Ahoj, Habr! Predstavujem vám preklad článku autora Andrewa Beekhoffa.
Mnohí ľudia uprednostňujú klastre pozostávajúce z dvoch uzlov, pretože sa javia konceptuálne jednoduchšie a sú navyše o 33 % lacnejšie ako ich trojuzlové náprotivky. Aj keď je celkom reálne zostaviť dobrý klaster z dvoch uzlov, v mnohých prípadoch, kvôli nezohľadneným scenárom, takáto konfigurácia vytvorí množstvo nejasných problémov.
Prvým krokom k vytvoreniu akejkoľvek vysoko dostupnej systému je identifikácia a snaženie sa odstrániť jednotlivé body zlyhania, často skrátene nazývané SPoF (single point of failure).
Je potrebné mať na pamäti, že v žiadnom systéme nie je možné eliminovať všetky možné riziká výpadku. To vyplýva aspoň z toho, že typickou ochranou pred rizikom je zavedenie určitej nadbytočnosti, čo vedie k zvýšeniu zložitosti systému a vzniku nových zlyhaní. Preto zo začiatku ideme na kompromis a sústreďujeme sa na udalosti vzťahujúce sa na jednotlivé body zlyhania, a nie na reťazce súvisiacich a teda čoraz menej pravdepodobných udalostí.
Zohľadňujúc kompromisy, nielenže hľadáme SPoF, ale tiež vyvažujeme riziká a následky, čo vedie k záveru, že to, čo je kritické, a čo nie, sa môže líšiť pre každé nasadenie.
Nie všetkým sú potrební alternatívni dodávatelia elektriny s nezávislými elektrickými líniami. Hoci paranoia sa vyplatila aspoň pre jedného klienta, keď ich monitoring odhalil chybný transformátor. Zákazník volal, snažiac sa upozorniť energetickú spoločnosť, kým chybný transformátor nevybuchol.
Prirodzeným východiskovým bodom je mať v systéme viac ako jeden uzol. Avšak predtým, než systém môže presunúť služby na zostávajúci uzol po výpadku, vo všeobecnosti je potrebné zabezpečiť, že presúvané služby nie sú aktívne na inom mieste.
Dvojuzlový klaster nemá nevýhody, ak v prípade zlyhania oba uzly obsluhujú rovnakú statickú webovú stránku. Avšak všetko sa mení, ak obe strany nezávisle spravujú spoločnú frontu úloh alebo poskytujú nekoordinovaný prístup na zápis do replikovanej databázy alebo spoločnej súborovej sústavy.
Preto, aby sme predišli poškodeniu údajov v dôsledku zlyhania jedného uzla – spoliehame sa na to, čo sa nazýva „oddelenie“ (fencing).
Princíp oddelenia
Základným otázkou princípu oddelenia je: môže konkurenčný uzol spôsobiť poškodenie údajov? Ak je poškodenie údajov pravdepodobným scenárom – dobrým riešením bude izolovať uzol od prichádzajúcich požiadaviek, ako aj od trvalého úložiska. Najrozšírenejším prístupom k oddeleniu je odpojenie poruchových uzlov.
Existujú dve kategórie metód oddelenia, ktoré nazvem priamymi a nepriamymi, ale rovnako ich možno nazvať aktívnymi a pasívnymi. Priame metódy zahŕňajú činnosti zo strany prežívajúcich rovnocenných uzlov, ako je interakcia s zariadením IPMI (Intelligent Platform Management Interface – rozhranie na vzdialené monitorovanie a správu fyzického stavu servera) alebo iLO (mechanizmus správy serverov v podmienkach nedostatku fyzického prístupu k nim), zatiaľ čo nepriamé metódy sa spoliehajú na zlyhávajúci uzol, aby nejakým spôsobom spoznal, že je v nezdravom stave (alebo aspoň bráni ostatným členom v regenerácii) a signalizoval o potrebe odpojiť zlyhávajúci uzol.
Kvorum pomáha pri používaní ako priamych, tak aj nepriamych metód.
Priame oddelenie
V prípade priameho oddelenia môžeme použiť kvorum na zabránenie pretečeniu oddelenia v prípade zlyhania siete.
S koncepciou kvorumu má systém dostatok informácií (aj bez pripojenia k svojim partnerom), aby uzly automaticky vedeli, či by mali iniciovať oddelenie a / alebo obnovu.
Bez kvorumu majú obidve strany sieťového rozdelenia oprávnenú predstavu, že druhá strana je mŕtva, a budú sa snažiť oddeliť druhého. V najhoršom prípade sa obom stranám podarí odpojiť celý klaster. Alternatívny scenár – deathmatch, nekonečný cyklus uzlov, ktoré sa objavujú, nevidia svojich partnerov, reštartujú ich a iniciujú obnovu len preto, aby sa reštartovali, keď ich partner prejde rovnakou logikou.
Problém s oddelením spočíva v tom, že najčastejšie používané zariadenia sa stávajú nedostupnými kvôli tým istým udalostiam zlyhania, na ktoré sa chceme zamerať pri obnove. Väčšina IPMI a iLO kariet je nainštalovaná na hostiteľoch, ktoré kontrolujú, a predvolene používajú tú istú sieť, čo spôsobuje, že cieľové uzly predpokladajú, že ostatné uzly sú offline.
Žiaľ, vlastnosti fungovania zariadení IPMI a iLO sa zriedka posudzujú v momente nákupu vybavenia.
Nepriamé oddelenie
Kvorum je tiež dôležité na riadenie nepriamych oddelení. Ak je všetko správne nastavené, kvorum môže umožniť preživším predpokladať, že stratené uzly prejdú do bezpečného stavu po určitom čase.
Pri tomto nastavení sa hardvérový watchdog timer resetuje každých N sekúnd, ak nedôjde k strate kvoru. Ak timer (zvyčajne niekoľko násobkov N) uplynie, zariadenie vykoná nešetrné vypnutie napájania (nie shutdown).
Tento prístup je veľmi efektívny, ale bez kvoru na jeho riadenie nie sú v rámci klastra dostatočné informácie. Nie je ľahké rozlíšiť medzi odpojením siete a zlyhaním uzla partnera. Dôvod, prečo to má význam, spočíva v tom, že bez možnosti rozlišovať medzi týmito dvoma prípadmi musíte zvoliť rovnaký spôsob správania v oboch prípadoch.
Problém s voľbou jedného režimu spočíva v tom, že neexistuje spôsob, ako maximalizovať dostupnosť a zabrániť strate dát.
- Ak sa rozhodnete predpokladať, že uzol partnera je aktívny, ale v skutočnosti došlo k zlyhaniu, klaster nadmerne zastaví služby, ktoré by mali fungovať na kompenzáciu straty služieb zlyhávajúceho uzla partnera.
- Ak sa rozhodnete predpokladať, že uzol nefunguje, ale išlo len o zlyhanie siete a skutočne vzdialený uzol funguje, potom sa, najlepšie, prihlásite na niektoré budúce manuálne porovnanie výsledných súborov dát.
Nezáleží na tom, akú heuritiku použijete, je triviálne vytvoriť zlyhanie, ktoré spôsobí, že obidve strany budú fungovať, alebo spôsobí, že klaster vypne prežívajúce uzly. Nepoužitie kvoru naozaj zbavuje klaster jedného z najvýkonnejších nástrojov vo svojom arzenáli.
Ak neexistuje iná alternatíva, najlepším prístupom je obetovať dostupnosť (tu autor odkazuje na CAP teóriu). Vysoká dostupnosť poškodených údajov nikomu nepomôže a ručné overenie rôznych súborov údajov tiež nie je príjemné.
Kvórum
Kvórum znie výborne, však?
Jedinou nevýhodou je, že na to, aby ste ho mali v klastre s N členmi, musíte mať pripojenie medzi N / 2 + 1 vašimi uzlami. Čo nie je možné v dvojuzlovom klastri po zlyhaní jedného uzla.
Čo nás nakoniec privádza k základnému problému s dvoma uzlami:
kvórum nedáva zmysel v dvojuzlových klastroch a bez neho nie je možné spoľahlivo určiť postup, ktorý maximálne zvyšuje dostupnosť a zabraňuje strate údajov.
Aj v systéme so spoločným pripojením dvoch uzlov je nemožné definitívne rozlíšiť medzi výpadkom siete a zlyhaním druhého uzla. Výpadok na jednom konci (ktorého pravdepodobnosť je nepochybne úmerná vzdialenosti medzi uzlami) stačí na vyvrátenie akéhokoľvek predpokladu, že funkčnosť kanála sa rovná zdraviu partnerského uzla.
Fungovanie klastra z dvoch uzlov
Niekedy klient nemôže alebo nechce dokúpiť tretí uzol a musíme hľadať alternatívu.
Možnosť 1 — Duplicita metódy zlyhania
Zariadenie iLO alebo IPMI uzla je bod zlyhania, pretože v prípade zlyhania zvyšné uzly nemôžu použiť na prepnutie uzla do bezpečného stavu. V klastri s 3 alebo viac uzlami môžeme toto zmierniť výpočtom kvóra a použitím hardwarového watchdogu (mechanizmus nepriamého zlyhania, ako bolo predtým diskutované). V prípade dvoch uzlov musíme namiesto toho použiť sieťové rozvádzače napájania (power distribution units alebo PDUs).
Po zlyhaní sa preživší najprv pokúša skontaktovať s primárnym zariadením na zlyhanie (vpínané iLO alebo IPMI). Ak sa mu to podarí, obnova pokračuje ako zvyčajne. Iba v prípade zlyhania zariadenia iLO / IPMI sa obrátia na PDU, ak je kontakt úspešný, obnova môže pokračovať.
Určite umiestnite PDU do siete, ktorá je odlišná od klastrového prenosu, inak jediný výpadok siete zablokuje prístup ako k zariadeniam odmeňovania, tak aj zablokuje obnovenie služieb.
Tu sa môžete opýtať – nie je zariadenie PDU jediným bodom zlyhania? Odpoveď znie – určite je.
Ak je toto riziko pre vás významné – nie ste sami: pripojte oba uzly k dvom PDU a nastavte klastrovému softvéru, aby používal oba pri zapínaní a vypínaní uzlov. Teraz klaster zostáva aktívny, ak jeden PDU zlyhá, a na zablokovanie obnovenia je potrebný druhý výpadok buď druhého PDU, alebo zariadenia IPMI.
Možnosť 2 – Pridanie arbitra
V niektorých scenároch, aj keď technicky je možná metóda duplikovaného odmeňovania, je politicky zložitá. Mnohým spoločnostiam sa páči mať určité rozdelenie medzi administrátormi a vlastníkmi aplikácií, a sieťoví administrátori, ktorí sa zaujímajú o bezpečnosť, nie vždy s nadšením prenechávajú komukoľvek prístupové parametre k PDU.
V tomto prípade je odporúčanou alternatívou vytvorenie neutrálnych tretích strán, ktoré môžu doplniť výpočet kvóra.
V prípade výpadku by mal uzol byť schopný vidieť ether svojho partnera alebo arbitra, aby obnovil služby. Arbitra tiež zahŕňa funkciu prerušenia spojenia, ak oba uzly môžu vidieť arbitra, ale nevidia sa navzájom.
Táto možnosť by sa mala používať v páre s nepriamou metódou odmeňovania, ako je hardvérový watchdog časovač, ktorý je nastavený na vypnutie stroja, ak stratí spojenie so svojím partnerom a arbitrom. Takže prežívajúci môže s dostatočnou istotou predpokladať, že jeho partner bude v bezpečnom stave po uplynutí doby platnosti hardvérového watchdog časovača.
Praktický rozdiel medzi arbitrom a tretím uzlom spočíva v tom, že arbiter vyžaduje oveľa menej zdrojov na svoju činnosť a potenciálne môže obsluhovať viac ako jeden klaster.
Možnosť 3 – Ľudský faktor
Posledný prístup spočíva v tom, že prežívajúci naďalej vykonávajú akékoľvek služby, ktoré už vykonávali, ale nespúšťajú nové, kým sa problém nevyrieši sám (obnovenie siete, reštart uzlu), alebo kým si niekto neprevezme zodpovednosť za ručné potvrdenie, že druhá strana je mŕtva.
Bonusová možnosť
Hovoril som už, že môžete pridať tretí uzol?
Dve skrine
Pre argumentáciu si predstavme, že som vás presvedčil o výhodách tretieho uzla, teraz musíme zvážiť fyzické umiestnenie uzlov. Ak sú umiestnené (a napájané) v tej istej skrini, to sa tiež považuje za SPoF, a to tak, že sa to nedá vyriešiť pridaním druhej skrine.
Ak je to prekvapujúce, zamyslite sa nad tým, čo sa stane, ak skrinka s dvoma uzlami zlyhá, a ako prežívajúci uzol bude rozlišovať medzi týmto prípadom a zlyhaním siete.
Krátka odpoveď: je to nemožné a opäť sa zaoberáme všetkými problémami, ktoré sú spojené s dvoma uzlami. Buď prežívajúci:
- ignoruje kvórum a nesprávne sa pokúša iniciovať obnovenie počas výpadkov siete (možnosť dokončenia odpojenia — to je iný príbeh a závisí od toho, či je zapojený PDU a či zdieľajú napájanie s niektorou zo skríň), alebo
- respektuje kvórum a predčasne sa odpojí, keď jeho partner-uzol zlyhá
V každom prípade, dve skrine nie sú lepšie ako jedna, a uzly by mali buď dostávať nezávislé zdroje napájania, alebo byť rozložené na troch (alebo viacerých, v závislosti od toho, koľko máte uzlov) skrín.
Dva dátové centrá
V tomto bode si čitatelia, ktorí už nie sú naklonení riziku, môžu pomyslieť na zotavenie po havárii. Čo sa stane, keď asteroid zasiahne jedno dátové centrum s našimi tromi uzlami rozloženými na troch rôznych skríňach? Je jasné, že zlé veci, ale v závislosti od vašich potrieb, pridanie druhého dátového centra nemusí byť dosť.
Ak všetko prebehlo správne, druhé dátové centrum vám (a to je rozumné) poskytuje aktuálnu a konzistentnú kópiu vašich služieb a ich dát. Avšak, rovnako ako v scenároch s dvoma uzlami a dvoma stojanmi, v systéme nie je dosť informácií na zabezpečenie maximálnej dostupnosti a zabránenie poškodeniu (alebo odlišnostiam súborov dát). Aj s tromi uzlami (alebo stojanmi) ich rozmiestnenie len po dvoch dátových centrách ponecháva systém neschopným spoľahlivo prijať správne rozhodnutie v prípade (teraz oveľa pravdepodobnejšom) incidentu, ktorý obe strany nedokážu prepojiť.
To neznamená, že riešenie s dvoma dátovými centrami nikdy nie je vhodné. Spoločnosti často chcú, aby bola osoba informovaná predtým, ako sa podnikne výnimočný krok pri prechode na záložné dátové centrum. Jednoducho majte na pamäti, že ak chcete automatizovať výpadok, budete potrebovať buď tretie dátové centrum, aby mal kvorum zmysel (priamo alebo prostredníctvom arbitra), alebo musíte nájsť spôsob, ako spoľahlivo odpojiť celé dátové centrum.
Zdroj: habr.com
