Jaký iSCSI Target pro Debian?

[KapitánRUMFree]

Ahoj,

jaký doporučujete iSCSI target pro Debian?
Nějakou dobu byl s iSCSI problém, různě jsem si s tím před pár roky hrál a nebylo to úplně použitelný (možná chyba nastavení?).
Možná máte s něčím velmi dobré zkušenosti, nebo naopak velmi špatné.
http://scst.sourceforge.net/comparison.html

Díky.

[Reklama]

[cita]

ja pouzil pred tremi roky ietd nad drbd s heartbeatem. A bez problemu funguje dokonce i failover.

kazdopadne doporucuju vyzkouset scst co jsem tak postreh. Mohl by byt i 3x rychlejsi nez ietd.

btw pokud budete delat nejake testy. hodte sem prosim vysledky.

[Tomáš Crhonek]

Používáme na CentOS STGT (z repa). Rychlost je omezena pouze rychlostí sítě, u nás 100MB/s, bond jsme ještě nenastavovali. 100MB/s je pro nás bohatě dostačující, většina zápisů je stejně náhodná a ne sekvenční. Na strojích s UPS a redundantními zdroji jsme si troufli i na writeback nastavení cache pro target, rychlost je tak vynikající i pro spoustu drobných zápisů (16GB RAM jako cache se hodí a je to poznat). Tam je rychlost obvykle větší, než lokální disk. Podle dané tabulky by to měl být nejpomalejší driver, tak nevím.

Na Debianu je afaik IET a ten alespoň v mém testu (Debian Squeeze vs. Windows 7 jako iniciator) dokonale propadl. Možná je to rukama, ale každý zápis (to bych ještě chápal, i když na disk to má jít až po vyžádání flush cache) a čtení (tohle už ne) šlo přímo z disku, bez cache. Nepoužitelně pomalé.

[citanus]

Používáme na CentOS STGT (z repa). Rychlost je omezena pouze rychlostí sítě, u nás 100MB/s, bond jsme ještě nenastavovali. 100MB/s je pro nás bohatě dostačující, většina zápisů je stejně náhodná a ne sekvenční. Na strojích s UPS a redundantními zdroji jsme si troufli i na writeback nastavení cache pro target, rychlost je tak vynikající i pro spoustu drobných zápisů (16GB RAM jako cache se hodí a je to poznat). Tam je rychlost obvykle větší, než lokální disk. Podle dané tabulky by to měl být nejpomalejší driver, tak nevím.

Na Debianu je afaik IET a ten alespoň v mém testu (Debian Squeeze vs. Windows 7 jako iniciator) dokonale propadl. Možná je to rukama, ale každý zápis (to bych ještě chápal, i když na disk to má jít až po vyžádání flush cache) a čtení (tohle už ne) šlo přímo z disku, bez cache. Nepoužitelně pomalé.

100MB/s? fuha, takovou dle rychlost jsem nedostal z 1Gb NI ani nahodou, max sem se priblizil k 70MB/s na linearnim cteni a 25MB/s na zapis(take linearni - dd) - to byl stgt

kousek vice jsme dostal na stejnem hw z iet - 90MB/s cteni a 35MB/s zapis

tehdy jsem to testoval na gentoo. Jako uloziste byl vzdy soubor(rozdil oproti lvcku ci primo disku byl minimalni - +-3MB/s).

[KapitánRUMFree]

Mě primárně nejde o rychlost, ale o schopnost vypořádat se s problémy jako je několik vypadlých paketů nebo restart a opětovné navázání spojení, aniž bych u toho musel být fyzicky přítomný. Samozřejmě bych rád i fungující checksumy.

[Reklama]

[Tomáš Crhonek]

100MB/s? fuha, takovou dle rychlost jsem nedostal z 1Gb NI ani nahodou, max sem se priblizil k 70MB/s na linearnim cteni a 25MB/s na zapis(take linearni - dd) - to byl stgt

kousek vice jsme dostal na stejnem hw z iet - 90MB/s cteni a 35MB/s zapis

tehdy jsem to testoval na gentoo. Jako uloziste byl vzdy soubor(rozdil oproti lvcku ci primo disku byl minimalni - +-3MB/s).

A jinak ta sit beha normalne? FTP nebo netcat musi davat 100/100 (full duplex gigabit). Take jsem to ladil. Obcas je to pekne k zlosti, kdyz se pro sitovku za 8tis a v enterprise distru museji kompilovat drivery. Intelka se nam dokonce vypinala (coz je u file serveru ponekud nestastna featura) a pomohlo az update firmware. Jinde se museji vypnout vsechny setrici fce. S drivery primo od vyrobce (Intel, Realtek) to jde bez problemu. Smutne na tom je, ze ti vyrobci sice davaji drivery jako opensource, ale k tomu je binarni blob v podobe firmware, bez ktereho je ten hw jen nefukcni srot. Potom, kdyz uz sitovka jede, je spis problem, ze to dokaze ucpat levnejsi switche a latence jdou az na sekundy a jakekoliv rizeni io je pak na nic.

Co se tyce vypadku site, tak ten nas fileserver pro esx prezije i restart switche (par desitek sekund). Vmware to nepolozi, naopak se pripoji okamzite po obnoveni spojeni, ale pokud trva vypadek dlouho (radove minuty), tak se systemy souboru ve virtualkach prepnou do readonly rezimu. Doma na widlich se to chova v podstate stejne, pocka to, az se "disk" opet pripoji. Vim, ze to nejsou exaktni crash testy, ale v praxi jsem na poskozeni dat jeste nenarazil (a z hlediska navrhu fs by ani nastat nemel) a to uz to zazilo asi vsechny katastrofy.

[citanus]

praveze netcat i ftp saturoval v pohode az k hranici linky. Ale zadny iscsi target se mi nepodarilo vyskalovat na max. 

Dokonce ani ted kdyz uz pouzivam netappy to nevysaturuju na maximum(tady ale tusim si to netapp balancuje sam). Flashovat firmware apod jsem nezkousel(NIC byl nejaky serverovy pci-e dualport od intelu). Co za NIC  jste pouzival vy?

Co se tyce vypadku site, tak ten nas fileserver pro esx prezije i restart switche (par desitek sekund). Vmware to nepolozi, naopak se pripoji okamzite po obnoveni spojeni, ale pokud trva vypadek dlouho (radove minuty), tak se systemy souboru ve virtualkach prepnou do readonly rezimu. Doma na widlich se to chova v podstate stejne, pocka to, az se "disk" opet pripoji. Vim, ze to nejsou exaktni crash testy, ale v praxi jsem na poskozeni dat jeste nenarazil (a z hlediska navrhu fs by ani nastat nemel) a to uz to zazilo asi vsechny katastrofy.

Souhlasim jediny fs, kde jsem mel problem byl xfs(pozorovano na centos i rhel 6.2). Tam jsem pri pokusech s tvrdym odpojeni storage nekolikrat narazil na "vynulovane" soubory, rozumejte tomu tak, ze soubory, ktere byly otevreny byt jen pro cteni zustavaly po tvrdem odpojeni s velikosti 0 a obsah take nemeli.

[Trubicoid2]

Xfs to dělalo, ale už je to dlouho opravený

[citanus]

Ja s tim mel problem cca brezen - duben 2012 v rhel 6.2. Kde to prosi fixly v upstreamu? Prosim link zkusim si pak dosledovat jestli je ten patch v produkcnim rhel jadru.

diky