Čau Habr! Do pozornosti dávam preklad článku od Andrewa Beekhofa.
Mnoho ľudí uprednostňuje dvojuzlové klastre, pretože sa zdajú koncepčne jednoduchšie a sú tiež o 33 % lacnejšie ako ich trojuzlové náprotivky. Aj keď je celkom možné poskladať dobrý zhluk dvoch uzlov, vo väčšine prípadov takáto konfigurácia spôsobí kvôli neuváženým scenárom veľa nezrejmých problémov.
Prvým krokom k vytvoreniu akéhokoľvek systému vysokej dostupnosti je nájsť a pokúsiť sa odstrániť jednotlivé body zlyhania, často označované skratkou SPoF (jediný bod zlyhania).
Je potrebné mať na pamäti, že v žiadnom systéme nie je možné eliminovať všetky možné riziká prestojov. Vyplýva to zo skutočnosti, že typickou obranou proti riziku je zavedenie určitej redundancie, čo vedie k zvýšenej zložitosti systému a vzniku nových bodov zlyhania. Preto spočiatku robíme kompromis a zameriavame sa na udalosti spojené s jednotlivými bodmi zlyhania, a nie na reťazce súvisiacich, a teda čoraz menej pravdepodobných udalostí.
Vzhľadom na kompromisy nehľadáme len SPoF, ale aj vyvažujeme riziká a dôsledky, v dôsledku čoho sa závery o tom, čo je kritické a čo nie, môžu pri každom nasadení líšiť.
Nie každý potrebuje alternatívnych dodávateľov elektriny s nezávislými elektrickými vedeniami. Paranoja sa síce vyplatila minimálne jednému zákazníkovi, keď ich monitoring odhalil chybný transformátor. Zákazník telefonoval a snažil sa upozorniť elektrárenskú 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, ako systém môže po zlyhaní presunúť služby do prežívajúceho uzla, musí sa vo všeobecnosti uistiť, že presúvané služby nie sú aktívne inde.
Neexistuje žiadna nevýhoda klastra s dvoma uzlami, ak zlyhanie spôsobí, že oba uzly obsluhujú rovnakú statickú webovú lokalitu. Veci sa však zmenia, ak výsledkom je, že obe strany nezávisle spravujú zdieľaný front úloh alebo poskytujú nekoordinovaný prístup k zápisu do replikovanej databázy alebo zdieľaného súborového systému.
Preto, aby sme zabránili poškodeniu údajov v dôsledku zlyhania jedného uzla - spoliehame sa na niečo tzv "disociácia" (oplotenie).
Princíp disociácie
Jadrom princípu disociácie je otázka: môže konkurenčný uzol spôsobiť poškodenie údajov? V prípade, že je pravdepodobným scenárom poškodenie údajov, dobrým riešením by bolo izolovať uzol od prichádzajúcich požiadaviek aj od trvalého úložiska. Najbežnejším prístupom k disociácii je odpojenie chybných uzlov.
Existujú dve kategórie metód disociácie, ktoré budem nazývať rovno и nepriamy, ale možno ich rovnako nazvať aktívny и pasívny. Priame metódy zahŕňajú akcie zo strany prežívajúcich rovesníkov, ako je interakcia so zariadením IPMI (Intelligent Platform Management Interface) alebo iLO (mechanizmus na správu serverov bez fyzického prístupu k nim), zatiaľ čo nepriame metódy sa spoliehajú na neúspešné uzol, aby nejako rozpoznal, že je v nezdravom stave (alebo aspoň bráni ostatným členom zotaviť sa) a signalizoval o potrebe odpojiť zlyhaný uzol.
Kvórum pomáha pri používaní priamych aj nepriamych metód.
Priama disociácia
V prípade priamej disociácie môžeme použiť kvórum, aby sme zabránili pretekom o disociáciu v prípade zlyhania siete.
S konceptom kvóra je v systéme dostatok informácií (aj bez pripojenia k rovesníkom), aby uzly automaticky vedeli, či majú iniciovať disociáciu a/alebo obnovu.
Bez kvóra budú obe strany rozdelenia siete správne predpokladať, že druhá strana je mŕtva a budú sa snažiť oddeliť tú druhú. V horšom prípade sa obom stranám podarí odstaviť celý klaster. Alternatívnym scenárom je deathmatch, nekonečná slučka spawnujúcich uzlov, ktoré nevidia svojich rovesníkov, reštartujú ich a iniciujú obnovu, aby sa reštartovali iba vtedy, keď ich rovesníci dodržiavajú rovnakú logiku.
Problém s odpojením je, že najčastejšie používané zariadenia sa stanú nedostupnými v dôsledku rovnakých udalostí zlyhania, na ktoré sa chceme zamerať pri obnove. Väčšina kariet IPMI a iLO je nainštalovaná na hostiteľoch, ktoré riadia, a štandardne používajú rovnakú sieť, čo spôsobuje, že cieľoví hostitelia sa domnievajú, že ostatní hostitelia sú offline.
Bohužiaľ, prevádzkové funkcie zariadení IPMI a iLo sa pri nákupe zariadenia len zriedka zvažujú.
Nepriama disociácia
Kvórum je tiež dôležité pre riadenie nepriamej disociácie; ak sa vykoná správne, kvórum môže umožniť pozostalým predpokladať, že stratené uzly po určitom čase prejdú do bezpečného stavu.
S touto konfiguráciou sa hardvérový strážny časovač resetuje každých N sekúnd, ak sa nestratí kvórum. Ak časovač (zvyčajne niekoľko násobkov N) uplynie, zariadenie vykoná bezradné vypnutie (nie vypnutie).
Tento prístup je veľmi efektívny, ale bez kvóra nie je v rámci klastra dostatok informácií na jeho riadenie. Nie je ľahké rozlíšiť medzi výpadkom siete a zlyhaním peer uzla. Dôvodom je to, že bez schopnosti rozlišovať medzi týmito dvoma prípadmi ste nútení zvoliť si rovnaké správanie v oboch prípadoch.
Problém s výberom jedného režimu spočíva v tom, že neexistuje žiadny postup, ktorý by maximalizoval dostupnosť a zabránil strate údajov.
- Ak sa rozhodnete predpokladať, že partnerský uzol je aktívny, ale v skutočnosti zlyhá, klaster zbytočne zastaví služby, ktoré by boli spustené, aby kompenzoval stratu služieb z neúspešného uzla rovnocenného uzla.
- Ak sa rozhodnete predpokladať, že uzol je mimo prevádzky, ale išlo len o zlyhanie siete a v skutočnosti je vzdialený uzol funkčný, potom sa prinajlepšom prihlásite na budúce manuálne zosúladenie výsledných súborov údajov.
Bez ohľadu na to, akú heuristiku použijete, je triviálne vytvoriť zlyhanie, ktoré buď spôsobí zlyhanie oboch strán, alebo spôsobí, že klaster vypne prežívajúce uzly. Nepoužívanie kvóra skutočne pripravuje klaster o jeden z najsilnejších nástrojov v jeho arzenáli.
Ak neexistuje iná alternatíva, najlepším prístupom je obetovať dostupnosť (tu sa autor odvoláva na vetu CAP). Vysoká dostupnosť poškodených dát nikomu nepomáha a ručné zosúlaďovanie rôznych dátových množín tiež nie je zábavné.
Kvórum
Kvórum znie skvele, však?
Jedinou nevýhodou je, že na to, aby ste ho mali v klastri s N členmi, musíte mať spojenie medzi N/2+1 zostávajúcimi uzlami. Čo nie je možné v klastri s dvoma uzlami 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 dvoch klastroch uzlov a bez neho nie je možné spoľahlivo určiť postup, ktorý maximalizuje dostupnosť a zabráni strate údajov
Ani v systéme dvoch uzlov prepojených kríženým káblom nie je možné definitívne rozlíšiť medzi výpadkom siete a poruchou druhého uzla. Zakázanie jedného konca (ktorého pravdepodobnosť je samozrejme úmerná vzdialenosti medzi uzlami) bude stačiť na vyvrátenie akéhokoľvek predpokladu, že zdravie spoja sa rovná zdraviu partnerského uzla.
Spustenie klastra s dvoma uzlami
Niekedy si klient nemôže alebo nechce kúpiť tretí uzol a my sme nútení hľadať alternatívu.
Možnosť 1 – Duplicitná metóda disociácie
Zariadenie iLO alebo IPMI uzla predstavuje bod zlyhania, pretože ak zlyhá, osoby, ktoré prežili, ho nemôžu použiť na uvedenie uzla do bezpečného stavu. V klastri 3 alebo viacerých uzlov to môžeme zmierniť výpočtom kvóra a použitím hardvérového strážneho psa (mechanizmus nepriameho oddeľovania, ako bolo uvedené vyššie). V prípade dvoch uzlov musíme namiesto nich použiť sieťové distribučné jednotky napájania (PDU).
Po zlyhaní sa preživší najprv pokúsi kontaktovať primárne disociačné zariadenie (embedded iLO alebo IPMI). Ak je to úspešné, obnova pokračuje ako zvyčajne. Iba v prípade zlyhania zariadenia iLO/IPMI sa pristupuje k PDU; ak je prístup úspešný, obnova môže pokračovať.
Uistite sa, že umiestnite PDU do inej siete, než je prevádzka klastra, inak jediné zlyhanie siete zablokuje prístup k obom zariadeniam na odpojenie a zablokuje obnovenie služieb.
Tu sa môžete opýtať - je PDU jediným bodom zlyhania? Na čo je odpoveď, samozrejme, je.
Ak je toto riziko pre vás významné, nie ste sami: pripojte oba uzly k dvom PDU a povedzte klastrovaciemu softvéru, aby pri zapínaní a vypínaní uzlov používal oba. Klaster teraz zostane aktívny, ak jeden PDU zanikne a na zablokovanie obnovy bude potrebné druhé zlyhanie druhého PDU alebo zariadenia IPMI.
Možnosť 2 – Pridanie arbitra
V niektorých scenároch je metóda duplicitnej disociácie technicky možná, no politicky náročná. Mnoho spoločností má rád nejaké oddelenie medzi správcami a vlastníkmi aplikácií a správcovia sietí, ktorí si uvedomujú bezpečnosť, nie sú vždy nadšení zdieľaním nastavení prístupu PDU s kýmkoľvek.
V tomto prípade je odporúčanou alternatívou vytvorenie neutrálnej tretej strany, ktorá môže doplniť výpočet kvóra.
V prípade zlyhania musí byť uzol schopný vidieť vysielanie svojho partnera alebo rozhodcu, aby mohol obnoviť služby. Rozhodca obsahuje aj funkciu odpojenia, ak oba uzly vidia rozhodcu, ale nevidia sa navzájom.
Táto možnosť sa musí použiť v spojení s metódou nepriameho odpojenia, ako je napríklad hardvérový strážny časovač, ktorý je nakonfigurovaný tak, aby zabil počítač, ak stratí spojenie so svojim rovnocenným a rozhodovacím uzlom. Preto môže osoba, ktorá prežila, dôvodne predpokladať, že jej partnerský uzol bude v zabezpečenom stave po vypršaní hardvérového strážneho časovača.
Praktický rozdiel medzi rozhodcom a tretím uzlom je v tom, že rozhodca vyžaduje na svoju činnosť oveľa menej zdrojov a môže potenciálne obsluhovať viac ako jeden klaster.
Možnosť 3 – Ľudský faktor
Posledným prístupom je, aby preživší pokračovali v spúšťaní akýchkoľvek služieb, ktoré už spustili, ale nezačínali nové, kým sa problém nevyrieši sám (obnovenie siete, reštart uzla) alebo osoba neprevezme zodpovednosť za manuálne potvrdenie, že druhá strana je mŕtva.
Bonusová možnosť
Spomenul som, že môžete pridať tretí uzol?
Dva stojany
Pre argumentáciu predstierajme, že som vás presvedčil o výhodách tretieho uzla, teraz musíme zvážiť fyzické usporiadanie uzlov. Ak sú umiestnené (a napájané) v rovnakom stojane, predstavuje to tiež SPoF, ktoré nemožno vyriešiť pridaním druhého stojana.
Ak je to prekvapujúce, zvážte, čo by sa stalo, keby stojan s dvoma uzlami zlyhal, a ako by prežívajúci uzol rozlíšil medzi tým a zlyhaním siete.
Krátka odpoveď je, že to nie je možné a opäť sa zaoberáme všetkými problémami v prípade dvoch uzlov. Alebo preživší:
- ignoruje kvórum a nesprávne sa pokúša spustiť obnovu počas výpadkov siete (schopnosť dokončiť disociáciu je iný príbeh a závisí od toho, či je zapojená PDU a či zdieľa napájanie s niektorým zo stojanov), alebo
- rešpektuje kvórum a predčasne sa odpojí, keď jeho partnerský uzol zlyhá
V každom prípade dva stojany nie sú o nič lepšie ako jeden a uzly musia mať buď nezávislé napájacie zdroje, alebo musia byť rozdelené do troch (alebo viacerých, v závislosti od toho, koľko uzlov máte) stojanov.
Dve dátové centrá
V tomto bode môžu čitatelia, ktorí už nemajú averziu voči riziku, zvážiť obnovenie po havárii. Čo sa stane, keď asteroid zasiahne to isté dátové centrum s našimi tromi uzlami rozmiestnenými v troch rôznych stojanoch? Očividne zlé veci, ale v závislosti od vašich potrieb nemusí pridanie druhého dátového centra stačiť.
Ak sa to urobí správne, druhé dátové centrum vám poskytne (a primerane) aktuálnu a konzistentnú kópiu vašich služieb a ich údajov. Rovnako ako v scenároch s dvoma uzlami a dvoma stojanmi však v systéme nie je dostatok informácií na zabezpečenie maximálnej dostupnosti a zabránenie poškodeniu (alebo nezrovnalostiam v súbore údajov). Dokonca aj pri troch uzloch (alebo stojanoch) ich distribúcia iba do dvoch dátových centier spôsobí, že systém nedokáže spoľahlivo urobiť správne rozhodnutie v prípade (teraz oveľa pravdepodobnejšej) udalosti, s ktorou obe strany nemôžu komunikovať.
To neznamená, že duálne riešenie dátového centra nie je nikdy vhodné. Spoločnosti často chcú, aby si človek bol vedomý predtým, ako urobí mimoriadny krok, ktorým je presun do záložného dátového centra. Len majte na pamäti, že ak chcete výpadok automatizovať, budete potrebovať buď tretie dátové centrum, aby kvórum dávalo zmysel (buď priamo alebo cez arbitra), alebo nájdete spôsob, ako spoľahlivo vypnúť celé dáta stred.
Zdroj: hab.com