A való világban előfordulhatnak olyan helyzetek, amikor a szerverek teljesítménye csökkenhet a hirtelen megnövekedett forgalomtól kezdve a hirtelen áramkimaradásig terjedő események miatt. Ez sokkal rosszabb is lehet, és a szerverei megbénulhatnak – függetlenül attól, hogy az alkalmazásai felhőben vagy fizikai gépen vannak-e elhelyezve. Az ilyen helyzetek elkerülhetetlenek. Ahelyett azonban, hogy abban reménykedne, hogy nem fordul elő, valójában azt kellene tennie, hogy felkészüljön arra, hogy rendszerei ne találkozzanak meghibásodással.
A probléma megoldása a nagy rendelkezésre állású (HA) konfiguráció vagy architektúra használata. A nagy rendelkezésre állású architektúra egy olyan megközelítés, amely egy rendszer összetevőinek, moduljainak vagy szolgáltatásainak olyan megvalósítását határozza meg, amely nagy terhelés esetén is optimális működési teljesítményt biztosít. Bár a HA-rendszerek megvalósításának nincsenek rögzített szabályai, általában van néhány jó gyakorlat, amelyet követni kell, hogy a legkevesebb erőforrásból is a legtöbbet hozza ki.
Miért van rá szükség?
Mondjuk meg a leállási idő fogalmát, mielőtt továbblépnénk. A leállási idő az az időszak, amikor a rendszer (vagy a hálózat) nem használható, vagy nem reagál. Az állásidő hatalmas veszteségeket okozhat egy vállalatnak, mivel minden szolgáltatásuk leáll, amikor a rendszerük nem működik. 2013 augusztusában az Amazon 15 percre leállt (mind a webes, mind a mobilszolgáltatások), és végül percenként több mint 66000 dollár veszteséget szenvedett el. Ezek óriási számok, még egy olyan méretű vállalat esetében is, mint az Amazon.
A leállásoknak két típusa van – tervezett és nem tervezett. A tervezett leállás karbantartásból adódik, ami elkerülhetetlen. Ide tartozik a javítások alkalmazása, a szoftverek frissítése vagy akár az adatbázis sémájának módosítása. A nem tervezett leállást azonban valamilyen előre nem látható esemény, például hardver- vagy szoftverhiba okozza. Ez történhet áramkimaradás vagy egy komponens meghibásodása miatt. A nem tervezett leállások általában nem számítanak bele a teljesítményszámításokba.
A nagy rendelkezésre állású architektúra megvalósításának elsődleges célja, hogy a rendszer vagy az alkalmazás úgy legyen konfigurálva, hogy minimális vagy semmilyen leállási idővel ne legyen képes kezelni a különböző terheléseket és a különböző meghibásodásokat. Ennek elérésében több komponens is segít, amelyeket röviden tárgyalunk.
Hogyan mérik a rendelkezésre állást?
A felhőinfrastruktúrát teljes mértékben kihasználni szándékozó szervezeteknek képesnek kell lenniük a 24/7-es rendelkezésre állásra vonatkozó igények kielégítésére is. A rendelkezésre állás a rendszerek rendelkezésre állási idejének százalékában mérhető.
x = (n – y) * 100/n
Hol n a naptári hónap összes percének száma, y pedig az adott naptári hónapban a szolgáltatás elérhetetlenségének összes perce. A magas rendelkezésre állás egyszerűen olyan komponensre vagy rendszerre utal, amely kívánatos hosszú ideig folyamatosan működőképes. A széles körben elterjedt, de szinte lehetetlen elérni egy termék vagy rendszer rendelkezésre állásának szabványát “öt 9-es” (99,999 százalékos) rendelkezésre állásnak nevezik. A magas rendelkezésre állás követelmény minden olyan vállalkozás számára, amely meg kívánja védeni vállalkozását a rendszer kieséséből eredő kockázatokkal szemben. Ezek a kockázatok több millió dolláros bevételkieséshez vezethetnek.
Tényleg megéri a pénzt?
Az, hogy a nagy rendelkezésre állású architektúra nagyobb teljesítményt biztosít, rendben van, de ennek nagy ára is van. Fel kell tennie magának a kérdést, hogy pénzügyi szempontból indokoltnak tartja-e a döntést.
Döntést kell hozni arról, hogy a többlet üzemidő valóban megéri-e azt az összeget, amit rá kell költeni. Fel kell tennie magának a kérdést, hogy az esetleges leállások milyen károkat okozhatnak a vállalatának, és mennyire fontosak a szolgáltatásai a vállalkozás működtetésében.
Hogyan érjük el ezt?
Most, hogy úgy döntött, hogy belevág, beszéljük meg a megvalósítás módjait. Nem intuitív módon több komponens hozzáadása egy rendszerhez nem segít a rendszer stabilabbá tételében és a magas rendelkezésre állás elérésében. Valójában az ellenkezőjéhez vezethet, mivel a több komponens növeli a meghibásodások valószínűségét. A modern tervek lehetővé teszik a munkaterhelés elosztását több példányra, például hálózatra vagy fürtre, ami segít az erőforrás-felhasználás optimalizálásában, a teljesítmény maximalizálásában, a válaszidő minimalizálásában és bármely rendszer túlterhelésének elkerülésében a terheléselosztás néven ismert folyamat során. Ez magában foglalja a tartalék erőforrásra, például egy szerverre, komponensre vagy hálózatra való átállást is az aktív erőforrás meghibásodása esetén, amit Failover-rendszereknek nevezünk.
Multi alkalmazásszerverek használata:
Képzelje el, hogy egyetlen szerverrel rendelkezik a szolgáltatásai nyújtására, és a forgalom hirtelen megugrása annak meghibásodásához (vagy összeomlásához) vezet. Ilyen helyzetben a szerver újraindításáig nem tud több kérést kiszolgálni, ami leálláshoz vezet.
A nyilvánvaló megoldás itt az, hogy az alkalmazást több szerverre telepíti. A terhelést úgy kell elosztani ezek között, hogy egyik sem legyen túlterhelt, és a kimenet optimális legyen. Az alkalmazás egyes részeit is telepítheti különböző szerverekre. Lehet például külön szerver a levelek kezelésére, vagy külön szerver a statikus fájlok, például képek feldolgozására (mint egy Content Delivery Network).
Adatbázisok skálázása:
Az adatbázisok a legnépszerűbb és talán az egyik legegyszerűbb koncepciójú módja a felhasználói adatok tárolásának. Nem szabad elfelejteni, hogy az adatbázisok ugyanolyan fontosak a szolgáltatások számára, mint az alkalmazáskiszolgálók. Az adatbázisok külön szervereken futnak (mint például az Amazon RDS), és hajlamosak az összeomlásokra is. Ami még rosszabb, hogy az adatbázisok összeomlása a felhasználói adatok elvesztéséhez vezethet, ami költségesnek bizonyulhat.
A redundancia olyan folyamat, amely a hibák felismerhetőségének elérésével és a közös okból bekövetkező hibák elkerülése révén magas szintű rendelkezésre állású rendszereket hoz létre. Ezt olyan mellékszerverek fenntartásával lehet elérni, amelyek be tudnak ugrani, ha a fő kiszolgáló összeomlik. Az adatbázisok skálázásának másik érdekes koncepciója a sharding. A shard egy horizontális partíció az adatbázisban, ahol ugyanazon tábla sorai, amely aztán külön szerveren fut.
Diverzifikált földrajzi helyek:
Az alkalmazások, majd az adatbázisok skálázása egy igazán nagy lépés előre, de mi van akkor, ha az összes szerver ugyanazon a fizikai helyen van, és valami szörnyűség, például természeti katasztrófa éri azt az adatközpontot, ahol a szerverek találhatók? Ez potenciálisan hatalmas leállásokhoz vezethet.
Elkerülhetetlen tehát, hogy szervereit különböző helyszíneken tartsa. A legtöbb modern webes szolgáltatás lehetővé teszi a szerverek földrajzi helyének kiválasztását. Bölcsen kell választania, hogy szerverei az egész világon el legyenek osztva, és ne egy területre lokalizálódjanak.
Ezzel a bejegyzéssel megpróbáltam megérinteni azokat az alapgondolatokat, amelyek a nagy rendelkezésre állású architektúra eszméjét alkotják. Végső soron nyilvánvaló, hogy egyetlen rendszer sem képes minden problémát megoldani. Ezért alaposan fel kell mérnie a helyzetét, és el kell döntenie, hogy milyen lehetőségek felelnek meg nekik a legjobban. Reméljük, hogy ez bevezette Önt a magas rendelkezésre állási architektúra világába, és segített eldönteni, hogyan valósítsa meg ezt a saját maga számára.
Melyek a legjobb gyakorlatok?
A rendszerhibák megfékezése és a tervezett és nem tervezett leállások kordában tartása érdekében a magas rendelkezésre állási (HA) architektúra használata erősen ajánlott, különösen a kritikus fontosságú alkalmazások esetében. A rendelkezésre állási szakértők ragaszkodnak ahhoz, hogy bármely rendszer magas rendelkezésre állású legyen, annak részeit jól kell megtervezni és szigorúan tesztelni kell. A nagy rendelkezésre állású architektúra megtervezése és későbbi megvalósítása nehéz lehet, tekintettel a szoftver-, hardver- és telepítési lehetőségek széles skálájára. A sikeres erőfeszítés azonban általában egyértelműen meghatározott és átfogóan megértett üzleti követelményekkel kezdődik. A kiválasztott architektúrának képesnek kell lennie a biztonság, a skálázhatóság, a teljesítmény és a rendelkezésre állás kívánt szintjének teljesítésére.
Az egyetlen módja annak, hogy garantáljuk a számítási környezetek kívánatos szintű működési folyamatosságát a termelési órák alatt, az, hogy magas rendelkezésre állással tervezzük meg őket. Az architektúra megfelelő megtervezésén túl a vállalatok a nagy rendelkezésre álláshoz ajánlott legjobb gyakorlatok betartásával tarthatják online a létfontosságú alkalmazásokat.
- Adatok biztonsági mentése, helyreállítása és replikálása
A rendszerhibák ellen védő jó adatvédelmi terv jellemzője a megbízható biztonsági mentési és helyreállítási stratégia. Értékes adatokat soha nem szabad megfelelő biztonsági mentés, replikáció vagy az adatok újbóli létrehozásának képessége nélkül tárolni. Minden adatközpontnak előre meg kell terveznie az adatvesztést vagy -rongálódást. Az adathibák ügyfél-hitelesítési problémákat okozhatnak, károsíthatják a pénzügyi számlákat és később az üzleti közösség hitelességét. Az adatintegritás fenntartására ajánlott stratégia az elsődleges adatbázis teljes biztonsági másolatának elkészítése, majd a forráskiszolgáló inkrementális tesztelése adatsérülések szempontjából. A teljes biztonsági mentések készítése a katasztrofális rendszerhiba utáni helyreállítás élvonalába tartozik.
- Klaszterezés
Még a legjobb minőségű szoftverfejlesztés mellett is minden alkalmazásszolgáltatás valamikor biztosan meghibásodik. A magas rendelkezésre állás lényege az alkalmazásszolgáltatások hibáktól független nyújtása. A klaszterezés azonnali meghibásodás esetén azonnali átállású alkalmazásszolgáltatásokat biztosíthat. Egy “klasztertudatos” alkalmazásszolgáltatás több kiszolgálóról is képes erőforrásokat hívni; a fő kiszolgáló kiesése esetén egy másodlagos kiszolgálóra esik vissza. A nagy rendelkezésre állású fürt több csomópontot tartalmaz, amelyek megosztott adatmemória-rácsokon keresztül osztják meg az információkat. Ez azt jelenti, hogy bármelyik csomópont leválasztható vagy lekapcsolható a hálózatról, és a fürt többi része normálisan működik tovább, amíg legalább egy csomópont teljesen működőképes. Minden egyes csomópont külön-külön frissíthető és újra csatlakoztatható, miközben a fürt működik. A fürt megvalósításához szükséges további hardver beszerzésének magas költségei enyhíthetők egy virtualizált fürt létrehozásával, amely kihasználja a rendelkezésre álló hardvererőforrásokat.
- Hálózati terheléselosztás
A terheléselosztás hatékony módja a kritikus webes alkalmazások rendelkezésre állásának növelésének. A szerverhibás példányok észlelésekor a forgalom automatikus újraelosztásakor zökkenőmentesen helyettesíthetők a még működő szerverekre. A terheléselosztás nemcsak magas rendelkezésre állást eredményez, hanem megkönnyíti a fokozatos skálázhatóságot is. A hálózati terheléselosztás megvalósítható “pull” vagy “push” modellel. Ez elősegíti a szolgáltatási alkalmazások magasabb szintű hibatűrését.
- Fail Over Solutions
A magas rendelkezésre állású architektúra hagyományosan lazán összekapcsolt szerverekből áll, amelyek rendelkeznek failover képességekkel. A failover alapvetően egy tartalék működési mód, amelyben egy rendszerkomponens funkcióit egy másodlagos rendszer veszi át abban az esetben, ha az elsődleges rendszer – akár meghibásodás, akár tervezett leállás miatt – offline állapotba kerül. A “hideg átállás” akkor következik be, amikor a másodlagos szerver csak az elsődleges szerver teljes leállítása után indul el. A “forró átállás” akkor következik be, amikor az összes kiszolgáló egyszerre fut, és a terhelés teljes egészében egy adott időpontban egyetlen kiszolgálóra irányul. Mindkét esetben a feladatok automatikusan átkerülnek egy tartalék rendszerelemre, hogy a folyamat a végfelhasználó számára a lehető legzökkenőmentesebb maradjon. Az átállás a DNS-en keresztül, jól ellenőrzött környezetben kezelhető.
- Geográfiai redundancia
A földrajzi redundancia az egyetlen védelmi vonal, ha a szolgáltatáskiesés megelőzéséről van szó olyan katasztrofális események, például természeti katasztrófák esetén, amelyek rendszerleállást okoznak. A georeplikációhoz hasonlóan több kiszolgálót telepítenek földrajzi szempontból különböző helyszínekre. A helyszíneknek globálisan elosztottnak kell lenniük, nem pedig egy adott területre lokalizáltnak. Alapvető fontosságú, hogy az egyes helyszíneken független alkalmazáscsomagokat futtassunk, hogy az egyik helyszín meghibásodása esetén a többi tovább működhessen. Ideális esetben ezeknek a helyszíneknek egymástól teljesen függetlennek kell lenniük.
- Tervezzünk a meghibásodásra
Mindamellett, hogy a nagy rendelkezésre állásra vonatkozó legjobb gyakorlatok alkalmazása lényegében a meghibásodásra való tervezést jelenti; vannak más intézkedések is, amelyeket egy szervezet megtehet, hogy növelje felkészültségét a leálláshoz vezető rendszerhiba esetére. A szervezeteknek meg kell őrizniük a meghibásodási vagy erőforrás-fogyasztási adatokat, amelyek felhasználhatók a problémák elkülönítésére és a trendek elemzésére. Ezeket az adatokat csak az operatív munkaterhelés folyamatos nyomon követésével lehet összegyűjteni. Helyreállítási help desket lehet felállítani a problémákkal kapcsolatos információk összegyűjtésére, a problématörténet megállapítására és a problémamegoldások azonnali megkezdésére. A helyreállítási tervet nemcsak jól dokumentáltnak kell lennie, hanem rendszeresen tesztelni is kell, hogy a nem tervezett megszakítások kezelése során biztosítsa annak gyakorlati alkalmazhatóságát. A személyzet rendelkezésre állástervezéssel kapcsolatos képzése javítja a magas rendelkezésre állású architektúrák tervezésével, telepítésével és karbantartásával kapcsolatos készségeiket. Biztonsági irányelveket is be kell vezetni, hogy megfékezzék a biztonsági rések miatti rendszerleállások eseteit.
Példa:
Az alábbi ábra bemutatja, hogyan lehet a FileCloud-kiszolgálókat magas rendelkezésre állásra konfigurálni a szolgáltatás megbízhatóságának javítása és az állásidő csökkentése érdekében. További részletekért kattintson ide.