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

Ma a memóriakezelést vesszük górcső alá. Ha valaki VMware blogokat bújik, akkor az ESX memória-kezelését az egyik legfontosabb versenyelőnyként ismeri meg. A helyzet szerintem ennél összetettebb.

Memóriakezelés – ami közös
Mindkét rendszer lefoglalja és a virtuális gépek számára izolálja a szükséges mennyiségű memóriát. A gazdagépek skálázhatósága azonban jelentősen eltér. A VMware legfeljebb 256 GB fizikai memóriát kezel, a Hyper-V viszont akár 1 TB-ot. (Ráadásul ez sem szigorú korlát, mert a Windows Server 2008 maximális támogatott memóriamérete 2 TB) Ezek ugyan csillagászati számok, de az igazán nagy szervezetek hamar rájönnek, hogy a virtualizáció esetén a legjobb megoldás a lehető legtöbb memória bepakolása egyetlen gépbe. Úgy tűnik, hogy az óriásgép építésében – köszönhetően a 64 bites architektúrának – a Hyper-V jelenleg jobb.
A virtuális gépek által használható memória mértéke azonos, 64 GB és bár különbözőképp fogalmaznak és számolnak, a Service Console (Hyper-V: szülő partíció) memória igénye is lényegében azonos. A virtuális gépek ezen felül többletmemóriát igényelnek. A VMware ESX egy táblázatban adja meg, a Hyper-V-nél pedig egy képlettel számolható, mekkora a tényleges többletmemóra igény. A Hyper-V képlete: 32 MB a virtuális gép igénye 1 GB VM memória alatt, majd minden további GB esetén +8 MB memória. Ha a cikk végén található táblázatot tekintjük, akkor az "Hyper-V overhead" oszlop első cellájának képlete: 32+INT(ABS(B2-1024)/1024)*8. Gépenként ez a többletmemória igény a Hyper-V esetén rendre 40-80%-kal kevesebb, mint az ESX esetén. Teljes környezetre számolva (3 példát is megadtam lent) ez 6-7%-kal kisebb memóriaigényt jelent – feltéve, hogy az ESX kiszolgáló nem használ memória túlfoglalást. Csakhogy általában használ…
Végül említsük meg, hogy közös mindkét megoldás esetén a NUMA architektúra támogatása, habár az ESX, éppúgy mint a processzorok esetén, implemenált node memória affinitást, míg ezt a Hyper-V nem teszi. Tekintve, hogy a képesség csak rétegigényt elégít ki, kétlem, hogy döntő technológiai érvként szerepel majd bármilyen kiértékelés során.

Memóriakezelés – különbségek
Az ESX rendszerek rendelkeznek egy olyan tulajdonsággal, amely lehetővé teszi, hogy a fizikailag létező memóriánál több memóriát foglaljunk le a virtuális gépek számára. Miből táplálkozhat a többletmemóra? Két forrásból. Az első forrás a virtuális gépek által nem használt memória-rész. Ha egy gépnek definiálunk 1 GB memóriát, de ténylegesen csak 650 MB-ot használ, akkor 350 MB-tal gazdálkodhatunk és odaadhatjuk olyan virtuális gépnek, amelynek szüksége van rá. Ha sok ilyen gépünk van, akkor jelentős mennyiségű újrahasznosítható memóriával gazdálkodhatunk. A másik forrás a virtuális gépek egyformaságából adódhat. Tegyük fel, hogy van 20 virtuális gépünk, amely mind Windows XP SP3-at futtat. Ezeknek a gépeknek a memória-térképe meglehetősen hasonló, azonos állományokat, dll-eket használnak. Az azonos lapok száma 5-30% között változhat (Forrás: VMWare Resource Management Guide), vagyis gépenként ennyivel kevebb memóriára lehet szükség. Az azonos (duplikált) memória lapok megszüntetését "memory sharing"-nek nevezzük.
És mindez még semmi. A memória túlfoglalás, a erőforrás csoportok (resource pool), és a később ismertetendő DRS és VMotion képességek együtt azt eredeményezhetik, hogy a gazdagépek "összenyílnak", vagyis processzor- és memóriaerőforrásaik egyben allokálhatók az összes virtuális gép között, azzal a megkötéssel, hogy egy virtuális gép egyszerre persze csak egy gazdagép erőforrásait használhatja. Ezzel elválik a fizikai erőforrások és a logikai erőforrások allokációja – íme az IT üzemeltetés paradigmaváltása, amelyet a virtualizáció hozott el.

Memória-túlfoglalás – az érem másik oldala
Persze minden éremnek két oldala van. A memória túlfoglalás elővigyázatlanul használva veszélyes művelet lehet. Ha nincs ESX fürtünk, csupán egyetlen gazdagépünk, vagy több gazdagép közös tároló nélkül, akkor előfordulhat, hogy a virtuális gépek működés közbeni memória-igény növekedése esetén egy vagy több VM is leállhat – nincs ugyanis honnan újabb memóriát elővenni. Alternatívaként használhatja ugyan a gazdagép a saját lapozó fájlját, de ez MINDEN virtuális gép válaszidejét DRASZTIKUSAN csökkentené. A VMware Performance Tuning Best Practices for ESX Server 3 így fogalmaz:

"Avoid high memory overcomittment. Make sure the host has more memory than the total amount of memory that will be used by ESX plus the sum of the working set sizes that will be used by all the virtual machines. Carefully select the amount of virtual memory you allocate to your virtual machines to allow enough memory to hold the working set of applications you will run in the virtual machine."

Meg kell találni a túlfoglalás optimális mértékét. Ha túl kicsi, akkor felesleges erőforrásokat hagyunk a virtuális gépeknél, ha túl nagy, akkor váratlan teljesítmény-csökkenésekkel nézhetünk szembe. Márpedig az "optimális" érték mindig is az adott virtuális gépektől és azok memória-használati szokásaiktól függ, vagyis az optimalizáció a rendszergazda feladata. Vagy esetleg a menedzsment eszközöké.
Száz szónak is egy a vége: a memória-túlfoglalásba igazából csak akkor érdemes vágni, ha a hypervisorunkat gazdagon körbebástyázzuk felügyelő, monitorozó megoldásokkal, valamint több, fürtbe kötött ESX gazdagéppel rendelkezünk. Ez persze nem techológiai, inkább üzemeltetési követelmény.

Egy VM költsége
A VMware az ESX szerver memória-kezelési képességei segítségével olyan számításokat publikált, amelyek alapján az egy virtuális gépre eső beszerzési költségek vonatkozásában (természetesen) az ESX megoldást mutatta ki jobbnak. A számítás logikai menete a következő:

  1. Azonos hardver konfiguráció az ESX-nél és a konkurrenciánál – így később a HW költségekkel egyszerűsíteni lehet
  2. Azonos virtuális OS licencelés – szintén azonos költségek (Tipikusan Windows Datacenter Edition – mert akkor a virtuális gépek száma korlátlan.)
  3. ESX Virtual Infrastructure az egyik oldalon – Windows Server 2008 DataCenter + System Center Suite a másik oldalon. Az ESX itt drágább.
  4. Az ESX a memória-túlfoglalással sokkal több virtuális gépet tud egy gazdagépen futtatni. Az összes költség osztva a virtuális gépek számával kiadja az egy VM-re jutó költségeket.

A vita néhány blogbejegyzése:

Érdemes elolvasni a megjegyzéseket is. A vitának a végkövetkeztetése, hogy azokban az esetekben, amikor a memória bővítésére van mód, az egy VM-re eső költség a Microsoftnál kedvezőbb. Amikor a HW bővítésére nincs mód, akkor az ESX olcsóbb. A számítások azonban minden esetben függnek a memória-túlfoglalás lehetséges arányától. Az pedig, láthattuk, egyedileg változó.

Ahol a memória-túlfoglalás igazán hasznos
Személyes véleményem, hogy bár a memória-túlfoglalás nem haszontalan képesség, éles üzemű kiszolgálóknál kisebb az értéke. Ahol viszont nagyon hasznos lehet, az a teszkörnyezet és a VDI. A saját demóimat egy 4 GB memóriával felszerelt notebookon tartom. Miközben néhány hónappal ezelőttig nem is volt kapható ennél több memóriával szerelt hordozható gép, egy System Center Operations Manager 2007 alsóhangon is képes elvinni 2 GB-ot, az Exchange 2007 is bőven 1 GB felett fogyaszt. Memória túlfoglalás nélkül állandóan le kell kapcsolni és újra kell konfigurálni bemutatótól függően az egyes gépek memóriáját. Túlfoglalással (és súlyozással) ez automatikusan menne működés közben.
A desktop operációs rendszerek virtualizálásával felépülő infrastruktúra (Virtual Desktop Infrastructure = VDI) szintén haszonélvezője lehet a technológiának. 100 azonos Windows XP, egy-két tucat pihenő gép esetén valóban érdemes túlfoglalni a memóriát.

AMD Rapid Virtualization Indexing (korábban: Nested Page Table)
Végezetül a memóriakezelés egy új – hardveresen támogatott lehetőségéről is érdemes szólni. A virtuális gépekben futó operációs rendszerek értelem szerűen a memóriát ugyaúgy kezelik, mintha nem virtuális környezetben működnének. A futó processzek ezért egy virtuális-virtuális címteret látnak (kék lapocskák), amelyet a vendég operációs rendszer fordít le VM-fizikai címre (szürke lapocskák). Ez még mindig nem valódi fizikai cím, de ez persze a vendég OS nem tudja. A gazdagép hypervisora (Hyper-V esetén a Virtual Stack Memory Manager) újabb fordítást végez, most már a valódi fizikai memória-címtérre (zöld lapocskák). A probléma a kettős könyvelésből ered, mert az igen csak CPU intenzív művelet.
Hogy ez ne így legyen a jövőben mind az AMD, mind pedig az Intel fejlesztésekbe kezdett. Az Intel a maga megoldását "Extended Page Table"-nek hívja, de még nem készült el vele. Az AMD lényegében ugyanezt Rapid Virtualization Indexing (RVI)-nek hívja, és már van a piacon ezt támogató terméke. A VMware ESX, orrhosszal Hyper-V előtt, támogatja az RVI-t. A Microsoft vélhetőleg csak a következő verzióban dolgozza le ezt a hátrányt, remélhetőleg az Intel támogatással egyetemben.

Összefoglalás

  1. A fizikai gépek memóriája a Hyper-V-nél jobban skálázható
  2. A többletmemória igény a Hyper-V esetén némileg kisebb
  3. A memória túlfoglalásra csak az ESX képes, a Hyper-V nem
  4. Az ESX nyújtotta "szoftveres memória" drága, de ha nincs mód a bővítésre, akkor jól jön.
  5. Az ESX támogatja a hatékonyság-javító EPT / NPT processzor-gyártói megoldásokat
No.

Tulajdonság

VMware ESX 3.5

Microsoft Hyper-v

1.

Maximális (támogatott) memória a fizikai gépben

256 GB

1 TB

2.

Maximális (támogatott) a virtuális gépekben

64GB

64 GB

3.

Service Console + hypervisor / Szülő partíció + hypervisor memória igénye

Service Console kb. 272 MB
Hypervisor: 50 MB + drivers

kb. 512 MB

4.

Virtuális gépekhez szükséges többletmemória

változó (*)

változó (*) – kevesebb

3.

Memória túlfoglalás (memory overcommit)

Van

Nincs

4.

Dinamikus memória túlfoglalás

Van

Nincs

5.

Erőforrás-allokáció integráció

Van

Nincs

6.

NUMA támogatás

Van

Van

7.

NUMA node memória affinitás

Van

Nincs

8.

AMD NPT támogatás

Van

Nincs

(*) – Virtuális gépekhez szükséges többletmemória. A számítások forrása:
VMware – Resource Management Guide (143. oldal)
Hyper-V – Performance Tuning Guidelines for Windows Server 2008

image_thumb[3]

Előzmények:

  1. A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
  2. A VMware ESX 3.5 és a Hyper-V összehasonlítása – 1. kör (történet, architektúra)
  3. A VMware ESX 3.5 és a Hyper-V összehasonlítása – 2. kör (Processzor)

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: