(Deel 1 is hier te lezen)

In de tweede ronde van onze herhaalde tests lieten kreeg elke VM de beschikking over vier vCPU's, het maximale dat de beide hypervisors toestaan. We hielden vast aan het plafond van 2 GB geheugen per VM, omdat dat een veelgebruikt maximum is bij het consolideren en testen van besturingssystemen. Meer dan de vorige opstelling laat dit scenario zien hoe VM's worden gebruikt in gevirtualiseerde database-applicaties, renderingparken, drukke transactiesystemen en andere applicaties die veel rekenkracht nodig hebben.

Ook nu zijn we begonnen met een enkele VM-guest om een ijkpunt te vast te leggen. Daar hebben we opnieuw twee machines aan toegevoegd voor een ronde, waarna we met zes machines hebben getest. In de eerste test merkten we, net als in onze test van de extra virtualisatiekosten, dat VMware een krappe afstand neemt wanneer deze Windows Server 2008 clients host, en een afstand van bijna 1100 bops met SLES 10.2 VM's. De prestaties van Hyper-V met SLES werden bij meerdere vCPU's verder beknot, omdat LinuxIC geen ondersteuning biedt voor SMP-omgevingen.

Bij de test van drie VM's met elk vier vCPU's, hadden we in totaal dus de beschikking over twaalf virtuele processoren. Omdat onze server was uitgerust met zestien fysieke cores, bleven vier van de cores ongebruikt. Hyper-V nam hier de leiding op VMware ESX, met een gemiddelde voorsprong van 6.500 bops. Dat suggereert dat Hyper-V de extra beschikbare bronnen kan vinden en aanwenden, en ESX die functie niet heeft. Maar dat voordeel verdwijnt als we gaan oversubscriben, een methode die meer fysieke CPU aan VM's toewijst dan daadwerkelijk beschikbaar is waardoor de machines hun capaciteit kunnen 'delen'. Dit proces is nuttig in het geval dat de VM's applicaties draaien waarbij de benodigde rekenkracht fluctueert, omdat het dan mogelijk is om meer virtuele machines te draaien, hopelijk zonder dat het ten koste gaat van de prestaties, of wellicht zelfs met betere prestaties vergeleken met wat de guests in een niet-gevirtualiseerde situatie zouden doen.

We lieten zes VM-guests met ieders vier virtuele processors oversubscriben op de zestien fysieke kernen in onze testopstelling. Beide hypervisors beginnen te piepen en te kraken onder deze extreme werklast, maar VMware lijkt toch beter om te gaan met oversubscription dan Hyper-V, getuige de 16.136 bops op WS 2008 (Hyper-V haalde 14.588) en 17.089 bops met SLES (11.122 voor Hyper-V). Microsoft heeft hierbij ook het nadeel dat een native sessie van Windows Server 2008 vereist is, en dat legt zijn tol op de rekencapaciteit.

De I/O in het licht van virtualisatie

We keken met IOMeter van Intel naar het schijfverkeer die de VM's genereren. IOMeter zet de subsystemen aan het werk door threads te genereren die lezen van en wegschrijven naar deze systemen in een door de testers gedefinieerde routine. De metingen worden weergegeven in IO's per seconde en ook hiervoor geldt: hoe hoger, hoe beter.

In deze gevirtualiseerde wereld hebben VM-guestsessies te maken met of de interne schijf, of het SAN. Wanneer de hardware met virtualisatie opnieuw wordt weergegeven in de guest-OS'en, dan gebruikt de hypervisor-laag zijn eigen disk driver om de activiteit in goede banen te leiden. Door VM's toe te voegen ontstaat een verdeling van de hardwarecapaciteiten onder de verschillende VM-sessies. Hoewel de systeemdrivers van de native besturingssystemen best goed kunnen zijn, is het beheren van de communicatieprocessen tussen guests door de hypervisor een erg secuur proces, en latency en inefficiëntie komen voelbaar terug in de prestaties van de applicaties.

We draaiden IOMeter binnen elke sessie om te zien hoe snel de hypervisor de gegevens naar de schijf weet te verplaatsen. We gebruikten een veeleisende verhouding van 70 procent writes en 30 procent reads. We wilden meer writes, omdat deze niet op grote schaal worden gecached door het besturingssysteem (en de inhoud niet verloren gaat wanneer de stroom uitvalt of de hardware opnieuw wordt opgestart). Bovendien kan read-based cache de metingen vertekenen.

We hebben de I/O-prestaties van het native OS gemeten (zowel in enkele als in SMP servers) om een eikpunt te krijgen van de I/O van de schijf. Vervolgens hebben we getest op elke omgeving met zes VM-guests. We waren benieuwd of de hypervisors de beschikbaarheid van de bandbreedte voor VM's konden verhogen ten opzichte van de native sessies.

Het goede nieuws is dat de tests laten zien dat beide hypervisors de capaciteit flink laten toenemen ten opzichte van de native drivers. Daarmee laten de hypervisors zien dat ze de disk channel prima kunnen benutten en vol kunnen gooien wanneer meer VM's worden bijgeplaatst.

We zagen in het geval van de gehoste SLES met een enkele vCPU dat Hyper-V flink profiteert van LinuxIC, en dat het daardoor beter draait dan ESX. Zonder LinuxIC waren de prestaties min of meer gelijk, met minder dan een procent verschil tussen de twee.

Helaas doet Hyper-V het niet zo goed met het leveren van I/O aan zijn eigen Windows Server 2008. VMware zet Microsoft op flinke achterstand met zes draaiende WS 2008-VM’s.

Tijdens het meten van de schijf I/O-activiteit in een SMP-omgeving, hebben we de server bewust oversubscribed om te zien of de hypervisor de channel-activiteit kon volhouden als elke guest een eisenpakket van de opslag krijgt. De hypervisor moet, omdat het een ook dienst doet als besturingssysteem, in staat zijn om de wegschrijftijd nauwkeurig kunnen toewijzen, en om de contexts tussen guests netjes en efficiënt te wisselen.

Beide hypervisors bleken in deze test sneller te zijn op I/O-gebied dan een native-OS op bare metal hardware. Maar ESX is de duidelijke winnaar. Het zette 1733,63 I/O’s per seconde neer met WS 2008-guests, tegen 874,29 I/O’s per seconde voor Hyper-V. Native haalde Windows Server 712,97 I/O’s per seconde. Op SLES wint ESX ook, ware het met een schamele 45 I/O’s per seconde. Wederom haalde Hyper-V geen profijt van LinuxIC, dat geen SMP ondersteunt.

Conclusie

De voorsprong die VMware heeft op de markt, heeft er ook voor gezorgd dat ESX een voorsprong heeft op de meeste prestatiegebieden waar we op hebben getest. Maar de macht van Microsoft begint door te sijpelen op een sleutelpositie: consolidatie van VM-prestaties in omgevingen met enkele processors. Beide leveranciers zullen de prestaties van hun software blijven verbeteren, vooral omdat dit een belangrijk aspect is van de wedloop. Ondertussen worden ze in de enkels gebeten door Citrix, Sun en Red Hat, en open source begint steeds meer commerciële kracht te vertonen. Prestaties van VM’s blijft een aspect waar we zeker op moeten blijven letten.

Test uitgevoerd door Tom Henderson en Brendan Allen van Networkworld.

Vertaling: Michiel van Blommestein

bron Bron: Techworld