Jak použít pro overlay aufs

4.2.2016 17:38 | Přečteno: 2054× | Za vším hledej Linux | | poslední úprava: 5.2.2016 11:45

Jsou tomu dva týdny, co jsem publikoval blogpost, ve kterém jsem shrnul problémy s překrýváním systému publikovaného přes NFS. Během té doby jsem absolvoval celou řádku pokusů a kompilací jádra - včetně těch nejaktuálnějších verzí z git repozitáře. Nakonec jsem nad tím zlomil hůl s tím, že řešení, o kterém jsem tu psal v předchozím blogpostu je funkční a je čas jít dál. A dnes jsem - v souvislosti s řešením zcela jiného problému - přišel na to, proč kolabovalo aufs a jak to obejít.

Co jsem minule nezmínil...

V blogpostu - Jak ojebat overlay, jsem nezmínil, že problémy s překrýváním NFS řeším proto, abych mohl konečně přemigrovat stávající infrastrukturu do virtualizačního prostředí postaveného nad distribuovaným úložištěm. Zasvěcenější možná i zaregistrovali, že jsem se konečně odhodlal vylézt na světlo a něco o tom v březnu utrousit i per huba na installfestu.

Virtualizační prostředí s distribuovaným úložištěm provozuji asi rok. Původně jsem používal pouze GlusterFS s blokovým přístupem, ale to má kapitální mouchu v tom, že během synchronizace dat po restartu nodu s replikovaným brickem má virtuální stroj zablokován přístup na disk a to některé souborové systémy (jako např. ext4) špatně snáší. Teď používám kombinaci: Distribuované blokového zařízení poskytuje Sheppdog a GlusterFS slouží jako distribuované úložiště souborů, které se publikují přes NFS.

A to je důvod proč řeším ten overlay. Stávající disklessová infrastruktura běží přes jaderný NFS server, co publikuje data ze sdíleného DRBD oddílu. A to má několik neuralgických bodů:

Když NFS server vyhnije, stroj hned neumře, takže z hlediska Pacemakeru je všechno OK, ačkoliv nic nejede, protože virtuály čekají až obživne NFS.

Když Pacemaker konečně zjistí že je problém, tak se pokusí přehodit služby na druhý nod. To se mu ale nepodaří, jelikož vyhnilý NFS server stále používá soubory z připojeného DRBD. Bohužel DRBD agent s touto situací nepočítá, takže se to všechno rozesere a je třeba situaci pořešit ručně. Bohužel se to neobejde bez restartu fyzického nodu.

A jednou z věcí, která spolehlivě vede k nabourání NFS serveru, je rušení starých Btrfs snapshotů publikovaných adresářů. Jisté řešení je, dočasně zrušit export snapshotovaného subvolume, ale při tom ohromném množství uložených dat je odstraňování snapshotů operace, která i na výkonném hardware trvá nechutně dlouho.

Pro vytvoření nové infrastruktury jsem měl několik cílů. Tím hlavním bylo zbavit se DRBD, které je víceméně dvounodovou záležitostí. Příslušný agent v Pacemakeru od Linbitu se chová u vícenodového clusteru jako prase.

Takže tohle už mám vyřešené. Blokové zařízení i soubory jsou distribované přes všechny nody, takže Pacemaker se stará pouze o spouštění virtuálních strojů. Používám vlastního agenta, který pracuje přímo s qemu, takže žádný libvirt není třeba. I když nepopírám, že to má jisté mouchy - kupř. není možná live migrace. Na druhou stranu - můžu aktualizovat a restartovat nody, aniž bych si musel lámat hlavu s tím, jestli se to všechno vzpamatuje.

Bohužel výkon distribuovaných systémů silně ovlivňuje IO výkon fyzických nodů a stroje, které jsem mohl použít sice mají slušný výkon CPU, ale z hlediska IO to jsou šet let staré desktopy s pomalými rotačními disky na SATA II. Abych to mohl přestěhovat na výkonnější stroje, musím konečně odmigrovat také disklessovou infrastrukturu určenou pro laboratoře, aby je bylo možné přeinstalovat.

NFS server a GlusterFS

V rámci nové infrastruktury běží NFS server na virtuálním stroji, který je sice součástí GlusterFS, ovšem data rozděluje a sbírá mezi bricky na fyzických nodech. GlusterFS však má jeden háček. Protože je navržen pro řádově velké objemy dat, používá 64 bitová čísla inodů.

Stejná čísla inodů také poskytuje přes GlusterFSAL Ganesha i jeho integrovaný NFS server. A jak se ukázalo, některé aplikace s tím mají problém.

Přišel jsem na to víceméně náhodou. Přestěhoval jsem stroj, který kromě DHCP zajišťuje pro disklessovou infrastrukturu také licenční server. Všechno naběhlo ok - kromě licenčního serveru. Neustále řval, že nemá k dispozici licenční soubor. Jenže ten tam byl.

Bylo to divné, protože všechno bylo překopírované z původní infrastruktury 1:1. No. Kašpárkoval jsem s tím včera celý večer. Spouštěl jsem to přes strace, na nové, i původní infrastruktuře, abych mohl porovnat co se během toho děje. Všechno bylo stejné, až na jeden drobný detail - že se u nové infrastruktury licenčnímu soubor server ani nepokusil otevřít.

Až mě napadlo zkusit ho překopírovat do /tmp na tmpfs. A voilá! Odtamtud ho sežral. Takže bylo jasné že je třeba se kouknout co se vlastně děje když se pokouší sáhnout na ten soubor.

No a k tomu jsem se dostal během dnešního dopoledne. Všimnul jsem si, že příkaz stat vrací u souboru z NFS nad GlusterFS dvacetimístné číslo inodu. Trochu jsem zapátral a ejhle! GlusterFS má pro svůj NFS server berličku v podobě parametru "nfs.enable-ino32: on". Po aktivaci tohoto parametru začne jeho NFS server nabízet čísla inodů jako 32 bitové číslo. Bohužel to nefunguje, pokud na GlusterFS svazek lezete přes API jako Ganesha.

Jak to souvisí s overlayem?

A jak se ukázalo - je to právě problém s 64 bitovým číslováním inodů, který je za tím, proč nefungovalo překrytí NFS adresáře přes aufs. A je velmi pravděpodobné, že stejný problém vězí i za tím, proč nefuguje modul overlay. Jak se zdá, tak právě přemapování inodů je to co se udělá při překrytí NFS pomocí unionfs-fuse, jak jsem předpokládal v diskuzi pod předchozím blogpostem.

GlusterFS to řeší interně v rámci svého NFS serveru. Jistě. Stejným způsobem by to pravděpodobně mohl oprasit i modul aufs. Ovšem zdá se, že chyba je kdesi v kódu VFS, který aufs využívá stejně jako overlay.

Update z 5.2.2016: Tušení mě nezklamalo. Stačí při mountování aufs přidat option "noxino". Bohužel se - pokud chcete používat overlay přes aufs - nevyhnete kompilaci vlastního kernelu, protože z distribučního jádra Debianu od verze 3.18 vykopli. Ale třeba někoho z maintainerů Debianu napadne, že to nebyl zrovna dobrý nápad.

       

Komentáře

[Ruža Becelin]

GlusterFS však má jeden háček. Protože je navržen pro řádově velké objemy dat, používá 64 bitová čísla inodů.

Jo, nabili jsme si hubu na tom samem dva roky zpatky, positizena aplikace byl starsi agent BMC ControlM.

Jinak diky a blog, je fajn videt jak kdo pouziva GlusterFS

[hydrandt]

Super zapisek, miluju detektivky. Diky moc za vsechny zapisky a za wiki.

Tesim se na zaznam z installfestu!

[MP]

Původně jsem používal pouze GlusterFS s blokovým přístupem, ale to má kapitální mouchu v tom, že během synchronizace dat po restartu nodu s replikovaným brickem má virtuální stroj zablokován přístup na disk

Neni to zpusobeno tim, ze ten glusterfs bezis ze 2 nodu?

[Aleš Kapica]

Neběží že dvou, ale že tří a samozřejmě že to je tím způsobené, protože objekty s nimiž GlusterFS pracuje jsou v podstatě tytéž soubory co poskytuje. Při resynchronizaci kontroluje atributy souboru a pokud mu nesedí nahradí soubor z kopie která je ok. U normálních souborů je to vcelku rychlá operace, jenže v případě virtuálních disků zabere času více a aby se mu během té doby výchozí soubor nezměnil, tak ho po dobu kopírování logicky musí chránit před potencionální změnou. Sheepdog je na tom podobně, jenže tam se nepracuje s obsahem, ale s rozsekaným souborem. Kotroluje se toho mnohem míň a pokud náhodou virtuál hrábne do místa, které ještě neprošlo kontrolou, tak se to projeví tím že systém podrží po nějaký čas IO operaci a pak případně vyhodí chybu souborového systému. Ale ta je pouze dočasného charakteru. Nikoliv trvalá. Systém jako takový běží.

[grdffgg]

mas to zbytocne zlozite, pritom by stacili mat servre s 8TB RAID1 diskami s jfs fs, 8GB RAM a debian jessie....

[Max]

1) když nejsou many, tak nejsou many
2) řeší se tu storage cluster, který je s dostupností úplně někde jinde oproti tebou navrhovanému řešní
3) jfs možná dobrý, ale kdo je zvyklý na snapshoty, kompletní checksumy apod., tak se nerad vrací zpět ...
4) možná to vypadá složitě, ale kdo do toho vidí, tak mu to zas tak složité nepřijde
Jinak díky za blog, dobrý počtení.
Zdar Max

[Odin1918]

To by bylo moc levne a hlavne by si neslo mesice a mesice hrat na ucet danoveho poplatnika.

[Odin1918]

Zajimave. Kdyz vsak vidim ty utrapy, nebylo by lepsi tuto vec outsourcovat a najmout na to spolecnost, ktera ma potrebne know-how a dokaze to delat efektivne? Chapu, ze je to zajimava problematika a ze je zajimave si projit vsechny mozne slepe ulicky, ale uvedomte si, ze instituce, ktera tyto hratky financuje, zije zejmena z penez danoveho poplatnika. Vy v pozici prijemce na konci danoveho a prerozdelovaciho retezce si to patrne neuvedomujete, ale ja, ktery stojim na zacatku retezce, krvacim z oci, kdyz toto plytvani vidim.

[Aleš Kapica]

Nechcete jít prudit tam, kde se scházejí cvičené opice, které máte tak rád, protože živí váš byznys?

Vy nestojíte na začátku řetězce, ale na jeho konci, tedy přesněji - v tom co z něj vypadne. Jinak byste si byl vědom, že bez lidí co se v té problematice pohybují by ty firmy neměly nikoho, kdo by ten outsourcing pro vás dělal.

Můžete si být jist, že řešení o kterém píšu v tomhle blogpostu vám za pár let nějaká firma za krvavé peníze prodá jako ohromnou novinku.

Vaše oči krvácí, ale měly by krvácet mnohem víc, když si uvědomí za kolik tohle řešení nabízí kupř. DELL. Mohu vás ubezpečit, že za ty prachy bych si válel koule až do důchodu.

[Odin1918]

Nechcete jít prudit tam, kde se scházejí cvičené opice, které máte tak rád, protože živí váš byznys?

Dobre minena kritika neni "prudit". A jinak se nenechte mylit. Ja nemam rad cvicene opice, jen chci, aby zamestnanec delal to, co ma ve smlouve a co je mu zadano. Nic vice, nic mene.

že bez lidí co se v té problematice pohybují by ty firmy neměly nikoho, kdo by ten outsourcing pro vás dělal.

Toto bych nechal na trhu. Verte, ze za penize jde vsechno a ze se nekdo najde, kdo onu praci bude delat, pokud mu ji nekdo zaplati.

Můžete si být jist, že řešení o kterém píšu v tomhle blogpostu vám za pár let nějaká firma za krvavé peníze prodá jako ohromnou novinku.

Mozne to jiste je. O tom se nepru.

Nezlobte se, ale opravdu jste mne svou utocnou reakci nepresvedcil o opravnenosti a ucelnosti vynalozenych prostredku na vase pracovni experimenty. Mel bych vam vsak spise podekovat. Toto cele je pro mne jen dalsi argument, ktery podtrhuje nutnost privatizace statniho vysokeho skolstvi. Soukrome skoly at si plytvaji, je to jejich vec a nezatezuji tim danoveho poplatnika.

[Aleš Kapica]

Pro vás ten blogpost napsán nebyl, tudíž si svou kritiku nechte na briefing ve vaší firmě, až budete posuzovat vlastní řešení. Bohužel pro vás jinou, než útočnou reakci mohu mít jen stěží, protože vám podobné považuji za ty největší pijavice na státním rozpočtu. Ať se vám to líbí, nebo ne.

[Odin1918]

za ty největší pijavice na státním rozpočtu

Rekl clovek zamestnany v ceskem vysokem skolstvi.

[Aleš Kapica]

Kromě toho - nevíte nic o mé náplni práce. Tohle řešení, které slouží pro výuku, vám žádná firma nedodá, protože to pro ni není lukrativní a je s tím hromada práce, kterou se vy tady snažíte veřejně devalvovat.

[Ruža Becelin]

Alesi, moc rad ctu vase blogy i to, co pisete na vasich strankach, takze pokracujte a nenechte se timhle znechutit, protoze

Ja nemam rad cvicene opice, jen chci, aby zamestnanec delal to, co ma ve smlouve a co je mu zadano. Nic vice, nic mene.

Odin1918 dokaze v jedne vete poprit sam sebe. Navic zadna rozumna firma nechte lidi, kteri si odsedi svoje a nic firme neprinesou. Staci se zeptat kohokoli, kdo svou firmu nekam dotahl.

[Odin1918]

Nepopiram sam sebe. Zkuste si muj prispevek precist jeste jednou a treba jej pochopite.

[Ruža Becelin]

Popirate. Ale chapu, ze novodobi otrokari maji zajem na tom, aby takovych lidi bylo co nejvice. Aby je nedejboze neohrozili, kdyz se ukaze, ze jsou schopnejsi nez oni.

[Odin1918]

Tohle řešení, které slouží pro výuku, vám žádná firma nedodá, protože to pro ni není lukrativní a je s tím hromada práce, kterou se vy tady snažíte veřejně devalvovat.

Nic nedevalvuji. Devalvujete ji svymi blogy sam. Mesice a mesice o tomto ctu a zjistuji, ze vam nic nefunguje a se vsim jsou neustale problemy. Neni na case to sverit nekomu povolanejsimu?

Vy opravu nejste osoba, ktera umi posoudit, co je a neni lukrativni pro nejakou firmu. Ale chapu vas tvrdohlavy postoj. Pokud by tuto vec prevzal profesional, tak by se take mohlo zjistit, ze to najednou jde a funguje, ze? Take byste si nemohl mesice a mesice hrat s ruznym hardware za penize danoveho poplatnika a psat o tom v pracovni dobe blogy, ze?

[Václav "Darm" Novák]

Jojo. Vypíše se výběrové řízení, bude to trvat pekelně dlouho a nakonec to nevyhraje společnost s potřebným know-how, ale společnost která dokáže z předražené zakázky lépe podplácet. Zrovna u státní správy (a často i jinde) mi připadá mnohem lepší, když si IT řeší problémy samo.

[Václav "Darm" Novák]

Vlastně ne, tady je to škola. Což vlastně nic nemění.

[Aleš Kapica]

U školy je to nemlich to samé - ba možná ještě horší, protože sedí na mnohem větším balíku peněz než obyčejné úřady - speciálně ČVUT. Nechci tady rozebírat tanečky, kterými procházejí mí kolegové, které provázejí budoucí nákup datového úložiště pro FEL. To by se teprve Odin-1918 osypal, kdyby si uvědomil, kolik člověkohodin promarněného času je s tím spojeno. Přitom technologicky nic lepšího než mám já jim stejně nikdo nedodá. Rozdíl je pouze v tom, že si tím koupí alibi pro případ, kdyby se něco začalo srát. Ovšem ta suma, na kolik taková sranda vyjde, je natolik velkorysá, že by někdo musel udělat fakt velkou botu, aby s tím byl problém.

[Václav "Darm" Novák]

Předpokládám že v tom figurujou i peníze z dotací, které se prostě musí utratit, jinak příště dotace nebudou. Navíc zrovna u škol vídám v IT často lidi kteří to mají napůl jako hobby a projekty dokončují klidně i ve volném čase.

Prostě ne... Pokud to řešení není poskytnuto firmou jako dar (nám takhle na střední celkem šťedře dávalo síťové prvky CISCO), nebo pokud na to zaměstnanci prostě nemaj, outsourcing tam nepatří.

[Odin1918]

protože sedí na mnohem větším balíku peněz než obyčejné úřady

Dalsi duvod, proc tuto a dalsi podobne instituce privatizovat, aby nebylo rozhodovano o penezich danoveho poplatnika.

[Max]

Ty jsi nějaký zaseklý / zpožděný, nebo já nevím, jak to popsat, ale ty se neustále opakuješ, stále dokola a dokola stejná písnička. Většině trochu inteligentních bláznů by stačilo copy-paste, ale ty musíš střídat pořadí slov a občas něco i obměňovat.
Nechápu, jak taková věc někoho může bavit, to už je snad nějaká nemoc ...
Zdar Max