Názory k článku ATA over Ethernet: sdílení disků po síti
-
Rozdíl je v tom že:
iSCSI - je zavedený odladěný protokol, podporují ho snad všichni výrobci diskových polí, initiator podporují snad všechny běžné operační systémy, iSCSI provoz jde přes TCP, takže je možné ho routovat.
AoE - je protokol tlačený pouze (převážně?) firmou Coraid, jak bylo řečeno nativní podpora je jen v Linuxu a v OpenBSD, AoE provoz je neroutovatelný.
AoE i iSCSI - zpřístupňují vzdálené blokové zařízení jako lokální disk, existují "urychlovací" PCI karty (HBA), je možné si zadarmo vyzkoušet softwarovou verzi obou protokolů (populární iSCSI target pro linux je IET daemon), atd.
Vlastně nevidím žádnou výhodu AoE proti iSCSI... -
Případně ještě GEOM Gate Network Devices… zmínku si zaslouží, ale z těchto technologií bych* volil iSCSI, které je nejstandardnější a nejvíc nezávislé na konkrétním OS. *) pokud by nebyly nějaké přesvědčivé výkonnostní argumenty pro něco jiného. -
Docela pekny clanek, Adame. Ale kdyz uz jsi se zacal zabyvat AoE, to iSCSI jsi mel urcite ozkouset taky... Neni to o moc slozitejsi a porovnani by se rozhodne hodilo. Ja jako mnoho dalsich jsem se presvedcil, ze iSCSI je i pres IP rychlejsi nez AoE pres ethernet. Pomerne zajimavou vyhodou je i fakt ze iSCSI initiator je soucasti Windows od Visty a do XP (2000?) je zdarma k disposici od M$. -
BTW: nevíš, jak na tenhle problém s pamatováním přihlašovacích údajů: iSCSI? Na Živě mi s tím zatím nikdo neporadil (a to bylo snad vůbec poprvé, co jsem se tam na něco ptal).
-
Je, tak to nevim, to jsem jeste neresil. Ja jsem iSCSI pouzil na par compech v praci kde doslo misto na lokalnich discich (aneb 30 GB mailu jen to hvizdne), ale tam jsem se na lokalni siti s autentikaci netrapil... Bez hesla se disky pripojujou spolehlive. Ale schvalne to jen tak pro zajimavost ozkousim, jestli to treba ve Viste nebo Windows 7 build 7057 neopravili :)
-
zz (neregistrovaný)no podla par zdrojou je iSCSI spolu z 10G ethernetom najrychlejsie aktualne pouzitelne storage riesenie ;-)
na druhu stranu kedze sa jedna v pripade Ata over Ethernet aj pri iSCSI o balenie do IP sa prejavia este viac klady a zapory jednotlyvych protokolou. a v prospech iSCSI hovori aj fakt ze sa jedna o overene a zname riesenie.
p.s. daju sa takto zdielat aj ATA zariadenia -
Izak (neregistrovaný)Jo ?
a jak toho vykonu dosahnete ?
Samozrejme mnohem rychlejis je 4Gb Fibrechanel, prtooze je to proaktivni switchovani, coz se projevi, kdyz tam tech uzlu bude vice, nebo budou spoje na delsi vzdalenosti, kdy FC umi dedikovat buffery na porty a posilat vice dat po optice najednou a necekat az paket dorazi do dalsiho switche.
Jenom ze FC ma ted bezne max 4Gb/sec a SCSI ma teoreticke maximum 360MB/sec ... a i stim ma treba adaptec problem, takze se pak zpomali na Ultra160 ....
Pritom pole jako IBM DS600 s DS8000 umi jeden raid pustit pres vice FC portu ;-))
To same NetApp, ktery umi jak FC tak NFS i iSCSI a FC je asi nejrychlejsi. -
Izak (neregistrovaný)No tak FC 4G ma samozrejme max 400MB/sec full duplex ... coz je to, co se v praxi pouziva ;-)) (20GFC) jsem v praxi vzivote nevidel, cimz nechci rict, ze neexistuje, ja jenom ze zde jsou karty: http://www.qlogic.com/Products/SAN_products_fibreHBA.aspx
a koukam ze uz je 8Gb v prodeji ;-))
... jo a jak se to k tomu iSCSI dostane ? ... to jako budete delat swraid ? ... ja jenom ze to pole, co je uvnitr iscsi je v enterprise resenich zapojeno na FC loop/switch, nove tez SAS ... nebo starsi SCSI ... nejak se ty data z toho RAIDu musi na iscsi target dostat.
Ultra 640 jsem taktez v zivote nevidel: http://www.lsi.com/storage_home/products_home/host_bus_adapters/scsi_hbas/index.html
Existuje jenom teoreticka norma, ale karta se mi v zivote nedostala do ruky a vzhledem k tomu, ze uz je SCSI mrtve, tak asi ani nikdy nedostane, SCSI uz bylo davno nahrazeno FC a v lowendu a knihovnach ho ted dorazi SAS.
.... prpravde SCSI VHDCI konektory byl nejvetsi opruz, jaky jsem kdy videl. -
ToM (neregistrovaný)Tak on hlavně 10GFC a 20GFC je určený spíš pro stacking switchů, takže hledat HBA bude marné. Navíc třeba Brocade už kdysi prohlásil, že kvůli nedodržení zpětné kompatibility do 10GFC nepůjde. Další věc je, že disky zatím končí na 4G, takže pro zvýšení rychlosti se musí dělat raid přes backend loopy. (BTW v polích se většinou dělá RAID centrálně. Takže RAID přes backend loopy je standardní vlastnost).
-
Sten (neregistrovaný)
10GFC HBA jsou pro FCoE (např. od jmenovaného QLogicu), přímo pro FC jsem je taky neviděl.
iSCSI nemusí operovat jenom nad SCSI, může operovat třeba nad PCI-E flash disky, jeden takový (ioDrive od Fusion-io) zvládá až 600 MB/s zápisu nebo až 700 MB/s čtení (škoda, že ho ve firmě nakonec nekoupili :). Klidně může operovat i nad SW RAIDem. Díky tomu, že v Linuxu se SCSI příkazy dnes používají pro přístup v podstatě ke všem diskům (včetně ATA, USB a softwarových MD a LVM), tak ta technologie není nutně přímo spojená s hardwarem (uznávám, že FC se dá taky emulovat, ale to má na rozdíl od iSCSI ty rychlostí limity - i když jen teoretické, pokud pomineme bonding, tak stejně zatím nejsou rychlejší sítě).
Ultra-640 se prý sice dělá (ale taky jsem řadič ještě neviděl), ale souhlasím, SAS (případně SATAⅡ, se kterou je SAS zpětně kompatibilní) ho dost drtí kvůli nižší ceně a rychlosti stejné jako Ultra-320 pro každý disk (tj. hodně nad schopnosti současných disků).
-
Sten (neregistrovaný)To jako že je rychlejší než 10G Fibre Channel? To se mi moc nechce věřit (ale možné to je).
No zajímavé bylo, že to bylo na lokální přímé lince a přesto AoE (které šlo přímo po ethernetu) bylo pomalejší než iSCSI (které se balilo do IP). Chvíli jsem zvažoval nasadit HyperSCSI nebo FCoE, ale tehdy (polovina roku 2007) jsem nenašel žádnou použitelnou implementaci pro Linux (Open-FCoE tehdy ještě neexistovalo a HyperSCSI.sf.net už tehdy nebylo pár let udržované).
Já takhle sdílel SATAⅡ disky, takže jsem si mohl vybrat, jestli použiji ATA nebo SCSI rozhraní jádra (aby to nemusel emulovat server) a SCSI to jasně vyhrálo :) -
ToM (neregistrovaný)10Gb FC bude spíš přeskočen, kvůli nekompatibilitě.
Tak či tak rychlost není výkon, který je dán ještě latencí. A ta je pro řadu aplikací o něco důležitější.
Pokud AoE bylo pomalejší než iSCSI, tak je opravdu dost podivné a tipuju na nějakou chybu řešení, nikoli normální stav.
Stejně to časem v podnikové oblasti vyhraje asi FCoE a nové typy HBA, které budou sdružovat všechny eth služby. -
Sten (neregistrovaný)No zatím se docela prosazuje (hlavně protože zatím nejsou linky na 16 GFC).
Nevím. To diskové pole připojené přes AoE a potom iSCSI je o dost rychlejší než ta gigabitová síť a iSCSI tu síť prostě líp zvládalo využít. Jestli to bylo latencí, menším overheadem nebo jen problematickou implementací jsem ale nezkoumal. Ale nejsem jediný, kdo došel k výsledku, že iSCSI je rychlejší než AoE. Možná za to může nějaký zásadní rozdíl mezi SCSI a ATA příkazy.
No uvidíme. S masivním nástupem 10 GBps to bude buď FCoE nebo iSCSI (AoE, iFCP ani FC + IPFC moc šancí nedávám). -
ondrej (neregistrovaný)Co vlastne znamena tento odstavec?
> Protokol obsahuje i cestu, jak mezi sebou mohou stroje komunikovat
> Tím se zabrání nebezpečnému přístupu více strojů k jednomu disku.
> ...
Mam 3 pc ktore budu vzdy jeden disk/oblast zdielat a urobim nad tym RAID5. Ak chcem pristupovat zo vsetkych PC na tento disk musim pouzit GFS, OCFS2 alebo mi teda staci ako filesystem mat ext3?
Pri iSCSI nebolo mozne mat iny filesystem ako GFS, OCFS2... -
Radek Hladik (neregistrovaný)Vcelku pochopitelne nemuze protokol implementujici blokove zarizeni vyresit problem vyssi vrstvy souboroveho systemu ohledne reseni konkuretnich pristupu. A je jedno, jestli je to AoE, FC nebo iSCSI. Dokonce neni mozne ani reseni jeden R/W pristup a jeden ci vice R/O pristupu.
Vsechny zminene clusterove filesystemy nejakym zpusobem musi resit synchronizaci pristupu ke sdielenemu blokovemu zarizeni. A opravdu nejde o jednoduchy problem, jak by se na prvni pohled mohlo zdat. Tzn. takovy filesystem sice pouziva sdileny block device, ale zaroven pouziva jiny kanal (napr. normalni tcp) na domlouvani se, kdo kdy ktery block pouziva nebo chce pouzivat. A take na reseni problematickych stavu, kdy se muzou stat lahudkoidni situace typu, kdy vsichni pripojeni maji k dispozici sdileny blockdevice, ale vsechny uzly se kvuli nakemu problemu nevidi navzajem, takze neni mozne se spravne synchronizovat a presto nesmi dojit k poskozeni dat... -
zz (neregistrovaný)no napryklad vmfs (vmware ESX servery) si predava informacie o zamknuti suboru na citanie zaznamenava do FS takze sa servery nemusia vydiet, ak som si vsimol spravne zariadenia zamok musia cyklicky obnovovat takze po vypadku servera sa subor po chvyle uvolni. (bezpecne to podla mojich skusenosti je len niekedy je problem najst kdo si to vlastne zamkol)
-
Sten (neregistrovaný)Šlo by použít i ext3 a nad tím NFS (a iSCSI/AoE/FC použít pro sjednocení diskových polí v různých strojích na jeden souborový systém). Ale AoE ani iSCSI ani FC neřeší nic na úrovni vyšší než je diskový oddíl, takže je nelze použít ke sdílení souborových systémů. Master-slave sdílení u nežurnálových (takže ne u ext3) nebo read-only by teoreticky šlo, ale to jsem nezkoušel.
-
zz (neregistrovaný)nie NFS je nieco ine. NFS ti prezentuje filesystem. iSCSI, AoE (nestastna skratka) a FC ti spristupnuju len zariadenie ako take.
co sa tyka jeden RW a ostatny RO to tiez nieje moc dobry napad. OS vyuziva rozne cache takze zmena nemusi byt na disku alebo ak aj je dalsy system ju nemusi akceptovat a pouzije stare data z cache. -
stepan (neregistrovaný)Výhodou AoE je že se dá snadno implementovat i do levných jednoúčelových hdd boxů s ethernetem. Tyhle boxy většinou mají ještě malý samba/ftp/ndas a pod. server, ale konfigurace, funkčnost i možnost upgrade bývá omezená. Ve srovnání s tím je řešení přes AoE mnohem flexibilnější. A AoE má minimální nároky na výkon procesoru v boxu.
-
bery (neregistrovaný)Pochybuju ze to bude levnejsi nez USB. Srovnani s USB je podle me namiste, protoze pokud k tomu stejne zaroven nemuze pristupovat vic uzivatelu nema to zadnou vyhodu (snad jen to, ze si to pripojim spolu se siti pomoci ethernetoveho kabelu nebo pres wifi)
Jinak iSCSI se mi osvedcilo pri testovani (chtel jsem si vyzkouset distribuovane FS a vse jsem si tedy udelal ve virtualni masine) -
Podle mého velice sexy potenciální aplikace AoE (a iSCSI) je boot disklessových klientů. A to boot neunixových disklessů (protože UNIXové disklessy je IMO lepší bootovat přes NFS). Viz např.
http://etherboot.org/wiki/sanboot
http://etherboot.org/wiki/appnotes/cow
Problém je, že pokud budete chtít šetřit místem na serveru a bootovat několik disklessů z jednoho společného diskového image uloženého na serveru, tak pokud tím bootovaným OS jsou Windows na bázi NT (W2k, XP, Vista, 7, W2k3, W2k8) tak si nabijete kokos o SID (nemluvě o porušní licence a dalším možném technickém problému s aktivací). Takže je to zajímavá hračka, ale prakticky dost k ničemu. Windows 95-Millenium jsou z mnoha důvodů pasé, stejně tak jako DOS (který se navíc možná snáz bootuje diskless z ramdisku, např. přes PXElinux + memdisk).
Fakt je, že ty XPčkové disklessy by mohly mít třeba jenom 10GB virtuální harddisk uložený na nějakém nadupaném serveru po gigabitové síti, takže by to mohlo bootovat jednotlivě levněji a rychleji než z prašivého lokálního disku, mohlo by to být centrálně zálohované na úrovni blokového zařízení apod. - ale stejně mi to moc nevoní dálkama... je to spíš takové cvičení systémácké zručnosti. Třeba pro centrální aplikaci updatů je to dost nepoužitelné - updaty by se beztak musely instalovat klasickým způsobem na každé stanici extra, ve chvíli, kdy je nabootovaná (jasně, jsou na to automatizační nástroje). Škoda že Microsoft diskless bootování ve smyslu centrální správy nějak víc nepodporuje. -
Coraid někde na webu doporučuje na AoE provoz vyhradit vlastní síťový segment. A konec konců to celkem dá rozum. Na vyhrazeném ethernetovém segmentu si pak lehce ohlídáte koho do něj připojíte a bez šifrování se obejdete. Nezapomeňte že AoE provoz není routovatelný, takže kdo není fyzicky připojen na daném segmentu se na AoE target nedostane.
-
anonymníZajimavy obdobny protokol je (mozna spis byl) HyperSCSI, coz je implementace SCSI over Ethernet ze Singapurske univerzity.
Ruzne zdroje na Internetu konstatovaly citelne vyssi propustnost nez u ISCSI
za cenu nizsi pruznosti (protokol nelze smerovat).
http://sourceforge.net/projects/hyperscsi
http://en.wikipedia.org/wiki/HyperSCSI
