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

Nem is tudom. milyen régóta szerettem volna megírni ezt a cikksorozatot. Annyi tévhit és leegyszerűsítés él a témáról a köztudatban, hogy az el sem mondható, miközben ténylegesen szinte senki nem vizsgálta ezt a területet. Általánosak az olyan megfogalmazások, hogy “a virtualizáció és a magas rendelkezésre állás kéz a kézben jár”, meg hogy “hypervisor fürtöket alkotva automatikusan magasabb rendelkezésre állású rendszert lehet kialakítani”, vagy például “a virtualizáció nyújtotta magas rendelkezésre állást biztosító technológiák kiváltják az alkalmazás szintű clusterezést” stb. stb. A következő tanulmányban négy konkrét alkalmazás példáján szeretném megmutatni mi igaz és mi nem ezekből az állításokból. A négy alkalmazás az Active Directory, az IIS, az Exchange DAG és az Oracle RAC – jó okom van épp ezt a négyet választani, később kiderül miért.

Alapozás
Mindenek előtt néhány definíció. Magas rendelkezésre állást biztosító technológiáról  (highly available, HA) akkor beszélünk, amikor van egy módszer, eszköz, technikai lehetőség, amely segítségével egy adott, vagy akár többféle meghibásodás esetén a rendszer a szolgáltatás kiesését minimalizálja. Ha ez a minimalizálás olyan jól sikerül, hogy semmiféle kiesés nem történik, legalábbis felhasználói szemszögből ez nem érzékelhető, akkor az adott módszert hibatűrő (fault tolerant, FT) megoldásnak hívjuk. Előbbire példa mondjuk egy Microsoft fail-over cluster: ha meghibásodik egy fürttag, akkor a szolgáltatások kis kiesés mellett átvándorolnak egy másik fürttagra. Az utóbbira – tehát a hibatűrésre – jó példa mondjuk egy RAID tömb: még ha meghibásodik is egy merevlemez, semmi gond, a RAID tömb működése biztosítja a szolgáltatást. Tipikusan NEM szokták a hibatűrő megoldások közé sorolni mondjuk azt, amikor IP-cím konfiguráció során kettő vagy több DNS kiszolgáló címét adjuk meg, pedig ez is szép példája a szolgáltatás tovább élésének: a TCP/IP hálózati forgalom-kezelés biztosítja, hogy egy kiszolgáló elérhetetlensége esetén a számítógép automatikusan egy másikhoz fordul.

A cikkben szolgáltatás szintű (alkalmazás szintű) magas rendelkezésre állást biztosító technológiának fogok nevezni minden olyan megoldást, amely egy szolgáltatás (pl. AD, Exchange SQL stb.) magasabb rendelkezésre állását biztosíthatja. Ezek a technológiai megoldások nagyon sokfélék lehetnek, konkrétan a mi kiválasztott alkalmazásainknál:

  • Többszörözés – pl. Active Directory. Ha több tartományvezérlőt állítok üzembe, akkor magasabb lesz az AD szolgáltatásom rendelkezésre állása.
  • Network Load Balance (NLB) – hálózati forgalomelosztó mechanizmus; Többek között az IIS szolgáltatás magasabb rendelkezésre állását segítő megoldás. Terheléselosztó szerepe is van, de ez a mi szempontunkból most mellékes.
  • Fail-over cluster – az operációs rendszerbe beépített mechanizmus, amelyet sok más szoftver mellett az Exchange 2010 Data Availability Group rendszere is használja, hogy ezáltal biztosítson adatbázis szintű magas rendelkezésre állást.
  • Egyedi, alkalmazás szintű megoldás – Erre jó példa az Oracle Real Application Cluster (RAC).

    Még egyszer: sokféle technika, azonos cél: az adott szolgáltatás folyamatosan működjön.

    A szolgáltatás elérhetetlenségének, leállásának többféle oka is lehet. Tervezetett leállásnak fogom nevezni azokat a leállásokat, melyek ideje előre meghatározott, és tevékenység pedig szándékolt. Leginkább a karbantartás, tervezett leállás, tervezett bővítés, csere stb. tartozik ide. A nem tervezett leállás fogalmát akkor veszem majd elő, amikor valamilyen váratlan meghibásodásról beszélünk.

    Gazdagép fürtözésnek (host cluster) nevezik azt a módszert, amikor a virtualizációs kiszolgálók alkotnak egy fürtöt, szervercsoportot, és meghibásodás esetén átveszik és futtatják a meghibásodott hardver virtuális gépeit.

    image_thumb2

    Gazdagép fürtözés

    Vendéggép fürtözésnek (guest clustering) hívjuk azt a megoldást, amikor két virtuális gép között alakítunk ki fail-over clustert. Ilyenkor nem a gépek, hanem – akárcsak a fizikai környezetben – a szolgáltatások vándorolnak egyik kiszolgálóról a másikra.

image_thumb5

    Vendéggép fürtözés

    Figyelem! Ebben a cikkben vendéggép fürtözésnek fogok hívni minden szolgáltatás szintű magas rendelkezésre állást biztosító technológiát, függetlenül attól, hogy az technológiai értelemben ténylegesen fürtözés-e.

    Előfeltevések
    A közbeszédben sohasem mondjuk ki, de itt most le kell írnom, hogy az alábbi gondolatsor a következő előfeltevésen alapul: bárhogy is alakítsuk át a rendszerünk architektúráját, egyforma ügyességgel vagyunk képesek üzemeltetni azt. A valóságban ez közel sincs így, mégis szükséges a lenti okfejtéshez hozzáfűzni. Miért? Azért mert a most következő gondolatsor feltételezi, a “ceteris paribus”-t, vagyis minden egyéb feltétel változatlan voltát.

    Ezen túl feltételezem, hogy a technológiában rejlő potenciál teljes egészében felhasználható. Például egy VMware cluster tipikusan egy telephelyen működik. Site Recovery Managerrel azonban a megoldás védkezni képes a teljes telephely megsemmisülése ellen is. Én azt feltételezem, hogy pénz, paripa, fegyer rendelkezésre áll bámilyen potenciálisan meglévő lehetőség tényleges megvalósítására.

    Kérdések
    Most, hogy a legfontosabb fogalmakat tisztáztuk, tegyük fel a kérdéseket, amelyekre a tanulmányban választ keresünk:

  1. Virtualizációs HA megoldással magasabb rendelkezésre állást leszünk-e képesek elérni olyan szolgáltatás esetén, amelyet korábban semmilyen HA vagy FT technikával sem védtünk?
  2. Virtualizációs HA megoldással magasabb rendelkezésre állást tudunk-e elérni olyan szolgáltatás esetén, amely korábban rendelkezett saját HA/FT megoldással, de a virtualizálás során ezt megszűntettük? (“Nincs már rá szükség” felkiáltással.) A kérdést úgy is feltehetjük, hogy az egyedi szolgáltatás-szintű HA megoldások helyett lehet-e egységes virtualizációs HA megoldást alkalmazni a szolgáltatásokra? Vagy még másképpen: kiváltja-e a Virtualizációs HA megoldás az alkalmazás szintű HA megoldásokat?
  3. Virtualizációs HA megoldással tudunk-e TOVÁBBI rendelkezésre állást nyerni olyan szolgáltatások esetén, amelyeknek a virtualizációs projekt előtt volt saját HA/FT megoldása és ezt a projekt után is megtartottuk?
    Mára elég, innen folytassuk legközelebb…

4 Responses to Virtualizáció és magas rendelkezésre állás – 1

  1. Pingback: oszefoglalo | IT?

  2. Tömören: ne felejtsd el definiálni a szolgáltatás fogalmát. Mondjuk AD esetében azt írod, hogy a többszörözés a szolgáltatás rendelkezésre állását növeli. Hmm. Ez igaz…általában. De attól függ valójában, hogy mi a szolgáltatás definiciója.

    A válaszok pedig szerintem:
    1, NEM
    2, NEM
    3, TILOS KOMBINÁLNI🙂

  3. lepenyet says:

    Sokat gondolkodtam Az AD-ről még a cikk megírása előtt. Hiszen vannak FSMO szerepkörök, az Exchange vagy más címtárt használó alkalmazás oda-oda ragadhat egy GC-hez vagy más tartományvezérlőhöz, tehát a “többszörözés” semmiképpen nem tekinthető precíz dolognak. Szemléltetésként viszont megfelel, és bár elnagyolt ahogy fogalmazok, a végső következtetést nem befolyásolja. Szóval egyetértek az “általában” kifejezéssel, de azt hiszem most ez is megteszi.

    A válaszok a cikksorozat végére megszületnek, ne lőjük le a poént😉

  4. Feriokos says:

    1. igen, magasabbat.
    Ha még képes elindulni a megdöglött virtuális vas, akkor csak a halott hosztot kell kicserélni a működőre.

    2. Nem csinálunk butaságot, a válasz nem.

    3. Javasolt kombinálni. De még mennyire! Már miért lenne tilos?

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: