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

Ma a virtuális gépek gazdagépek közötti mozgatásáról lesz szó. A VMware ESX kiszolgálónál a VMotion-t / Storage VMotion-t és a HA-t, a Hyper-V-nél pedig a Quick Migration-t ismertetem nagy vonalakban. Most még csak technológiai alapozást tartunk. Ezzel a cikkel annyi a célom, hogy leírjam, melyik megoldás hogyan működik. Az értékelésüket, hasznosságuk becslését, további felhasználási területüket egy következő alkalommal, a 9. körben fejtem majd ki.

Egy érzelgős történet
2004. őszén egy VMware ESX bemutatón vettem részt, amelyet a BCSS Kft. munkatársai szerveztek nekem és Krisztián kollégámnak. Láttam már korábban is virtualizációt, 1999. óta ismertem a VMware-t, egy-két éve már GSX-et is használtunk, de a srácok valami különlegeset ígértek. Hosszan fejtegették, hogy az ESX, szemben a GSX-szel, már nem igényel operációs rendszert, hanem közvetlenül a vason fut, és olyan nagyvállalati funkciók vannak benne, amely a GSX-ben sohasem lesznek. A felsorolt és demózott példák között volt egy lenyűgöző: elindítottak egy virtuális gépet, elkezdtek rámásolni egy állományt a hálózatról, elkezdték folyamatosan pingelni, majd egy speciális technológiával azt mondták, hogy "move", és a virtuális gép némi szöszmötölés után átugrott egyik kiszolgálóról a másikra úgy, hogy csupán egyetlen ping maradt ki, a fájlmásolás pedig gond nélkül folytatódott. Leesett az állam. Percekig nem tértem magamhoz. Vigyorogtam, mint a tejbetök. Micsoda távlatok! Egy operációs rendszer, amely nincs a vashoz kötve, amely igény szerint vándorol. A hardverhibák tökéletesen kiküszöbölhetőek! EZ KELL NEKEM!

Ekkor vettem meg az ESX-et. Persze a számlát nem akkor és nem én írtam alá, de amikor elmeséltem a főnökömnek, hogy mit láttam – és higgyétek el, eléggé érzékletesen meséltem el – nem volt többé kétség, hogy a virtualizáció felé indul a cég, és az új kiszolgálóinkat már ezzel szereljük fel. Rajtam múlt, én akartam, és tudtam, hogy ez a jövő, és pár év múlva minden a virtualizációról szól majd.

Az élet felgyorsult 2004. vége felé. Újabb és újabb kiszolgálókat kellett volna üzembe helyeznünk, de a iroda födémje ezt már nem bírta. Le kellett költöztetnünk a szerverszobát a földszintre. Olyan érdekesnek láttam az előttem álló feladatokat, hogy elhatároztam, blogot fogok vezetni. 2004. December 20.-án el is kezdtem. A legelső feladat, amelyet magam előtt láttam? VMWare ESX 2.5 szerver éles üzembe állítása. Végül sor került rá, a 2005-ben sokat írtam róla. Sajnos a beruházás elég költséges volt, vasakat is kellett venni, storage-ot, meg minden. Nem jutott már pénz a Virtual Centerre, sőt még a Virtual SMP-re sem. (Akkoriban azért még fizetni kellett.) És igazság szerint a Vmotion-t sem tudtuk megvenni. Bánni bántam, mert nagyon jó lett volna, viszont helyette megcsináltuk talán az ország első éles guest-clusterét RDM-mel. Éles Exchange 2003 clusterrel! Nem annyira látványos, mint a vmotion, de amikor belegondoltam, elégedett lehettem: tulajdonképpen ugyanazt csinálta, mint a vmotion, a szolgáltatást elválasztotta a hardvertől és tetszés szerint mozgatta. Ha kevés a pénz, akkor a kevésből kell kihozni a legtöbbet. Nekünk így sikerült.

————————————-

Ma már tudom, hogy több szempontból is nagyon tipikus volt, ahogy a VMware és a virtualizáció megjelent nálunk. Ezek közül a legfontosabbak:

    • Hardver erőforrás beszerzése a kiindulópont.
    • Közös, bemutatóval összekötött, profi mérnök vezette munkanap.
    • “Nagyvállalati technológiák” előtérbe helyezése – középpontban a magas rendelkezésre állás.
    • Homályos fogalmak, úgy mint: “bare metal hypervisor”
    • A bemutatón a teljes rendszer együttes bemutatása (Platform + Management)
    • A döntő momentum a Vmotion demó.

Bátran állítom, hogy a VMotion megjelenése pillanatától az egyik legfontosabb képesség a VMware számára. Eldönti az üzletet, eladja magát, meg a céget is. Nem véletlen, hogy csak a legdrágább VI változatban lehet hozzájutni.

Majdnem két évig volt páratlan funkció a VMotion. A Microsoft Virtual Server 2005 R2 – 2005. novemberében jelent meg, és először hordozott olyan képességet, amely, összevethető volt vele. Akkoriban ezt úgy hívták, hogy “host clustering”. Egy kis script, amely nem tesz mást, mint átmozgat egy virtuális gépet az egyik fürttagról a másikra. Az idő gyorsan elszállt, ma már Windows Server 2008-as fürtökön Hyper-V ketyeghet, és a beintegrált host clustering technológiát “Quick Migration”-nek nevezik. Ez egyáltalán nem úgy működik, mint a vmotion, ám amikor érték-elemzést végzünk, meglepő eredményre juthatunk. Nézzünk meg, hogyan is műkődik a két megoldás.

Technológiai ismertetők

A VMotion
products_vmotion_diagram A Vmotion technológiának van néhány előfeltétele, lássuk ezeket sorban:

  1. A megoldás szerverek között működik, tehát szükségünk van legalább két szerverre.
  2. Meg kell vásárolnunk a megfelelő licenceket. Látszólag nevetséges ezt felsorolni a feltételek között, de mégis muszáj. A funkcióval kapcsolatos táblázatok néha csalnak. Az ESXi ingyenes, és amikor a funkciót feltüntetik az ESXi képességei között, akkor úgy tűnik, mintha a Vmotion is ingyenes lenne. Nem az, pénzbe kerül.
  3. Szükségünk van valamilyen közös adattároló rendszerre, célszerűen SAN-ra.
  4. Szükségünk van egy olyan hálózati szegmensre, amelyen a Vmotion az adatokat mozgatja. Sok lesz belőle, ezért célszerű a dedikált szegmens és hálózati adapter.
  5. imageSzükségünk van közel azonos processzor architektúrára a szerverekben. A processzoroknak nem kell teljesen azonosaknak lennie, de azért rendes kis aknamezőt hozott össze az iparág. Szerencsére van kompatibilitási mátrixunk (HP forrás, Dell forrás) és a Vmotion maga is alapos ellenőrzést végez a gépmozgatás előtt. Jelenleg abszolút megkerülhetetlen feltétel az azonos gyártótól származó processzor (Reméljük nem sokáig: épp a minap demonstráltál először, hogy lehetséges live migration intel-amd processzorok között is. Ez ugyan most még nem ESX Vmotion, de idővel az is lesz.)
  6. Végezetül szükségünk lesz egy ún. fürtözött fájlrendszerre. Mindjárt azt is leírom, miért, itt most legyen annyi elég, hogy az ESX rendelkezik ilyennel, VMFS-3 a neve.

Ha minden előfeltétel adott, akkor lássuk a mutatványt – nem túlbonyolítva a működés mikéntjét:

  1. Kiadjuk az utasítás a gép mozgatására
  2. Az ESX elvégzi a megfelelő ellenőrzéseket, hogy a Vmotion művelet elvégezhető-e. (Van-e elegendő szabad memória a másik szerveren, megfelelő-e a processzor architektúra stb. stb.)
  3. A két rendszer elkezdi a virtuális gép memória tartalmát egyik szerverről a másikra másolni. Eközben a virtuális gép fut tovább, így a memória térképe is változik.
  4. A másolás végeztével egy újabb iterációval a megváltozott memóriablokkok másolása kezdődik, és a folyamat addig tart, amig a két kiszolgálón a mozgatandó gép memória-tartalma közel azonos.
  5. Az első kiszolgáló megállítja a virtuális gép futását, átmásolja az utolsó változott memóriablokkokat, végül a VMFS fájrendszerben elengedi a virtuális gép merevlemezeit. A második szerver lefoglalja a VM merevlemezeit reprezentáló fájlokat, elindítja a virtuális gépet, a hálózatra pedig kiküld egy olyan ARP csomagot, amely jelzi a hálózati kapcsolóknak, hogy a virtuális gép MAC címét ezentúl hol keressék. Ez az ötödik pont kevesebb, mint egy másodperc alatt zajlik le.
  6. Az első kiszolgáló törli a virtuális gép memória tartalmát. A folyamat kész.

Kritikus az egész tevékenységsor során, hogy a memória-lapok változásával keletkezett adatmennyiség képes legyen átvándorolni a másik kiszolgálóra. Ha bárhol szűk keresztmetszet jelentkezik, az iteráció soha nem ér véget, egy idő után pedig a művelet meghiúsul. A Vmotion tehát nem tudja garantálni az átmozgatás sikerét, sem a folyamat hosszát.
A fürtözött fájlrendszer az ötödik lépésnél nagyon fontos. Az ilyen típusú fájlrendszereknek az a sajátossága, egy egy időben több kiszolgáló is elérheti, írhat rá és olvashat róla, a fájlok zárolását és hozzáférését pedig egy elosztott algoritmussal biztosítják. Vagyis mindkét kiszolgáló “látja” a virtuális merevlemezeket, de egyszerre csak egyikük használja. Az átadás-átvétel ezzel a lehető leggyorsabb. Ugyanakkor látni kell, hogy a virtuális gép egy “egyszerű” vmotion műveletnél nem “mozog” sehová: a virtuális merevlemez változatlanul ott marad az adattárolón, csupán a futtatási feladatokat veszi át egyik szerver a másiktól. Ahhoz, hogy a virtuális gép tényleg vándoroljon, egy másik komponensre van szükség, amit úgy hívnak, hogy Storage Vmotion.

A Storage VMotion
imageHa megértettük, hogyan működik a Vmotion, akkor annak analógiájára könnyen érthetővé válik a storage vmotion működési elve. Technológiai részletekbe nem belebújva a lényeg virtuális lemezeket reprezentáló fájlok mozgatása különböző adattárolók között úgy, hogy közben a virtuális gép működik. Ez a képesség újra elindíthatja a fantáziánkat: SAN kiürítés, katasztrófa-telephelyek létrehozása, SAN reorganizáció, I/O terhelés elosztása stb stb.

Külön szépsége a megoldásnak, hogy különböző storage-ok között is működik. Kell hozzá persze a sávszélesség, meg vmotion licensz, csak parancssorból működik és számos korláttal bír, hogy mást ne mondjak, a Vmotion és a Storage Vmotion művelet együtt nem működik jelenleg, NPIV és Storage Vmotion kizárja egymást, snapshot-ot szintén nem használhat a virtuális gép stb. stb., de ettől még ígéretes képességnek tűnik(*). Sőt, ami még fontosabb: akárcsak a Vmotion esetén, további, még szofisztikáltabb megoldásoknak lehet később alapja (pl. Katasztrófa-védelem.)

Egyetlen részletkérdést nem tisztáztunk csupán: mi a helyzet meghibásodáskor? Mi történik, ha egy rendszergazda véletlenül mindkét tápkábelt kihúzza? Mi történik, ha tönkremegy egy kiszolgáló? Hogyan működik ilyen a Vmotion/Storage Vmotion? Nos, sehogy.

VMware High Availability
Meglepő, ugye? Pedig logikus. A Vmotion műveletek időt igényelnek. De a táp kihúzása után már nincs idő. A fizikai kiszolgáló leállt, a virtuális gépek pedig vele együtt a semmibe vesztek – legalábbis ami a memória-állapotukat illeti. A Vmotion/ Storage VMotion-nek esélye sincs működésbe lépni. Ezért van a VMware VI-ban egy haramadik komponens, amit nemes egyszerűséggel “High Availability”-nek, röviden HA-nak hívnak, és az a feladata, amit a Vmotion nem tud elvégezni: elindítani azokat a virtuális gépeket, amelyek a fizikai kiszolgáló hibája, vagy bármi más hiba miatt leálltak. Nincs állapotmentés, nincs működés közbeni átmozgatás és semmi hókuszpók. Egyszerűen csak elindítani azt, ami nem megy, méghozzá ott, ahol lehet.

A Microsoft oldal
imageAmit a VMware három komponenssel old meg, azt a
Microsoft másféllel próbálja. A Quick migration a Windows Server 2008-ban található Fail-over cluster és a Hyper-V szerepkör házassága. Nézzük az előfeltételeket:

  1. Szerverek között mozgatunk majd virtuális gépeket, tehát itt is szükség lesz legalább két kiszolgálóra.
  2. Szükségünk lesz a megfelelő kiszolgáló oldali licenszre is. Néha tévesen azt feltételezik, hogy a Hyper-V csak a Windows Server 2008 Enterprise és DataCenter kiadásban található meg. Ez nem így van, a Standard kiszolgáló is futtathat Hyper-V szerepkört. Ugyanakkor érvényes a kiadások közötti “rendes” különbség. Konkrétan a mi esetünkben a Standard kiadás nem tartalmazza a Fail-over cluster-t, így az amúgy létező Hyper-V szerepkörrel sem tud integrálódni. Sok beszédnek sok az alja: a Quick Migration-höz Enterprise vagy Datacenter kiadást kell vásárolni a szerver hardverhez. Vegyük ugyanakkor észre, hogy a Microsoft szerint ez a képesség az  operációs rendszer része és nem igényel külön menedzsment eszközt, pláne nem licencet.
  3. Szükségünk lesz SCSI3 Reservation parancsokat értő/ismerő közös tároló rendszerre – célszerűen SAN-ra.
  4. A teljes rendszerre vonatkozóan le kell futtatni a fail-over cluster beépített ellenőrző funkcióját (ez telepítéskor mindenképp lezajlik, de később is bármikor elvégezhető.) Ha a validációs eljárásnál a rendszer nem talál kifogásolni valót, akkor a fürt – függetlenül attól, hogy milyen gyártótól származnak a komponensek – támogatott lesz.
  5. A Quick Migration éppúgy memória és processzor állapotot mozgat át egyik gépről a másikra, mint a VMotion. És éppen ezért ugyanolyan feltételeket támaszt. Vagyis: a fürttagoknak azonos processzor-architekúrával kell rendelkezniük. A Microsoft nem bocsátott (még) ki kompatibilitási mátrixot, de 99%-os valószínűséggel a HP és Dell források megfelelnek itt is.

Ha minden feltételnek eleget tettünk, akkor következhet az átmozgatás:

  1. Kiadjuk a parancsot a virtuális gép mozgatására.
  2. A Hyper-V megállítja a VM virtuális processzorát és elkezdi a memória tartalmat a merevlemezre menteni.
  3. A kliens alkalmazások – függően attól, miként kezelik a hálózati kimaradást – jelzik, hogy a kiszolgáló nem elérhető. A memória nagyságától és a rendelkezésre álló HBA-k biztosította sávszélességtől függően a Hyper-V lemezre menti a virtuális gép futási állapotát.
  4. A virtuális gépet reprezentáló fürt erőforrások egyesével “Offline” állapotba kerülnek. Ultoljára a lemez erőforrás.
  5. A utasításnak megfelelően az erőforrás csoportot az cél-kiszolgáló veszi birtokba. Technikai értelemben ez egy SCSI3 lefoglalási paranccsal zajlik. Ez a fázis egy másodperc alatt zajlik le.
  6. Az új kiszolgálón elindulnak a fürt erőforrások. Az első ezek közül a lemez-erőforrás, amely a virtuális gép merevlemezeit tartalmazza.
  7. A Hyper-V lefoglalja az átkötöző virtuális gép által igényelt memória mennyiségét és megkezdi betölteni azt, felolvasva a másik kiszolgáló által lementett adatokat.
  8. Miután a betöltés sikeres volt, a Hyper-V elindítja a virtuális gép processzorát és egy ARP csomaggal jelzi, hol található az új virtuális gép. A folyamat befejeződött.

A mozgatásban nincs iterációs lépés és nem függ a virtuális gép terheltségétől, kizárólag a SAN sávszélességétől. A Quick Migration mindig lezajlik, és a mozgatás ideje jó közelítéssel becsülhető. Ha a célkiszolgáló nem lenne képes fogadni a virtuális gépet, a fail-over cluster automatikusan újabb és újabb kiszolgálót keres mindaddig, amíg a virtuális gépet újra működésbe nem lehet hozni.
Végül látható, hogy nincs fürtözött fájlrendszer, a lemez-erőforrásokat egyszerre csak az egyik fürttag birtokolhatja/olvashatja/írhatja. Akárcsak a VMotion esetén, itt sem mozog a virtuális gép lemeze, csupán annak birtoklása. A tényleges vándorláshoz további eszközökre van szükség.

imageFöldrajzilag elosztott fürt
Nincs szégyenkeznie valója a Windows Server 2008-nak, támogatja a földrajzilag elosztott fürtöket. Igaz, storage replikációs technológiával nem rendelkezik, de ha van ilyen alatta, akkor képes használni. A földrajzilag elosztott fürt persze egy kicsit más, mint a storage vmotion. A kitűzött cél itt a katasztrófa kivédése és a folyamatos üzemmenet. Nincs szó SAN depopulációról, I/O átterhelésről és hasonlókról. Heterogén tároló-rendszer megoldás szinte biztosan nem működik. Viszont a kitűzött célt elég magas szinvonalon elvégzi, többféle modellel – mellesleg nem csak Hyper-V esetén.

Magas rendelkezésre állás
Már csak egy kérdést kell tisztáznunk: mennyire működik a magas rendelkezésre állás? Mi történik egy Hyper-v kiszolgáló elszállásakor?

Nos, a Microsoft megoldása ebben az esetben is a Fail-over cluster. Ha egy kiszolgáló kiesik a fürtből, a többi tag ezt azonnal észreveszi, az erőforrásokat pedig azonnal és automatikusan elindítja a következő preferált vason. Nincs állapot, amelyet vissza lehetne tölteni, a cluster ilyenkor a virtuális gépeket csupán elindítja. Figyelem! A Quick Migration és a HA a Microsoft világában ugyanaz a szoftver végzi.

Az alapokból ennyi elég, az értékelés a következő cikkre vár.

——————————————————–

(*) – Egy szoftver mindig egy adott szolgáltatás-készlettel rendelkezik: sohasem kész, viszont tulajdonsága, hogy kiadták. A képességeit megvizsgálva el lehet dönteni, hogy kielégíti-e a mi igényeinket, vagy sem. Ha kielégíti, akkor jó, ha nem nem. Értelmetlen ugyanakkor az “1.0” használata lekicsinylő értelemben.

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

  1. fearme says:

    "A Microsoft nen bocsátott (még) ki kompatibilitási mátrixot, " Nen? :-)

  2. Tamas says:

    Köszi, 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: