Egy technikai ember számára lenyűgöző élmény egy olyan videót megnézni amely a Microsoft adatközpontjainak evolúciójáról, felépítéséről és működéséről szól (konrétan erre utalok: Windows Azure Data Centers, the ‘Long Tour’). Különösen akkor van ez így, hogy ha maga is együtt “él” ilyen rendszerekkel, imádja a hardver “szagát” és hasonlókat épít is, persze, értelemszerűen sokkal kisebb méretekben. Úgyhogy ha még nem láttuk ezt a filmet, tegyük meg mihamarabb, mert tényleg érdekes és látványos.

És ha már belenéztünk, akkor rögtön látni fogjuk, hogy a Microsoft publikus felhője gyakorlatilag rengeteg majdnem átlagos rack szervert, vagy inkább rack szerver “hegyeket” jelent, plusz persze tárolókat, hálózati eszközöket és tápegységeket is. Egy ilyen rackben kb. 50 db szerver van (blade/node), plusz x db router és tápegység. 20 db ilyen rack (tehát nagyjából 1000 szerver) alkot egy újabb, de most már csak logikai egységet, mégpedig egy cluster-t (de nem szó szerint a klasszikus és a földi rendszerekben megszokott fürtről van szó, bár azért vannak közös vonások), amelyet egy ún. fabric controller (FC) üzemeltet.

Egy ilyen speciális Azure fürt felügyeletét ellátó FC a lelke a rendszernek, a mondás szerint kb. úgy viszonyul a benne foglalt szerverekhez, mint egy Windows OS a kernelhez. Az FC egy elosztott, állapottartó alkalmazás, ami minden hozzátartozó node-on (szerveren) aktívan dolgozik. Egy FC általában egy 5 tagból álló fürtben működik a magas rendelkezésre állás apropóján, és azért van 5 tag, mert a többségi quorum elv ismérvei miatt (50%+1 gép szavazata kell az ún. master gép kiválasztásához, azaz a fürt működtetéséhez elég 3 aktív tag).

De lépjünk vissza most a méretekben egyet. Az első szintű fizikai elválasztás a rack szerverek csoportjainál az ún. “fault domain”, ami nagyjából és körülbelül 1 db komplett rack-et jelöl. Ezt egy olyan szegmensként foghatjuk fel, amely önálló pl. az energiaellátás, a hálózati eszközök, stb. szempontjából, azaz két fault domain várhatóan nem fog egyszerre megállni.

(Ha már itt tartunk a fault domain-nel a tagolás szempontjából gyakorlatilag azonos az ún. “update domain” , csak a jellege más: ez a szoftver frissítések terítésének szétválasztása és az ehhez kapcsolódó VM leállítások miatt szükséges.)

Ha viszont netalántán nemcsak egy fault domain áll meg, hanem történetesen az egész adatközpont, akkor is van áthidaló megoldás, ez pedig a földrajzilag elosztott szolgáltatás (pl. egy IIS VM esetén a Traffic Manager-rel*), hiszen azonkívül, hogy egy földrészen is minimum 2 adatközpont áll rendelkezésre (egymástól jó messzire, hogy egy helyi esemény pl. egy földrengés ne okozzon többszörös gondot), ráadásul több földrésszel is kalkulálhatunk (Microsoft adatközpontból a mondás szerint tíznél több, száznál kevesebb van, ebből nyolcat láthatunk a portálon).

Elegánsan leegyszerűsítve és kihagyva a további részleteteket, már ennyiből is látható, hogy a Microsoft oldaláról bőven van hardveres és szoftveres megoldás a redundanciára és a hibatűrésre valamint a gépek közös felügyeletére. De a fault és az update domainek megléte önmagában még nem garancia a hibatűrésre, nekünk is van teendőnk, mégpedig a virtuális gépeinket szinkronba kell hoznunk ezzel a hardver alapú szegmentálással, azaz gépenkénti konfigurálással meg kell szüntetnünk az esetleges SPOF (Single Point of Failure) problémát. Ugyanis pl. egy publikus RDS szolgáltatás esetén például 2 db RDS szerverrel máris sokat javíthatunk a rendelkezésre álláson, de mi van akkor, ha ezek azonos rackben működnek, és ugyanazt a routert vagy tápegységet használják amivel épp most történik valami rendelleneség? Akkor bizony erre a rack-re kiható leállás mindkét gépünk ideiglenes kiesését is jelenti majd.

Azaz akkor tudjuk kiaknázni az IaaS-ban, egy saját virtuális géppark esetén pl. a fault domain elválasztást, ha használjuk az Azure Management Portálon ún. Availability Set (AS) opciót, azaz az említett 2 RDS gépet ugyanabba az Availability Set-be pakoljuk (feltéve persze ha ugyanabban a Cloud Service-ben vannak a virtuális gépeink), mert ezzel biztosan különböző fault domain-ekbe (és így különböző rack-ekbe) kerülnek, és ezzel meg is szűnt a SPOF.

Egy AS elkészítése akár már az első virtuális gép létrehozásakor megtörténhet (de nem kötelező ekkor létrehozni), de ilyenkor persze még nincs használati értelme. Az ezután következő ugyanazt a szerepet betöltő virtuális gép létrehozásakor viszont már lesz, ha ide kerül az új gép (VM > Configure), pl. a második RDS, akkor ezt megjegyzi az FC, és működik a fent ismertetett szeparáció, ergo védettek vagyunk a rackben előforduló átmeneti hardveres problémákkal és a tervezett leállásokkal szemben is. Természetesen bármikor ki- illetve berakhatjuk a gépeinket egy adott AS-be, vagy gyárthatunk újakat is.

Egyébiránt a gépeink által használt fault domainek pontos száma nem feltétlenül egyezik meg az AS-ek számával és nincs is tökéletesen egyenlően elosztva, mivel az AS használata csak azt garantálja, hogy az azonos célra fentartott virtuális gépeink közül legalább egy példány egy másik fault domainbe kerül, tehát ha például van 3 IIS VM-ünk, lehet, hogy ezek közül kettő azonos fault domainben lesz, míg a harmadik egy ettől eltérőben. És ha 4 db van akkor 3:1 is lehet az elosztási arány.

Éppen ezért lényeges, hogy tényleg csak a teljesen azonos funkcionalitású gépeket pakoljuk be egy közös AS-be, mert így van üzemeltetési szempontból reális értelme. Jó tudni azt is, hogy az Availability Set-ek kombinálhatóak a Load Balancing végpontokkal is, amit majd egy későbbi cikkben fogok kivesézni.

És még egy fontos dolog: ha használjuk az AS-t, akkor a Microsoft az alapértelmezett 99,9%-os rendelkezésre állás helyet 99,95%-ot vállal.

—

* Jelenleg Preview állapotban van az Azure Management portálon