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…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: