Helló, Habr! Örömmel mutatom be az írás fordítását. szerző: Andrew Beekhof.
Sokan a két csomópontból álló klasztereket részesítik előnyben, mert koncepcionálisan egyszerűbbnek tűnnek, ráadásul 33%-kal olcsóbbak, mint három csomópontból álló társaik. Bár teljesen lehetséges egy jó két csomópontos klasztert létrehozni, a legtöbb esetben a figyelembe nem vett forgatókönyvek miatt ez a konfiguráció sok nem nyilvánvaló problémát fog okozni.
A magas rendelkezésre állású rendszer létrehozásának első lépése a potenciális egyedi hibapontok keresése és megpróbálása azok megszüntetése, amelyeket gyakran SPoF-nak neveznek. SPoF (egypontos hiba).
Érdemes megjegyezni, hogy bármely rendszerben lehetetlen az összes lehetséges állásidő kockázatot megszüntetni. Ez legalább is abból a tényből adódik, hogy a tipikus védekezés a kockázatok ellen a redundancia bevezetése, ami a rendszer bonyolultságának növekedéséhez és újabb hibapontok megjelenéséhez vezet. Éppen ezért kezdetben kompromisszumot kötünk, és a különböző egyedi hibapontokkal kapcsolatos eseményekre összpontosítunk, és nem a kapcsolódó, így egyre valószínűtlenebb események láncolatára.
A kompromisszumokat figyelembe véve nemcsak az egyedi hibapontokat keressük, hanem a kockázatok és következmények egyensúlyát is felmérjük; így a kritikus és nem kritikus elemek meghatározása eltérő lehet minden telepítésnél.
Nem mindenki igényel alternatív áramellátókat független áramvezetékekkel. Bár a paranoia legalább egy ügyfél számára megtérült, amikor a monitorozás felfedezte a hibás transzformátort. Az ügyfél telefonált, próbálva figyelmeztetni az energetikai vállalatot, míg a hibás transzformátor fel nem robbant.
A természetes kiindulópont az, hogy a rendszerben több mint egy csomópont legyen. Azonban mielőtt a rendszer át tudná helyezni a szolgáltatásokat a hiba után életben maradt csomópontra, általában biztosítani kell, hogy az áthelyezett szolgáltatások ne legyenek aktívak máshol.
A kétcsomópontos klaszternek nincsenek hiányosságai, ha mindkét csomópont ugyanazt a statikus weboldalt szolgálja ki hiba esetén. Azonban minden megváltozik, ha a két oldal függetlenül kezeli a közös feladatlistát, vagy nem koordinált írási hozzáférést biztosít a replikált adatbázishoz vagy a közös fájlrendszerhez.
Ezért, hogy megakadályozzuk az adatok megsérülését egy csomópont meghibásodása miatt – számítunk arra, amit úgy hívunk, fencing (kerítés).
A kerítés elve
A kerítés elvének alapja a kérdés: okozhat-e egy versengő csomópont adatkárosodást? Ha valószínű, hogy az adatkárosodás bekövetkezik – akkor a csomópontokat el kell szigetelni, hogy azok ne érhessenek be jövőbeli kéréseket és ne férhessenek hozzá a tartós tárolóhoz. A legelterjedtebb megközelítés a hibás csomópontok kikapcsolása.
Két kategóriába sorolható a kerítés módszerei, amelyeket közvetleneknek és ésközvetetteknek , de egyformán nevezhetők és aktívnakés A közvetlen módszerek közé tartoznak a túlélő egyenrangú csomópontok által végzett intézkedések, mint például az IPMI (Intelligent Platform Management Interface – a szerver fizikai állapotának távoli megfigyelésére és kezelésére szolgáló interfész) vagy az iLO (szerverek kezelése, amikor nincs fizikai hozzáférés), míg a közvetett módszerek a hibás csomóponttól függenek, hogy valamilyen módon felismerje, hogy kedvezőtlen állapotban van (vagy legalábbis akadályozza a többi tagot a helyreállásban) és jelezze
hardware watchdog
a hibás csomópont kikapcsolásának szükségességét.
A kvorum segít mind közvetlen, mind közvetett módszerek esetén.
Közvetlen kerítés esetén a kvorum segítségével megakadályozhatjuk a kerítési versenyeket hálózati hiba esetén. A kvorum koncepcióval a rendszer elegendő információval rendelkezik (még a partnerekhez való csatlakozás nélkül is), hogy a csomópontok automatikusan tudják, hogy el kell-e kezdeniük a kerítést és/vagy a helyreállítást.
Ha nincs kvorum, mindkét fél a hálózati partícióban jogosan feltételezi, hogy a másik fél halott, és igyekezni fog elhatárolódni a másiktól. A legrosszabb forgatókönyvben mindkét félnek sikerül lekapcsolnia az egész klasztert. Alternatív forgatókönyv — deathmatch, a csomópontok végtelen ciklusa, amelyek megjelennek, nem látják a párjaikat, újraindítják őket, és kezdeményeznek helyreállítást, csak hogy újrainduljanak, amikor a párjuk ugyanazon logika alapján megy keresztül.
A leválasztás problémája, hogy a leggyakrabban használt eszközök elérhetetlenné válnak ugyanazok miatt a hibás események miatt, amelyekre a helyreállításhoz orientálódni szeretnénk. A legtöbb IPMI és iLO kártya a kezelendő hosztokon van telepítve, és alapértelmezés szerint ugyanazt a hálózatot használják, ezért a célszámok azt feltételezik, hogy a többi csomópont offline van.
Sajnos az IPMI és iLo eszközök működésének sajátosságai ritkán kerülnek figyelembevételre a berendezések vásárlásának időpontjában.
Közvetett leválasztás
A kvorum szintén fontos a közvetett leválasztások kezelésében, ha minden megfelelően van elvégezve, a kvorum lehetővé teszi a megmaradók számára, hogy feltételezzék, hogy az elveszett csomópontok egy bizonyos idő elteltével biztonságos állapotba kerülnek.
Ebben a beállításban a hardver erőforrás-váróidő N másodpercenként visszaáll, ha a kvorum nem veszett el. Ha a váróidő (általában több N többszöröse) lejár, az eszköz rendkívüli leállítást hajt végre (nem leállítást).
Ez a megközelítés nagyon hatékony, de a kvorum nélküli kezeléshez túl kevés információ áll rendelkezésre a klaszteren belül. Nehéz megkülönböztetni a hálózati lekapcsolást és a partner csomópont hibáját. Azért van jelentősége, mert két eset megkülönböztetésének hiányában kénytelen vagy ugyanazt a magatartási módot választani mindkét esetben.
Az egyetlen üzemmód választásának problémája, hogy nincs olyan intézkedés, amely maximálisan növelné a rendelkezésre állást és megelőzné az adatok elvesztését.
- Ha feltételezi, hogy a partner csomópont aktív, de valójában hiba történt, a klaszter túl sok szolgáltatást állít le, amelynek működnie kellett volna a leállt partner csomópont szolgáltatásainak elvesztésének kompenzálására.
- Ha feltételezi, hogy a csomópont nem működik, de ez csak egy hálózati hiba volt, és valójában a távoli csomópont működik, akkor legjobb esetben is egy jövőbeli manuális ellenőrzésre írja alá az eredő adathalmazokat.
Bármely heuristicát is használ, könnyű létrehozni egy hibát, amely vagy mindkét felet működésre kényszeríti, vagy a klasztert arra készteti, hogy lekapcsolja a megmaradt csomópontokat. A kvórum nem használata tényleg megfosztja a klasztert a legnagyobb eszközök egyikétől az arzenáljában.
Ha nincs más alternatíva, a legjobb megközelítés az, ha feláldozza a rendelkezésre állást (itt a szerző a CAP-tételre utal). A sérült adatok magas rendelkezésre állása senkinek sem segít, és a különböző adathalmazok manuális ellenőrzése sem örömteli.
Kvórum
A kvórum jól hangzik, igaz?
Az egyetlen hátránya az, hogy ahhoz, hogy legyen kvórum egy N tagú klaszterben, a csomópontjainak N / 2 + 1 közötti kapcsolatnak fenn kell maradnia. Ez lehetetlen egy két csomópontból álló klaszterben, miután az egyik csomópont meghibásodik.
Ami végül a két csomópont alapvető problémájához vezet:
A kvórumnak nincs értelme két csomópontos klaszterekben, és enélkül nem lehet megbízhatóan meghatározni azt a cselekvési irányt, amely maximálisan növeli a rendelkezésre állást és megakadályozza az adatvesztést.
Még egy két csomópontból álló rendszerben, amelyet keresztkábellel kötnek össze, véglegesen nem lehet megkülönböztetni a hálózati leállítást a másik csomópont meghibásodásától. Az egyik végének lecsatlakozása (amelynek valószínűsége kétségtelenül arányos a csomópontok közötti távolsággal) elegendő lesz ahhoz, hogy cáfolja bármely felvetést, hogy a csatorna működőképessége megegyezik a partner csomópont egészségével.
Két csomópontos klaszter működésre bírása
Néha az ügyfél nem tud vagy nem akar harmadik csomópontot vásárolni, és alternatívát kell keressünk.
1. lehetőség - Megképezési módszer alkalmazása
Az iLO vagy IPMI eszköz a csomópont esetében hibapontot jelent, mert meghibásodás esetén a működő eszközök nem tudják azt használni a csomópont biztonságos állapotba helyezésére. Három vagy annál több csomópont esetén a kvórum számításával és a hardveres watchdog használatával, amelyről korábban beszéltünk, enyhíthetjük ezt a problémát. Két csomópont esetén ehelyett tápelosztó egységeket (PDU) kell használnunk.
Hibásodás után a megmaradt csomópont először megpróbálja felvenni a kapcsolatot a fő leválasztó berendezéssel (beépített iLO vagy IPMI). Ha ez sikerül, a helyreállítás folytatódik a megszokott módon. Csak iLO / IPMI meghibásodás esetén fordulunk a PDU-hoz, ha a kapcsolat sikeres, a helyreállítás folytatódhat.
Fontos, hogy a PDU-t egy olyan hálózatba helyezzük, amely elkülönül a klaszter forgalmától, egyetlen hálózati hibajelenség esetén így nem blokkolja a leválasztó berendezésekhez való hozzáférést és a szolgáltatások helyreállítását sem.
Itt felteheti a kérdést – nem tekinthető-e a PDU egyetlen hibapontnak? A válasz - természetesen az.
Ha ez a kockázat jelentős az Ön számára – nem Ön az egyetlen: csatlakoztassa mindkét csomópontot két PDU-hoz, és utasítsa a klaszter szoftvert, hogy mindkettőt használja a csomópontok bekapcsolásakor és kikapcsolásakor. Most a klaszter aktív marad, ha az egyik PDU meghal, és a helyreállítást a második PDU vagy az IPMI eszköz hibája fogja blokkolni.
2. lehetőség – Arbitrátor hozzáadása
Egyes forgatókönyvekben, bár technikailag lehetséges a duplikált leválasztási módszer, politikailag bonyolult. Sok cég kedveli a határozott elkülönülést az adminisztrátorok és az alkalmazástulajdonosok között, és a biztonságra érzékeny hálózati adminisztrátorok nem mindig lelkesednek azért, hogy bárkinek is átadják a PDU hozzáférési paramétereit.
Ebben az esetben a javasolt alternatíva egy semleges harmadik fél létrehozása, amely ki tudja egészíteni a kvórum számítást.
Hibásodás esetén a csomópontnak látnia kell a partnere vagy az arbitrátor éterét ahhoz, hogy helyreállíthassa a szolgáltatásokat. Az arbitrátor egy szakító funkciót is tartalmaz, ha mindkét csomópont látja az arbitrátort, de nem látják egymást.
Ez az opció közvetett elválasztási módszerrel, például hardver watchdog időzítővel használható, amely beállítva van arra, hogy leállítsa a gépet, ha az elveszíti a kapcsolatot a partnercsomópontjával és az arbitrással. Így a túlélő kellő biztonsággal feltételezheti, hogy a partnercsomópontja biztonságos állapotban lesz a hardver watchdog időzítő lejárta után.
Az arbitrázs és a harmadik csomópont közötti gyakorlati különbség az, hogy az arbitrázs sokkal kevesebb forrást igényel a működéséhez, és potenciálisan több klasztert is kiszolgálhat.
3. lehetőség - Emberi tényező
Az utolsó megközelítés az, hogy a túlélők folytatják bármilyen szolgáltatás teljesítését, amelyet már végeztek, de újakat nem indítanak, amíg vagy a probléma nem oldódik meg önmagában (hálózat helyreállítása, csomópont újraindítása), vagy egy ember nem vállalja a felelősséget a másik fél halálának manuális megerősítéséért.
Bónusz opció
Már említettem, hogy hozzáadhat harmadik csomópontot?
Két állvány
A vita kedvéért tegyük fel, hogy meggyőztelek a harmadik csomópont előnyeiről, most meg kell vizsgálnunk a csomópontok fizikai elhelyezkedését. Ha azok ugyanabban az állványban találhatók (és áramellátást kapnak), az szintén SPoF-t jelent, amely nem oldható meg a második állvány hozzáadásával.
Ha ez meglepő, gondolj arra, mi történik, ha a két csomóponttal rendelkező állvány elromlik, és hogyan tudja a túlélő csomópont megkülönböztetni ezt az esetet egy hálózati hibától.
Rövid válasz: ez lehetetlen, és ismét minden problémával szembesülünk a két csomópontos esetben. Vagy a túlélő:
- figyelmen kívül hagyja a kvórumot, és hibásan próbál helyreállítást kezdeményezni hálózati leállások során (a leválasztás lehetősége egy másik történet, és attól függ, hogy a PDU érintett-e és osztoznak-e az áramon bármelyik állvánnyal), vagy
- tiszteletben tartja a kvórumot, és idő előtt lecsatlakozik, amikor a partnercsomópontja meghibásodik.
Bármely esetben, két állvány nem jobb, mint egy, és a csomópontoknak vagy független áramforrásokat kell kapniuk, vagy három (vagy annál több, attól függően, hány csomópontja van) állványra kell szétszóródniuk.
Két adatközpont
Ebben a pillanatban a kockázatot elkerülő olvasók a katasztrófa utáni helyreállításra gondolhatnak. Mi történik, ha egy aszteroida nekiütközik egy adatközpontnak, míg három csomópontunk három különböző állványra van elosztva? Nyilvánvalóan rossz dolgok történnek, de igényeidtől függően egy második adatközpont hozzáadása lehet, hogy nem elegendő.
Ha mindent jól csinálnak, a második adatközpont aktuális és konzisztens másolatot biztosít a szolgáltatásaikról és adataikról. Azonban, akárcsak a két csomópontos és két állványos forgatókönyvekben, a rendszer nem rendelkezik elegendő információval a maximális elérhetőség biztosításához és a károsodás (vagy az adathalmozók eltérése) elkerüléséhez. Még három csomópont (vagy állvány) esetén is, ha csak két adatközpont között vannak elosztva, a rendszer nem képes megbízhatóan jónak ítélni a helyzetet egy olyan (most már sokkal valószínűbb) esemény esetén, amelyet mindkét oldal nem tud összekapcsolni.
Ez nem jelenti azt, hogy a két adatközpont megoldás soha nem megfelelő. A cégek gyakran szeretnék, ha egy személy tisztában lenne a helyzettel, mielőtt kivételes lépést tennének a tartalék adatközpontra való áttérés előtt. Csak tartsd szem előtt, hogy ha automatizálni szeretnéd a leállást, szükséged lesz egy harmadik adatközpontra, hogy a kvórum értelmet nyerjen (közvetlenül vagy egy döntőbíró által), vagy találnod kell egy módot, hogy megbízhatóan leállítsd az összes adatközpontot.
Forrás: habr.com
