Szia Habr! Figyelmébe ajánlom a cikk fordítását írta: Andrew Beekhof.
Sokan a kétcsomópontos klasztereket részesítik előnyben, mert elvileg egyszerűbbnek tűnnek, és 33%-kal olcsóbbak is, mint három csomópontos társai. Bár teljesen lehetséges két csomópontból álló jó klaszter összeállítása, a legtöbb esetben a meggondolatlan forgatókönyvek miatt egy ilyen konfiguráció sok nyilvánvaló problémát okoz.
Bármilyen magas rendelkezésre állású rendszer létrehozásának első lépése, hogy megtaláljuk és megkíséreljük kiküszöbölni az egyes meghibásodási pontokat, amelyeket gyakran rövidítenek: SPoF (egyetlen meghibásodási pont).
Érdemes szem előtt tartani, hogy egyetlen rendszerben sem lehet minden lehetséges leállási kockázatot kiküszöbölni. Ez abból fakad, hogy a kockázatok elleni tipikus védekezés némi redundancia bevezetése, ami a rendszer bonyolultságának növekedéséhez és új hibapontok megjelenéséhez vezet. Ezért kezdetben kompromisszumot kötünk, és az egyes kudarcpontokhoz kapcsolódó eseményekre összpontosítunk, nem pedig a kapcsolódó és ezért egyre kevésbé valószínű események láncolatára.
Tekintettel a kompromisszumokra, nem csak az SPoF-et keressük, hanem a kockázatokat és a következményeket is egyensúlyba hozzuk, aminek következtében a következtetés, hogy mi a kritikus és mi nem, telepítésenként eltérő lehet.
Nem mindenkinek van szüksége alternatív áramszolgáltatókra, független vezetékekkel. Bár a paranoia legalább egy ügyfélnek kifizetődött, amikor a monitorozásuk hibás transzformátort észlelt. Az ügyfél telefonálva próbálta riasztani az áramszolgáltatót, amíg a hibás transzformátor fel nem robbant.
Természetes kiindulópont az, ha egynél több csomópont van a rendszerben. Mielőtt azonban a rendszer a szolgáltatásokat áthelyezhetné a túlélő csomópontba egy hiba után, általában meg kell győződnie arról, hogy az áthelyezett szolgáltatások máshol nem aktívak.
A két csomópontból álló fürtnek nincs hátránya, ha egy hiba azt eredményezi, hogy mindkét csomópont ugyanazt a statikus webhelyet szolgálja ki. A dolgok azonban megváltoznak, ha mindkét fél önállóan kezel egy megosztott jobsort, vagy koordinálatlan írási hozzáférést biztosít egy replikált adatbázishoz vagy megosztott fájlrendszerhez.
Ezért, hogy megakadályozzuk az adatsérülést egyetlen csomópont meghibásodása következtében - támaszkodunk valami ún "disszociáció" (vívás).
A disszociáció elve
A disszociáció elvének középpontjában a kérdés áll: okozhat-e egy versengő csomópont adatsérülést? Abban az esetben, ha az adatsérülés valószínű forgatókönyv, jó megoldás lenne a csomópont elkülönítése a bejövő kérésektől és az állandó tárolástól. A szétválasztás leggyakoribb módja a hibás csomópontok leválasztása.
A disszociációs módszereknek két kategóriája van, ezeket nevezem el közvetlen и közvetett, de ugyanúgy nevezhetők aktív и passzív. A direkt módszerek közé tartoznak a túlélő társak részéről végzett műveletek, például interakció az IPMI (Intelligent Platform Management Interface) vagy az iLO (a kiszolgálók fizikai hozzáférésének hiányában történő felügyeleti mechanizmus) eszközzel, míg a közvetett módszerek a meghibásodott eszközökre támaszkodnak. csomópont, hogy valahogy felismerje, hogy egészségtelen állapotban van (vagy legalábbis megakadályozza a többi tag felépülését), és jelezze a meghibásodott csomópont leválasztásának szükségességéről.
A kvórum segít a közvetlen és közvetett módszerek alkalmazásakor.
Közvetlen disszociáció
Közvetlen disszociáció esetén a határozatképességet használhatjuk a disszociációs versenyek megelőzésére hálózati meghibásodás esetén.
A kvórum fogalmával elegendő információ van a rendszerben (még a társakhoz való csatlakozás nélkül is), hogy a csomópontok automatikusan tudják, kezdeményezniük kell-e a disszociációt és/vagy a helyreállítást.
Határozatképtelenség nélkül a hálózati megosztottság mindkét oldala joggal feltételezi, hogy a másik oldal halott, és megpróbálja szétválasztani a másikat. A legrosszabb esetben mindkét félnek sikerül leállítani az egész klasztert. Alternatív forgatókönyv a deathmatch, a csomópontok végtelen köre, amelyek nem látják társaikat, újraindítják őket, és csak akkor indítják el a helyreállítást, hogy újrainduljanak, amikor a társuk ugyanazt a logikát követi.
A szétválasztással az a probléma, hogy a leggyakrabban használt eszközök elérhetetlenné válnak ugyanazon hibaesemények miatt, amelyeket a helyreállításhoz szeretnénk megcélozni. A legtöbb IPMI- és iLO-kártya az általuk vezérelt gazdagépekre van telepítve, és alapértelmezés szerint ugyanazt a hálózatot használják, ami miatt a célállomások azt hiszik, hogy más gazdagépek offline állapotban vannak.
Sajnos az IPMI és iLo eszközök működési jellemzőit ritkán veszik figyelembe a berendezés vásárlásakor.
Közvetett disszociáció
A kvórum a közvetett szétválasztás kezelésében is fontos; ha helyesen történik, a kvórum lehetővé teszi a túlélők számára, hogy feltételezzék, hogy az elveszett csomópontok egy bizonyos idő elteltével biztonságos állapotba kerülnek.
Ezzel a konfigurációval a hardverfigyelő időzítő N másodpercenként alaphelyzetbe áll, ha a kvórum nem vész el. Ha az időzítő (általában az N többszöröse) lejár, akkor a készülék tisztességtelen kikapcsolást (nem leállítást) hajt végre.
Ez a megközelítés nagyon hatékony, de határozatképesség nélkül nincs elegendő információ a klaszteren belül a kezeléséhez. Nem könnyű különbséget tenni a hálózati kimaradás és a peer csomópont meghibásodása között. Ennek az az oka, hogy a két eset megkülönböztetésének képessége nélkül kénytelen mindkét esetben ugyanazt a viselkedést választani.
Az egyik mód kiválasztásával az a probléma, hogy nincs olyan intézkedés, amely maximalizálja a rendelkezésre állást és megakadályozza az adatvesztést.
- Ha úgy dönt, hogy feltételezi, hogy egy peer-csomópont aktív, de valójában meghibásodik, a fürt szükségtelenül leállítja a futó szolgáltatásokat, hogy kompenzálja a hibás peer csomópont szolgáltatásvesztését.
- Ha úgy dönt, hogy feltételezi, hogy egy csomópont nem működik, de csak hálózati hiba volt, és valójában a távoli csomópont működik, akkor a legjobb esetben is feliratkozik az eredményül kapott adatkészletek későbbi kézi egyeztetésére.
Függetlenül attól, hogy milyen heurisztikát használ, triviális olyan meghibásodást létrehozni, amely vagy mindkét fél meghibásodását okozza, vagy a fürt leállítja a túlélő csomópontokat. Ha nem használja a kvórumot, az valóban megfosztja a klasztert arzenáljának egyik leghatékonyabb eszközétől.
Ha nincs más alternatíva, a legjobb megközelítés a rendelkezésre állás feláldozása (itt a szerző a CAP-tételre hivatkozik). A sérült adatok magas rendelkezésre állása nem segít senkinek, és a különböző adatkészletek manuális egyeztetése sem szórakoztató.
Határozatképesség
A Kvórum jól hangzik, igaz?
Az egyetlen hátránya az, hogy ahhoz, hogy egy N tagú fürtben legyen, kapcsolatnak kell lennie N/2+1 megmaradt csomópont között. Ami nem lehetséges egy két csomópontos fürtben, miután egy csomópont meghibásodik.
Ez végül elvezet minket a két csomópont alapvető problémájához:
A kvórumnak nincs értelme két csomópont klaszterben, és enélkül lehetetlen megbízhatóan meghatározni azt a cselekvési irányt, amely maximalizálja a rendelkezésre állást és megakadályozza az adatvesztést
Még egy keresztkábellel összekapcsolt két csomópontból álló rendszerben sem lehet határozottan különbséget tenni a hálózati kimaradás és a másik csomópont meghibásodása között. Az egyik vég letiltása (amelynek valószínűsége természetesen arányos a csomópontok távolságával) elegendő lesz ahhoz, hogy érvénytelenítsünk minden olyan feltevést, amely szerint a kapcsolat állapota megegyezik a partner csomópont állapotával.
Két csomópontos fürt működése
Előfordul, hogy az ügyfél nem tud vagy nem akar harmadik csomópontot vásárolni, és kénytelenek vagyunk alternatívát keresni.
1. lehetőség – Duplikált disszociációs módszer
Egy csomópont iLO- vagy IPMI-eszköze meghibásodási pontot jelent, mert ha meghibásodik, a túlélők nem tudják használni a csomópont biztonságos állapotba hozására. Egy 3 vagy több csomópontból álló klaszterben ezt a kvórum kiszámításával és egy hardveres megfigyelő (közvetett disasszociációs mechanizmus, amint arról korábban szó volt) segítségével enyhíthetjük. Két csomópont esetén helyette hálózati tápelosztó egységeket (PDU) kell használnunk.
Hiba után a túlélő először megpróbál kapcsolatba lépni az elsődleges disasszociációs eszközzel (beágyazott iLO vagy IPMI). Ha ez sikeres, a helyreállítás a szokásos módon folytatódik. Csak akkor lehet elérni a PDU-t, ha az iLO/IPMI eszköz meghibásodik; ha a hozzáférés sikeres, a helyreállítás folytatódhat.
Ügyeljen arra, hogy a PDU-t a fürtforgalomtól eltérő hálózatra helyezze, különben egyetlen hálózati hiba blokkolja a hozzáférést mindkét szétválasztási eszközhöz, és blokkolja a szolgáltatások visszaállítását.
Itt felteheti a kérdést – vajon a PDU egyetlen hibapont? Amire a válasz természetesen az.
Ha ez a kockázat jelentős az Ön számára, nincs egyedül: csatlakoztassa mindkét csomópontot két PDU-hoz, és mondja meg a fürtöző szoftvernek, hogy mindkettőt használja a csomópontok be- és kikapcsolásakor. A fürt most aktív marad, ha az egyik PDU meghal, és a másik PDU vagy az IPMI-eszköz második meghibásodására lesz szükség a helyreállítás blokkolásához.
2. lehetőség – Döntőbíró hozzáadása
Egyes forgatókönyvekben, bár a párhuzamos szétválasztási módszer technikailag lehetséges, politikailag nehéz. Sok vállalat szereti, ha elkülönülnek egymástól a rendszergazdák és az alkalmazások tulajdonosai, és a biztonságtudatos hálózati rendszergazdák nem mindig lelkesednek a PDU hozzáférési beállítások megosztásáért bárkivel.
Ebben az esetben az ajánlott alternatíva egy semleges harmadik fél létrehozása, amely kiegészítheti a határozatképesség számítását.
Meghibásodás esetén a csomópontnak látnia kell társa vagy döntőbíró éterét a szolgáltatások visszaállítása érdekében. A döntőbíró tartalmaz egy leválasztási funkciót is, ha mindkét csomópont látja a döntőbírót, de nem látja egymást.
Ezt a beállítást egy közvetett szétválasztási módszerrel, például egy hardverfigyelő időzítővel együtt kell használni, amely úgy van beállítva, hogy megölje a gépet, ha megszakad a kapcsolat a társ- és döntő csomópontjával. Így egy túlélő ésszerűen feltételezheti, hogy társcsomópontja biztonságos állapotban lesz, miután a hardverfigyelő időzítő lejár.
A gyakorlati különbség egy döntőbíró és egy harmadik csomópont között az, hogy egy döntőbíró sokkal kevesebb erőforrást igényel a működéséhez, és potenciálisan egynél több fürtöt is ki tud szolgálni.
3. lehetőség – Emberi tényező
A végső megközelítés az, hogy a túlélők továbbra is futtassák azokat a szolgáltatásokat, amelyeket már futtattak, de addig nem indítanak újakat, amíg a probléma magától meg nem oldódik (hálózat-visszaállítás, csomópont újraindítása), vagy amíg egy személy nem vállalja a felelősséget azért, hogy manuálisan megerősítse, hogy a másik oldal meghalt.
Bónusz lehetőség
Említettem már, hogy hozzáadhat egy harmadik csomópontot?
Két állvány
Az érvelés kedvéért tegyük fel, hogy meggyőztem Önt a harmadik csomópont érdemeiről, most meg kell vizsgálnunk a csomópontok fizikai elrendezését. Ha ugyanabban a rackben vannak elhelyezve (és árammal látják el), ez is SPoF-nak minősül, és nem oldható meg egy második rack hozzáadásával.
Ha ez meglepő, gondolja át, mi történne, ha egy két csomóponttal rendelkező rack meghibásodik, és hogyan különböztetné meg a túlélő csomópont ezt a hálózati meghibásodástól.
A rövid válasz az, hogy ez nem lehetséges, és két csomópont esetén ismét minden problémával foglalkozunk. Vagy túlélő:
- figyelmen kívül hagyja a határozatképességet, és helytelenül próbálja meg kezdeményezni a helyreállítást a hálózati kimaradások során (a disszociáció befejezésének képessége egy másik történet, és attól függ, hogy a PDU érintett-e, és megosztja-e az áramot valamelyik rack-el), vagy
- tiszteletben tartja a kvórumot, és idő előtt lekapcsolja magát, ha a társcsomópontja meghibásodik
Mindenesetre két rack nem jobb, mint egy, és a csomópontoknak vagy független tápegységet kell kapniuk, vagy három (vagy több, attól függően, hogy hány csomópontja van) rack között kell elosztaniuk.
Két adatközpont
Ezen a ponton azoknak az olvasóknak, akik már nem kerülik a kockázatot, érdemes megfontolni a katasztrófa utáni helyreállítást. Mi történik, ha egy aszteroida ugyanabba az adatközpontba ütközik, ahol három csomópontunk három különböző állványon található? Nyilvánvalóan rossz dolgok, de az Ön igényeitől függően előfordulhat, hogy egy második adatközpont hozzáadása nem elég.
Ha helyesen tette, a második adatközpont (és ésszerű módon) naprakész és következetes másolatot biztosít az Ön szolgáltatásairól és adatairól. A két csomópontos, két állványos forgatókönyvekhez hasonlóan azonban nincs elegendő információ a rendszerben a maximális rendelkezésre állás biztosításához és a korrupció (vagy az adatkészlet-eltérések) megelőzéséhez. Még három csomópont (vagy rack) esetén is, ha csak két adatközpont között osztja el őket, a rendszer nem tudja megbízhatóan meghozni a megfelelő döntést egy olyan (most sokkal valószínűbb) esemény esetén, amikor mindkét fél nem tud kommunikálni.
Ez nem jelenti azt, hogy a kettős adatközpontos megoldás soha nem megfelelő. A vállalatok gyakran azt akarják, hogy egy személy tisztában legyen, mielőtt megtenné azt a rendkívüli lépést, hogy egy tartalék adatközpontba költözik. Ne feledje, hogy ha automatizálni szeretné a kimaradást, akkor vagy egy harmadik adatközpontra lesz szüksége, hogy a határozatképesség értelme legyen (akár közvetlenül, akár egy döntőbírón keresztül), vagy megtalálja a módját a teljes adat megbízható leállításának. központ.
Forrás: will.com