Lees deel 1 (installatie en gebruik van de Novell Xen-implementatie in SUSE) hier, en deel 2 (installatie en gebruik van XenServer) hier.

Na onze vergelijkingstest van VMware ESX en Hyper-V, kregen we veel commentaar op het feit dat Xen zo ontzettend afwezig was. Onze verklaring was dat ten tijde van de tests, die we in de zomer uitvoerden, geen enkele Xen-leverancier klaar was om mee te doen.

Ondertussen hebben we medewerking gekregen van Novell, Citrix en nog een derde partij, Virtual Iron, zodat we alsnog tests konden uitvoeren op deze Xen-derivaten. We hadden Red Hat en Sun aangeschreven, maar om verschillende redenen konden zij ook deze keer niet participeren.

Uit onze tests kunnen we opmaken dat lezers gelijk hebben als ze zeggen dat het open source Xen een grote uitdager is van de bedrijfseigen hypervisors Hyper-V en ESX. Pakken we de cijfers erbij van onze andere hypervisor-test, dan zul je zien dat de gebroeders Xen echt wel wat te melden hebben.

Para- of volledige virtualisatie

Novell SUSE Xen en XenServer bieden de mogelijkheid om te paravirtualiseren. Daarmee, zo is althans de gedachte, kan de toegang van een gast-vm tot de hulpbronnen van de fysieke server worden uitgebreid, waardoor het gast-OS beter bij die bronnen kan. Virtual Iron, onze derde geteste hypervisor, ondersteunt deze mogelijkheid niet.

Alle tests van SLES vm's op Novell Xen en Citrix XenServer zijn met de modi voor zowel paravirtualisatie als gewone virtualisatie uitgevoerd. Daarmee wilden we kijken of de genoemde voordelen van paravitualisatie consistent zijn. Maar helaas: hoewel paravirtualisatie voordelen biedt voor een paar van onze incrementele ingeladen profielen, konden we geen voordeel ontdekken dat consistent genoeg is om een trend aan te duiden. Om die reden hebben we het gehouden op een weergave van de beste score per hypervisor.

De benchmark voor transacties

We hebben verschillende testprofielen ontworpen die een ruwe weergave vormen van verschillende manieren waarop de hypervisors gebruikt worden. Alle producten werden voor deze ronde gedraaid op een HP 580 G5, vier socker/16 kernen server. Dat is dezelfde hardware als waarop we ESX tegen Hyper-V hebben getest.

Om de benchmarks voor transacties vast te stellen, gebruikten we SPECjbb2005, een op Java gebaseerde zakelijk meetsysteem. Eerst vergeleken we de prestaties van de basisprofielen, waarna we steeds meer vm's toevoegen tot we in oversubscription kwamen.

In over de gehele breedte bleek XenServer de snelste te zijn in onze transactiebenchmark.

Tijdens de test waarbij vm's met Windows Server 2008 gehost werden moest XenServer alleen genoegen nemen met het zilver toen we zes sessies draaiden, die allemaal toegang hadden tot een enkele virtuele processor. Daar ging Hyper-V aan de haal met het goud door 14.531 bops (basic operations per second) te halen, tegen 14.128 bops voor XenServer.

Wij denken dat XenServer meer hulpbronnen uitdeelt aan individuele vCPU's dan de andere hypervisors, waardoor de prestaties een lift krijgen zolang er niet meer dan één vm per processor wordt gedraaid.

Bij de SUSE Linux vm's mag het geen verrassing heten dat de Novell Xen-implementatie de eer pakt als we een enkel guest-OS draaiden. Het verschil met 25 bops is wel heel erg klein. ESX deed het beter dan XenServer als zes vm's werden gedraaid op vier vCPU's.

Prijs van prestatie

De server krijgt bij het virtualiseren van een besturingssysteem meer werk te verstouwen. Meer vm-guests betekenen meer gedeelde hulpbronnen waardoor de prestaties logischerwijs minder worden. Wij maten de prestaties van Windows Server 2008 Enterprise en Novell SLES 10.2 om te zien welke basisprestaties we kunnen verwachten. Dat kwam neer op 18.153 bops voor WS 2008 en 22.240 voor SLES.

Een hypervisor maakt het mogelijk om meer hulpbronnen toe te wijzen dan een native OS, omdat de hypervisor alle bronnen van de server kan verwerken, terwijl een native-installatie gebonden is aan bijvoorbeeld beperkingen van de kernel. Met de hypervisors meegeleverde I/O-drivers kunnen ook efficiënter omgaan met de hulpbronnen.

We hakten deze test in tweeën. Eerst voerden we de tests uit met slechts één socket en vier kernen, en vervolgens installeerden we de overige drie sockets, voor in totaal zestien kernen. Elke guest kreeg in dat laatste geval vier vCPU's toegewezen. Bij elke test voegden we steeds meer guests toe, en vergeleken we de resultaten met die van de native-OS'en op dezelfde hardware.

Hier kregen we een duidelijke winnaar, en ook in deze categorie was dat XenServer. Die was bijzonder efficiënt met het vinden en toewijzen van beschikbare systeembronnen aan vm's. In het geval waarin een vm-guest met enkele vCPU Windows Server draaide, wees XenServer genoeg bronnen toe om de guest soepeler te laten draaien dan native Windows. Daarbij gebruiken ze wel wat onderhandse trucjes, bijvoorbeeld door meer bronnen toe te wijzen dan de grote gemene deler, maar het werkt wel.

Ook wanneer drie vm's onderling vier rekenkernen (en dus vier vCPU's) mochten verdelen, bleef XenServer de koploper. Daarbij ging het net eventjes iets trager, maar nog steeds sneller dan native. Pas bij oversubscription begon XenServer echt te vertragen, maar het bleef sneller dan de concurrentie.

Met Novell SLES 10.2 als guest kan het geen verrassing heten dat Novell Xen voor SLES in de eerste paar tests als beste boven kwam drijven. Maar ook hier waren de verschillen klein, en vanaf vier vCPU's werd deze Xen-variant ingehaald door XenServer. En op geen enkel moment kwam de snelheid van de SLES vm uit boven die van native SLES.

Ook XenServer vm's met juist heel veel toegewezen vCPU's bleven redelijk goed presteren met WS 2008, met 98,5 procent van de prestatiecijfers van native Windows op vier vCPU's per vm. Hij kwam zelfs op een overweldigende 108 procent als we nog eens drie vm's toevoegden aan de vier vCPU's (het gaat immers om het vinden van meer systeembronnen). Bij oversubscription zakten de prestaties ietwat, met een score van 60 procent van de nativeprestaties bij zes guests, vier vCPU's ieder op een machine met zestien rekenkernen.

XenServer bleef de bovenliggende partij toen we Linux vm's met meerdere vCPU's voor elke vm draaiden, met uitzondering van het allerzwaarste scenario. Met zes SLES vm's op vier vCPU's voor elke guest is VMware ESX koning.

Wat verder opvalt bij XenServer is de inconsistentie bij zes vm's met ieders vier kernen. Hoewel de getoonde prestatiecijfers de gemiddelde snelheid van de vm's laten zien, hebben we ook de snelheid van elke vm op het moment van testen in de gaten gehouden. Met XenServer zaten de prestaties van de langzaamste en snelste vm soms wel 41 procent bij elkaar vandaan tijdens de tien testsessies die we deden. Geen enkele andere hypervisor liet zulke grote verschillen zien. Er viel ook niet te voorspellen welke vm tijdens deze scenario's het beste of slechtste zou presteren.

We vroegen Bill Caravano, voor Citrix verantwoordelijk voor technisch beheer van XenServer, om uitleg. Volgens hem zijn de variaties te verklaren door cron jobs die door de guests kunnen worden opgestart. Als er niet getweaked wordt, dan kunnen deze cron jobs erg onvoorspelbaar zijn, met als gevolg dat de prestaties fluctueren, zegt Caravano. Intern probeert Citrix deze cron jobs te onderdrukken, zodat de boel constant blijft.

Virtual Iron bungelt over het algemeen onderaan, maar het is belangrijk op te merken dat het niet altijd het sulletje was. Virtual Iron werd bijvoorbeeld tweede toen we een enkele Windows Server 2008-guest draaiden over vier vCPU's, met toegewezen geheugen van 2GB en alle beschikbare schijfruimte.

I/O resultaten

I/O-prestaties hebben we gemeten met IOMeter van Intel. Daarbij keken we naar het aantal I/O's per vm in zowel over- als undersubscription. Voor de eerste van onze twee I/O-tesscenario's gebruikten we zes guest-vm's die elk een enkele vCPU toegedeeld kregen, wat een typisch consolidatiescenario is. Bij de tweede test ging het om zes virtuele machines met vier vCPU en SMP-kernels.

Novell SLES Xen veegde de vloer aan met de concurrentie. Het resultaat was dusdanig overtuigend (Novell Xen haalde soms zelfs het tienvoudige ten opzichte van de rest) dat we test voor die hypervisor nog een keer hebben gedraaid om te zien wat er in de disk I/O-channel gebeurt. We maakten gebruik van een 70/30 wegschrijven/lezen ratio om virtualisatie na te bootsen in drukke omgevingen met een hoge I/O. Deze ratio komt lang niet bij elke applicatie voor, maar zware jongens als data warehousing, analyse, database-onderhoud en batch processing hebben meer aan writes dan aan reads, dus vandaar de zware instelling.

In het geval van Novell zagen we dat de lees/schrijf-transacties van de schijf in nogal lange cycli komen, in plaats van de regelmatige stroom van gegevens die de andere hypervisors lieten zien en normaal duidt dat op schijfactiviteit. Daarom dachten we direct dat Novell hier gebruik maakt van write caching.

Novells productmanager Santanu Bagchi bevestigde onze vermoedens door te zeggen dat write caching als standaard wordt ingesteld als de virtuele schijf geconfigureerd is als file-backed disk, wat met ons testbed inderdaad het geval was.

Write caching voorkomt dat er opstoppingen ontstaan bij drukte, maar in sommige gevallen kan het ook integriteitsproblemen veroorzaken in de transacties. Er valt wat voor te zeggen dat veel serverconfiguraties ondervangen kunnen worden met een accu, zodat de transactie-integriteit die ontstaat door het tijdelijk opslaan wordt beschermd zolang de accu het volhoudt, of tot wanneer de gegevens daadwerkelijk zijn weggeschreven.

In moderne datacentra worden servers dikwijls beschermd tegen stroomstoringen en andere ongelukken die de cache kunnen corrumperen. Daarom besloten wij Novell Xen niet te diskwalificeren, ondanks dat puristen zich niet zullen vinden in het cachen-als-standaardinstelling en de potentiële rampen die daarmee kunnen ontstaan.

De cijfers die Citrix XenServer bij deze test haalde waren dusdanig laag, dat we toch even bij de fabrikant te rade gingen. Ons werd verteld dat we de scheduler moesten instellen op NOOP, wat de standaardinstelling hoort te zijn. Dat was het alleen niet door een bug in de installer. Maar deze verandering verslechterde de cijfers juist voor Windows vm's, terwijl voor SLES de resultaten flink omhoog sprongen. De cijfers die we hier geven, zijn die met NOOP als scheduler.

Als het gaat om prestaties, dan concurreren de broertjes Xen flink mee. De vraag die bij een keus gesteld moet worden, is wat je het belangrijkst vindt voor jouw vm-omgeving. Bij transactieprestaties is dat XenServer, terwijl Novell Xen uitblinkt in I/O (mits je tegen caching kunt).

Vertaling: Michiel van Blommestein

Bron Bron: Techworld