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

Amikor a cikk témáját (hálózat és tárolórendszerek) a szakiradalom olvasásával kezdtem körbejárni, éreztem, itt baj lesz. Az I/O alrendszerek kezelésében hatalmas architektúrális különbségek vannak a két hypervisor között, a másik rendszer "szerkezetének" kikezdése kézenfekvő. A helyzetet tovább nehezíti, hogy az I/O virtualizáció hardveres támogatása inkább még sehogy sem áll, vagyis mindenkinek "szoftverből" kell megoldania mindent. Harmadrészt a I/O alrendszer általában a leglassabb komponense a számítógépnek, ezért a "teljesítmény" kényszere minden gyártó számára adott. Száz szónak is egy a vége, mielőtt bármilyen táblázatot fabrikálnék, össze kell hasonlítanunk a szoftverek felépítését – enélkül nem megy.

Az 1. körben elemeztük már egyszer a hypervisorok felépítését, de most mégis vissza kell térnünk az eszközmeghajtók témakörhöz. Tisztáztuk, hogy az ESX a hypervisorba fordította a hardver fizikai eszközeihez szükséges meghajtókat. Ezt a módszert a szakirodalom "direkt driver modell"-ként ismeri. Ezzel szemben a mikrokerneles felépítést képviselő Hyper-V eszközmeghajtói nem a hypervisor privilégiumszintjén helyezkednek el, hanem a szülő partíciókban. Ez az indirekt driver modell.

Mindkét megoldásnak megvannak a maga előnyei és hátrányai. Az IO feladatok szempontjából a direkt modell egyszerűbb, mivel a eszközkezelők behívásához nincs szükség privilégium-szint váltásra, sőt itt zajlik a virtuális eszközök emulációja is, ami előnyösebb, mintha magasabb, pl. r0 vagy r3 szintet használnánk. Az eszközkezelők számát ugyanakkor korlátozni kell, és a kódot módosítani is, hogy a hypervisor szintjén futhassanak. Az emulációt gyosítja, ha a virtuális gépben VMware Tools üzemel. Ez a komponens ugyanis  – sok más mellett – figyeli az operációs rendszer kernelét, és "értesíti" a hypervisor-t, mikor van szükség virtualizáció helyett tényleges emulációra.

 

 

imageA mikrokernel felépítésnél közönséges eszközmeghajtók használhatók, így egy szélesebb hardverbázis szolgálhat a rendszer alapjául. A rugalmasságnak azonban ára van. Az emulációt nem a hypervisor végzi, hanem Virtual Machine Worker Process, amely egy user módban, tehát ring3-ban futó, virtuális gépenként létrejövő programfolyam. Az emuláció ebben a formájában "drága": a hypervisornak kell észrevennie, hogy a virtuális gépben az operációs rendszer egy emulált eszközhöz szeretne nyúlni, majd ezt a szülő partíció megfelelő worker processzéhez kell irányítania, amely azután megint csak privilégiumszint-váltással a Virtual Service Provideren keresztül éri el a fizikai eszközt. Nem is kell ezt túragozni, a folyamat lassú. (Egyébként, hogy mindez mennyire az architektúrától függ, jól példázza, hogy a Xen szinte teljesen hasonló módon működik. Ott az emulációt a Qemu egy módosított változata végzi, és a folyamat kísértetiesen hasonlít az itt leírtakhoz. Akárcsak az ezután következő megoldások.)

 

 

 

Nem is sok helye lenne a nap alatt a Hyper-V-nek, ha nem lenne az emuláció mellett egy másik IO megoldás is, imagea szintetikus eszközöké. Erről írtam már korábban, most csak az IO szempontok szerint nézzük meg őket. A szintetikus eszközök nemcsak hogy virtuálisak, de a valóságban sosemvolt eszközök. És ez jól is van így. Arra hivatottak, hogy virtuális környezetben éljenek. Ha egy virtuáis gépben az operációs rendszer rendelkezik a szükséges szintetikus eszközzel, akkor a Hyper-V alatt ezen eszköz számára felépül egy csatorna a szülő partíció felé(*). Ez a VMBus. A csatorna egyik végén, a virtuális gépben egy VSC (Virtual Service Consumer), a másik végén, a szülőpartícióban pedig a Virtual Service Provider található. Az adatforgalom a hypervisor kihagyásával, közvetlenül, privilégiumszint-váltás nélkül zajlik. Értelem szerűen nincs szükség a Worker Processzre és emulációra sem. Eredmény? Gyors, nagyon gyors adatátvidel.
A szintetikus eszközöket a virtuális gép létrehozásakor definiáljuk, de azok mindaddig elérhetetlenek, amig a Hyper-V virtuális gépbe való részét, az "Integrated Components" csomagot nem telepítjük. Telepítés után az operációs rendszer indulásakor betöltődnek a megfelelő eszközmeghajtók, felépül a VMBus, aztán hajrá. És addig? Addig, vagyis a szintetikus eszközmeghajtók betöltődéséig csak emulált eszközök állnak rendelkezésre. Emulált, tehát lassú.

