Bevezetés a magas rendelkezésre állású számítástechnikába: fogalmak és elmélet

Koncentráljunk inkább a klaszterkezelés néhány nagyobb építészeti elvére, mint bármelyik egyedi technológiai megoldásra.

Néhány tényleges megvalósítást később láthatunk a könyvben - és sokat megtudhat arról, hogyan működik ez az Amazon AWS-jén, a Manning Learn Amazon Web Services című cikkében, a Manning egy hónapos ebéd könyvében. De most először győződjünk meg arról, hogy jól érezzük magunkat az alapokban.

A kiszolgálói műveletek futtatása fizikai vagy virtuális számítógépek fürtjeivel mind a megbízhatóság, mind a teljesítmény javításán alapul, felülmúlva azt, amit elvárhat egy nagy teljesítményű szervertől. A megbízhatóságot úgy növeli, hogy elkerüli a teljes infrastruktúra egyetlen hibapontra (azaz egyetlen szerverre) való felakasztását. És növelheti a teljesítményt azáltal, hogy a számítási teljesítményt és kapacitást nagyon gyorsan hozzá tudja növelni és kicsinyíteni.

Ez történhet a munkaterhelések intelligens elosztásával a különböző földrajzi és keresleti környezetek között (terheléselosztás), és biztosítja

Biztonsági mentési kiszolgálók, amelyek gyorsan üzembe helyezhetők abban az esetben, ha egy működő csomópont meghibásodik (feladatátvétel), optimalizálva az adatréteg telepítését, vagy lehetővé téve a hibatűrést a lazán összekapcsolt architektúrák révén.

Mindehhez eljutunk. Először is, itt van néhány alapvető meghatározás:

Csomópont : Egyetlen (fizikai vagy virtuális) szerver, amely futtatja a szervert, függetlenül működik a saját operációs rendszerén. Mivel bármelyik csomópont meghibásodhat, a rendelkezésre állási célok teljesítéséhez több csomópont kell működnie egy fürt részeként.

Klaszter : Két vagy több szerver csomópont, amelyek egymással összehangolva futnak az egyes feladatok elvégzéséhez egy nagyobb szolgáltatás részeként, ahol a kölcsönös tudatosság lehetővé teszi egy vagy több csomópont számára, hogy kompenzálja a másik veszteségét.

Szerverhiba : A szervercsomópont képtelen megfelelően reagálni az ügyfél kéréseire. Ennek oka lehet egy teljes összeomlás, kapcsolódási problémák, vagy mert a nagy kereslet elárasztotta.

Feladatátvitel : Az a mód, ahogy egy fürt megpróbálja kielégíteni az egyetlen kiszolgálói csomópont meghibásodása miatt elárvult ügyfelek igényeit azáltal, hogy más csomópontokat indít vagy irányít át egy szolgáltatáshiány kitöltésére.

Visszacsatolás : A felelősség visszaállítása egy kiszolgáló csomópontra, amikor az helyreáll egy hibából.

Replikáció : A kritikus adattárolók másolatainak létrehozása annak érdekében, hogy megbízható szinkron hozzáférést biztosítson több kiszolgáló csomópontjától vagy kliensétől, és biztosítsa a katasztrófák túlélését. A replikációt a megbízható terheléselosztás biztosításához is használják.

Redundancia : Több azonos fizikai vagy virtuális szerver csomópont kiépítése, amelyek közül bármelyik átveheti egy másik árva ügyfelét, amely nem működik.

Osztott agy : Olyan hibaállapot, amelyben a csomópontok vagy a megosztott tárhely közötti hálózati kommunikáció valamiképp megszakadt, és több különálló csomópont - mindegyik úgy gondolja, hogy ez az egyetlen aktív csomópont - továbbra is hozzáférnek egy közös adatforráshoz és frissítik azt. Ez ugyan nem befolyásolja a megosztott-semmi tervezéseket, de kliens-hibákhoz és adatok meghibásodásához vezethet a megosztott fürtökön belül.

