Welk virtualisatieplatform biedt de grootste meerwaarde in datacenters als bare-metal hardwarevirtualisatiesolution: Hyper-V of Esxi?

Welk virtualisatieplatform biedt de grootste meerwaarde in datacenters als bare-metal hardwarevirtualisatiesolution: Hyper-V of Esxi? Promotor: Mh Johan De Gelas Onderzoeksvraag uitgevoerd door

VAN ONSEM MATTHIAS Voor het behalen van de graad van Bachelor in de

NEW MEDIA AND COMMUNICATION TECHNOLOGY HOWEST | 2015-2016

Woord vooraf Virtualizatie is vandaag de dag niet meer weg te denken uit moderne datacenterinfrastructuren. Zowel scalability, onderhoudbaarheid, kost efficiëntie, enz. vormen sterke argumenten die tot een keuze naar virtualizatie leiden. In de datacenterwereld is bare metal virtualizatie dan ook vrijwel altijd aanwezig om zo efficiënt mogelijk met de beschikbare middelen om te springen. Doorheen de jaren zijn er dan ook heel wat platformen aanwezig. Zowel Cisco, Microsoft, Oracle en vele anderen concurreren nu hevig om het grootste deel in een steeds groter wordende markt. De bekendste platformen zijn wellicht Esxi (VMware) en Hyper-V (Microsoft) die samen ongeveer 80% van de markt in beslag nemen. Voor mijn bachelorproef onderzocht ik twee maanden lang de virtualizatieoplossingen Hyper-V en Esxi en hun specifieke kenmerken. Doorheen dit document zal je een aantal argumenten vinden die het maken van deze keuze gemakkelijker moet maken. Ik zal ook bij elk punt een aantal specifieke praktische situaties benaderen met daarbij een voorkeurssysteem. Het is dan ook de bedoeling dat je als lezer op het einde van het document een beter beeld krijgt over de verschillen en gelijkenissen van Hyper-V en VMware. Ik wil voor dit werk graag allereerst Pieter Schepens, Alexander Vervaet en Jan Demedts van het ICT-beleid van Don Boscocollege Zwijnaarde bedanken voor de middelen die zij mij ter beschikking stelden voor het uitvoeren van onderstaand onderzoek. Ook de vrijheid die zij mij schonken tijdens mijn stageperiode heeft de voortgang tot dit onderzoek sterk versneld. Tot slot wil ik graag mijn vriendin bedanken voor de steun en het vertrouwen in mij doorheen dit proces.

1

Inhoudsopgave Woord vooraf ................................................................................................................................................ 1 H1 – Virtualisatie, een korte inleiding........................................................................................................... 3 Inleiding..................................................................................................................................................... 3 Bare metal virtualisatie ............................................................................................................................. 3 De huidige marktsituatie........................................................................................................................... 4 Esxi ............................................................................................................................................................ 4 Hyper-V ..................................................................................................................................................... 5 H2 – Performance ......................................................................................................................................... 7 Inleiding..................................................................................................................................................... 7 Hardware .................................................................................................................................................. 7 Software en tools ...................................................................................................................................... 8 Resultaten ................................................................................................................................................. 8 Inleiding................................................................................................................................................. 8 CPU performance .................................................................................................................................. 8 Grafische performance – de default situatie ...................................................................................... 12 Grafische performance – RemoteFX, PCI-passthrough en vSGA ........................................................ 16 Memory en Storage ............................................................................................................................ 25 H3 – Conclusie............................................................................................................................................. 29 Inleiding................................................................................................................................................... 29 Kostprijs .................................................................................................................................................. 29 Performance ........................................................................................................................................... 29 Algemene conclusie ................................................................................................................................ 30 Bijlagen........................................................................................................................................................ 31 CPU-performance ................................................................................................................................... 31 GPU-performance - default .................................................................................................................... 37 GPU-performance - RemoteFX

................................................................................................... 51

Memory-performance ......................................................................................................................... 58 Storage-performance – SSD

................................................................................................................ 60

Storage-performance – RAID 10

......................................................................................................... 62

2

H1 – Virtualisatie, een korte inleiding Inleiding Doorheen dit document zal een vergelijking worden gemaakt tussen de twee populairste bare metal virtualisatieplatformen op de markt, namelijk Hyper-V en Esxi. We zullen zowel performance, administratie en security bespreken aan de hand van duidelijke voorbeelden en tests. Deze resultaten worden geanalyseerd om zo tot een objectief besluit te kunnen komen over welk platform in welke situatie de voorkeur zal genieten. Let wel dat onze middelen qua hardware en beschikbare tools beperkt is waardoor de kwaliteit van dit onderzoek (vooral op vlak van performance) waarschijnlijk lager zal liggen dan onderzoeken die worden uitgevoerd door professionele bedrijven of universiteiten.

Bare metal virtualisatie Wanneer we spreken over bare metal virtualisatie, bedoelen we een situatie waar we onze virtualisatielaag rechtstreeks op de hardware zal draaien. Virtualbox en VMware workstation zijn met andere woorden geen bare metal virtualisatiesystemen omdat we deze op een OS zoals Linux of Windows draaien. Hyper-V en Esxi worden dus rechtstreeks op de hardware geïnstalleerd. Een ander voorbeeld van bare metal virtualisatie is Citrix Xenserver. Deze manier van virtualisatie heeft als grote voordeel dat we rechtstreeks gebruik kunnen maken van de hardwaremiddelen zonder rekening te moeten houden met een eventueel Parent OS. Onze hypervisor zal hier alle hardware beheren en beperkte middelen beschikbaar stellen aan de VM’s. Dit geeft als voordeel dat we meerdere systemen op dezelfde hardware kunnen draaien, wat onze hardware veel efficiënter maakt tov wanneer slechts één systeem de hele hardwareset gebruikt die hij zelden zal gebruiken.

Figure 1 bare metal

3

De huidige marktsituatie Tot op heden zijn er slechts drie grote spelers aanwezig wanneer we de markt van bare metal virtualisatie bekijken, namelijk Esxi, Hyper-V en Citrix Xenserver. De marktaandelen van deze hypervisors zijn als volgt verdeeld:

Marktsituatie 2014

13% 3.30%

56%

28%

Vmware

Microsoft

Citrix

andere

Aangezien Esxi (Vmware) en Hyper-V (Microsoft) samen een monsteraandeel bedragen, is het interessant dat deze twee systemen eens degelijk met elkaar vergelijken om zo te kunnen uitmaken in welke situaties welke hypervisor nu het best van pas komt.

Esxi Vmware biedt al sinds 1998 hun hypervisor aan als bare metal virtualisatieoplossing. Esxi (vroeger Esx server genaamd) wordt tot op heden ook als trendzetter gezien wanneer we over virtualisatie spreken. Esxi bevat twee grote componenten die samen de virtualisatieoplossing omvatten, namelijk Esxi en Vsphere. Wanneer we spreken over Esxi, bedoelen we technisch gezien enkel de hypervisor of de virtualisatielaag die op de hardware draait. Dit wil zeggen dat Esxi op zich een bare metal virtualisatieoplossing is aangezien deze perfect in staat is hardware te virtualiseren en virtuele machines (VM’s) op deze hardware te laten draaien.

4

We hebben echter nog nood aan een tweede component om deze hypervisor te beheren. Dit onderdeel wordt ingevuld door Vsphere of Vcenter. Deze management software kan zowel een client zijn die op een andere machine werd geïnstalleerd, of een webinterface die rechtstreeks zal draaien op onze Esxi host.

Figure 2 Esxi

Figure 3 Prijs Esxi

Esxi en vsphere zijn heden niet meer gratis te verkrijgen. Als klant kan je echter wel nog een 60 dagen probeerversie installeren om te zien hoe de software precies werkt, maar daarna is een jaarlijkse licentie verplicht, het kostenmodel zit als volgt in mekaar: Een probeerversie bemachtigen vereist eveneens ook een bedrijfsemail een het invullen van een enquête. De laatste versie momenteel is de 6.0. We zullen deze versie ook behandelen in onze vergelijking doorheen dit document.

Hyper-V Microsoft wordt heden nog veel gezien als de nieuwe speler in virtualisatieland. Dit komt vooral omdat de eerste versie van Hyper-V pas in juni 2008 werd geïntroduceerd in bepaalde Windows Server versies. Momenteel zit Hyper-V standaard verwerkt in elke Windows Server versie en eveneens in de consumentenversies van Windows (die worden niet gezien als bare metal).

5

Ook hier wordt de virtualisatieoplossing in twee delen opgesplitst: namelijk de hypervisor en de management tools. Wanneer we Hyper-V echter enablen op Windows Server, zien we dat Windows Server nog steeds aanwezig is voor management. Management kan echter ook vanop afstand worden gedaan via een Windows client met Hyper-V management tools enabled. Hyper-V heeft sinds 2012 ook zijn eigen OS gekregen: namelijk Hyper-V server. Dit is een Windows distributie zonder GUI waar enkel de hypervisor op draait. Management moet hier zowiezo vanop afstand gebeuren. Het prijsmodel van Hyper-V is echter een stuk goedkoper dan Esxi. Enerzijds kunnen we Hyper-V server volledig gratis en onbeperkt downloaden, installeren en gebruiken. We moeten ons hier echter wel registreren met een Microsoft account. We zullen echter wel merken dat specifieke features zoals RemoteFX (zie grafische performance) niet beschikbaar zijn op deze gratis versie en we dus een licentie moeten kopen voor Windows Server. Deze licenties hebben een prijs per geïnstalleerde eenheid. We maken echter wel een onderscheid tussen fysieke eenheden (POSE’s) en virtuele eenheden (VOSE’s). de prijs per eenheid zit op de volgende manier in elkaar:

Figure 4 Prijzen Hyper-V

In de volgende vergelijking maken we gebruik van zowel Windows Server 2016 TP4 (momenteel nog gratis) en Hyper-V server 2016. Merk dat dit nog geen afgewerkte producten zijn en onderstaande resultaten dus kunnen afwijken van de definitieve release.

6

H2 – Performance Inleiding In de discussie over welk virtualisatie de voorkeur verdient, wordt performance zeer vaak over het hoofd gezien. Performance is echter zeer belangrijk wanneer we kiezen naar de juiste oplossing. We willen namelijk dat onze VM’s zo veel mogelijk van de fysieke middelen ter beschikking hebben om verwachte taken uit te voeren. Het is ook cruciaal dat deze middelen zo efficiënt mogelijk schalen wanneer meerdere VM’s toegevoegd worden aan één fysieke eenheid. We kunnen performance opdelen in volgende grote factoren:    

De geheugenperformance (RAM) De storageperformance (disks) De CPU-performance De grafische performance

Deze factoren zijn zeer situatie specifiek. Wanneer we bv. virtualisatie willen toepassen op webapplicaties, zullen we niet zo geïnteresseerd zijn in grafische kracht dan wanneer we bijvoorbeeld 3D willen renderen. Het is ook belangrijk dat we deze tests op meerdere “soorten” VM-opstellingen toepassen. Het kan namelijk zo zijn dat de performance niet goed zal schalen naarmate meerdere VM’s worden toegevoegd. We zullen de tests dan ook uitvoeren wanneer slechts één VM aanwezig is, alsook wanneer twee VM’s tegelijk actief staan om de schaling van de beschikbare middelen te testen.

Hardware Voor we beginnen aan de effectieve tests, is het handig om eerst even de gebruikte hardware te bekijken. De volgende configuratie werd voornamelijk gebruikt:      

i7 3770K 3.6Ghz CPU (met Corsair H80 liquid cooler) ASUS P8Z77-V Pro moederbord 4x4GB Corsair Vengeance DDR3 RAM 1600Mhz (9-9-9-24) Samsung 850 EVO 256GB SSD (TRIM enabled) MSI R9 390X 8GB Gddr5 OC (1100Mhz clock, 6.1Ghz memory clock) Corsair HX1050 modular PSU (80 PLUS Gold certified)

Om disk performance te testen is het uiteraard aangewezen dat zowel magnetische HDD’s als SSD’s worden getest. Daarom werd voor deze specifieke test ook volgende configuratie gebruikt.    

2x Xeon e5 5630 2.5Ghz CPU (in NUMA) 48GB 1033Mhz RAM 8x Seagate 500GB HDD 7200rpm (in hardware RAID10) 2x 860Wh PSU

7

Software en tools Er zijn heel wat performance testing tools aanwezig die gebruikt kunnen worden. Voor de volgende tests werden vooral volgende test suites gebruikt  

Passmark 8 3Dmark (Fire Strike)

Deze tests werden uitgevoerd op de volgende configuraties       

Windows 10 op hardware 1x Windows 10 op Windows Server 2016 TP4 2x Windows 10 op Windows Server 2016 TP4 1x Windows 10 op Hyper-V Server 2016 2x Windows 10 op Hyper-V Server 2016 1x Windows 10 op Esxi 6.0 2x Windows 10 op Esxi 6.0

Alvorens we deze testen bespreken zien we uiteraard dat dit redelijk consumentgerichte testen zijn. Dit wil zeggen dat deze testen zeker geen optimale serversituaties schetsen. Vele Server- en VM-gerichte benchmarktools zoals SiSoftware en VMwareMark vereisen echter ofwel licentie om mee te werken, of kunnen niet als objectieve tool gezien worden in de vergelijking die we momenteel behandelen. We zullen proberen deze testen zo algemeen mogelijk te benaderen zodat we toch een realistisch beeld kunnen schetsen van onze behandelde hypervisors.

Resultaten Inleiding We onderscheiden onze resultaten in vier algemene categorieën:    

CPU performance GPU performance Memory performance Disk performance

Bij elk van deze resultaten zal een analyse volgen die enerzijds zal toelichten waarom we tot deze resultaten komen en anderzijds op welke praktijksituaties deze resultaten een groot effect kunnen hebben. We zullen ook zien dat we sommige resultaten kunnen boosten door een aantal instellingen te herconfigureren in de hypervisor zelf. Deze instellingen zullen ook in detail besproken worden samen met een aantal opmerkingen en praktische situaties waar deze van toepassing zijn.

CPU performance Om het concept CPU performance in virtualisatie beter te begrijpen, moeten we eerst kijken naar hoe de CPU-middelen worden doorgegeven aan onze VM’s. We onderscheiden hier vier aparte virtualisatietechnieken van de CPU: partial, full, hardware assisted en paravirtualization.

8

Wanneer we spreken over partial virtualization, zal slechts de address space gevirtualizeerd worden. Dit wil zeggen dat ons OS niet volledig in een VM zal draaien en dus niet volledig wordt geïsoleerd. Om de address space te kunnen virtualiseren hebben we echter wel nood aan hardware die address-relocation of virtueel geheugen ondersteund. Full virtualization daarentegen biedt ons de mogelijkheid om het volledige OS zonder aanpassingen volledige virtueel te draaien. Hyper-V en Esxi zijn dus beiden voorbeelden van Full virtualization platformen aangezien de CPU volledig wordt gevirtualizeerd. Let wel dat Full virtualization zonder hardware assist redelijk wat overhead met zich meebrengt. Hardware assisted virtualization lost dit probleem grotendeels op. Hier zal de hardware ons grotendeels helpen met het isoleren van onze VM’s, alsook om de performance overhead te minimaliseren. Hardware assisted virtualization is een vorm van full virtualization en wordt volledige gesupport in Hyper-V en Esxi. Zowel AMD als Intel komen met hun eigen branding voor deze technologie, namelijk Intel-VT (Virtualization Technology) en AMD-V. Naast deze drie vormen onderscheiden we ook nog Paravirtualization. Hier maken we gebruik van APIredirection. We passen als het ware het guest-OS aan zodat deze speciale API’s zal aanspreken van de Hypervisor. Deze API- of Systemcalls worden ook wel eens Hypercalls genoemd. Dit wil zeggen dat we niet verplicht zijn de hardware te virtualiseren, maar we wel nood hebben aan de source code van het guest-

OS aangezien we deze moeten hercompileren. Paravirtualization wordt niet ondersteund in Hyper-V en Figure 5 vCPU's

Esxi.

9

In dit document hebben we te maken met Hardware Assisted Virtualization met Intel-VT. We virtualiseren onze logische cores of threads dus tot vCPU’s zoals hierboven snel werd geschetst. Let wel dat elke vCPU slechts een tijdsslot omvat van elke sequenciële thread. Dit wil zeggen dat wanneer we twee vCPU’s op één thread draaien, in theorie de performance van elke vCPU op die thread met 50% gereduceerd wordt. Aan de andere kant wil dit ook zeggen dat SMT perfect te combineren valt met vCPU’s, waardoor we in het geval van onze i7 CPU acht parallelle vCPU’s kunnen toewijzen aan onze VM’s aangezien deze quad core CPU hyperthreading ondersteunt. Let dus ook dat Intel hier heden (maart 2016) een stapje voor heeft tov AMD aangezien de nog niet bestaande ZEN-architectuur de eerste AMD-CPU’s zullen brengen die SMT ondersteunen. Voor onze tests definiëren we twee Windows 10 VM’s die elk acht vCPU’s ter beschikking hebben. Hieruit kunnen we zien hoeveel CPU-performance we effectief verliezen wanneer we één systeem virtueel draaien, alsook hoeveel performance loss we krijgen wanneer twee vCPU’s op 1 sequenciële thread draaien. We doen dit voor zowel Hyper-V als Esxi en nemen dezelfde benchmark op een Windows 10 host die rechtstreeks op de hardware draait als marge. We kunnen volgende resultaten afleiden:

CPU-performance Total 12000 10453 10000

9113

8000

6943 6955 6061

6000

10681

6228 5540 4437 4391

4000 2000 0 Windows Server 2016 TP4

Hyper-V server 2016 1 VM

2 VMs 1

Esxi 6.0

Hardware

2 VMs 2

Let wel dat deze resultaten een groepering representeerd van verschillende resultaten, in de volgende bespreking zullen de resultaten te vinden op pagina 30 aan bod komen. Wat meteen opvalt is dat Esxi een stuk hoger ligt (ongeveer 10% tov Windows Server) bij vrijwel elke CPUtest. Deze benadering is consistent wanneer we schalen naar twee VM’s. We kunnen hieruit al snel afleiden dat Hyper-V een hogere CPU-overhead met zich meebrengt dan Esxi wanneer we deze virtualiseren. We kunnen er al snel van uitgaan dat door de vele Windows Server processen en services die standaard draaiende zijn, onze vCPU standaard minder resources beschikbaar zullen hebben voor eigen gebruik. We 10

kunnen dit zeer mooi zien on onze single threaded test, waar slechts één vCPU belast zal worden. Enerzijds zien we dat één VM in Windows Server 2016 slechter scoort dan wanneer we twee VM’s te test synchroon laten uitvoeren. Omdat we dit verschil niet terugzien in onze Hyper-V server test, kunnen we er vanuit gaan dat deze test op één VM werd uitgevoerd op een thread die op dat moment gebruikt werd door de standaard Windows Processen van onze Hypervisor. In theorie levert het feit dat we hier Windows Server 2016 draaien met GUI ook wat overhead mee tov een Server zonder GUI. In onze praktijksituatie is deze overhead echter te verwaarlozen aangezien we gebruik maken van een externe GPU (R9 390X) om onze grafische elementen te renderen. Het is echter wel aangewezen voor systemen zonder dedicated GPU, de GUI uit te schakelen. Dit zal niet alleen een groot verschil in CPU-performance geven, maar ook meer RAM beschikbaar stellen aangezien dit wordt gebruikt als VRAM door de CPU. De grootste verwondering lijkt hier toch het performanceverschil tussen Windows Server 2016 met alle toeters en bellen aanwezig en de lightweight Hyper-V server die niet eens een GUI geïnstalleerd heeft staan. Deze testen werden meerdere keren uitgevoerd om tot een objectief resultaat te komen. We kunnen zien dat dit performanceverschil (ongeveer 33%) eveneens veel te groot is om nog te negeren of te wijten aan opstart- of updateprocessen. We moeten hier echter wel rekening houden met het feit dat Hyper-V een gratis tool is, terwijl Windows Server 2016 een licentie vereist. We kunnen hieruit afleiden dat de hypervisor in Hyper-V server in grote mate onderdoet aan die van Windows Server 2016. Deze redenering wordt nogmaals versterkt wanneer we de schaling van multithreaded performance vergelijken van één VM naar twee VM’s. Tests zoals bijvoorbeeld compressie, encryptie en Extended Instructions (ook wel SIMD genaamd). Enerzijds zien we hier mooi het voordeel in performance bij het gebruiken van Hardware Accelerated Virtualization. Hoewel we in theorie 50% performance verliezen wanneer twee vCPU’s aanwezig zijn op dezelfde thread, zien we dat onze performance slechts met 40% gereduceerd wordt in onze situatie. Anderzijds kunnen we ook stellen dat de schaling en proporties van Hyper-V server tov Windows Server hetzelfde zijn, met andere woorden onze performance schaalt in dezelfde mate, maar onze VM’s krijgen in de eerste plaats minder CPU-performance toegekend. De multithreaded testen op zich vormen een zeer interessante factor bij het kiezen naar de juiste virtualizatiekeuze. We willen namelijk onze hardware zo efficiënt mogelijk benutten. Dit wil zeggen dat in een optimale situatie, we streven naar een situatie die mooi wordt uitgebeeld in onze multithreaded tests omdat we ons systeem dan als het ware ten volle benutten. We merken hier een zeer klein verschil tussen Esxi en Windows Server (slechts 5% in het voordeel van Esxi). Dit is enerzijds normaal, aangezien onze standaard Windows services en processen redelijk beperkt worden in aantal cores die worden gebruikt. Deze logica wordt eveneens versterkt wanneer we deze testen uitvoeren over meerdere VM’s. Vooral bij de multithreaded tests zien we dat Windows Server bijna gelijk staat in performance met Esxi. Dit is hoogstwaarschijnlijk ook te wijten aan het feit dat de tijdssloten van elke vCPU steeds kleiner worden naarmate meer vCPU’s actief staan op dezelfde fysieke sequenciële thread. Dit wil zeggen dat onze Windows services op Windows Server steeds minder CPU-tijd in beslag nemen aangezien meer vCPU’s in de wachtrij staan. Daarmee kunnen we eveneens ook afleiden dat deze processen op zich niet zoveel overhead met zich meebrengen, maar dat bij de aanwezigheid van minder vCPU’s ervoor zorgt dat de fysieke kracht van onze CPU minder efficiënt zal verdeeld worden. Dit maakt Hyper-V al een veel sterkere concurent dan de testen op het eerste moment doen blijken. Voor parallelle taken zoals webservers of het draaien van zeer veel VM’s tegelijk. Het wordt echter ook al snel duidelijk dat onze “lightweight”

11

Hyper-V server hier bijna op de blacklist kan gezet worden. We zien namelijk dat we bij elke test ferm onder de Windows Server score zitten en dat deze relatie consistent is bij het schalen naar meerdere VM’s. In conclusie kunnen we stellen dat Esxi als duidelijke winnaar uit de bus komt wanneer we spreken over CPU-performance. Dit komt vooral door de kleinere overhead van de “lightweight” Esxi tov Windows Server of Hyper-V server. We zien echter wel dat deze overhead minder merkbaar is naarmate we meerdere taken tegelijk verwerken. Dit wil zeggen dat we in de meeste praktijksituaties (waarin veel VM’s een veelvoorkomende situatie is) we dit verschil nauwlijks nog zullen merken. Het is ook opmerkelijk dat Windows Server 2016 met Hyper-V een zeer grote performancewinst haalt tov de gratis lightweight Hyper-V server. Vanuit onze tests waar we deze vertraging bij vrijwel elk onderdeel zien kunnen we afleiden dat de hypervisor er veel langer over doet de fysieke middelen beschikbaar te stellen aan onze VM’s. Hoewel deze hypervisor gratis is, kunnen we deze niet aanraden voor een professionele omgeving waar het efficiënt gebruik van middelen cruciaal is voor de bedrijfsprocessen.

Grafische performance – de default situatie Wanneer we situaties bespreken waar grafische performance een grote rol speelt binnen het kader van virtualisatie, is onze lijst beperkt. Grafische performance is namelijk bedoeld voor zeer specifieke situaties die in vele gevallen zo zwaar zijn dat we deze niet willen virtualiseren uit angst voor een te grote performance loss of stabiliteit van ons systeem. Grafische elementen kunnen we meestal op de volgende manier renderen:  

Op de CPU Op een dedicated GPU of APU

Het renderen van geavanceerde grafische elementen is op zich één van de meest complexe procedures die onze computer afhandelt. Het proces is namelijk niet alleen zeer belastend voor de hardware, maar het parallelliseren van dit proces is een zeer complex probleem die voor vele rendertechnieken grotendeels nog steeds onopgelost blijft (denk maar aan Raytracing). Om de parallelle rendertaken een flinke boost te geven, wordt vaak gebruik gemaakt van een dedicated GPU of APU (in ons geval is dit een R9 390X). Wat echter een groot nadeel vormt is dat veel van deze videokaarten een OS-specifieke driver nodig heeft om optimaal te kunnen functioneren aangezien we standaard API-calls gebruiken om de videokaart aan te spreken. In de volgende testen nemen we een kijkje hoe onze virtualisatiesystemen omgaan met grafische taken op de VM’s. We moeten echter de volgende resultaten benaderen met de volgende kennis: onze Windows 10 client die rechtstreeks op de hardware draait maakt volledig gebruik van de R9 390X videokaart via de AMD Crimson driver (december 2015). Deze videokaart is DirectX (versie 12.0 feature level 2), OpenGL (versie 4.4), Vulkan (heden nog niet beschikbaar) en Mantle (AMD) enabled. Dit wil zeggen dat de volgende tests die gebruik maken van de DirectX API zeer vlotte access zullen krijgen op de videokaart. We maken hier gebruik van zowel Passmark 8.0 die een aantal DirectX testen zullen uitvoeren, alsook 3Dmark (Firestrike test) die ons systeem zal onderwerpen aan een zeer intensieve test voor zowel VRAM, GPU en CPU. We stellen als eerste meteen een driverprobleem vast bij het zoeken naar drivers voor onze virtualisatiesystemen. Omdat onze R9 390X nog steeds een consumentgerichte GPU is die speciaal is gemaakt voor games, zijn er geen drivers beschikbaar voor zowel Windows Server, Hyper-V server en Esxi. Dit wil zeggen dat de kans erg klein is dat we de GPU kunnen virtualiseren voor meerdere VM’s aangezien 12

dit proces zeer drivergebonden is. Wanneer we het probleem rond driversupport echter wat logisch bekijken, stoten we al snel op een interessante mogelijkheid binnen Hyper-V. Omdat Windows Server technisch gezien een serverlaag is die op een Windows NT kernel draait, kunnen we ervan uitgaan dat een normale Windows 10 driver hoogstwaarschijnlijk ook zal werken op Windows Server 2016 (we moeten echter wel onthouden dat dit geen officiële support is). Deze theorie lijkt in de praktijk ook perfect te kloppen. Wanneer we de Crimson driver installeren op onze Windows Server zien we niet alleen dat de installatie perfect mogelijk is, maar wanneer we een grafische benchmark vergelijken met onze Windows 10 client merken we ook dat deze driver op exact dezelfde manier werkt. We moeten echter realistisch denken vooraleer we beginnen aan onze grafische testen. Doordat onze GPU officieel niet ondersteund wordt op Windows Server 2016, is de kans uiteraard klein dat met de standaard instellingen deze kaart zal gebruikt worden voor grafische virtualisatie. We kunnen er dus vanuit gaan dat onze testresultaten, zelfs met de Crimson driver geïnstalleerd op onze Windows server dezelfde resultaten zullen opleveren als wanneer we geen enkele grafische driver installeren. Wanneer we onze grafische testen analyseren, zien we de volgende resultaten:

3D performance - Total 10000 8584

9000

8000 7000 6000 5000 4000 3000 2000

1000 59.5 46.7 48

53.9 30.8 30.4

85.7 46.3 48.8

Windows Server 2016 TP4

Hyper-V server 2016

Esxi 6.0

0

1 VM

2 VMs 1

Hardware

2 VMs 2

Zoals bij de CPU-benchmarks, omvat de totale score hier een groepering van alle onderliggende testen. In de volgende bespreking komen ongeveer alle testen op pagina 36 aan bod. Wat hier meteen opvalt is dat onze virtualisatie hier veel slechter presteert tov onze Windows 10 client die rechtstreeks op de hardware draait. We spreken hier namelijk van een factor 100 of meer. We kunnen er hier dan ook al snel vanuit gaan dat onze virtualisatiesystemen hier geen gebruik zullen maken van onze R9 390X voor het renderen, iets wat we ook hadden voorspeld. We gebruiken met andere woorden 13

onze CPU als GPU. Om onze vergelijking tussen Esxi en Hyper-V wat visueler voor te stellen, kunnen we beter kijken naar de grafieken zonder de Windows 10 client.

3D performance - Total 85.7

90 80 70 60

50

59.5 53.9 46.7

48

46.3

48.8

40 30.8

30.4

30 20 10 0 Windows Server 2016 TP4


2 VMs 1

Esxi 6.0

2 VMs 2

Wanneer we deze overzichtelijkere resultaten bekijken, zien we dat Windows Server en Esxi ongeveer gelijk scoren op praktrijksituaties. We hebben hier echter wel wat overhead bij het testen van 1 VM met 8 vCPU’s, wat eveneens te danken is aan onze onderliggende Windows services en processen. Let wel dat het uitschakelen van de GUI op Windows Server deze overhead niet in merkbare mate zal verminderen, we renderen hier onze GUI nog steeds op de R9 390X. We merken ook dat Windows Server beter scoort naarmate onze DirectX versie nieuwer is. Dit geeft aan dat naarmate onze grafische applicaties gebruik maken van nieuwere Microsoft gebaseerde API’s, Hyper-V op Windows Server interessanter wordt. We merken echter wel dat deze trend niet consistent is bij Hyper-V server, wat nogmaals doet vermoeden dat de hypervisor op Hyper-V server zeker niet dezelfde is als op Windows Server. We merken dat ook voor grafische toepassingen, Hyper-V server niet in de buurt komt van Windows Server en Esxi in het kader van performance. Let wel dat we hier zeer specifieke API-calls testen en we dus een praktijktest nodig hebben om de grafische performance effectief te gaan vergelijken. We kiezen hier voor 3Dmark. Deze DirectX gebaseerde test wordt namelijk veel gebruikt door gamers om hun grafische performance te testen. Hoewel de kans klein is dat we games in een virtuele omgeving gaan draaien, wil ik er wel even op wijzen dat games tot de zwaarste toepassingen behoren wanneer we spreken over API gebaseerd renderen. Deze test omvat ook een physics test, waar zowel CPU gerelateerde taken alsook grafische taken in één test worden uitgevoerd. We merken de volgende resultaten op:

14

3Dmark - total 52

51

50

48

46 44 44

42

40 Windows Server 2016 TP4

Esxi 6.0

We merken hier meteen op dat, hoewel Windows Server ongeveer hetzelfde scoort in passmark, we in een praktijksituatie toch iets lagere resultaten zien bij Windows Server. We zien dat dit grotendeels te danken is aan een kleine superieure framerate in de grafische testen. Wat we echter wel opmerken is dat Windows Server betere resultaten toont in de combinatietesten (zowel combined en physics test) waar we zowel grafisch renderen alsook fysica berekenen op dezelfde hardware (namelijk de CPU). Het feit dat we de vCPU’s hier gebruiken voor grafische en fysica gerelateerde berekeningen wordt ook mooi getoond in de physics test, waar we toch de helft halen in kracht tov onze Windows 10 client. Desondanks kunnen we vaststellen dat voor dergelijke taken zoals simulaties en animaties, onze virtualisatieplatformen niet voldoen aan onze eisen. Op de testen zelf, merken we op dat we hier enkel de DirectX API gebruiken als tolk voor onze grafische hardware. We kunnen redeneren dat, aangezien DirectX een Microsoft product is, onze Hyper-V hypervisor een stap voor heeft op Esxi. We virtualiseren namelijk hardware waarvan de performancebaseline zeer API- en drivergebonden is. Dit merken we uiteraard bij videokaarten op zich ook, een driver- of API-update kan namelijk zeer grote performance-impact hebben (denk maar aan de overhead van DirectX 12 tov 11). Om onze platformen dus zo objectief mogelijk te testen, willen we uiteraard ook weten hoe de OpenGL API presteert in benchmarks. We kiezen hier voor furmark om OpenGL op te testen. Deze testsuite wordt namelijk het meest gebruikt om de stabiliteit te testen van GPU’s. In theorie kunnen we de gemiddelde framerate van beide systemen vergelijken met elkaar om zo te weten welk platform de beste performance levert. In de praktijk zien we echter een heel ander verhaal. We merken namelijk dat onze testen niet eens willen starten op geen van onze drie hypervisors.

