Dotaz: Alternativy k NFS

[ranxer]

Zdravim vsechny. Mame uz par let nasazene NFS v siti, ale porad se objevuji nejake problemy ruzneho charakteru (vykon, obnova po restartu a pod..samozrejme vyzkousena zpousta konfiguraci). Zajimalo by me, jestli existuje nejaka alternativa k NFS, ktera by mela splnovat tyto kriteria: 1.dostupna v distribucich (debian) 2. bez nutnosti patchovani kernelu/extra kompilace modulu k vanilla kernelu 3. pouziti jenom s 1 serverem a moznosti zapisu X klientu na vyexportovany FS nebo zarizeni zaroven ? Dival sem se na DRBD, OCFS2, GFS2 ale ani jedno z toho neni to co si myslim, ze by bylo vhodnou alternativou. Samozrejme SAMBU nepovazuju za lepsi reseni nez NFS.

Odpovědi

[Dalibor Smolík]

V poslední době jsem nějaké problémy s NFS měl - na straně klienta bylo nutné (u Debianu sid) přidat parametr nolock do /etc/fstab, na straně serveru nepříjemný bug - nfs ve verzi 1.2.1-1, přestalo fungovat připojení a bylo nutné se vrátit na verzi 1.2.0-4.1 jak nfs-common, tak i nfs-kernel-server, nicméně po vyřešení žádné problémy nejsou, s obnovou po restartu jsem nikdy neměl - ale alternativa by mě také zajímala .

[ranxer]

Me jde o prenosovou rychlost - read-only od serveru ke klientum. Na 1Gb/s spoji nedam po tunningu (nfs,fs,tcp/ip atd.) vic nez 500-600Mb/s. FTP bez problemu +-960Mb/s. Zkouseno na ruznem serverovem HW. Do kombinace ISCSI+gfs2 nebo ocfs2 se mi moc nechce. A POHMELFS je jeste daleko...

[AraxoN]

Potrebuješ asi niečo, čo má cachovanie u klienta... Napríklad OpenAFS.

Alebo prepísať aplikáciu tak aby si to lokálne cachovala sama.

[ranxer]

OpenAFS jsem zkousel, ale cache nepomuze pro zapisy napr. 2GB fajlu na server. Cache to jenom "opticky" zrychly, ale realna rychlost zapisu na server porad nedosahuje hranice 1Gb/s ethernetu narozdil od takoveho FTP.

[AraxoN]

read-only od serveru ke klientum

zapisy napr. 2GB fajlu na server

To sú dosť protichodné požiadavky.

A prečo teda nepoužiješ FTP, keď spĺňa Tvoje kritériá na rýchlosť? FTP sa cez fuse dá namountovať ako normálny adresár na disku a podobná funkcia je dostupná aj pre Windows klientov.

[ranxer]

ok, tak ne zapis, ale cteni..proste mezicache neni reseni. OpenAFS pouziva mezicache hlavne pro data, ktere se casto pouzivaji na stanici uzivatelem. FTP cez fuse je fajn ale treba pri delsi dobe necinnosti to prestava fungovat a taky podle toho jak sem to zkousel pred nejakou dobou, tak kdyz se na serveru neco zapsalo, tak klient to videl az po nejake dobe a pod.

[Ondar]

NFSv4 + delegations. Myslim ze nfs je dobry protokol - nedam na nej dopustit

[ranxer]

zkousel sem a rychlost +- stejna jako u NFS3. Proste jednoduchy test. Nahrat na server a stahnout ze serveru 2GB soubor a ocekavam rychlosti pohybujici se nekde kolem 900-1000Mb/s, podobne jako u FTP. Kolik to jde u vas ?

[Ondar]

Nevim nemeril jsem to. Ale myslim ze jediny zpusob jak toho dosahnout je povolit ty delegations - zalezi na serverove implementaci. Taky si myslim, ze srovnavat to s FTP je trochu nefer. FTP neni sitovy souborovy system, takze tak zasadni veci jako zamykani souboru, cache proste neresi. Pro jednoho uzivatele to neni treba ale pro site se bez tohoto neobejdete. Myslim ze zadny solidni sitovy FS nenabidne lepsi propustnost...

[ranxer]

