i begyndelsen var der Fiber Channel (FC), og det var godt. Hvis du ville have en ægte SAN-versus delt direct-attached SCSI storage-FC er hvad du har. Men FC var frygtelig dyrt, kræver dedikerede afbrydere og vært bus adaptere, og det var svært at støtte i geografisk distribuerede miljøer. Derefter ramte iSCSI for omkring seks eller syv år siden SMB-markedet på en stor måde og begyndte langsomt at klatre ind i virksomheden.
den mellemliggende tid har set en masse dårligt informeret krangel om, hvilken der er bedre. Nogle gange har iSCSI-vs.-FC-debatten nået niveauet for en religiøs krig.
denne kamp var et resultat af to hovedfaktorer: for det første blev lagringsmarkedet delt mellem store etablerede lagringsleverandører, der havde foretaget en tung investering i FC-markedsføring mod yngre leverandører med lave omkostninger, kun iSCSI-tilbud. For det andet har administratorer en tendens til at lide det, de ved, og mistroer det, de ikke gør. hvis du har kørt FC SANs i årevis, vil du sandsynligvis tro, at iSCSI er en langsom, upålidelig arkitektur og hurtigere ville dø end at køre en kritisk service på den. Hvis du har kørt iSCSI SANs, tror du sandsynligvis FC SANs er massivt dyre og en bjørn at oprette og styre. Det er heller ikke helt sandt.
nu hvor vi er omkring et år nede i pike efter ratificeringen af FCoE (FC over Ethernet) – standarden, er tingene ikke meget bedre. Mange købere forstår stadig ikke forskellene mellem iSCSI-og Fiberkanalstandarderne. Selvom emnet let kunne udfylde en bog, her er en hurtig gennemgang.
grundlaget for FC
FC er en dedikeret lagringsnetværksarkitektur, der blev standardiseret i 1994. I dag implementeres det generelt med dedikerede HBAs (host bus adaptere) og kontakter-hvilket er hovedårsagen til, at FC betragtes som dyrere end andre lagringsnetværksteknologier.
med hensyn til ydeevne er det svært at slå FC ‘ s lave latenstid og høje gennemstrømning, fordi FC blev bygget fra bunden til at håndtere lagringstrafik. De behandlingscyklusser, der kræves for at generere og fortolke FCP-rammer (Fiber Channel protocol), aflæsses helt til dedikerede HBA ‘ er med lav latenstid. Dette frigør serverens CPU til at håndtere applikationer i stedet for at tale med opbevaring.
FC er tilgængelig i 1Gbps, 2Gbps, 4gbps, 8Gbps, 10Gbps og 20Gbps hastigheder. Afbrydere og enheder, der understøtter 1Gbps, 2Gbps, 4gbps og 8Gbps hastigheder er generelt bagudkompatible med deres langsommere brødre, mens 10Gbps og 20Gbps enheder ikke er, på grund af det faktum, at de bruger en anden rammekodningsmekanisme (disse to bruges generelt til interkontaktforbindelser).
derudover er FCP også optimeret til at håndtere lagringstrafik. I modsætning til protokoller, der kører oven på TCP/IP, er FCP en markant tyndere protokol med et enkelt formål, der generelt resulterer i en lavere skiftelatenstid. Det inkluderer også en indbygget strømstyringsmekanisme, der sikrer, at data ikke sendes til en enhed (hverken lager eller server), der ikke er klar til at acceptere dem. Efter min erfaring kan du ikke opnå den samme lave interconnect latency med nogen anden lagringsprotokol, der eksisterer i dag.
men FC og FCP har ulemper-og ikke kun høje omkostninger. Den ene er, at det kan være dyrt at understøtte lagringssammenkobling over lange afstande. Hvis du vil konfigurere replikering til et sekundært array på et eksternt sted, er du enten heldig nok til at have råd til mørk fiber (hvis den er tilgængelig), eller du bliver nødt til at købe dyre fcip-afstandsportaler.
derudover kræver styring af en FC-infrastruktur et specialiseret færdighedssæt, hvilket kan gøre administratoroplevelsen til et problem. For eksempel bruger FC-regulering kraftigt lange seksadecimale verdensomspændende knudepunkter og Portnavne (svarende til MAC-adresser i Ethernet), hvilket kan være en smerte at håndtere, hvis der foretages hyppige ændringer i stoffet.
den nitty-gritty på iSCSI
iSCSI er en lagringsnetværksprotokol bygget oven på TCP / IP-netværksprotokollen. Ratificeret som standard i 2004 er iscsis største påstand om berømmelse, at den kører over det samme netværksudstyr, der kører resten af virksomhedsnetværket. Det kræver ikke specifikt ekstra udstyr, hvilket gør det relativt billigt at implementere.
fra et præstationsperspektiv ligger iSCSI bag FC / FCP. Men når iSCSI implementeres korrekt, koger forskellen ned til et par millisekunder yderligere latenstid på grund af den overhead, der kræves for at indkapsle SCSI-kommandoer inden for den generelle TCP/IP-netværksprotokol. Dette kan gøre en enorm forskel for ekstremt høje transaktionsmæssige I/O-belastninger og er kilden til de fleste påstande om, at iSCSI er uegnet til brug i virksomheden. Sådanne arbejdsbelastninger er sjældne uden for Fortune 500, men i de fleste tilfælde er præstationsdeltaet meget snævrere.
iSCSI lægger også en større belastning på serverens CPU. Selvom iSCSI HBA ‘ er eksisterer, bruger de fleste iSCSI-implementeringer en programinitiator-i det væsentlige indlæser serverens processor med opgaven at oprette, sende og fortolke lagerkommandoer. Dette er også blevet brugt som et effektivt argument mod iSCSI. I betragtning af det faktum, at servere i dag ofte sender med betydeligt flere CPU-ressourcer, end de fleste applikationer kan håbe at bruge, er de tilfælde, hvor dette gør nogen form for væsentlig forskel, få og langt imellem.
iSCSI kan holde sin egen med FC i form af gennemstrømning gennem brug af flere 1Gbps Ethernet eller 10Gbps Ethernet links. Det drager også fordel af at være TCP / IP, idet det kan bruges over store afstande gennem eksisterende links. Dette brugsscenarie er normalt begrænset til San-til-SAN-replikation, men er betydeligt lettere og billigere at implementere end kun FC-alternativer.
bortset fra besparelser gennem reducerede infrastrukturomkostninger finder mange virksomheder iSCSI meget lettere at implementere. Meget af det færdighedssæt, der kræves for at implementere iSCSI, overlapper hinanden med den generelle netværksdrift. Dette gør iSCSI ekstremt attraktiv for mindre virksomheder med begrænset it-Personale og forklarer i vid udstrækning dens popularitet i dette segment.
denne lette implementering er et dobbeltkantet sværd. Da iSCSI er let at implementere, er det også let at implementere forkert. Manglende implementering ved hjælp af dedikerede netværksgrænseflader, for at sikre understøttelse af skiftefunktioner såsom strømningskontrol og Jumbo-indramning og implementering af multipath i/O er almindelige fejl, der kan resultere i manglende ydeevne. Historier bugner af internetfora med mislykkede iSCSI-implementeringer, der kunne have været undgået på grund af disse faktorer.
Fiber Channel over IP
FCoIP (Fiber Channel over Internet Protocol) er en nicheprotokol, der blev ratificeret i 2004. Det er en standard til indkapsling af FCP-rammer inden for TCP/IP-pakker, så de kan sendes over et TCP/IP-netværk. Det bruges næsten udelukkende til at bygge bro over FC-stoffer på flere steder for at muliggøre San-til-SAN-replikation og backup over lange afstande.
på grund af ineffektiviteten af fragmentering af store FC-rammer i flere TCP/IP-pakker (van-kredsløb understøtter typisk ikke pakker over 1.500 bytes), er det ikke bygget til at være lav latenstid. I stedet er det bygget til at tillade geografisk adskilte Fiberkanalstoffer at blive forbundet, når mørk fiber ikke er tilgængelig til at gøre det med native FCP. FCIP findes næsten altid i FC-afstandsportaler-i det væsentlige FC/FCP-til-FCIP-broer-og bruges sjældent, hvis nogensinde, indbygget af lagerenheder som en server til lagringsadgangsmetode.
Fiber Channel over Ethernet
FCoE (Fiber Channel over Ethernet) er den nyeste lagringsnetværksprotokol for bunken. Ratificeret som standard i juni sidste år, FCoE er Fiber Channel-samfundets svar på fordelene ved iSCSI. Ligesom iSCSI bruger FCoE standard multipurpose Ethernet-netværk til at forbinde servere med opbevaring. I modsætning til iSCSI kører den ikke over TCP/IP-det er sin egen Ethernet-protokol, der optager et mellemrum ved siden af IP i OSI-modellen.
denne forskel er vigtig at forstå, da den har både gode og dårlige resultater. Det gode er, at selvom FCoE kører over de samme generelle formål, som iSCSI gør, oplever det betydeligt lavere end-to-end latenstid på grund af det faktum, at TCP/IP-overskriften ikke behøver at blive oprettet og fortolket. Det dårlige er, at det ikke kan dirigeres over en TCP/IP-van. Ligesom FC kan FCoE kun køre over et lokalt netværk og kræver en bro for at oprette forbindelse til et fjernt stof.
på serversiden bruger de fleste FCoE-implementeringer 10 Gbps Ethernet FCoE CNAs (konvergerede netværkskort), som både kan fungere som netværkskort og FCoE HBAs-aflæsning af arbejdet med at tale med opbevaring svarende til den måde, som FC HBAs gør. Dette er et vigtigt punkt, da kravet om en separat FC HBA ofte var en god grund til at undgå FC helt. Efterhånden som tiden går, servere kan ofte sendes med FCoE-kompatible CNAs indbygget, i det væsentlige at fjerne dette som en omkostningsfaktor helt.
Fcoes primære fordele kan realiseres, når det implementeres som en udvidelse af et allerede eksisterende Fiberkanalnetværk. På trods af at have en anden fysisk transportmekanisme, som kræver et par ekstra trin at implementere, kan FCoE bruge de samme styringsværktøjer som FC, og meget af erfaringerne med at betjene et FC-stof kan anvendes til dets konfiguration og vedligeholdelse.
at sætte det hele sammen
Der er ingen tvivl om, at debatten mellem FC og iSCSI vil fortsætte med at rase. Begge arkitekturer er gode til bestemte opgaver. Men at sige, at FC er godt for virksomheden, mens iSCSI er godt for SMB, er ikke længere et acceptabelt svar. Tilgængeligheden af FCoE går langt i retning af at spise i iscsis omkostnings-og konvergensargument, mens den stigende forekomst af 10Gbps Ethernet og stigende server CPU-ydeevne spiser i FCS præstationsargument.
uanset hvilken teknologi du beslutter dig for at implementere til din organisation, så prøv ikke at blive suget ind i religionskrigen og lav dit hjemmearbejde, før du køber. Du kan blive overrasket over, hvad du finder.
denne artikel, ” Fiber Channel vs. iSCSI: Krigen fortsætter, ” oprindeligt dukkede op på InfoWorld.com. Læs mere af Matt Prigges Information Overload blog og følg den seneste udvikling inden for datalagring og informationsstyring på InfoWorld.com.