15

Figure 6 Error OpenGL

Deze error spreekt zonder uitleg al boekdelen, uiteraard kunnen we ook al snel de reden van deze error achterhalen. Ook de GFX-benchmark die meerdere OpenGL-versies ondersteunt, geeft bij elke OpenGL versie dezelfde error terug. Doordat we hier gebruik maken van drivers voor virtuele hardware, is het uiteraard logisch dat niet elke API wordt ondersteund. Wat echter wel opvallend is, is dat hoewel OpenGL een opensource API is, deze toch in veel mindere mate wordt ondersteund dan DirectX, een closed source API van Microsoft. We kunnen hieruit ook concluderen dat grafische toepassingen in Linux gebaseerde systemen zeer slecht, tot zelfs niet zullen draaien onder zowel Hyper-V als Esxi omdat Linux bijna uitsluitend deze API gebruikt voor grafische toepassingen. Dit kan echter snel veranderen in de toekomst met Vulkan. Omdat zowel Vulkan en DirectX 12 min of meer gebasseerd zijn op de Mantle API van AMD, een API die zelfs opensource is, is de kans zelfs groot dat we in de toekomst niet meer zullen botsen op dit soort fouten. Dit zal uiteraard slechts zo zijn wanneer de applicatie in kwestie gebruik zal maken van deze API-versies. In conclusie kunnen we stellen dat met de standaard instellingen op beide virtualisatiesystemen, de grafische performance te betreuren is. Dit heeft uiteraard veel te maken met het feit dat onze huidige hardware veel meer potentieel toont op onze Windows 10 client. Deze conclusie kunnen we met andere woorden uitsluiten bij de doorsnee server hardware, waar er meestal geen sprake is van de aanwezigheid van een GPU of APU. We kunnen ook concluderen dat hier enkel Windows Server 2016 en Esxi met elkaar kunnen concurreren, de performance van Hyper-V ligt namelijk een stuk lager en is zeker niet aan te raden voor grafische taken op API niveau. Merk ook dat we hier ook geen rekening hebben gehouden met speciale instellingen en mogelijkheden van onze virtualisatiesystemen. In de volgende sectie duiken we dieper in op de grafische virtualisatiemogelijkheden van elk platform.

Grafische performance – RemoteFX, PCI-passthrough en vSGA We merken na wat onderzoek dat elk platform een aantal troeven tot zijn beschikking heeft om de grafische performance wat te verbeteren. Beide platformen bieden dan ook een oplossing aan voor verschillende specifieke situaties waarin we willen gebruik maken van virtualisatie. We moeten echter wel 16

letten op een aantal factoren vooraleer we deze troeven kunnen toepassen zoals bv. driversupport en hardwareconfiguratie. Zoals besproken in de vorige testen, merken we dat zowel Hyper-V als Esxi standaard geen grafische hardware virtualiseren. Dit is grotendeels logisch aangezien deze hardware zeer driver gebonden is en in de meeste gevallen zal worden aangesproken met een set API’s. We kunnen in theorie onze hypervisor dus een eigen driver laten meegeven aan elke VM en deze een soort sandboxed omgeving geven op de onze hardware zelf. Dit proces wordt standaard al op verschillende soorten hardware toegepast (denk maar aan bv. storage) en geeft ons enerzijds de mogelijkheid om dezelfde hardware beschikbaar te stellen aan meerdere VM’s. Anderzijds kunnen we in theorie onze grafische kracht controleren per VM aangezien onze hypervisor als het ware de rol van grafische hardware op zich neemt. Het virtualiseren van hardware op deze manier wordt ook wel eens een abstraction layer genoemd. In de praktijk is dit echter niet efficiënt. Hoewel de moderne server CPU tot op heden slechts één algemene ISA hanteert, zien we dat dit bij grafische hardware volledig anders verloopt. We zitten hier namelijk niet met een eenheid van architecturen (denk maar aan Maxwell, Pascal, Iris, GCN, Kepler,…). Ongeveer elke nieuwe generatie GPU’s definieert als het ware een nieuwe taal die de hardware hanteert om bepaalde resultaten te bekomen. Dit wil zeggen dat om dit te kunnen virtualiseren, onze hypervisor al deze talen niet alleen moet kennen (dit gebeurt namelijk door de driver), maar ook een manier moet zoeken om deze hardware in een sanboxed environment beschikbaar te stellen aan de verschillende actieve VM’s. Dit is niet alleen zeer complex te implementeren, maar ook zeker niet schaalbaar. Bij elke nieuwe GPU architectuur zou namelijk een nieuwe hypervisor update moeten worden geschreven, deze update moet daarnaast ook op elk ondersteund OS werken. Het zou dus niet alleen zeer kostelijk zijn dit systeem te implementeren, maar ook om te onderhouden. We kunnen onze virtualisatie echter wel uitvoeren op API niveau. Aangezien elke architectuur een groot aantal API-sets ondersteund (DirectX en OpenGL zijn meestal aanwezig) en renderen met hardware acceleration grotendeels wordt gedaan met deze API’s, kunnen we alle API-calls op de grafische hardware opvangen op elke VM en deze op een efficiënte manier doorsturen naar onze GPU. Dit proces wordt ook wel eens API-redirection genoemd. Dit proces is niet alleen zeer modulair, aangezien we slechts een beperkte set API’s moeten ondersteunen, maar geeft onze VM’s ook een sandboxed environment aangezien renderAPI’s one-way zijn. Een ander voordeel is eveneens dat we vanop onze hypervisor de hardware gewoon verder kunnen gebruiken samen met de actieve VM’s. Dit systeem is echter verre van perfect. Een groot probleem waarmee we kampen is het gebruik van VRAM, we moeten er namelijk voor zorgen dat we niet over onze GPU limiet gaan, dit zou anders resulteren tot crashes van de grafische applicaties. Een ander nadeel waarmee we kampen is dat we controle verliezen over onze performance. We sturen namelijk vanop onze hypervisor een API-call gewoon door naar onze GPU. Zowel Windows Server als Esxi komen beiden met een vorm van API-redirection. Wanneer we APIredirection bekijken in Windows Server, stoten we op een Remote Desktop Service genaamd RemoteFX. Let wel dat aangezien dit onder de RDS categorie valt, we deze feature niet kunnen installeren op de gratis Hyper-V server. Je zal dan ook merken dat we hier enkel Windows Server en Esxi bespreken. RemoteFX is in de eerste plaats een API-redirection tool, maar biedt ook een set slimme algoritmes aan waardoor thin clients niet alleen minder belast worden, maar ook een scherper en smoother beeld krijgen in hun RDP-connecties. Deze service ondersteund de volledige DirectX library bij het virtualiseren van 17

GPU’s, plus een aantal specifieke OpenGL calls. Dit wil zeggen dat deze feature zeer interessant is wanneer we gebruik maken van DirectX applicaties, maar we beter applicaties die OpenGL gebruiken niet riskeren. Het wil ook zeggen dat elke GPU die DirectX enabled is met een driver voor onze Windows Server kan worden gebruikt voor onze VM’s. Hoewel enkel de professionele GPU’s van AMD (FirePro) en Nvidia (Quadro) officieel ondersteund worden voor Windows Server, hebben we eerder al gezien dat bijna elke Windows 10 ondersteunde GPU gebruikt kan worden. Dit geeft ons niet alleen de mogelijkheid om de R9 390X te gebruiken voor onze VM’s, maar dit wil ook zeggen dat Windows Server hier een serieus beentje voor heeft op Esxi in het kader van GPUondersteuning. Na de Crimson driver geïnstalleerd te hebben, kunnen we deze kaart ook registreren in Hyper-V als “RemoteFX enabled card”. Let wel dat RemoteFX slechts één GPU per host ondersteund. Dit wil zeggen dat AMD Crossfire en Nvidia SLI niet mogelijk zijn binnen Hyper-V, maar ook twee GPU’s die onafhankelijk van mekaar werken zijn niet toegelaten. Dit is enerzijds wel logisch aangezien onze VM’s hier als het ware rechtstreeks werken op de driver in onze hypervisor. Wanneer we onze GPU geregistreerd hebben als RemoteFX adapter, kunnen we deze instantiëren op onze VM’s. We worden hier ook gevraagd om een VRAM limiet in te stellen van maximaal 1024MB. Dit zal er uiteraard deels voor zorgen dat twee VM’s elkaar niet overlappen in VRAM gebruik. Let wel dat deze limiet niet automatisch zal schalen of rekening zal houden met andere actieve VM’s. in onze situatie waar we 8GB GDDR5 VRAM ter beschikking hebben, wil dat zeggen dat wanneer acht VM’s hun volledige 1024MB in gebruik hebben, er applicaties zullen crashen aangezien onze hypervisor ook VRAM in gebruik heeft. Uiteraard zal onze hypervisor ook geen rekening houden met deze limieten en aangezien hij zelf geen limiet heeft gekregen, is het dan ook niet aangewezen grafische applicaties op de hypervisor zelf te draaien terwijl VM’s gebruik maken van een remoteFX adapter. We creëren in de volgende test twee situaties. Enerzijds herbekijken we een aantal grafische tests met een remoteFX adapter op één VM om te zien hoeveel performance winst we nu eiglijk halen. Anderzijds zullen we deze testen ook schalen naar twee VM’s om te zien hoe de grafische performance schaalt. We hebben hier namelijk geen directe relatie met het tijdsslotenmodel van de vCPU’s. We krijgen de volgende resultaten te zien:

18


9000 8000 7000 6000 5000 4000 3000

1927 1662 1699

2000 1000

59.5

46.7

48

0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware

2 VMs 2

3Dmark - total 12000

11189

10000 8000 6000 4000 1490 1263 1140

2000 44 0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware

2 VMs 2

Wat meteen opvalt is dat onze DirectX performance meteen een stuk dichter komt bij onze Windows 10 client (10-20%). Dit lijkt op zich vrij weinig en we zien inderdaad nog steeds een zeer hoge overhead tov de fysieke mogelijkheden van onze hardware. Wanneer we echter kijken naar de schaling over meerdere VM’s, worden onze resultaten een stuk interessanter. Uiteraard zien we in vele situaties een performance drop tov onze configuratie met één VM, maar deze drop is echter veel te klein om ervan uit te gaan dat onze ene VM enkel door hypervisor overhead een relatief zwak resultaat behaalt. We zien zelfs een aantal situaties waarin onze performance zelfs stijgt bij de aanwezigheid van meerdere parallelle VM’s.

19