A szintetikus eszközök létének van egy furcsa mellékhatása. Mivel mindegyik "puszta szoftver", és mivel mindegyik ugyanahhoz a csatornához csatlakozik, a teljesítményük szinte teljesen egyforma. Vegyük példának az IDE eszközmeghajtót. Köztudott, hogy Virtual Server 2005 alatt jelentős különbség volt az (emulált) IDE és az (emulált) SCSI adapterek sebessége között – a legjobb gyakorlat szerint az emulált SCSI-ről kellett indítani az operációs rendszert. Hyper-V alatt nincs emulált SCSI, csak szintetikus, ergo sem telepíteni sem elindítani nem lehet operációs rendszer (virtuális) SCSI adapteren lógó merevlemezről. Akkor marad az IDE. Csakhogy induláskor még nincs szintetikus eszköz, marad az emulált IDE. Lassú lesz? Nem. A boot folyamat során az IDE vezérlő automatikusan szintetikusra vált. Ettől a pillanattól kezdve lényegtelen, hogy a virtuális adapter nem SCSI, sebesség szempontjából a kettő egyforma. Felesleges riadalom (felesleges riogatás!), ha valaki az IDE csatolóra panaszkodik. Vagy egyszerűen a Hyper-V nem ismerete.

Egyébként az IO rendszerre egy másik tény is mellékhatással bír, nevezetesen a szülőpartíció képességei. Az ESX-nél a Consol OS szerepe pontosan az, ami a neve. Egy menedzsment felület a hypervisor telepítésére, konfigurálására és karbantartására. Maga a hypervisor mindig változatlan – hacsak a szoftverfrissítések nem érintik. A szülő partició ezzel szemben gyökeresen más. Attól függően, hogy milyen eszközkezelőket tartalmaz változhat a tudása.

Látható, hogy a Hyper-V versenyképessége a szintetikus eszközökön áll vagy bukik. Ha egy operációs rendszerhez van/lesz IC, akkor az gyors IO alrendszerrel büszkélkedhet. Ha nincs IC, akkor az operációs rendszer csak megtűrt másodhegedűs maradhat. Nem véletlen a Microsoft-Xen és a Microsoft-Novell együttműködés. A végeredmény egy olyan IC, amely Linux alatt is működik. Solaris alatt is futnak majd szintetikus eszközkezelők, ha majd a Sun-nal kötött megállapodás beérik. Addig marad az emuláció.

A később következő összehasonlításokat a fentiek fényében kell látni.

(*) – Valójában a VMBus egy virtuális gép, nem pedig egyetlen eszköz számára jön létre. 

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

  1. István says:

    Szia Tamás!
     
    A kérdésem az lenne, hogy végeztetek-e konkrét teljesítmény összehasonlító teszeket a konkurens vmware ESX termékével?
    Ha igen, akkor ennek mi volt az eredménye?
     
    Cégünknél most állunk "komoylabb" virtuális technológiai bevezetéseelött, és ezzel kísérletezünk.
    Eddig az ingyenes vmware servert használtuk, és meg voltunk vele elégedve, valamint teszteljük az ESX legujabb verzióját is az összes komponensel. 
    Teljesen azonos hardverre (HP DL380 G5, 10GB RAM, 2x2G Quad Core proci, 2x150G SAS HDD) telepítettük az ESX-et és a HyperV-t, valamint teszt jelleggel az SCVMM 2008-at.
    Azonos guast konfiggal (DC-SQL-Dynamics AX) végeztünk méréseket, és eddig – ha hajszállal is – az ESX jött ki jobban.
     
    Kíváncsi vagoyk a véleményedre.
     
    Üdv,
    István
     

  2. Tamas says:

    Szia István!
     
    A teljesítmény-tesztek elvégzése nem triviális, mert a virtualizáció során előre nem látható módon torlódhatnak memória processzor vagy IO igények.
    Konkrét méréseket természetesen végzett a cég, de ezek nem nyilvánosak, mert nyilvánosságra hozásukat mind a VMware ESX, mind pedig a Windows Server 2008 EULA a gyártó hozzájulásához köti. Van még egyéb mondandóm is, dez az inkább egy külön bejegyzésben.

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: