A VMware ESX 3.5 és a Hyper-V összehasonlítása – 10. 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.)

Tervezett leállás
Amikor tervezett leállásról beszélünk, akkor valami előre eltervezett tevékenységre gondolunk. Mi most megengedőbbek vagyunk. Minden olyan szituációt, amikor nem lép fel hiba, és a virtuális gépek szabályos módon át akarnak/tudnak költözni egyik kiszolgálóról a másikra, tervezett leállásnak tekintünk. A tervezett leállás célja, hogy kiürítsünk egy szervert, és annak hypervisorát vagy hardverét karbantartsuk. A VMware a fenti célra a VMotion-t, a Microsoft jelenleg a Quick Migration-t használja.

Sokan kétlik, hogy a két megoldás egyáltalán összevethető. Gondolom mindenki láttam már a VMware mérnökök által készített rövid demókat, amely bemutatták a két megoldás közötti különbséget, és demonstrálta, mennyire “alkalmatlan” a Quick Migration vállalati környezetben. Van még ember, aki veszi a bátorságot az összehasonlításra? No, én veszem a bátorságot.

image_thumb2 Készítettem egy kis excel táblát, amelyben azt lehet vizsgálni, hogy egy szolgáltatás rendelkezésre állására hogyan hat a virtualizáció. Elgondoltam, hogy a mai vállalati szolgáltatások elosztottan, több számítógép együttműködésével valósulnak meg. Három fő szituációt hasonlítottam össze:

  1. Minden gép fizikai kiszolgálón fut .
  2. Minden gép virtuális gépben fut Hyper-V környezetben, és működik a Quick Migration.
  3. Minden gép virtuális környezetben fut VMware ESX környezetben, a gépek mozgatását pedig a Vmotion szolgáltatás végzi.

A modell átláthatósága érdekében néhány egyszerűsítéshez folyamodtam, ezek a következők:

  • Mindegyik szituáció homogén, tehát ugyanolyanok a gépek, csak egyfajta technológiát használunk (vagy csak fizikai, vagy csak Hyper-v, vagy csak ESX)
  • Egy gép egyetlen feladatot lát el, amely a teljes szolgáltatásnak egy része. Egygépes környezetben a részfeladat egyenlő a teljessel.
  • A gépek méretét átlagosra vettem az itt látható táblázatból. 2 GB RAM-mal rendelkeznek és 2 Gb-es Fibre Channel kapcsolattal. A Quick Migration áttérési időt a táblázatból vettem, és 16 másodperccel számoltam minden alkalommal.
  • Nincs nem tervezett leállás.
  • A tervezett leállások az alábbi okokból következhetnek be (nem mindegyik létezik minden szituációban, módosítható értékek):
    • Vendég gép alkalmazásának karbantartása (egységesen 20 perc/hónap)
    • Vendéggép operációs rendszerének karbantartása (egységesen 20 perc/hónap)
    • Gazdagép karbantartása (OS és hardver együtt, újraindulással, egységesen 20 perc/hónap)
    • Quick Migration átállási idő (egységesen 16 másodperc)
    • Quick Migration visszaállási idő (egységesen 16 másodperc)
  • Ha egy gép bármely okból leáll, akkor a teljes szolgáltatás leáll. Minden gép szükséges a teljes szolgáltatás működéséhez.

Ez utóbbi feltételezés nagyvállalati környezetben nem állja meg a helyét, ezért a gépek száma alatti sorban feltüntettem azon gépek számát, amely redundanciát biztosítanak egy-egy rész szolgáltatásnak. Ez további állásidőket hozott be a modellbe:

  • A redundáns rész-szolgáltatás átállási ideje a tartalék kiszolgálóra. Egységesen 16 másodpercben számoltam, ami erős átlag. Vannak olyan szolgáltatások, amelyeknek nincs szükséges átállási időre (pl.: AD, DNS, NLB), másoknak viszont akár több is lehet, mint 16 másodperc (pl: Exchange adatbázis, SQL adatbázis stb.)
  • A redundáns rész-szolgáltatás visszaállási ideje a tartalék kiszolgálóra.

Ezek az új állásidő-típusok ugyanakkor megtakarításokat is jelentenek. A redundáns rész-szolgáltatások esetében nem kell számolni a Quick Migration időkkel, sem a vendég operációs rendszerek és szolgáltatások karbantartási idejével. Amikor tehát megadunk egy redundanciát biztosító kiszolgálót, a modell levonja az így elért megtakarításokat.

Négy kiesési idővel számoltam, természetesen ezek sem jelentkeznek mindig minden alkalommal. A négyféle kiesés:

  1. A nem redundáns rész-szolgáltatások kiesési ideje. Havonta meg kell frissíteni az alkalmazást és az operációs rendszert.
  2. A redundáns rész-szolgáltatások kiesési ideje. Az át- és visszaállási idők.
  3. A virtuális gépek mozgatásából fakadó kiesési idők. Ez értelem szerűen csak a Quick Migration esetén jelentkezik.
  4. A hardver karbantartásból fakadó kiesési idők. (Beleértve a hypervisor karbantartását is.) Ez meg, természeténél fogva, csak a fizikai környezetben jelenik meg, hiszen mind a hyper-v mid pedig az ESX kiüríti a gazdagépet, tehát annak karbantartása nem jelent szolgáltatás kiesési időt.

A négy kiesési időt összegeztem és megszoroztam 12-vel, hogy az éves kiesést láthassuk. Végül éves rendelkezére állást számoltam, meg azt, hogy a kiesési időt hány százalékkal képes csökkenteni a Quick Migration illetve a Vmotion. Akkor most játsszunk a számokkal.

Az első körben egy olyan szolgáltatásra végeztem számítást, amely egyetlen kiszolgálón fut. Az eredmény az ezen a képen látható. A modell szépen kihozta, hogy a virtualizációval jelentősen csökkenthető az állásidő, mert a hardver karbantartása többé nem befolyásolja a szolgáltatás működését. Az is látható, hogy a legjobban a VMotion teljesített. A Quick Migration elmaradása ugyanakkor minimális, a rendelkezésre állást tekintve ezredszázalékban mérhető, de az állásidő csökkentésének mértékében is 1%-on belül marad.

Egy gép nem gép. Nézzük a következő ábrát, itt 50 kiszolgáló alkot egyetlen nagy szolgáltatást. A fizikai szerverekből álló rendszer rendelkezésre állása 93% könyékére sűllyedt. Érthető: ha nincs magas rendelkezésre állás, akkor a karbantartás mind jobban zavarja a szolgáltatást. A virtualizációs megoldások jobban teljesítettek 95%-ra “érkeztek”, kidomborodik a hypervisorok alkotta fürtök előnye. Ugyanakkor még egy ilyen nagy rendszernél is tized százalékon belüli a Quick Migration hátránya a VMotion-höz képest. Elgondolkodtató, ugye? És az is elgondolkodtató, hogy a virtualizáció sem képes megoldani a szolgáltatás rendelkezésre állásának erodálódását.

És akkor végül a harmadik ábra. Öt kiszolgáló alkotta szolgáltatás. A Quick Migration-nel rendelkező felhasználók előtt két hiptetikus út áll: átnyergelnek VMotion-re, vagy elkezdenek foglalkozni a szolgáltatások magas rendelkezésre állásának biztosításával a virtuális gépeken belül. Ezt mutatja a két kis nyil. A VMotionnal, láttuk, tizedszázalékot lehet nyerni. De akár csak egyetlen rész-szolgáltatás magas rendelkezésre állásúvá konvertálása 13%-kal több állásidő csökkentést tesz lehetővé. Ha viszont nő azoknak a gépeknek a száma, amelyek a virtuális világon belül redundánsak, akkor tovább eliminálódik a Quick-Migration-ből fakadó leállás (A D16-os érték 2 perc nyolc másodperc. Ha nem lenne a plusz egy redundancia, akkor 2:40 lenne)

Levonható következtetések:

  1. A virtualizáció azonnali rendelkezésre állás növekedést eredményez, mert megszűnik a hardver karbantartás. A VMotion és Quick Migration itt és csak itt fejti ki jótékony hatását.
  2. Bármilyen nagy és összetett alkalmazásról beszélünk, a Quick Migration hátránya a Vmotion-höz képest elenyésző.
  3. Ha nem gondoskodunk a virtuális gépeken belüli alkalmazások redundanciájáról, akkor nem tudjuk megakadályozni a teljes szolgáltatásunk rendelkezésre állásának erodálódását. Ennek az ok az, hogy a vendég rendszereket továbbra is karban kell tartani. Amíg a HA-nál még megengedők lehettünk, itt már nem. Súlyos baklövés kihagyni a vendéggépek fürtözését vagy egyéb módon való többszörözését. Ha valakinek a rendelkezésre állás fontos, akkor a VMotion/Quick Migration önmagában nem elég.
  4. Ha a VM-eken belül is alkalmazunk valamilyen redundanciát, akkor ugrásszerűen javul a rendelkezésre állás – és még inkább marginalizálódik a VMotion és a Quick Migration közötti különbség!

Van még jó hírem. A modellben “kialakított” szolgáltatások mind azt feltételezik, hogy a kliensek a túloldalon azonnal leszakadnak és a szolgáltatás megszűnik, éppen úgy, ahogy a VMware-es videóból is látszik. A valóság azonban teljesen más. Mi történik, ha egy Exchange kiszolgáló eltűnik egy pillanatra a hálózatról, a szolgáltatás túloldalán pedig Outlook 2003/2007 szoftverek futnak? Mindenki tudja a választ: ha működik a “cache mode exchange” üzemmód, akkor semmi. Az Outlook kliensek tűrik a szakadást, majd alkalmas időben újraépítik a kommunikációs csatornát. És mit történik egy Terminál szolgáltatás esetén? Semmi. Pontosabban az RDP kliens 20 alkalommal megpróbál újracsatlakozni, és amint sikerül, ott lehet folytatni a munkát, ahol abbahagytuk. (Jól látható a videóból, hogy a Hyper-v esetén nem egy valódi Remote Desktop, hanem a Hyper-V Manager VMConnect szolgáltatása szakad meg.) Fájlmásolás? Nézzünk nagyvállalati fájlszolgáltatást! Mi történik, ha egy SCCM disztribúciós pont replikál egy másik disztribúciós pontra és megszakad közöttüka kapcsolat? Semmi. Amikor helyreáll, ott folytatják, ahol abbahagyták. Mi történik ha egy felhasználó a hálózati meghajtóra átirányított, majd kapcsolat néküli üzemmódra felkészített “My Documents” mappájában megnyit egy állományt a szerveren? Vista esetén semmi. A rendszer tűri a kapcsolat nélküli üzemmódot, még az éppen nyíitott állományok esetén is. (Auto-Offline üzemmód.)

Vagy nézzük (a modell által érintett) redundáns szolgáltatásokat! Mi történik, amikor egy tartományvezérlő fél-percre, egy percre kiesik a hálózatból? Semmi, a tartalék DC dolgozik helyette. Mi történik a DNS szolgáltatással? Semmi, a másik DNS működik. Mi történik, ha egy DHCP szerver nincs rajta a hálózaton egy percig. Semmi, a kliensek újrapróbálkoznak egy kicsit később. Mi történik, ha egy NLB-fürtbe tett webszerver egyik állomása épp nincs rajta a hálózaton. Semmi,a többiek végzik a munkájukat. Láthattuk a modellből, hogy a szolgáltatások redundanciája nem oldható meg kizárólag HA-val, VMotion-nel, Quick Migration-nel. Ha viszont szükség van a Guest clustering bármilyen formájára, értelmét veszti a Quick Migration használhatatlanságáról beszélni.

És még néhány apróság:

  • a VMotion (és a majdan megjelenő Microsoft-féle Live Migration) használatakor NEM GARANTÁLT az átállás egyik kiszolgálóról a másikra. Ha túl gyorsan változnak a memória-lapok, és nincs elég sávszélesség az átmásolás befejezésére, a VMotion folyamat egy idő után leáll. A sokat szidott Quick Migration viszont végbemegy.
  • A VMotion nem működik a Raw Device Mapping “Physical Compatibility” módjával, sem az SCSI2-es (értsd: Windows Server 2003, vagy korábbi) Microsoft Guest clusternél. A Quick Migration számára a Pass-through disk nem akadály (SCSI2-es Guest cluster viszont Hyper-V alatt nincs, ahogy azt már korábban írtam.)

A témát egy nem jelentéktelen ténnyel szeretném zárni. Vajon mennyire fontos a virtuális gépek mozgatása? Mindkét gyártó azt állítja, hogy nagyon fontos. Ehhez képest egyik sem teszi lehetővé, hogy bármely megoldásában a gépmozgatás megjelenjen. A VMware egyenesen csak a legdrágább csomagjának megvásárlóiról gondolja úgy, hogy fontos nekik a tervezett leállás. A Microsoft ehhez képest megengedőbb: nem kell menedzsment szoftver venni a funkcióhoz (néhány képesség feláldozása az ár), és nem kell a legdrágább operációs rendszert megvenni. Ez az ügyfél szempontjából jobb. A tökéletes persze az lenne, ha mindenki, minden verzióban ingyen hozzáférne ezekhez a funkcióhoz. Mert tényleg fontos!

Végső következtetésem, hogy – az általános vélekedés ellenére – a VMotion nem szükséges a tervezett karbantartáshoz. Jó, ha van, jó, ha az ember megengedheti magának, technológiai értelemben jobb, mint a Quick Migration. A Quick Migration viszont, a jelenlegi licencelési konstrukciókat nézve – ár/teljesítményben elpáholja a VMotion-t.

Akkor hol fontos a működő gép kiesés néküli mozgatása egyik kiszolgálóról a másikra? Az dinamikus erőforrás-használat kiegyenlítésnél. Vagyis… majd a következő cikkben meglátjuk.

No. Tulajdonság VMware ESX 3.5
VMotion
Microsoft Hyper-V
Quick Migration

1. Gépmozgatás szolgáltatás leállás nélkül Igen Nem(*)
2. Tömeges gépmozgatás Igen Igen
3. Gépmozgatás telephelyek között (multi-site cluster) Nem Igen
4. Garantált idejű átmozgatás Nem Igen
6. Processzor kompatibilitási ellenőrzés Igen Nem
7. Raw Device Mapping (RDM) “Virtual Compatibility mode” lemezes VM mozgatása Igen N.A. (**)
8. RDM Physical Compatibility mode / Pass-through lemezes VM mozgatása Nem Igen
9. SCSI2 alapú Microsoft Cluster node virtuális gép mozgatása Nem N.A. (**)
8. Mozgatás management szoftver nélkül (technikailag) Nem Igen
10. Licencelés VI Management része W2008 EE / Datacenter része

Megjegyzések

* – A cikkben felsorolt kivételektől eltekintve
** – Ilyen képesség a Hyper-V-ben nincs

Utóirat:
A VMotion-Quick Migration összevetésének van még egy dimenziója, de ezt majd csak a 11. rész végén tárom fel.

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 VMware ESX 3.5 és a Hyper-V összehasonlítása – 9. kör

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

  1. Attila says:

    Szia Tamás!- A VMotion RDM esetén is működik ESX-en.- Quick Migration ESX-en is van: suspend és drag&drop (vagy jobb katt, "Migrate"). Valaki VC plugint is írt hozzá tudtommal, tehát a VMware nem kevesebb (írod: VMotion nem valósítható meg, ha túl gyorsan változnak a lapok). (a memória átmásolás idejéhez képest nagyon nem változtat az a lényegen, hogy kézzel húzza át valaki a VM-et vagy automatikusan történik: ha a hálózati kapcsolatok megszakadtak, akkor már mindegy)- MSCS: valószínűleg pont a Microsoft a gátja annak, hogy a VMotion nem támogatott, egészen pontosan ESX clusterben nem támogatott az MSCS VM-en belül.- a processzor kompatibilitás ellenőrzése kulcsfontosságú, szerintem 1-2 mondatot bőven megért volnaA kettő közötti különbségről való teljes véleményemet az újabb bejegyzésben fejteném ki, oda jobban passzol.Üdv,Attilaui: az xls-t nem tudtam megnyitni/letölteni

  2. Tamas says:

    RDM – Virtual compatibility módban valóban működik, fizikaiban pedig nem. – Ezt írtam a táblázatba is. Rosszul tudom?Az host-cluster guest-cluster keverése MS környezetben sem támogatott általában. Alkalmazástól függ. A dolog ilyen formában nem szép, de igazságos.A processzor kompatibilitásról külön – ahogy megígértem.Hol akadsz el az XLS-nél? Nekem működik.

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: