Ahoj, Habr! Představuji vám překlad článku autor Andrew Beekhof.
Mnoho lidí dává přednost clusterům tvořeným ze dvou uzlů, protože se zdají být konceptuálně jednodušší a navíc jsou o 33 % levnější než jejich tříuzlové protějšky. Ačkoli je možné sestavit dobrý cluster ze dvou uzlů, v mnoha případech tato konfigurace, kvůli nevyřešeným scénářům, vytvoří řadu neviditelných problémů.
Prvním krokem k vytvoření jakéhokoli systému s vysokou dostupností je hledat a pokusit se odstranit jednotlivé body selhání, často zkráceně nazývané SPoF (single point of failure).
Je třeba mít na paměti, že v jakémkoli systému není možné eliminovat všechny možné rizika výpadku. To vyplývá alespoň z faktu, že typickou ochranou proti riziku je zavedení určité redundantnosti, což zvyšuje složitost systému a vytváří nové body selhání. Proto již na začátku jsme ochotni vyjednávat a soustředíme se na události související s jednotlivými body selhání, nikoli na související a tudíž stále méně pravděpodobné události.
Vzít v úvahu kompromisy, hledáme nejen SPoF, ale také vyvažujeme rizika a důsledky, což znamená, že závěry o tom, co je kritické, mohou být pro každé nasazení odlišné.
Ne všichni potřebují alternativní dodavatele energie s nezávislými elektropřenosovými liniemi. Ačkoli paranoidní přístup se vyplatil alespoň jednomu klientovi, když jejich monitoring odhalil vadný transformátor. Zákazník volal a snažil se varovat energetickou společnost, dokud se vadný transformátor nevybuchl.
Přirozeným výchozím bodem je mít v systému více než jeden uzel. Nicméně, než systém bude moci přesunout služby na zbývající živý uzel po selhání, v zásadě je třeba zajistit, že přesouvané služby nejsou aktivní na jiném místě.
Dvouuzlový cluster nemá nevýhody, pokud při selhání oba uzly obsluhují stejnou statickou webovou stránku. Nicméně všechno se mění, pokud obě strany nezávisle spravují společnou frontu úloh nebo poskytují nekoordinovaný přístup pro zápis k replikované databázi nebo sdílenému souborovému systému.
Proto, abyste zabránili poškození dat v důsledku selhání jednoho uzlu, spoléháme se na to, co se nazývá „odizolování“ (fencing).
Princip odizolování
Základním otázkou principu odizolování je, zda může konkurenční uzel způsobit poškození dat. Pokud je poškození dat pravděpodobným scénářem, je dobrým řešením izolace uzlu jak od příchozích požadavků, tak od trvalého úložiště. Nejběžnějším přístupem k odizolování je odpojení vadných uzlů.
Existují dvě kategorie metod odizolování, které nazvu přímé a nepřímé, ale v rovné míře je lze nazvat aktivními a pasivními. Přímé metody zahrnují akce přeživších rovnocenných uzlů, jako je interakce s zařízeními IPMI (Intelligent Platform Management Interface — rozhraní pro vzdálené sledování a správu fyzického stavu serveru) nebo iLO (mechanismus správy serverů v podmínkách absence fyzického přístupu k nim), zatímco nepřímé metody spoléhají na selhávající uzel, aby nějak rozpoznal, že se nachází v nezdravém stavu (nebo alespoň brání ostatním členům v obnově) a signalizoval o nutnosti odpojení selhávajícího uzlu.
Kvorum pomáhá v případě použití jak přímých, tak nepřímých metod.
Přímé odizolování
V případě přímého odizolování můžeme použít kvorum k prevenci závodů odizolování v případě selhání sítě.
Při zavedení konceptu kvorum má systém dostatek informací (i bez připojení k partnerům), aby uzly automaticky věděly, zda by měly iniciovat odizolování a/nebo obnovu.
Bez kvorum si obě strany síťového rozdělení oprávněně předpokládají, že druhá strana je mrtvá, a budou usilovat o odizolování druhého. V nejhorším případě se obě strany podaří odpojit celý cluster. Alternativním scénářem je deathmatch, nekonečný cyklus uzlů, které se objevují, nevidí své protějšky, restartují je a iniciují obnovu jen proto, aby se restartovaly, když jejich protějšek projde stejnou logikou.
Problém s odškrtáním spočívá v tom, že nejčastěji používaná zařízení se stávají nedostupnými kvůli stejným událostem selhání, na které se chceme zaměřit pro obnovení. 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é uzly se domnívají, že ostatní uzly jsou offline.
Bohužel se zvláštnosti funkce zařízení IPMI a iLo zřídka zvažují v okamžiku nákupu hardwaru.
Nepřímé odškrtání
Kvorum je také důležité pro správu nepřímých odškrtání; pokud je vše dobře nastaveno, kvorum může umožnit přeživším předpokládat, že ztracené uzly se po určité době dostanou do bezpečného stavu.
Při takovém nastavení se hardware watchdog resetuje každých N sekund, pokud není ztraceno kvorum. Pokud časovač (obvykle několikrát N) vyprší, zařízení provede nešetrné vypnutí napájení (ne shutdown).
Tento přístup je velmi efektivní, ale bez kvorum pro jeho správu však uvnitř klastru chybí dostatek informací. Není snadné rozlišit mezi odpojením sítě a selháním uzlu-partnera. Důvod, proč na tom záleží, spočívá v tom, že bez možnosti rozlišovat mezi těmito dvěma případy musíte zvolit stejný režim chování v obou situacích.
Problém s výběrem jednoho režimu spočívá v tom, že neexistuje žádný způsob, jak postupovat, který by maximalizoval dostupnost a zabránil ztrátě dat.
- Pokud se rozhodnete předpokládat, že uzel-partner je aktivní, ale ve skutečnosti došlo k selhání, klastr zbytečně zastaví služby, které by měly fungovat kvůli kompenzaci ztráty služeb selhaného uzlu-partnera.
- Pokud se rozhodnete předpokládat, že uzel nefunguje, ale šlo pouze o selhání sítě a ve skutečnosti vzdálený uzel funguje, pak se v lepším případě zavazujete k budoucí ruční kontrole výsledných datových sad.
Bez ohledu na to, jakou heuristiku používáte, je triviální vytvořit selhání, které buď donutí obě strany pracovat, nebo přiměje klastr vypnout přeživší uzly. Nepoužívání kvorum skutečně zbavuje klastr jednoho z nejmocnějších nástrojů ve svém arzenálu.
Pokud neexistuje jiná alternativa, nejlepší přístup je obětovat dostupnost (autor odkazuje na CAP teorém). Vysoká dostupnost poškozených dat nikomu nepomáhá a ruční kontrola různých datových sad také není příjemná.
Kvórum
Kvórum zní skvěle, že?
Jedinou nevýhodou je, že aby bylo možné mít jej ve shluku s N členy, je třeba, aby zůstalo připojení mezi N / 2 + 1 vašich uzlů. Což je nemožné ve shluku se dvěma uzly po selhání jednoho uzlu.
Co nás nakonec přivádí k základnímu problému se dvěma uzly:
kvórum nemá smysl ve dvouuzlových clusterech a bez něj není možné spolehlivě určit postup, který maximalizuje dostupnost a zabraňuje ztrátě dat.
I v systému se dvěma uzly spojenými křížovým kabelem není možné konečně rozlišit mezi odpojením sítě a selháním druhého uzlu. Odpojení jednoho konce (jehož pravděpodobnost je bezpochyby úměrná vzdálenosti mezi uzly) bude stačit k vyvrácení jakéhokoli předpokladu, že provozuschopnost kanálu se rovná zdraví partnerského uzlu.
Přimět k fungování cluster ze dvou uzlů
Někdy klient nemůže nebo nechce dokoupit třetí uzel a jsme nuceni hledat alternativu.
Varianta 1 — Duplicitní metoda rozpojení
Zařízení iLO nebo IPMI uzlu představuje bod selhání, protože v případě výpadku jej zbývající uzly nemohou použít k přepnutí uzlu do bezpečného stavu. V clusteru se 3 nebo více uzly můžeme tuto situaci zmírnit výpočtem kvórum a využitím hardware watchdog (mechanismus nepřímého odpojení, jak bylo diskutováno dříve). V případě dvou uzlů musíme místo toho použít přepínače napájení (power distribution units nebo PDUs).
Po selhání se přeživší nejprve pokouší navázat spojení s hlavním rozpojeným zařízením (integrovaným iLO nebo IPMI). Pokud se to podaří, obnova pokračuje jako obvykle. Pouze v případě selhání zařízení iLO / IPMI dojde k dotazu na PDU, pokud je dotaz úspěšný, může obnova pokračovat.
PDU umístěte do sítě oddělené od provozu clusteru, jinak může jediné selhání sítě zablokovat přístup jak k zařízením k dispozici, tak k obnovení služeb.
Můžete se ptát – je zařízení PDU jediným bodem selhání? Odpověď zní — samozřejmě, že je.
Pokud je toto riziko pro vás významné — nejste sami: připojte oba uzly k dvěma PDU a nastavte clusterový software, aby používal obě při zapínání a vypínání uzlů. Nyní zůstává cluster aktivní, pokud jedno PDU selže, a pro zablokování obnovy bude potřebovat druhé selhání buď jiného PDU, nebo zařízení IPMI.
Varianta 2 — Přidání arbitra
V některých scénářích, ačkoliv je technicky možné použít metodu duálního odměřování, je to politicky složité. Mnoho firem dává přednost určitému rozdělení mezi správci a vlastníky aplikací, a síťoví administrátoři, kteří se starají o bezpečnost, ne vždy s nadšením předávají přístupové parametry k PDU někomu jinému.
V tomto případě je doporučenou alternativou vytvořit neutrální třetí stranu, která může doplnit výpočet kvoru.
V případě selhání musí mít uzel možnost vidět svůj protějšek nebo arbitra, aby bylo možné obnovit služby. Arbitra také zahrnuje funkci přerušení spojení, pokud oba uzly mohou vidět arbitra, ale nevidí se navzájem.
Tato volba by měla být používána v páru s nepřímou metodou odměřování, jako je hardware watchdog časovač, který je nastaven na vypnutí stroje, pokud ztratí spojení se svým uzlem-partnerem a arbitrem. Tímto způsobem může přeživší s dostatečnou jistotou předpokládat, že jeho uzel-partner bude v bezpečném stavu po uplynutí doby platnosti hardware watchdog časovače.
Praktický rozdíl mezi arbitrem a třetím uzlem spočívá v tom, že arbitr vyžaduje mnohem méně zdrojů pro svoji činnost a potenciálně může obsluhovat více než jeden cluster.
Varianta 3 — Lidský faktor
Poslední přístup spočívá v tom, že přeživší pokračují v plnění jakýchkoli služeb, které již vykonávali, ale nezačnou nové, dokud se problém nevyřeší sám (obnovení sítě, restart uzlu) nebo dokud si někdo nepřevezme odpovědnost za ruční potvrzení, že druhá strana je mrtvá.
Bonusová možnost
Už jsem zmínil, že můžete přidat třetí uzel?
Dvě stojany
Pro argumentaci si představme, že jsem vás přesvědčil o výhodách třetího uzlu, nyní musíme zvážit fyzické umístění uzlů. Pokud jsou umístěny (a napájeny) ve stejném stojanu, představuje to také SPoF, což nelze vyřešit přidáním druhého stojanu.
Pokud je to překvapující, zamyslete se, co se stane, pokud se stojan se dvěma uzly porouchá, a jak přeživší uzel rozlišuje tuto situaci a selhání sítě.
Krátká odpověď: to není možné, a opět čelíme všem problémům spojeným se dvěma uzly. Buď přeživší:
- ignoruje kvórum a nesprávně se pokouší zahájit obnovu během výpadků sítě (možnost dokončení oddělení je jiný příběh a závisí na tom, zda je zapojen PDU a zda sdílejí napájení s některým z stojanů), nebo
- respektuje kvórum a předčasně se odpojí, když jeho partnerský uzel selže
V každém případě dvě stojany nejsou lepší než jeden a uzly by měly buď získávat nezávislé zdroje napájení, nebo být rozloženy do tří (nebo více, v závislosti na tom, kolik uzlů máte) stojanů.
Dvě datacentra
V tuto chvíli si čtenáři, kteří už nemají sklon k riziku, mohou začít uvědomovat obnovu po havárii. Co se stane, když asteroid zasáhne jedno datové centrum s našimi třemi uzly rozmístěnými ve třech různých stojanech? Je jasné, že špatné věci, ale v závislosti na vašich potřebách může být přidání druhého datacentra nedostatečné.
Pokud je vše nastaveno správně, druhé datové centrum vám (a to je rozumné) poskytuje aktuální a konzistentní kopii vašich služeb a jejich dat. Nicméně, stejně jako ve scénářích se dvěma uzly a dvěma racky, systém nemá dostatek informací, aby zajistil maximální dostupnost a předešel poškození (nebo nesouladu datových sad). I s třemi uzly (nebo racky) jejich rozložení pouze do dvou datových center ponechává systém neschopný spolehlivě učinit správné rozhodnutí v případě (nyní mnohem pravděpodobnějšího) incidentu, který obě strany nemohou utlumit.
To neznamená, že řešení se dvěma datovými centry nikdy není vhodné. Společnosti často chtějí, aby byl někdo informován, než učiní výjimečný krok k přechodu na záložní datové centrum. Jen mějte na paměti, že pokud chcete automatizovat selhání, budete potřebovat buď třetí datové centrum, aby quorum dávalo smysl (buď přímo, nebo prostřednictvím arbitra), nebo najdete způsob, jak spolehlivě odpojit celé datové centrum.
Zdroj: habr.com
