GlusterFS 3.6 a pár blbostí kolem

9.2.2015 21:16 | Přečteno: 1950× | Za vším hledej Linux |

Tak jsem se konečně dostal ke svému dlouhodobému restu - hodit manuál ke GlusterFS z poznámek do wiki, a když už jsem byl v ráži, tak byl již existující manuál k LVM rozšířen o kapitolu na téma Thin Provisioning a využití SSD jako LVM cache.

Pokud se někdo pozastavil nad tím, jakou má souvislost LVM s GlusterFS, tak pokud je svazek sestaven z bricků nad tzv. thin LV, je možné u GlusterFS verze 3.6 svazky snapshotovat.

Možná si někdo říká, proč raději místo tohoto blogpostu ty manuály nevisí tady - licence pánové..

       

Komentáře

[pavlix]

Mimochodem jsem právě narazil na to, že thin-provisioning-tools vyžadují boost a ten že se ukrutně dlouho kompiluje.

[mimi.vx]

boost je pekna vec:) a stale se mi nekompiluje tak dlouho jako FF , nebo LO

[pavlix]

LO za normálních okolností ne potřebuju a pokud ano, použiju -bin, FF jsem dosud používal -bin, ale zjistil jsem, že je to špatně, nešly mi ani základní věci z HTML5 video, teď mi zřejmě zbývá jedna, bez které stojí youtube pořád zaprd. Ale pořád se dá nahodit -bin, spustit a pak teprve kompilovat, ale u boostu to nejde, když ho to chce kompilovat ještě během instalace před rebootem. Nehledě na to, že genkernel-next na něm taky bůhvíproč prostřednictvím thin-provisioning-tools závisí.

[Marián Kyral]

Mimochodem jsem právě narazil na to, že thin-provisioning-tools vyžadují boost a ten že se ukrutně dlouho kompiluje.

Boost podle mne potřebuje hlavně hodně paměti. Na starším HW to bylo vždy utrpení, teď na i5-4210M CPU @ 2.60GHz se 16GB RAM a 6GB ramdiskem pro /var/tmp/portage to je v pohodě. Nejvíce mi pije krev webkit-gtk.

# qlop -tH boost
boost: 11 minutes, 14 seconds for 2 merges

# qlop -tH firefox
firefox: 36 minutes, 58 seconds for 4 merges

# qlop -tH libreoffice
libreoffice: 2 hours, 6 minutes, 0 seconds for 2 merges

# qlop -tH dev-qt/qtwebkit
qtwebkit: 29 minutes, 16 seconds for 3 merges

# qlop -tH net-libs/webkit-gtk
webkit-gtk: 1 hour, 4 minutes, 49 seconds for 2 merges

[pavlix]

Já jsem na to narazil na tomhle, což jsem osadil jednou 8GB ramkou.

# qlop -t boost
boost: 3145 seconds average for 1 merges
# qlop -g boost
boost: Wed Feb 11 03:09:50 2015: 3145u seconds
boost: 1 times

To jsem ho nainstaloval až v rámci kompletního rebuildu, který běžěl přes noc a ani to nestačilo :).

[Marián Kyral]

Tak AMD procesory už nějakou dobu nesleduji, takže netuším jak je na tom ten tvůj v porovnání s tím mým. Ale evidentně je pomalejší Další věc asi bude, že mám sice jen dvě plnohodnotná jádra, ale systém vidí čtyři, takže pří kompilaci používám "-j5".

[pavlix]

Ta deska s procesorem popravdě stála míň než ramka, kterou jsem do ní dal, takže nevím, jaký výkon bys asi tak čekal.

[Marián Kyral]

Koupíš si počítač do kanceláře a pak se divíš, že se ti tam Gentoo kompiluje dlouho

[pavlix]

Jo vidíš, MAKEOPTS jsem ani neladil, jaká je vlastně výchozí hodnota?

[Marián Kyral]

MAKEOPTS  
 Use this variable if you want to use parallel make.

Z toho mi logicky vyychází, že 1.

