Čau Habr! Předkládám vaší pozornosti překlad článku od Andrewa Beekhofa.
Mnoho lidí preferuje dvouuzlové clustery, protože se zdají koncepčně jednodušší a jsou také o 33 % levnější než jejich tříuzlové protějšky. I když je docela dobře možné sestavit dobrý shluk dvou uzlů, ve většině případů, kvůli neuváženým scénářům, taková konfigurace způsobí mnoho neviditelných problémů.
Prvním krokem k vytvoření jakéhokoli systému vysoké dostupnosti je najít a pokusit se odstranit jednotlivé body selhání, často označované jako SPoF (jediný bod selhání).
Je třeba mít na paměti, že v žádném systému nelze eliminovat všechna možná rizika prostojů. Vyplývá to ze skutečnosti, že typickou obranou proti riziku je zavedení určité redundance, což vede ke zvýšené složitosti systému a vzniku nových bodů selhání. Proto zpočátku děláme kompromis a zaměřujeme se na události spojené s jednotlivými body selhání, nikoli na řetězce souvisejících, a tedy stále méně pravděpodobných událostí.
Vzhledem k kompromisům nehledáme pouze SPoF, ale také vyvažujeme rizika a důsledky, v důsledku čehož se závěr o tom, co je kritické a co ne, může u každého nasazení lišit.
Ne každý potřebuje alternativní dodavatele elektřiny s nezávislým elektrickým vedením. Paranoia se sice minimálně jednomu zákazníkovi vyplatila, když jejich monitoring odhalil vadný transformátor. Zákazník telefonoval a snažil se upozornit energetickou společnost, dokud vadný transformátor neexplodoval.
Přirozeným výchozím bodem je mít v systému více než jeden uzel. Než však systém může po selhání přesunout služby do přežívajícího uzlu, musí se obecně ujistit, že přesouvané služby nejsou aktivní jinde.
Cluster se dvěma uzly nemá žádnou nevýhodu, pokud selhání způsobí, že oba uzly obsluhují stejný statický web. Věci se však změní, pokud výsledkem je, že obě strany nezávisle spravují sdílenou frontu úloh nebo poskytují nekoordinovaný přístup pro zápis do replikované databáze nebo sdíleného systému souborů.
Proto, abychom zabránili poškození dat v důsledku selhání jediného uzlu – spoléháme na něco tzv "disociace" (oplocení).
Princip disociace
Jádrem principu disociace je otázka: může konkurenční uzel způsobit poškození dat? V případě, že je pravděpodobným scénářem poškození dat, dobrým řešením by bylo izolovat uzel jak od příchozích požadavků, tak od trvalého úložiště. Nejběžnějším přístupem k oddělení je odpojení vadných uzlů.
Existují dvě kategorie disociačních metod, které budu nazývat rovný и nepřímý, ale lze je také nazývat aktivní и pasivní. Přímé metody zahrnují akce na straně přeživších vrstevníků, jako je interakce se zařízením IPMI (Intelligent Platform Management Interface) nebo iLO (mechanismus pro správu serverů při absenci fyzického přístupu k nim), zatímco nepřímé metody spoléhají na selhání. uzel, aby nějak rozpoznal, že je v nezdravém stavu (nebo alespoň brání ostatním členům v zotavení) a signalizoval o nutnosti odpojit selhaný uzel.
Kvorum pomáhá při používání přímých i nepřímých metod.
Přímá disociace
V případě přímé disociace můžeme použít kvorum, abychom zabránili disociačním závodům v případě selhání sítě.
S konceptem kvora je v systému dostatek informací (i bez připojení ke svým kolegům), aby uzly automaticky věděly, zda mají zahájit disociaci a/nebo obnovu.
Bez kvora budou obě strany rozdělení sítě správně předpokládat, že druhá strana je mrtvá, a budou se snažit tu druhou oddělit. V nejhorším případě se oběma stranám podaří celý cluster vypnout. Alternativním scénářem je deathmatch, nekonečná smyčka uzlů, které se množí, nevidí své vrstevníky, restartují je a iniciují obnovu, aby se restartoval pouze tehdy, když se jejich protějšek řídí stejnou logikou.
Problém s oddělením je, že nejčastěji používaná zařízení se stanou nedostupnými kvůli stejným událostem selhání, na které se chceme zaměřit při obnově. Většina karet IPMI a iLO je nainstalována na hostitelích, které ovládají, a ve výchozím nastavení používají stejnou síť, což způsobuje, že cíloví hostitelé se domnívají, že ostatní hostitelé jsou offline.
Provozní vlastnosti zařízení IPMI a iLo jsou bohužel při nákupu zařízení zvažovány jen zřídka.
Nepřímá disociace
Kvorum je také důležité pro řízení nepřímé disociace; pokud je provedeno správně, může kvorum umožnit pozůstalým předpokládat, že ztracené uzly po určité době přejdou do bezpečného stavu.
S touto konfigurací se hardwarový hlídací časovač resetuje každých N sekund, pokud nedojde ke ztrátě kvora. Pokud časovač (obvykle několik násobků N) vyprší, zařízení provede nešetrné vypnutí (nikoli vypnutí).
Tento přístup je velmi efektivní, ale bez kvora není v klastru dostatek informací pro jeho správu. Není snadné rozeznat rozdíl mezi výpadkem sítě a selháním peer uzlu. Důvodem je to, že bez schopnosti rozlišovat mezi dvěma případy jste nuceni zvolit stejné chování v obou případech.
Problém s výběrem jednoho režimu spočívá v tom, že neexistuje žádný postup, který by maximalizoval dostupnost a zabránil ztrátě dat.
- Pokud se rozhodnete předpokládat, že partnerský uzel je aktivní, ale ve skutečnosti selže, cluster zbytečně zastaví služby, které by byly spuštěny, aby kompenzoval ztrátu služeb z neúspěšného uzlu rovnocenného partnera.
- Pokud se rozhodnete předpokládat, že uzel je mimo provoz, ale šlo pouze o selhání sítě a ve skutečnosti je vzdálený uzel funkční, pak se v nejlepším případě přihlašujete k nějakému budoucímu ručnímu odsouhlasení výsledných datových sad.
Bez ohledu na to, jakou heuristiku používáte, je triviální vytvořit selhání, které buď způsobí selhání obou stran, nebo způsobí, že cluster vypne přežívající uzly. Nepoužití kvora skutečně připravuje cluster o jeden z nejvýkonnějších nástrojů v jeho arzenálu.
Pokud neexistuje jiná alternativa, nejlepším přístupem je obětovat dostupnost (zde autor odkazuje na větu CAP). Vysoká dostupnost poškozených dat nikomu nepomáhá a ani ruční sladění různých datových sad není legrace.
Kvorum
Kvorum zní skvěle, že?
Jedinou nevýhodou je, že abyste to měli v clusteru s N členy, musíte mít spojení mezi N/2+1 zbývajícími uzly. Což není možné v clusteru se dvěma uzly poté, co jeden uzel selže.
Což nás nakonec přivádí k základnímu problému se dvěma uzly:
Kvorum nedává smysl ve dvou clusterech uzlů a bez něj nelze spolehlivě určit postup, který maximalizuje dostupnost a zabraňuje ztrátě dat
Ani v systému dvou uzlů propojených kříženým kabelem nelze definitivně rozlišit mezi výpadkem sítě a poruchou druhého uzlu. Vypnutí jednoho konce (jehož pravděpodobnost je samozřejmě úměrná vzdálenosti mezi uzly) bude stačit k vyvrácení jakéhokoli předpokladu, že zdraví spoje se rovná zdraví partnerského uzlu.
Zprovoznění clusteru se dvěma uzly
Někdy klient nemůže nebo nechce zakoupit třetí uzel a my jsme nuceni hledat alternativu.
Možnost 1 – Duplicitní metoda disociace
Zařízení iLO nebo IPMI uzlu představuje bod selhání, protože pokud selže, přeživší je nemohou použít k uvedení uzlu do bezpečného stavu. Ve shluku 3 nebo více uzlů to můžeme zmírnit výpočtem kvora a použitím hardwarového hlídacího psa (mechanismus nepřímé disociace, jak bylo uvedeno výše). V případě dvou uzlů musíme místo toho použít síťové napájecí distribuční jednotky (PDU).
Po selhání se přeživší nejprve pokusí kontaktovat primární disociační zařízení (embedded iLO nebo IPMI). Pokud je to úspěšné, obnova pokračuje jako obvykle. Pouze pokud zařízení iLO/IPMI selže, je přístup k PDU; pokud je přístup úspěšný, obnova může pokračovat.
Ujistěte se, že PDU umístíte do jiné sítě, než je provoz clusteru, jinak jediné selhání sítě zablokuje přístup k oběma zařízením pro oddělení a zablokuje obnovení služeb.
Zde se můžete zeptat - je PDU jediným bodem selhání? Na což je odpověď, samozřejmě, že je.
Pokud je pro vás toto riziko významné, nejste sami: připojte oba uzly ke dvěma PDU a řekněte klastrovacímu softwaru, aby při zapínání a vypínání uzlů používal oba. Cluster nyní zůstane aktivní, pokud dojde k výpadku jednoho PDU, a k zablokování obnovy bude nutné druhé selhání druhého PDU nebo zařízení IPMI.
Možnost 2 – Přidání arbitra
V některých scénářích, zatímco metoda duplicitní disociace je technicky možná, je politicky obtížná. Mnoho společností má rádo určité oddělení mezi správci a vlastníky aplikací a správci sítí dbající na bezpečnost nejsou vždy nadšení ze sdílení nastavení přístupu PDU s kýmkoli.
V tomto případě je doporučenou alternativou vytvoření neutrální třetí strany, která může doplnit výpočet kvora.
V případě selhání musí být uzel schopen vidět vysílání svého partnera nebo arbitra, aby mohl obnovit služby. Arbiter také obsahuje funkci odpojení, pokud oba uzly vidí arbitra, ale nevidí se navzájem.
Tato možnost musí být použita ve spojení s metodou nepřímého oddělování, jako je hardwarový hlídací časovač, který je nakonfigurován tak, aby zabil počítač, pokud ztratí spojení s uzlem peer a arbitrer. Přeživší tedy může rozumně předpokládat, že jeho peer uzel bude po vypršení hardwarového hlídacího časovače v zabezpečeném stavu.
Praktický rozdíl mezi arbitrem a třetím uzlem je v tom, že arbitr vyžaduje mnohem méně zdrojů k provozu a může potenciálně obsluhovat více než jeden cluster.
Možnost 3 – Lidský faktor
Konečným přístupem je, aby přeživší pokračovali ve spouštění jakýchkoli služeb, které již spouštěli, ale nespouštěli nové, dokud se problém nevyřeší sám (obnovení sítě, restartování uzlu) nebo osoba převezme odpovědnost za ruční potvrzení, že druhá strana je mrtvá.
Možnost bonusu
Zmínil jsem se, že můžete přidat třetí uzel?
Dva stojany
Pro argumentaci předstírejme, že jsem vás přesvědčil o přednostech třetího uzlu, nyní musíme zvážit fyzické uspořádání uzlů. Pokud jsou umístěny (a napájeny) ve stejném stojanu, představuje to také SPoF, které nelze vyřešit přidáním druhého stojanu.
Pokud je to překvapivé, zvažte, co by se stalo, kdyby selhal rack se dvěma uzly, a jak by přeživší uzel rozlišil mezi tím a selháním sítě.
Krátká odpověď je, že to není možné, a opět se zabýváme všemi problémy v případě dvou uzlů. Nebo přeživší:
- ignoruje kvorum a nesprávně se pokouší zahájit obnovu během výpadků sítě (schopnost dokončit disociaci je jiný příběh a závisí na tom, zda je zapojena PDU a zda sdílí napájení s některým ze stojanů), nebo
- respektuje kvorum a předčasně se odpojí, když jeho partnerský uzel selže
V každém případě dva stojany nejsou o nic lepší než jeden a uzly musí buď přijímat nezávislé napájecí zdroje, nebo být rozděleny do tří (nebo více, v závislosti na tom, kolik uzlů máte) stojanů.
Dvě datová centra
V tomto okamžiku mohou čtenáři, kteří již nemají averzi k riziku, zvážit zotavení po havárii. Co se stane, když asteroid zasáhne stejné datové centrum s našimi třemi uzly rozmístěnými ve třech různých stojanech? Zjevně špatné věci, ale v závislosti na vašich potřebách nemusí přidání druhého datového centra stačit.
Pokud se to udělá správně, druhé datové centrum vám poskytne (a přiměřeně) aktuální a konzistentní kopii vašich služeb a jejich dat. Stejně jako ve scénářích se dvěma uzly a dvěma stojany však v systému není dostatek informací k zajištění maximální dostupnosti a zabránění poškození (nebo nesrovnalostem v sadě dat). Dokonce i se třemi uzly (nebo stojany) jejich distribuce pouze do dvou datových center způsobí, že systém nebude schopen spolehlivě učinit správné rozhodnutí v případě (nyní mnohem pravděpodobnější) události, kdy obě strany nemohou komunikovat.
To neznamená, že duální řešení datového centra není nikdy vhodné. Společnosti často chtějí, aby si byl člověk vědom, než učiní mimořádný krok, kterým je přesun do záložního datového centra. Jen mějte na paměti, že pokud chcete výpadek automatizovat, budete buď potřebovat třetí datové centrum, aby kvorum dávalo smysl (buď přímo, nebo prostřednictvím arbitra), nebo najdete způsob, jak spolehlivě vypnout celá data centrum.
Zdroj: www.habr.com