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

Amikor magas rendelkezésre állást biztosító technológiákat alkalmazunk, a tervezés során pontosan fel kell mérnünk, hogy egy-egy megoldás milyen típusú meghibásodás ellen nyújt védelmet, és mi az, amit nem visel el. Nézzünk erre példát virtualizáció nélkül. A sorokban a meghibásodások típusát, az oszlopokban a különböző szolgáltatás szintű magas rendelkezésre állást biztosító technológiákat soroltam fel. Az architektúránál feltételeztem, hogy a kiszolgálók nem SAN-ról indulnak, de az adatbázisuk, vagy az IIS által átadott tartalom már a SAN-on van. (Ha SAN Boot-ot feltételeznék, akkor a SAN kapcsolat kiesés megegyezne a szerver kiesés sorral, a SAN tároló kiesés pedig a teljes telephely kieséssel). X-el jelölöm, amikor egy adott komponens kiesése ellen védelmet nyújhat egy adott technológia, utána pedig magyarázatot fűzök a táblázathoz. Értelem szerűen a táblázat “felbontása” lehet sokkal finomabb is, pl. milyen típusú adatbázis meghibásodások, milyen típusú szerver meghibásodások stb. stb. Én itt most egy-egy komponens teljesen használhatatlanná válásával számoltam. Még egy megjegyzés: más eszközöm nem lévén, vastaggal és zöld háttérrel jelöltem az Oracle RAC-ot, mivel az hibatűrő megoldás is egyben – vagyis a meghibásodások a felhasználó szemszögéből nem észlelhető. (Kivéve a SAN hibát és a teljes telephely átállást.)

Kieső komponens AD – két tartományvezérlővel IIS – NLB-vel Exchange DAG Oracle RAC
Adatbázis                   x               x            x
Alkalmazás                   x             x             x            x
Operációs rendszer                   x             x             x            x
Szerver hardver                   x             x             x            x
SAN kapcsolat                   x             x(*)             x            x
SAN tároló                   x             x(*)             x            x(*)
Teljes telephely                   x             x(*)             x            x(*)

Az Active Directory több telephelyen elszórható, egymással replikációs kapcsolatot tartó kiszolgálókból áll, ún. tartományvezérlőkből áll. Mindegyik tartományvezérlő saját adatbázist kezel. Ha ezek közül egyik meghibásodik, akkor az adott szerveren a szolgáltatás nem üzemel, a kliensek pedig automatikusan másik kiszolgálóhoz fordulnak.

NLB-vel védett IIS esetén az “adatbázis” lehet egy könyvtárstruktúra. Ennek eltűnése nem állítja le az IIS szolgáltatást, ezért az adott IIS kiszolgálóhoz fordulók valamilyen hibakódot ad vissza a kliensek kérésére. Minden egyéb meghibásodáskor az NLB gondoskodik arról, hogy a felhasználók megkapják a kérésüknek megfelelő adatot. NLB fürtöt pl. DNS Round robin segítségével több telephelyre is szétszórhatunk, bár ilyenkor bizonyos kliensek hibára futhatnak – ezért a (*) megjegyzés.

Az Exchange DAG és a Oracle RAC minden, általam felsorolt hiba ellen képes védekezni annyi megjegyzéssel, hogy egy Oracle RAC különböző telephelyek között csak úgy tud elhelyezkedni, ha a távolság nem haladja meg a 100 Km-t. Ez ritka kivételeket leszámítva bőven elegendő. Az Exchange-nek a távolság nem akadály, az Amsterdam-Dublin átállás simán elképzelhető.

Ha valaki a fenti okfejtést kissé bonyolultnak tarja, annak felhívom a figyelmét, hogy a magas rendelkezésre állás nem is minden aspektusát vettük figyelembe. Exchange esetén például tervezhetünk a kommunikációs csatornák magas rendelkezésre állásával is, nem csak az adattárolás magas rendelkezésre állásával.

Ez a táblázatos módszer (persze nem az itteni móricka változat, hanem egy precízen kifejtett) egyébként alkalmas egy-egy beruházás megtérülésének utólagos számításához. Ha ismerjük a rendszerünk jelenlegi rendelkezésre állását, a kiesések okát és költségét, akkor a beruházás utáni rendelkezésre állás növekedés (kiesés csökkenés) költsége megtakarításként jelentkezik. Magas rendelkezésre állást implementálni csak akkor érdemes, ha mérjük is, hogy milyen magas a magas, nem mondtam még? Winking smile Virtualizációs terveknél pedig azt sem árt tudni, hogy melyik fajta kiesés mekkor súllyal esik latba. Miért is? Mert virtualizációs környezetben egész más lesz ez a táblázat.

Folytatjuk…

One Response to Virtualizáció és magas rendelkezésre állás – 2

  1. Lakati Balázs says:

    Szia!

    ezt írtad:
    “vagyis a meghibásodások a felhasználó szemszögéből nem észlelhető. (Kivéve a SAN hibát és a teljes telephely átállást.)”
    Az Oracle RAC-nál ezt sem veszi észre a felhasználó. Ha a RAC nodejai a diszkeket mindkét telephelyről megkapják, látják is egymás diszkjeit /azaz a SAN zonázása jól van beállítva/ és az ASM-be különböző failovergroup-kba pakoljuk a telephelyek diszkjeit, akkor az egyik telephelyet le is bombázhatják a felhasználók ezt nem veszik észre. És persze a nodeok nem egy telephelyen vannak🙂

    Ami a RAC egyik nagy hibája, hogy nagy távolságokat nem tud áthidalni. Te 100Km -t írtál, a valóságba már 25 fölött nem ajánlják.🙂
    A nagy távolságok áthidalására szokták azt csinálni, hogy telephelyenként 2 vagy több RAC node és a telephelyek közti szinkronizálást meg DataGuard-dal viszik át.

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: