Programmēšana

Fibre Channel pret iSCSI: karš turpinās

Sākumā bija Fibre Channel (FC), un tas bija labi. Ja vēlaties patiesu SAN - salīdzinājumā ar koplietotu, tieši pievienotu SCSI krātuvi - FC ir tas, ko jūs ieguvāt. Bet FC bija šausmīgi dārga, un tam bija nepieciešami īpaši slēdži un resursdatora kopņu adapteri, un to bija grūti atbalstīt ģeogrāfiski sadalītās vidēs. Tad apmēram pirms sešiem vai septiņiem gadiem iSCSI lielā mērā nonāca SMB tirgū un lēnām sāka kāpšanu uzņēmumā.

Starpbrīdī ir daudz nepietiekami informētu domstarpību par to, kurš ir labāks. Dažreiz iSCSI un FC diskusijas ir sasniegušas reliģiskā kara līmeni.

[Arī vietnē .com: lejupielādējiet Logan Harbaugh's Archive Deep Dive un iegūstiet normatīvo aktu ievērošanas pamatus. | Uzziniet, kā datu deduplikācija var palēnināt sprādzienbīstamu datu pieaugumu, izmantojot Kita Šulca Deep Dive ziņojumu. ]

Šī cīņa bija divu galveno faktoru rezultāts: Pirmkārt, krātuves tirgus tika sadalīts starp lielajiem vēsturiskajiem krātuvju pārdevējiem, kuri bija ieguldījuši lielus ieguldījumus FC mārketingā pret jaunākiem pārdevējiem ar lētiem, tikai iSCSI piedāvājumiem. Otrkārt, administratoriem parasti patīk tas, ko viņi zina, un neuzticas tam, ko viņi nezina. Ja vairākus gadus esat vadījis FC SAN, jūs, visticamāk, uzskatāt, ka iSCSI ir lēna, neuzticama arhitektūra un ātrāk nomirtu, nekā tajā darbinātu kritisku pakalpojumu. Ja esat vadījis iSCSI SAN, jūs, iespējams, domājat, ka FC SAN ir dārgi dārgi, un to iestatīšana un pārvaldīšana ir lācis. Ne viens, ne otrs nav taisnība.

Tagad, kad pēc FCoE (FC over Ethernet) standarta ratifikācijas esam palikuši apmēram gadu līdakā, viss nav daudz labāk. Daudzi pircēji joprojām nesaprot atšķirības starp iSCSI un Fibre Channel standartiem. Lai gan šī tēma varētu viegli aizpildīt grāmatu, šeit ir ātri aprakstīta.

FC pamati

FC ir īpaša krātuves tīkla arhitektūra, kas tika standartizēta 1994. gadā. Mūsdienās to parasti īsteno ar speciāliem HBA (resursdatora kopņu adapteriem) un slēdžiem - tas ir galvenais iemesls, kāpēc FC tiek uzskatīts par dārgāku nekā citas krātuves tīkla tehnoloģijas.

Runājot par veiktspēju, ir grūti pārspēt FC zemo latentumu un lielo caurlaidspēju, jo FC tika uzbūvēta no zemes, lai apstrādātu krātuves trafiku. Apstrādes cikli, kas nepieciešami, lai ģenerētu un interpretētu FCP (šķiedru kanāla protokola) rāmjus, tiek pilnībā izkrauti specializētiem zema latentuma HBA. Tādējādi servera centrālais procesors tiek atbrīvots, lai apstrādātu lietojumprogrammas, nevis runātu ar krātuvi.

FC ir pieejams 1Gbps, 2Gbps, 4Gbps, 8Gbps, 10Gbps un 20Gbps ātrumā. Slēdži un ierīces, kas atbalsta 1Gbps, 2Gbps, 4Gbps un 8Gbps ātrumu, parasti ir savietojami ar saviem lēnākajiem brāļiem, savukārt 10Gbps un 20Gbps ierīces nav, jo tie izmanto atšķirīgu rāmju kodēšanas mehānismu (šie divi parasti tiek izmantoti starpslēdzēja saitēm).

Turklāt FCP ir arī optimizēts, lai apstrādātu krātuves trafiku. Atšķirībā no protokoliem, kas darbojas virs TCP / IP, FCP ir ievērojami plānāks, viena mērķa protokols, kura rezultāts parasti ir mazāks komutācijas latentums. Tas ietver arī iebūvētu plūsmas kontroles mehānismu, kas nodrošina datu nesūtīšanu uz ierīci (glabātuvi vai serveri), kas nav gatava tos pieņemt. Pēc manas pieredzes, jūs nevarat sasniegt to pašu zemo starpsavienojuma latentumu ar citu šodien pastāvošo krātuves protokolu.

Tomēr FC un FCP ir trūkumi - un ne tikai augstas izmaksas. Viens no tiem ir tas, ka krātuves savstarpējās savienojamības atbalstīšana lielos attālumos var būt dārga. Ja vēlaties konfigurēt sekundārā masīva replicēšanu attālā vietā, jums ir paveicies atļauties tumšās šķiedras (ja tā ir pieejama), vai arī jums būs jāpērk dārgas FCIP attāluma vārtejas.

Turklāt, lai pārvaldītu FC infrastruktūru, ir nepieciešama specializēta prasmju kopa, kas administratoram var radīt problēmas. Piemēram, FC zonējums intensīvi izmanto garus heksadecimālos pasaules mezglu un portu nosaukumus (līdzīgi kā MAC adreses Ethernet tīklā), kuru pārvaldīšana var sagādāt sāpes, ja audumā tiek veiktas biežas izmaiņas.

Smieklīgi iSCSI

iSCSI ir krātuves tīkla protokols, kas izveidots virs TCP / IP tīkla protokola. 2004. gadā kā standarts ratificēts, iSCSI lielākā slavas prasība ir tā, ka tā darbojas ar to pašu tīkla aprīkojumu, kas darbojas pārējā uzņēmuma tīklā. Tam nav īpaši nepieciešama papildu aparatūra, kas padara tā ieviešanu salīdzinoši lētu.

No veiktspējas viedokļa iSCSI atpaliek no FC / FCP. Bet, kad iSCSI tiek pareizi ieviests, starpība samazinās līdz dažu milisekunžu papildu latentumam, jo ​​rodas papildu izmaksas, kas vajadzīgas, lai iekapsulētu SCSI komandas vispārēja TCP / IP tīkla protokolā. Tas var radīt milzīgas atšķirības ārkārtīgi lielām darījumu I / O slodzēm, un tas ir vairums apgalvojumu, ka iSCSI nav piemērots lietošanai uzņēmumā. Šādas slodzes ārpus Fortune 500 ir reti sastopamas, tāpēc lielākajā daļā gadījumu veiktspējas delta ir daudz šaurāka.

iSCSI rada lielāku slodzi arī servera centrālajam procesoram. Lai arī aparatūras iSCSI HBA pastāv, vairumā iSCSI ieviešanu tiek izmantots programmatūras iniciators - būtībā servera procesoru ielādē ar uzdevumu izveidot, nosūtīt un interpretēt krātuves komandas. Tas arī tika izmantots kā efektīvs arguments pret iSCSI. Tomēr, ņemot vērā faktu, ka mūsdienās bieži serveri tiek piegādāti ar ievērojami lielāku CPU resursu daudzumu, nekā cer cerēt izmantot lielākā daļa lietojumprogrammu, gadījumu, kad tas rada jebkādas būtiskas atšķirības, ir maz un tālu.

iSCSI var noturēt sevi ar FC caurlaides ziņā, izmantojot vairākas 1Gbps Ethernet vai 10Gbps Ethernet saites. TCP / IP ir arī izdevīgi, jo to var izmantot lielos attālumos, izmantojot esošās WAN saites. Šis lietošanas scenārijs parasti aprobežojas ar SAN-SAN replikāciju, taču to ir ievērojami vieglāk un lētāk īstenot nekā tikai FC alternatīvas.

Papildus ietaupījumiem, izmantojot samazinātas infrastruktūras izmaksas, daudziem uzņēmumiem iSCSI ir daudz vieglāk izvietot. Liela daļa iSCSI ieviešanai nepieciešamo prasmju kopuma pārklājas ar vispārējās tīkla darbības prasmēm. Tas padara iSCSI ārkārtīgi pievilcīgu mazākiem uzņēmumiem ar ierobežotu IT personālu un lielā mērā izskaidro tā popularitāti šajā segmentā.

Šī izvietošanas vieglums ir divvirzienu zobens. Tā kā iSCSI ir viegli ieviest, to ir arī viegli nepareizi ieviest. Nespēja ieviest, izmantojot īpašas tīkla saskarnes, nodrošināt atbalstu komutācijas funkcijām, piemēram, plūsmas kontrolei un jumbo kadrēšanai, un daudzceļu I / O ieviešana ir bieži sastopamas kļūdas, kuru rezultāts var būt vājš. Interneta forumos ir daudz stāstu par neveiksmīgu iSCSI izvietošanu, no kā varēja izvairīties šo faktoru dēļ.

Šķiedru kanāls, izmantojot IP

FCoIP (Fibre Channel over Internet Protocol) ir nišas protokols, kas tika ratificēts 2004. gadā. Tas ir standarts FCP rāmju iekapsulēšanai TCP / IP paketēs, lai tos varētu nosūtīt pa TCP / IP tīklu. To gandrīz tikai izmanto FC audumu savienošanai vairākās vietās, lai iespējotu SAN-SAN replikāciju un dublēšanu lielos attālumos.

Sakarā ar neefektivitāti sadalīt lielus FC rāmjus vairākos TCP / IP paketēs (WAN shēmas parasti neatbalsta paketes, kas pārsniedz 1500 baitus), tas nav veidots ar zemu latentumu. Tā vietā tā ir veidota tā, lai ļautu ģeogrāfiski atdalītus šķiedru kanālu audumus sasaistīt, ja tumšā šķiedra nav pieejama, lai to izdarītu ar vietējo FCP. FCIP gandrīz vienmēr ir atrodams FC attāluma vārtejās - galvenokārt FC / FCP – FCIP tiltos - un glabāšanas ierīces to reti izmanto, ja kādreiz to izmanto kā servera līdz krātuves piekļuves metodi.

Šķiedru kanāls pa Ethernet

FCoE (Fibre Channel over Ethernet) ir jaunākais kopas krātuves tīkla protokols. Pagājušā gada jūnijā kā standarts tika ratificēts FCoE ir Fiber Channel kopienas atbilde uz iSCSI priekšrocībām. Tāpat kā iSCSI, arī FCoE izmanto standarta daudzfunkcionālus Ethernet tīklus, lai savienotu serverus ar krātuvi. Atšķirībā no iSCSI, tas nedarbojas pa TCP / IP - tas ir paša Ethernet protokols, kas OSI modelī aizņem vietu blakus IP.

Šo atšķirību ir svarīgi saprast, jo tam ir gan labi, gan slikti rezultāti. Labais ir tas, ka, pat ja FCoE darbojas ar tiem pašiem vispārējas nozīmes slēdžiem, ko dara iSCSI, tā saskaras ar ievērojami zemāku gala līdz galam latentumu, jo TCP / IP galvene nav jāizveido un jāinterpretē. Slikti ir tas, ka to nevar novirzīt pa TCP / IP WAN. Tāpat kā FC, FCoE var darboties tikai lokālajā tīklā, un tam ir nepieciešams tilts, lai izveidotu savienojumu ar attālo audumu.

Servera pusē lielākā daļa FCoE ieviešanu izmanto 10Gbps Ethernet FCoE CNA (Converged Network Adapters), kas var darboties gan kā tīkla adapteri, gan kā FCoE HBA - sarunu sarunu darbs tiek pārkrauts līdzīgi tam, kā to dara FC HBA. Tas ir svarīgs punkts, jo prasība pēc atsevišķas FC HBA bieži bija labs iemesls, lai pilnībā izvairītos no FC. Laikam ejot, serveri parasti var piegādāt iebūvētus CNA, kas spēj FCAE, būtībā to pilnībā atceļot kā izmaksu faktoru.

FCoE galvenās priekšrocības var realizēt, kad tā tiek ieviesta kā jau pastāvoša Fibre Channel tīkla paplašinājums. Neskatoties uz atšķirīgo fiziskā transporta mehānismu, kura ieviešanai ir nepieciešamas dažas papildu darbības, FCoE var izmantot tos pašus vadības rīkus kā FC, un lielu daļu no FC auduma darbībā iegūtās pieredzes var izmantot tā konfigurācijā un uzturēšanā.

Saliekot to visu kopā

Nav šaubu, ka debates starp FC un iSCSI turpinās plosīties. Abas arhitektūras ir lieliski piemērotas noteiktiem uzdevumiem. Tomēr apgalvojums, ka FC ir labs uzņēmumiem, bet iSCSI ir piemērots maziem un vidējiem uzņēmumiem, vairs nav pieņemama atbilde. FCoE pieejamība ir tāls ceļš uz iSCSI izmaksu un konverģences argumentu, savukārt pieaugošā 10Gbps Ethernet izplatība un servera CPU veiktspējas palielināšanās iekļauj FC veiktspējas argumentu.

Neatkarīgi no tā, kādu tehnoloģiju jūs nolemjat ieviest savai organizācijai, mēģiniet neieslīgt reliģiskajā karā un pirms pirkuma veiciet mājasdarbus. Jūs varat būt pārsteigts par to, ko atrodat.

Šis raksts "Fibre Channel vs iSCSI: karš turpinās" sākotnēji tika parādīts vietnē .com. Lasiet vairāk Matt Prigge emuāra Informācijas pārslodze un sekojiet jaunākajiem notikumiem datu glabāšanā un informācijas pārvaldībā vietnē .com.

$config[zx-auto] not found$config[zx-overlay] not found