No tady ( http://www.abclinuxu.cz/poradna/linux/show/283180#1 )clovicek psal, ze na sambe udelal 900Mbps, co se mi taky nepovedlo :(

[Zdenek]

Jak uz se kdosi podivuje v puvodnim vlakne, tak tohle bych opravdu chtel videt. SMB protokol je tak zoufale neefektivni, kvuli svemu overheadu, ze stezi dosahuje 3/4 realne rychlosti linky, navic je silne zavisly na latenci. Vicemene to resi SMB2, ktery MS uvedl s Vistami, ale ktery v soucasne sambe neni (mozna bude v 3.5, urcite ve 4). Jinak s NFS nemam problem a dosahuji cca 960 Mbps, prakticky shodne s FTP a s netunenou sambou kolem 600Mbps.

[ranxer]

Mohl bych pozadat o zverejneni konfigurace na strane serveru i klienta (export optiony, mount optiony) a pripadne neco dalsi co bylo provedeno aby to takhle chodilo ? Stejne bych chtel videt pokud je to mozne nejakou ukazku cteni/zapisu napr. pomoci time cp ...

[multi]

taky jsem pozoroval lepsi vysledky s NFS nez se sambou

[Heron]

Jak uz se kdosi podivuje v puvodnim vlakne, tak tohle bych opravdu chtel videt.

Se někdy stav. Opravdu si to nevymýšlím - pokud si to tedy nevymýšlí dstat a totalcommander.

[Ivan]

Pomalu se zacinam smirovat s tim, ze nic lepsiho nez NFSx na Unixu neexistuje.

- AFS pouziva UDP a je svazany s kerberosem => vyzaduje komplexni setup kterej nekdy neni potreba. Rychlost AFS je limitovana UDP protokolem. Pri "rekonfiguraci" v siti mohou klienti vytuhnout a uz se nikdy neproberou

- OCFS2 ma problemy se stabilitou. Na "vypadky" v siti reaguje rebootem serveru.

- NFS ma problemy se zamykanim a ma tragickej vykon s optionem noac(ten vyzaduje treba oracle). Server na FreeBSD nebo komercni NetApp je lepsi nez Linux NFS server.

- pak je tu jeste Veritas, ten je komerni a ma problemy snad je s velikym poctem souboru v jednom adresari.

[cronin]

Udajne sa konecne rozhybali veci okolo Samby 4. Neskusal niekto tuto alternativu?

[Ondar]

- NFS ma problemy se zamykanim a ma tragickej vykon s optionem noac(ten vyzaduje treba oracle). Server na FreeBSD nebo komercni NetApp je lepsi nez Linux NFS server.

Ano, implementace zamykani je na NFSv3 neefektivni a diky stateless protokolu je dost tezke udelat efektivni client/server cache pro NFSv3 ktera by v jistych situacich nehrozila ztratou dat. Proto vam oracle vnucuje noac. Jak rikam NFSv4 je jiny kafe, tam je tohle vsechno vyreseny. S tou implementaci je to fakt, ze Linux zatim na stabilni server implementaci NFSv4 nema (v porovnani s treba NetAppem), ale NFSv3 je v pohode

[Pheek]

Ahoj, tohle mě zajímá, jde mi konkrétně o OCFS2, už ho nějakou dobu provozuji na diskovém poli a když jsem to testoval tak mi to pomocí iSCSI chodilo na jedničku, ale všiml jsem si že se mi občas restartovali nody co jsou k poli připojeny a nemohl jsem najít v čem je problém, myslel jsem že to bylo špatnou konfigurací iSCSI ale na poli je FS OCFS2.

[Ivan]

OCFS2 neni nic moc. Taky se mi rebootovali servery, a podle stacktrace pri panicu to vypada, ze OCFS2 spoleha ze SCSI vrstva bude 100% funcni a kdyz se stane neco nepredpokladaneho tak to OCFS2 zabali. Tohle se asi stava jen u ISCSI u FC to nehrozi. A vubec je to nejaky divny, mel jsem na jednom volumu instalacni DVD na centos a kdyz jsem ho smazal(rm -rf), tak jsem na druhym nodu porad videl nejaky adresare. Cteni tech adresaru koncili s chybou. Tak jsem to odmontaval na obou nodech a spustil fsck - a nic, "filesystem clean". Kdyz jsem spustil fsck -f tak nasel asi milion chyb(na prazdnym FS) a zase skoncil s tim ze "filesystem is clean". Nejdivnejsi je, ze jsem musel spustit fsck jeste 2x a pokazdy se na tom FS nasly nejaky chyby, ktery bylo potreba spravit. Co je to za fsck, kdyz to necha bordel na filesystemu?

PS: vypada to, ze OCFS2 je napul mrtvy. Oracle koupil lidi co delali v Digital-u AdvFS pro Tru64 ted asi bude tlacit novej closed-source FS, kterej pojede pres fuse :(

[petznaku]

já jsem úspěšně přehodil po posledním rozes*ání NFS všechny "interdomácí" shary na sshfs a od té doby si nemůžu na nic stěžovat... podotýkám ale, že si nejsem jist Vaší třetí podmínkou (!)

[ranxer]

tak sshfs s arcfour a bez komprese je na +-350Mbps:( malo