Kerítés : Az agy hasadásának megakadályozása érdekében a stonithd démon konfigurálható úgy, hogy automatikusan leállítson egy hibásan működő csomópontot, vagy virtuális kerítést szabjon közte és a fürt többi részének adatforrásai közé. Amíg van esély arra, hogy a csomópont továbbra is aktív lehet, de nem megfelelően koordinálódik a fürt többi részével, addig a kerítés mögött marad. Stonith jelentése: „Lődd le a másik csomópontot a fejedben”. Igazán.

Kvórum : Beállíthatja a kerítéseket (vagy kényszerített leállításokat) azokra a csomópontokra, amelyek egymással vagy valamilyen megosztott erőforrással érintkezésbe kerültek. A kvórumot gyakran a teljes fürt összes csomópontjának több mint feleként definiálják. Az ilyen definiált konfigurációk használatával elkerülheti, hogy két csomópont-alcsoport legyen, amelyek mindegyike hibásnak hiszi a másikat, és megpróbálja megütni a másikat.

Katasztrófa utáni helyreállítás y: Az infrastruktúrája aligha tekinthető rendkívül elérhetőnek, ha nincs automatikus biztonsági mentési rendszere, valamint integrált és tesztelt katasztrófa utáni helyreállítási terv. A tervnek figyelembe kell vennie a fürt mindegyik kiszolgálójának újratelepítését.

Aktív / passzív klaszter

A szolgáltatás feladatátvétele mögött az az elképzelés áll, hogy a szolgáltatáscsoportban bármelyik csomópont hirtelen elvesztését gyorsan pótolja egy másik csomópont. Ahhoz, hogy ez működjön, az IP-cím hibakezelés esetén automatikusan a készenléti csomópontba kerül. Alternatív megoldásként hálózati útválasztó eszközök, például terheléselosztók használhatók a forgalom átirányítására a meghibásodott csomópontoktól. A feladatátvétel pontos módja a csomópontok konfigurálásának módjától függ.

Kezdetben csak egy csomópont lesz konfigurálva az ügyfelek kiszolgálására, és ezt továbbra is egyedül fogja folytatni, amíg valahogy nem sikerül. A meglévő és az új ügyfelek felelőssége ekkor áthelyeződik (azaz „feladatátvétel”) a passzív - vagy tartalék - csomópontra, amelyet eddig passzívan tartalékként tartottak. Ha a modellt több szerverre vagy kiszolgáló helyiség-összetevőre (például tápegységekre) alkalmazzuk, az n + 1 redundancia éppen elegendő erőforrást biztosít az aktuális igényhez, valamint további egy egységet a hiba fedezésére.

Aktív / Aktív fürt

Az aktív / aktív tervezést használó fürtnek két vagy több azonos konfigurációjú csomópontja lesz, függetlenül az ügyfelek kiszolgálásától.

Ha egy csomópont nem működik, az ügyfelek automatikusan csatlakoznak a második csomóponthoz, és amennyiben az erőforrások megengedik, teljes erőforrás-hozzáférést kapnak.

Amint az első csomópont helyreáll, vagy kicserélődik, az ügyfelek ismét fel lesznek osztva mindkét szerver csomópont között.

Az aktív / aktív fürtök futtatásának elsődleges előnye abban rejlik, hogy hatékonyan kiegyensúlyozza a csomópontok és akár a hálózatok közötti munkaterhelést is. A terheléselosztó - amely az ügyfelektől érkező összes kérést az elérhető kiszolgálókra irányítja - úgy van konfigurálva, hogy figyelje a csomópontok és a hálózati tevékenységeket, és valamilyen előre meghatározott algoritmus segítségével irányítsa a forgalmat azokhoz a csomópontokhoz, amelyek a legjobban képesek kezelni azt. Az útválasztási házirendek követhetik a körbefutási mintát, ahol az ügyfélkéréseket egyszerűen váltogatják a rendelkezésre álló csomópontok között, vagy egy előre beállított tömeggel, ahol az egyik csomópontot valamilyen arányban előnyben részesítik.

Ha egy passzív csomópont aktív / passzív fürtkonfigurációban partnerének készenléti helyettesítőként működik, jelentős beépített redundanciát biztosít. Ha a művelete feltétlenül megszakítás nélküli szolgáltatást és zökkenőmentes feladatátváltást igényel, akkor az aktív / passzív architektúra bizonyos variációinak kell lennie a célnak.

Megosztott-semmi összehasonlítva megosztott lemez-fürtökkel

Az elosztott számítástechnika egyik alapelve az, hogy elkerülje, hogy működése egyetlen hibapontra támaszkodjon. Vagyis minden erőforrásnak aktívan replikálódnia (redundánsnak) vagy önállóan cserélhetőnek (feladatátvételnek) kell lennie, és nem létezhet egyetlen elem, amelynek meghibásodása a teljes szolgáltatásodat lebuktathatja.

Most képzelje el, hogy néhány tucat csomópontot futtat, amelyek mindegyike egyetlen adatbázis-kiszolgálóra támaszkodik a funkciójához. Annak ellenére, hogy bármely csomópont meghibásodása nem befolyásolja a megmaradt csomópontok további állapotát, ha az adatbázis lemegy, az egész fürt haszontalanná válik. A megosztott semmiben nem szereplő fürt csomópontjai azonban (általában) fenntartják saját adatbázisukat, így feltételezve, hogy megfelelően szinkronizálva vannak és konfigurálva vannak a folyamatos tranzakcióbiztonság érdekében, semmilyen külső hiba nem befolyásolja őket.

Ennek jelentősebb hatása lesz a terheléssel kiegyensúlyozott fürtre, mivel minden terheléssel kiegyensúlyozott csomópontnak állandó és kritikus igénye van az adatok egyidejű elérésére. Az egyszerű feladatátvételi rendszer passzív csomópontja azonban képes lehet túlélni egy ideig hozzáférés nélkül.

Bár egy ilyen beállítás lelassíthatja a fürt reagálását egyes kérésekre - részben azért, mert az osztott agyi kudarcoktól való félelem időszakos kerítéseket igényelhet a kőből -, a kompromisszum igazolható a misszió szempontjából kritikus telepítéseknél, ahol a megbízhatóság az elsődleges szempont.

Elérhetőség

A klaszter megtervezésekor elég jól kell érzékelnie, hogy mennyire toleráns lehet a kudarccal szemben. Vagy más szóval, figyelembe véve az Ön szolgáltatásait fogyasztó emberek vagy gépek igényeit, meddig tarthat egy szolgáltatás megszakadása, mire a tömeg szurokvillával és lángoló fáklyákkal ömlik át az első kapun. Fontos tudni ezt, mert a redundancia mennyisége, amelyet beépít a tervébe, hatalmas hatással lesz a leállási időkre, amelyekkel végül szembe kell néznie.

Nyilvánvaló, hogy az a rendszer, amelyet egy olyan szolgáltatáshoz építesz, amely egy hétvégére leállhat anélkül, hogy bárki észrevenné, nagyon különbözik attól az e-kereskedelmi webhelytől, amelynek ügyfelei 24/7-es hozzáférésre számítanak. Legalább arra kell törekednie, hogy legalább 99% -os rendelkezésre állási átlagot érjen el - egyes műveletekhez a valóságban lényegesen magasabb eredmények szükségesek. A 99% -os növekedési idő kevesebb, mint négy év veszteséget jelent minden évből.

Van egy viszonylag egyszerű képlet, amelynek segítségével hasznos becslést készíthet az elérhetőségről (A). Az ötlet az, hogy a meghibásodás előtti átlagidőt elosztjuk a meghibásodás előtti átlagos idővel és a javítás átlagidejével.

A = MTBF / (MTBF + MTTR)

Minél közelebb kerül az A értéke 1-hez, annál jobban elérhető lesz a fürtje. Az MTBF reális értékének megszerzéséhez valószínűleg időt kell fordítania arra, hogy egy valódi rendszert komoly büntetésnek tegyen ki, és gondosan figyelje a szoftveres, hardveres és hálózati hibákra. Feltételezem, hogy a hardvergyártók vagy a nagyüzemi fogyasztók, például a Backblaze, közzétett életciklus-mutatóival is megkeresheti, hogy képet kapjon arról, hogy az erősen használt hardver várhatóan mennyi ideig tarthat.

Az MTTR annak az időnek a terméke lesz, amely alatt a fürt a sikertelen kiszolgáló csomópont funkcionalitásának cseréjét veszi igénybe (ez a folyamat hasonló, bár nem azonos a katasztrófa utáni helyreállítással - amely a meghibásodott hardverek és kapcsolatok gyors cseréjére összpontosít). Ideális esetben ez a nulla másodperchez legközelebb eső érték lenne.

A probléma az, hogy a való világban általában túl sok ismeretlen változó van ahhoz, hogy ez a képlet valóban pontos legyen, mivel a különböző szoftverkonfigurációkat futtató, különböző profilú és korú hardverekkel felépített csomópontok várható élettartama széles. Mindazonáltal jó eszköz lehet a projektjéhez legmegfelelőbb klaszterterv azonosításában.

Ezekkel az információkkal könnyen előállíthatja annak becslését, hogy a szolgáltatás mekkora teljes leállással várható egy egész év során.

Ehhez kapcsolódó megfontolás, ha erőforrásait harmadik féltől származó platformszolgáltatóhoz telepíti, például a VMWare vagy az Amazon Web Services, a szolgáltató szolgáltatási szintjének megállapodása (SLA). Az Amazon EC2-je például garantálja, hogy számítási példányaik és blokkolt áruházi tárolóeszközeik legalább 99,95% -os havi üzemidő-százalékot eredményeznek, ami kevesebb, mint öt órányi leállási idő évente. Az AWS hónapokra bocsát ki hiteleket, amelyek során nem teljesítették célkitűzéseiket - bár közel sem elég ahhoz, hogy kompenzálják az állásid teljes üzleti költségeit. Ezekkel az információkkal megszervezheti az egyedi igényeinek megfelelő szintű szolgáltatás-redundanciát.

Természetesen a saját ügyfelek szolgáltatójaként szükség lehet saját SLA közzétételére az MTBF és MTTR becslései alapján.

Munkamenetkezelés

Bármely szerver-kliens kapcsolat esetén az állapotfüggő HTTP-munkamenetek által generált adatokat úgy kell menteni, hogy elérhetővé váljanak a jövőbeni interakciókhoz. A klaszterarchitektúrák komoly bonyolultságot okozhatnak ezekben a kapcsolatokban, mivel az adott szerver, amellyel az ügyfél vagy a felhasználó interakcióba lép, az egyik és a másik lépés között változhat.

Szemléltetésképpen képzelje el, hogy bejelentkezett az Amazon.com webhelyre, böngészi az LPIC-képzésről szóló könyveiket, és rendszeresen felvesz egy elemet a kosarába (remélhetőleg több példányt ebből a könyvből). Mire készen áll a fizetési információk megadására és a kijelentkezésre, előfordulhat, hogy a szerver, amelyet böngészni használt, már nem is létezik. Honnan fogja tudni jelenlegi szervere, mely könyveket választotta?

Nem tudom pontosan, hogyan kezeli ezt az Amazon, de a problémát gyakran olyan adatreplikációs eszköz segítségével kezelik, mint például a memcached

külső csomópont (vagy csomópontok). A cél az, hogy állandó hozzáférést biztosítsunk egy megbízható és következetes adatforráshoz minden olyan csomópont számára, amelyre szüksége lehet.

Ez a cikk a „ Tanítsd meg magad Linux virtualizációnak és magas rendelkezésre állásnak: készülj fel az LPIC-3 304 minősítő vizsgára ” c. Nézze meg az AWS-ről és a Linux-adminisztrációról szóló egyéb könyveimet , köztük a Linux in Action és a Linux in Motion  - egy hibrid tanfolyam, amely több mint két órányi videóból és a Linux in Action szövegének körülbelül 40% -ából áll.