Purtroppo, anche dopo tutte le ultime evoluzioni tecnologiche, ancora oggi c’è gente che è convinta che FC è meglio di iSCSI. Ovviamente questo non è vero, soprattuto quando si parla della maggior parte degli utenti finali Italiani. Scegliere fra iSCSI e FC non è una questione di protocollo di comunicazione, (quasi) tutti gli storage parlano SCSI, è più una questione di media, di “incapsulamento del protocollo” e quindi dell’efficienza nel trasporto dei comandi SCSI e dei dati.
Storicamente lo storage è FC
Chi si occupa di storage è abituato, soprattutto nella grande azienda, ad avere a che fare con la Fibra (Fibre channel). FC, grazie alle sue caratteristiche intrinseche, è un protocollo molto performante e che garantisce la qualità della trasmissione del pacchetto fra lo storage e i server. Questo, negli anni, lo ha portato ad essere il protocollo principe e tutti gli storage enterprise lo hanno adottato come protocollo primario (e standard). Nel tempo, con la diffusione delle SAN anche in aziende più piccole, questo è rimasto un sistema sicuro e relativamente facile per gestire la comunicazione fra host e storage.
Poi c’è stata un’evoluzione
Ethernet (e TCP/IP) nel frattempo, hanno avuto uno sviluppo esagerato e oggi abbiamo reti a 10Gbit, con la previsione di 40 e 100 a breve, protocolli molto sofisticati, QoS, e così via.
FC, per quanto ora anche a 16Gbit/s (e in futuro 32), non sta avendo uno sviluppo così rapido e il suo costo e la complessità generale sono dei freni sempre più forti.
In particolare, è sufficiente guardare quanti produttori hanno già adottato l’FC a 16Gbit: pochissimi. Non che ce ne sia effettivamente bisogno per la maggior parte dei server o degli array, ma comunque il 16Gbit non è la priorità ne di chi compra le HBA (costose) e ne di chi produce gli Array (porte a 8Gbit bastano per il 99% dei casi).
Al contrario, i server di ultima generazione possono essere tutti ordinati con porte a 10Gbit, gli switch a 10Gbit si stanno diffondendo molto rapidamente, il loro costo si sta progressivamente abbassando ed è quindi tutto più facile.
La percezione errata
Premettendo che TCP/IP ha un modo di lavorare tale per cui quando è necessario ritrasmettere dei pacchetti a causa di errori, la velocità di trasmissione cala. E’ necessario sempre notare che l’idea che gli utenti finali si sono fatti è spesso sbagliata. Soprattutto all’inizio, iSCSI veniva spinto come protocollo per fare delle SAN economiche, questo è vero, ma nel tempo le cose sono cambiate radicalmente.
Uno dei problemi più gravi che affligge iSCSI non è l’iSCSI o l’ethernet in se ma gli switch scadenti che vengono usati. Faccio un esempio: uno switch FC di base costa 4/5K euro e ha un numero di porte decisamente limitato (8 o 12), per utilizzarlo sono necessarie delle HBA ( Host Bus Adapter) che costano l’una fra 700 e 1500 euro, e infine i cavi in fibra (che costano anche quelli, sicuramente più di quelli di rame). Il cliente è disposto a spendere per tutto questo.
Dall’altro lato, quando valuta iSCSI prende spesso in considerazione degli switch economici (spesso nell’ordine delle centinaia di euro), non verifica se le NIC (o le CNA) sono all’altezza della situazione. E’ ovvio che in questo secondo caso il materiale ha spesso prestazioni scadenti che quindi crea problemi di ogni tipo (es.: errori di trasmissione) e che traducono spesso in una velocità scarsa!
Anche il protocollo Ethernet, negli anni, ha subito dei miglioramenti straordinari e ora è possibile avere la sicurezza di quali pacchetti hanno una priorità nella trasmissione (es. DCB). Certo è che, anche in questo caso, se compri il tuo switch dal computer discount è molto probabile che certe funzionalità più sofisticate non siano presenti!
Basta guardarsi intorno
La maggior parte dei fornitori storage dell’ultima generazione supportano sia FC che iSCSI. In alcuni casi specifici addirittura solo iSCSI, e non parlo del tuo NAS di casa!
Certo, non si può negare che gli sforzi fatti da colossi come CISCO negli ultimi anni, non abbiamo contribuito (non nel senso che voleva cisco forse… ma questo è un altro discorso). In ogni caso l’utilizzo in generale di Ethernet come media di trasmissione e TCP/IP come protocollo di base semplifica, e non di poco, le architetture dei DC.
Un canale a 10Gbit, soprattutto quando ridondato e quindi bilanciato, può portare comodamente sia il traffico IP che tutto quello ethernet. Questo significa molti meno cavi, meno switch e meno complessità in generale che poi si traduce in meno costi e facilità di gestione!
Anche se, per diversi motivi, nella large enterprise la situazione è diversa e i cambiamenti sono sempre più lenti, anche qui si registra un aumento di Ethernet come media di trasporto per lo storage.
Perchè è importante
Il mercato FC è comunque in declino, lo dicono i dati di vendita dei maggiori vendor.
Nel caso si sia investito molto in FC è difficile pensare ad un cambiamento radicale (fra l’altro funziona molto bene e ci sono molti skill a disposizione). Quando però si disegnano infrastrutture nuove non ha senso oggi pensare a cose diverse da Ethernet… sia per i costi ma anche poi per la gestione che viene dopo.
Secondo me c’è da considerare che 10Gbit Ethernet è lungi dall’essere del tutto pronto.. sopratutto per colpa/causa del TOE, il TCP Offload Engine che non è ancora pienamente supportato ed è uno standard ancora in via definizione.
Gianluca,
Il TOE non è un protocollo ma una funzionalità che si trova in alcune NIC piuttosto che in altre. Possiamo discutere quali funzionano meglio e quali no ma è una questione secondaria. Molti vendor che conosco (anche quelli che vendono soluzioni 100% flash) stanno vendendo tanto iSCSI quanti FC e Nimble l’azienda più di successo nel mondo storage da anni vendoe solo iSCSI. FC va soprattutto da chi ha già l’infrastruttura fatta in quel modo.
ciao,
E
Io rimango un fan di un prodotto di nicchia: ATA over Ethernet. Peccato che lo porti avanti solo Coraid…
Forse dovresti informati un po’ di più’… comunque buon natale.
Marco.
Non si lancia il sasso e poi si ritira la mano…
La discussione è aperta e ogni commento è il benvenuto (anche quello dei vendor).
Buon natale anche a te.
E
Generalmente mi trovo in sintonia con i tuoi post, tanto da non sentire la necessita’ di commentare =), tuttavia in questo caso il primo pensiero dopo la lettura e’ stato:
it depends !
lasciando stare considerazioni tecniche sugli overhead di protocolli/encoding ecc, togliendo tutta la storiella della convergenza network/storage e SDDC, la mia perplessita’ deriva proprio dal paragrafo “La percezione errata”:
lo dico in quanto non e’ piu’ cosi’ marcato il delta di prezzo tra una soluzione FC 8Gb (non 16Gb) ed una 10GbE iScsi, ovviamente al netto dello storage array, vuoi per la “commodizzazione” dell’hardware ,vuoi perche’ l’high mark e’ ora 16Gb, fatto sta che un fabric switch 24 porte tipo i silkworm 300/qlogic 5800 con SFP licenze base ecc sono oramai al livello prezzo di un switch 10Gb “medio”..e tuttavia, come hai ben sottolineato nel progettare una soluzione iScsi 10GbE bisogna far molta, ma molta, piu’ attenzione alla scelta dei componenti, cosa che invece in un ambito FC 8b e’ diciamo “semplificato” da anni di affinamento/consolidamento tecnologico .
Lo dico perche’ si sente sempre piu’ spesso dire per i corridoi che per creare una SAN iScsi bastano quatto cavi CX4 e un paio di switch 10GbE e la cosa e’ fatta, mente in realta’ il rapporto aspettative/risultati di solito per chi abbraccia questo pensiero e’ penosamente negativo.
Ecco il mio punto e’:
FC 8Gb e’ nettamente piu’ prevedibile in termini di performance/latenze/gestibilita’ e lo e’ ad un prezzo di entrata inferiore
rispetto ad una soluzione iScsi 10GbE “generica” dove tipicamente si impiegano switch di fascia media “generici” senza considerare DCB, MLACP e soprattutto i “deep packet buffer”, cose che effettivamente portano l’iScsi 10GbE a superare FC 8Gb ma appena inserite come requsiti nei feature selector dei vendor di switch fanno livitare assai il costo della soluzione, perche’ non venitemi a dire che un Dell PowerConnect 6224 e’ uguale a un Force10, o un HP2900 ad un HP 5800/5900 o un c3750 ad un Nexus e via discorrendo.
Certamente siamo all’intersezione e iScsi e’ sulla linea ascendente (FCoE non e’ un ostacolo imho), soprattuto pensando a 40/100GbE ma io non direi che l’iSCSI 10GbE e’ piu’ conveniente dell’FC tout court (senza i casi limite del direct attach Fc di Luigi) , direi appunto:
it depends !
Saluti e buon anno a tutti!
Antonio,
Concordo con te che con FC è più facile ottenere risultati sicuri (anche grazie al protocollo che è alla base).
D’altro canto la convergenza su ethernet e il fatto che comunque sui 10gbE puoi far girare anche tutto il traffico IP dei server porta a risparmi su tutti i fronti.
Ciao e buon anno.
E
sono tutte argomentazioni interessanti, ma tu configureresti oggi con iSCSI per un sistema produttivo (anche piccolo) ? Non parlo di VDI.
Tutti i giorni, senza dubbi!
Ciao a tutti,
personalmente sono nato e cresciuto con il FC e ho per la verità fatto poche, pochissime implementazioni in iSCSI. La mia esperienza personale mi porta comunque a dire che il delta economico tra soluzioni FC 8GB e iSCSI 10GB oggi sia praticamente nullo o a vantaggio del FC, tanto più che per installazioni “piccole” (quelle che per la maggior parte vedo/implemento/gestisco) non è più necessario una infrastruttura FC esterna, ma si può sfruttare il direct-attach.
La mia piccola esperienza iSCSI conferma inoltre appieno che se le componenti netowrking NON sono curate e progettate correttamente, i risultati sono “pessimi”.
Sto cominciando ad utilizzare con più frequenza le connessioni Ethernet 10GB a causa (si fa per dire) dei nuovi progetti storage basati su VSA: qui non si scappa, iSCSI o NFS che sia.