[pavlix]

Opravil jsem to v systému i ve wiki stránce.

[Jirka]

Pěkné! Používáš glusterfs někde na ostro? Co jsem zkoušel nějakou starší verzi (3.4?), tak jsem přišel na replikovaném svazku o data, zkoušel jsem odpojení/připojení ethernetu u jednoho serveru a dokázalo se to spolehlivě rozbít, když jsem to dělal rychleji.

[Aleš Kapica]

Zatím ne, ale plánuji to. S produkčním nasazením čekám až budu mít k dispozici nové disky. Všechny disky co mám k dispozici teď mají minimálně rok po záruce a jsou relativně malé a pomalé.

No a pak tu ještě zbývá jedna věc - nejsem jednoznačně rozhodnut jakou zvolím strategii. Diskless NFS mám odzkoušeno, jenže NFS se u GlusterFS moc pěkně nechová. Blokový přístup do GlusterFS svazku je fajn, ale neumožňuje aby stroj při výpadku původního nodu komunikoval přes jiný (tak jak to udělá klient co jede přes fuse). Snapshotování funguje pěkně, ale víc se mi líbí jak to funguje u Btrfs. Které používám teď nad drbd oddílem. Jenže GlusterFS má zase tu výhodu, že nefunguje pouze mezi dvěma nody. Takže to udělám nejspíš tak, že stroje z jednoho NFS rozhodím na samostatné svazky, využiju GlusterFS klienta a plan9 a snapshotovat budu bricky rovnou na nodech.

[MP]

Slo by vice info prosim? Shodou okolnosti po GlusterFS pokukuji pro webovou farmu, ktera bude mit www slozky pripojene pres sit. Bohuzel zatim jsme bez sitoveho uloziste, takze to musim resit pres lokalni disky. DRBD limit na 2 nody je to, cemu se chci vyhnout - navic bych rad funkcnost zapisu primo na oba nody a active/active DRBD se mi moc nelibi. Sice to mam nasazene s OCFS2, ale ta dvounodovost je nedostatecna.

Obecne hledam dostatecne vykonny sitovy FS s vice nody, bez metadatoveho serveru, schopneho upgradu jednotlivych nodu bez nutnosti vypnout cely FS, prepinani IP ci multiIP(multinod) pripojeni.

[Aleš Kapica]

Je mi jasné o čem je řeč. Také jsem tuhle kombinaci v minulosti používal.

Nicméně to by bylo lepší probrat konkrétně. On-line diskuze na to asi není ten nejlepší prostor. Nevím jak konkrétní řešení vypadá, co se nad tím používá atd.

[mimi.vx]

a co CEPH ?

[Aleš Kapica]

Dával jsem mu šanci už několikrát, ale pokaždé mě vytočil tak, že jsem ho proklel.

[David Jaša]

Blokový přístup do GlusterFS svazku je fajn, ale neumožňuje aby stroj při výpadku původního nodu komunikoval přes jiný (tak jak to udělá klient co jede přes fuse).

Opravdu? Já myslel, že ten bd-xlator nemění síťové chování glusteru, tedy že klient je připojen ke všem relevantním serverům a při výpadku jednoho zůstane připojený (resp. při přidání dalšího se k němu připojí). To, co píšeš, zní jako ty NFS/SMB/... brány do glusteru, které se samy chovají jako gluster klient, a představují SPOF...

Jinak kolik strojů hodláš použít pro glusteří cluster?

[Aleš Kapica]

Proxmox má patch, který to umožňuje obejít. Testoval jsem to s qemu-nbd ale moc se mi to nelíbí. Nakopíruje blok, a zamrzne, dokud to nerozdistribuuje a teprve pak jde na další blok. Ale pozitivní je, že to spojení neupadne.

Stroje hodlám použít tři. Svazky replikované. Ale jak jsem psal - strategii ještě nemám ujasněnou. Viz závěr k onomu testu. Blokový přístup by umožnil i virtualizaci win os, které jako diskless běžet nemohou.

[Aleš Kapica]

Jinak v tom manuálu řada věcí ještě chybí, protože je nemám kloudně zpracované. Proto to ale píšu do wiki, kde je možné ty věci průběžně doplňovat. Kromě toho, i když se někomu může ta wiki jevit uzavřená, není tomu tak. Registrace účtu není vázaná na katedru.

[Prcek]

licence pánové..

Jen aby se místní dámy necítily dotčeny .

[pavele]

Příloha:

• uptime.png (17212 bytů)

Není nad to si libovat, jak to pěkně funguje, a po aktualizacích provést po půl roce restart PC.

Najednou nejde glusterfs 3.6.1 připojit. Jo, na děti Komenského se ohled nebere. (export LC_NUMERIC="en_US.UTF-8" && mount.glusterfs ...).

A když ještě k tomu před půl rokem přejmenujete síťovou kartu pro Glusterfs a zapomenete upravit také firewall, nastává pěkná legrace...

Pořád na to zapomínám:

1. Když to funguje, nešahej na to!

2. Já ti to říkal.

[Honza Jaroš]

Nejsou v článku o LVM Cache v bodech 3. a 4. uvedené špatné disky? Vidím tam /dev/sde a /dev/sdg, které se nikde jinde v textu nevyskytují, tipuju, že tam má být /dev/sd[bc], že...?

[Aleš Kapica]

Samozřejmě. Děkuji za upozornění. Už jsem to opravil.

[Honza Jaroš]

Mimochodem, nechají se u LVM cache doladit parametry podobně jako u bcache? Třeba poměr cache pro writeback k cachi pro čtení apod? Nějak jsem se toho včera nedopátral. Co jsem koukal, tak statistiky jde vytáhnout přes dmsetup, možná to nastavení půjde taky přes něj, ale nikde jsem nenašel dokumentaci...

[Aleš Kapica]

Přiznám se, že nevím. Vyzkoušel jsem to, funguje to, ale nemám k dispozici tolik hardware, abych pro to měl praktické využití, tudíž víc do hloubky jsem v tomto směru nešel.

[Honza Jaroš]

Já právě používám bcache, ale jednak od jádra 3.13 výš tam je nějaká regrese, která až do (na Gentoo) aktuálně používaného jádra 3.17 není vyřešená (load se drží na hodnotě shodné s počtem cachovaných blokových zařízení a po čase zápisy vytuhnou - ví se o tom, ale nevím, jestli už to dořešili, zůstávám kvůli tomu u jádra 3.12), jednak se mi na řešení s LVM líbí, že jde bez problémů přecházet mezi cachovaným a necachovaným stavem (alespoň od LVM 2.0.112, které zatím v Gentoo také není), což bcache neumožňuje. Respektive umožňuje vyřadit cache, ale vždycky tam zbyde extra blokové zařízení.

Akorát když jsem to včera zkoušel, tak mi CrystalDiskMark spuštěný ve windowsovém virtuálu pod KVM neukazoval nijak extra vyšší hodnoty, zatímco bcache mi v zápisu malých bloků dat dost pomůže. Zatím předpokládám, že problém je v nějaké nekompatibilitě verzí jádra/LVM/device mapperu; jak jsem psal výše, verze které jsou v Gentoo k dispozici jsou poněkud staršího data. Uvidíme, ještě si s tím o víkendu zkusím pohrát.

Každopádně díky za tip, o LVM cachi jsem nevěděl.

[Aleš Kapica]

Zajímavé. Já kdysi bcache také zkoušel, ale jak už jsem zmínil, neměl jsem a nemám na to HW prostředky na to abych to mohl v reálu nasadit. Smutný to fakt. Za to se člověk naučí plést z hovna bič.

[Honza Jaroš]

Mně nad tím běží v KVMku Windows s Kerio Connectem, který je dost náročný na diskové operace (zvlášť třeba při přesunech nebo mazání celých složek s velkým množstvím zpráv) a bcache to je schopná rapidně zrychlit. Ale taky je to jen jeden stroj, se kterým není radno příliš experimentovat. Zvlášt v situaci, kdy pro zapnutí LVM cache musím bcache vypnout a přebootovat na novější jádro, protože si s jaderným modulem dmcache z jádra 3.12 pro změnu nerozumí LVM 2.02.110 a odmítne provést 'lvconvert --type cache-pool'...

Ty experimenty s verzí 112 jsem teď dělal na svém notebooku, ale tam mám pro změnu zase jen dvě SSDčka, takže se cachování nijak neprojeví.

[Honza Jaroš]

Takže nějaký problém s verzemi tam určitě bude, protože když s LVM 2.02.110 vytvořím cachovaný oddíl, tak se mi s pomocí staticky zkompilovaného LVM 2.02.112 už nepodaří cachování vypnout (verze 110 ještě přepínač --splitcache neuměla, ten je k dispozici od 112 výš). Naopak když na tomtéž systému zapnu cachování s pomocí té staticky zkompilované verze 2.02.112, tak cache následně odpojit jde.

Večer zkusím, jestli se cachování zapnuté pomocí verze 112 nějak projeví na benchmarcích...

[Aleš Kapica]

Jestli tě mohu požádat, zkus své poznatky pak shrnout do nějakého blogpostu. Tady v diskuzi by se to mohlo zbytečně ztratit.

[Honza Jaroš]

Já se obávám, že by to bylo dost chaotické. Ale zkusím kdyžtak o víkendu něco spáchat. Pokud teda dospěju k nějakým výsledkům. Ono i pokud to bude fungovat, tak asi zatím zůstanu u bcache, než se do Gentoo protlačí příšlušné verze LVM & spol.

[Aleš Kapica]

To nevadí. I kdyby to mělo být pouhé vylíčení patálií s konstatováním, že to je na nic, tak to má svůj přínos.

[Honza Jaroš]

No tak si to zkouším na jiném stroji, kde sice nemám SSD, ale řeším to provizorním ramdiskem. A vůbec z těch výsledků nejsem moudrý. Zkouším si dělat benchmarky pomocí fio a jednou to jede jak dráha a podruhé se tentýž test neliší od zápisu na necachovaný disk. Přijde mi, že pokud to detekuje sekvenční zápis při vytváření testovacího souboru, tak má pak problém přepnout zpátky na náhodný a furt se to chová jako by to jelo sekvenčně. Zkoušel jsem i vypnout detekci sekvenčního zápisu, ale výsledek byl jen ten, že se to do random módu nepřeplo vůbec.

S jakou verzí jádra a LVM to používáte? Předpokládám, že jedete jen ve writethrough módu, je to tak?

Jinak ladit se to nechá pomocí 'dmsetup message' a 'dmsetup --table' a ke statistikám se člověk dostane pomocí 'dmsetup status'. Je to popsané v dokumentaci.

[Honza Jaroš]

Ještě jsem hledal a těch konstatování, že dm-cache má ve writeback módu výsledky dost mizerné jsem našel více. Ostatně o tom píší i v tom odkazu na benchmark pomocí fio. Takže i kdybych chtěl něco ublognout, není vcelku co. V podstatě bych jen zkonstatoval, že ve writeback módu je to k ničemu.

Doufejme, že je to jen dočasné.

Jinak ve vaší wiki by možná stálo doplnit i možnost vytvořit nový cachepool v jednom kroku, jak o tom píší tady:

lvcreate --type cache-pool -L CacheSize -n CachePoolLV VG FastPVs

Co se týče bcache, bohužel jak jsem si teď ověřil, problém s vytuháváním projevující se od jádra 3.13 výš trvá i v jádře 3.19. Teď jsem našel nějaký relativně čerstvý patch, který by to snad měl řešit, zítra ho vyzkouším...

[Honza Jaroš]

Patch vyzkoušen, systém přežil den náhodných zápisů, takže to snad problém s deadlocky řeší. Zvýšený load bohužel stále zůstává, takže tam asi je nadále něco shnilého, ale člověk snad už alespoň nepřijde o data...