Om deze situatie logisch te benaderen, kunnen we het proces analyseren die onze tests zullen uitvoeren om tot een resultaat te komen. Vele applicaties die gebruik maken van hardware accelerated rendering maken namelijk nog steeds gebruik van een standaard systeem. Hieronder kunnen we een grafische voorstelling zien om onze analyse visueel bij te staan:

Figure 7 Gameloop

We onderscheiden met andere woorden twee aparte processen. Enerzijds zullen we een bepaalde logica berekenen, deze CPU berekeningen zullen bv. bepalen waar bepaalde objecten zich bevinden, hoe ze geschaald zijn, in welke hoek onze camera zich bevindt, etc. Het is belangrijk dat dit om een CPU-intensief proces gaat en deze dus ook de vCPU gerelateerde regels zal volgen. In de tweede fase zullen we het beeld van de Gamelogic fase gaan renderen, dit proces bestaat erin dat we de renderAPI’s zullen aanspreken om een bepaald object te renderen op een bepaalde resolutie. Dit proces is dus deels CPU-intensief, maar zal grotendeels worden uitgevoerd door de GPU. We moeten er ook op letten dat dit proces in een sandboxed omgeving moet draaien, we willen bijvoorbeeld niet dat een beeld die wordt uitgevoerd door een VM rechtstreeks op ons scherm zal terecht komen. Onze hypervisor moet met andere woorden deze API-calls sturen zodat zijn eigen renderproces niet in de war komt. In conclusie kunnen we dus twee vaste delays onderscheiden. Enerzijds volgen we nog grotendeels het tijdsslotenmodel dat eerder werd besproken, dit wil zeggen dat theoretisch gezien onze framerate sterk zal afhangen van onze vCPU opstelling en niet zozeer van onze GPU. Omdat deze vCPU’s dynamisch kunnen schalen door onze Hardware Accelerated Virtualisation, stellen we uiteraard een zeer efficiënte schaling vast bij vele testen omdat de gamelogic meestal slechts twee of drie threads in beslag zal nemen. We kunnen die ook goed zien in de physics test, waar we geen performance drop vaststellen wanneer we schalen naar meerdere VM’s. Uiteraard hebben we bij het draaien van slechts één VM al te maken met een zeer grote overhead. Dit is op het eerste zicht niet erg logisch aangezien onze vCPU’s dynamisch schalen. We kunnen echter wel vaststellen dat in vorige tests onze CPU overhead bijzonder hoog ligt bij

20

het draaien van slechts 1 VM. Hoewel dit zeker zal helpen in de performance drop, kunnen we dit uiteraard niet als enige oorzaak zien. We moeten ons echter wel bewust zijn van het feit dat een GPU zich redelijk autonoom gedraagt. Dit wil zeggen dat deze in staat is een volledig beeld te renderen zonder tussenkomst van extra code of de CPU in het algemeen. Dit wil zeggen dat als we nood hebben aan een soort synchronisatieproces op onze hypervisor om te voorkomen dat het renderproces van onze VM’s in de weg zullen staan met onze hypervisor of andere VM’s. Dit wil zeggen dat onze framerate eveneens sterk zal afhangen van de beslissingen die de hypervisor neemt, wat in de eerste plaats zeer negatief lijkt voor onze VM performance. Uiteraard wil dit ook zeggen dat onze VM’s in complete isolatie kunnen bestaan tov elkaar en met onze hypervisor, wat wil zeggen dat de renderprocessen van zowel de VM’s als de hypervisor elkaar niet zullen beïnvloeden, wat dus een zekere stabiliteit geeft. We zien dan ook dat we steeds efficiëntere resultaten krijgen naarmate we meer VM’s gebruik laten maken van RemoteFX, wat eveneens veel efficiëntie zal geven in realistische praktijkscenario’s. Deze scenario’s zijn jammer genoeg redelijk gelimiteerd. Hoewel het handig is om een GPU te virtualiseren over meerdere VM’s, hebben we weinig controle over hoe de middelen worden verdeeld. In vele praktrijksituaties waar hardware accelerated rendering nodig is, zien we dat het efficiënter is om praktisch alle middelen beschikbaar te stellen aan één proces, aangezien de kans redelijk klein is dat alle VM’s constant moeten renderen. We stellen bijvoorbeeld een rendersituatie voor waar drie VM’s aanwezig zijn die elk een verschillende rendertaak op zich nemen. Een groot deel van de situaties zal machine A bijvoorbeeld een taak op zich nemen, en na een periode machine B of C. Hoewel het efficiënter zou zijn wanneer we machine A alle middelen geven zodat deze de taak zo snel mogelijk kan vervolledigen, is deze bij RemoteFX beperkt tot een zeer limiterende set van middelen. Dit maakt het geheel onnodig traag. Het feit dat we ook maximaal slechts 1024MB VRAM kunnen voorzien per VM sluit eveneens zeer intensieve taken uit. High memory assets en hoge resoluties zijn dus eveneens uitgesloten bij het gebruiken van RemoteFX. De grootste teleurstelling is uiteraard dat onze applicaties gelimiteerd zijn tot DirectX, bij het testen van meerdere OpenGL applicaties (blender, autoCAD, World of goo, GFX,…) stellen we crashes, freezes, etc vast of gewoon de tekortkoming van hardware accelerated rendering. Ook bij Linux systemen zoals Ubuntu zien we geen verschil in benchmarkresultaten wanneer we RemoteFX instellen. In een professionele omgeving (zoals bijvoorbeeld renderfarms) zien we dan ook dat er meestal gebruik wordt gemaakt van speciale drivers en API’s (denk maar aan VRay en IRay) om zeer hoge kwaliteitsbeelden te renderen. Deze zullen uiteraard ook niet ondersteund worden in RemoteFX. DirectX lijkt echter wel zeer vlot te werken (met uitzondering van games). Aangezien deze technologie ook perfect werkt met RDP, kunnen we een situatie waar Photoshop werk wordt gedaan op thin clients als realistisch beschouwen. Dit wil zeggen dat we als systeembeheerder enkel moeten investeren in een één centrale locatie, wat serieus wat tijd en geld bespaart. Ook het feit dat we een consumenten GPU kunnen gebruiken is eveneens een zeer groot voordeel. Niet alleen omdat deze kaarten goedkoper zijn, maar deze zijn eveneens op vele vlakken performanter dan professionele kaarten wanneer API’s zoals DirectX worden gebruikt. In het andere kamp biedt Esxi ook GPU virtualisatie aan met hun vSGA technologie. vSGA gebruikt de eerder vermelde abstraction layer. Uiteraard wil dit in de eerste plaats zeggen dat ondersteunde API-set 21

hier duidelijker breder zal zijn dan wat we zagen bij RemoteFX. We zullen dus met andere woorden meerdere soorten applicaties toegang kunnen geven tot onze GPU. Hierdoor zullen ook Linux systemen meer middelen ter beschikking krijgen, dus zijn we niet beperkt tot één bepaald systeem omdat deze als enige een API gebruikt. Aan de andere kant is de hardwaresupport bij Esxi zeer teleurstellend, slechts enkele professionele kaarten worden ondersteund. In de volgende lijst kunnen we een kleine opsomming zien:          

AMD FirePro S4000X AMD FirePro S7000 AMD FirePro S9000 AMD FirePro S9050 AMD FirePro W7000 GRID K1 kaarten GRID K2 kaarten Tesla M6 Tesla M60 HD Graphics P4700

We zien dat hier enkel workstation- en serverkaarten worden ondersteund. Uiteraard zijn deze kaarten ook een pak duurder dan onze R9 390X die we reeds gebruikten voor onze vorige tests. Het is ook belangrijk dat we opmerken dat de ondersteunde Nvidia GPU’s allemaal GRID ondersteunen. GRID is een GPU virtualisatietechnologie ontwikkeld door Nvidia zelf. De kans is groot dat deze technologie die werd ontwikkeld door de GPU-fabrikant zelf, veel hogere performance en support zal genieten dan de algemene abstraction layer van VMware. Wanneer we deze abstraction layer technisch benaderen, stellen we enerzijds een aantal grote voordelen alsook nadelen vast tov de RemoteFX technologie. Het eerste grote voordeel is dat Esxi de verantwoordelijkheid voor vSGA support veel zal leggen bij de GPU-vendor. Onze GPU fabrikant moet met andere woorden zelf vSGA support injecteren in hun drivers. Deze zullen dan via een speciale driver in VMwaretools doorgevoerd worden naar de client. Dit wil zeggen dat onze beschikbare API-set dezelfde zal zijn die op de GPU wordt ondersteund, wat op zich een groot voordeel biedt over RemoteFX waar we grotendeels beperkt waren tot DirectX. We zien uiteraard ook snel de keerzijde van deze keuze hierboven wanneer we de beschikbare hardware voor deze technologie opsomden. Het beperkte aantal modellen is niet alleen veel duurder dan onze consumentenvarianten, maar zijn meestal ook zeer beperkt in kracht. We zien namelijk dat wanneer we de FirePro S9050 vergelijken met onze R9 390X, onze consumentenkaart bijna drie keer zo snel (3.23 TFLOPS tov 8.6 TFLOPS) is in fysieke kracht terwijl deze slechts 25% van de prijs bedraagt. We moeten er hier echter wel bij melden dat het kiezen van een professionele workstation of serverkaart vele voordelen met zich meebrengt. Zo zien we bijvoorbeeld dat de S9050 professionele zaken aanbiedt zoals ECC memory, extended support, low power consumption en speciale drivers voor zowel Windows Server, Esxi en Citrix Xenserver. Aan de andere kant kunnen we er ook vanuit gaan dat deze kaarten ook grotere performancewinst zullen bieden op RemoteFX aangezien deze technologie ook officieel ondersteund worden door de vendor. Omdat we geen GPU uit bovenstaande lijst ter beschikking hebben, kunnen we het performance verschil tussen hardware clients en vSGA uiteraard niet testen. We kunnen enkel afgaan op speculaties en

22

testresultaten van derden. Deze resultaten zijn zeer beperkt. We vinden namelijk geen enkele objectieve vergelijking die ons de overhead toont van de virtualisatietechniek die Esxi hier hanteert. We zien echter aan de hand van gelezen opinies en testen uitmaken dat Hardware Acceleration vrij goed werkt op de meeste professionele workloads. Er zijn echter twee benchmarks die zeer interessante resultaten geven. De benchmarks in kwestie werden genomen door Gunnar Berger, CTO van Citrix’s Desktop and Apps group. Zijn benchmarks vergelijken grotendeels de vSGA technologie op Esxi tov Nvidia’s GRID technologie op Xenserver in performance en grafische resultaten. Het is ook belangrijk om te weten dat deze benchmarks werden genomen eind 2013. Dit wil enerzijds zeggen dat deze tests draaiden op een Esxi 5.5 host, wat dus een ouder systeem is dan wat we hier behandelen. Anderzijds kunnen we ook afleiden dat, aangezien Gunnar Berger pas in 2014 bij Citrix aan de slag ging, we hier min of meer ook te maken hebben met een objectieve vergelijking. Voor deze testen voerde hij zowel de Heaven DirectX benchmark uit, alsook een CAD performance benchmark voor real time rendering, wat gebruik maakt van de OpenGL API. We kunnen de volgende eindresultaten waarnemen:

vSGA vs vGPU - CAD 3000

2647

2500 2000 1500 1000 500 73 0 Vmware vSGA

Nvidia vGPU

vSGA vs vGPU - Heaven 800

704

700 600 500 400

300 200 100

70

0 Vmware vSGA

Nvidia vGPU

We kunnen al snel zien dat de virtualisatietechnieken van Nvidia hier zeer superieur zijn tov de deze in vSGA. We zien dat we ook in het verloop van de benchmark stoten op heel wat grafische fragments en 23

glitches in onze resultaten, dit wil grotendeels zeggen dat we niet alleen een teleurstellende framerate krijgen bij het werken met vSGA tov vGPU, maar dat redelijk wat API calls en API-specifieke materialen niet worden ondersteund in vSGA. Sinds Esxi 6.0 wordt Nvidia’s vGPU technologie ondersteund in Esxi. Dit wil zeggen dat we niet alleen de volledige performancewinst van vGPU nu ook kunnen verkrijgen in Esxi, maar dat wanneer we GPU’s willen virtualiseren in Esxi, we veel betere performance zullen halen met Nvidia GPU’s dan dat we kunnen krijgen met AMD GPU’s aangezien vGPU zeer architectuurgebonden is en een Nvidia technologie is. We draaien namelijk de officiële GPU-driver op onze VM’s. Dit wil zeggen dat deze driver speciaal werd ontworpen om het delen van grafische performance mogelijk te maken, maar ook dat we op die manier de grafische overhead elimineren die bij vSGA in zeer grote mate aanwezig is. We merken ook dat vSGA een zeer grote beperking oplegt in ons API-gebruik. We kunnen dit enerzijds al merken in onze grafische resultaten waar glitches en fragments regelmatig opduiken. Na vSGA wat nader te hebben bekeken, zien we dat enkel de API-versies DirectX tot versie 9.0c en OpenGL tot versie 2.1 ondersteund worden. We kunnen hier dan ook met volle overtuiging afleiden dat we bij het virtualiseren van GPU’s, vSGA beter vermijden en andere alternatieven bestuderen. Esxi biedt echter nog een derde mogelijkheid aan om onze GPU performance door te voeren. We kunnen namelijk onze hardware direct linken met onze VM’s. Dit is perfect mogelijk aangezien onze GPU zeer onafhankelijk werkt tov de andere hardware in ons systeem. We hebben hier met andere woorden te maken met een Request Response systeem waar onze CPU taken doorgeeft aan onze GPU en de resultaten weer kan ontvangen. Bij het proces van PCI-passthrough of sDGA, zullen we onze hardware dus meteen beschikbaar stellen aan onze VM’s zonder enige tussenkomst van onze hypervisor. Dit wil zeggen dat we de factor van welke hardware er effectief ondersteund wordt verleggen naar onze VM-OS’s. We kunnen namelijk perfect onze R9 390X beschikbaar stellen aan een Windows 10 VM zonder enige vorm van hypervisor overhead te creëren. We zien hier uiteraard al aankomen dat we onze hardware met deze techniek niet beschikbaar kunnen stellen aan meerdere VM’s tegelijk omdat we hier geen speciale drivers voor hebben. Dit process wordt We kunnen dan ook niet zeggen dat het hier om hardware virtualisatie gaat, maar eerder passthrough. Om sDGA te laten werken hebben we nood aan een CPU die ofwel Intel VT-d support, of AMD IOMMU. Hier voldoet onze 3770K processor uiteraard niet aan aangezien dit een consumentenprocessor is. Onze Xeon e5630 ondersteund dit uiteraard wel, maar daar botsen we op de afwezigheid van de nodige 6-pin connectoren om een videokaart van genoeg stroom te voorzien, de 860Wh voeding in dit systeem is ook niet modulair, waardoor we deze kabels ook niet zelf kunnen aanbrengen. In principe is het eveneens overbodig sDGA te testen aangezien onze VM volledig beheer heeft op de GPU. Dit wil zeggen dat de enige overhead waarmee we hier zullen kampen zal komen van de vCPU’s of de driversupport van onze VM zelf. In conclusie kunnen we hier geen duidelijke winnaar aanduiden. We kunnen echter wel Hyper-V server opnieuw aanduiden als slechtst presterende systeem door gebrek aan een GPU-virtualisatietechnologie. Enerzijds zien we dat grafische performance een zeer ingewikkeld geheel vormt en dat virtualisatie bij deze systemen zeer beperkt is. Zowel Hyper-V in Windows Server als Esxi bieden beiden een aantal technologiën aan die zeer situatiespecifiek zijn. 24

Als eerste kunnen we slechts twee GPU-virtualisatiesystemen onderscheiden, namelijk RemoteFX en vSGA (en vGPU). We stellen al meteen vast dat Hyper-V hier de voorkeur krijgt in het kader van hardwaresupport doordat theoretisch gezien elke Windows 10 GPU-driver zou moeten werken op Windows Server 2016. Doordat RemoteFX slechts een API redirection tool is en enkel optimaal werkt in DirectX applicaties, hebben we slechts weinig situaties waarin deze technologie bruikbaar wordt. We stellen Remote Desktop applicaties als meestvoorkomende situatie. We zien ook dat RemoteFX veel crashes veroorzaakt wanneer we overlapping creëeren in onze VRAM settings. Dit geeft ook als bijkomend nadeel dat we onze RemoteFX adapters niet zo flexibel kunnen schalen en dat zware taken een zeer grote overhead krijgen door gebrek aan fysieke middelen. We zien wel dat deze technologie vrij goed schaalt naarmate meer VM’s hiervan gebruik maken. Esxi kunnen we beter adviseren voor zeer specifieke professionele situaties. We moeten hier echter wel vermelden dat vSGA niet aan te raden is door de API-limitaties en grote overhead naar onze VM’s toe. We spitsen ons dus beter toe op de vGPU technologie van Nvidia. Dit komt omdat we hier eveneens nood hebben aan dure server- of workstationhardware om virtualisatie mogelijk te maken, en we zeer weinig performance winst behalen in vSGA dan wanneer we dezelfde testen ondernemen op vGPU. Dit wil zeggen dat Nvidia hardware hier interessanter zal zijn dan AMD. Wanneer we zeer zware hardware accelerated testen willen ondernemen (bv Iray renderen) terwijl we andere VM’s willen draaien op dezelfde CPU, kiezen we hier ook beter voor Esxi met hun PCI-passthrough ondersteuning. We kunnen hierdoor de volle capaciteiten van onze GPU doorvoeren naar onze VM zonder enige vorm van overhead, wan uiteraard interessant zal zijn voor zware GPU-applicaties.

Memory en Storage In veel servergerelateerde situaties zullen RAM en storage performance een zeer grote rol spelen. Dit zijn namelijk twee van de traagste componenten in ons systeem, maar zijn ook onmisbaar wanneer we data (al dan niet blijvend) willen opslaan en verwerken. Wanneer we de RAM performance testen op onze systemen, kunnen we volgende resultaten waarnemen:

RAM - total 3000 2000 1500

2615

2386

2500

1913 1870 1518 1194 1175

1191

1045 1036

1000 500 0

Windows Server 2016

Hyper-V Server 1 VM

Esxi

2 VMs 1

Hardware

2VMs 2

Uiteraard kijken we hier opnieuw naar een aantal deelcategoriën om tot een objectieve conclusie te komen.

25

We kunnen hier opnieuw de volgorde van onze vorige testen waarnemen. Esxi lijkt hier opnieuw het hoogst te scoren bij vrijwel elke test, gevolgd door Windows Server 2016 en als laatste Hyper-V server. We kunnen ook merken dat Esxi hier veel stabieler zal schalen wanneer we meerdere VM’s tegelijk laten draaien. Ook de overhead bij het schalen naar meerdere VM’s lijkt hier in mindere mate voor te komen bij Esxi dan bijvoorbeeld Windows Server en vooral ook Hyper-V server. Wat ook opvalt is dat bij het lezen van de CPU caches, Hyper-V server hier zwaar moet onderdoen aan zowel Esxi en Windows Server (we spreken over een 50% performance drop). We kunnen stellen dat dit een bijproduct is van de al onderpresterende CPU benchmarks die we eerder al vaststelden bij Hyper-V. we kunnen ook een algemene performance drop zien op Hyper-V (zowel Windows Server als Hyper-V server) wanneer we naar uncached tests kijken. We zien dat we enerzijds te maken hebben met een relatief kleine overhead bij één VM in Windows tov Esxi, maar ook dat onze performance veel beter zal schalen wanneer meerdere VM’s ons uncached memory zullen uitlezen. Deze schaling is enerzijds te wijten aan de overhead die we waarnemen bij het draaien van één VM. Dit wordt wellicht beïnvloed door de RAM access die de standaard Windows Server processen ondernemen. We kunnen ook afleiden dat Esxi slimmer gebruik zal maken van de beschikbare RAM modules om de memory access times per VM te verminderen. Dit zien we terug in zowel elke test buiten deze de niet RAM intensief zijn (de cache testen). We testen hier ook een veel voorkomende praktijksituatie, namelijk de RAM performance wanneer we een aantal database operaties doorvoeren. We zien ook hier dat Esxi zich op de eerste plaats bevindt met een serieuze voorsprong op Windows Server (bijna een verdubbeling). Hyper-V server scoort hier zeer slecht, maar komt dichter in de buurt van Windows Server wanneer we schalen naar meerdere VM’s. We merken ook dat database operaties zeer mooi schalen in Hyper-V server met bijna geen extra overhead tov één enkele VM. Esxi lijkt hier wel niet zo stabiel te schalen als Hyper-V. We merken namelijk dat er bij enkele tests met ongeveer 50% verschil te maken hebben tussen de twee VM’s, iets wat bij Hyper-V grotendeels een 5050 verhouding oplevert. Hyper-V levert ons ook de mogelijkheid om de prioriteit van memory operaties op elke VM’s te definiëren, iets wat niet direct mogelijk lijkt te zijn in Esxi (waar dit enkel per share kan worden gedaan). Dit geeft Hyper-V de mogelijkheid QoS beter te beheren dan Esxi met name RAM performance. In conclusie stellen we echter dat in de praktijk Esxi opnieuw als winnaar moet worden gekroond. Dit komt vooral door de standaard overhead die niet aanwezig is op Esxi, maar wel op Hyper-V. Ook bij database operaties (wat zeer veel gevirtualiseerd voorkomt) merken we dat Hyper-V hier ook serieus wat lager scoort tov Esxi. Hyper-V server lijkt hier opnieuw als laatste uit de bus te komen, door een serieuze overhead tov zowel Windows Server als Esxi. We merken ook op dat zowel Windows Server en Hyper-V server beiden veel stabieler zullen schalen in RAM performance dan Esxi, waar we soms 50% verschillen opmerken tussen VM’s. Wanneer we over storage performance spreken, moeten we rekening houden dat we hier te maken hebben met twee grote soorten hardware: namelijk HDD’s en SSD’s. Beide types zullen zich uiteraard anders gedragen bij verschillende tests en schalingen. HDD’s zullen bijvoorbeeld gevoeliger zijn aan IOPtesten terwijl SSD’s hier bijna geen last van zullen hebben. Dit zal ons uiteraard twee verschillende schalingspatronen geven.

26

We voerden onze storage tests (sequencial read, sequencial write, IOPs) uit op zowel een SSD (Samsung 850 evo) als op een hardware RAID10 setup met acht 7200rpm disks. We kunnen de volgende resultaten opmerken:

storage - total SSD 3000 2630

2536 2331

2500

2085 2000

1741

1673 1483

1500

1177

1145 965



2 VMs 1

Esxi 6.0

Hardware

2 VMs 2

storage - total HDD 3000 2581 2500 2073 2000

1500

1225 980.4

1000

500

435.1

880 481.4

380.3

435.1

133.6 0 Windows Server 2016 TP4


2 VMs 1

Esxi 6.0

Hardware

2 VMs 2

We merken meteen op dat onze Windows 10 client het hier slechter doet dan alle geteste virtualisatiesystemen op zowel SSD’s als HDD’s. Dit wil duidelijk zeggen dat we bij zowel Hyper-V als Esxi gebruik zullen maken van buffers om zo de disk performance van onze VM’s te vergroten. Dit zal uiteraard 27

als effect hebben dat onze geheugenperformance hieronder zal leiden, aangezien we deze meer zullen belasten voor elke storage request. We merken ook dat Hyper-V veel beter scoort in elke test (met Windows Server op kop), we kunnen dus afleiden dat deze hypervisor ook meer gebruik zal maken van buffers dan Esxi. Dit zien we niet alleen in onze write operaties, maar ook bij het lezen van de schijf, dit wil hoogstwaarschijnlijk zeggen dat Hyper-V een grotere buffer zal voorzien dan Esxi voor storage operaties. Dit is ook te merken bij de RAM-testen, waar Esxi beter scoorde in geheugenperformance omdat deze de RAM minder zal belasten door kleinere buffers. Dit geeft, hoewel we over het algemeen betere performance zullen halen met veel actieve VMs, een groot nadeel. Omdat onze VM deze buffers ziet als effectieve storage, hebben we geen failover wanneer we met een plotse stroomuitval zitten. Dit wil zeggen dat ons systeem bij uitval een kleine kans heeft corrupt te raken door incomplete storage operaties. Deze kans is uiteraard zeer klein aangezien we in de meeste gevallen ook een UPS zullen hebben staan indien we met een stroompanne zitten. Het feit dat we onze VM’s eigenlijk oplichten door ze te laten denken dat onze buffer de storage is, wil ook zeggen dat het niet efficiënt zal zijn om nogmaals te cachen in onze VM zelf aangezien we dan grotendeels dezelfde operatie tweemaal uitvoeren. We merken ook dat deze buffer onze read performance zal verbeteren, wat dus wil zeggen dat we in een virtuele omgeving onze applicatiecaches grotendeels mogen disablen. We kunnen deze buffer ook per VM regelen via een percentageslider in de memory settings. Deze staat standaard op 20% van het toegewezen geheugen voor die VM. De buffergrootte is niet meteen controleerbaar in Esxi (eveneens mogelijk via een share). We kunnen echter wel bij zowel Hyper-V als Esxi instellen hoeveel IOP-range elke VM-disk mag krijgen. Dit geeft ons de mogelijkheid om bepaalde VM’s robuster te maken dan andere. Let wel dat HDD’s hier veel gevoeliger zijn aan IOP’s dan SSD’s. Dit zien we ook aan de storage performance resultaten waar schalen naar meerdere VM’s stabielere resultaten geeft bij onze SSD dan onze RAID 10 HDD’s. In conclusie kunnen we stellen dat met de default opties in beide systemen, Hyper-V hogere performance geniet met name storage. Dit gaat uiteraard ten koste van RAM performance en veiligheid aangezien hier veel wordt gebufferd naar het geheugen. Zowel Hyper-V als Esxi leveren beiden management over zowel RAM als storage, maar voor simpele VM-configuraties lijkt Hyper-V simpeler om geheugen- en storageperformance te tweaken. Aan de andere kant zullen de administrative tools in Esxi veel overzichtelijker zijn naarmate onze VM-stack groter wordt.

28

H3 – Conclusie Inleiding Vooraleer we overgaan tot de eindconclusie, moeten we echter merken dat deze vergelijking enerzijds wegens tijdsgebrek zeer beperkt is. Zowel administratie, security, failover,… kwamen hier namelijk niet aan bod. Deze factoren zijn zoals Performance ook zeer diepgaand, waardoor we dit onderzoek nog zeker kunnen verviervoudigen in lengte wanneer we ze zouden onderzoeken. Door een relatief diepgaand onderzoek in performance kunnen we echter wel min of meer besluiten in welke virtualisatieoplossing in een bepaalde situatie het meest geschikt is en waarom.

Kostprijs Wanneer we enkel kostprijs in rekening brengen, hebben we hier meteen te maken met een licentiemodel tov een Price per Unit model. We merken enerzijds dat Hyper-V veel goedkoper is voor kleinere netwerken wanneer we features zoals RemoteFX nodig hebben die enkel aanwezig zijn in Windows Server. Ook het feit dat we gratis zoveel Hyper-V server nodes kunnen opzetten als we maar willen en deze vanuit één centraal punt kunnen beheren, maakt Hyper-V een zeer interessante oplossing voor KMO’s. We merken ook dat wanneer we geavanceerde grafische kracht nodig hebben voor DirectX applicaties, we veel goedkopere hardware kunnen aanschaffen dan is vereist in Esxi, wat ideaal is voor organisaties die kleine grafische toepassingen willen draaien op één centrale hardwareset. Doordat Esxi echter met een licentiemodel werkt, kunnen we ervan uitgaan dat voor grote ondernemingen Hyper-V minder interessant wanneer we geavanceerde mogelijkheden nodig hebben. Windows Server mag namelijk per licentie slechts één maal worden geïnstalleerd op een fysieke machine. Hoewel de Hyper-V server gratis is, botsen we hier nog regelmatig op beperkingen in featureset alsook performance, iets wat van groter belang is bij grotere organisaties.

Performance In conclusie zijn de meningen op vlak van performance wat verdeeld. Beide systemen leveren degelijke performance over het algemeen. We merken wel dat Hyper-V hier in vele gevallen tekortschiet tov Windows Server en Esxi. Wanneer performance een grote rol speelt kunnen we Hyper-V server moeilijk aanbevelen door deze beperkingen. Op vlak van grafische performance kunnen we niet anders dan Esxi als winnaar te kronen. Let wel dat het virtualiseren van GPU’s hier enkel de voorkeur geniet wanneer Nvidia kaarten worden gebruikt. AMD is namelijk zeer gelimiteerd in performance over zowel één als meerdere VM’s. Windows Server met Hyper-V biedt hier echter wel een zeer interessante optie aan voor hardwarevirtualisatie. Jammer genoeg zijn er door beperkingen in API-support niet veel situaties waarin we deze technologie kunnen gebruiken. Dit maakt de meeste professionele toepassingen niet haalbaar met RemoteFX. het is eveneens jammer dat PCI-passthrough niet wordt ondersteund in Hyper-V. We merken dat beide systemen heel wat features aanbiedt waarmee we de performance kunnen tweaken zoals buffergrootte, RAM priority,… Hyper-V benadert deze opties echter veel simpeler dan Esxi wanneer we kleine VM-opstellingen moeten beheren. We merken dat Esxi met hun Hiërarchisch systeem zeer handig zal zijn in grote opstellingen.

29

Algemene conclusie Zoals doorheen dit document al snel blijkt, kunnen we hier niet meteen één keuze maken die in alle situaties zal gelden. We moeten met andere woorden naar de noden van de gebruiker kijken om zo tot de meest efficiënte keuze te komen. Aangezien onze vergelijking zich hier beperkt tot performance, en niet zozeer tot andere factoren, kunnen we onze conclusie ook enkel beperken tot die factor. We merken wel tijdens onze testen dat Esxi hier zeker is gemaakt met grote organisaties in gedachten. Dit vormt zowel een voor als nadeel. We kunnen stellen dat voor KMO’s Hyper-V hier over het algemeen de betere optie is. Niet alleen kunnen we virtualisatie combineren met andere Windows Server features, maar ook het beheren van een beperkte set VM’s gaat een stuk vlotter dan in Esxi. Wanneer we echter schalen naar grotere ondernemingen, merken we beheer in Hyper-V steeds repetitiever en lastiger wordt door de afwezigheid van globale instellingen op bepaalde clusters. Esxi lijkt meer opgewassen te zijn voor dit probleem met features zoals Share-instellingen. Er is echter veel meer onderzoek nodig om een gegronde conclusie samen te stellen omtrent dit probleem.

30

Bijlagen CPU-performance


10681

9113

8000

6943 6955 6061

6000

6228 5540 4437 4391



2 VMs 1

Esxi 6.0

Hardware

2 VMs 2


9113

8000

6943 6955 6061

6000

10681

6228 5540 4437 4391



2 VMs 1

31

Esxi 6.0 2 VMs 2

Hardware

CPU-performance floatin point 10000

8000

8601

8578

9000

7828

7704

7000 6000 5000

5566

5418

5165 4266

3992 3802

4000 3000 2000 1000 0 Windows Server 2016 TP4


2 VMs 1

Esxi

Hardware

2 VMs 2

CPU-performance prime number 35 31.2 29.4

30

25

24.9 23.2

23.1

19.8

20 16 15.7 15

13.9 13.5

10

5



Esxi

2 VMs 1

32

2 VMs 2

Hardware

CPU-performance extended instructions 60

53.1 50

49.4

47.6

40 32.8

32.4

34.5

29.6

30

26.1 21.3 21

20

10



Esxi

2 VMs 1

Hardware

2 VMs 2

CPU-performance Extended Instructions 60 53.1 50

49.4

47.6

40

32.8 30

32.4

34.5

29.6 26.1 21.3 21

20

10



Esxi

2 VMs 1

33

2 VMs 2

Hardware

CPU-performance compression 18000 15345

16000 14000

15335

13723

12000 10000

9139

8684

8458

9743

7547

8000

6137 6000

5561



2 VMs 1

Esxi

Hardware

2 VMs 2

CPU-performance encryption 2500 2130

2094 2000

1968

1500

1277

1261

1088 1036 1000

1050 767 747

500



2 VMs 1

34

Esxi 2 VMs 2

Hardware

CPU-performance physics 600

569

550

503 500 422.4 400 313.2 281.5

300

259.6

275.5

274

245.7

200

100



Esxi

2 VMs 1

Hardware

2 VMs 2

CPU-performance sorting 10000 9000

8620

8588 8087

8000 7000

6000 5000

5404 4548

4259

4000

4236

4556

3211 3020

3000 2000 1000 0 Windows Server 2016 TP4


2 VMs 1

35

Esxi 2 VMs 2

Hardware

CPU-performance single threaded 2500

2319 2286 2296

2328

2116 2077 2000 1627 1500

900 925 925

1000

500



2 VMs 1

36

Esxi 2 VMs 2

Hardware

GPU-performance - default


9000 8000 7000 6000 5000 4000 3000 2000 1000

59.5 46.7

48

53.9 30.8 30.4

85.7 46.3 48.8

Hyper-V server 2016

Esxi 6.0


1 VM

2 VMs 1

Hardware

2 VMs 2

3D performance - Total 85.7

90 80 70 60 50

59.5 53.9 46.7

48

46.3

40 30.8

30.4

30



2 VMs 1

37

2 VMs 2

Esxi 6.0

48.8

3D performance - DirectX 9 Simple 600 528 500 400

300 200 100 2.3

5.2

2.99 1.46 1.48

2.25 2.39

2.64 2.64



Esxi 6.0

2 VMs 1

Hardware

2 VMs 2

3D performance - DirectX 9 Simple 6 5.2 5 4 2.99 3 2.3

2.25

2.64

2.39

2

1.46

1.48

1 0 Windows Server 2016 TP4


2 VMs 1

38

2 VMs 2

Esxi 6.0

2.64

3D performance - DirectX 9 Complex 200 175.8

180 160 140 120 100

80 60 40 20

1.61 1.4

1.4

1.57 0.92 0.87

2.32 1.43 1.42

Hyper-V server 2016

Esxi 6.0


1 VM

2 VMs 1

Hardware

2 VMs 2

3D performance - DirectX 9 complex 2.5

2.32

2 1.61 1.5

1.57 1.4

1.43

1.4

0.92

1

0.87

0.5



2 VMs 1

39

2 VMs 2

Esxi 6.0

1.42

3D performance - DirectX 10 160 143.5 140 120 100 80 60 40 20 1.68 1.05 1.03

1.21 0.77 0.75

1.74 1.05 1.05


Hyper-V server 2016

Esxi 6.0

0

1 VM

2 VMs 1

Hardware

2 VMs 2

3D performance - DirectX 10 2 1.8

1.74

1.68

1.6 1.4 1.2

1.21 1.05

1.05

1.03

1 0.77

0.8

0.75

0.6 0.4 0.2 0 Windows Server 2016 TP4


2 VMs 1

40

2 VMs 2

Esxi 6.0

1.05

3D performance - DirectX 11 180

170.1

160 140 120 100 80 60 40 20 0.79 0.55 0.57

0.59 0.36 0.36

0.93 0.49 0.56


Hyper-V server 2016

Esxi 6.0

0

1 VM

2 VMs 1

Hardware

2 VMs 2


0.93

0.9 0.8

0.79

0.7 0.6

0.55

0.57

0.59

0.56 0.49

0.5 0.36

0.4

0.36

0.3 0.2



2 VMs 1

41

2 VMs 2

Esxi 6.0

3D performance - DirectCompute 4500

3938

4000

3500 3000 2500 2000 1500 1000 500

108.8 51.5 50.7

61.5 33.3 32.9


Hyper-V server 2016

108.7 50.7

50

0

1 VM

Esxi 6.0

2 VMs 1

Hardware

2 VMs 2

3D performance - DirectCompute 120

108.8

108.7

100 80 61.5 60

51.5

50.7

50.7 33.3

40

32.9



2 VMs 1

42

2 VMs 2

Esxi 6.0

50

3Dmark - graphics 16000 13383

14000 12000 10000 8000 6000 4000 2000 44

51


Esxi 6.0

0 Hardware

3Dmark - graphics 52

51

50

48

46 44 44

42


Esxi 6.0

43

3Dmark - physics 12000

11126

10000

8000

6000

5695

5487


Esxi 6.0

4000

2000

0 Hardware

3Dmark - combined score 6000 5039 5000

4000

3000

2000

1000 19

22


Esxi 6.0

0

44

Hardware

3Dmark - combined score 22.5 22 22 21.5 21 20.5 20 19.5 19 19 18.5 18 17.5 Windows Server 2016 TP4

Esxi 6.0

3Dmark - graphics test 1 70

64.35

60 50 40 30 20 10 0.21

0.22


Esxi 6.0

0

45

Hardware

3Dmark - graphics test 1 0.222 0.22 0.22 0.218 0.216 0.214 0.212

0.21 0.21 0.208 0.206

0.204 Windows Server 2016 TP4

Esxi 6.0

3Dmark - graphics test 2 60 53.11 50

40

30

20

10 0.18

0.23


Esxi 6.0

0

46

Hardware

3Dmark - graphics test 2 0.25

0.23

0.2

0.18

0.15

0.1

0.05

0


Esxi 6.0

3Dmark - physics test 40 35.32 35 30 25 20

18.08

17.42


Esxi 6.0

15 10 5 0

47

Hardware

3Dmark - physics test 18.2 18.08 18

17.8

17.6 17.42 17.4

17.2


Esxi 6.0

3Dmark - combined test 25

23.44

20

15

10

5

0.09

0.1


Esxi 6.0

0

48

Hardware

3Dmark - combined test 0.102 0.1 0.1 0.098 0.096 0.094 0.092 0.09 0.09 0.088 0.086 0.084 Windows Server 2016 TP4

Esxi 6.0


11189

10000

8000

6000

4000

2000 44

51


Esxi 6.0

0

49

Hardware

3Dmark - total 52

51

50

48

46

44 44

42


Esxi 6.0

50

GPU-performance

-

RemoteFX


9000 8000 7000 6000

5000 4000 3000 1927

2000

1699

1662

1000 59.5

46.7

48

0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware

2 VMs 2

3D performance - DirectX 9 Simple 600 528 500

400

300

200

155.1 142.3 152.4

100 2.3

2.25

2.39

0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2

51

3D performance - DirectX 9 Simple 600 528 500

400

300

200

155.1 142.3 152.4

100 2.3

2.25

2.39

0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2


143.5

140 120 100

80 60 40.2 40 20

1.68

1.05

36

34.8

1.03

0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2

52

3D performance - DirectX 11 170.1

180 160 140

120 100 80 60

44.4

39.7

46.5

40 20

0.79

0.55

0.57

0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2

3D performance - DirectCompute 4500 3938

4000 3500 3000

2571

2500 1839 1808

2000 1500 1000 500

2.3

2.25

2.39

0

No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2

53

3D mark - graphics 16000 13383

14000 12000 10000 8000 6000 4000 1669 1385 1247


RemoteFX 1 VM

2 VMs 1

Hardware

2 VMs 2

3Dmark - physics 12000

11126

10000 8000 6000

5695 4850 4606 4862


RemoteFX 1 VM

2 VMs 1

Hardware

2 VMs 2

54

3Dmark - combined score 6000 5039 5000 4000 3000 2000 1000

525

460

409

19 0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2

3Dmark - graphics test 1 70

64.35

60 50 40 30 20 9.04

10

8.67

8.32

0.21 0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

55

Hardware 2 VMs 2

3Dmark - graphics test 2 60 53.11 50

40

30

20

10

6.06

4.61

4.02

0.18 0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2

3Dmark - physics test 40 35.32

35 30 25 20

18.08 15.4

15

14.62

15.44

10 5 0 No RemoteFX

RemoteFX

1 VM

2 VMs 1

56

Hardware

2 VMs 2

3Dmark - combined test 25

23.44

20

15

10

5 2.44

2.14

1.91

0.09 0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

Hardware 2 VMs 2


11189

10000

8000

6000

4000

1490

2000

1263

1140

44 0 No RemoteFX

RemoteFX 1 VM

2 VMs 1

57

2 VMs 2

Hardware

Memory-performance

RAM - total 3000 2615

2386

2500

1913 1870

2000 1518 1500

1194 1175

1191

1045 1036

1000 500 0 Windows Server 2016

Hyper-V Server 1 VM

Esxi

2 VMs 1

Hardware

2VMs 2

RAM - database operations 120 100.3 100 87.6 77.9

80

68.2 60

52.5 42.4 41.7

40

37.7

32.7

35

20

0 Windows Server 2016

Hyper-V Server 1 VM

Esxi 2 VMs 1

58

2VMs 2

Hardware

RAM - Read Cached 35000 30000

299532980229281

30067

265112648227195

25000 20000 1539815885 15000

11713

10000 5000 0 Windows Server 2016

Hyper-V Server 1 VM

Esxi

2 VMs 1

Hardware

2VMs 2

RAM - Read Uncached 18000 16000 14000

15462

14834 13109 1168211841

12000 10139 10000

8825 8796 7451 7056

8000 6000 4000 2000 0 Windows Server 2016

Hyper-V Server 1 VM

Esxi

2 VMs 1

59

2VMs 2

Hardware

Storage-performance

–

SSD

storage - total SSD 3000 2630

2536

2500

2331 2085

2000

1741

1673 1483

1500

1177

1145 965

1000

500



2 VMs 1

Esxi 6.0

Hardware

2 VMs 2

storage - sequencial Read 300

260.5

200

190.8 190.7

178.8

150 100

254.3

246.2

250

130 128.8

70.2

63.9


Hyper-V server 2016

1 VM

Esxi 6.0

2 VMs 1

60

2 VMs 2

Hardware

storage - sequencial write 300 252.6 250

233.4

222.1 193.8

200 150

137.3 134

129.7

128.3 111.8

110.2



Esxi 6.0

2 VMs 1

Hardware

2 VMs 2

storage - IOP score 250

233.1

233 202.8

201.1

200 153.3 150

127.6

119.3 118.1

128.4

100

50

27.7



Esxi 6.0

2 VMs 1

61

2 VMs 2

Hardware

Storage-performance

–

RAID

10

storage - total HDD 3000 2581 2500 2073 2000

1500 1225 980.4

1000

435.1

500

880 481.4

380.3

435.1 133.6



2 VMs 1

Esxi 6.0

Hardware

2 VMs 2

storage - sequencial Read HDD 700 600

587

500 392.7

400 300

254 201.4

190.1

200

99 100

63.3

49.5


Hyper-V server 2016

32.6

63.3

0

1 VM

Esxi 6.0

2 VMs 1

62

2 VMs 2

Hardware

storage - sequencial Write HDD 90

82.6

80 70

65.1

60

50 35.4

40 30.6

28.1

30 20.4

20.3

20.3

20

11.7

10

2.08



Esxi 6.0

2 VMs 1

Hardware

2 VMs 2

storage - IOP score HDD 60 50 40

54.2

54

43.6 36.7

36.7

35.6 32.1

30 22.4 20 6.6

10



Esxi 6.0

2 VMs 1

63

2 VMs 2

Hardware

Welk virtualisatieplatform biedt de grootste meerwaarde in datacenters als bare-metal hardwarevirtualisatiesolution: Hyper-V of Esxi?

Recommend Documents