FCoE – Fibre Channel over Ethernet (diskuse)

[xkucf03]

Díky za článek

Ocenil bych jednu informaci – ptal jsem se na to i borce na jedné konferenci (po přednášce o tom jak je FCoE super a máme si ho koupit) – jaká je režie IP protokolu? Zajímá mne srovnání iSCSI a FCoE za jinak stejných okolností. Rád bych slyšel konkrétní čísla, protože od něj jsem se dozvěděl, že režie IP protokolu je strašně velká. A vůbec, je to nesrovnatelné, protože na FCoE je potřeba mít 10Gbps ethernet a na tom on iSCSI nikde neprovozoval. Takže, pokud budu mít FCoE a iSCSI na stejně rychlé síti (ať už 1 nebo 10 nebo třeba 100 Gbps), o kolik bude FCoE rychlejší?

[Stanislav Petr]

Obecne u iSCSI zacina byt znatelna zatez na iniciatoru uz kolem 600Mbps pri pouziti bezne sitove karty, takze 10Gbps adapter tak trochu nepripada v uvahu. iSCSI se da celkem rozumne pouzivat na rychlosti 1Gbps pri pouziti specialni karty (http://qlogic.com/Products/SANandDataNetworking/iSCSIAdapters/Pages/iSCSIAdaptersHome.aspx). Ale takovehle iSCSI adaptery se prave vyrabeji do rychlosti max. 1Gbps, takze zadne konkretni sorvnani cisel existovat nemuze...

[kyytaM]

Iba uvaha - pri pouziti kvalitnej NIC s TCP/UDP offloadom (mala by sa odburat velka cast rezie spojena so sietovym prenosom) by mala byt zataz obmedzena prevazne na reziu samotnej iSCSI vrstvy (teoreticky). Je to aj v realite tak?

[Stanislav Petr]

tcpoffload je u iSCSI pokud chcete dosahovat rozumnych rychlosti skoro podminkou... Ale stejne bezna karta s tcpoffload ani zdaleka nevyrovna specialni iSCSI karte (prakticky testovano na - prakticky testovano na Intel PRO 1000/F a 1000/MF.

[zigi]

Mohu se zeptat, v cem tak zasadnim se lisi vyuziti lepsi sitove karty, Linuxu a nejake implementace iSCSI targetu od pouziti toho specializovaneho HBA? Jestli jsem to aspon trochu pochopil, tak veskere nastaveni sdilenych prostredku se resi pres tuto kartu (tedy obsahuje implementaci iSCSI - firmware, ovladac a nejaky program pro nastaveni z user space)?

[JZ]

Obecně použití speciálního HW uleví zátěži systému, protože ten pak nemusí funkci tohoto adaptéru emulovat (např. u FCoE tedy nemusí řešit zapouzdření FC do Ethernetových rámců systém, ale řeší ho HW).

[zigi]

To je mi jasny, ale protoze s FC/iSCSI nemam zatim zadnou primou zkusenost, tak me zajima, jak se pri pouziti takovychto zarizeni konfiguruje sdileni disku, popr. diskoveho oddilu (jak pres FC tak i za pomoci HBA).
Pro linux je nekolik implementaci iSCSI (TCP/IP - Ethernet), pomoci kterych se da nasdilet disk/oddil a specifikovat, kdo se k nemu muze pripojit.

Otazka: Da se v linuxu pouzit FC pro propojeni nekolika pocitacu (jako klasicka ethernet sit) a co se pro FC na linuxu pouziva? Diky

[Käyttäjä 11133]

Pokud myslíš, jako udělat si diskové pole na Linuxu, tak ano, ale potřebuješ k tomu FC HBA, které podporuje v linuxovém kernelu target mode.

[frr]

Svého času jsem provedl experiment - náhodou se mi na stole sešlo železo, které ho umožňovalo: dvě síťovky Myri-10G, externí RAIDový box s řadičem Areca na úrovni ARC-1680 (ale propoj PCI-e pouze x4), nějaký server s čipsetem Intel 5000P (CPU Xeon tuším 5300 series), jako koncové zařízení (iSCSI initiator) nějaký "průmyslový desktopový" board tuším s i945, který podporuje v x16 slotu i jiné věci než grafiku (zde iSCSI kartu).

Desktop           |     Server     |         | RAID |
10Gb Eth <======> 10Gb Eth | PCIe x4 <=====> PCIe x4

Použil jsem "alternativní" softwarový SCSI target pro Linux SCST, který mj. obsahuje také iSCSI front-end. Jako back-end umí použít libovolné blokové zařízení buď s použitím systémového bufferingu (VM), nebo bez bufferingu v "direct módu" (bDIRECT), nebo snad i s přímým relayem SCSI příkazů. SCST žije celý v kernelu a je optimalizován na průchodnost.

Mám pocit, že Intel I/OAT v čipsetu 5000 jsem nepoužil - jednak mi to v Linuxu nechtělo chodit, jednak to možná nechodí se síťovkou jinou než Intel, jednak to vlastně v Linuxu má odlehčovat jenom "copy to user", což je dost k ničemu, když SCST žije celý v kernelu (viz níže).

Samotný RAID mi dával přímo proti serveru sekvenční LBA čtení cca 600 MBps. Když jsem ho přes iSCSI namapoval "klientovi" (initiatoru) na tom desktopovém stroji, tak desktopový stroj z toho vytáhl sekvenční LBA čtení 500 MBps (v jedné relaci). Provedl jsem jenom nějaké lehké ladění dostupnými prostředky:

• jako nejrychlejší pro tento typ zátěže se ukázal SCST režim "bDIRECT" (bufferovaný režim dával asi 300 MBps - což při random zátěži nemusí být k zahození)
• pochopitelně jsem použil Jumbo framy o běžné maximální velikosti 9 kB
• tušímže jsem trochu poladil "maximum window" parametry TCP stacku na obou koncích na maximální hodnotu

Ono je nakonec možné, že pro většinu aplikací ty sekvenční MBps jsou honěním trička. Důležitým číslem jsou IOps. Pokud uvážíte nevelkou standardní hloubku TCQ front na několika zúčastněných vrstvách, tak se do toho poměrně přímo promítá doba zpracování jednotlivého požadavku, potažmo i přenosové latence. Latence na běžném Ethernetu (neřku-li TCP/IP) jsou nepochybně delší, než latence na klasických storage sběrnicích.
V tomto směru bohužel žádné benchmarky nemám.

Strašlivá režie vrstev TCP/IP má několik faset. Pokud se týče ztráty kapacity na vrub enkapsulace, jsou to tuším nějaké jednotky procent při MTU=1500 (= ztráta zanedbatelá). Jiná věc je "processing overhead", tj. spotřeba procesorového výkonu na počítání algoritmů a spotřeba průchodnosti sběrnic na "zbytečné" kopie dat. Nějaká čísla jsou tady, ovšem podle mých experimentů zjevně neaktuální pro dnešní hardware - mají snad nějakou relativní hodnotu. A ještě jiná věc je režie způsobená reakcemi "TCP/IP flow control" (regulační smyčky) - tj. rozjezd spojení, přibržďování oknem, a nedejbože retransmit při ztrátě paketu, ó hrůzo.

Protože mě storage hardware v podstatě neživí, dovolím si pár odhadů selským rozumem a laických pivních prohlášení "Hrozný overhead iSCSI" znamená víceméně tolik, že netriviální logika vrstev TCP/IP se nesnadno implementuje v čistém hardwaru, a navíc zejména za nepříznivých okolností (vytížení sítě směsí různého provozu) může projevovat náhodné vyšší latence. Proto si vymyslíme jednodušší enkapsulaci celých FC rámců, která pojede přímo nad Ethernetem, nebude mít vlastní garanci doručení, proto bude implementačně jednoduchá. Garanci doručení pak doženeme jednoduchými recepty, známými z minulosti (absolutní priorita pro náš provoz, a (802.3x)802.1bb flow-control v Ethernetu) - že jednoduché recepty mohou mít své mouchy, zejména v prostředí se složitým mixem "best effort" provozu, to ať si vyřeší někdo jiný. Když dáme povinně 10Gb Ethernet, tak s trochou štěstí bude úzké hrdlo někde jinde (reálné targety nebo initiatory). Ostatně "přibržďování toku" si v moderním SCSI provozu řeší TCQ s podobným efektem, jako má TCP receive window (až na to, že ztráta FCoE paketu znamená SCSI command timeout, což je docela závažná chyba).

Abych nebyl zase tolik zbytečně ošklivý, ono má asi smysl, v nějaké složitější síti, tj. v systému, kde spolu soupeří spousta datových toků na vrstvách síťové komunikace a storage komunikace, aby storage komunikace měla obecně přednost - aby se provoz škrtil a hltil přednostně na internetové vrstvě (kde je to jaksi snáze omluvitelné), ale aby počítače měly pokud možno vždycky dostupné disky. Je možné, že to v globále vede k lepší stabilitě systémů. Podmínkou je, aby nějaká aplikace nežrala IO bandwidth "nadoraz, co to dá" - to je právě problém s absolutní priorizací. Stejně jsem ale zvědav, jak jsou na FCoE ošetřeny problémy typu "head of line blocking". A mimochodem, té priorizace by se možná dalo dosáhnout třeba i levněji s klasickými switchi, pomocí 802.1p, ne?

Jestli někdo potřebuje storage síťku na capture HD videa, tzn. vyžaduje striktně deterministické odezvy (dokonce nejen od blokové vrstvy, ale od filesystému, chacha) tak by možná měl sáhnout spíš po FC než po FCoE.

iSCSI HBA třeba od Adaptecu mívaly tuším svého času prostě jenom síťovku Intel, která byla vybavena trochu jinou option ROMkou a ovladači pro Windows, aby se to v BIOSu tvářilo jako SCSI řadič. Čili nějaký kompletní offload iSCSI do hardwaru se v podstatě nekonal.

Když se FCoE před časem začalo objevovat, mluvilo se o tom, že ethernetové switche pro tento provoz jsou stavěny speciálně na super-nízké latence. Čili není to normální kancelářský Ethernet. Máte někdo představu, kolik tyhle hračky stojí? Je to cenově blízko ke konvenčnímu Ethernetu, nebo spíš k FibreChannelu?

[gtz]

Ano má to něco do sebe, ale i tak, já bych raději volil klasickou FC. Latence jsou tam nízké až skoro žádné. Novější modely FC již podporují 8Gbit, oproti 4Gbit je to opravdu fofr.

Prováděl pár testů na FC diskovém poli ( SATA-II ) a normálním obyčejným Intel Serverem na kterém běžel CentOS (+FC KARTA). Pokusím se benchmarky najít, sice to byl jen +4Gbit, ale i tak se to s technologií iSCSI nedalo ani srovnat (iSCSI bylo v řádech pomalejší).

[herne the hunter]

panečku, to muselo dát pěknou práci tenhle komentář jen napsat… RESTEKP! škoda, že tomuhle tématu rozumím asi stejně jako lister středostavovským způsobům 19. století ;) nicméně mne zaujala věta

Strašlivá režie vrstev TCP/IP má několik faset.

doteď jsem byl dojmu, že fazeta je skosená hrana. nebo se normálně používá i v tomhle kontextu?

[frr]

>> Strašlivá režie vrstev TCP/IP má několik faset.
>>
> doteď jsem byl dojmu, že fazeta je skosená hrana.
> nebo se normálně používá i v tomhle kontextu?
>
obrazně řečeno. Několik aspektů. Fakt je, že jsem to slovo takhle použité potkal asi spíš v anglině než v češtině. Omlouvám se tedy za neblahý novotvar

F.Ryšánek

[motyq]

spravne se pise RESKEPT :D

[tomfi]

>>> Čili není to normální kancelářský Ethernet. Máte někdo představu, kolik tyhle hračky stojí?

Vlajkovou lodí je u cisca řada NEXUS 7000... vše redundantní, zatím podpora 256 nebo 512 10GbE portů... časem by měl umět snad i 40 a 100GbE porty. klidně ho zkuste poptat, ale můj tajný typ je že v korunách se pod 7 cifernou hodnotu nedostanete.

Na druhou stranu pokud má switch 10GbE a adekvátní propustnost switching fabric, tak by si to mělo poradit i když to bude mít na cedulce edimax :D (nízké latence jsou dobrou prerekvizitou vůbec k zacházení s 10GbE... ono když to má zvládnout minimálně 200kpps na port (10GbE), tak máš na jeden rámec velmi málo času... ty latence z principu být velké nemůžou.) Snad jediné na co si dát pozor je QoS a nějakou tu ochranu před dos, aby ten FCoE měl dobré podmínky pro doručení i v těchto rychlostech.

[Käyttäjä 11133]

4x Cisco nexus 2k, 4x Cisco nexus 5k, 4x Cisco nexus 7k - €500 000, kolik stál jednotlivej kousek nemám tušení.

[frr]

Koukám, že hranice sci-fi se zase o dost posunula. Zůstává mi rozum stát, jak dokážou znovu a znovu ochcat základní fyziku...

[polish]

On to v podstate bude klasicky switch, akorat se bude chovat jako nevychovany : v podstate nebude cekat az ramec prijde cely, aby ho zkontroloval a po overeni, ze je v poradku ho poslal dal, ale hned z hlavicky se ho bude snazit rvat na cilovy port (prave kvuli snizeni latence)

[frr]

Cili cut-through, nikoli "store and forward". Proc ne... spis mi nejde na rozum, jak jsou schopni tohle delat mezi nejakymi 256 porty 10Gb Eth najednou navzajem, a jeste pri tom pocitat nejake priority a vkladat "pause" ramce

[petr_p]

Já bych řekl, že těch 10 Gb/s · 256 portů náhodného provozu je nesmysl. Třeba trvalý proud z jednoho na druhý port zvládne maximální rychlostí, paralelní izolované přenosy taky. Ale jakmile dojde na křížení provozu a soupeření o vnitřní sběrnici (pochybuji, že tam mají n(n-1) cest, spíš něco na způsob hyperkrychle nebo možná jen okruhu), tak zpoždění začne narůstat.

[zigi]

Pokud mate zkusenosti s iSCSI, mohl byste mi doporucit nejakou implementaci, viz. http://www.abclinuxu.cz/poradna/linux/show/294773

[Ivan]

Pokud mne pamet neklame, tak existuji i standarty "SCSI over ethernet" and dokonce jsem nekde videl i "ATA over ethernet".

[Yenya]

Jo, me by zajimalo jak si FCoE stoji proti ATA-over-Ethernet. To mi prislo jako jednoduchy protokol, nevyzadujici zadnou prioritizaci ani jumbo framy.

-Yenya

[Käyttäjä 11133]

FCoE to ke své funkci (tu prioritizaci) taky nepotřebuje, ale pokud to chceš mít spolehlivé FCoE (či libovolnou jinou storage technologii po ethernetu) musíš nějak ochcat Best effort delivery featury.

[xkucf03]

U ATAoE jsem viděl i srovnání, kde vycházel pomalejší než iSCSI (přestože ho „nezdržuje“ TCP/IP). Ale možná to bylo jen mizernou implementací…

[pavuk]

svieze zamyslenie nad FCoE a Infiniband http://etherealmind.com/fcoe-doesnt-replace-infiniband-copy-cheaper/