Architektúratervezés felhős rendszerekre - első rész

Napjaink egyik legtöbbet elhangzó IT buzzwordje a cloud, azaz a felhő. Sokszor azt is annak nevezik, ami csak minimális technológiai átfedésben van vele, miközben semmi köze hozzá, mert felhőként jól eladható - egyes helyeken egy VMware-szervert is már vállalati felhőnek hívnak. Ez sajnos zavart okoz, néha még szakmabeliek körében is heves viták folynak arról, mi is az a felhő. Ebbe nem is folynék most bele.

Egy blogbejegyzés alatti hozzászólásokban találtam az alábbi bölcsességet, ami az ezzel kapcsolatos véleményemet kicsit ugyan kifigurázva, de eléggé kifejezi (szabad fordításban):

“A Cloud az Internet új neve”

Nem mehetsz oda egy ügyfélhez azzal az ötlettel, hogy

- Van egy jó ötletem: mi lenne ha az üzleti titkaidat felraknánk az Internetre?

Ez nem hangzik jól. Viszont ez:

- Van egy jó ötletem: mi lenne, ha a rendszereidet bemigrálnánk a felhőbe?

És már el is adtad...

Az IT Services Hungary Kft.-nél dolgozom, volt szerencsém látni a T-család fejlődését a kezdetektől. Anyacégünk, a T-Systems International egyike a piacvezető szolgáltatóknak a privátfelhő-szolgáltatások terén, többek közt ennek az építésében, üzemeltetésében veszünk részt. A privát felhő az egyik legvitatottabb terület ezen a piacon: egyesek szerint egyenesen a felhő fogalmának meghágása. Nos, ez valahol sajnos igaz.

Ha abból indulunk ki, hogy mik az elvárt tulajdonságok egy felhős szolgáltatással kapcsolatban:

• Olcsó
• Megbízható
• “Végtelen” mértékben skálázható
• Könnyen és gyorsan biztosítja az igényelt szolgáltatást
• Rugalmasan igazodik az árazás a felhasználási igényeikhez (pay per use)

Akkor a privát felhő:

• Méretgazdaságossága nem éri el a publikus felhőét, így kissé drágább
• Megbízhatósága magasabb a publikus felhőknél, bár “érzésre” az ellenkezője az igaz
• Megrendelése általában szerződésalapú, így percek helyett napok-hetek-hónapok, mire az ügyfél hozzájut az igényelt erőforrásokhoz.
• A dedikáltan, egy ügyfél számára bevásárolt berendezésnek van egy beszerzési költsége, ami ugyan egy havidíj formájában jelenik meg, de ez a költség akkor is létezik, ha az ügyfél meggondolja magát és kevesebb, vagy épp más típusú erőforrásra lenne szüksége, így az anyagi rugalmasság is csak igen korlátozottan létezik.

Mielőtt kifejteném, hogy akkor mi is az értelme, létjogosultsága a privát felhőnek, hadd magyarázzam meg a megbízhatóságról szóló pontot, ha jól tippelek, ezzel többen nem értenek egyet, de legalábbis vitathatónak találják.

Szubjektív rendelkezésre állás

A nagy publikus felhőszolgáltatók rengeteg szervert használnak. A Google vagy Microsoft esetén ez nyilvános információk alapján milliós nagyságrend, de a Facebook és a többiek sincsenek túlságosan lemaradva. A gépekbe épített alkatrészeknek van egy MTBF (mean time between failures) értéke, ami azt mutatja meg, hogy átlagosan mennyi idő telik el két meghibásodás között. Ez az érték x86 szerverek esetén hónapokban mérhető, azaz évente legalább egy meghibásodást várhatunk. Persze mondhatjátok, hogy „a mi szerverünk 5 éve ott megy a sarokban, sosem kellett hozzányúlni”. Igen, ilyen is van, de a tapasztalat az, hogy az első hónapok veszélyesek, ekkor jöhetnek ki a gyártási hibák (ez főleg a friss generációs szerverekre igaz) utána jön 2-3 év nyugi, majd rohamosan szaporodnak a hibák. Diszkek, ventilátorok szinte biztosan tönkremennek, de van, ahol például a kondenzátorok fáradása vagy a hőterhelés miatt az elektronika is kezdi megadni magát. Ha van 1 millió szervered, akkor ez percenként legalább két szerver leállását jelenti átlagosan.

Egy enterprise szolgáltatónál, ahol presztízs és komoly anyagi kérdés is, hogy például egy banki rendszer ne álljon le, klaszterek, szinkron távoli adatreplikáció és agyonszabályozott folyamatok segítik azt, hogy minimális legyen az esélye a nem tervezett szolgáltatás-kiesésnek. Ez komoly tervezést és rengeteg utógondozást igényel, tehát drága. A publikus felhőszolgáltatók ilyet nem csinálnak, látszólag mégsem állnak le soha (na jó, egy-két komoly eset azért napvilágra került). Mivel nem tudják elkerülni a hibákat, nem is teszik - együtt élnek velük. Feltalálták a szubjektív rendelkezésre állás fogalmát. Ezt általában úgy érik el, hogy az egy területről érkező felhasználókat megpróbálják különböző gépek, különböző rackek, vagy akár különböző adatközpontok közt szétszórni.

Ha épp használod a Gmail-fiókodat, ami alól kidől a szerver és emiatt megszakad a munkamenet, ránézel a melletted lévő gépre, megkérdezed a haverod, hogy neki működik-e, és mivel nála épp igen, elkönyveled, hogy a böngésződben, az operációs rendszerben, a hálózatban vagy épp benned van a hiba, de tuti nem a Google-nál, hisz a többieknek működik. Újratöltöd az oldalt vagy újraindítod a géped, miközben a háttérben az alapos monitorozásnak és a replikációnak hála akár egy teljes adatközpont elvesztése esetén is előkerül egy tartalék szerver, és mire újra megpróbálod, már minden megy is.

Miért más a privát felhő?

És hogy miért nem lehet ugyanezt privát felhőben megcsinálni? Mert míg a publikus felhős szolgáltatások egy-két jól megfogható, direkt felhőre fejlesztett workloadot futtatnak, addig a privát felhő a legtöbb esetben nem szól másról, minthogy az ügyfél matuzsálem rendszereit egy az egyben virtualizáljuk. Ezzel csak annyit nyerünk, hogy újabb (olcsóbb, kevesebb áramot fogyasztó) szerverre tehetjük őket, és a hardverek kihasználtsága 80 százalék fölé emelhető. Ugyanakkor ahány rendszer, annyi féle. Teljesen különböző rendszerek esetén egy üzemeltető nagy biztonsággal 20-30 rendszert tud üzemeltetni. Ha legalább részeiben sikerül szabványosítani, akkor ez néhány százig is felmehet. Ezt például az operációs rendszerek egységesítésével tudjuk elérni: azonos verzió, azonos patch level, azonos struktúrájú diszkkiosztás, egységes felhasználó-kezelés, stb. Egy “igazi” felhős rendszerben viszont egy üzemeltető több ezer, vagy több tízezer szerverért felel.

“Egyszerű”, mert mindegyik ugyanolyan, az utolsó bitig. De ugyanakkor félelmetes is, mert egyetlen alapkomponens hibája is végzetes lehet, és órákra, napokra tönkreteheti az egész szolgáltatást. Csak egy egyszerű, 10 megabájtos patch terítése, ami esetleg reboottal jár, komoly kihívás, ha azt egymillió példányban kell szétszórni (10 TB forgalom), és a rebootokat úgy kell menedzselni, hogy az ügyfelek ezt észre se vegyék. Ezt csak jól párhuzamosított automatizálással, orchestration rendszerek használatával lehet hatékonyan csinálni. Viszont az a rendszer, ami egy gomb megnyomásával gépek százait hozza létre, telepíti, állítja be és kapcsolja az éles szolgáltatásba percek alatt, ugyanezt le is tudja rombolni másodpercek alatt.

Nyerd meg az 5 darab, 1000 eurós Craft konferenciajegy egyikét! A kétnapos, nemzetközi fejlesztői konferencia apropójából a HWSW kraftie nyereményjátékot indít.

Elég csak egy haragos alkalmazott, aki távozásakor kielégíti a kíváncsiságát, vajon mit is csinál a felhőszolgáltató weboldalán látható “drop cluster” feliratú gomb. Ha a szolgáltatás nincs alaposan megtervezve, szolgáltatófüggetlen módon megvédve, abba egy ilyen esetben egy teljes vállalat is belerokkanhat. Gondoljunk bele abba, ha ez mondjuk a vállalatirányítási- vagy a pénzügyi rendszerünkkel történik, és viszi magával az elmúlt években felhalmozott adatokat, akár a mentésekkel együtt.

És ez az, ahol a privát felhők bekerülnek a képbe. Az ügyfelek látják a publikus felhők előnyeit, mindenhol jelen van egy folyamatos költségcsökkentési törekvés, így érzik a kényszert, hogy felhőt használjanak. Ugyanakkor a jelenlegi rendszereik tökéletesen alkalmatlanok erre, tartanak a hibrid infrastruktúra biztonsági kérdéseitől, és alapvetően szeretnek néha személyesen a szemébe nézni annak, aki életben tartja a rendszereiket. A privát felhő esetén ezek megoldására mind lehetőség van. Konkrétan rá tudunk mutatni azokra az eszközökre, ahol az adatok laknak, és arra a személyre, aki felelős a szolgáltatás minőségéért.

A cikk szerzője Balog Zsolt, vezető enterprise architect, IT Services Hungary.