A VMware ESX 3.5 és a Hyper-V összehasonlítása – 9. kör

(Eredetileg a 9-10-11. kör egy cikknek készült. Végül olyan terjedelmes lett, hogy három cikkre bontottam, viszont a kereszthivatkozásokat nem gyomláltam ki belőlük. Érdemes egyszerre elolvasni őket.)

Az előző körben begyűjtöttük, hogy a két gyártó milyen megoldásokat dolgozott ki a virtuális gépek mozgatására a különböző szituációkban. Most összehasonlítjuk ezeket a megoldásokat – mindegyik persze a maga párjával, azonos helyzetben. Mielőtt azonban ezt elkezdenénk, egy fontos figyelmeztetést előre  kell bocsátanom.

imageA két gyártó teljesen más filózófia mentén csomagolja a termékeit, más kerül pénzbe az egyiknél illetve a másiknál. A korábbi cikkek során csak olyan képességeket hasonlítottunk össze, amely a Windows Server 2008 Hyper-V szerepkör és/vagy az ESX alaprendszer hordozott magában. Ezúttal azonban a górcső alá vett szoftver-komponensek részben vagy egészben nem az alap-platform részei.

A VMware-nél , ha a standard csomagokat tekintjük, a HA képesség a VI Standard, a Vmotion és a ráépülő egyéb megoldások pedig a VI Enterprise részei. Kapható ugyan minden komponens külön is, “a la cart” jelleggel, a weblapon talált árazást figyelembe véve azonban vagy le kell mondanunk a Vmotion-ről, vagy a HA-ról, vagy ha mind a kettőt szeretnénk, de nem szeretnénk Enterprise-t, akkor az drágább, mint az Enterprise licence, az ilyen választásnak meg sok értelme nincs. (Erről még később értekezünk.)

imageNem is rágódnék ezen annyit, ha nem helyezné a funkciók többségét egészen máshová a Microsoft. De ezt teszi, és ez megnehezíti az alma-alma jellegű összehasonlítást. A Microsoft is négyféle megoldást kínál, de ezek mind az operációs rendszerre vonatkoznak, nem pedig a menedzsmentre. Az MS táblázatból hiányzik a teljes System Center termékcsalád, miközben a HA és a Quick Migration az operációs rendszer része (Enterprise és Datacenter esetén), nem pedig a menedzsmenté. Mindez azért fontos, mert mind a Quick Migration, mind pedig a magas rendelkezére állás területén a System Center szoftverek kiegészítik az operációs rendszer alapképességeit.

A fentiek figyelembe vételével tehát a következő munkamódszert alkalmaztam:

Vettem az ESX VI Standard illetve Enterprise készletét és azt hasonlítottam össze a Microsoft alap operációs rendszerével. Amikor azonban olyan funkciók is felszínre kerültek, amelyek a Microsoftnál megvannak, de nem az alaptermékben, hanem a System Centerben, akkor azt külön jeleztem. No, akkor most indulhat az értékelés.

Az előző cikkben felsorolt képességeket három szituációban lehet használni.

  1. Nem tervezett leállás
  2. Tervezett leállás/karbantartás
  3. Erőforrás-használat kiegyenlítése

Nem tervezett leállás 
Nem tervezett leállás (pl. váratlan hardver meghibásodás) ellen a VMware platform a HA clustert, a Microsoft pedig a Fail-over clustert vonultatja fel. A VMware világban egy clusternek két funkciója lehet: DRS (Distributed Resource Scheduler) és HA (High Availability). Most csak a HA-t taglaljuk, a DRS-re később térünk ki. Ez azért nem triviális, mert a HA sok tekintetben sziámi a DRS-sel, a dokumentáció is együtt foglalkozik velük. Ugyanakkor a szinergiák ellenére különöböző licencekről, és persze eltérő funkcionaliásról van szó, ami megerősíti a külön tárgyalás lehetőségét.

A legfontosabb tudnivaló, hogy hiba, kiesés, kiszolgáló meghibásodás esetén mindkét termék újraindítja a virtuális gépeket egy másik, virtuális gépeket futtató kiszolgálón, esetünkben fürttagon. Azért fontos ezt hangsúlyozni, mert a HA és a Vmotion képességet sokszor, helytelenül, összemossák, és azt hiszik, a HA is úgy működik, mint a VMotion. Nem! Egészen másképp működik.

Ezen túlmenően a fürtöknek előéletükből eredően vannak előnyeik, illetve hátrányaik, nem könnyű eldönteni, hogy egy megvalósított képesség egyiknél job, vagy a másiknál. Itt van például a virtuális gépek indítási sorrendje. A VMware HA-ban prioritást (Disabled, Low, Medium, High) lehet a VM-ekhez rendelni, értelem szerűen előbb a magas prioritású gépek indulnak, majd a közepesek, végül a maradék. Azért célszerű ez a funkció, mert fürt-túlallokálás esetén biztosítható, hogy a magas prioritásúak mindenképp fussanak. Konkrét – gépről gépre történő beállítás ugyanakkor nincs. A Hyper-V a gépek indítási sorrendjét úgy határozza meg, hogy minden géphez késleltetést rendelhetünk (másodpecben). Ha konzekvensen alkalmazunk értékeket (pl.: 5, 10, 15 másodperces késleltetést használunk csak), akkor hasonló hatást érhetünk el, mintha prioritást használnánk, kényszer azonban nincs, ráadásul a másodpercek súlyként való alkalmazása nem mindig elfogadható. Viszont néha épp ez a megfelelő beállítási rend. Elemzés kérdése, hogy melyik megoldás jobb. Gépről gépre történő beállítás a Microsoft világban sem ismert.

A VMware HA beállítható úgy, hogy akkor is elindítson gépeket, ha a rendelkezésre állási elvárásokat a fürt megszegi. Hogyan lehetséges ez? Úgy, hogy a gépek ugyan elindulnak, de a számukra előzetesen lefoglalt garantált erőforrások nem teljesen érhetők el. Ez adott esetben drasztikus teljesítmény-csökkenést jelenthet – cserébe a szolgáltatások a virtuális gépekben mégis futhatnak. A Microsoft ezt a funkciót az SCVMM-be implementálta, de mivel nincs memória-túlfoglalás, a gépek vagy elindulnak, vagy, ha nem áll rendelkezésre elegendő erőforrás, akkor nem tudnak elindulni. Itt is kérdés, hogy melyik megoldás a jobb. Talán azzal, hogy az ESX konfigurálható “SCVMM-esre”, fordítva viszont nem, egy hajszállal az ESX tűnik jobbnak. Ha SLA előírás létezik teljesítményre is, akkor a két megoldás egyforma: sem így, sem úgy nem teljesül az SLA. Mindkét megoldás ismeri egyébként a fürt-túlfoglalás fogalmát. Ez azt jelenti, látják, képes-e a fürt adott számú fürttag kiesése esetén a magas rendelkezésre állású virtuális gépeket a maradék fürttagokon futtatni. Ha túlvállalást észlelnek, akkor például nem engedélyezik újabb virtuális gépek létrehozását.

Van aztán olyan terület, ahol a Microsoft fürtje érettebb. Mindenek előtt képes kezelni a földrajzilag elosztott fürt fogalmát. Néhány fürttagot elhelyezhetünk egyik, illetve másik telephelyen, és konfigurálás nélkül “evakuálhatjuk” a futó virtuális gépeket – quick migration-nel – az egyik telephelyről a másikra. Mindez persze nem működhet harmadik gyártó storage replikációs mechanizmusa nélkül. Kicsit ironikus, de az  EMC is támogatja a Windows földrajzilag elosztott fürtjét.  A VMware cluster önmagában nem ismeri a multi-site fogalmat, de storage replikációval és “némi” kézi konfigurálással azért itt is megoldható a katasztrófa telephely kialakítása. Van a VMware-nek még egy Site-Recovery megoldása is, de ez nem része a “Virtual Infrastructure” csomagnak, hanem külön megvásárolható szoftver. Most nem tárgyaljuk.

Fura volt olvasni, de a VMware HA-ban van egy “lyuk”. Normál esetben 15 másodperc szükséges ahhoz, hogy a fürt tagjai észleljék egy node kiesését (Windows esetén ez 5 másodperc, mindkét megoldásnál állítható a paraméter). A VMware “Resource Management Guide” 79-80. oldalán olvasható  “Host Network Isolation” rész taglalja azt, mi történik ebben a 15 másodpercben. A leírás szerint, ha a 12. másodpercben az elszakadt fürt lekapcsolja a gépeket, de a 14. másodpercben visszajön a kapcsolat, akkor a gépek lekapcsolva maradnak és nem indulnak újra. Nem mondom, hogy nagyon gyakori szituáció, de nem szép, az biztos. A Microsoft a “split brain” helyzetet konzekvensen kezeli, a szavazásos módszer korszerűbb, mint a VMware féle primary-secondary node konfiguráció, ráadásul többféle cluster modell is felépíthető. A fürttagok kiesését figyelő heartbeat forgalom időtúllépési értékei éppen azért finomhangolhatók, hogy a fürt alkalmazkodhasson az egyes modellekhez, például a földrajzilag elosztott konfigurációhoz.

A nem tervezett leállást kivédő szoftverek elemzésével kapcsolatban egy fontos dolgot nem árt tudni, bármelyik megoldást is válasszuk. A rendszer felkészíthető arra, hogy a virtuális gépek egy másik gépen elindulhassanak, és ez olyan gondolatokat ébreszthet bennünk, hogy az ilyen megoldások kiválthatják a hagyományos fürtöket és magas rendelkezésre állási technológiákat. A VMware dokumentációk bátorítanak is erre. A magam részéről csak egy kitétellel együtt tudok ezzel a tervezési elvvel egyetérteni. A kitétel pedig az, hogy gondoskodnunk kell a vendéggép mentésből való helyreállíthatóságáról és tudatában kell lennünk annak, a megoldásunk magában hordozza az adatvesztés lehetőségét. Ennek alátámasztására álljon itt néhány mondat az ntfs.com-ról:

“NTFS uses transaction logging and recovery to guarantee that the volume structure is not corrupted. For this reason, all system files remain accessible after a system failure. However, user data can be lost because of a system failure or a bad sector.”

A Hyper-V esetén ez azt jelenti, hogy mind a szülő-partíció, mind pedig a vendég elindítható marad, de a vendég memóriájában található, ki nem írt adatok elvesznek. Nem találtam erre vonatkozó utalást, de feltételezhetem, hogy a VMFS éppúgy képes túlélni az ilyen leállásokat, de a benne futó virtuális gépekre a figyelmeztetés ugyanúgy áll. Nem Windows vendéggépek esetén meg kell nézni, hogy a fájlrendszer képes-e a tranzakció-naplózásra és helyreállásra. A mai rendszerek többsége ezt tudja, de egy ellenőrzés azért nem árt.

No.

Tulajdonság

VMware ESX 3.5 High Availability

Microsoft Hyper-V Fail-over cluster

1.

Magas rendelkezésre állású fürtök létrehozása

Igen

Igen

2.

Fürttagok maximális száma

32

16

3.

Meghibásodás esetén viselkedés

VM újraindítás

VM újraindítás

4.

Kezelt gépek száma

Az alapplatform határozza meg

Az alapplatform határozza meg

5.

Gépújraindítási sorrend

Prioritás alapján

Késleltetés alapján

6.

Fürt-túlallokálás figyelése

Igen

Igen

7.

Fürt-túlallokálás engedélyezése

Igen

Nem

8.

Fürttag izoláció kezelése

Igen

Igen

9.

Fürttag izoláció következetes megoldása

Nem

Igen

10.

Földrajzilag elosztott fürt

Nem

Igen

11.

Állítható hearbeat értékek

Igen

Igen

12.

Erőforrás-elosztás (DRS/PRO) integráció

Igen

Igen

Előzmények:
A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 6. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 7. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 8. kör

A cikk a 10. körrel folytatódik

2 Responses to A VMware ESX 3.5 és a Hyper-V összehasonlítása – 9. kör

  1. fearme says:

    "A fürttagok kiesését figyelő hearbeat forgalom" – hear(t)beatnek, mintha egy t kimaradt volna :-)

  2. Tamas says:

    Igen, valóban. Javítottam.

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: