I starten var der Fibre Channel (FC), og det var godt. Hvis du ønskede en ægte SAN - kontra delt direkte knyttet SCSI-lager - FC er hvad du fik. Men FC var frygtelig dyrt og krævede dedikerede switche og host-busadaptere, 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 strid om, hvilken der er bedre. Nogle gange har iSCSI-vs-FC-debatten nået niveauet for en religiøs krig.
[Også på .com: Download Logan Harbaughs Archiving Deep Dive, og få det grundlæggende i overholdelse af lovgivningen. | Lær hvordan dataduplikering kan bremse den eksplosive vækst i data med Keith Schultz's Deep Dive Report. ]
Denne kamp var et resultat af to hovedfaktorer: For det første blev lagermarkedet opdelt mellem store etablerede lagerleverandører, der havde foretaget en stor investering i FC-markedsføring mod yngre leverandører med billige iSCSI-tilbud. For det andet har admins tendens til at kunne lide det, de ved, og mistro, hvad de ikke gør. Hvis du har kørt FC SAN'er i årevis, vil du sandsynligvis tro, at iSCSI er en langsom, upålidelig arkitektur og hurtigere ville dø end at køre en kritisk tjeneste på den. Hvis du har kørt iSCSI SAN'er, tror du sandsynligvis, at FC SAN'er er enormt dyre og en bjørn at oprette og administrere. Ingen af dem er helt sandt.
Nu hvor vi er omkring et år nede på gedderne efter ratificeringen af FCoE (FC over Ethernet) -standarden, er tingene ikke meget bedre. Mange købere forstår stadig ikke forskellene mellem iSCSI og Fibre Channel standarder. Selvom emnet let kunne udfylde en bog, er her en hurtig gennemgang.
Grundlaget for FC
FC er en dedikeret arkitektur til lagernetværk, der blev standardiseret i 1994. I dag implementeres den generelt med dedikerede HBA'er (hostbus-adaptere) og switche - hvilket er hovedårsagen til, at FC betragtes som dyrere end andre lagernetværksteknologier.
Med hensyn til ydeevne er det svært at slå FC's lave latenstid og høje kapacitet, fordi FC blev bygget fra bunden til at håndtere lagertrafik. De behandlingscyklusser, der kræves for at generere og fortolke FCP (Fibre Channel Protocol) -rammer, aflades helt til dedikerede HBA'er med lav latenstid. Dette frigør serverens CPU til at håndtere applikationer i stedet for at tale med lagring.
FC fås i hastigheder på 1 Gbps, 2 Gbps, 4 Gbps, 8 Gbps, 10 Gbps og 20 Gbps. Omskiftere og enheder, der understøtter hastigheder på 1 Gbps, 2 Gbps, 4 Gbps og 8 Gbps, er generelt bagudkompatible med deres langsommere brødre, mens 10 Gbps og 20 Gbps-enheder ikke er det, fordi de bruger en anden rammekodningsmekanisme (disse to bruges generelt til interswitch-links).
Derudover er FCP også optimeret til at håndtere lagertrafik. I modsætning til protokoller, der kører oven på TCP / IP, er FCP en væsentlig tyndere, enkeltformålsprotokol, der generelt resulterer i en lavere skiftetid. Det inkluderer også en indbygget flowkontrolmekanisme, der sikrer, at data ikke sendes til en enhed (enten lager eller server), der ikke er klar til at acceptere det. Efter min erfaring kan du ikke opnå den samme lave sammenkoblingslatens med nogen anden lagerprotokol, der findes i dag.
Alligevel har FC og FCP ulemper - og ikke kun høje omkostninger. Den ene er, at det kan være dyrt at understøtte sammenkobling af lager over lange afstande. Hvis du vil konfigurere replikering til et sekundært array på et fjernt websted, er du enten heldig nok til at have mørk fiber (hvis den er tilgængelig), eller du bliver nødt til at købe dyre FCIP distance gateways.
Derudover kræver styring af en FC-infrastruktur et specialiseret sæt, som kan gøre administratoren til et problem. F.eks. Benytter FC-zoneinddeling kraftigt lang hexadecimal World Wide Node og Port navne (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 en standard i 2004, er iSCSIs største krav til berømmelse, at det kører over det samme netværksudstyr, der kører resten af virksomhedsnetværket. Det kræver ikke specifikt ekstra hardware, hvilket gør det forholdsvis billigt at implementere.
Fra et præstationsperspektiv halter iSCSI bag FC / FCP. Men når iSCSI implementeres ordentligt, koger forskellen til nogle få millisekunder ekstra latenstid på grund af den faste omkostning, der kræves for at indkapsle SCSI-kommandoer inden for TCP / IP-netværksprotokollen til generelle formål. Dette kan gøre en enorm forskel for ekstremt høje transaktions 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 smallere.
iSCSI lægger også større belastning på serverens CPU. Selvom der findes hardware iSCSI HBA'er, bruger de fleste iSCSI-implementeringer en softwareinitiator - i det væsentlige indlæser serverens processor med opgaven at oprette, sende og fortolke lagringskommandoer. Dette er også blevet brugt som et effektivt argument mod iSCSI. I betragtning af det faktum, at servere i dag ofte leverer med betydeligt flere CPU-ressourcer, end de fleste applikationer kan håbe på at bruge, er de tilfælde, hvor dette gør enhver form for væsentlig forskel, få og langt imellem.
iSCSI kan holde sig selv med FC med hensyn til kapacitet gennem brug af flere 1Gbps Ethernet- eller 10Gbps Ethernet-links. Det har også fordel af at være TCP / IP, idet det kan bruges over store afstande gennem eksisterende WAN-links. Dette brugsscenarie er normalt begrænset til SAN-til-SAN-replikering, 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 nødvendige sæt til implementering af iSCSI overlapper det med almindelig netværksdrift. Dette gør iSCSI ekstremt attraktivt for mindre virksomheder med begrænset it-personale og forklarer i vid udstrækning dets 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 flowkontrol og jumbo-indramning og implementering af flervejs I / O er almindelige fejl, der kan resultere i svag ydelse. Der er mange historier på internetfora om mislykkede iSCSI-implementeringer, der kunne have været undgået på grund af disse faktorer.
Fibre Channel over IP
FCoIP (Fibre Channel over Internet Protocol) er en nicheprotokol, der blev ratificeret i 2004. Det er en standard til indkapsling af FCP-rammer i 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-replikering og sikkerhedskopiering over lange afstande.
På grund af ineffektiviteten ved fragmentering af store FC-rammer i flere TCP / IP-pakker (WAN-kredsløb understøtter typisk ikke pakker over 1.500 byte), er det ikke bygget til at have lav latenstid. I stedet er den bygget til at muliggøre sammenkobling af geografisk adskilte Fibre Channel-stoffer, når mørk fiber ikke er tilgængelig for at gøre det med indbygget 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.
Fibre Channel over Ethernet
FCoE (Fibre Channel over Ethernet) er gruppens nyeste lagringsnetværksprotokol. Ratificeret som en standard i juni sidste år, FCoE er Fibre Channel-samfundets svar på fordelene ved iSCSI. Ligesom iSCSI bruger FCoE standard multifunktionelle Ethernet-netværk til at forbinde servere med lagring. I modsætning til iSCSI kører den ikke over TCP / IP - det er dens egen Ethernet-protokol, der optager et sted 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 switches til almindelige formål, som iSCSI gør, oplever den signifikant lavere end-to-end-latenstid på grund af det faktum, at TCP / IP-headeren ikke behøver at oprettes og fortolkes. Det dårlige er, at det ikke kan dirigeres over et TCP / IP WAN. 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 10Gbps Ethernet FCoE CNA'er (Converged Network Adapters), som både kan fungere som netværksadaptere og FCoE HBA'er - hvilket aflaster arbejdet med at tale til lagring svarende til den måde, FC HBA'er 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, kan servere ofte leveres med FCoE-kompatible CNA'er indbygget, hvilket i det væsentlige fjerner dette som en omkostningsfaktor helt.
FCoEs primære fordele kan realiseres, når det implementeres som en udvidelse af et allerede eksisterende Fibre Channel-netværk. På trods af at have en anden fysisk transportmekanisme, som kræver et par ekstra trin til implementering, kan FCoE bruge de samme styringsværktøjer som FC, og meget af den erfaring, der er opnået med at betjene et FC-stof, kan anvendes til dets konfiguration og vedligeholdelse.
Samler det hele
Der er ingen tvivl om, at debatten mellem FC og iSCSI fortsætter med at rase. Begge arkitekturer er gode til visse opgaver. At sige, at FC er godt for virksomheden, mens iSCSI er godt for SMB, er imidlertid 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 10 Gbps Ethernet og øget server-CPU-ydeevne spiser ind i FC's præstationsargument.
Uanset hvilken teknologi du beslutter at implementere for din organisation, så prøv ikke at blive suget ind i den religiøse krig og lav dit hjemmearbejde, før du køber. Du kan blive overrasket over, hvad du finder.
Denne artikel, "Fibre Channel vs. iSCSI: krigen fortsætter", optrådte oprindeligt på .com. Læs mere af Matt Prigges informationsoverbelastningsblog, og følg den seneste udvikling inden for datalagring og informationsstyring på .com.
