Vlákno názorů k článku Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty od FTR - Dobrý článek, ovšem přidal bych jedno varování: Linuxový cluster...
-
FTR (neregistrovaný)
Dobrý článek, ovšem přidal bych jedno varování:
Linuxový cluster tak, jako ho má pohromadě RedHat a další je bohužel stále ještě nedovařený a nedoporučil bych ho právě u služeb, které *musí* běžet a visí vám na nich podstatné finance. Vícekrát jsem na něm viděl ztrátu informace o konfiguraci clusteru nebo hůře, ztrátu dat při splitbrain nebo i "běžné" relokaci, což jsem na jiných clusterech (veritas, Oracle SC, HACMP, ServiceGuard) nikdy neviděl - a šlo o zcela korektní patchované instalace.
O něčem vypovídá i fakt, že podobné situace se vyskytují i na připravených labech.
Jeden z důvodů je právě nepřítomnost toho, co je v článku uvedeno jako "druhořadá" metoda fencingu, tedy např SCSI rezervace, a reálně prakticky jediná podporovaná volba je STONITH (a komerčně podporované je jen tvrdé vypnutí druhého nodu remote power switchem).
STONITH má zásadní problémy
- race condition (servery se mohou zastřelit navzájem, zvlášť pokud používáte KVM agenty, a pak leží všechno)
- žádný sync nebo nějaké podobé řešení nacachovaných filesystem (meta) dat, a tedy větší riziko ztráty.
- Nod, který nemá co dělat (a tedy je vlastně méně provozně důležitý) má větší pravděpodobnost, že "vystřelí dřív". Když se taky nudí a celé dny si jen hraje s bouchačkou...
- problém se zvětšuje s počtem nodů v clusteru.Ostatní clustering řešení fencing řeší kombinací externí autority a mechanismu v kernelu jednotlivých nodů. Při splitbrain nody clusteru zkusí kontaktovat autoritu a umístit na ni svůj zámek. Operace je atomická a z definice může vyhrát jen jeden. Ten je pak master clusteru a ostatní, kteří zjistí, že už je zamčeno se musí s vlastníkem quora zkontaktovat. Pokud nod není v této situaci schopen kontaktu s quorem ani s vlastníkem quora automaticky sám sebe zastaví (kernel panic/dump/halt).
Tento fencing bývá primárně SCSI2 nebo SCSI 3 rezervace, nebo nějaký jednoduchý síťový server třeba i v jiné lokalitě, který akceptuje spojení od nodů clusteru a čeká na zámek od prvního, kdo ho bude chtít.
Na skutečný support fencingu tohoto typu, hlavně na SCSI rezervace a podporu "sebevraždy" čekáme léta jak na smilování a je skutečně smutné, že to zřejmě "není priorita", asi proto, že více se řeší aplikační clustery a horizontální škálování, než old-school HA.Pochopitelně se pak řeší "quorum matematika", tedy jestli pozůstalí mají dost "hlasů", aby cluster sám sebe považoval za provozuschopného nebo bude vyžadovat lidskou intervenci, ale to už je asi na článek.
Neberte to prosím jako shazování článku nebo autora, je to jen varování před přílišným optimismem vedoucím k neopatrnosti. Použití uvedeného clusteru prostě jen vyžaduje větší péči a kontingenční plány "co když" - a především důsledné a časté zálohy, ze kterých si musíte být jisti, že obnovíte v požadovaném čase komplet celý cluster. Trochu to jde proti smyslu clusteru, když se obáváte s ním manipulovat a musíte si každou operaci nějak jistit, ale v malém prostředí se s tím dá žít.
-
MarSik (neregistrovaný)
RHV například používá sanlock [1], který vypadá přesně jako to co popisujete. lockspace je na sdíleném disku a pří nedostupnosti lockspace dojde k rebootu aplikace nebo celého nodu (přes watchdog).
Sanlock jinak běží jako lokální služba na každém nodu a aplikace si říkají o zámky (a jsou svázané s jejich životností). Asi by tudíž šlo propojit corosync a sanlock na úrovni aplikace, která vlastní daná chráněná data.
[1] přímo i přes livbirt / qemu, vic je toho v manpage: https://pagure.io/sanlock
-
sanlock bohužel není zdaleka totéž.
1 - nejde o ochranu dat aplikace, to je druhotný efekt. Aplikace do fencingu nemá co mluvit, to musí být v režii clusteru. Jde o quorum, tedy o pomoc v rozhodnutí v krizové situaci, kdy jeden nebo více nodů nemá spojení na ostatní nody clusteru, kdo má "mít pravdu" ohledně stavu a konfigurace clusteru jako takového. Druhá strana sama sebe prohlásí za nepoužitelnou, aby zůstala jen jedna autorita, a ukončí se, aby nedošlo ke konfliktům. Dokonce má odmítnout nabootovat systém, dokud nevidí vítěze arbitráže a nemůže od něj dostat aktuální konfiguraci a povolení připojit se do clusteru. A to už sanlock+watchdog nevyřeší.
Mimochodem, aplikační data jsou lépe chráněna proto, že se nod, který "prohrál" arbitráž sám zahaltuje s flushem cache, místo aby ho někdo jiný zastavil vypnutím uprostřed rozepsaných metadat. Druhotný efekt.
2 - plést do toho watchdog není moc šťastné. Quorum device (ať disk nebo síťové) není nutné ani žádoucí kontaktovat až dokud nenastane potřeba. Vůbec nejde o pravidelné proby na quorum device, nemá to přeci suplovat cluster interconnect. Proč riskovat pád části clusteru kvůli momentální nemožnosti kontaktovat quorum device, což může být zcela záměrné nebo to může být opomenutí jinak neovlivňující provoz (maintenance odlehlé části sítě v jiné lokalitě, migrace na jiné disky...)
3 - SCSI3 rezervace například nepotřebuje vůbec žádný prostor na disku, nespotřebuje žádné IO. Pokud máte viditelný jakýkoli LUN ze všech nodů clusteru, může být quorum device právě on, ať je na něm cokoli. Aplikace to vůbec nepozná. Za zkušenosti mohu říci, že SCSI rezervace je zatím asi nejspolehlivější metoda, ačkoli má taky mouchy (co třeba když máte cluster i data na dvou serverech a dvou polích ve dvou serverovnách).
Nakonec mám trochu osobní mentální potíž s výrazem "asi by šlo" v kontextu něčeho, na co vsázím stabilitu provozu a své klidné spaní. Jak píšete "Asi by tudíž šlo propojit corosync a sanlock na úrovni aplikace". Ano, asi by šlo. Ovšem "asi by šlo" je dost slabé vyjádření. Lze také říci "vendore, asi by šlo dodělat standardní fencing přes quorum devices a podporu v systému místo STONITH". Asi by šlo dát aplikaci za balancer nebo využít aplikační cluster. Asi by šlo ji i přepsat.
"Asi" je slovo, které v produkčním projektu nemá co dělat, a právě množtví těch "asi by šlo" záležitostí v podobně základních věcech jako fencing je to, co mi na téhle implementaci poněkud vadí. Nevadí to pro relativně malé nebo osobní projekty. Ale například RedHat má přeci vyšší ambice než tvrdit, že by něco "asi šlo" udělat v implementaci na úrovni konkurence z roku 2003 (SUN cluster v2, a kdo to viděl potvrdí, že to bylo také "něco"). Vlastně lépe řešený fencing mělo i DECovské ASE v polovině devadesátých let. Vsadí si někdo na "asi by šlo" když mu určitě jde o mnoho?
Opravdu nechci nějak bořit nebo shazovat téma článku. Naopak, jako úvod do clusterování je to pěkná sumarizace a dává to smysl. Zkusíte tohle, pro menší prostředí si vystačíte, a víte, po čem se ptát dál. Jen je třeba i vědět, že to má svá úskalí a není to vrchol snažení.
-
MarSik (neregistrovaný)
> 1 - nejde o ochranu dat aplikace, to je druhotný efekt.
Jak u které aplikace. Databázový server je typicky služba, kde jde primárně o data a samotný stroj není tak důležitý (to samé virtuální počítače a ochrana proti double-mount disků).
Aplikace bez dat a s vedlejšími efekty je pak zase příklad vaší strany mince a situace kam se sanlock úplně nehodí.
> Proč riskovat pád části clusteru kvůli momentální nemožnosti kontaktovat quorum device, což
> může být zcela záměrné nebo to může být opomenutí jinak neovlivňující provoz (maintenance
> odlehlé části sítě v jiné lokalitě, migrace na jiné disky...)V případě sanlocku a jím hlídaných dat se obvykle jedná o jeden a ten samý storage server (nebo cluster). Takže delší nedostupnost jednoho znamená nedostupnost obou. Navíc ztráta spojení s daty znamená i ztrátu možnosti je poškodit. Poškození zápisem starších dat po znovuobnovení spojení právě vyřeší lokální sanlock fencingem aplikace nebo celého nodu přes lokální kernel watchdog (což je jen mechanizmus specifický pro linux a ochrana proti pádu lokálního sanlock daemona).
> Aplikace do fencingu nemá co mluvit, to musí být v režii clusteru.
Ale to samozřejmě platí i pro ten aktivní přístup. Aplikace se nemůže neukončit, když řídící logika clusteru zavelí (a je jedno jestli to je corosync nebo sanlock).
> Jde o quorum, tedy o pomoc v
> rozhodnutí v krizové situaci, kdy jeden nebo více nodů nemá spojení na ostatní nody clusteru,
> kdo má "mít pravdu" ohledně stavu a konfigurace clusteru jako takového.Samozřejmě chápu, že u old-school HA existuje i informace o počtu nodů a arbitr není za běžného provozu potřeba. Jak se ovšem takový cluster vyrovná se ztrátou poloviny +1 nodů? (např. pád celého jednoho datacentra). V tu chvíli jsou zbývající nody v menšině a možná vidí arbitra. Předpokládám, že je pak potřeba ruční zásah, narozdíl od aktivně udržovaného zámku.
Oba dva přístupy (quorum + arbitr pro nerozhodný stav vs. aktivní zámek) mají svoje sady problémů a hodí se na malinko jiné typy aplikací. A rozhodně neplatí stejná pravidla pro umístění HA arbitra (někde mimo) a sanlock lockspace (co nejblíže datům), proto se ty přístupy nedají takto jednoduše porovnat.
-
Jako jsem psal níže, sanlock a SCSI3 rezervace (nebo síťový arbitr) pro účely quora neřeší to samé a mají různý účel. Právě proto je nelogické je porovnávat a rozhodně nemůžete argumentovat tím, že byste řešil quorum a následky získání/ztráty quora jednotlivých nodů clusteru sanlockem - Umím si představit, jak bych to celé napodobil, ale není to rozhodně integrální součást tohoto clusteru, bude to můj dodělek. To je vše.
-
MarSik (neregistrovaný)
Nejsme ve sporu, tvrdím to samé. To typické použití se liší.
Nicméně sanlock samozřejmě interně synchronizaci nodů a split-brainy řeší taky. Je tam na koncensus použitý PAXOS co si vzpomínám. Aplikace a data už jsou odstíněna od té komplexity a jen si udržují zámek, takže quorum nemusí řešit.
-
jk (neregistrovaný)
Nevidím tu nic, co by SCSI fencing řešil a STONITH to nedělal také nebo lépe.
- race condition: bez kvóra se nefencuje, fencuje se z kontroleru (tj. jeden stroj). Není to náhodná palba všech na všechny při ztrátě tokenu. Nejdřív quorum a pak střílení nezúčastněných ;). Nevidím, kde by tam mohla vzniknout race condition.
- žádný sync. SCSI reservace taky žádný sync neposkytují nebo ho přímo znemožňují. Takový sync si musí dělat filesystem a aplikace (žurnály třeba, datasync po write...). STONITH tady přispívá zajištěním, že po fencu už k neočekávanému zápisu nedojde (mašina je vypnutá).
- node, co nemá co dělat se akorát dříve připojí do nového ringu po ztrátě tokenu. Je pravděpodobnější, že tam bude. Obecné principy ale zůstanou a není nic jako "hrát si s bouchačkou". Pořád musí udělat kvórum a postupovat skrz stejnou logiku.
- problém se s počtem výrazně nezvětšuje. Ta logika funguje pořád stejně. Leda by se ty nody během formování nového ringu (membership) pořád připojovaly a náhodně odpojovaly (a způsobovaly by tak restart toho cyklu).
STONITH > SCSI fencing any time :)
Samozřejmě se rád dozvím, pokud něco z toho není pravda :).
-
Asi mluvíme o něčem jiném, zkusím to lépe zformulovat. SCSI rezervace není metoda provedení fencingu, je to prostředek dodávající metodě podklad k rozhodování. Metoda samotná je STONITH versus "ukončení běhu sebou samým".
Neboli nod ukončí sám sebe, pokud je ve stavu vyžadujícím quorum a quorum ztratil. Standardní případ, 2 nody plus 1 hlas quorum device. Splitbrain, jeden získá zámek na quorum device (nemá nic společného s clusterovými disky pro aplikaci), a tedy má 2 hlasy, druhý má jen sebe, ztratil quorum, ukončuje se. Ale protože ho nikdo nevypnul vypínačem, tak má všechna systémova metadata *svých* disků, včetně systémových, včetně služeb, které byly "jeho", korektně uložena nebo odrolována (systemová, nikoli aplikační). A máte také crash dump, logy v konzoli, nevidíte tam jen "mlčení jehňátek".
Méně standardní případ, 5 nodu, quorum device 4 hlasy, rozpad na 1, 2 a 2. Kterákoli skupina získá device přežívá, ostatní samy sebe ukončí.
Ukončené nody se do clusteru nemohou připojit ani utvořit vlastní, dokud neuvidí na ostatní, protože prostě nemohou získat quorum.Při splitbrain se můžete spolehnout jen na jedno, a to že vám nefunguje síť. Jak chcete v takovém stavu zaručit, že vůbec jste schopen STONITH provést?
STONITH > SCSI fencing nedává tedy smysl ani this time ani any time :-). Porovnavejte STONITH s metodou "ukončuje se každý sám".
Také nelze míchat SCSI rezervaci quorum device (a psal jsem, že to je jen jedna z možných metod) se zamykáním aplikačních disků, což je oddělená záležitost, i kdyby využívala podobný mechanismus. Překvapivě je sync normálně možný :-). A znovu, netýká se aplikace, můj problém se STONITH je notorická nespolehlivost právě při splitbrain, který má řešit, v logu mlčení jehňátek a ztráta dat nebo rozpad konfigurace clusteru s pravděpodobností 1:6 (vlastní statistika, zkuste vlastních dvacet HA testů pod zátěží, porovnáme data :-).
- ad race condition: vše záleží na metodě určení quora. A bohužel jsem vzájemnou střelbu viděl a řešil, takže si nejsem tak jist, že není možná. Poku je tento bug už vyřešen, jsem rád a odškrtněte si to, ale pořád to neřeší problém se sítí při splitbrain ani větší riziko ztráty dat při opakovaném vypínání napájení.
-
MarSik (neregistrovaný)
Hlavní problém nastane pokud dojde ke ztrátě spojení mezi částí clusteru a kontrolerem. Pokud je IPMI dostupné, tak se nic neděje a fencing to vyřeší.. ale například hodně serverů co jsem viděl používá na IPMI a na síť stejný kabel... a kdo pak odstřelí ten server, když je nedostupné i IPMI?
Pokud to dobře chápu, tak SCSI rezervace je jen arbitr pro případ, že se dvě oddělené části clusteru musí _autonomně_ (bez kontroleru) rozhodnout jestli spáchají sebevraždu nebo ne. Ten kdo se první dostane k arbitrovi vyhrál a zůstane v provozu.
-
Ano, tak by se to dalo formulovat. Nebo lépe, vyhraje ten, kdo nahrabe víc hlasů. Hlas má od quorum device (to může mít víc hlasů dle potřeby) a od každého, na koho vidí po interconnectech a kdo mu tudíž svůj hlas "dá". Má-li většinu, on a jeho "bratři v quoru" žijí dál. Zbytek nodů se sám odstřelí.
Ten problém s IPMI je přesně příklad té potíže. Osobně mi vadí i to vypínání, které pokládám za komplikaci, ale to jistě může být osobní preference, byť k ní mám praktické důvody. Nemusíte mít navíc jen stejný kabel, můžete běžet přes stejné switche apod. Je toho hodně, co se mohlo pokazit, STONITH prostě přidává krok navíc výměnou za sporné benefity, můj názor na to asi nemá smysl opakovat.
-
Dobrý den, díky za komentář a omlouvám se za pozdní reakci.
K pár bodům:
Vícekrát jsem na něm viděl ztrátu informace o konfiguraci clusteru nebo hůře, ztrátu dat při splitbrain nebo i "běžné" relokaci
===> Tohle by mě zajímalo. Byl otevřen case na Red Hat podporu? Co Vám tam řekli? Split brain je poměrně těžko dosažitelný stav, pokud je cluster správně konfigurován (viz níže)
O něčem vypovídá i fakt, že podobné situace se vyskytují i na připravených labech.
===> Nejsem si jistý, kam tím směřujete. Můžete to prosím říct jinak?
"druhořadá" metoda fencingu, tedy např SCSI rezervace
===> Druhořadá proto, že stejně musíme zajistit reboot nodu. Jinak pokud storage SCSI 3 rezervace podporuje, a fence device je správně nastavena, pak SCSI fencing zpravidla účinně a okamžitě zamezí danému nodu přistupovat k datům
STONITH má zásadní problémy
- race condition (servery se mohou zastřelit navzájem, zvlášť pokud používáte KVM agenty, a pak leží všechno)===> Z tohoto důvodu se používá parametr delay na jedné z fence devices. Pokud by měla nastat situace, kdy se oba nody chtějí fencnout zároveň (ve stejnou chvíli), jedna bude fencovat dříve než ta druhá -- a split brain nenastane
- žádný sync nebo nějaké podobé řešení nacachovaných filesystem (meta) dat, a tedy větší riziko ztráty.
===> Toto pozjíšťuji, nedokážu teď odpovědět
- Nod, který nemá co dělat (a tedy je vlastně méně provozně důležitý) má větší pravděpodobnost, že "vystřelí dřív". Když se taky nudí a celé dny si jen hraje s bouchačkou...
===> Ńetuším, co tím chcete říct... Zkuste znovu jinými slovy prosím
- problém se zvětšuje s počtem nodů v clusteru.
===> Který problém? Předpokládám, že se odvoláváte na to "vystřelení"?
Ostatní clustering řešení fencing řeší kombinací externí autority a mechanismu v kernelu jednotlivých nodů
===> Externí autorita může být quorum disk (quorum device od 7.4) a mechanismus v kernelu je využíván při SBD -- storage based death (sbd poison-pill fencing via block-device).
https://access.redhat.com/articles/2943361
Asi bychom potřebovali probrat konrétní situace a udělat RCA na základě logů a daných konfigurací.
Díky, jsou to připomínky k věci.
ČLÁNKY DO MAILU