Portál AbcLinuxu, 3. května 2025 18:43
Křivolaké jsou cestu osudu. A mne přivedly k tomu, že jsem vytvořil náš první HA cluster a začal se v tom krapet vrtat. Na základě několika příspěvků ve zdejších diskuzích jsem kontaktoval i některé z vás - tímto je zdravím, kteří se se mnou ochotně o své zkušenosti podělili - za což jim děkuji.
Existují různé typy clusteru. Tenhle je určen primárně pro KVM virtualizaci. Správu zdrojů zajišťuje Pacemaker, za jehož vývojem stojí Red Hat. A v tom byl kámen úrazu, neboť mou preferovanou distribucí je Debian. Zpočátku jsem v tom měl docela chaos, neboť jsem netušil co všechno vlastně nainstalovat a jak to má fungovat. Stroje opakovaně padaly do vývrtky a já netušil proč. Zdroje - přestože jsem postupoval dle návodů - nefungovaly jak měly a čas od času jsem byl odměněn i nečekaným zpanikařením celého stroje.
To však mám ale již za sebou. Opět se potvrdilo, že co si člověk neudělá, to nemá a také se vyplatí občas kouknout aplikacím na střeva. Takže kromě vlastní dokumentace k HA clusteru na naší wiki, jsem si vytvořil i vlastní repository pro amd64. Bla bla bla k ní najdete v kapitole CRM - instalace. Pokud budete chtít balíky z ní použít, budu rád. Pokud budete chtít přispět k jejich vylepšení, budu ještě radši.
Když už jsem u toho, tak bych chtěl upozornit ještě na kategorii Manuály. Možná i tam najdete něco co se vám bude hodit. Jen tak namátkou bych zmínil manuály na téma: GRUB2, LVM nebo Linuxový SW RAID. Je v nich uložena spousta času zabitého hledáním střípků v hromadách internetového hnoje a vše na vlastní kůži odzkoušeno - tak si toho važte.
Předtím jsem tyhle věci psal na wikibooks, ovšem po zralé úvaze a znechucení ze strany samozvaných cenzorů jsem od toho upustil. Není nad wiki, kde je člověk svým pánem, neboť vývoj jde stále kupředu a klasické staticky publikované články, nebo blogy jako tento, nemají z hlediska času šanci přežít.
Tiskni
Sdílej:
Používám linuxový SW raid (verze 1.2). Jenže ten je až pod LVM, takže s ním DRBD vůbec nepracuje.Šlo o to, že DRBD potřebuje mít jistotu, že je na disku fyzicky aktualizována bitmapa bloků v metadatech, než se začnou zapisovat další data. Jinak by při nekorektním ukončení systému (výpadek napájení) mohla být DRBD metadata nekonzistentní se skutečným stavem. Když máte HW RAID z baterii, tak je za "fyzickou aktualizaci" uvažován už zápis do writeback cache na RAIDu, a disk kvůli tomu nemusí dělat hned seek. I proto se Linbit vyjadřuje ve smyslu "DRBD jedině s HW RAIDem a BBWC, jinak se ničemu nedivte". Takže u SW raidu buď může dojít k nekonzistenci, nebo je tam degradace výkonu při určitém typu žátěže. Nevýhody HW RAIDu jsou jasné, ale pokud se u toho clusteru použije u každého uzlu karta jiného výrobce, tak se ta rizika podle mě omezí.
Mimochodem, není bez zajímavosti, že velmi podobně navrhnul své centrální úložiště i Zdeněk Burda, na jehož blogpost mě upozornil kolega v době kdy už jsem si sepisoval poznámky ke kapitolce o DRBD.Ono to na linuxu moc jinak udělat nejde, natož pak lépe. Ano, ten blogspot je dobrý.
Tady už bruslím na tenkém ledě, ale myslím, že právě proto se nad drbd v režimu Master/Master používá OCFS2, které data replikuje na úrovni souborového systému.No to nevím. Podle mě OCFS2 o nějakém DRBD vůbec nic neví. OCFS2 prostě předpokládá, že máte na všech strojích sdílené blokové zařízení. Typicky exportované z nějakého externího pole/SAN přes iSCSI nebo Fibre Channel. V prostředí, pro které je OCFS2 primárně určen, je DRBD taková nouzovka, pokud nemáte dost peněz na SAN. OCFS2 jako nakonec asi každý clusterový filesystem (třeba GFS) má vlastní lock manager, který mezi uzly komunikuje přes síť a řeší synchronizaci přístupu / zámky.
Když chcípne jeden stroj, tak se při nahazování data nejprve synchronizují z disku který zůstal běžet tak aby se nenabourala jiná data,Tohle dělá DRBD. S tím OCFS2 téměř jistě nemá nic společného, protože o DRBD nic neví.
s tím že případné zbylé nekonzistence se pak již řeší na úrovni souborového systému.To je něco jiného. DRBD metadata slouží hlavně k tomu, aby se po výpadku poznalo, které bloky na "neaktuálním" disku byly v době výpadku změněny, aniž by se musely projíždět oba celé disky. Kvůli tomu je velmi důležité držet konzistenci těch metadat a pořadí zápisů. Jinak může dojít k tomu, že DRBD resource bude ve stavu Consistent, ale data na obou stranách se budou lišit. I proto je možné a asi i dobré občas spustit kompletní kontrolu konzistence dat na obou stranách. Vše je popsáno na webu Linbitu. Ale pokud to vše funguje dobře, není to zásadně podstatné. Nejhorší situace, kdy se toto může projevit, je výpadek napájení obou strojů pod I/O zátěží.
Ostatně pro cluster s větším počtem nodů bych zvolil spíše CEPH, nebo GlusterFS, které pracují s rozprostřenými daty.Záleží na typu zátěže a požadovaném výkonu. Je pravda, že tahle SW řešení typu GlusterFS se stávají stabilními až v poslední době. Ale ty firmy, co si kupují drahé SAN systémy, nejsou úplně mimo. Jako hodně zajímavé z této oblasti mi přijde tohle: http://sourceforge.net/apps/mediawiki/vastsky/index.php?title=Main_Page, plánuje se integrace do Xenu.
No to nevím. Podle mě OCFS2 o nějakém DRBD vůbec nic neví. OCFS2 prostě předpokládá, že máte na všech strojích sdílené blokové zařízení. Typicky exportované z nějakého externího pole/SAN přes iSCSI nebo Fibre Channel. V prostředí, pro které je OCFS2 primárně určen, je DRBD taková nouzovka, pokud nemáte dost peněz na SAN.No to se mi moc nezdá. Nemám pocit že by OCFS2 nutně vyžadovalo sdílené blokové zařízení.
Nějak se míjíme v chápání psané věty, protože to co jsem napsal jinými slovy říká totéž.Když chcípne jeden stroj, tak se při nahazování data nejprve synchronizují z disku který zůstal běžet tak aby se nenabourala jiná data,Tohle dělá DRBD. S tím OCFS2 téměř jistě nemá nic společného, protože o DRBD nic neví.
Ne tak docela. Tím nemám ne mysli stabilitu těchto souborových systémů, jako spíš způsob jejich nasazení. Jejich nasazení má totiž smysl až u většího počtu strojů, což je úúplně jiná situace, než v jaké se nasazuje SAN. Krom toho XEN je z hlediska linuxu podle mě mrkev. Dovolím si krapet zavěštit. Na počátku stojí klasická otázka: "Kdo za tím stojí a komu to slouží?". Zajímavá je rivalita v oblasti lokálních souborových systémů ( Ext4 versus Btrfs ), souborových systémů pro menší clustery ( GFS2 versus OCFS2 ) či souborových systémů pro velké clustery ( GlusterFS versus Lustre ). Na jedné straně barikády stojí Red Hat a na té druhé ORACLE. Zajímavé jsou určité invektivy či skoro až pomluvy, které se vůči ORACLE čas od času vynoří. Je to logické, neboť Red Hat se cítí z této strany ohrožen. ORACLE už získal SUN. Firmu která byla v oblasti unixových serverů konkurencí pro Red Hat a vyvíjela kancelářský balík. S ní i řešení pro lokální virtualizaci. Kdyby ORACLE spolknul Red Hat, tak by se defakto dostal do přímé protiváhy Microsoftu, neboť by byl schopen nabídnout naprosto stejné alternativní spektrum služeb. Od desktopu po virtualizační platformu. Ovšem na rozdíl od Microsoftu staví ORACLE přes veškeré poplašné zprávy jak se zdá svou budoucnost na open source platformě, neboť si je dobře vědom že takto má k dispozici tisíce vývojářů a miliony testerů, které by nikdy nebyl schopen zaplatit.Ostatně pro cluster s větším počtem nodů bych zvolil spíše CEPH, nebo GlusterFS, které pracují s rozprostřenými daty.Záleží na typu zátěže a požadovaném výkonu. Je pravda, že tahle SW řešení typu GlusterFS se stávají stabilními až v poslední době. Ale ty firmy, co si kupují drahé SAN systémy, nejsou úplně mimo.
No to se mi moc nezdá. Nemám pocit že by OCFS2 nutně vyžadovalo sdílené blokové zařízení.Tak na co tam pak řešíte DRBD? DRBD dělá replikaci a nad tím OCFS dělá replikaci ještě jednou? DRBD není nic jiného, než "virtuálně" sdílené blokové zařízení. V Active/Active se to na obou strojích tváří jako by to bylo nějaké sdílené diskové pole.
Nějak se míjíme v chápání psané věty, protože to co jsem napsal jinými slovy říká totéž.Ano, špatně jsem to pochopil.
Ne tak docela. Tím nemám ne mysli stabilitu těchto souborových systémů, jako spíš způsob jejich nasazení. Jejich nasazení má totiž smysl až u většího počtu strojů, což je úúplně jiná situace, než v jaké se nasazuje SAN.To asi ano, oblast je jiná. Přesto pro účely provozního uložení obrazů disků virtuálních strojů považuji SAN za nejlepší řešení. Pokud potřebujeme storage pro soubory, pak se mi třeba GlusterFS líbí víc. Jistě záleží na typu žátěže pro ty virtuální stroje, pokud půjde o I/O výkon a latence, tak SAN řešení musí vyhrát už z principu složitosti a počtu vrstev. Další otázkou je spolehlivost, kde ale teorie dosti selhává - každopádně u distribuovaného FS data prochází daleko větší logikou a větším množstvím kódu než v případě [ diskové pole - FC síť - FC HBA ]. V oblasti enterprise virtualizace ani nikdo jinou cestou než SAN storage nejde ... ale i tam to možná přijde.
Krom toho XEN je z hlediska linuxu podle mě mrkev. Dovolím si krapet zavěštit.Z hlediska linuxu možná. XEN rozhodně jen tak neumře, Citrix na něm má postaveno dost zajímavých produktů. A vývoj je OSS. Ale je to koncipováno spíš jako "blackbox" typu VMWare ESX.
"It is also a shared disk cluster file system, one that allows multiple nodes to access the same disk at the same time"O replikaci tam nic nevidím, i když by mě to potěšilo. Ale oni by se o tom jistě zmínili. Všechny návody, co jsem viděl, používaly OCFS nad DRBD nebo se počítalo třeba s nějakým sdíleným iSCSI polem. Je to stejný typ filesystemu jako RedHat GFS.
Věc se má tak, že nejdřív tam bylo DRBD a teprve následně jsem hledal vhodný FS. Faktem je, že v kombinaci s OCFS se mi prakticky nestalo, že by mi vznikla nekonzistence, kvůli níž by bylo nutné provést synchronizaci.S OCFS je výhoda, že máte jen jeden DRBD resource, trvale ve stavu Active/Active. Třeba XenServer tohle řeší tak, že nad sdíleným diskem má jen LVM se kterým ale dělá různá kouzla kvůli snapshotům. Mají to nějak vyřešené, že není potřeba ani cLVM. Nebo nechávají správu oddílů pro VM přímo na SAN vrstvě (StorageLink).
Lokální SW RAID vytvořený z nbd zařízení. Každý nod má vyexportováno jedno blokové zařízení. Takže /dev/nbd0 je připojený přes 127.0.0.1 a zbytek( /dev/nbd1, ...) po síti.Jasně, tohle je taky možnost. Ale DRBD lépe řeší ty potenciálně nekonzistentní situace. A počítá s tím, že "každou chvíli není dotupný některý z disků", na což mdraid není úplně stavěný.
U kombinace DRBD + OCFS2 byla rychlost kopírování kolem 56M/sKopírování z jednoho disku na ten samý, nebo např. z
/dev/zero na disk? Protože tam, kde mám DRBD nad HW RAIDem s BBWC je při zápisu evidentně limitem replikační Gb Ethernet. Byl bych rád, pokud byste napsal, na jakou rychlost sekvenčního zápisu se dostane KVM virtual machine nad OCFS2+DRBD+mdraid. A ideálně i jak rychlý je stejný zápis přímo na lokální mdraid bez DRBD. V mém případě Xen VM zapisuje z /dev/zero na DRBD replikovaný disk rychlostí 120 MB/s (VM filesystem ext3, 15 GB soubor, čas dd+sync, replikační Eth celou dobu na 997000 kbit/s). Pod DRBD tady na testování mám na obou stranách kartu HP SmartArray 212, RAID10, 4 obyčejné SATA disky. Sekvenční čtení souboru uvnitř VM je cca 200 MB/s.
syncer {
# it's recommended to use 30 % of GbE
rate 33M;
verify-alg sha1;
}
syncer rate se uplatňuje v okamžiku resychronizace, např. pokud jeden z uzlů nějakou dobu neběžel. Nastavení se doporučuje udělat tak, aby resychnronizace využila třetinu linky, a zbytek byl volný pro provozní zápisy.
Byl bych rád, pokud byste napsal, na jakou rychlost sekvenčního zápisu se dostane KVM virtual machine nad OCFS2+DRBD+mdraid. A ideálně i jak rychlý je stejný zápis přímo na lokální mdraid bez DRBD.Zkusím na to pamatovat. Až to otestuji, tak bych to upíchnul nejspíš opět do blogu, jako samostatný blogpost. Tady by to zapadlo. Každopádně díky za konkrétní čísla.
To je sice pravda, nicmene je treba vzit do uvahy ze:
Navic (aspon pokud jsem to spravne pochopil) Linbit HeartBeat spis udrzuje nez vyviji dal, coz nemusi byt v kratkodobem horizontu problem, ale v dlouhodobem byt muze.
.., i když doba výpadku je větší (nestačí třeba přehodit IP adresy, ale musí se nabootovat celý VM) a nedá se tím řešit výkon jedné aplikace.To není až tak docela pravda. U KVM lze přemigrovat stroj zaživa bez výpadku - prakticky odzkoušeno. Mimochodem, to je taky důvod proč jsem se v tom Pacemakeru začal hrabat až tak do hloubky - abych si udělal agenta pro KVM na míru, bez nutnosti používat libvirt, který má ony požadované funkcionality prozatím toliko v TODO. Bohužel "céčko" až tak dalece neovládám. Zpracovávat XML shellovým skriptem mi přijde jednodušší. Jinak bych to byl do toho libvirtu dodělal.
To není až tak docela pravda. U KVM lze přemigrovat stroj zaživa bez výpadku - prakticky odzkoušeno.Jasně, ale to beru spíš jako takovou věc navíc. Pokud mluvíme a vysoké dostupnosti, tak beru jako zásadní mít co nejkratší neplánované výpadky. Tj. jak dlouho to nepůjde, když aktivní uzel nečekaně zkolabuje (výpadek napájení ze všech zdrojů, vyhořelý HW apod.). A v tomto případě stroj musí nabootovat znovu. I když Xen má funkční (experimentální) implementaci realtime replikace obsahu RAM na druhý uzel, takže pak k pádu OS nedojde. Jsou s tím samozřejmě principielní problém, hlavně co se týče výkonu.
abych si udělal agenta pro KVM na míru, bez nutnosti používat libvirt, který má ony požadované funkcionality prozatím toliko v TODOKvůli nutnosti použít libvirt, který se mi zdál příliš komplikovaný, jsem dříve raději použil Xen. Protože pro něj je Heartbeat/Pacemaker agent skutečně triviální a hotový. Pro KVM jsem tehdy našel jen řešení přes libvirt, a to mi přišlo jako zbytečná potenciálně chybová vrstva. A jak píšete, možná požadované funkce ani neumí.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.