De release van Hyper-V heeft voor flink wat opschudding gezorgd in de virtualisatiemarkt. Daarom wilden wij wel eens weten hoe de grote aanbieders ten opzichte van elkaar presteren, en hoe ze het doen op gebieden als gebruikersgemak, beheer en migratie. Zowel Microsoft als VMware gingen in op onze uitnodiging, maar de andere twee, Citrix (Xen) en Red Hat (KVM) konden niet meedoen omdat ze bezig zijn met een herziening van hun producten. Wat we dus hebben is een een-tegen-een confrontatie tussen titelhouder ESX en uitdager Hyper-V.

We hebben voor deze test gelet op de prestaties van de hypervisor. Later deze maand nemen we het gebruiksgemak, beheer en migratie onder de loep.

Welke van de twee hypervisors de snelste is, hangt af van een aantal factoren. Zo is het de vraag hoe de VM- guest besturingssystemen zijn verdeeld over de beschikbare CPU's en geheugen van de hosts. Het hangt ook sterk af van allerlei productspecifieke beperkingen.

Dat gezegd hebbende: VMware ESX is de uiteindelijke winnaar van onze prestatiewedstrijd, waar we beperkt werden tot het draaien van zes VM's naast elkaar vanwege de beperkingen van onze server. In de meeste van onze load-testen, multi-CPU VMware hosting en de I/O-prestatietesten van de schijven is het ESX die boven Hyper-V eindigde.

Maar Hyper-V deed het op een paar fronten goed, vooral toen we een een set tooltjes gingen gebruiken om de prestaties op te krikken van de enige Linux-distro die Microsoft ondersteunt, namelijk SUSE Linux van Novell.

Hypervisors zijn ontworpen om serverhardware na te bootsen voor verschillende guest-besturingsystemen. De fysieke CPU's (de kernen) worden naar de guest toe vertaald als virtuele CPU's (vCPU). Dat wil niet zeggen dat een enkele kern ook een enkele vCPU voorstelt; die exacte verhouding hangt van de hypervisor af. In onze test liueten we de hypervisor zelf uitmaken hoeveel vCPU's door de kernen worden aangestuurd.

De OS'en 'zien' de hulpbronnen van de server voor zover de hypervisor dat toelaat. Zo kan een quadcore CPU-systeem worden gepresenteerd als een enkele CPU voor het besturingssysteem. En met die ene CPU moet hij het dan maar doen. Maar vier CPU's kunnen ook worden gevirtualiseerd als acht vCPU's, wat te gebruiken is voor meerdere lichte VM's die niet het uiterste van de processor vragen. Maar ook de schijfomvang, de I/O van het netwerk en zelfs eventuele toegang tot de CD/DVD-speler in de server kunnen allemaal ingesteld worden.

Frustrerend met zowel ESX en Hyper-V is dat het maximum van het aantal kernen dat aan een VM kan worden toegewezen vier is, wat de versie van het OS of het aantal beschikbare kernen ook is. Bovendien moet opgemerkt worden dat als de 32-bits versie van SLES 10 als gast wordt gedraaid, dat Microsoft deze altijd een enkele vCPU toekent.

Deze beperkingen zijn er om twee redenen. Om te beginnen vergt het bijhouden van VM-guests met flinke CPU-eisen ook enorm veel geheugenbeheer en veel ingewikkelde communicatie tussen CPU's. Ten tweede wordt het hosten van VM-guests gezien als een consolidatieslag, en servers die geconsolideerd moeten worden bestaan in de regel uit slechts een enkele CPU.

Dit bepaalde hoe we onze 16-CPU HP DL580G5 testserver konden gebruiken (de volledige methode staat hier beschreven).

Tijdens de testprocedures maakte Microsoft zijn Hyper-V Linux Interface Connector kit (Hyper-V LinuxIC) voor ons beschikbaar, een set drivers die de CPU, het geheugen, schijf en netwerk I/O optimaliseren voor SLES gastsessies. Met de kit zagen we een flinke stijging in de prestaties, maar alleen als er één vCPU per gast beschikbaar werd gesteld. LinuxIC wordt niet ondersteund voor SMP-omgevingen.

De prijs van virtualisatie

Niemand zal beweren dat de 'buzz' rond servervirtualisatie op niets is gebaseerd. Het maakt het mogelijk om meerdere besturingssystemen tegelijk te draaien op dezelfde hardware waar normaalgesproken slechts eentje op gedraaid wordt. En het maakt het een stuk eenvoudiger om een gestandaardiseerd systeemprofiel over een geheel datacentrum uit te rollen.

Maar dat is allemaal niet zonder offers. Hypervisors worden het basis-OS van een machine, wat een last legt op de prestaties. Met onze eerste test meten we het veschil tussen een gast-OS op de hypervisor met hetzelfde OS op de machine zelf. Daarmee krijgen we een theoretische last op de machine die de hypervisor zelf veroorzaakt.

Bij ons komt uit een test me een enkele (vCPU toegewezen aan de VM) een prestatieverlies van 2,5 procent (gast-OS is Windows Server 2008) onder ESX, en maar liefst 12 procent onder Hyper-V met SLES. De daadwerkelijke lasten waren variabel, maar VMware wint deze theoretische ronde. Theoretisch, want er zijn maar weinig redenen te bedenken om een enkele guest met één processor op de platformen te laten draaien.

Als we het aantal voor de VM beschikbare CPU's laten stijgen, des te sterker varieert de werklast. Toen we een enkele OS SMP-toegang gaven tot vier vCPU's, was het verlies met minder dan 4 procent het kleinst, onder VMware met een SLES-gast. Aan de andere kant hadden we een SLES-sessie onder Hyper-V, dat met 15 procent verlies werd beboet.

Deze ronde verliest Hyper-V dus ook, maar de verschillen met Windows-sessies zijn wel erg klein. Grote verliezen worden geconstateerd met SLES, maar dat is waarschijnlijk omdat we toen LinuxIC nog niet tot onze beschikking hadden.

VM's gestest met zakelijke applicaties

De tweede ronde van onze prestatietests vergelijkt herhaalde applicaties die we op de VM's draaien, terwijl we ondertussen steeds meer VM's toevoegen. We hielden de resultaten bij voor een, drie en zes VM's met ondersteunde guests. We maten de prestaties terwijl elke guest op zijn eigen vCPU liep, en terwijl elke de beschikking kreeg over vier virtuele processors. Daarmee zouden we, theoretisch, de verschillen zichtbaar kunnen maken.

We kozen voor SPECjbb2005 als testtool, een wijdverspreide benchmark die gedistribueerde transacties in een warehouse-achtige omgeving nabootst. De test maakt gebruikt van Java-applicatiecomponenten die in een enkele host of VM-sessie draaien. Het eerste component simuleert een client die threads genereert voor het tweede component die als een business logic engine de objecten opslaat en terughaalt van en naar Java Collection objecten. Zo emuleert het een database-engine. SPECjbb2005 genereert testparameters op basis van het aantal gevonden CPU's en de hoeveelheid gehost geheugen. De gemeten output is het aantal operaties per seconde, of bops per tijdseenheid. Hoe meer bops per test, des te beter.

We draaiden meerdere sessies per hypervisor, met een set waarbij elke VM zijn eigen vCPU kreeg en een set met vier vCPU's per VM. Dit om de beurt met een, drie en zes VM's. We draaiden elke sequentie eerst met Windows Server 2008 als gast, en daarna met SLES 10.2 als gast.

De eerste ronde gebruikte een verdeling van één VM gast-OS per vCPU en gelimiteerde toegang tot het geheugen (2GB) per sessie. Dit is een typische verdeling voor serverconsolidatie van oudere machines met een enkele CPU worden geconsolideerd naar een fysieke-naar-virtuele hostverplaatsing.

VMware had direct een snelle start, waarbij WS 2008 en SLES in virtuele omgevingen bijna even snel draaiden als dat ze in een native-sessie zouden doen. Ook met drie besturingssystemen als gast hield ESX het tempo redelijk vol. Hyper-V met drie machines liep zo'n 1.400 bops achter met Windows Server, en 1.800 bops met SLES.

Beide hypervisors kregen echt moeite toen er zes guests gedraaid werden. Hier wint Hyper-V wat terrein terug, omdat deze het verlies net iets meer binnen de perken hield. Het lijkt erop de distributie toch iets meer lineair is vergeleken met ESX.

Maar in de echte wereld worden geconsolideerde sessies niet per se zo zwaar belast als met onze SPECjbb2005-tests. Slechts weinig besturingssystemen en applicaties zullen zo'n consistent CPU-verbruik tonen, en wij hebben de VM's en hypervisors nu ook echt onder enorme werklasten geplaatst.

Volgende week deel 2 van deze prestatietests, uitgevoerd door Tom Henderson en Brendan Allen van Networkworld.

Vertaling: Michiel van Blommestein

Bron Bron: Techworld