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

Elérkeztünk az utolsó alkalmazás elemzéséhez, s amilyen összetett architektúrákat lehet megálmodni, olyan egyszerű maga táblázat:

Kieső komponens	RAC – fizikai	Ora – VMware HA-val	Ora – Hyper-V clusterrel	Ora – VMware FT-vel	RAC VMware HA-val	RAC Hyper-V clusterrel	RAC VMware   FT-vel
Adatbázis	x	NS	NS	NS	NS	NS	NS
Alkalmazás	x	NS	NS	NS	NS	NS	NS
Operációs rendszer	x	NS	NS	NS	NS	NS	NS
Szerver hardver	x	NS	NS	NS	NS	NS	NS
SAN kapcsolat	x	NS	NS	NS	NS	NS	NS
SAN tároló	x	NS	NS	NS	NS	NS	NS
Teljes telephely	x	NS	NS	NS	NS	NS	NS

Az Oracle úgy látja jónak, hogy harmadik gyártó virtualizációs platformján nem támogatja a saját szoftvereit, pontosabban az ügyfélnek bizonyítania kell, hogy a probléma, amelyet bejelentett, nem áll kapcsolatban a hamadik fél hypervisorával. (Bővebben itt: http://oraclestorageguy.typepad.com/oraclestorageguy/2009/04/what-the-oracle-vmware-support-statement-really-meansand-why.html) Azoknál, akiknél az adatbáziskezelő szabvány az Oracle adatbáziskezelője, a virtualizációs szabvány pedig Vmware vagy Hyper-V, egyetlen út marad: fizikai környezetben maradni. Mivel még egy esetleges támogatás meglétekor sem bírna olyan képességekkel a rendszer, mint natív környezetben (mint azt a korábbi alkalmazáoknál láttuk), igazából ez talán nem is fáj. Következtetésem az Oracle RAC esetén hasonló, mint korábban: az alkalmazás szintű magas HA/FT megoldások nem nélkülözhetők.

A cikksorozat elején kiválasztottunk négy alkalmazást, amelyek egymástól eléggé eltérő módon biztosítják a magas rendelkezésre állás lehetőségét, mostanra kiderült, hogy bármely megoldás elhagyása azt jelenti, hogy a virtualizációs HA/FT-vel felépített rendszerünk bizonyos típusú, ritkának és különlegesnek nem mondható szituációkat nem kezel le. Nézzük meg a sorozat elején feltett kérdéseket:

• 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? – Még nem válaszoltunk a kérdésre, egyelőre többszörözött rendszerekkel foglalkoztunk.

• 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 vizsgálat alapján kijelenthetjük, hogy nem tudunk magasabb rendelkezésre állást elérni, sőt, az eredeti szintet sem érjük el, függetlenül attól, hogy virtualizációs oldalon HA vagy FT, ESX vagy Hyper-V az építőkocka.

• 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? – Sem nem lehet egységes HA megoldást alkalmazni, sem pedig azt nem állíthatjuk, hogy a virtualizációs HA/FT megoldások kiválthatnák az eredeti architektúrákat.

• 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? – Ha pusztán a HA/FT megoldásokat figyeljük, akkor erre NEM a válasz.

Persze koránt sem varrtunk el minden szálat, a cikksorozat következő részeiben az alábbi kérdésekre keresünk válaszokat:

• virtualizáció technológiája (izoláció, provizionálás, standard környezet, snaphost technológia) miképp befolyásolja a szolgáltatás rendelkezésre állását?
• A HA és FT megoldások hajszálra egyformán szerepeltek a táblázatokban. Tényleg semmi különbség nincs köztük, vagy valamit nem vizsgáltunk? Azért mégsem mindegy, hogy HA vagy FT, nem?
• Mi az előnye – ha van – az Exchange kiszolgálók guest clustering-be szervezésének?
• A fail-over cluster rendszerek kiváltását hypervisor HA-ra azzal is indokolni szokták, hogy így Windows szerver licencet lehet megtakarítani, hiszen Enterprise Edition helyett elegendő a Standard használata. Igaz ez?
• Az első részben feltételeztük, hogy “mindent egyformán jól tudunk üzemeltetni”. Mi történik, ha ezt a peremfeltételt elhagyjuk?

Marad tehát bőven témánk, folytatjuk…

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

Két alkalmazásnál már úgy láttuk, hogy a szolgáltatás szintű magas rendelkezésre állás nem elhagyható opció. Nézzük most meg az Exchange-et. Elvégre AD és NLB elérhető egy Windows Standard változattal is, Exchange clusterhez viszont minimum Windows Enterprise Edition szükségeltetik, tehát pénzre megy a játék(*). A korábbi táblázatunk Exchange alkalmazásra vonatkoztatva az alábbiak szerint alakul:

Kieső komponens	Exch – DAG fizikai	Exch – VMware HA-val	Exch – Hyper-V clusterrel	Exch – VMware FT-vel	Exch DAG VMware HA-val	Exch DAG Hyper-V clusterrel	Exch DAG VMware   FT-vel
Adatbázis	x				NS	NS	NS
Alkalmazás	x				NS	NS	NS
Operációs rendszer	x				NS	NS	NS
Szerver hardver	x	x	x	x	NS	NS	NS
SAN kapcsolat	x	x	x	x	NS	NS	NS
SAN tároló	x	x(*)	x(*)	x(*)	NS	NS	NS
Teljes telephely	x	x(*)	x(*)	x(*)	NS	NS	NS

A táblázat bal fele – most már mondhatjuk – a szokásos. Az alacsonyabb logikai rétegben dolgozó virtualizációs HA  képtelen bizonyos szituációkat lekezelni. Ráadásul  a le nem kezelt szituációk még talán gyakoribbak, mint a lekezeltek, főleg ha azt is számítjuk, hogy a táblázat nem csak a nem tervezett, de a tervezett leállásokat is tartalmazza. Azt nem mondom, hogy egy adatbázis szétesés mindennapi eset, de egy javítócsomag telepítés az alkalmazásra vagy az operációs rendszerre már sokkal inkább. A következtetésem ismét ugyanaz, mint korábban: lemondani az alkalmazás szintű Exchange fürtözésről és pusztán a virtualizációs HA/FT megoldásokra támaszkodni – ez visszalépés a magas rendelkezésre állás biztosítása terén.

A táblázat jobb oldala már újdonság. NS, vagyis “not supported” (nem támogatott). A pontos megfogalmazás így hangzik:

“Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.”

Forrás: http://technet.microsoft.com/en-us/library/aa996719.aspx

Mielőtt bárki csúnya-csúnya microsoftozna, íme a VMware álláspont:

Before you set up MSCS, review the list of functionality that is not supported for this release, and any
requirements and recommendations that apply to your configuration.The following environments and functionality are not supported for MSCS setups with this release of vSphere:
* Clustering on iSCSI, FCoE, and NFS disks.
* Mixed environments, such as configurations where one cluster node is running a different version of ESX/ESXi than another cluster node.
* Clustered virtual machines as part of VMware clusters (DRS or HA).
* Use of MSCS in conjunction with VMware Fault Tolerance.
* Migration with VMotion of clustered virtual machines.
* N-Port ID Virtualization (NPIV)
* With native multipathing (NMP), clustering is not supported when the path policy is set to round robin.
* You must use hardware version 7 with ESX/ESXi 4.0.

Forrás: www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf

Ez az utóbbi cikk egyébként nagyon pontos, és számos együttélési problémára rávilágít (RDM lezemek, egyáltalán storage kezelés, multipath, clustered vmdk, 2003 vs 2008 fürtök stb stb.) érdemes olvasgatni. Ha a táblázat bal oldala szerint a virtualizációs HA/FT megoldások csökkentik a rendszer képességét, hogy különböző meghibásodásokra reagáljon, a jobb oldala pedig a “nem támogatott” helyzetbe sodorna minket, a következtetés egyértelmű: ha komolyan gondoljuk az Exchange adatbázis kiszolgálók magas rendelkezésre állását, akkor Exchange Mailbox Store szerepkört nem keverünk össze virtualizációs HA/FT megoldással.

Ez viszont nem jelenti azt, hogy ne lehetne egy mailbox szerepkört virtualizálni. Lehet, guest clustering segítségével – ez a téma viszont nem tartozik szorosan a tárgyhoz, majd máskor tárgyaljuk.

Még egy fontos dolgot tisztáznunk kell. Vajon minden fail-over clusteres alkalmazás esetén azonos szabályokat kell alkalmaznunk? Ez egyáltalán nem biztos. Az eredeti alkalmazások között ugyan nem szerepel, de érdekes példa lehet a Microsoft SQL szerver. Szemben az Exchange csapattal, itt a host + guest cluster támogatott.

• Guest Failover Clustering is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 in a virtual machine for the supported hardware virtualization environments listed in this article provided all of the following requirements are met: 
  • The Operating System running in the virtual machine (the “Guest Operating System”) is Windows Server 2008 or higher
  • The virtualization environment meets the requirements of Windows 2008 Failover Clustering, as documented in the following Microsoft Knowledge Base article:

    943984 (http://support.microsoft.com/kb/943984/ ) The Microsoft Support Policy for Windows Server 2008 Failover Clusters

[…]

Q5: Is Quick and Live Migration with Windows Server 2008 R2 Hyper-V supported with SQL Server?
A5: Yes, Live Migration is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 when using Windows Server 2008 R2 with Hyper-V or Hyper-V Server 2008 R2.Quick Migration, which was introduced with Windows Server 2008 with Hyper-V and Hyper-V Server 2008, is also supported for SQL Server 2005, 2008, and 2008 R2 for Windows Server 2008 with Hyper-V, Windows Server 2008 R2 with Hyper-V, Hyper-V Server 2008, and Hyper-V Server 2008 R2.

Forrás: http://support.microsoft.com/?id=956893

Furcsa fricska, hogy az előbb idézett vSphere dokumentum általánosan a Microsoft cluster megoldásra vonatkozik, tehát az SQL szerverre is, míg a Microsoft a maga részéről a guest clustered SQL kiszolgálók migrációját nem bánja.

Végeredményben tehát két dolgot legalább meg kell tanulnunk:

1. A fail-over cluster – NEM ELHAGYHATÓ magas rendelkezésre állást biztosító technológia.
2. A guest fail-over cluster és a host cluster megoldások vagy egyáltalán nem keverhetők, vagy pedig erősen meg kell nézni, hogy mely gyártó mely alkalmazásnál milyen megkötéseket ad meg.

Folytatjuk…

—————

(*) – Ezt az “érvet” még elemezzük egy későbbi cikkben

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

Az előző cikkben az AD-t elemeztük, de persze komolyan senki sem gondolhatja – virtualizáció ide vagy oda – hogy egyetlen kiszolgálóra bízza ezt a szolgáltatást. Most nézzük meg, hogy egy alapvetően más módszert alkalmazó szoftvernél mi a helyzet. Az IIS rendelkezésre állásának növelésére hagyományosan NLB-t alkalmaznak. Az AD mintájára készítsük el újra a táblázatunkat

Kieső komponens	IIS – NLB, fizkai	IIS – VMware HA-val	IIS – Hyper-V clusterrel	IIS – VMware FT-vel	IIS – NLB-vel és VMware HA-val	IIS NLB-vel és Hyper-V clusterrel	IIS NLB-vel és FT-vel
Adatbázis
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(*)

Szinte teljesen azonos táblázatot kaptunk, mint az előző cikkben. Az eredeti táblázatból tudjuk, hogy az NLB nem foglalkozik azzal, hogy az IIS átal szolgáltatott tartalom mennyire jó, ha az IIS fut, akkor az NLB könyörtelen oszt rá felhasználókat, akik hibaüzeneteket kapnak vissza.

Az IIS leállását semelyik virtualizációs technológia sem veszi észre: ha működik az operációs rendszer, de az IIS nem, az a host cluster megoldásokat nem zavarja.. Az NLB elhagyása még akkor is elfelejtendő, ha csak a rendelkezésre állásra ügyelünk és a terheléselosztással nem is számolunk.

Ha visszahozzuk az NLB-t, akkor jobbára visszakapjuk az eredeti, virtualizáció nélküli megoldásunkat, de azért a szerver hardverek kiesésénél nem árt ügyelni a cluster helyes konfigurációjára. Mind a VMware HA esetén, mind pedig a Hyper-V-nél be KELL konfigurálni az anti-affinitás szabályokat, amellyel elérhetjük, hogy a két vagy több VM, amely IIS-t futtat NLB-vel, lehetőleg külön fizikai szerveren fusson, ellenkező esetben egy esetleges szerver meghibásodás mindenképpen leállással jár – a fizikai környezetben ilyen szituáció nem fordulhat elő. A VMware megoldásánál tehát mindenképp Distributed Resource Schedulerre (DRS) van szükség, ez viszont csak a drágább kiadásokban érhető el. Ez pedig súlyos következményekkel jár: egy virtualizált NLB farmnak lehet kisebb a rendelkezésre állása, egy fizikai implementációhoz mérve – Vmware fault-tolerant ide vagy oda. Az én végkövetkeztetésem: az NLB nem váltható ki semmilyen host cluster megoldással, és még együttes alkalmazásuk is odafigyelést igényel.

Folytatjuk…..

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…

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? 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…

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.



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.

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…