Virtualizáció és magas rendelkezésre állás – 3

Amikor virtuális környezetbe költöztetjük a szolgáltatásainkat futtató operációs rendszereket, dönthetünk arról, hogy megtartjuk, vagy elhagyjuk a korábban alkalmazott HA vagy FT megoldásokat. Ráadásul virtualizáció implementálásakor használhatunk HA helyett FT-t is – legalábbis VMware esetén. Mivel ez így meglehetősen széles választék, nézzük alkalmazásonként, hogyan változik a táblázatunk. Kezdjük az AD-vel.

Kieső komponens	AD fizkai, 2 DC	AD – VMware HA-val	AD – Hyper-V clusterrel	AD – VMware FT-vel	AD – két DC-vel és VMware HA-val	AD – két DC-vel és Hyper-V clusterrel	AD -  két DC és VMware FT-vel
Adatbázis	x				x	x	x
Alkalmazás	x				x	x	x
Operációs rendszer	x				x	x	x
Szerver hardver	x	x	x	x	x	x	x
SAN kapcsolat	x	x	x	x	x	x	x
SAN tároló	x	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)
Teljes telephely	x	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)

Ez egy nagyon érdekes táblázat. Az első két oszlopa azt a szituációt mutatja, amikor elhagyjuk a dupla tartományvezérlőt. Sajnos sem a VMware HA, sem a Hyper-V cluster nem óv meg bennünket az AD adatbázisok megsérülése esetén a szolgáltatás kiesésétől. Sőt! Ugyanez a helyzet a VMware FT esetén is. Persze a dolog érthető: mindkét HA megoldás alacsonyabb rétegben dolgozik. Ráadásul még kiosztottam mindkét oszlopban egy csomó csillagot. Lássuk a magyarázatot:

1. SAN kapcsolat bontása esetén a VMware HA fürt adott kiszolgálóján a virtuális gépek elhasalnak és egy másik kiszolgálón indulnak el
2. Ugyanebben a szituációban a Hyper-V cluster redirekciót hajt végre és a VM-ek tovább üzemelnek.
3. Szerver hardver meghibásodás esetén a VMware FT által védett tartományvezérlős VM hibátlanul üzemel tovább
4. SAN kapcsolat vesztésnél a VMware FT által védett tartományvezérlős VM hibátlanul üzemel tovább
5. SAN tároló összeomlásakor mindhárom megoldásnál kézzel kell elindítani egy site-failover tevékenységet – már persze ha erre felkészültünk. Ugyanez a helyzet teljes telephely összeomláskor. Egyik esetben sem olyan automatikus az átállás mint a két telephelyen, egymástól függetlenül üzemelő tartományvezérlők esetén, a horribilis költségekről már nem is beszélve.

   Most gondoljuk el, hogy milyen szituációk esetén nem véd ez az architektúra:

• AD meghibásodás
• OS indulási problémák (sérült boot sector, kékhalál stb.)
• OS rendszeres karbantartás (havi frissítések)
• OS átkonfigurálás, ha újraindítással jár.

Az előző cikkben említettem, hogy érdemes mérni a magas rendelkezésre állás működését, a hibákat, az átállásokat stb. Ha ezt nem tesszük, akkor nem tudjuk, hogy a fenti felsorolás az összes kiesés hány százalékát érinti. Látatlanban én azt mondom, hogy ez a négy pont nem elhanyagolható.

A másik három oszlopnál visszatér a “teljes” védelem, de ezt nem a virtualizációs HA megoldásoknak, hanem az alkalmazás belső védelmének köszönhetjük. Ráadásul ha virtuális gép költöztetéses megoldást választunk az AD esetén akkor az 5. pont itt is érvényes. Összességében a táblázatból az szűrhető le, hogy IGEN NAGY HIBA lenne elhagyni az AD esetén a saját maga által biztosított magas rendelkezésre állást. Virtualizációval ezen csak rontani lehet, beleértve  a VMware FT megoldást is. Meglepő az eredmény? Nézzük meg, hogy alakul ez az IIS-nél.

Folytatjuk…