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

Processzor-használat
Nem titkolom, hogy miközben a cikket fogalmazom, jómagam is számos területen utána nézek bizonyos adatoknak információknak. Kezdetben azt hittem, hogy a processzor-használatról majdnem mindent el tudok mondani legfeljebb három bekezdésben, de aztán rájöttem, hogy a téma ennél sokkal szélesebb. Mindenképp beszélnünk kell a fizikai és virtuális gépekhez tartozó minimumok/maximumok mellett a követelményekről (kompatibilitásról), az erőforrás-kiosztásról és a processzorok virtualizálásáról (maszkolásról) is.

A gazdagép- minimumok és maximumok felsorolása hálás feladat és persze egyszerű is. Számokról van szó, azok meg magukért beszélnek. Mégis azt javaslom, hogy a legkevésbé itt ragadjon le az olvasó. A szóban forgó két rendszer ugyanis – már ami a gazdagépeket illeti – a ma egyáltalán elérhető legnagyobb x86/x64 rendszerek mindegyikén képes működni. A legnagyobb rendszerek pedig sokkal-sokkal nagyobbak, mint az átlagos beszerzéskor szóba kerülők. Ráadásul – ahogy kivettem – mindkét cég hasonló módon határozza meg a támogatott konfigurációt. Támogatott az, amely nagyságú rendszeren tesztelték a szoftvert. Ez egyúttal azt jelenti, hogy mindkét gyártó esetén lehetséges a megadottnál nagyobb processzorszámon is futtatni az adott hypervisort, és csak idő kérdése, hogy az ilyen rendszerek egyszer csak a támogatott kategóriába essenek. Konkrétan tudom, hogy a Microsoft azért 16 logikai processzort támogat a gazdagép oldalon, mert ekkora gépeken tesztelték a hyper-v-t, de már az RTM kibocsátása körül elkezdték a 32 core-os rendszer-teszteket. Hasonló a helyzet az VMware-nél. Az ESX 3.5 még legfeljebb 128 virtuális CPU-t támogatott, ez az update 2 megjelenésével 192-re nőtt és a VMware a 192-es támogatást utólag megadta az update 1-es  verzióra is. Nem történt más, mint a tesztelő csapat végre nagyobb rendszerekhez jutott, vagy más módon utolérte önmagát. És tessék csak végiggondolni! 16 core az azt jelenti, hogy 4 quad-core-os processzorral szerelt gép. A Microsoft előszeretettel használ ilyen gépeket pl. TCO számításkor, sok egyéb mellett abból a megfontolásból is, hogy itt hangsúlyozottan drágul az VMware megoldás. No, de kérem, érvel a VMware, hol vannak még ezek a gépek? Manapság még méregdrágák, kell egy-két év, mire tényleg átlagosnak mondható egy ilyen konfiguráció. És valóban, ebben a VMware-nek igaza van – viszont ez az érvelés a maximumok körüli vitát is egyszer s mindenkorra agyoncsapja. Szóval a hostokra vonatkozó processzor maximumokkal – bár megadom a számokat – néhány ritka kivételtől eltekintve nemigen kell törődni.

Sokkal érdekesebb a kompatibilitás kérdése. A VMware ESX mindenevő. Lényegében bármilyen x86 (32 bit) vagy x64 (64 bit) processzoron elfut. Nem csoda: az ESX alapvetően bináris traszlációval és ring deprivilege módszerrel dolgozik, azt bármilyen processzoron el lehet végezni. (A fenti fogalmakat tisztáztuk már a bevezető cikkben. Van olyan funkciója a VMware ESX-nek, amely speciális CPU képességhez kötött, a Vmotion EVC, de erről majd később.)
Az ESX-szel szemben a Hyper-V kényes: csak olyan processzorokon fut, amelyek támogatják a hardveres virtualizációt, továbbá a Data Execution Prevention (DEP; Az AMD-s megfelelője a No eXecute: NX) fukciót. Ezek nélkül fel sem települ. "Cserébe" a Hyper-V sohasem használ sem bináris transzlációt, sem pedig ring deprivilege-et. Mi következik mindebből? A Hyper-V a 2006 előtt kiadott processzorokon valószínűleg nem fut. Nem lehet azzal kezdeni, hogy majd egy kiöregedett géppel elkezdünk kísérletezni. Ha valaki érti, hogyan működik a Hyper-V, akkor most már tudja miért nem. (Mint ahogy egy kimustrált masinára valószínűleg nem lehet feltenni egy ESXi-t sem. A processzorral nem lenne gond, de a driverek hiányoznának a hypervisorból. Aki tudja, milyen az ESXi architektúrja, az azt is tudja, miért.)
Szerencsére az Intel-VT/AMD-V már legalább egy éve minden szerverekbe szánt processzorban benne van, vagyis olyan nagy baj nincs. Ráadásul a virtualizációs projektek szinte kivétel nélkül új hardveren konszolidálnak, a fenti követelmények igen könnyen megugorhatóak. Ha viszont valaki mégis a régi rendszerével szeretne elindulni, akkor kétséges lehet a Hyper-V üzembe helyezése.

CPU erőforrás allokáció. Nem találtam különösebb különbséget a processzor-kapacitás virtuális gépek közötti elosztása között. A VMware a processzor- és a memóra virtuális gépekhez történő súlyozott allokálását egy panelen oldja meg, a Hyper-V – lévén, hogy memória túlfoglalásra nem képes – ugyanezt a funkciót a memóra, mint erőforrás kihagyásával végzi el. Mindkét rendszer tud lefoglalást (reserve) és limitet állítani, továbbá mindkettő képes relatív súlyt adni egy virtuális gépnek (az ESX esetén ezt részvénynek nevezik angolul)

image image 
              VMware ESX CPU erőforrás kezelés                                           Hyper-V CPU erőforrás kezelés

Tegyük azt is rögtön hozzá, hogy ezt a képességre jó, ha a rendszerüzemeltetők 10%-a használja. Maga a VMware "Resource Management Guide"-ja is azt mondja, hogy a fenti beállításoknak csak a Resource Pool-ok bevezetése esetén van értelme, arról pedig majd később beszélünk. Most a processzor-használat összevetésekor legyen annyi elég, hogy mindkét rendszer ugyanazokkal az alapokkal rendelkezik.

CPU affinitás kezelése. A CPU affinitás azt jelenti, hogy egy virtuális gépet hozzáköthetünk egy vagy több adott fizikai processzormaghoz. A VMware ESX rendelkezik ilyen képességgel, habár a "Resource Management Guide" megint csak őszintén beszél a témáról:

image

Nos, a Hyper-V nem tartalmaz CPU affinitás menedzsmentet. Nem azért, mintha olyan nehéz lenne implementálni a funkciót (elvégre az SQL szerver már évek óta tudja ezt), hanem egyszerűen azért, mert olyan minimális rá az igény, hogy a prioritási listán ez a képesség nem tudta beküzdeni magát az első körbe.

CPU maszkolás. A CPU maszkolás egy speciális módszer, amelynek a segítségével a hypervisor elrejti a vendéggépek elől a processzor bizonyos képességeit (utasításkészleteit)
Izgalmas olvasmány az ESX Resource Management Guide, márcsak azért is, mert – nagyon helyesen – a szerzők nem feledkeznek meg időről időre definíciókat is megadni. Íme egy példa: mi a különbség az emuláció és a virtualizáció között.

"To understand CPU related issues, the difference between emulation and virtualization. With emulation, all operations are executed in software by an emulator. A software emulator allows programs to run on a computer system other than the one for which they were originally written. The emulator does this by emulating, or reproducing, the original computer’s behavior by accepting the same data or inputs and achieving the same results. Emulation provides portability and is often used to run software designed for one platform across several different platforms. With virtualization, the underlying physical resources are used whenever possible and the virtualization layer executes instructions only as needed to make the virtual machines operate as if they were running directly on a physical machine. Virtualization emphasizes performance and runs directly on the processor whenever possible."

Példákat nem sorolnak, de ha azt mondom "Commodore 64 PC-n", akkor mindenki tudja, hogy ez emuláció, hiszen a Commodore annak idején nem x86-os processzorarchitektúrán futott.
Ha a processzort nem emuláljuk a virtuális gépek számára, hanem csak virtualizáljuk, akkor tulajdonképpen nem is rejtjük el a processzort típusát és képességeit? – A válasz alapesetben mindkét gyártónál az, hogy "igen, nem rejtjük el a processzor képességeit". Ha a válasz az, hogy nem rejtjük el a processzort, akkor mi értelme van a CPU maszkolásnak, amely mégiscsak egyfajta CPU képesség-eltitkolás. Nos, van értelme.

Az x86-os architektúra azt jelenti, hogy van egy processzor-család (ha az AMD-t is számítjuk, akkor mondhatjuk, hogy rokonság), amely legalább egy közös utasításkészlettel rendelkezik, és jó közelítéssel a rokonság minden tagja futattja az architektúrára írt szoftvereket és operációs rendszerek. Az ördög a részletekben – a fentiekkel szóvel a "jó közelítés"-ben – lakozik. A kiadott szoftverek a kiadásuk idején már elkészült processzorokon tesztelték, a később megjelenőkön nem. Így fordulhatott elő, hogy a Windows NT 4 (és biztosan más rendszerek is) a legújabb processzorokon egy szoftverhiba (bug) miatt elkékhaláloznak. A hiba akkor jelentkezik, amikor az operciós rendszer lekérdezi a processzort pontosan azonosító CPUID-t és túl magas értéket kap vissza. A megoldás a CPU maszkolás, amely a Hyper-V esetén egyetlen jelölőnégyzetbe sűrűsödik: tessék még egyszer megnézni a CPU erőforrás-allokáció résznél a Hyper-V képet! A "Limit Processor Functionality" segít a taglalt probléma megoldásában.

A VMware ennél egy fokkal továbbment, de egészen más okból kifolyólag. A processzorok funkcionalitási különbségei problémát jelentenek akkor is, amikor egy virtuális gépet egyik gazdarendszerről a másikra szeretnénk átmozgatni (VMotion), konkrétan eléggé szigorúan "hasonlítania kell" a processzoroknak egymásra. Az azonos gyártó a minimum, de pl. meg kell egyezniük az SSE utasításkészletnek is. A Vmware a Dell-el karöltve kiadott egy VMotion kompatibilitási mátrixot, amely jól jellemzi a helyzetet. A CPU maszkolás nem más, mint az a módszer, amellyel "azonos szintre" hozhatók a processzorok, vagyis működésre lehet bírni a VMotion-t.

imageA VMWare  gyártott grafikus felületet és ha nem is triviális, de értő kezekben épkézláb módon lehet maszkot gyártani. Muszáj volt ezt meglépni, mert a CPU maszk hiánya működésképtelenné tenné a VMotion-t, attól pedig megállna a DRS.

Jól látható, hogy a helyzet tarthatatlan, ezt az Intel és az AMD is érzékelte. Mindkét cég elkezdte a CPU maszkolás beépítését a processzorokba az Intel Flexmigration az AMD pedig "Extended Migration" fantázia név alatt. A VMware legújabb ESX 3.5 U2 verziójának az egyik újdonsága éppen ennek a technológiának a támogatása, ezáltal egy megbízhatóbb VMotion biztosítása (Enhanced VMotion Compatibility EVC)

Az EVC-nek persze jelenleg eléggé szigorúak a feltételei és csupán négy processzor támogatja, de egy év múlva már jobb lesz a helyzet.

A Hyper-V a fenti speciális esetet kivéve nem tartalmaz egyéb CPU maszkolási technológiát, amit a Quick Migration-nél le is csapódik azonnal: jelen állapot szerint csak azonos processzor-családból lehet virtuális gépeket mozgató fürtöt építeni.

Összefoglalás a processzorok használatáról:

  1. A gazdagépek maximumai mindkét rendszer esetén bőségesen elegendőek, a rendszerek jól skálázhatók
  2. Az eltérő architektúra miatt eltérőek a processzor követelmények. A régebbi processzorok többnyire csak az ESX-et futattják, hardveres virtualizációs támogatás hiányában a Hyper-V-t nem.
  3. A CPU erőforrás-allokációban nincs különbség a két megoldás között
  4. A rétegigényt kielégítő CPU affinitás kezeléssel csak az ESX rendelkezik
  5. A CPU maszkolás vonatkozásában az ESX versenyelőnye egyértelmű, bár a Hyper-V számára a téma nem teljesen ismeretlen.
No.

Tulajdonság

VMware ESX 3.5

Microsoft Hyper-v

1.

Maximális (támogatott) processzormag a fizikai gépben

32 (*)

16 (*)

2.

Maximális (támogatott) logikai processzorok száma

192

128 (*)

3.

(Támogatott) virtuális processzor processzormagonként

8 (VDI esetén 11) (*)

8 (*)

4.

Maximális (támogatott) virtuális gép gazdagépenként

170

128

5.

Maximális virtuális processzor virtuális gépenként

4 (**)

4 (**)

6.

Hardveres virtualizáció támogatás

Nem követelmény

Követelmény

7.

DEP/NX processzor-funkció

Nem követelmény

Követelmény

8.

CPU erőforrás allokáció (Relatív súly/foglalás/limit)

Igen

Igen

9.

CPU affinitás (virtuális gép CPU-hoz kötése)

Van (Nem javasolt)

Nincs

10.

CPU maszkolás

Van

Van (csak egy speciális esetre)

* – Nem fizikai korlát
** – Függ a virtuális gép operációs rendszerétől.

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

  1. fearme says:

    "Nem azért, mintha olyan nehéz lenne implementálni a funkxiót." Pedig funkxiót biztos nehéz :-)

  2. Tamas says:

    Köszi, javítottam.

  3. istvan says:

    Gratulálok a cikk sorozathoz, nagyon hasznosnak találom. Viszont, szerintem az összehasonlító táblázatban a VMWare-es 9 és 10 tulajdonságra adott válasz fel lett cserélve?! Legalábbis a cikkből számomra az jött le, hogy CPU affinitás nem javasolt.Üdv.:István

  4. Tamas says:

    Igen, igazad van, ez egy sajtóhiba. Javítom.

  5. Tamas says:

    Valóban. Ezzel együtt vedd figyelembe, hogy mind az ESX, mind pedig a Hyper-V egy szerver virtualizációs megoldás. Az a lista, amit beidéztél, desktop processzorok összehasonlítása. Úgy lett volna helyes a megfogalmazás, hogy "Szerencsére az Intel-VT/AMD-V már legalább egy éve minden szerverekben szánt processzorban benne van, vagyis olyan nagy baj nincs". Javítottam is.

  6. Gabor says:

    "A régebbi processzorok többnyire csak az ESX-et futattják, hardveres virtualizációs támogatás hiányában a Hyper-V-t nem."Jól tudom, hogy 64 bites processzorral, de hardveres virtualizációs támogatás nélkül az ESX sem képes 64 bites guest futtatására?

  7. Tamas says:

    Bizony-bizony. Köszönöm, hogy felhívtad rá a figyelmemet! Idemásoltam a IESX Installation Guide megfelelő részét."There are specific hardware requirements for 64‐bit guest operating system support. For AMD Opteron‐based systems, the processors must be Opteron Rev E and later. For Intel Xeon‐based systems, the processors must include support for Intel Virtualization Technology (VT). Many servers that include CPUs with VT support might ship with VT disabled by default, and VT must be enabled manually. If your CPUs support VT but you do not see this option in the BIOS, contact your vendor to request a BIOS version that lets you enable VT support."

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: