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

A Hyper-V megjelenése óta figyelem, hogyan reagálja le a szakma és a blogvilág az új hypervisort. Hát érdekesen. Ha a Microsofttal szimpatizáló forrásból olvasunk, akkor valahogy így:

  1. Végre megjelent, előbb, mint ígérték.
  2. Valódi bare-metal, kicsi többlet-terheléssel. Gyors.
  3. Minden lényeges és fontos képessége megvan, hogy sikeres legyen. Érett a nagyvállalati bevezetésre.

Ellenben, ha VMware-kedvelő forrásra akadunk, akkor meg ezek a végkövetkeztetések:

  1. Késve jelent meg. Az ESX-hez képest mindenképp, de még az eredeti ígéretekhez képest is.
  2. Nem igazi bare-metal megoldás, nagy (értsd: sok kód).
  3. Lényeges, alapvető képességek hiányoznak belőle, úgymint: vmotion, DRS, memory-overcommit. Nem érett a nagyvállalati környezetre

Na, nesze neked! Itt igazodj ki, ha tudsz! Márpedig ki kell igazodni, mert a virtualizáció nagyon itt kopogtat. Csak egyedül én fel tudnék sorolni vagy egytucat olyan projektet, amely a kiválasztási fázisban tart nagyvállalatoknál, és az a kérdés, hogy VMware ESX vagy Hyper-V. Vagyis a precíz információra szükség van.
Nos, a webnaplóból mindenki tudja, hogy a Microsoftnál dolgozom, ezért aztán, ha úgy tetszik, lehet majd legyinteni az elkövetkezedő írásokra, hogy részrehajló, hiszen egy MS alkalmazott írta. Ezzel együtt megpróbálok mindent elkövetni, hogy objektív és elfogulatlan összehasonlítást írjak, már amennyire ez lehetséges.
A termékek teljeskörű összehasonlításával, legalábbis ami engem maradéktalanul kielégített volna, még nem találkoztam. Részben azért, mert minden írás egyetlen cikkre szorítkozott, részben pedig azért, mert a cikk írói többnyire csak a felszínt karcolták.
Elhatároztam, hogy a lehető legteljesebb elemezést írom meg, ami persze azzal jár, hogy kénytelen leszek részekre szabdalni a mondanivalómat, nagyjából az alábbi fejezetek szerint:

  1. Architektúrális összehasonlítás
  2. Processzor- és memória-használat
  3. A virtuális gépek belülről.
  4. Hálózatkezelés és adattárolás
  5. Magas rendelkezésre állás, tervezett karbantartás, terhelés-elosztás
  6. Rendszerfelügyelet – alapok (Host kezelés, VM életciklus, biztonság, P2V V2V)
  7. Rendszerfelügyelet – haladó (host monitorozás, mentés)

No, csapjunk a lovak közé!

——————————————————————————————————————————————————

A Hyper-v története
Az új generációs hypervisorát a Microsoft 2005-ben kezdte fejleszteni és kezdetben 2008-ban szándékozták kiadni önálló termékként. Később azonban változott a stratégia, és felmerült egy, a Windows Longhorn szerverbe (a későbbi Windows Server 2008-ba) integrált változat kiadása. 2006-ban aztán véglegesedett a megjelenés formája és időpontja. 2006 májusa óta a Microsoft úgy határozta meg a Hyper-V kiadási időpontját, hogy a "Windows Server 2008 megjelenését követő 180 napon belül". Ez teljesedett is, sőt 120 nap lett a 180-ból. Ugyanakkkor a történet úgy teljes, hogy maga a szerver termék késett, illetve 2007-ben – épp határidő tartása érdekében – jónéhány funkciót kivágtak a Hyper-V-ből. Összefoglalva tehát:

  1. Az eredeti tervek 2008-as megjelenéssel számoltak.
  2. A Microsoft felkorbácsolta a várakozásokat azzal, hogy a szerverbe integrálta a Hyper-V-t, amelynek az eredeti megjelenése ezzel 2007-re csúszott előre.
  3. Maga a Windows Server 2008 késett, így vele késett a Hyper-V is.
  4. Az Hyper-V előbb jelent meg, mint az ígért Windows Server 2008 RTM dátum plusz 180-nap, de jópár, korábban beharangozott funkciót nem fejlesztettek bele.

A Hyper-V és az ESX architektúrájának összehasonlítása
A Hyper-V és az ESX szerver is type1-es hpyervisor, ezt szokás bare-metal hypervisornak is mondani. A témát ebben a webnaplóban már körbejártuk a Mi is az a hypervisor? – Megoldások cikkben, sőt utána lőttünk a Triviális és mégis bejegyzéssel. A teljesség kedvéért felrajzolom a különböző típusok közötti különbséget.

image

Az utóbbi napoknak az az egyik tanulsága, hogy a "Bare metal" igazi marketing fogalom lett. Egészen a hyper-v megjelenéséig a "bare metal = type1 hypervisor"
egyenlet mindenki által elfogadott volt. Mostanság viszont egyre több forrásból olvasom, hogy a Hyper-V, úgymond, nem igazi bare metal megoldás, mert szüksége van egy gazdarendszerre, anélkül nem fut. Az érvelés mögött két helytelen feltételezés húzódik meg. Az egyik az a legenda, amely szerint a bare metal hypervisor esetén nincs szükség operációs rendszerre. Ez nem igaz. Az VMware ESX kiszolgáló vitán felül "bare metal", mégis szüksége van egy Console OS partícióra, ahol bizony egy operációs rendszer fut. Az ESXi-nél ilyen Console OS már valóban nincs, de a "Triviális és mégis cikkben" tisztáztuk, hogy ez azért lehetséges, mert minden operációs rendszer funkció a hypervisorba került, vagyis a hypervisor maga az operációs rendszer. A másik helytelen feltételezés az, hogy a gazdagép egyben azt jelenti, hogy nem virtualizált gép. Ez sem állja meg a helyét. Az ESX, az ESXi, a Hyper-V (és a Xen és a KVM is!) olyan hypervisor, amely még a szülő/console/dom0 gépet is virtualizálja.

image A typer1-es hipervisorok ugyanakkor nem egyformák. Legalább két "alfajuk" van, a monolitikus és a mikrokernel típusú. A VMware ESX és az ESXi monolitikus hypervisor, míg a Xen és a Hyper-V mikrokernel alapú. Most nem cifrázzuk túl a különbségek elemzését, a legfontosabb a fizikai hardvert kezelő eszközmeghajtók elhelyezkedése. (Lásd ábra). Az ESX/ESXi-nél az eszközmeghajtókat a hypervisorba fordítják. Ebből következően a legnagyobb privilégium-szinttel rendelkező kódrész összetettebb lesz. További következmény, hogy a driverek száma nem lehet akármennyire sok, tehát mindig a szoftvergyártó (értsd: VMware) határozza meg, milyen eszközkezelőket tartalmazzon a rendszer, ergó a támogatott hardverek száma korlátozottabb. Szerencsére a hardvervilág minden komponense néhány nagyobb szállító körül kristályosodik, így viszonylag kevés eszközmeghajtóval is a szállítók modelljeinek nagy része lefedhető. Ezzel együtt a dolog sohasem biztos, ezért a VMware szinte hetente adja ki az újabb és újabb kompatibilitási listáit éppen azért, hogy az ügyfelek ne fussanak lyukra a hardver beszerzés indításakor.
Végezetül meg kell említeni, hogy a hypervisorba befordított eszközmeghajtók nem módosítás nélküliek, vagyis ismét csak a VMware fejlesztőitől függ, hogyan és mikor kerülnek a szoftverbe.

A Hyper-V mikrokernel architektúrájú. Ez azt jelenti, hogy a hypervisor kizárólag a processzor vezérlését (ütemezés stb.) és a memóra kezelését végzi. A perifériák meghajtásához szükséges eszközmeghajtók egy privilégium szinttel feljebb, a szülő partícióban helyezkednek el. Ez nem azt jelenti, hogy a hyper-v nem kontrollálja a teljes hardvert. Kontrollálja, úgy csapja be a szülőpartíciót, ahogy akarja. Viszont a fenti felépítés lehetővé teszi, hogy a Windows eszközmeghajtók változtatás nélkül használhatók legyenek. A gyártóknak nem kell új módszert megtanulniuk az meghajtók írására, a Microsoftra sem kell várni, hogy egy eszközmeghajtó virtualizált környezetben is használható legyen. Éppúgy kell telepíteni őket, mintha nem virtualizált rendszerről beszélnénk. Mindemellett a hypervisor erőteljesen leegyszerűsödött és semmilyen harmadik gyártótól származó kódot sem tartalmaz.
Akkor most megbízhatóbb a hypervisor felépítése? Erre nem lehet határozott igent mondani. Kisebb hypervisorhoz kevesebb hiba tartozik – elméletileg. Másrészt viszont ha egy eszközmeghajtó miatt megáll a szülőpartíció, akkor a teljes rendszer megáll, a szülőpartíció tehát egy Achilles sarok (Single Point of Failure). A felépítés végső előnye nem a versenytárs termékekkel szembeni nagyob megbízhatóságban, hanem a szélesebb használati körben rejlik, meg abban, hogy az eszközkezelők változatlanul használhatók.
Persze vannak, akiknek épp ez a bajuk, mondván: ha akármilyen eszözmeghajtót fel lehet telepíteni, akkor a rossz minőségű meghajtók bizonytalanná tehetik a teljes rendszert. Tegyük a kezünket a szívünkre! Mikor omlott össze utoljára SZERVER operációs rendszer a kezünk között eszközmeghajtó probléma miatt? Az igazság az, hogy ha van is probléma a meghajtókkal, az többnyire a desktop operációs rendszereknél jelentkezik (monitorvezérlő, nyomtatómeghajtó). A kiszolgálóknál sokkal kevesebb számosságú, sokkal egyszerűbb meghajtó üzemel, a problémák mértéke is ehhez igazodik. Ma már ezen a téren semmiféle szégyenkeznivalója nincs a Microsoftnak. Arról nem is beszélve, hogy a Hyper-V – lévén csak 64-bites verzióban érhető el – kizárólag a Microsoft által aláírt, tehát az MS által tesztelt, bevizsgált meghajtókkal találkozik.

Még egy aggodalom üti fel a fejét rendszeresen a Hyper-vel kapcsolatban. Mivel minden vendéggép a szülőpartíción keresztül éri el a perifériákat, ezért a szülő partíció maga szűk keresztmetszetté válhat. Szerintem ez a lehetőség kizárt, a következők miatt. A virtuális gépek a szülőpartíción keresztül az IO műveleteket végzik el. A processzor- és a memória elérés a hypervisoron keresztül zajlik. A szülőpartíción keresztül zajló adatforgalom túlnyomó részt a lemezhozzáférésből (írás- és olvasás), valamint a hálózati adatcseréből áll. A szülő partíció a gyermekpartíciókkal egy kernel módú, pont-pont VMBus csatornán keresztül kommunikálnak (a témát májusban veséztük a Virtuális eszközök és a Hyper-V cikkban). A szülő partíció akkor jelentene szűk keresztmetszetet, ha a szülő partíció és a virtuális gépek közötti VMBuszok bedugulnának, miközben egy adott periféria kihasználatlan marad. Könnyű belátni, hogy a memória-lapok másolásával működő VMbus adatok sokkal nagyobb sávszélességgel rendelkeznek a szülő partíció felé, mint a szülő partíció a lassú hálózati vagy külső adattároló rendszerek felé. Ebből az következik, hogy a szűk keresztmetszet mindig a periféria lesz, és nem a szülő partíció.

Nem mehetek el még egy fontos – szintén megkérdőjelezhető – állítás mellett. A minap nyilatkozott Paul Maritz, a VMware frissen kinevezett vezérigazgatója és a Hyper-V-t úgy emlegette, mint az ESXi versenytársát. Szó szerint ez hangzott el:

Microsoft’s Hyper V hypervisor, software that separates hardware from operating systems and applications inside computer servers, is virtually free. How do you plan to compete with that?
We don’t see the need to lower our price points. But that said, we created lower price SKUs for our customers. Hyper V is really just one layer and it corresponds to our ESXi. Our customers no longer pay for that. What they pay us for is the software that sits on top of that. Microsoft is not there yet. They don’t have the virtual infrastructure suite that we have.

A Hyper-V-t az ESXi-vel összehasonlítani nem igazán célszerű. Az ESXi egy olyan hypervisor változat, amely nem tartalmazza a teljes ESX host consol OS részét. Egy mindössze 32 MB-os szoftverről van szó, amely látszólag éppúgy partícionál és virtualizál, mint a nagy testvér ESX. A kis méret lehetővé teszi, hogy Flash kártyán tárolják, gyakorlatilag egyfajta firmware karakterisztikát mutat ezzel. Az ESXi célpiaca inkább a kis- és középvállalatok.
A VMware számára legalább két ok miatt célszerű az ESXi vs Hyper-V összehasonlítást erőltetni.

  1. Az ESXi kis méretével szemben a Hyper-V szülőpartícióval szemben kb. 2 GB igényel. No nem a memóriában, hanem egy merevlemezen, de ilyen optikán keresztül már "nem is olyan lényeges" a mikrokernel architektúrából fakadó 500 KB-os hypervisor méret.
  2. Az ESXi a kis- és középvállalatokat célozza. Azáltal, hogy az összehasonlítást erőltetik, azt a látszatot lehet kelteni, mintha a Hyper-V is csak a kis- és középvállalatokat célozná meg. Jelentem, nem így van!

Az ESXi-nek a Microsoft oldalán jelenleg nincs versenytársa. 2007. novemberében bejelentettük, hogy megjelenik majd egy "Microsoft Hyper-V Server" nevű termék. Célszerű lesz majd azt a két megoldást összevetni.

Összefoglalásul készítettem egy táblázatot, hogy a leírtakat gyorsan át lehessen tekinteni. Zölddel írtam azt, amit előnynek látok egyik, vagy másik megoldásnál.

No. Tulajdonság VMware ESX 3.5 Microsoft Hyper-v
1. A megjelenés dátuma 2007. dec.(1.0 – 2001) 2008. június
2. A hypervisor típus type1 (bare metal) type1 (bare metal)
3. A hypervisor architektúrája monolitikus mikrokernel
4. Eszközmeghajtó modell hypervisorba integrált szülő partícióba telepíthető
5. Az eszközvezérlők létrehozása módosított módosítás nélküli
6. Eszközvezérlő tesztelés, aláírás tesztelt, aláírt tesztelt, aláírt
7. Beágyazott verzió Van (ESXi) Nincs

A processzor- és memória-használattal folytatjuk

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

  1. Zoltan says:

    Korrekt, jó cikk, kíváncsian várom a többi részét!:)
     
    Pár megjegyzés:
    – "Az ESXi a kis- és középvállalatokat célozza": Amennyire én tudom, az ESXi nem feltétlen SMB-nek szánt, a nagyvállalatoknak szánt Virtual Infrastructure-ban is lehet azt használni. Nem vagyok VMware-es, szóval nem tudom mi a konkrét tervük vele jelenleg, de pl. itt meg máshol is olvastam, hogy előbb-utóbb az ESX helyett át akarnak térni szépen az ESXi-re. Te tudsz valamit ezzel kapcsolatban? Az ESXi csak akkor kifejezettem SMB, ha a hétfőtől elérhető ingyenes verzióját választod, amihez nincs VirtualCenter meg support. A Hyper-V-nél is a nagyvállalati szegmenst gondolom a Hyper-V + System Center termékek együtt célozzák meg. Az összehasonlítás valahol tényleg ESX vs. ESXi vs. Hyper-V vs. Xen vs. Linux KVM szinten jogos, ez az alap réteg, ami virtuális gépeket tud futtatni. A következő réteg összehasonlítása meg a Virtual Infrastructure vs. System Center Virtual Machine Manager vs. …
    – A monolitikus hypervisornak szerintem még előnye, hogy jelenleg ezzel lehet megvalósítani a kis méretű megoldásokat. Xen esetén nem tudom mennyire lehet összenyomni a dom0-ban lévő Linuxot, Hyper-V esetén ez ugye Server Core-ral 2 GB. És azért abban valahol igaza van a VMware-nek, hogy a 32 MB kódban biztos kevesebbet kell patchelni majd, mint 2 GB-ban. Lásd ezt az eléggé flame blogbejegyzést (Obama Forces Hyper-V to Reboot). Szóval tényleg nehéz megmondani, hogy melyik megoldás a jobb, ha lehet egyáltalán ilyet választani (ugyanúgy, mint az OS-eknél a monolitikus-mikrokernel örök vita)
    – A Beágyazott verziónál a Hyper-V miért zöld?
    – a "Microsoft Hyper-V Server" termékről van már valami publikus információ?:) Milyen lesz az architektúrája, miben különbözik a sima Windows Server + Hyper-V szereptől? Mi fut majd a gazda partícióban?

  2. Tamas says:

    – Az ESXi tervekről nemtudok
    – a 955020 szerintem nem kell a server core változaton, de ezt le kell majd ellenőriznem (obama hyper-v cikk)
    – A színezési sajtóhibákat javítottam
    – A Hyper-V serverről még nem lehet semmit tudni.
     
    Az, hogy melyik termék melyik piaci szegmensre hogyan való, az megérne egy külön cikket. Lehet, hogy egyszer meg is írom.
     

  3. kkiss says:

    Szia Tamás !Egy kis észrevétel. Az ESXi – már cikked írásakor sem volt – terv :). Létezett, működött. Sőt, oktatták is már májusban, több helyen, a VCP vizsga anyaga tartalmazott is belőle elegendő számú kérdést .Más:A VMware ESXi / Vi3 nem csak kis vagy középvállalatoknak ajánlott / alkalmas megoldás. Enterprise szinten is jól alkalmazható; azonban mindenképpen VC kell hozzá. Ami a Console-t illeti: a VI3 -ban alapból nincs Console, illetve egy hibakeresésre alkalmas módja van, ami azonban igazából nem konzol.

  4. Tamas says:

    A "terv" szó eredetileg Mizo hozzászólásában szerepelt "Nem vagyok VMware-es, szóval nem tudom mi a konkrét tervük vele jelenleg, de pl. itt meg máshol is olvastam…" Erre írtam, hogy én sem tudom, mi a tervük az ESXi-vel. Egyébként maga az ESXi persze hogy nem terv.
    Igen, nem csak kis- és középvállalatoknak ajánlott, ez is igaz. Ezzel együtt most nem elemezzük. Majd megjelenik a "Microsoft Hyper-V Server" – akkor elővesszük mind a kettőt. Persze az is lehet, hogy szentelek majd egy egész cikkes összahasonlítást az ESXi és a Hyper-V között, de csak ez után a cikksorozat után.

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: