Dotaz: NFSv3 a iSCSI pre linux-vserver, OpenVZ

[disposable]

V súčasnosti mi bežia virtualizované servery (linux-vserver, OpenVZ, LXC) z Nexenta SAN cez NFSv3. Chcel by som ale rapídne zvýšiť množstvo serverov, ktoré mi takto bežia. (50x viac)

Narozdiel od vmware/kvm/xen sú moje vservery uložené v adresároch a nie kontajneroch (teda tisíce malých súborov namiesto jedného veľkého). Ako čo najviac zrýchlim prácu s tisíckami malých súborov? Cez čisté NFSv3 mám data throughput zhruba 15-25 MB/s pre každého NFS klienta (pri veľkých súboroch 700+ MB/s).

Rozmýšľal som, že na SANe vytvorím veľké súbory, sformátujem ich ako ext4 a do nich uložím po 50 vserverov. Adresár s tými súbormi exportujem cez NFS a mountnem tie súbory lokálne cez loopback. Je seek v jednom veľkom súbore rýchlejší než práca s malými súbormi cez NFS?

Nemám nič proti použitiu iSCSI (ethernet, nie FC) namiesto NFSv3, ale vo všetkých benchmarkoch mi iSCSI pripadá rovnako rýchly, alebo ešte pomalší než NFS.

Som otvorený všetkým prakticky vyskúšaným riešeniam.

Predtým než sa niekto opýta, tak SAN určite v tomto prípade nie je bottleneck. Mám aj ZIL (mirrored Stec Zeusram) aj L2ARC (mirrored OCZ Vertex 3 Max Iops) a dostatok ram. SAN je z dvoch serverov, dvoch mirrored JBODs a dvoch juniper switchov.

Odpovědi

[disposable]

chybička se vloudila - s/FC/dedicated HBA

[Aleš Kapica]

Podle mě si přechodem na velké soubory nepomůžeš. Spíš naopak. I když na druhou stranu pak by mělo smysl začít používat jumbo frame. Ty by ti mohly pomoct i v případě iSCSI.

Já bych to nechal jak to máš, pokud ti to ta Nexenta stíhá. NFS server počítá s tím že pracuje s mnoha malými soubory. Problémy občas přináší naopak soubory velké.

U svého linuxového NFS serveru bych to ošetřil zvýšením počtu naslouchajících démonů. Mimochodem ten můj linuxový stroj je při použití asynchronního připojení jako NFS server výkonnější než Nexenta. Ta totiž jede vždy v synchronním režimu.

Řešil jsem tohle dilema (sync versus async) zrovna nedávno. Nakonec jsem usoudil, že riziko že by se server dostal do kolapsu během nedokončeného asynchronního přenosu je mnohem nižší, než při synchronním přenosu. Jinými slovy - u asynchronního přenosu trvají veškeré operace mnohem kratší dobu.

[disposable]

vďaka za odpoveď. sync vs async u mňa veľký rozdiel nerobí, keďže zápis sa cachuje do hardverových RAM diskov - odozva <23μs, sustained write 800MB/s (4K blocks), 100K random IOPS (4K blocks).

Na jumbo frames teraz už prejsť nemôžem, to som mal spraviť na začiatku.

Otázka je skrátka, či je open(), seek(), seek(), seek(), ..., close() v jednom veľkom súbore cez NFS rýchlejší než veľa open(), seek(), close(), open(), seek(), close() na malých súboroch. (prípadne cez iSCSI)

[Roman]

Otázka je skrátka, či je open(), seek(), seek(), seek(), ..., close() v jednom veľkom súbore cez NFS rýchlejší než veľa open(), seek(), close(), open(), seek(), close() na malých súboroch. (prípadne cez iSCSI)

Tak to zkus a uvidis hned, jak se to chova ve tvem konkretnim prostredi, ne?

[disposable]

Dear Cpt Obvious,

Podstata položenia tejto otázky na takomto fóre je vyhnúť sa zabitiu celého dňa vytváraním testovacieho prostredia a testovaním. Takisto, ak s týmto už niekto má skúsenosti, je možné že prišiel na veci, ktoré mne ani nenapadlo brať do úvahy.

Nakoniec to tak, či tak budem musieť otestovať, ale najprv chcem zozbierať trochu skúseností od iných.