I begynnelsen var det Fibre Channel (FC), og det var bra. Hvis du ønsket en ekte SAN - kontra delt direkte tilkoblet SCSI-lagring - er FC det du fikk. Men FC var veldig dyrt, og krevde dedikerte brytere og vertbussadaptere, og det var vanskelig å støtte i geografisk distribuerte miljøer. For rundt seks-syv år siden traff iSCSI SMB-markedet på en stor måte og sakte begynte å klatre inn i bedriften.
Den mellomliggende tiden har sett mye dårlig informert krangel om hvilken som er bedre. Noen ganger har iSCSI-vs-FC-debatten nådd nivået av en religiøs krig.
[Også på .com: Last ned Logan Harbaughs Archiving Deep Dive og få grunnleggende om lovoverholdelse. | Lær hvordan deduplisering av data kan redusere den eksplosive veksten av data med Keith Schultzs Deep Dive Report. ]
Denne kampen var et resultat av to hovedfaktorer: For det første ble lagringsmarkedet delt mellom store sittende lagringsleverandører som hadde gjort en tung investering i FC-markedsføring mot yngre leverandører med lave, iSCSI-eneste tilbud. For det andre har administratorer en tendens til å like det de vet, og mistillit til det de ikke gjør. Hvis du har kjørt FC SAN-er i årevis, vil du sannsynligvis tro at iSCSI er en treg, upålitelig arkitektur og ville fort dø enn å kjøre en kritisk tjeneste på den. Hvis du har kjørt iSCSI SAN-er, tror du sannsynligvis at FC SAN-er er enormt dyre og en bjørn å sette opp og administrere. Ingen av dem er helt sanne.
Nå som vi er omtrent et år nede i gjedda etter ratifiseringen av FCoE (FC over Ethernet) -standarden, er det ikke mye bedre. Mange kjøpere forstår fortsatt ikke forskjellene mellom iSCSI og Fibre Channel-standardene. Selv om emnet lett kan fylle en bok, er det en kort oversikt.
Grunnleggende om FC
FC er en dedikert lagringsnettverksarkitektur som ble standardisert i 1994. I dag implementeres den generelt med dedikerte HBA (vertsbusadaptere) og brytere - noe som er hovedårsaken til at FC anses som dyrere enn andre teknologier for lagringsnettverk.
Når det gjelder ytelse, er det vanskelig å slå den lave latenstiden og den høye gjennomstrømningen til FC, fordi FC ble bygget fra grunnen av for å håndtere lagringstrafikk. Behandlingssyklusene som kreves for å generere og tolke FCP-rammer (Fibre Channel Protocol), lastes helt ut til dedikerte HBA-er med lav latens. Dette frigjør serverens CPU for å håndtere applikasjoner i stedet for å snakke med lagring.
FC er tilgjengelig i hastigheter på 1 Gbps, 2 Gbps, 4 Gbps, 8 Gbps, 10 Gbps og 20 Gbps. Brytere og enheter som støtter hastigheter på 1 Gbps, 2 Gbps, 4 Gbps og 8 Gbps, er generelt bakoverkompatible med sine langsommere brødre, mens 10 Gbps og 20 Gbps-enhetene ikke er det, på grunn av at de bruker en annen rammekodningsmekanisme (disse to brukes vanligvis for koblinger).
I tillegg er FCP også optimalisert for å håndtere lagringstrafikk. I motsetning til protokoller som kjører på toppen av TCP / IP, er FCP en betydelig tynnere, enkeltbruksprotokoll som vanligvis resulterer i lavere byttelatens. Den inkluderer også en innebygd flytkontrollmekanisme som sikrer at data ikke sendes til en enhet (enten lagring eller server) som ikke er klar til å akseptere den. Etter min erfaring kan du ikke oppnå den samme lave sammenkoblingsforsinkelsen med noen annen lagringsprotokoll som eksisterer i dag.
Likevel har FC og FCP ulemper - og ikke bare høye kostnader. Det ene er at det kan være dyrt å støtte sammenkobling av lagring over lange avstander. Hvis du vil konfigurere replikering til en sekundær matrise på et eksternt sted, er du enten heldig nok til å ha råd til mørk fiber (hvis den er tilgjengelig), eller du må kjøpe dyre FCIP-avstandsportaler.
I tillegg krever administrering av en FC-infrastruktur et spesialisert ferdighetssett, noe som kan gjøre at administratoren opplever et problem. FC-sonering bruker for eksempel lang bruk av lange heksadesimale verdensomspennende knutepunkt- og portnavn (ligner på MAC-adresser i Ethernet), noe som kan være en smerte å håndtere hvis hyppige endringer gjøres i stoffet.
Den nitty-gritty på iSCSI
iSCSI er en lagringsnettverksprotokoll bygget på toppen av TCP / IP-nettverksprotokollen. Ratifisert som en standard i 2004, er iSCSIs største påstand om berømmelse at den kjører over det samme nettverksutstyret som driver resten av bedriftsnettverket. Det krever ikke spesifikt ekstra maskinvare, noe som gjør det relativt billig å implementere.
Fra et ytelsesperspektiv henger iSCSI etter FC / FCP. Men når iSCSI er implementert riktig, koker forskjellen ned til noen millisekunder med ekstra ventetid på grunn av overhead som kreves for å kapsle inn SCSI-kommandoer i TCP / IP-nettverksprotokollen. Dette kan utgjøre en stor forskjell for ekstremt høye transaksjonelle I / O-belastninger, og er kilden til de fleste påstander om at iSCSI er uegnet til bruk i bedriften. Slike arbeidsmengder er sjeldne utenfor Fortune 500, men i de fleste tilfeller er ytelsesdeltaet mye smalere.
iSCSI legger også større belastning på CPU-en til serveren. Selv om det eksisterer iSCSI HBA-maskinvarer, bruker de fleste iSCSI-implementeringer en programvareinitiator - i det vesentlige å laste serverens prosessor med oppgaven å opprette, sende og tolke lagringskommandoer. Dette har også blitt brukt som et effektivt argument mot iSCSI. Men med tanke på at servere i dag ofte leverer med betydelig mer CPU-ressurser enn de fleste applikasjoner kan håpe å bruke, er tilfellene der dette utgjør noen form for vesentlig forskjell, få og langt mellom.
iSCSI kan holde sitt med FC når det gjelder gjennomstrømning ved bruk av flere 1Gbps Ethernet- eller 10Gbps Ethernet-lenker. Det har også fordeler av å være TCP / IP ved at den kan brukes over store avstander gjennom eksisterende WAN-lenker. Dette bruksscenariet er vanligvis begrenset til SAN-til-SAN-replikering, men er betydelig enklere og billigere å implementere enn kun FC-alternativer.
Bortsett fra besparelser gjennom reduserte infrastrukturelle kostnader, synes mange bedrifter iSCSI er mye lettere å distribuere. Mye av det ferdighetssettet som kreves for å implementere iSCSI overlapper det som generell nettverksdrift. Dette gjør iSCSI ekstremt attraktivt for mindre bedrifter med begrenset IT-bemanning og forklarer i stor grad dens popularitet i det segmentet.
Denne lette distribusjonen er et tveegget sverd. Fordi iSCSI er enkelt å implementere, er det også enkelt å implementere feil. Manglende implementering ved bruk av dedikerte nettverksgrensesnitt, for å sikre støtte for å bytte funksjoner som strømningskontroll og jumbo-innramming, og å implementere flerveis I / O er vanlige feil som kan resultere i svak ytelse. Historier florerer på internettfora om mislykkede iSCSI-distribusjoner som kunne vært unngått på grunn av disse faktorene.
Fiber Channel over IP
FCoIP (Fibre Channel over Internet Protocol) er en nisjeprotokoll som ble ratifisert i 2004. Det er en standard for innkapsling av FCP-rammer i TCP / IP-pakker, slik at de kan sendes over et TCP / IP-nettverk. Den brukes nesten utelukkende til å bygge bro på FC-stoffer på flere steder for å muliggjøre SAN-til-SAN-replikering og sikkerhetskopiering over lange avstander.
På grunn av ineffektiviteten med å fragmentere store FC-rammer i flere TCP / IP-pakker (WAN-kretser støtter vanligvis ikke pakker over 1500 byte), er den ikke bygget for å ha lav ventetid. I stedet er den bygget for å tillate geografisk atskilte fiberkanalstoffer å koble sammen når mørk fiber ikke er tilgjengelig for å gjøre det med innfødt FCP. FCIP finnes nesten alltid i FC avstandsportaler - i det vesentlige FC / FCP-til-FCIP-broer - og blir sjelden om noen gang brukt naturlig av lagringsenheter som en server-til-lagrings tilgangsmetode.
Fibre Channel over Ethernet
FCoE (Fibre Channel over Ethernet) er den nyeste lagringsnettverksprotokollen til gjengen. Ratifisert som en standard i juni i fjor, er FCoE Fibre Channel-samfunnets svar på fordelene med iSCSI. I likhet med iSCSI bruker FCoE standard flerbruks Ethernet-nettverk for å koble servere med lagring. I motsetning til iSCSI, kjører den ikke over TCP / IP - den er sin egen Ethernet-protokoll som opptar en plass ved siden av IP i OSI-modellen.
Denne forskjellen er viktig å forstå, da den har både gode og dårlige resultater. Det gode er at selv om FCoE kjører over de samme bryterne som iSCSI gjør, opplever den betydelig lavere end-to-end-latens på grunn av at TCP / IP-headeren ikke trenger å opprettes og tolkes. Det dårlige er at det ikke kan rutes over et TCP / IP WAN. I likhet med FC kan FCoE bare kjøre over et lokalt nettverk og krever en bro for å koble til et eksternt stoff.
På serversiden bruker de fleste FCoE-implementeringer 10Gbps Ethernet FCoE CNAer (Converged Network Adapters), som både kan fungere som nettverkskort og FCoE HBA-er - avlaster arbeidet med å snakke med lagring på samme måte som FC HBA-er. Dette er et viktig poeng ettersom kravet til en separat FC HBA ofte var en god grunn til å unngå FC helt. Etter hvert som tiden går, kan servere ofte sendes med innebygde FCNA-kompatible CNAer, og i det vesentlige fjerne dette som en kostnadsfaktor helt.
FCoEs primære fordeler kan realiseres når den implementeres som en utvidelse av et eksisterende Fibre Channel-nettverk. Til tross for at de har en annen fysisk transportmekanisme, som krever noen ekstra trinn for å implementere, kan FCoE bruke de samme administrasjonsverktøyene som FC, og mye av erfaringene med å betjene et FC-stoff kan brukes på konfigurasjon og vedlikehold.
Sette alt sammen
Det er ingen tvil om at debatten mellom FC og iSCSI vil fortsette å rase. Begge arkitekturer er gode for visse oppgaver. Å si at FC er bra for bedrift mens iSCSI er bra for SMB, er imidlertid ikke lenger et akseptabelt svar. Tilgjengeligheten av FCoE går langt i retning av å spise iSCSIs kostnads- og konvergensargument, mens den økende forekomsten av 10Gbps Ethernet og økende CPU-ytelse på serveren spiser inn i FCs ytelsesargument.
Uansett hvilken teknologi du bestemmer deg for å implementere for organisasjonen din, prøv å ikke bli sugd inn i den religiøse krigen og gjøre leksene dine før du kjøper. Du kan bli overrasket over det du finner.
Denne artikkelen, "Fibre Channel vs. iSCSI: War fortsetter," dukket opprinnelig opp på .com. Les mer av Matt Prigges informasjonsoverbelastningsblogg og følg den siste utviklingen innen datalagring og informasjonsadministrasjon på .com.
