i början fanns Fibre Channel (FC), och det var bra. Om du ville ha en sann SAN-kontra delad direktansluten SCSI-Lagring-FC är vad du har. Men FC var fruktansvärt dyrt, kräver dedikerade switchar och värdbussadaptrar, och det var svårt att stödja i geografiskt distribuerade miljöer. Sedan, för cirka sex eller sju år sedan, slog iSCSI SMB-marknaden på ett stort sätt och började långsamt klättra in i företaget.
den mellanliggande tiden har sett en hel del dåligt informerade gräl om vilken som är bättre. Ibland har iSCSI-vs.-FC-debatten nått nivån på ett religiöst krig.denna kamp var ett resultat av två huvudfaktorer: för det första delades lagringsmarknaden mellan stora befintliga lagringsleverantörer som hade gjort en stor investering i FC-marknadsföring mot yngre leverantörer med billiga, iSCSI-erbjudanden. För det andra tenderar administratörer att gilla vad de vet och misstro vad de inte gör. om du har kört FC SANs i flera år kommer du sannolikt att tro att iSCSI är en långsam, opålitlig arkitektur och skulle förr dö än att köra en kritisk tjänst på den. Om du har kört iSCSI SANs tror du förmodligen att FC SANs är massivt dyra och en björn att ställa in och hantera. Inte heller är helt sant.
Nu när vi är ungefär ett år ner gädda efter ratificeringen av FCoE (FC over Ethernet) standard, saker är inte mycket bättre. Många köpare förstår fortfarande inte skillnaderna mellan iSCSI och Fiber Channel-standarderna. Även om ämnet lätt kan fylla en bok, här är en snabb genomgång.
grunden för FC
FC är en dedikerad lagringsnätverksarkitektur som standardiserades 1994. Idag implementeras det generellt med dedikerade HBA (värdbussadaptrar) och switchar-vilket är den främsta anledningen till att FC anses vara dyrare än andra lagringsnätverkstekniker.
När det gäller prestanda är det svårt att slå FC: s låga latens och höga genomströmning, eftersom FC byggdes från grunden för att hantera lagringstrafik. De bearbetningscykler som krävs för att generera och tolka FCP-ramar (Fibre Channel protocol) avlastas helt till dedikerade HBA med låg latens. Detta frigör serverns CPU för att hantera applikationer snarare än att prata med lagring.
FC finns i 1Gbps, 2Gbps, 4Gbps, 8Gbps, 10Gbps och 20Gbps hastigheter. Växlar och enheter som stöder 1Gbps, 2Gbps, 4Gbps och 8Gbps hastigheter är i allmänhet bakåtkompatibla med sina långsammare bröder, medan 10Gbps och 20Gbps-enheterna inte är det, på grund av att de använder en annan ramkodningsmekanism (dessa två används vanligtvis för Interswitch-länkar).
dessutom är FCP också optimerad för att hantera lagringstrafik. Till skillnad från protokoll som körs ovanpå TCP/IP är FCP ett betydligt tunnare protokoll med ett enda syfte som i allmänhet resulterar i en lägre omkopplingsfördröjning. Den innehåller också en inbyggd flödeskontrollmekanism som säkerställer att data inte skickas till en enhet (antingen lagring eller server) som inte är redo att acceptera den. Enligt min erfarenhet kan du inte uppnå samma låga interconnect latens med något annat lagringsprotokoll som finns idag.
men FC och FCP har nackdelar – och inte bara höga kostnader. En är att det kan vara dyrt att stödja lagringssammankoppling över långa avstånd. Om du vill konfigurera replikering till en sekundär array på en fjärrplats, har du antingen turen att ha råd med mörk fiber (om den är tillgänglig) eller du måste köpa dyra FCIP-distansgateways.
dessutom kräver hantering av en FC-Infrastruktur en specialiserad kompetensuppsättning, vilket kan göra att administratören upplever ett problem. Till exempel använder FC-zonering tung användning av långa hexadecimala världsomspännande nod-och portnamn (liknande MAC-adresser i Ethernet), vilket kan vara en smärta att hantera om frekventa ändringar görs i tyget.
nitty-gritty på iSCSI
iSCSI är ett lagringsnätverksprotokoll byggt ovanpå TCP / IP-nätverksprotokollet. Ratificerad som standard 2004 är iSCSI: s största anspråk på berömmelse att den körs över samma nätverksutrustning som kör resten av företagsnätverket. Det kräver inte specifikt någon extra hårdvara, vilket gör det relativt billigt att implementera.
ur ett prestationsperspektiv ligger iSCSI bakom FC / FCP. Men när iSCSI implementeras korrekt, köljer skillnaden ner till några millisekunder av ytterligare latens på grund av den överliggande som krävs för att inkapsla SCSI-kommandon inom det allmänna TCP/IP-nätverksprotokollet. Detta kan göra en enorm skillnad för extremt höga transaktionella I/O-belastningar och är källan till de flesta påståenden om att iSCSI är olämplig för användning i företaget. Sådana arbetsbelastningar är sällsynta utanför Fortune 500, men i de flesta fall är performance delta mycket smalare.
iSCSI lägger också en större belastning på serverns CPU. Även om hårdvara iSCSI HBA existerar, använder de flesta iSCSI-implementeringar en mjukvaruinitiator-i huvudsak laddar serverns processor med uppgiften att skapa, skicka och tolka lagringskommandon. Detta har också använts som ett effektivt argument mot iSCSI. Men med tanke på att servrar idag ofta levereras med betydligt mer CPU-resurser än de flesta applikationer kan hoppas kunna använda, är de fall där detta gör någon form av materiell skillnad få och långt mellan.
iSCSI kan hålla sin egen med FC när det gäller genomströmning genom användning av flera 1Gbps Ethernet eller 10Gbps Ethernet-länkar. Det drar också nytta av att vara TCP / IP genom att det kan användas över stora avstånd genom befintliga WAN-länkar. Detta användningsscenario är vanligtvis begränsat till SAN-till-SAN-replikering, men är betydligt enklare och billigare att implementera än FC-only-alternativ.
bortsett från besparingar genom minskade infrastrukturkostnader, tycker många företag att iSCSI är mycket lättare att distribuera. Mycket av den kompetens som krävs för att implementera iSCSI överlappar den för allmän nätverksoperation. Detta gör iSCSI extremt attraktivt för mindre företag med begränsad IT-bemanning och förklarar till stor del dess popularitet inom det segmentet.
denna enkla utplacering är ett tveeggat svärd. Eftersom iSCSI är lätt att implementera är det också lätt att implementera felaktigt. Underlåtenhet att implementera med hjälp av dedikerade nätverksgränssnitt, för att säkerställa stöd för växlingsfunktioner som flödeskontroll och jumbo-inramning och för att implementera multipath I/O är vanliga misstag som kan leda till svag prestanda. Berättelser finns i överflöd på Internetforum om misslyckade iSCSI-distributioner som kunde ha undvikits på grund av dessa faktorer.
Fiber Channel over IP
FCoIP (Fiber Channel over Internet Protocol) är ett nischprotokoll som ratificerades 2004. Det är en standard för inkapsling av FCP-ramar i TCP/IP-paket så att de kan skickas över ett TCP/IP-nätverk. Det används nästan uteslutande för att överbrygga FC-tyger på flera platser för att möjliggöra San-till-SAN-replikering och säkerhetskopiering över långa avstånd.
på grund av ineffektiviteten att fragmentera stora FC-ramar i flera TCP/IP-paket (WAN-kretsar stöder vanligtvis inte paket över 1500 byte), är det inte byggt för att vara låg latens. Istället är den byggd för att tillåta geografiskt separerade Fiberkanaltyger att kopplas när mörk fiber inte är tillgänglig för att göra det med inbyggd FCP. FCIP finns nästan alltid i FC-avståndsgateways-i huvudsak FC/FCP-till-FCIP-broar-och används sällan om någonsin av lagringsenheter som en server till lagringsåtkomstmetod.
Fibre Channel over Ethernet
FCoE (Fibre Channel over Ethernet) är det senaste lagringsnätverksprotokollet i gänget. FCoE ratificerades som standard i juni förra året och är Fibre Channel-samhällets svar på fördelarna med iSCSI. Liksom iSCSI använder FCoE vanliga Ethernet-nätverk för flera ändamål för att ansluta servrar med lagring. Till skillnad från iSCSI körs det inte över TCP/IP-det är sitt eget Ethernet-protokoll som upptar ett utrymme bredvid IP i OSI-modellen.
denna skillnad är viktig att förstå eftersom den har både bra och dåliga resultat. Det goda är att även om FCoE går över samma generella omkopplare som iSCSI gör, upplever den betydligt lägre end-to-end-latens på grund av att TCP/IP-rubriken inte behöver skapas och tolkas. Det dåliga är att det inte kan dirigeras över en TCP/IP WAN. Liksom FC kan FCoE bara köra över ett lokalt nätverk och kräver en bro för att ansluta till ett fjärrtyg.
på serversidan använder de flesta FCoE-implementeringar 10Gbps Ethernet FCoE CNAs (Converged Network Adapters), som både kan fungera som nätverksadaptrar och FCoE HBA-avlastning av arbetet med att prata med lagring som liknar det sätt som FC HBA gör. Detta är en viktig punkt eftersom kravet på en separat FC HBA ofta var en bra anledning att undvika FC helt och hållet. Med tiden kan servrar vanligtvis skickas med FCoE-kapabla CNA inbyggda, vilket i huvudsak tar bort detta som en kostnadsfaktor helt.
FCoE: s primära fördelar kan realiseras när det implementeras som en förlängning av ett befintligt Fiber Channel-nätverk. Trots att FCoE har en annan fysisk transportmekanism, som kräver några extra steg att implementera, kan FCoE använda samma hanteringsverktyg som FC, och mycket av erfarenheten från att använda ett FC-tyg kan tillämpas på dess konfiguration och underhåll.
att sätta ihop allt
det är ingen tvekan om att debatten mellan FC och iSCSI kommer att fortsätta att rasa. Båda arkitekturerna är bra för vissa uppgifter. Att säga att FC är bra för företag medan iSCSI är bra för SMB är dock inte längre ett acceptabelt svar. Tillgängligheten av FCoE går långt mot att äta in i iSCSI: s kostnads-och konvergensargument medan den ökande förekomsten av 10 Gbps Ethernet och ökande server-CPU-prestanda äter in i FC: s prestandargument.
oavsett vilken teknik du väljer att implementera för din organisation, försök att inte sugas in i religionskriget och gör dina läxor innan du köper. Du kan bli förvånad över vad du hittar.
den här artikeln, ” Fibre Channel vs. iSCSI: Kriget fortsätter, ” ursprungligen dök upp på InfoWorld.com. Läs mer om Matt Prigges Information Overload-blogg och följ den senaste utvecklingen inom datalagring och informationshantering på InfoWorld.com.