Project VRC: Klokafwijking en testresultaten
Gepubliceerd op 23 september 2009 • 4 min leestijd • 799 woordenNaar mijn mening is dit een serieuze tegenslag voor Project VRC dat wordt beschouwd als een instituut in de virtualisatiewereld. Mensen zullen de resultaten in twijfel trekken als er geen nieuwe tests worden uitgevoerd.
Hieronder vindt u een beschrijving van de Project VRC-website waarin de nieuwe whitepaper wordt uitgelegd die zij op 14 september 2009 hebben gepubliceerd. Dit is een must read voor mensen die al wat tests hebben gedaan, evenals nieuwe tests. Kortom: ‘Door het Windows-klokgedrag in virtuele machines zijn de resultaten beïnvloed en kunnen sommige hypervisors beter uitkomen dan ze in werkelijkheid zijn.
Deze whitepaper is een recensie en reflectie op eerdere Project VRC-publicaties, de benchmark: “Login Virtual Session Indexer (VSI)” en Windows-klokgedrag binnen virtuele machines. Deze discussie wordt aangewakkerd door het feit dat de resultaten van de afzonderlijke Project VRC-whitepapers naast elkaar worden geplaatst om hypervisors met elkaar te vergelijken. Project VRC is in gesprek geweest met zowel leveranciers als de gemeenschap en heeft in deze context aanvullend onderzoek uitgevoerd. Voordat Project VRC nieuwe resultaten kan publiceren, is het belangrijk om eventuele vragen te beantwoorden, de impact van deze discussie te beoordelen en VSI waar mogelijk te verbeteren.
Je kunt het downloaden op www.projectvrc.nl
De belangrijkste conclusies in dit Whitepaper zijn:
- Klokafwijkingen binnen VM’s zijn mogelijk op elke hypervisor. Dit heeft twee implicaties:
- De klok is verantwoordelijk voor de responstijdmetingen: de gerapporteerde resultaten kunnen minder nauwkeurig zijn.
- De klok wordt gebruikt bij elke getimede gebeurtenis zoals slaap/wachten/vertraging/pauze/etc.: dit kan een impact hebben op de zwaarte van de werklast omdat de activiteiten zich in de loop van de tijd uitstrekken.
- Het gebruik van /USEPMTIMER in boot.ini is vereist voor Windows 2003-gasten die op XenServer draaien. Dit lost de consistente 10% klokafwijking/nauwkeurigheidsproblemen op die op XenServer voorkomen.
- De gemeten afwijkingen/nauwkeurigheidsproblemen zijn veel lager (een consistente 10-20 ms per getimede gebeurtenis) met VMware vSphere 4.0 en Microsoft Hyper-V 2.0.
- Login VSI 2.0 introduceert een nieuwe indexeringsmethode genaamd VSImax. De nieuwe methode is nauwkeuriger omdat elke vorm van scripted of ingebouwde vertraging/slaap volledig wordt uitgesloten van de gemeten responstijd.
- Door de genoemde verbeteringen in de scriptmethode die in Login VSI 2.0 wordt gebruikt, is de betrouwbaarheid en robuustheid enorm verbeterd: de VSI-werklast is nu stabiel onder extreme omstandigheden.
- VSI is leverancier- en productonafhankelijk. Om deze reden blijft AutoIT de geprefereerde en meest praktische methode om de VSI-werklast te genereren.
- Met VSI 2.0 is het nu mogelijk om de responstijd op een externe Microsoft SQL-server te meten en tijdens runtime de slaapplaatsen binnen het AutoIT-script te kalibreren.
- Externe klokken en kalibratie beïnvloeden de resultaten met een relatief kleine marge (er werd tot 6% gemeten).
- De overstap van Optimal Performance Index naar VSImax heeft potentieel een veel grotere invloed op de resultaten. Als gevolg hiervan is het veilig om aan te nemen dat de verhouding tussen VMware ESX 3.5 en Citrix XenServer 5.0 gerapporteerd in VRC1.0 vergelijkbaar zou zijn met de VSI 2.0-resultaten die we vonden met vSphere 4.0 en XenServer 5.5 als VSImax werd gebruikt.
Naar aanleiding hiervan maakten zij de volgende opmerking:
Het is de moeite waard om kalibratie te gebruiken wanneer hypervisors worden vergeleken. Bij het evalueren van verschillende configuraties op één hypervisor zijn de resultaten echter altijd relatief en zou kalibratie de conclusies niet veranderen. Bijgevolg veranderen deze bevindingen niets aan de aanbevelingen en best practices die zijn ontdekt en gepubliceerd in VRC 1.0 en de 1.1-update. Project VRC zal voortaan alleen de specifieke VSImax-uitkomst publiceren bij gebruik van een externe klok. Eventuele “niet-gekalibreerde” resultaten zullen alleen worden gebruikt om de verschillen (in %) binnen de context van één hypervisor te benadrukken.
Hoe waar deze bewering ook mag zijn, veel van onze klanten gebruiken de verschillende whitepapers om hypervisors te vergelijken, hoewel Project VRC helemaal draait om Microsoft-clientbesturingssystemen en VDI versus terminalserverschaling op verschillende hypervisors. Dus als ze de resultaten van de voorgaande tests niet corrigeren, zijn ze naar mijn mening waardeloos geworden en dat zou zonde zijn, want Project VRC is een geweldig initiatief en ik weet dat jongens als Ruben Spruijt en Jeroen van de Kamp veel tijd besteden aan het proberen ons iets te geven om mee te werken.
Ik hoop dus echt dat ze de tijd vinden om de resultaten van de vorige test te corrigeren, omdat klanten en leveranciers altijd zullen proberen hun geweldige test te gebruiken om een hypervisorvergelijking te doen, omdat het vergelijken van hypervisors zo’n verdomd moeilijke taak is om (zichzelf) uit te voeren.