Cluster és High Availability kezdőknek

A következő írásommal megint csak kezdő, illetve informatikában képzetlenebb emberekhez szeretnék szólni. Olyan sokszor esik szó a Cluster és High Availability rendszerekről, hogy egy részletes írásban be kívántam mutatni, mi is ez. Az iromány nagyon bagatell és egyszerű módon kíván fogalmazni, így kicsit is gyakorlott informatikusok számára zavaró is lehet. Bízom benne, többen hasznos olvasmányra lelnek benne.

Mi az a HA és miért kell?

A HA a magas rendelkezésre állás, azaz High Availability rövidítése. Olyan rendszereket, vagy szolgáltatásokat látunk el ezzel a kifejezéssel, melyeknek állandóan működniük kell, és hiba esetén sem megengedett, hogy a szolgáltatás ne legyen elérhető.

Mindenki használ ilyen rendszereket, ha nem is tud róla. Amikor valaki megnyitja az index.hu weboldalt, akkor egy olyan webes szolgáltatást néz meg, ami magas rendelkezésre állású technológiákkal van megvalósítva.

Másik jó példa a netbank. Amikor valaki saját bankja netes szolgáltatásába jelentkezik be, az is egy magas rendelkezésre állású rendszert fog használni.

Mi az a SPOF?

A SPOF egy rövidítés. A Single Point Of Failure rövidítése, ami annyit tesz, hogy a rendszerünkben, egyetlen pont meghibásodásával a teljes rendszer meghibásodik. Nézzünk rá példát:

A fenti képen jól látszik, hogy a kliensek a baloldalon, illetve az Alkalmazás Szerver a jobb oldalon, egyetlen hálózati csomópontba csatlakozik. Amennyiben ez meghibásodik, az alkalmazás szerver elérhetetlenné válik minden kliens számára.

!! Minden olyan rendszer, ahol egyetlen eszköz, vagy összeköttetés meghibásodásával az egész rendszer működése válik lehetetlenné az nem magas rendelkezésre állású rendszer !!

Akkor nézzünk egy példát egy magas rendelkezésre állású rendszerre.

Ahogy látjátok, ez egy bonyolult rendszer. Sajnos nincs egyszerű magas rendelkezésre álló megoldás, de ennek a miértjét a továbbiakban fogjuk kivesézni. A fenti ábrán látszik, hogy minden egyes szinten, ugyan arra a feladatra két eszköz is van. Viszont nem elengedő, hogy mindenből kettő van, minden szinten lévő eszköz minden alatta-felette lévő eszközzel kapcsolatban kell, hogy álljon. A fenti ábrában akármelyik szinten egyetlen eszközt, vagy kapcsolatot, ha kiiktatunk, a rendszer maga képes lesz működni.

Mi lehet SPOF?

Remélem, látszik már a Single Point Of Failure mennyire fontos szerepet fog betölteni a cluster életében. Ugyanis, ha akárhol találunk SPOF-ot, akkor az a cluster potenciális veszélynek van kitéve. A későbbiekben tárgyalt rendelkezésre állási időt nem lehet garantálni.

Nézzük meg milyen tényezőkre is kell figyelni akkor, amikor SPOF-t keresünk egy rendszerbe.

Hardware

Mielőtt Cluster-ről és több tényezőről kezdünk beszélni, fontos egy gépen belüli redundanciáról is beszélni. A redundancia egy új kifejezés. Egy elem, vagy alkatrész akkor redundáns, ha meghibásodása esetén is tovább üzemel a rendszer. Ez ténylegesen azt jelenti, hogy egynél több ilyen alkatrész van, ami át tudja venni a másik szerepét hiba esetén.

Egy nyitott szerverről láthatunk egy képet a fenti ábrán. Ahogy látszik, a gép szimmetrikus felépítésű. A baloldal megegyezik a jobb oldallal. Minden egyes alkatrészből, processzor, memória, diszk, tápellátás tehát egynél több van beszerelve. Pont azért, hogy ha elromlik valamelyik alkatrész, akkor se keljen megállni a szervernek és cluster-nek működésbe lépnie.

Természetesen az is egy fontos szempont ilyenkor, hogy az alkatrészeket lehet-e menet közben cserélni. Azokat az egységeket, amiket a szerver leállítása nélkül, menet közbe lehet cserélni, azokat HOT SWAP komponensnek nevezzük.

Felhasználó (USER)

Vicces módon egy SPOF lehet a felhasználó is. Ugyanis abban az esetben, ha a szolgáltatás már nem azon a gépen érhető el, amiről a felhasználó tud, akkor a szolgáltatás lehet, hogy máshol érhető el, de arról a felhasználónak is tudnia kell. Illetve az a legjobb, ha ez rejtve marad, és a felhasználó automatikusan az új környezetben futó szolgáltatást éri el.

Környezet (ENVIRONMENT)

Több gépes szolgáltatás esetén fontos természetesen az is, hogy a gépek milyen távol vannak egymástól. Hiába valósítunk meg cluster környezetet, ha a két gép ugyan abban a terem, ugyan azon szekrényében található. Egy tűz esetén mindkettő elpusztulhat. Ha két külön teremben helyezzük el, már kivédtük azt, hogyha az egyik teremmel történik valami, de azt még mindig nem, hogy mi történik akkor, ha az épülettel magával. Rakhatjuk a két gépet két külön városba is, vagy két külön kontinensre. Ilyenkor viszont biztosítanunk kell a két gép közötti kommunikációs kapcsolatot is, ami természetesen egyre nehezebb és drágább, minél messzebb van a két gép.

Ezért fontos, hogy magas rendelkezésre állású rendszert úgy építsünk, hogy tisztába vagyunk az igényekkel, és a ráfordítható költségekkel.

A HA mint fogalom mérése

A magas rendelkezésre állású rendszereket valahogy mérni kell. Egy mérőszámot szokás használni, ami azt akarja kifejezni, hogy egy évben a szolgáltatás mennyi időt volt elérhető. Mennyi ideig volt elérhető az ügyfelek részére. Legyen ez hajnalok hajnala, vagy piros betűs ünnep. Nem számít. Egy magas rendelkezésre állású rendszernek mindig mennie kell.

Egy évben 365.5 nap van Ez 525 949 perc, és 31 536 000 másodperc. Amikor valaki magas rendelkezésre állású rendszert vásárol, vagy ad el akkor egy százalékos arányban kifejezett rendelkezésre állást biztosít. Azaz, az év mennyi százalékában képes biztosítani a technológiájával, hogy az a szolgáltatás elérhető lesz.

Az informatikusok az első oszlopban lévő névvel szoktak hivatkozni egy szolgáltatásra, ami értelem szerűen, azt kívánja reprezentálni, hogy a százalékos rendelkezésre állás mérőszámában, mennyi kilences található. Látható, hogy három kilences után már egy évben csupán kevesebb, mint 9 óra kiesés megengedett. Ehhez pedig nagyon biztos hardware-ket, softwarek-et és megfelelő távolságban lévő helyeket kell használnunk. Ami pedig még fontos, hogy a környezethez megfelelő tudású adminisztrátoroknak kell elérhetőnek lenniük, reggel, este, ünnepnapokon, és hétvégén is.

Cluster Komponensek

Itt az ideje, hogy szót ejtsünk arról, miből is áll egy cluster rendszer. Milyen elemeknek kell kapcsolódnia milyen elemekhez. Mennyi kell a kapcsolatra van szükség és mi miatt. Induljunk el tehát az alapoktól és próbáljunk meg redundáns rendszert alkotni.

Szerver

Természetes igény, hogy egy fizikai gép helyett többet használjunk. Minimum kettőt. Így ha valami oknál fogva a szerver működésképtelenné válna, az alkalmazás, vagy a szolgáltatás induljon el a másikon. Természetesen a két szerver egymástól függetlenen kell, hogy legyen. Minél távolabb vannak egymástól helyileg, annál kisebb az esély, hogy ugyan az a probléma mindkettőre kihat.

Operációs Rendszer

Természetesen a két független szerverre két független operációs rendszert kell installálni. Itt még a két gép két különböző gép, semmi kapcsolat nincs köztük.

Cluster Software

A két gépet kapcsolatba kell hozni egymással. Ehhez a kapcsolathoz szükséges egy program, egy software. Ez lesz a cluster software. Ezt külön kell installálni és beállítani. A cluster software feladat lesz, hogy egyik részről definiálja a cluster által kezelt alkalmazásokat. Illetve, hogy egy ellenőrző mechanizmust valósítson meg. Fel tudja ismerni, hogy mikor vált elérhetetlenné a társa, és kell átvennie a másik feladatát.

Storage

Ahhoz, hogy a szolgáltatás hiba esetén át tudjon menni a másik gépre, ahhoz szükséges, hogy az alkalmazás által használt adatok mindkét gép számára elérhetőnek legyenek. Ehhez, legpraktikusabb egy közös storage-t használni. Így az adatok egy közös helyen érhetőek el mindkét gép számára, és hiba esetén az egyik ott tudja folytatni, ahol a másik abbahagyta.

Hálózat

Természetesen hálózatra is szükség lesz. Egy részről a két gép között szükség van egy INTERCONNECT vagy más néven HEARTBEAT vonalra. Ez csak arra szolgál, hogy a cluster képes legyen egymás közötti kommunikációra, és ezen a vonalon ellenőrzik a gépek egymást, hogy elérhetőek-e.

A detektálás, nagyon egyszerű módon történik. Az egyik küld egy Heartbeat-et, egy szívdobbanást a másiknak, és ha a másik válaszol, akkor nincs semmi gond. Amennyiben nem válaszol, abban esetben cselekednie kell a gépnek, és át kell vennie a feladatát.

Természetesen a gépeknek, nem csak interconnect, hanem publikus hálózati csatlakozásának is lennie kell. Ezen lesz elérhető a gép, és természetesen a rajta futó alkalmazás / szolgáltatás a felhasználók számára.

A fenti képen a kék vonalak szimbolizálják a Storage kapcsolatot. Ez lehet DAS/NAS/SAN.
A kettő darab fekete vonal jelenti a két különálló Interconnect / Heartbeat vonalat. A Zöldel jelzett, felhőbe tartó vonalak, pedig a kettő darab publikus hálózati elérést.

Alkalmazás

Természetesen a rendszer legfontosabb része, ami miatt az egészet építettük, az az alkalmazás. Az alkalmazást a cluster kell, hogy indítsa és felügyelje, hogy megfelelő képen működik-e.

Amennyiben a cluster hibát érzékel az alkalmazás működésében, az alkalmazást el kell indítani a másik gépen.

Ahogy, a lenti képen is látszik FAILOVER fog történni, ami annyit tesz, hogy az alkalmazás működése „átkapcsolódik” (switch) a másik gépre. Ez ténylegesen annyit tesz, hogy az alkalmazás el fog indulni a Szerver2-n, a közös storage-n tárolt adatok által pedig onnan tud minden folytatódni, ahol a másikon meghibásodott.

Cluster Megoldások

Működése szempontjából két nagy csoportba oszthatjuk a Cluster-eket.

Failover

A fent is bemutatott Failover megoldás szerint egy alkalmazás, csupán egyetlen gépen futhat egy időben. Ezt nevezzük aktív node-nak. Az összes többi gép, ami nem futtatja az alkalmazást, a passzív node. Amikor az aktív node-n bármilyen probléma történik, az alkalmazás egy passzív node-on képes elindulni, automatikusan.

Scalable

A Failover megoldásnál, mindig vannak passzív gépek, amik egész addig nem látnak el feladatot, míg az aktív gépről nem kapcsolódik át az alkalmazás. Így azon erőforrásokat normál esetben nem használjuk ki. Erre kíván megoldást adni a Scalable, azaz skálázható cluster.

Skálázható esetben van egy Load Balancer, ami vagy egy külön eszköz, vagy valamelyik gép is elláthatja ezt a feladatot. A Load Balancer egy terhelés eloszlást hajt végre. Minden kérés ehhez az eszközhöz érkezik, ami tovább irányítja azt egy másik gépnek. A nevéből is adódóan, ezeket a különböző kéréseket, mindig másik gép számára fogja továbbítani, így elosztva több gép között a terhelést.

Hiba esetén természetesen a Load Balancer-nek tudnia kell, hogy az egyik gép nem elérhető, és annak nem kell több kérést intéznie. A Load Balancer-nek hála így a hibakezelés is megoldott, és a mindegyik gép részt veszt aktívan a munkában.

A Load Balancer funkciót betöltő eszközt ilyenkor Frontend-nek, a Load Balancer mögötti gépeket Backend-nek nevezzük.

Split Brain

A split brain egy cluster környezetben használatos kifejezés. A helyzet akkor áll elő, amikor két vagy több gép nem képes egymással kommunikálni. Ez két dolgot jelenthet. Az első, amikor a másik gép ténylegesen működésképtelen és társának át kell vennie az alkalmazás futtatását. A második pedig, amikor csak a kettejük közötti Interconnect / Heartbeat kapcsolat szakadt meg, és a társának nem kell semmit csinálnia. Abban az esetben, ha ilyenkor mégis elindítja az alkalmazást a másik gép is, azzal csak azt érjük el, hogy összeakad a két helyen is futtatott alkalmazás, és egyik helyen sem fog működni. Ez a helyzet az, amit Split Brain-nak nevezünk.

Értelem szerűen el kell kerülnünk a Split Brain helyzeteket. Ehhez szükségünk van egy újabb kommunikációs csatornára, ami végső esetben segítségül hívhatunk ilyen helyzetekben. Mivel cluster nincs közös Storage nélkül, ezért érdemes a Storage kapcsolatot használni, mint alternatív kommunikációs eszköz.

A cluster-be szervezett gépeknek tehát úgynevezett QUORUM-ot kell definiálni, ami a Storage diszkek lesznek. Ezekre, a minden rendszer által elérhető diszkekre, mindegyik gép rá fogja rendszeresen írni a saját egyedi kulcsát. Amennyiben megszakad az interconnect / heartbeat kapcsolat, a többiek csak ellenőrzik a közös storage-n a kulcsokat. Amennyiben megtalálható a másik kulcsa, abban az esetben azt feltételezi, hogy a másik működik, hiszen ha nem működne, nem tudna egy friss kulcsot ráírni a Storage-ra. Amennyiben nem található friss kulcs, abban az esetben pedig nyugodtan elindíthatják az alkalmazást a másik helyett.

Service Group / Resource Group

Eddig megbeszéltük, hogy miért kell cluster-t használnunk, milyen egységekre van szükségünk ahhoz, hogy cluster-t üzemeltessünk, és a cluster-nek milyen fajtái vannak. Most nézzük meg, hogy ha minden feltétel adott, a cluster software-ben, hogy kell definiálnunk egy működő cluster szolgáltatást.

Eddigiekben mindig, mint alkalmazás beszéltem arról a szolgáltatásról, amit cluster környezetbe akartunk integrálni. Viszont, ahhoz hogy az a szolgáltatás teljesen működőképes legyen, több mint egy alkalmazásra lesz szükségünk, amit adott esetben a cluster elindít. A szolgáltatás kisebb építő elemekből fog állni.

Vegyünk egy egyszerű és nem túl reális példát. Szeretnénk zenét hallgatni az irodában. Közös storage-n tároljuk a zeneszámainkat, és clusterbe szervezünk két gépet. Az alkalmazás egy egyszerű zenelejátszó alkalmazás lesz, ami a Storage-n tárolt zeneszámok mellett, egy listából játssza folyamatosan a zenét. Amennyiben meghibásodik az egyik gép, a másik kezdi el játszani a számokat.

Fontos, hogy ilyen Clusterbe épített szerviz több is lehet, nem csak egy. Két gépből álló clusterbe integrálhatunk egy Zenelejátszó szolgáltatás, és egy hálózati nyomtató szolgáltatás.

A zenelejátszó szolgáltatás azért felel, hogy mindenképp az egyik gépen szóljon a zene, a nyomtató szolgáltatás pedig azért, hogy mindkét gépre rákötött nyomtató elérhető legyen az irodában hálózati nyomtatásra.

Állapotok

Tehát a clusteren ezek a Service Group vagy Resource Groupok valamilyen állapotban kell, hogy legyen.

Online

Ha valamelyik Service Group valamelyik gépen Online, az azt jelenti, hogy ott érhető el és ott fut.

Offline

Ha valamelyik Service Group Offline, az azt jelenti, hogy azon a gépen az a szolgáltatás nem érhető el.

Természetesen, ha egy Service Group egyik gépen Offline a másikon Online, az nem azt jelenti, hogy egyáltalán nem működik. Csak annyit, hogy az egyik gépen megy, és hiba esetén a másikra megy át. A szolgáltatás abban az esetben nem működik, amennyiben egyik gépen sem Online az állapota.

Failed

Amennyiben egy Service Group, egyik gépen hiba miatt leállt, azt a cluster megjelöli hibásnak. Amíg az adminisztrátor kézzel nem törli ki ezt a hibás bejegyzést, addig a cluster nem fogja megpróbálni visszakapcsolni erre a gépre. Mondván, hogy ahol már történt hiba, ott meg se próbálja a Service Group-ot elindítani, amíg valaki ki nem javította a hibát.

Partial

Ezt nem minden Cluster program ismeri. Amennyiben egy Service Group Partial állapotban van, az annyit tesz, hogy a csoporthoz tartozó Resourcek közül nincs mind Online állapotban, de van néhány, ami igen.

Switch

Ez nem állapot. Azt a folyamatot, amikor a Service Group átvált egy másik gépre, Switch-nek vagy átkapcsolásnak nevezzük. Ez történhet hiba miatt automatikusan a cluster által indítva. Illetve történhet az adminisztrátor által, manuálisan átkapcsolva.

Mi a Resource?

Végül beszéljünk egy kicsit a Service Group / Resource Group-okat építő elemekről a Resource-kről. A resource olyan elemi erőforrás, amiket ha csoportba foglalunk, és megfelelő függőséget alakítunk ki köztük, akkor az egy szolgáltatás működését fogja biztosítani.

Nézzük néhány elemi resource típust.

Hálózati Kapcsolat

Egy külön resource-t szokás beállítani arra, hogy ellenőrizze, hogy a megadott hálózat elérhető-e. Amennyiben meghibásodna, akkor ez a resource a Service Group-ban FAILED állapotú lesz, ami együtt járhat azzal, hogy az egész csoport emiatt FAILED lesz, és a Service Group el akar indulni a másik oldalon.

IP cím

Külön resource felel azért, hogy egy IP cím elérhető legyen a gépen, ami nem magát a gépet fogja azonosítani, hanem a szolgáltatásunkat. Ez azért fontos, mert amennyiben a Service Group egy másik gépen indul el, abban az esetben a felhasználónak erről nem kell tudomást szerezni. Ehhez viszont az kell, hogy a régi hálózati címen legyen elérhető, ami azt jelenti, hogy a Service Group-hoz a gépektől független IP címre van szükség. Ez a cím mindig pluszban fog megjelenni azon a gépen, ahol a Service Group online.

Diszk

Egy resource-ra van szükség, ahhoz hogy megbizonyosodjunk arról, hogy a tárhely elérhető és használható.

Tárhely Felcsatolása

Amennyiben a tárhely elérhető, egy külön resource lesz, ami felcsatolja azt az adott gépre, ezáltal a megfelelő file-ok elérhetőek lesznek a gépen.

Alkalmazás

Ezek után természetesen szükség lesz egy olyan resource-re, ami már a tényleges alkalmazás elindulásáért / leállításáért / és monitorozásáért felelős.

Beépített vagy saját Application Resource

Alkalmazások kezeléséhez a Cluster Software szokott előre elkészített Alkalmazás Resource-ket adni. Egy Apache, Oracle DB, és hasonló népszerű alkalmazásokhoz használhatunk ilyen resource-ket. Ilyenkor nem kell nekünk teljesen megírni az indító / leállító / monitorozó scriptet, mert a gyártó maga felel ezekért. Ezeknél a beépített Application Resource-knál minimális információt kell megadnunk.

Ezen túl van általános Application Resource. Ilyenkor bármilyen tetszőleges alkalmazást integrálhatunk a clusterbe. Ebben az esetben viszont az indító scriptet / leállító scriptet / illetve monitorozó scriptet saját magunknak kell megírni.

Resource Függőségek

Fontos, hogy a fent említett resource-k közül, még rengeteg létezik. Mind-mind egy elemi funkciót kínálnak. Hasonló képen, mint a LEGO kockák. Külön-külön is léteznek, de megfelelő sorrendben csoportba szervezve új alakot képesek formába önteni.
Ahogy a LEGO elemeknél is, úgy a Resourcek-nál sem mindegy, hogy melyik résszel kezdünk, és mi után mi következik. Ezt a fajta sorrendiséget a Resource-k függőségével adhatjuk meg.
Definiálhatjuk, hogy egy resource ne próbáljon meg elindulni, amíg egy másik nem indult már el. Például nincs értelme felcsatolni egy tárhelyet, ha nem ellenőriztük le, hogy a diszkek elérhetőek. Nincs értelme felhúzni IP címet, ha nem ellenőriztük le, hogy a hálózati csatoló elérhető. Ami pedig a legfontosabb, amíg minden más feltétel nem teljesült, nincs értelme az alkalmazást elindítani, hisz az csak akkor tud megfelelő képen futni, amennyiben minden adott a működéshez.

Cluster típusok különböző platformokon

Windows

Windows Cluster
Veritas Cluster (VCS)

Linux

Linux HA
Veritas Cluster

Solaris

Oracle (SUN) Cluster
Veritas Cluster (VCS

AIX

HACMP / PowerHA
Veritas Cluster (VCS)

HP-UX

ServiceGuard Cluster
Veritas Cluster (VCS)

Összegzés

Remélem sikerült a laikusabb olvasó számára bevezetni a Cluster-t és a magas rendelkezésre állást. Nem könnyű dolog minden technikai utalás nélkül bemutatni egy igazán komplex rendszert. Bízom benne az életből merített példák és párhuzamok sikeresen rávilágítottak a felmerülő kérdésekre. A legtöbb olyan cikk, ami egy adott platformon, egy adott cluster software beállítását mutatja be, az szintén ezek az elvek szerint van felépítve. Aki ezek után érez magában még további érdeklődést, az keresgéljen a többi írás között.