Jaký storage pro virtualizaci?

20.5.2015 14:59 | Přečteno: 4287× |

Zdravím,

Začínám si připravovat nějaké návrhy na virtualizaci ve firmě. Už dlouho pročítám různé info na webu, ale je toho moc a možností ještě víc, spousta důležitých detailů mi určitě unikla, něco jsem špatně pochopil a tak bych potřeboval nějak uspořádat myšlenky, vybrat vhodné řešení a... a studovat dal

Celé by to mělo běžet na KVM, Proxmoxu (2 nebo 3 node), který už provozuji v jednom testovacím/poloprodukčním provozu (nic důležitého, respektive výpadek není problém), ale na hodně špatném HW. A teď už přišla doba kdy je potřeba s tím pohnout a začít jednat

Hlavně se ale nemohu rozhodnou pro vhodny storage...

1. ZFS?

Nejdříve jsem byl skoro rozhodnut pro nějaký systém ZFS. FreeNas nebo OmniOS+NappIT. Žádný HW RAID, připojení přes NFS nebo iSCSI. Jako HW pravděpodobně SuperMicro, nějaký 4jádrovy Xeon , 32GB RAM, 10Gbit ethernet, SSD ZIL. SAS HDD raid10.

Potom jsem ale začal pátrat po možnostech ZFS a nejake redundanci a HA clusteru. No a se ZFS to zřejmě není zrovna samozřejmé. NappIT na to ma placeny plugin, FreeNAS to resi pomocí CARP+HAST ale neni to soucasti. Nas4Free na to ma i klikatko ve WebGui, ale mam z toho nejaky pocit jako ze je to něco co je okrajové a navíc. A protože to běží v rezimu Primary/Secondary tak v našem idealním světě :) ten druhy server nedělá nic a jenom čeká na potencionalni výpadek toho prvniho. Ale hlavně skoro v každe diskuzi se objeví varovná poznámka: ZFS není clusterový filesystém......

Takže pátrám dál a stále častěji se dostávám k DRBD, GlusterFS a CEPH.

2. DRBD+LVM?

To už teď používám na jedné pobočce na 2node Proxmox HA clusteru. To funguje docela pěkně, Primary/Primary, ale jenom pro 2 nody, nutnost HW raid (i když už jsem koukal na DRBD+ZFS(ZoL)), případné rozšiřování bude komplikovanější..... To na tomto běžícim clusteru až tak nevadí (žádné rozšiřování nebude) , ale na centrálu firmy bych chtěl něco flexibilnějšího.

3. CEPH?

To vypada papírově hodně pěkně. Navíc Proxmox integruje CEPH cluster v sobě, takže není potřeba mít pro storage cluster vlastní HW. Rozšiřování vypadá také OK. Buď přidám disky do nodu, nebo celý nový node. Otázka je co ta kombinace Proxmox+CEPH na jednom železe udělá s výkonem. Ale v případě této kombinace bych tedy mohl vylepšit HW třeba na 3node, každý 2x 6jadrovy Xeon, 64GB RAM, SSD pro OS, SSD Ceph zurnal, 10GBit ethernet. To by snad mohlo byt výkonostně dostatečně v pořádku.

4. GlusterFS?

Tady zatim moc netuším. Každopádně zde už bych měl mít storage opět na samostatném železe...

Teď co všechno na tom vlastně poběží? Ať nejdu s pověstným kanonem na vrabce......

Právě že nic moc velkého. Žádné VPS pro tisíce uživatelů, žádný hosting pro veřejnost s miliony přístupů za hodinu..... Kapacita pole pro VM by mela stačit cca +- 3-4 TB použitelného místa

VM (KVM) budou tyto:

1. Linux - Zimbra pro cca 100 uživatelů - všichni používají webklienta
2. Linux - Samba4 - domena pro cca 20 stanic, printserver
3. WIN7 - Sybase databáze pro účetnictví
4. WIN7 - (na hrani)
5. Linux - WebApplikace - Request Tracker, Joomla, - opět cca 20 uživatelů
6. Linux - Puppet server - zatim není dodělaný ale mel by obsluhovat cca 70 stanic
7. Linux - konsoleApp - ruzne skripty (hlavně stahování a odesílání na FTP)
8. Linux - OpenVPN server - cca 50 klientu

To je zaklad který by mel běžet ve VM a pro tyto potřeby bude výkonu až až. Každý z nich si občas naklonuji pro nějakou zkoušku. Potom bych ale rád přidal něco dalšího...

9. Linux terminal server - pravděpodobně postavený na X2go pro cca 5 uzivatelu - normalni kancelarska prace (Office, web)
10. Linux - jBOSS + Postgresql - to je asi nejnáročnější systém který používáme. 
    Momentálně běží na vlastním železe (2x 4jadro, 32GB RAM, pro DB je RAID1 15kSAS) Výkon je trochu předimenzovaný, ale tento stroj nesmí byt v ničem omezován.
11. ..... nejake BI, OLAP ......

Tak, a co vybrat?

Nejvic se mi asi líbí ten Proxmox+Ceph. Ale nedokážu odhadnout jak to bude s tím diskovým výkonem, hlavne pro ten jBOSS+Postgresql. Všude se píše že výkon CEPH clusteru roste s počtem disků a nodů. Bude tedy lepší více menších disků? Třeba misto 4x1TB 7kSATA pouzit 6x500GB 10kSATA? A tim trochu dohonit režii pro replikaci mezi nody? Já nepotřebuji desitky TB. CEPH dokáže obsluhovat obrovská pole v datacentrech a tam se asi ukazuje jeho síla, ale nebude ten 3node cluster opravdu minimum s tím že to proste nebude to pravé ořechové? Nebo bude CEPH pro naše potreby dost zbytečný?

HW ještě není vybraný, takže s tím se dá stále hýbat dle potřeby.

Takže bych mel otázky pro zdejší uživatele. Provozujete něco podobného? Na čem? Bylo by nějaké doporučení jakým směrem do toho šlápnout a na co se zaměřit? A co naopak rovnou opustit?

Díky.        

Komentáře

[Andantech]

ja by som zvolil exFAT alebo este lepsie FAT 32, urcite nie NTFS.

[Johnny]

BTRFS?

[-g-]

No, ak aktiv/pasiv riesenie je problem, ze pasiv nic nerobi tak sa to vo vacsine pripadov da rozdelit na 2 skupiny diskov a rozbalancovat, ako kto uzna za vhodne. Z mojich skusenosti je to podstatna vyhoda, ak riesim nestandardnu situaciu. Jedna zo skupin diskov mi posluzi ako porovnavacia vzorka v rovnakom prostredi. Ja prevadzkujem drbd + btrfs, alebo drbd + lvm + ocfs2 bez problemov. Az teraz na jednom testovacom prosterdi mam problem s kernelom 4.0.x ktory koruptuje ocfs2 filesystem. Mam pocit, ze to moze byt nieco docinenia s tymto (aj ked sa to tyka ext4 ale korupcie nastavaju uz na vrstve raidu):

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.0-EXT4-Warning

[ZS-Man]

No to DRBD+LVM pouzivam a funguje dobre. Disk rozdeleny na 2 resousrces, obe Primary/Primary. Na res1 jsou VM bezici na node1, na res2 VM z node2. V pripade split-brain staci discard a resysnc spravneho resX na spravnem node a vse bezi dal. Takze to je OK, funguje HA, Live-Migrace mezi nody, nefunguji snapshoty. Ale jakekoliv budouci rozsirovani mi prijde neprijemne komplikovane. Proto koukam po nejakem flexibilnejsim a dostupnem storage clusteru.

[Aleš Kapica]

Nechápu proč sem pleteš ZFS. Nemá nativní podporu v jádře a v clusterovém použití prakticky na prd.

CEPH - Zapomeň. 3 nody jsou pro něj existenční minimum. Já mu dával šanci už třikrát, a pokaždé to skončilo na tom, že se mi ho nepodařilo rozběhat.

DRBD - fajn. Má ovšem jeden háček. Buď musíš mít pro každý stroj extra pole, nebo na něj lézt přes NFS, jako to používáme disklessu. Protože ale chceš virtualizovat i vidle, tak diskless požít nemůžeš a virtuální disky přes NFS.. - no, použít se to dá, ale žádná výhra. Navíc mám poslední dobou pocit, že hoši od Linbitu nějak prdí na agenta pro Pacemaker.

Takže já bych osobně doporučil u takové infrastruktury jako chceš provozovat jít do replikovaného GlusterFS. Výkonově je Schrot slabší, ale oproti DRBD se GlusterFS jeví pro clusterové použití jako robustnější řešení - nemusíš řešit ze kterého nodu na virtuální disk lezeš a můžeš bez obav šaškovat s nody - průběžné je aktualizovat a dělat s nimi i jiné hrátky. Mě v tom jedou zatím tři méně důležité stroje. Pořád zatím ve fázi testu. Oproti původnímu disklessovému řešení linuxových strojů které používám u Peanuts jsem zatím nepřišel na vhodnou strategii zálohování.

[trekker.dk]

DRBD - fajn. Má ovšem jeden háček. Buď musíš mít pro každý stroj extra pole

Proč to? Nestačilo by nad tím DRBD rozběhat LVM? Přímo nad DRBD jsem to teda nezkoušel, ale IIRC jsem to zkoušel nad iSCSI blokovým zařízením - hádám, že by to mělo fungovat podobně. Samozřejmě to omezuje na maximálně 2 nody

[snajpa]

Nechápu proč sem pleteš ZFS. Nemá nativní podporu v jádře a v clusterovém použití prakticky na prd.

Pls. Nesir informace o necem, co neznas. ZFS bezi se vsemi jadry od 2.6.32 po nejnovejsi. A clusterove pouziti pro object store se ZFS neni zadna novinka. Je nekolikero zpusobu, jak na to, ve vsech ZFS usnadnuje zivot.

Autorovi postu: kdybys se rozhodl pro ZFS a potreboval poradit, napis mi mail, pripadne muzes sem.

[trekker.dk]

Nativní podporou bylo, hádám, myšleno začlenění do mainline. Pro někoho (třeba pro mě taky) je to poměrně důležité kritérium pro nasazení.

[snajpa]

Svet neni tak Linux-centric, jak by linuxaci radi videli. ZFS neni o linuxacich, ale o reseni storage napric ruznymi unix-like platformami. Z principu ani nemuze byt mainline. Tim padem irelevantni diskuze. Podporovane upstreamem ZFSonLinux je, dokonce funguje spoluprace mezi porty na ruzne OS, ze si navzajem hlasi bugy. Co je, nebo neni v kernelu, je vzhledem k produkcnimu nasazeni IMHO irelevantni, pokud je nekdo, kdo tomu dela podporu.

[Michal Kubeček]

Co je, nebo neni v kernelu, je vzhledem k produkcnimu nasazeni IMHO irelevantni, pokud je nekdo, kdo tomu dela podporu.

…tedy aspoň do chvíle, než vás s tím taintovaným jádrem support pošle někam. Nebo vám ten někdo bude podporovat celé jádro?

[ZS-Man]

No rozhodnuty zatim nejsem pro nic. Jak jsem psal, nejvic se mi zatim libi ten Proxmox a do nej integrovany CEPH. https://pve.proxmox.com/wiki/Ceph_Server . Je to vse v jednom - staci 3 servery, instalace na par prikazu. Je mi jasne ze nejaky tunning pro konkretni potreby uz bude trochu jiny level, ale u ceho neni, ze? Ted jenom co ten vykon tohoto reseni..... Jsem skoro presvedcen ze ze na vetsinu planovaneho pouziti to bude bez problemu, ale vubec netusim jak se na to bude tvarit velka DB. Treba je CEPH sice skvele reseni ale urcene pro uplne jine potreby.... ZFS jsem uvazoval hlavne ve spojeni s FreeNAS nebo OmniOS a jako externi cluster pripojeny pres iSCSI nebo NFS. A kdybych to uchodil jako storage cluster, tak je to dalsi HW navic. Takze minimalne 2nody pro storage a 2 (+1) nody pro proxmox. Takze jesli bys pro me mel nejake zakladni info na co na co se podivat, a jak se resi ZFS v clusteru, budu rad. Pak bych asi prisel s doplnujcimi otazkami

[snajpa]

Ja bych to pro takhle maly pocet serveru nekomplikoval clusterovanim, kdybych mel resit replikaci dat, tak asynchronne send/recv snapshotu periodicky. Jelikoz to PVE ale nepodporuje, resil bych si to par skriptama sam zrejme. Ne kazdymu muze vyhovovat, nekdo rad UI v browseru, to pak se ZFS asi nic pointegrovaneho poradne neexistuje, leda poupravit drobne FreeNAS (snad umi nejake pluginy, pokud si vzpominam dobre). Ale nativni distribuovana reseni bych uvazoval az od vetsiho poctu nodu, s poradnou siti, atd. V malem bych se spokojil s nejakou formou asynchronni replikace. Nicmene to je muj nazor a jsou priklady lidi, kteri to provozuji i v malem vcelku dobre zclusterovane, ale uprimne si myslim, ze to je dost developmentu naskladat reseni, aby fungovalo a pak se dalo i vyskalovat.

Bohuzel se v hi-level resenich pripravenych pro snadne pouziti neorientuju vlastni zkusenosti, protoze si rad ty technologie poskladam podle situace sam; nicmene samotne ZFS toho umi hodne, rekl bych, ze na spoustu use-cases vubec neni nejake pokrocilejsi UI potreba, staci 2 prikazy na obslouzeni celeho storage a pripadne par skriptu na replikaci (na Githubu se pro ZFS vali nekolik variant vhodnych pro nasazeni rovnou.).

[Max]

Do CEPH bych také nešel, je to pro trošku větší počet nodů.
NFS 4 má hodně blízko k iSCSI co se týče výkonu. Aspoň nedávno jsem si dělal pomocí google průzkum. Nicméně díval jsem se i na FCoE a docela by mně zajímalo, zda to někdo zkoušel. Vypadá to jako zatím nejrozumnější volba, co se týče výkonu.
Když bych to tedy měl řešit já, tak bych asi vyzkoušel :
mdadm / nebo HW RAID -> LVM -> nad ním drbd -> nad drbd lvm -> nad lvm FCoE, na který by přistupovaly všechny nody přes 10Gbit ethernet.
Až budu mít storage, tak to snad vyzkouším a uvidím.
Zdar Max

[MP]

"mdadm / nebo HW RAID -> LVM -> nad ním drbd -> nad drbd lvm -> nad lvm FCoE"

Tohle presne provozuji ve variante: HW RAID -> LVM pro VM -> drbd -> ext4 nebo lvm -> ext4 Ma to jednu velkou nevyhodu - nejak se mi nedarilo namountovat drbd pro cteni na clusterovem stroji jinym zpusobem, nez ten drbd pripojit do nektereho virtualhostu.

[Luboš Doležel (Doli)]

Na Linuxu mám velké problémy s iSCSI initiatorem. Občas prostě při určité zátěži slítne, na targetu to do dmesg napíše error -32 (což je broken pipe) a je to v háji. Vede to k poškození dat.

Bohužel jsem nikdy neviděl podrobnosti toho pádu, protože mám přes iSCSI rootfs. A když padne initiator, padne všechno.

[Max]

Tak zkus FCoE a dej vědět :)
Zdar Max

[alkoholik]

A neni to bug ohledne cteni SMART pres iSCSI?
Kdyz pustis rucne smartctl a slitne to, budes na spravne ceste..
;)

[trekker.dk]

Pár měsíců zpátky psal snajpa v konferenci vpsfree, že Ceph je pomalej. Sám jsem nezkoušel, takže nemůžu ani potvrdit, ani vyvrátit. Je samozřejmě otázka, co je pro snajpu dost rychlé Faktem je, že teoreticky by byl pěkný, AFAIK s tím jde pracovat jako s blokovým zařízením a KVM snad má nějakou podporu pro ceph zabudovanou.

Nad made in udělej si sám úložištěm už jsem přemýšlel, napadlo mě něco jako DRBD + corosync/pacemaker + iSCSI. Dokonce jsem to i rozběhal, ale stějně bych nevěděl, jak moc tomu věřit. Přece jenom iSCSI - pokud vím - není přímo na tohle dělané a redundance je v podstatě založená na tom, že jeden stroj spadne, aniž by předtím odpojil klienty. Když jsem failover vyvolal ručně, server odpojil klienty a těm se ztráta disků moc nelíbila.

[Aleš Kapica]

Pánové nic proti, ale jste jak praštění. Nemáte s tím reálnou zkušenost (CEPH), ale doporučujete to. Přitom z principu CEPH nemůže být rychlejší než GlusterFS, který na rozdíl od něj na menším počtu nodů provozovat lze.

K dnešnímu dni spravují šest clusterů různého typu - většina je symetrických dvounodových, ale mám zkušenosti i s asymetrickým clusterem o více nodech. Jelikož u žádného z nich nemám k dispozici centrální storage, řešil jsem stejný problém o jakém je tenhle blog.

Pokud jde o ZFS. Btrfs funguje stejně dobře, akorát při použití s GlusterFS nedává použití ani jednoho z nich smysl, protože se pracuje s virtuálním diskem, a výhody těchto FS jsou při jeho aplikaci na nic.

Lepší je to v kombinaci DRBD v režimu Primary/Slave a nad tím NFS. Jenže jsem zjistil nepříjemnou věc - systém se hroutí je-li odstraňován větší počet snapshotu z blokového zařízení nad kterým běží NFS.

Dalším problémovým prvkem je agent pro Pacemaker od Linbitu, jak už jsem napsal. Nepočítá totiž s použitím ve vicenodovem clusteru a dělá pěkný binec v konfiguraci závislostí. Jakmile se zapne nějaký nod do stavu online, chce moci mermo prehazovat všechny stroje které jsou aktuálně jako Master. Kamsi. A to i když s tím nodem nemá zdroj jinak nic společného. Naštěstí se mu to nepodaří, jenže zdroj se tím dostane do stavu unmanage a jste v pytli.

U GlusterFS nejsou takové opičky třeba - k datům lze přistupovat přes kterýkoliv z nodů, a to i ze strojů které jsou mimo ně. Qemu má pro API GlusterFS podporu.

[trekker.dk]

Pánové nic proti, ale jste jak praštění. Nemáte s tím reálnou zkušenost (CEPH), ale doporučujete to.

Zatímco vy jste se asi praštil do hlavy doopravdy, a pak jste z mého příspěvku vyčetl něco, co tam ani náhodou není.

[Max]

A nad FCoE jsi nepřemýšlel?
Jinak to odstraňování snapshotů myslíš lvm snapshotů mezi drbd a nfs (s jakou verzí nfs)?
díky
Zdar Max

[Aleš Kapica]

FCoE situaci neřeší a navíc na to nikde nemám HW.

K těm snapshotům - jde o btrfs snapshoty. DRBD (blokové zařízení) + BTRFS (souborový systém) + NFS (sdílení). Používat nad DRBD LVM považuji za úlet. Ne že by to nešlo, ale je to další, vcelku zbytečná vrstva, protože obvykle se používá DRBD vytvořené nad LVM logickým oddílem.

Jinak se pokusím schematicky uvést jaké kombinace jsem používal a proč jsem je opustil

( MD RAID | HW RAID ) + LVM + DRBD Primary/Primary + OCFS2 + Virtual disk

Navíc jsem si musel napsat vlastního agenta do Pacemakeru, který se staral o správné namountování OCFS2, protože ten co byl k dispozici byl zastaralý (pracoval tenkrát ještě se zámky v userspace, které u novější verze jádra byly odstraněny). To by rok 2011. Kritickým bodem byl ovšem rozpad DRBD pole. Po opakovaných restartech, se rozpadalo DRBD pole a vznikal split-brain, jehož řešení obnášelo dilema - který nod má ta správná data? Proto jsme tento koncept opustili postupně opustili a během r. 2012 přešli zpátky na DRBD v režimu Primary/Slave.

( MD RAID | HW RAID ) + LVM + DRBD Primary/Slave + ( Ext3 | Ext4 | Btrfs ) + NFS + (Diskless | Virtual disk)

Tato změna sebou přinesla to, že jsme mohli zahodit OCFS2 a používat rovnou běžný souborový systém. U některých clusterů se přes NFS exportují celé virtuální disky, ale nejlepší výkon a komfort poskytuje Diskless - na který už jsem odkazoval výše - který pracuje rovnou se soubory.

Bohužel neuralgickým bodem je agent Pacemakeru pro DRBD od Linbitu. Jedinou cestou, jak se zbavit závislosti na DRBD je - GlusterFS. Není sice tak výkonný (jeho výkon je závislý na mnoha faktorech), ale funguje poměrně spolehlivě a co hlavně - virtuální disky uložené na jeho svazcích lze poskytovat i na jiné stroje.

Btrfs multidevice + Thin LVM + GlusterFS + Virtual disk

Tohle řešení je ale poměrně čerstvá záležitost. Mám totiž ve zvyku věci průběžně dokumentovat, což je dost náročné na čas a ještě jsem nerealizoval všechny plánované testy nejrůznějších krizových stavů. Jednoznačná výhoda je v tom, že lze virtualizovat libovolný systém. Je to blbuvzdorné a jednou vytvořený virtuální stroj lze v případě nutnosti spustit z libovolného bricku, ale nemám odzkoušeno co se stane, když se začnou hnojit data uvnitř souboru s virtuálním diskem na některém z bricků. Největší slabiny spatřuji v následujících věcech:

• Přechod z disklessu na virtuální disky - znamená to výkonostní propad, ztrátu komfortu a vývojový krok zpět (musí se řešit zavaděč, verze jádra, diskové oddíly, souborové systémy a další blbosti s tím spojené)
• Protože nejsou soubory všech virtuálů v jednom souborovém systémy, nelze řešit zálohu rychlým snapshotem na úrovni souborového systému. Klasické zálohovací metody jsou poměrně náročné na čas i výkon a navíc s musí řešit pro každý stroj extra. A řešit zálohu snapshotováním blokových zařízení na úrovni LVM je blbost. Tento typ snapshotu se hodí pro krátkodobou zálohu, k níž se hodláte vrátit pouze v případě že neklapne aktualizace virtualizovaného systému.

[Max]

A NFS v jaké verzi? Každopádně to je nemilý problém :-/.
FCoE jsem myslel pomocí sw implementace v linuxu a přejít z NFS na blokové zařízení -> FCoE a tím pádem pápá btrfs a mít jen LVM pro virtuálky. Byla by to teoreticky nejvýkonnější možná varianta s HA, ale jen s LVM snapshotama (pro VM).
Zdar Max

[Aleš Kapica]

NFS kernel server 1.2.8-6 jádro 3.14.11 - jasně už je krapet obstarožní ale upgrade clusterového prostředí za běhu není zrovna záležitost kterou bych si chtěl lajznout. Ve Schrotu už mám už všude kernel 4.0.2 a GlusterFS 3.6.2 až na něj přesunou stroje co musí běžet furt a vypadnou studenti na prázdniny (bude možné odstavit infrastrukturu pro laborky), tak si budu moct dovolit upgrade.

[MP]

Jake mate zkusenosti s vykonem glusterfs ? Velmi uvazuji o jeho nasazeni. Jde o to, pouzit NFS v glusteru ci jaky zpusob pripojeni klientu k serveru je v soucasnosti nejlepsi ? U nas by se jednalo o webove slozky (hodne malych souboru) a zaroven by na tom mely bezet databaze psql (10-100GB per psql cluster).

[Aleš Kapica]

NFS přístup na GlusterFS stojí za prd. Dobré jako nouzovka, ale nedá se mu věřit. Ověřeno praktickými testy. Takže smysl má především přístup přes API, který podporuje QEMU.

Pro hodně malých souborů je přímé uložení v rámci GlusterFS svazku smrtelné - režie spojená s manipulací se soubory je příšerná. Při práci s většími soubory (typicky virtuální disky) je to mnohem lepší.

Celkově se dá říct, že výkon GlusterFS je závislý na výkonu blokových zařízení na kterých jsou uloženy bricky. Klasické SATA II disky jsou na tom prachbídně, protože neumožňují asynchronní přístup a jsou ke všemu ještě pomalé - obzvláště ty co se prodávají teď.

Je to bolest ale především při primární instalaci, nebo obnově. Při běžném provozu už to tak nebolí, protože GlusterFS pracuje s bloky dat, nikoliv s celými soubory naráz. Také se to dá žonglovat s jeho konfigurací. Viz odkazovaná stránka v naší wiki umístěná v mém příspěvku o kus výše.

Pokud jde o ty databáze. Nemám to odzkoušeno - ve škole máme na data extra databázový cluster. A ty co jsou v těch testovacích virtuálech nelze považovat za dostatečný vzorek na nějaké závěry.

[Aleš Kapica]

Jinak u GlusterFS je dost zavádějící použití keše. Prostě krmíš data, říkáš si jak to svižně jede a pak najednou nic.. Říkáš si: Co se děje? A on mezitím rozhazuje data z keše na ostatní nody. Je to dost deprimující, ale na reálný výkon virtuálního stroje to pak zas tak velký vliv nemá, neboť pak se větší objemy dat spíš načítají, než zapisují. Zde se ovšem viditelně projevuje skutečný výkon blokových zařízení na jednotlivých nodech. Zatím co u DRBD v režimu Primary/Slave se data tlačí na Slave víceméně jednosměrně, u GlusterFS je poměrně náročná kontrolní režie spojená s distribucí datových bloků mezi nody. Tudíž předpokládám, že zrovna v tomto nasazení se vyplatí mít SAS disky, nebo alespoň o něco levnější NL SAS disky.

[SAM:]

A co zkusit EMC ScaleIO je to sice closed, komerční - pro nekomerční využití bude uvolněno free bez supportu.

[flakon]

Otázka : proč Sybase databázi na Win7 ??? Na Linuxu běží nativně, lépe než na Win.

[ZS-Man]

Protoze to takto dodava dodavatel ucetnictvi (momentalne bezi na XP). S tim nic nenadelam. Na to uz jsem se jich taky ptal, duvodu byla hromada, ale ten hlavni byl asi: Linux???

Vic do toho nevrtam a jsem rad ze zrovna o tohle se stara kolega......

[ZS-Man]

Skladat si to cele podle sebe moc nechci. Ne ze bych s tim mel nejaky osobni problem, v testovacim prostredi si hraju dost, ale do produkce chci radsi neco "standartniho" . To pro mne znamena vybrat nejake reseni ktere se co nejvic blizi pozadovanym potrebam a vyuzivat podporovanou funkcionalitu. Drobna uprava nebo pomocny skript je OK, ale delat nejakou skladacku se mi nechce. No a v mem pripade se tedy jedna o Proxmox a KVM a veskere snazeni by se melo tocit kolem nej.

Takze jak to vidim ted (zatim porad teorie ):

Jestlize mi pujde o co nejlepsi vykon ktery mi dany HW dokaze poskytnout (hlavne pro ty potencionalni DB stroje) tak se asi vykaslat na clusterovani, pouzit samostatne sdilene uloziste pripojene pres 10Gbit iSCSI (MPIO?) a nejak vyresit priodicke backupy ? V tom pripade bych se asi pustil do ZFS. Kdyz mu dam dostatek RAM, vykonne SSD a slusne HDD, tak asi chybu neudelam. Zde by me tedy zajimalo jak se resi to zalohovani snapshotu? Jak casto? Kam? Pri nejakem velkem prusvihu prijdu o data od posledni zalohy?

Jestlize bych ten cluster precijen pozadoval, tak nejakou formu primary/secondary replikace mezi 2 nody? Zde uz musim pocitat s nejakou reziji pro replikaci a propadu diskoveho vykonu. K tomu ale take potrebuji idealne stejne vykonny druhy server, ktery prijde ke slovu pouze v pripade vypadku/udrzbe toho prvniho. To uz se da povazovat za HA storage. Se zfs to tedy zrejme nebude problem? nebo treba to DRBD ktere uz provozuji.

Nasleduje to mnou aktualne provozovane reseni primary/primary DRBD bezici primo na virtualizacnich nodech. Pekne je to ze staci 2 nody, spatne je to ze maximalne 2 nody (i kdyz ted jsem koukal ze DRBD9 uz umi multinode replikaci). Taky momentalne nemam moznost snapshotu. Split-brain je neprijemnost ale ne problem, funguje to.

A potom plnohodnotny storage cluster - GlusterFS a CEPH. Pro GlusterFS by tedy stacily 2 nody? Ale externi, takze zase HW navic. Musim pocitat se znatelnou rezii kvuli replikaci mezi nody, na nejaky use-case se hodi vic, na neco min. Ale ziskam vyborne moznosti rozsirovani.

CEPH - pro moje potreby nejmin vhodny (a to me stve hodne takhle teoreticky vypada opravdu idealne..), - sice je podporovan beh primo na Proxmoxu, ale rychlostne asi nejslabsi..... Na nenarocne VM by to asi slo, ale na narocnejsi DB asi spatne. Nemam jak otestovat, nezbyva mi nez verit zkusenostem jinych.

Pak jsou tady nejake dalsi kombinace, ktre asi nejak funguji, ale zde uz si prave nejsem jisty jestli to chci riskovat.... Koukal jsem na nejake navody na DRBD+ZFS (Proxmox uz ma podporu ZoL) a GlusterFS na dvou Proxmox nodech. Ale jak rikam, do toho bych se asi poustet nechtel...

No kazdopadne diky za dosavadni diskuzi (i kdyz spis jenom ctu a hledam o cem to vlastne mluvite), a za dalsi namety ke zkoumani

[Aleš Kapica]

Komu není rady, tomu není pomoci. Kdyby ses byl podíval na výše odkazované stránky v naší wiki, tak bys byl dávno v obraze. Proxmox je ve skutečnosti to samé co mám já, jen v kompaktním balení. Mám-li porovnat CEPH versus GlusterFS, tak to je nebe a dudy. Rozchodit GlusterFS lze lupnutím prstu. Nicméně mne tahle diskuze přiměla k zamyšlení v čem se liší a už to mám. CEPH je výhodný u většího počtu nodů, protože funguje podobně jako Sheepdog o kterém jsem tu již svého času psal. GlusterFS vyžaduje počty 2, 4, 8 atp.

[trekker.dk]

Rozchodit GlusterFS lze lupnutím prstu.

To bych nepovažoval za tak důležité jako to, jak dobře to pak bude chodit. Ale ok, to už jste tu psal taky, že na dvou nodech (a jestli jsem dobře pochopil, tazatel jich víc mít nebude) to stáhlo za prd, to jako argument beru.

Když jsem to četl, na Ceph se mi líbil návrh - hromada strojů, na nich hromada disků, poskládám to dohromady a všichni vidí všechno. Ideální pro prostředí, které se vyvíjelo tak, že tu hromadu strojů už mám, takže kvůli síťové storage nemusím vyhodit půlku serverovny. Dokonce mám pocit, že EMC něco podobného nabízí za peníze a vůbec bych se nedivil, kdyby se inspirovali (ať už jedni nebo druzí.)

Na druhou stranu jsem o Ceph od nikoho neslyšel žádné pozitivní reference, takže jsem nějaké vážnější testování nechal "na jindy"...

[Aleš Kapica]

Jak už jsem zmínil. Zkušel jsem ho nasadit už třikrát a pokaždé jsem shořel jak papírový čert. Naposledy asi před čtvrt rokem. To jsem měl od kolegy vypůjčených 7 starších strojů. Jenže nejdříve jsem zabil hromadu času tím, že jsem navzdory ujištění že SCSI disky v těch "úžasných" strojích jsou ok, řešil odumírající bloková zařízení. Nakonec těch 7 strojů zbyly čtyři. No nic. Na minimální konfiguraci pro CEPH by to mělo stačit. Všecho jsem měl nainstalované. Dokonce jsem si vyrobil i vlastní binární balík, z aktuálního gitu. Stroje se viděly, vše se zdálo ok. Chyběla pouze taková drobnost - vytvořit připojitelné zařízení. To jsem zkrátka nedal. Všude se píše o použití skriptu ceph-deploy, jenže ten součástí instalace nebyl. Nu což. Manuálně to mělo jít taky. Stroje byly puppetizované takže o distribuci konfiguráků na jednotlivé nody bylo postaráno. Jenže jsem zjistil, že jaksi v dokumentaci opoměli promítnout některé změny které se týkaly konfiguráku. I to jsem zvládnul. Skončil jsem na tom, že na rozdíl od GlusterFS, kterému pro brick stačí předhodit adresář, CEPH trvá na tom, že si chce naformátovat celé blokové zařízení. No a u toho jsem neustále narážel na ty problémy s těmi disky. Tak jsem to vzdal. GlusterFS jsem testoval již když jsem si hrál se sheepdogem, což je čtyři roky nazpátek. A i tehdy nebyl s jeho rozběháním žádný problém. Akorát výkonově to byla tehdy dost bída. Ostatně, xlator, který umožňuje rychlejší blokový přístup k souborům přes GlusterFS API se objevil teprve před dvěma lety. A podpora pro snapshotování svazků je přítomná teprve od GlusterFS verze 3.6, která je u Debianu pouze v repozitáři pro experimental.

[Aleš Kapica]

Napadlo mě uvést také důvod proč upřednostnil GlusterFS a ne Sheepdog, který již tehdy fungoval velice pěkně. Je to jednoduché - GlusterFS svazek lze namountovat jako souborový systém a soubory existují jako soubory. Ovšem k blokovým zařízením spravovaným přes Sheepdog se jinak nedá dostat než přes QEMU nebo iSCSI, protože jsou rozsekané na bloky a roztahané všude možně.

[Aleš Kapica]

Jinak jen tak pro zajímavost. Během dnešního dopoledne jsem aktualizoval všechny nody ve Schrotu a v Debianu již je GlusterFS verze 3.7.0 Upgrade proběhnul bez odstávky svazků za bez větších problémů.

A když už jsem naťuknul.. Aktuálně hledám způsob, jak otestovat jestli je GlusterFS svazek připraven k použití. Pokud totiž připraven není, vybleje QEMU chybu, ale zůstane viset.

[ZS-Man]

No v planu jsou 3 servery. Proto jsem zacal uvazovat i nejakem tom storage clusteru ( za predpokladu ze na tech trech nodech pobezi jak virtualizace tak storage) A jde o to jestli to clusterove uloziste v tomto mensim podani poskytne dostatecny vykon treba pro nejakou narocnejsi databazi. Jestli CEPH nebo GlusterFS je v zasade jedno, vybral bych to co bude pro moje potreby vyhodnejsi. A jestli takove storage nebude vhodne v ani jednom pripade, tak budou 2nody pro virtualizaci a z tretiho bych udelal treba ten externi ZFS. Myslim ze moznosti jsou, HW mohu stale upravovat podle potreb. Bohuzel HW ted nemam, takze vlastni testy chybi....

Myslim ze mimo hru by nebyly ani 4 nody , z toho 2 by mely lepsi CPU a vice RAM. na nich by bezeli virtualy, zbyle dva slabsi cpu a mene RAM. Disky ve vsech 4 nodech. To by pro ten CEPH mohlo byt zese o neco lepsi. Ale jestli je to porad malo a CEPH ten slusny vykon proste neda tak je samozrejme mimo hru. A jestli si na tom bude GlusterFS chrochtat blahem, tak je vitez Ale jak rikam, zatim nemam HW, tak proto ten sber informaci, treba se tu ukaze nekdo kdo ma obe varianty realne otestovane.

[SAM:]

EMC ScaleIO

[ZS-Man]

Poradit si necham rad, GlusterFS jsem nikdy nesledoval ani okrajove, takze i kdyz si odkazovanou Wiki procitam, potrebuju cas na vstrebani Kazdopadne na te Wiki je spousta zajimavich veci, diky.

K tomu tvemu pokusu s CEPH.... Odmitat ho protoze jsi ho ani nerozbehal neni zrovna OK. Ja jsem v trochu jine situaci. HW bude novy, funkcni a mohu ho vybrat na miru konkretnim potrebam (samozrejme dalsi otazka bude cena za ten idelani HW). Se SW tak necekam nejaky velky problem. Nebudu si to kompilovat sam, nebudu to manualne skadat.... Pouzil bych ten Proxmox ktery CEPH podporuje hlavne tou bezproblemovou instalaci a integraci. Maji na to vlastni balicek ktery se postara o instalaci i zavislosti. Spravovat se da pres Webmanagment proxmoxu.

Takze spis jde o to jaky vykon bude CEPH vs GlusterFS mohu ocekavat na stejnem HW.

[ZS-Man]

Tak jsem konecne vyzkousel ten Glusterfs. Zatim na virtualech. Vypada to zajimave a schopne, zprovozneni jednoduche (skoro jako ten CEPH ). Nasel jsem i nejake porovnani pristupu pres FUSE a QEMU API a to je pekny rozdil. QEMU tam bylo jen o trochu pomalejsi nez primy pristup k diskum. Ale nejakou tu otazku bych k tomu mel...

Pouzivat spis vice samostatnych disku (bricku) v jednom nodu? Nebo z vice disku sestavit RAID pole (RAID0) a z tohoto pole vytvorit jeden brick?

Ptam se proto ze pri tom zkouseni na virtualech jsem v kazdem nodu mel 2 disky (20GB a 10Gb) Celkova kapacita sice 30GB ale nemohl jsem zapsat soubor vetsi nez 20 GB. Je mi jasne ze pri pouziti normalnich disku se do takove situace asi nedostanu, ale pri pouziti vice malych disku by se to stat klidne mohlo zase.

A kdyz budu mit ty jednotlive disky/bricky , tak v ramci nodu sice mohou byt ruzne velikosti, ale ostatni nody musi mit stejne kombinace?

Co HW RAID s cache? Pomuze nebo ma Glusterfs radsi primy pristup k diskum?

[Aleš Kapica]

Více bricků v jednom nodu - předpokládám, že teď hovoříme o jednom svazku - jde to, ale je to zbytečné. Lepší varianta je jeden brick nad RAID polem. To by mělo být buď RAID 1 nebo RAID 6, jinak je to na nic. To už je lepší použít Btrfs multivolume, což je v podstatě RAID0 ale na úrovni souborového systému, nikoliv blokových zařízení.

Pokud se používá RAID, tak nad ním rozhodně použij LVM. Já používám pravidlo, že velikost bricku (LV oddílu) by měla být minimálně dvakrát větší než je plánovaná velikost virtuálního disku. Pokud se ti totiž podaří brick zaplácnout, tak jsi v kopru. Jinak GlusterFS má parametry pro nastavení limitu. Jenže jeden velký soubor, jakým je virtuální disk je něco trochu jiného než hafo menších souborů. A taky je rozdíl, je-li GlusterFS svazek distribuovaný, nebo replikovaný. Pro virtuální disky má smysl jedině replikace.

Pokud se používá replikace, měly by být bricky stejně velké, i když samozřejmě lze kombinovat různé velikosti.

Pro přístup k blokovým zařízením má GlusterFS možnost použít AIO, ale zatím jsem s tím moc neexperimentoval.

Zatím jsem otestoval snapshotování GlusterFS. Hodí se leda pro vytvoření výchozího svazku s image virtuálního disku, který pak lze klonovat. Jinak to přináší víc problémů než užitku. Když by na to přišlo, tak už by bylo mnohem lepší dobastlit snapshotování svazků na úrovni Btrfs.

[ZS-Man]

Ano, jeden svazek. Respektive kdybych chtel vice svazku, tak 1-svazek/1-brick/ na kazdem nodu?

RAID0 ne? Vychazim z toho ze RAID0 by mi mel dat lepsi vykon toho pole. Jestlize lehne jeden disk, tak sice lehne cely brick, ale to by mely pojistit ty 2 zbyvajici nody, ne ?(stale pocitam s 3-node resenim) Nebo je zadrhel jeste jinde?

A co nejaka cache (SSD)? Jak to tak procitam, tak GlusterFS se o nejake cachovani moc nezajima? Respektive proste vyuziva tu nizsi vrstvu tak jak je? Koukal jsem na nejake info o bcache, dm-cache, ale to je spis vec samostatne konfigurace OS toho nodu.

Takze treba nepouzivat zadny HW RAID, misto toho nasadit ten ZFSonLinux (prosim ponechme stranou podporu/nepodporu jadra), doprat mu kvalitni SSD a dostatek RAM, s naroky na vykon pro ZFS by problem taky byt nemel a nad nim Glusterfs? Na nejake clanky o teto kombinaci jsem narazil, ale nikde nejake testy a porovnani treba EXT4,XFS vs. ZFS na tom samem zeleze.

[MP]

Asi to chce lepe hledat...napr: http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?limitstart=0

[ZS-Man]

Diky. Skoda ze ZFS bylo testovane bez ZIL/L2ARC a s malou RAM. A co kdyz nad tim vsim bude ten GlusterFS? Bude tam nejaka rezie, ale jinak +- stejne, nebo to bude vsechno uplne jinak?

[ZS-Man]

Tak jsem na tom mem stavajicim Proxmox/DRBD clusteru zrusil jednu DRBD resource a misto ni jsem nahodil GlusterFS 3.6.3. A tady je nejake prvotni porovnani pomoci fio na local, VM na DRBD a VM na GlusterFS. GlusterFS se zda byt zatim nejrychlejsi, a pri Random Read ten GlusterFS vede dost zasadne. Cekal jsem spis ze bude nejpomalejsi...... Ale zatim tezko soudit podle jednoho testu.

Random read/write:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

Random read

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread

Host - local, RAID10 6x300GB SAS2, MegaRAID SAS 2108

Random read/write

read : io=3072.4MB, bw=12732KB/s, iops=3183 , runt=247092msec  
write: io=1023.7MB, bw=4242.3KB/s, iops=1060 , runt=247092msec

Random Read

read : io=4096.0MB, bw=19690KB/s, iops=4922 , runt=213013msec

VM Debian - GlusterFS, cache writeback, VirtIO

Random read/write

read : io=3071.7MB, bw=13732KB/s, iops=3432, runt=229056msec
write: io=1024.4MB, bw=4579.4KB/s, iops=1144, runt=229056msec 

Random Read

read : io=4096.0MB, bw=45570KB/s, iops=11392, runt= 92040msec

VM Debian - DRBD, cache directsync, VirtIO

Random read/write

read : io=3071.7MB, bw=11792KB/s, iops=2948, runt=266734msec
write: io=1024.4MB, bw=3932.5KB/s, iops=983, runt=266734msec

Random read

read : io=4096.0MB, bw=16911KB/s, iops=4227, runt=248025msec

Vubec tedy nevim jestli ty vysledky jsou celkove dobre nebo spatne, DRBD i GlusterFS bezi na vychozi konfiguraci, temer bez jakychkoliv uprav. Takze je cas trochu se venovat tomu tunningu...

[Aleš Kapica]

Hodně to ovlivní paměti a keše. U mne se to projevuje od práce s daty nad 10GB. Pro běžné fungování je to ok. Potíž je při větších přesunech dat, jako je kopírování virtuálních disků, většího objemu záloh a pod.

[ZS-Man]

OK, zkusim jeste nejake vetsi soubory. Me jde hlavne o pouziti jako storage pro virtualni disky, zalohovani probiha na externi NAS, zadne velke presuny bezne nedelam. Proste vytvorit VM a ten at bezi co nejlepe to jde.

A nemas nejaky oblibeny benchmark kterym si delas rychlou predstavu o vykonu toho GlusterFS pro potreby KVM VM? A k tomu nejake vysledky at mam neco na porovnani?

[MP]

Jak presne mas pripojeny local? Zmeril jsem s tvymi fio nastavenimi svoje:
UUID=XXXXXXXXXXX /mnt/gluster-storage ext4 errors=remount-ro 0 0
Xen kernel, Debian 8 (8x 300GB SAS2 10k, SmartArray P410, cache R/W 25/75, R10)

Random R/W:
read : io=3071.7MB, bw=11986KB/s, iops=2996, runt=262420msec
write: io=1024.4MB, bw=3997.9KB/s, iops=999, runt=262420msec

Random R:
read : io=4096.0MB, bw=18343KB/s, iops=4585, runt=228656msec

(8x 300GB SAS2 10k, SmartArray P410, cache R/W 75/25, R10)

Random R/W:
read : io=3071.7MB, bw=11409KB/s, iops=2852, runt=275688msec
write: io=1024.4MB, bw=3804.8KB/s, iops=951, runt=275688msec

Random R:
read : io=4096.0MB, bw=17226KB/s, iops=4306, runt=243480msec

Pro porovnani:

/var/tmp:
read : io=3071.7MB, bw=10460KB/s, iops=2614, runt=300719msec
write: io=1024.4MB, bw=3488.3KB/s, iops=872, runt=300719msec

To, ze je 6 disku rychlejsich nez 8, je zvlastni. Glusterfs FUSE fio 2 nody:

read : io=3071.7MB, bw=7332.3KB/s, iops=1833, runt=428978msec
write: io=1024.4MB, bw=2445.2KB/s, iops=611, runt=428978msec

Gluster FUSE top 2 nody:

root@ic3:/mnt/gluster-test/fio# gluster volume top gluster-test read-perf bs 4096 count 1024
Brick: ic3-gluster:/mnt/gluster-storage
Throughput 2974.68 MBps time 0.0014 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /fio/test                                       2015-06-03 10:06:29.522222
   0 /test                                           2015-06-03 09:58:58.369362
Brick: ic4-gluster:/mnt/gluster-storage
Throughput 2555.94 MBps time 0.0016 secs

root@ic3:/mnt/gluster-test/fio# gluster volume top gluster-test write-perf bs 4096 count 1024
Brick: ic3-gluster:/mnt/gluster-storage
Throughput 719.93 MBps time 0.0058 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /fio/test                                       2015-06-03 10:06:29.494512
Brick: ic4-gluster:/mnt/gluster-storage
Throughput 728.18 MBps time 0.0058 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /fio/test                                       2015-06-03 10:03:11.735087
   0 /test                                           2015-06-03 09:55:40.622298

[ZS-Man]

Glusterfs mam nainstalovany primo na dvou Proxmox nodech, nody propojeny 2x10Gbit round-robin, a QEMU nepouziva FUSE ale primi pristup k tem VM. FUSE asi bude ten problem....

[MP]

To, ze je FUSE pomale, vim. V tom textu je chyba v odradkovani...Ten vykon 6 disku je trochu lepsi nez vykon 8 disku bez FUSE - to je docela zvlastni.

2x10Gbit RR je docela maso. Sice provozuji RR s 4x1Gbps, ale pod DRBD. Na glusterfs bych si to asi nelajznul, hlavne z toho duvodu, ze podpora ze strany switchu bude nejista. BTW: ty sitovky jsou SPF+ ci Rj45? A pripadne switche? Z volby sitove infrastruktury mame dost tezkou hlavu.

[ZS-Man]

Propojeny jsou naprimo, bez switchu. Tohle bylo od zacatku planovano jako 2-node a DRBD. Ale je to jediny vykony HW ktery ted mam, tak jsem zrusil tu jednu DRBD resource a na ni ted jede na zkousku ten Glusterfs.

[ZS-Man]

Jo a tady je ten local mount:

/dev/sdb1 /glusterfs/disk1 ext4 defaults 0 2

[Aleš Kapica]

root@nod2 :~# gluster volume top stroj read-perf bs 4096 count 1024
Brick: nod2:/srv/stroj/data
Throughput 1062.39 MBps time 0.0039 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /disk.img                                       2015-06-03 12:04:00.744629
Brick: nod3:/srv/stroj/data
Throughput 1080.73 MBps time 0.0039 secs
Brick: nod1:/srv/stroj/data
Throughput 1122.07 MBps time 0.0037 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /disk.img                                       2015-05-27 18:00:42.352519
root@nod2 :~# gluster volume top stroj write-perf bs 4096 count 1024
Brick: nod2:/srv/stroj/data
Throughput 421.07 MBps time 0.0100 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /disk.img                                       2015-06-03 13:07:13.967296
Brick: nod3:/srv/stroj/data
Throughput 565.88 MBps time 0.0074 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /disk.img                                       2015-06-03 13:07:15.150104
Brick: nod1:/srv/stroj/data
Throughput 443.47 MBps time 0.0095 secs
MBps Filename                                        Time                      
==== ========                                        ====                      
   0 /disk.img                                       2015-06-03 13:07:17.407223
root@nod2 :~# gluster volume info stroj
 
Volume Name: stroj
Type: Replicate
Volume ID: ce1671b3-7217-4817-b051-1919407824a4
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: nod2:/srv/stroj/data
Brick2: nod1:/srv/stroj/data
Brick3: nod3:/srv/stroj/data
Options Reconfigured:
cluster.self-heal-daemon: enable
nfs.disable: on

Ono s těmi benchmarky je to takové všelikajé, tak jsem jen pro porovnání přihodil stejné měření aplikované na virtuál, který používám pro testy, než bude časem úplně odstavený - stroj. Link jsem přidal, abyste si mohli otestovat jak ten stroj reaguje. Jede na něm apache, postgres. Dřív se na něm sbíraly data a dělaly nějaké výpočty.

Bricky na nodech jsou na 4TB SSHD od Seagate (LVM oddíl o velikosti 50GB, formátovaný na btrfs). Virtuální disk má 40GB a paměti má ten stroj 1GB.

Kromě tohoto stroje jedou na nodu nod2 ještě další dva, a celkem je v provozu 9 svazků.

[MP]

Jeste dodam jeden test - mereno pres NFS v glusterfs:

z ic3-gluster: ic4-gluster:/gluster-test /mnt/nfsgluster nfs defaults,_netdev 0 0

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
  read : io=3071.7MB, bw=28420KB/s, iops=7105, runt=110675msec
  write: io=1024.4MB, bw=9477.5KB/s, iops=2369, runt=110675msec

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread
  read : io=4096.0MB, bw=36024KB/s, iops=9006, runt=116430msec


z ic3-gluster: ic3-gluster:/gluster-test /mnt/nfsgluster nfs defaults,_netdev 0 0

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
  read : io=3071.7MB, bw=10407KB/s, iops=2601, runt=302226msec
  write: io=1024.4MB, bw=3470.7KB/s, iops=867, runt=302226msec

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread
  read : io=4096.0MB, bw=14545KB/s, iops=3636, runt=288362msec

Podle tohoto testu je vykon pres NFS v pripade pripojeni na vzdaleny node cca 2.5x vetsi...

[ZS-Man]

Trochu "tunningu" Glusterfs a VM a vysledek je toto: Opensuse VM:

Random R
 read : io=4096.0MB, bw=72636KB/s, iops=18159, runt= 57744msec

Random RW
 read : io=3071.7MB, bw=17964KB/s, iops=4490, runt=175095msec  
 write: io=1024.4MB, bw=5990.6KB/s, iops=1497, runt=175095msec 

Hlavne ten Random Read je docela zasadni skok.

U pripojeni pres NFS (1Gbit) byly vysledky spis polovicni. Ale to pouzivat nebudu, takze asi neresim.

Takze ted jdu hledat jak na benchmarky DB

[Aleš Kapica]

Bylo by možné uvést, v čem ten "tunnig" spočíval? Bez toho to jsou jen nic neříkající čísla.

[ZS-Man]

GlusterFS:

quick-read=off                                                                                                               
read-ahead=off                                                                                                               
io-cache=off                                                                                                                 
stat-prefetch=off                                                                                                            
eager-lock=enable                                                                                                            
remote-dio=enable                                                                                                            
quorum-type=auto                                                                                                             
server-quorum-type=server 

VM: VIRTIO, writeback

cat /sys/block/vda/queue/scheduler
[noop] deadline cfq 

blockdev --getra /dev/vda
32768

Jsou to bezne vygoogleny rady pro VM a Glusterfs, ani nevim co melo nejvetsi vliv (tusim ze se to pohlo pri nastaveni parametru Glusterfs) Ted hledam nejake vhodne zpusoby tech benchmarku DB a na zaklade toho bych pokracoval s ladenim GlusterFS.

[Aleš Kapica]

Zajímavé. U většiny těch parametrů bych čekal, že budou ve stavu on naopak výkon zlepšovat. Ale tweaking výkonu GlusterFS nemám zatím nijak odzkoušený.

[ZS-Man]

Tak zrovna toto je opsano primo z GlusterFS dokumentace.

http://www.gluster.org/community/documentation/index.php/Virt-store-usecase#Tunables

[MP]

Me testy s temi "tunable parametry", ktere jsi pouzil ukazaly:
a] zpomaleni pole s deadline + glusterfs tunable
b] pouze pouzite deadline misto cfq - zrychleni pole
b1] v pripade FUSE: rozdil pod 10% v rr/rw,rr
b2] v pripade NFS: rozdil pod 10% v rr/rw, v rr je to zajimavejsi:

z ic3-gluster: ic4-gluster:/gluster-test /mnt/nfsgluster nfs defaults,_netdev 0 0
[cfq]
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread
  read : io=4096.0MB, bw=36024KB/s, iops=9006, runt=116430msec
[deadline]
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread
  read : io=4096.0MB, bw=76913KB/s, iops=19228, runt= 54533msec