Hypervisor gebaseerde x86 virtualisatie Xen en VMware ESX

Hypervisor gebaseerde x86 virtualisatie Xen en VMware ESX

Philip Dubois & Thomas De Ly Academiejaar 2007–2008

Promotor: Lector J. De Gelas, Sizing Servers Lab

Scriptie voorgedragen tot het behalen van de graad van Bachelor in de Multimedia en Communicatie Technologie

De auteur en promotor geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen ervan te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie. The author and promoter give the permission to use this thesis for consultation and to copy parts of it for personal use. Every other use is subject to the copyright laws, more specifically the source must be extensively specified when using from this thesis. Kortrijk, Mei 2008 De auteurs, Philip Dubois, Thomas De Ly

Woord vooraf Om onze opleiding Multimedia en Communicatie Technologie af te ronden, dienden wij een een projectmatige stage te volgen, en dit document is hiervan het resultaat. Wij kregen de kans om mee te draaien in het innovatieve Sizing Servers Lab, onder leiding van J. De Gelas, en gehuisvest in het Departement PIH van de Hogeschool West-Vlaanderen. Hier onderzochten wij de performantie impact van virtualisatie, toegespitst op de technologiën van VMware en Xen. Het werk werd verdeelt. Zo werkte Thomas rond VMware ESX en heeft hij de “real world”testopstelling uitgewerkt. Philip werkte met de Xen technologie en heeft het “worst load”testscenario opgezet. Philip Dubois, Thomas De Ly Kortrijk, juni 2008

Dankwoord Thomas Graag wens ik Johan De Gelas te bedanken voor deze leuke stage. Virtualisatie was iets nieuw voor mij, ook het werken met de vele (dure) servers was verrijkend. In het laaste jaar de kans krijgen om met uniek materiaal te werken is niet iedereen gegund. Het team in het Sizing Servers Lab heeft ons warm onthaald en de nodige begleiding gegeven. Af en toe een pot koffie, de nodige bijsturing en vooral het plezier doorheen de stage. Het was een leuke ervaring maar het belangrijkste is dat ik nu een heel andere manier van denken heb. Nieuwe technologieën onderzoeken, testen en daarvan een conclussie nemen het was allemaal vrij nieuw voor mij. Deze stage is dan ook een mooi slot van mijn MCT carriére. Ook Geert Hofman wens ik te bedanken voor het begrip en de begeleiding doorheen deze stage. Met Elisabeth van Dijk, onze interne stagecoatch, was het aangenaam samenwerken, ook de mede stagestudenten waren één voor één toffe kerels die maar al te graag eens brainstormden over verschillende theorieën. Verder wens ik mijn familie te bedanken voor de hulp en het vele verbeterwerk aan de thesis. En mijn vriendin, Charity Hochedez, voor het begrip en de steun tijdens de stageperiode. En last but not least wens ik Philip te bedanken voor de leuke samenwerking. Zijn nogal extreme open-source ingesteldheid heeft mij ook op bepaalde gebieden doen nadenken. Ook zijn kennis over linux Operating Systems (OSs) was voor mij heel leerrijk.

ii

Philip Bij deze zou ik een paar mensen willen bedanken voor hun steun en hulp bij m’n stage, en mijn MCT studies in het algemeen: M’n partner in dit project, Thomas. Hoewel het niet altijd even makkelijk is om met zo’n mierenneuker als ik samen te werken, gingen we dit project samen aan. De mensen van het Sizing Servers Lab. Zo bedank ik Johan De Gelas voor het aanbieden en ten volle steunen van dit uitdagend project. Johan volgde ons steeds vol enthousiasme op en wist de moed erin te houden. Af en toe diende hij er terecht de zweep eens bij te houden om ons op schema te houden. Werken met zo’n bron van onuitputtelijke informatie is zeer aangenaam, en ik kijk dan ook uit naar een verdere samenwerking. Dan hebben we Tijl Deneut, die ons met alles in het lab vertrouwd maakte, en onze collega student, Aswin Coolsaet Windows Man, die er steeds weer was voor allerhande opzoekwerk en must-know tips ivm. Windows optimalisaties. Verder wil ik ook Elisabeth Van Dijk bedanken voor het steeds bijstaan bij allerhande softwareproblemen, en Tjerk Ameel voor het prachtige logo dat dit document siert. Tenslotte zijn er nog the programmers!, Dieter Vandroemme en Yves Wouters, voor de prachtige vApus testomgeving en het brengen van mijn koffie op gezette tijden. Mijn ouders, meer bepaald m’n vader Harry Dubois en stiefmoeder Nora Vanden Berghe, alsook mijn zus Julie Nagels en mijn vriendin Elke Matthijs voor alle steun die ze steeds bieden en alle interesse naar mijn werk. Zo hebben m’n ouders mij ook steeds gesteund in mijn studiekeuze, ook al moest ik dan op kot in dat verre land Kortrijk. Ook wil ik m’n goeie maat, Nick Vannieuwenhoven, bedanken voor de grote interesse in dit project en het steeds weer doornemen van mijn tekst. Hij had vaak goede suggesties en ook hielp hij mij met bepaalde aspecten beter uit te diepen. En dan is er uiteraard nog Stijn Verslijcken, om mij aan deze stage te helpen door mijn naam aan Johan door te geven.

iii

Inhoudsopgave 1 Inleiding 1.1 Sizing Servers Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Virtualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 x86 2.1 2.2 2.3

Virtualisatietechnieken Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . Ring deprivileging . . . . . . . . . . . . . . . . . . . . . . . Binary Translation . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 System Calls . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Toegang tot de chipset en I/O, interrupts en DMA . 2.3.3 Memory Management . . . . . . . . . . . . . . . . . 2.4 Paravirtualization . . . . . . . . . . . . . . . . . . . . . . . 2.5 Hardware Assisted Virtualization . . . . . . . . . . . . . . . 2.5.1 Eerste generatie . . . . . . . . . . . . . . . . . . . . 2.5.2 Tweede generatie: Hardware Assisted Pages (HAP) 2.6 Full Virtualization . . . . . . . . . . . . . . . . . . . . . . .

1 1 2

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

4 4 5 6 7 7 8 8 9 9 10 11

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

12 12 13 14 14 15 17 18 19 21 22 23

4 Praktisch gebruik van Xen 4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Vereisten om Xen te gebruiken . . . . . . . . . . . . . . . . . . . . . .

24 24 24 24

3 Xen 3.1 Omschrijving . . . . . . . . . . . . . . 3.2 Terminologie . . . . . . . . . . . . . . 3.3 Architectuur . . . . . . . . . . . . . . 3.3.1 Xen paravirtualization . . . . . 3.3.2 De hypervisor en het Privileged 3.3.3 CPU-tijd en scheduling . . . . 3.3.4 Hypercalls . . . . . . . . . . . . 3.3.5 Privileges en geheugenbeheer . 3.3.6 Drivermodel . . . . . . . . . . . 3.3.7 Virtuele netwerking . . . . . . 3.3.8 Hardware Virtual Machines . .

iv

. . . . . . . . . . . . . . . . . . . . Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Inhoudsopgave

4.3

4.4

4.2.2 Installatie van binaire pakketten . . 4.2.3 Installatie vanaf de broncode . . . . 4.2.4 Commerciële Xen opties . . . . . . . Xen beheer met de Xen Manager . . . . . 4.3.1 Algemene xm opties . . . . . . . . . 4.3.2 Creëeren van een DomainU systeem 4.3.3 Het beheer van een DomU . . . . . . 4.3.4 Monitoren van DomUs . . . . . . . . Xen troubleshooting . . . . . . . . . . . . . 4.4.1 Netwerkproblemen . . . . . . . . . . 4.4.2 De xend daemon wil niet opstarten .

5 VMware ESX 5.1 VMware . . . . . . . . . . . . . . . . . 5.1.1 inleiding . . . . . . . . . . . . . . 5.1.2 VMware ESX . . . . . . . . . . 5.1.3 De console . . . . . . . . . . . . . 5.1.4 Architectuur van VMware ESX 5.1.5 VMware ESX 3.5 nieuwigheden 5.2 VMware ESX ontleding . . . . . . . . 5.2.1 VMFS . . . . . . . . . . . . . . . 5.2.2 Onderdelen van een VM . . . . . 5.2.3 VMware tools . . . . . . . . . . 5.3 Monitoring in VMware ESX . . . . . . 5.3.1 VMware Infrastructure Client 5.3.2 esxtop . . . . . . . . . . . . . . . 5.4 Andere VMware toepassingen . . . . . 5.4.1 VirtualCenter Agent : . . . . . . 5.4.2 Consolidated Backup : . . . . . . 5.4.3 Update Manager : . . . . . . . . 5.4.4 VMware HA : . . . . . . . . . . 5.4.5 VMotion : . . . . . . . . . . . . . 5.4.6 Storage VMotion : . . . . . . . . 5.4.7 VMware DRS : . . . . . . . . . . 5.4.8 Virtual Center Server : . . . . . . 5.5 Maintenance en Standby Modes . . . . . 5.5.1 Maintenance Mode . . . . . . . . 5.5.2 Standby Mode . . . . . . . . . . 6 Praktisch gebruik van VMware ESX 6.1 VMware ESX 3.5 installatie . . . . . 6.2 Aligneren . . . . . . . . . . . . . . . . 6.3 VMware Infrastructure Client (VIC) 6.3.1 Overzicht van de host . . . . . v

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

26 26 28 29 29 31 32 32 33 33 33

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

34 34 34 35 35 35 35 36 36 36 38 38 38 38 39 39 39 39 39 40 40 40 41 42 42 42

. . . .

44 44 46 46 46

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Inhoudsopgave 6.4

6.5

6.6

6.7

Virtual Machine (VM) . . . . . . . . . . . . . . . . . 6.4.1 Toolbar . . . . . . . . . . . . . . . . . . . . . 6.4.2 Nieuwe Machine aanmaken . . . . . . . . . . Installatie VMware Tools . . . . . . . . . . . . . . . 6.5.1 Windows 2003 Server . . . . . . . . . . . . . 6.5.2 Sles10 . . . . . . . . . . . . . . . . . . . . . . Settings van de Virtuele machines . . . . . . . . . . 6.6.1 Hardware . . . . . . . . . . . . . . . . . . . . 6.6.2 Options . . . . . . . . . . . . . . . . . . . . . 6.6.3 Resources . . . . . . . . . . . . . . . . . . . . Troubleshooting . . . . . . . . . . . . . . . . . . . . . 6.7.1 KERNEL MOUNTING FAILED . . . . . . . 6.7.2 Problemen met de AMD Opteron 8356 CPU.

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

7 Benchmarks: Worst load scenario 7.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Opzet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Sysbench: Online Transaction Processing (OLTP) benchmark 7.2.2 Algemeen sysbench testprotocol . . . . . . . . . . . . . . . . . 7.3 Xen benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 RAID configuratie - WriteBack vs. WriteThrough . . . . . . 7.3.2 Xen 3.0.4 - Quad Opteron 8356 . . . . . . . . . . . . . . . . . 7.3.3 Xen 3.0.4 - Quad Opteron 8356 numa=on . . . . . . . . . . . . 7.3.4 Xen 3.0.4 - Quad Xeon E7330 . . . . . . . . . . . . . . . . . . 7.3.5 Xen 3.0.4 - Quad Xeon E7340 . . . . . . . . . . . . . . . . . . 7.3.6 Xen 3.0.4 - Dual Opteron 8356 . . . . . . . . . . . . . . . . . 7.3.7 Xen 3.0.4 - Dual Xeon E7330 . . . . . . . . . . . . . . . . . . 7.3.8 Xen 3.2.1 - Quad Opteron 8356 . . . . . . . . . . . . . . . . . 7.4 VMware benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Dual Opteron 8356 . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 VMware tegenover Xen . . . . . . . . . . . . . . . . . . . . 8 Benchmarks: Real world scenario 8.1 Opstelling . . . . . . . . . . . . . . 8.2 Testsoftware . . . . . . . . . . . . . 8.2.1 vApus . . . . . . . . . . . . 8.2.2 Soorten tests . . . . . . . . 8.3 Swingbench (charbench) . . . . . . 8.3.1 Praktisch . . . . . . . . . . 8.4 Test instellingen 2008 . . . . . . . 8.4.1 2cpu’s per virtuele machine 8.4.2 4cpu’s per virtuele machine

. . . . . . . . .

. . . . . . . . .

vi

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

47 48 49 51 51 51 52 52 53 53 54 54 55

. . . . . . . . . . . . . . . . . .

58 58 59 59 59 62 62 63 63 64 64 66 66 67 68 68 68 68 72

. . . . . . . . .

73 73 74 74 74 79 79 80 80 80

Inhoudsopgave 8.5

8.6

VMware benchmarks . . . . . . . . 8.5.1 7330 dual vs 7330 quad . . 8.5.2 7330 quad vs 7350 quad . . 8.5.3 VMware vs Xen . . . . . . 8.5.4 Opteron 8356 vs Xeon 7330 Conclussies . . . . . . . . . . . . . 8.6.1 Xen vs VMware . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

81 81 83 84 85 87 88

9 Algemene Conclusies

89

A Google Ganeti A.1 Omschrijving . . . . . . . . . . . . . . A.2 Mogelijkheden . . . . . . . . . . . . . . A.3 Vergelijking traditionele HA & Ganeti A.4 Ganeti DRBD System Recovery . . . . A.5 Toekomst . . . . . . . . . . . . . . . . A.6 Meer informatie . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

91 91 92 92 93 94 94

B OpenVZ B.1 Omschrijving . . . . . . . . . B.2 OpenVZ Virtualisatie . . . . B.2.1 OS Virtualisatie . . . B.2.2 Netwerk Virtualisatie B.3 Resource Management . . . . B.4 Meer Informatie . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

95 95 96 96 96 96 97

C Test Protocol C.1 Virtuele machines : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2 Fysieke Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.3 Rapportering en monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98 98 98 99

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

D Resultaat tabellen

100

E Testconfiguraties

113

F Scripts 117 F.1 Linux sysbench scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Woordenlijst

121

Bibliografie

124

Projectfiche en -samenvatting

126

Stageverslagen en planning

129

vii

Lijst van tabellen 4.1

Benodigde software voor het compileren van Xen. . . . . . . . . . . . . . . .

27

5.1

Speciale console commando’s. . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

7.1

overzicht van de gebruikte RAID configuratie. . . . . . . . . . . . . . . . . . .

60

D.1 Writeback performantie in sysbench. . . . . . . . . . . . . . . D.2 Writethrough performantie in sysbench. . . . . . . . . . . . . D.3 Xen 3.0.4 - Quad Opteron 8356 sysbench resultaten. . . . . . D.4 Xen 3.0.4 - Quad Opteron 8356 numa=on sysbench resultaten. D.5 Xen 3.0.4 - Quad Xeon E7330 sysbench resultaten. . . . . . . D.6 Xen 3.0.4 - Quad Xeon E7340 sysbench resultaten. . . . . . . D.7 Xen 3.0.4 - Dual Opteron 8356 sysbench resultaten. . . . . . D.8 Xen 3.0.4 - Dual Xeon E7330 sysbench resultaten. . . . . . . D.9 Xen 3.2.1 - Quad Opteron 8356 sysbench resultaten. . . . . . D.10 VMware ESX 3.5 - Dual Opteron 8356 sysbench resultaten. . D.11 VMware esx 3.5 - Dual Xeon E7330 Windows resultaten. . . D.12 VMware esx 3.5 - Quad Xeon E7330 Windows resultaten. . . D.13 VMware esx 3.5 - Quad Xeon E7350 Windows resultaten. . . D.14 Xen 3.2.0 - Quad Xeon E7330 Windows resultaten. . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

100 100 101 102 103 104 105 106 107 108 109 110 111 112

E.1 E.2 E.3 E.4

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

113 114 115 116

Opteron 8356 testconfiguratie Xeon E7330 testconfiguratie . Xeon E7340 testconfiguratie . Xeon E7350 testconfiguratie .

. . . .

. . . .

. . . .

. . . .

. . . .

viii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Lijst van figuren 1.1 1.2 1.3

Het Sizing Servers Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verloop van het gebruik van virtualisatie in de loop der jaren. . . . . . . . . . Consolidatie door middel van virtualisatie. . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

Kernel en User Mode. . . . . . . . . . . . Ring deprivileging. . . . . . . . . . . . . . Binary Translation. . . . . . . . . . . . . . Binary Translated Code. . . . . . . . . . . System Calls Problem. . . . . . . . . . . . Shadow Page Tables. . . . . . . . . . . . . Hardware Assisted Virtualization. . . . . . Hardware Assisted Virtualization. . . . . . Hardware Assisted Pages. Ook wel Nested

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . of Extended Page Tables genoemd.

5 5 6 6 7 8 9 10 10

3.1 3.2 3.3 3.4 3.5 3.6

12 15 16 19 20

3.7 3.8 3.9

Het logo van Xen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overzicht van de Xen architectuur. . . . . . . . . . . . . . . . . . . . . . . . . Basisorganisatie van de Xen componenten. . . . . . . . . . . . . . . . . . . . Geheugenbeheer: Xen’s pseudo-physical memory versus shadow pages. . . . . Privilege ring model bij een 64-bit systeem. . . . . . . . . . . . . . . . . . . . Domain0 bevat de native en backend drivers, dewelke DomainU aanspreekt via diens frontend-drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Xen driver model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netwerking binnen een Xen systeem. . . . . . . . . . . . . . . . . . . . . . . . Xen full virtualization dmv. QEMU. . . . . . . . . . . . . . . . . . . . . . . .

4.1

De interactie met de xend daemon, via het xm commando. . . . . . . . . . . .

29

5.1 5.2 5.3 5.4 5.5 5.6

VMware . . . . . . Performance in VIC. VMware HA. . . . VMotion. . . . . . . Storage VMotion. . . DRS. . . . . . . . . .

. . . . . .

34 38 40 40 41 41

6.1

Installatie VMware ESX. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

ix

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

1 2 3

21 22 22 23

Lijst van figuren 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11

Partitionering VMware ESX. . . VMware ESX startscherm. . . . Host overzicht in VIC. . . . . . . . VM overzicht in VIC. . . . . . . . Toolbar in VIC. . . . . . . . . . . . VMware virtual machine options. VMware virtual machine options. VMware virtual machine options. QuadBarcelona CPU. . . . . . . . Snapshot disabeling access. . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

45 45 46 48 48 52 53 54 55 57

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13

Schematische weergave van de Linux worst load testopstelling. . . . . . . Sysbench: WriteBack versus WriteThrough resultaten. . . . . . . . . . . . Sysbench: Xen 3.0.4 - Quad Opteron 8356. . . . . . . . . . . . . . . . . . Sysbench: Xen 3.0.4 - Quad Opteron 8356 numa=on. . . . . . . . . . . . . Sysbench: Xen 3.0.4 - Quad Xeon E7330. . . . . . . . . . . . . . . . . . . Sysbench: Xen 3.0.4 - Quad Xeon E7340. . . . . . . . . . . . . . . . . . . Sysbench: Xen 3.0.4 - Dual Opteron 8356. . . . . . . . . . . . . . . . . . . Sysbench: Xen 3.0.4 - Dual Xeon E7330. . . . . . . . . . . . . . . . . . . . Sysbench: Xen 3.2.1 - Quad Opteron 8356. . . . . . . . . . . . . . . . . . Sysbench: Quad Opteron 8356 en Quad Xeon E7330. . . . . . . . . . . . . Power metingen bij de Opteron 8356 en Xeon 7330 (lager is beter). . . . . Sysbench native: CPU load bij Dual en Quad Opteron 8356 opstellingen. Sysbench: Xen en VMware ESX op de dual Opteron 8356. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

58 62 63 64 65 65 66 67 67 69 70 71 72

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19

Windows test opstelling. . . . . . . . . . . . . . . . Testopstelling vApus. . . . . . . . . . . . . . . . . As Soon As Possible. . . . . . . . . . . . . . . . . . Continous Rate. . . . . . . . . . . . . . . . . . . . vApus. . . . . . . . . . . . . . . . . . . . . . . . . . Apus Webbenchmark. . . . . . . . . . . . . . . . . Apus Database Benchmark. . . . . . . . . . . . . . Apus SlaveControlCenter. . . . . . . . . . . . . . . SlaveGroup. . . . . . . . . . . . . . . . . . . . . . . 7330 dual vs 7330 quad charbench. . . . . . . . . . 7330 dual vs 7330 quad CPU belasting charbench. 7330 dual vs 7330 quad CRDBBenchmark. . . . . 7330 dual vs 7330 quad CRWebHttpBenchmark. . 7330 quad vs 7350 quad charbench. . . . . . . . . . 7350 quad vs 7330 quad CPU belasting charbench. Xen vs VMware OLTP. . . . . . . . . . . . . . . . Xen vs VMware WebBench. . . . . . . . . . . . . . 8356 vs 7330 WebBench. . . . . . . . . . . . . . . . 8356 vs 7330 BenchDB. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

74 75 75 75 76 77 77 78 78 81 82 82 83 84 84 85 85 86 86

x

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

Lijst van figuren 8.20 8356 vs 7330 Oltp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

A.1 A.2 A.3 A.4

. . . .

91 92 93 93

B.1 OpenVZ: container based virtualisatie. . . . . . . . . . . . . . . . . . . . . . .

95

Opbouw van een Ganeti cluster. . . . . . . . Traditionele High Availability oplossing. . . . De Google Ganeti High Availability oplossing. Schijf failover met Google Ganeti . . . . . . .

xi

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Hoofdstuk 1

Inleiding 1.1

Sizing Servers Lab

Het lab waar wij de kans kregen om dit onderzoek uit te voeren is de eerste plaats waar onze resultaten toegepast zullen worden. Sizing Servers is een onderneming, gesubsidiëerd door de Vlaamse Overheid, die in contact staat met talloze Vlaamse KMO’s. Algemeen kunnen we stellen dat de consumentenmarkt in de IT-wereld momenteel gecontroleerd wordt door voornamelijk Amerikaanse software-giganten. Proberen concurreren in deze markt is voor een KMO in ons Vlaanderen zo goed als nutteloos. Toch staan we op vlak van softwareontwikkeling zeker op de kaart, en dit het ontwikkelen van zeer specifieke en gespecialiseerde applicaties.

Figuur 1.1: Het Sizing Servers Team.

1

Hoofdstuk 1. Inleiding Het sizen van deze applicaties is waar het lab zich, in de samenwerking met KMO’s, in de eerste plaats op toespitst. Het analyseren van de toepassingen die de KMO’s gebruiken, en op basis daarvan gebaseerd een gedetailleerd onderzoek naar de impact van bepaalde harden software onderzoeken.

1.2

Virtualisatie

Virtualisatie is in deze groene tijden een hot topic geworden. Volgens een paper van het IDC1 [13] zou het gebruik van virtualisatietechnologiën jaarlijks stijgen met zo’n 47 %. Zo is een van de belangrijkste voordelen van virtualisatie consolidatie (fig. 1.3). Met consolidatie doelt men op het ten volle benutten van een fysieke server, door er een groot aantal Virtual Machines (VMs) op te plaatsen. Zodoende spaart men hardware, plaats en stroom uit.

Figuur 1.2: Verloop van het gebruik van virtualisatie in de loop der jaren.

In de meeste publicaties zijn de testscenario’s vaak onrealistisch; men wil hun product uiteraard in een zo goed mogelijk daglicht plaatsen. Deze publicaties laten gewoonlijk een vergelijking zien tussen een native situatie, en een situatie waar het geheel gevirtualiseerd wordt uitgevoerd. Hier toont men echter steeds het resultaat in een situatie waar slechts een enkel VM draait. Van het feit uitgaande dat consolidatie de meest aangeworven toepassing is van hypervisor gebaseerde virtualisatie, is dit een zeer onrealistische testopstelling. Verder wordt er het vaakst getest met synthetische benchmarks, die vooral CPU intensief zijn. Maar puur rekenwerk is probleemloos te virtualiseren. De grootste virtualisatie overhead treedt echter op als er veel calls naar de hardware gemaakt worden en er veel interrupts gegenereerd 1

http://www.idc.com/

2

Hoofdstuk 1. Inleiding worden. Met andere woorden, als er veel op I/O apparaten wordt gesteund.

Figuur 1.3: Consolidatie door middel van virtualisatie.

Met dit onderzoek willen we de performantie impact van real world toepassingen van hypervisor gebaseerde virtualisatie, met Xen en VMware, profileren. Hiervoor moeten we eerst een goede kennis hebben van de gebruikte technologie (hoofdstukken 3 en 5), waarna we over gaan tot het benchmarken. Dit benchmarken wordt uitgevoerd aan de hand van twee testopstellingen; namelijk een worst load scenario (hoofdstuk 7) en een real world scenario (hoofdstuk 8).

3

Hoofdstuk 2

x86 Virtualisatietechnieken In dit hoofdstuk worden kort de virtualisatietechnieken met hypervisor toegelicht. Voor een uitgebreide uiteenzetting over virtualisatie, en de impact van hardware assisted virtualization, verwijzen we de lezer graag door naar het artikel van J. De Gelas [10].

2.1

Hypervisor

Om verschillende OSs op één fysieke machine te laten werken is er een extra software laag nodig, de hypervisor of Virtual Machine Monitor (VMM). Zijn belangrijkste rol is de toegang van virtuele OSs te regelen naar de onderliggende hardware. Op deze manier is het mogelijk om meerdere OSs virtueel te laten werken op één host systeem. Om precies te begrijpen wat een VMM doet moeten we eerst begrijpen hoe een modern OS werkt. De meeste OSs werken in twee modes: Kernel Mode(ring 0) kan bijna elke CPU instructie runnen, inclusief geprivilegieerde instructies die moeten omgaan met interrupts, geheugen management,... Dit is natuurlijk de mode waar de kernel van het OS in werkt. User Mode(ring 3) laat alleen instructies toe die nodig zijn om te rekenen of om data te verwerken. Applicaties werken altijd in deze modus en kunnen alleen gebruik maken van hardware door een system call uit te voeren (deze zal communiceren met de kernel). Het volledige kernel- en usermode systeem is gebaseerd op het feit dat het werkgeheugen ingedeeld is in pages. Vooraleer een geprivilegieerde instructie wordt uitgevoerd gaat de CPU eerst controleren of de page waar de instructie vandaan komt de juiste 2-bit code heeft. De meest geprivilegieerde instructies hebben zo een 00 code nodig. Deze 2-bit code laat vier levels toe met 11 als laagste level. De 2-bit code wordt veelal voorgesteld door vier ajuin ” ringen”. Ring 0 is de meest geprivilegieerde laag, ring 1 minder en ring 3, waar de gebruiker zijn applicaties laat draaien, heeft geen rechten om hardware te beheren.

4

Hoofdstuk 2. x86 Virtualisatietechnieken

Figuur 2.1: Kernel en User Mode.

2.2

Ring deprivileging

Een techniek die voor alle software gebaseerde virtualisatie oplossingen wordt gebruikt is ring deprivileging. Hier wordt het OS verplaast naar een andere ring (bijvoorbeeld ring 1 ). Dit laat de Virtual Machine Monitor (VMM) toe om de toegang van het guest OS naar de hardware resources te controleren. Zo krijgt een guest OS geen directe controle over de hardware.

Figuur 2.2: Ring deprivileging.

Er is echter een groot probleem met ring deprivileging. Elke geprivilegieerde instructie uitgevoerd door een VM zorgt voor een trap, een fout, omdat deze VM in een lager geprivilegieerde ring werkt. De VMM vangt al deze traps op en emuleert de instructie zonder de integriteit van andere VMs in het gedrang te brengen. Om performantie redenen is geprobeerd om het aantal traps, en de tijd nodig om die af te handelen, te reduceren. Het probleem met een x86 CPU is dat bepaalde instructies uit ring 1 gewoon genegeerd worden. Hieruit volgt dat als een guest OS een interrupt uit probeert te schakelen, dewelke 5

Hoofdstuk 2. x86 Virtualisatietechnieken echter niet opgevangen wordt, en de VMM weet niet wat er gebeurt. Tot overmaat van ramp hebben x86 CPUs 17 van deze instructies die niet getrapped worden. Deze worden de x86 stealth instructions genoemd.

2.3

Binary Translation

VMware is niet blijven wachten op een oplossing voor de x86 stealth instructions en begon te werken aan een eigen oplossing (anno 1999). Deze kwam er door Binary Translation, de binare code die de kernel van een guest OS genereert. Dit gebeurt “on the flyën slaat de aangepaste x86 code op in een Translator Cache (TC). Gebruikersapplicaties (ring 3) worden door de VMware Binary Translator (BT) niet aangeraakt omdat deze code als “safe”wordt beschouwd. Dus worden gebruikersapplicaties onmiddelijk uitgevoerd alsof deze native werken. De kernel code die nu in ring 0 wordt uitgevoerd is een door de BT vertaalde

Figuur 2.3: Binary Translation.

code van het guest OS. In bepaalde omstandigheden wordt de BT gegenereerde code langer dan de originele code. Als een guest OS een geprivilegieerde instructie wenst uit te voeren zal de BT deze namelijk omvormen tot een veiligere usermode code. Deze veilige code zorgt ervoor dat de werking van andere VMs en de VMM zelf niet in het gedrang komt.

Figuur 2.4: Binary Translated Code.

6

Hoofdstuk 2. x86 Virtualisatietechnieken VMware probeert ook de overhead van de BT zo laag mogelijk te houden door de instructiestroom niet te gaan optimaliseren maar deze wel in een cache te steken. Als er een loop is kan deze code dus snel weer opgevraagd worden en wordt de vertaling slechts eenmaal uitgevoerd. BT staat echter nog voor enkele uitdagingen:

2.3.1

System Calls

Een system call is het resultaat van een usermode applicatie die een service van de kernel vraagt. De x86 instructieset biedt een low-latency manier om de system calls te verwerken: SYSENTER (of SYSCALL) en SYSEXIT. Een system call zal de VMM en vooral de BT extra werk geven. Het probleem is dat een SYSENTER (“request the service of the kernel”) naar een page wordt gestuurd met privilege 0. Het verwacht daar een OS te vinden maar komt bij de VMM uit. Zodoende moet de VMM iedere system call emuleren, de code omvormen om vervolgens de controle over te laten aan de vertaalde kernel code, die in ring 1 draait. Eenmaal de binary translated code van het guest OS uitgevoerd is zal deze een SYSEXIT naar de user generen. Het guest OS werkt echter op een ander niveau en heeft dus niet de nodige privileges om SYSEXIT uit te voeren dus stuurt de CPU een fout naar ring 0, waar de VMM de call van de guest vertaalt.

Figuur 2.5: System Calls Problem.

Het is duidelijk dat system calls veel overhead veroorzaken. Deze kosten de VM tienmaal meer cycles dan een native machine.

2.3.2

Toegang tot de chipset en I/O, interrupts en DMA

Een groot probleem voor elke vorm van virtualisatie is I/O. Als de host machine niet genoeg CPU kracht heeft dan kan je CPU’s met meer cores plaatsen. Maar de geheugen bandbreedte, de chipset en de storage HBA zijn in de meeste gevallen gedeeld door alle VMs en een stuk moeilijker te upgraden. In tegenstelling tot de CPU is de meeste hardware van een VM geëmuleerd. Dit betekent dat elke toegang tot de driver van virtuele hardware moet omgevormd worden door BT naar de echte driver. 7

Hoofdstuk 2. x86 Virtualisatietechnieken Zo moeten moderne fysieke servers samen werken met een in VMware ESX geëmuleerde chipset, een negen jaar oude BX chipset en de HBA, een oude Bus Logic of LSI card. Dit betekent ook dat nieuwe features in het guest OS, voor verbetering van performantie, met de hardware niet gebruikt kunnen worden.

2.3.3

Memory Management

Een OS gebruikt page tables om virtuele memory pages te vertalen in fysieke geheugen adressen. Alle moderne x86 procesoren ondersteunen virueel geheugen in de hardware. De vertaling van virueel tot fysieke adressen wordt uitgevoerd door de Memory Management Unit (MMU). Het adres wordt opgeslaan in het CR3 register (hardware page table pointer) en de meest gebruikte onderdelen van de page table worden gecached in de Translation Lookaside Buffer (TLB). Het is duidelijk dat een guest OS geen toegang mag hebben tot de echte page tables. In plaats hiervan ziet een guest OS page tables op een geëmuleerde MMU. De echte pages zijn verborgen voor het guest OS en worden beheerd door de VMM. Er wordt gebruik gemaakt van shadow page tables, die de virtuele adressen van het guest OS vertalen naar fysieke pages. Telkens een guest OS zijn page mapping aanpast, zal de MMU de shadow page tables aan-

Figuur 2.6: Shadow Page Tables.

passen. Dit kost echter veel CPU cycles, drie tot 400 maal meer dan in een native situatie. Het resultaat is dat met geheugen intensieve applicaties, in een gevirtualiseerde omgeving, het grootste verlies te vinden is bij het werkgeheugen beheer.

2.4

Paravirtualization

Paravirtualisatie is een virtualisatietechniek die een software interface aan VMs voorstelt, gelijkaardig (maar niet identiek) aan de onderliggende hardware, waar het guest OS zich bewust is van het feit dat het gevirtualiseerd wordt. Deze virtualisatietechniek vereist dat de het guest OS gewijzigd dient te worden om in deze virtuele context te draaien. Deze aanpassing dient echter enkel op kernel niveau te gebeuren, zodat usermode applicaties onaangeroerd blij-

8

Hoofdstuk 2. x86 Virtualisatietechnieken ven. Paravirtualisatie laat hierdoor toe dat de VMM eenvoudig blijft, als we deze vergelijken tegenover een hypervisor die op Binary Translation steunt. Het, in dit document besproken, Xen maakt gebruik van paravirtualisatie. In hoofdstuk 3 vindt de lezer een uitgebreide uiteenzetting terug over de architectuur van Xen.

2.5 2.5.1

Hardware Assisted Virtualization Eerste generatie

Ook hardware producenten zijn begonnen met het produceren van hardware met features om virtualisatie technieken te vereenvoudigen. Vruchten hiervan zijn onder andere Intel Virtualization Technology (Intel VT) en AMD’s AMD Virtualization (AMD-V). Hardware Virtualisatie is geen verbeterde versie van BT of paravirtualisatie. Het eerste idee was om het probleem met de x86 stealth instructions op te lossen. Dit betekent dat hardware virtualisatie probeert om alle excepties en geprivilegieerde instructies op te vangen, door het afdwingen van een overgang van de guest naar de VMM, die een VMexit wordt genoemd. Het grote

Figuur 2.7: Hardware Assisted Virtualization.

voordeel is dat het guest OS werkt op zijn normaal privilege niveau (ring 0), de VMM werd verplaatst naar een nieuwe ring op een nog hoger niveau (ring -1 of Root Mode). System calls gaan niet meer automatisch resulteren in VMM tussenkomsten, zolang het geen kritieke instructies zijn. Hierdoor kan het guest OS kernel services bieden aan de applicaties. Deze vorm van virtualisatie zou de overhead moeten reduceren tot een minimum. Maar desondanks de implementatie in hardware, is voor elke overgang van VM naar de VMM (VMexit) en terug (VMentry) een relatief groot aantal CPU cycles nodig. Afhankelijk van de interne CPU architectuur en het soort van operatie (VMexit, VMentry, VMread,...) kunnen deze acties honderden tot duizenden CPU cycles in beslag nemen. Enkele oplossingen voor dit probleem zijn al uitgewerkt. Zo werd het aantal cycles nodig voor VMM overgangen gereduceerd alsook het aantal VMM events. Deze eerste generatie hardware virtualisatie is in die mate verbetert dat het werd opgenomen in VMware ESX en Xen om op 64bit guest OSs toe te passen. 9

Hoofdstuk 2. x86 Virtualisatietechnieken

Figuur 2.8: Hardware Assisted Virtualization.

2.5.2

Tweede generatie: Hardware Assisted Pages (HAP)

Bij Binary Translation werd al verduidelijkt dat de MMU gebruik maakt van de TLB om om de mapping van virtuele naar fysieke geheugenadress in op te slaan. Tevens werd kort uitgelegd dat voor virtualisatie een shadow page table nodig is om fysieke geheugen adressen te linken aan virtuele geheugen addressen. Het probleem dat binary translation ervaart met deze shadow page tables willen AMD en Intel gaan oplossen met Hardware Assisted Pages (HAP). De oplossing bestaat eruit om een extra kolom in de TLB te creëren; namelijk de Address Space Identifier (ASID). Hierdoor is er een directe link tussen fysieke en virtuele geheugen adressering. Een bijkomend voordeel

Figuur 2.9: Hardware Assisted Pages. Ook wel Nested of Extended Page Tables genoemd.

is dat een VM de TLB inhoud van een andere VM niet wist, op voorwaarde dat de TLB groot genoeg is natuurlijk. Volgens AMD biedt deze technologie 23 % winst. HAP heeft vooral zijn voordelen als er meerdere virtuele CPUs zijn per VM. Hierdoor zijn er meer synchronisaties met de page tables en worden die ook frequenter vernieuwd. Er zijn echter nadelen aan Nested/Extended Page Tables, zo is het opzoeken van een fysiek adres veel complexer geworden. Telkens er iets moet opgezocht worden in de TLB moet er gezocht worden in zowel guest mapping als VMM mapping. 10

Hoofdstuk 2. x86 Virtualisatietechnieken Een tweede nadeel is de standaardisatie. De implementaties van AMD (Nested Page Tables) en Intel (Extended Page tables) zijn niet onderling compatibel. Dit betekent dat softwareontwikkelaars aparte modules moeten ontwikkelen voor de producten van beide fabrikanten. Dit is weer extra code die moet worden opgenomen in de softwarepakketten.

2.6

Full Virtualization

Bij deze vorm van virtualisatie heeft het guest OS een volledig virtueel platform: virtuele BIOS, virtuele hardware en virtueel geheugen beheer. Op deze manier is het guest OS zich er niet van bewust dat het in een gevirtualiseerd omgeving draait en zijn er geen extra aanpassingen nodig om de aangeleverde hardware te kunnen gebruiken. Deze vorm van virtualisatie heeft het grote voordeel dat de VM volledig ontkoppeld is van de onderliggende hardware. VMware claimt gebruik te maken van full virtualization door middel van binary translation. Dit is grotendeels juist, echter na installatie van de VMware tools wordt bijvoorbeeld gebruik gemaakt van de geparavirtualiseerde vmxnet netwerkadapter.

11

Hoofdstuk 3

Xen Dit hoofdstuk is een uitbreiding op de thesis van S. Verslycken [15], onze voorganger in het Sizing Servers Lab, die het eerste onderzoek naar Xen virtualisatie voor Sizing Servers deed. Verdere informatie komt uit de boeken van Williams & Garcia [17] en von Hagen [16]. De Xen architectuur wordt kort toegelicht in Xen Architecture Overview [18]. Voor een diepgaande uiteenzetting van de Xen VMM verwijzen we de lezer graag door naar Xen and the Art of Virtualization [7] en het boek dat geschreven werd door Chisnall [9].

Figuur 3.1: Het logo van Xen.

3.1

Omschrijving

Xen is een open source Virtual Machine Monitor (VMM) die oorspronkelijk ontwikkeld werd voor de Intel IA32 (x86 en x86-64) hardware architectuur. Tegenwoordig is er ook support voor de Intel IA64 “Itanium”, alsook de IBM PowerPC. Xen werd ontwikkeld met als doel de huidige hypervisor gebaseerde virtualisatie oplossingen te overtreffen in prestaties. De grootste belofte, die steeds maar weer naar boven komt, is dat deze VMM een near-native performantie kan aanbieden voor VMs. Men tracht dit te bewerkstelligen door te steunen op paravirtualisatie (zie 2.4 en 3.3.1). Het Xen project is vrij innovatief en het ontwikkelingsprocess gaat in sneltreinvaart vooruit. Doordat er nauw wordt samengewerkt met partners, zoals bijvoorbeeld Intel en AMD, kan men als één van de eersten nieuwe technologieën implementeren. Eén van de nieuwste hardware technieken die Xen al ondersteund is bijvoorbeeld 12

Hoofdstuk 3. Xen HAP (sectie 2.5.2), dewelke momenteel ge¨ıntegreerd is in de nieuwste Opteron (codename “Barcelona”) processoren van AMD. Xen is ontstaan als academisch onderzoeksproject aan de University of Cambridge in 2003 onder leiding van Ian Pratt. Men zag het commerciële potentieel in van dit project met als gevolg de oprichting van XenSource1 in 2005. Dit bedrijf werd opgericht door het originele team dat Xen ontwikkelde, waaronder Ian Pratt en Moshe Bar, en heeft vestigingen in Cambridge (UK), Palo Alto (CA, USA) en Redmond (WA, USA). Dit team is nog steeds verantwoordelijk voor het grootste gedeelte van de ontwikkeling van dit virtualisatieplatform, in samenwerking met partners als Intel, AMD, Novell en Redhat. De broncode is gelicenseerd onder de GNU General Public Licence (GNU GPL) en is ter download beschikbaar op Xen.org. In oktober 2007 werd XenSource overgenomen door Citrix2 , welke vooral gekend is in de desktop-virtualisatie markt. Hoezeer XenSource’s overname door Citrix de toekomst van Xen zal be¨ınvloeden is nog onduidelijk. Er is echter al een samenwerking opgezet tussen Citrix en Microsoft, voor het ontwikkelen van een compatibiliteitslaag tussen de producten van beide fabrikanten, respectievelijk Xen en Hyper-V 3 . Zo zal het mogelijk zijn om Windows Server 2008 geparavirtualiseerd boven de Xen VMM te draaien. Doordat Xen Open Source Software (OSS) is, gelicenseerd onder de GNU General Public Licence (GNU GPL) versie 2, kan elke softwareproducent de technologie implementeren, zolang deze implementatie ook voldoet aan de eisen van de GNU GPLv2 licentie. Grote spelers op de commerciële open source markt, zoals Novell en Redhat, waren er al vroeg bij om de Xen technologie te implementeren en hebben ook grote bijdragen terug geleverd aan de Xen codebase.

3.2

Terminologie

Xen gebruikt een ietwat afwijkende terminologie. Hierna volgt een overzicht van de gebruikte termen, zodoende verwarring te vermijden tijdens het verder verloop van dit document. Domain Een synoniem voor Virtual Machine (VM). Privileged Domain (Dom0) Het domain van waaruit Xen beheerd wordt. Dit is de VM waar de xend daemon draait en de native device drivers (zie 3.3.6) aanwezig zijn. Het systeem is gelimiteerd tot één Privileged Domain (Dom0). Unprivileged Domain (DomU) De reguliere domains, zonder speciale rechten. 1

http://www.xensource.com http://www.citrix.com 3 http://www.microsoft.com/windowsserver2008/en/us/virtualization-consolidation.aspx?pf=true 2

13

Hoofdstuk 3. Xen Driver Domain DomU met speciale privileges om bepaalde hardware rechtstreeks aan te spreken. Paravirtual Machine (PVM) Een geparavirtualiseerd Unprivileged Domain (DomU). Hardware Virtual Machine (HVM) Een hardware gevirtualiseerd DomU. Dit is een domain dat in full virtualization mode draait, gebruikmakend van de hardware virtualisatie extensies die de nieuwe Intel en AMD processoren bieden. Men vindt meer informatie over dit type domain terug in sectie 3.3.8. Hypercall Een signaal dat een domain kan uitsturen om de hypervisor ervan op de hoogte te brengen dat het een geprivilegieerde taak wil uitvoeren. Native device driver Traditionele I/O driver waarmee de fysieke hardware devices worden aangestuurd.

3.3 3.3.1

Architectuur Xen paravirtualization

Xen gaat uit van het principe van de paravirtualisatie; de VMM gaat er namelijk van uit dat de gevirtualiseerde kernel zich ervan bewust is dat deze geen exclusieve toegang heeft tot de hardware. Zodoende dient Xen geen onnodige CPU cycles te verliezen aan de vertaalslag van instructies voor het afschermen van de individuele VMs; wat het geval is bij binary translation, beschreven in sectie 2.3. Een domain krijgt geen speciale hardware voorgespiegeld (emulatie), maar heeft de beschikking over de fysieke hardware. Deze VM heeft echter geen directe toegang tot de hardware, maar dient via de Xen Application Programming Interface (API) met de hypervisor te communiceren. Dit betekent dat een guest systeem speciaal aangepast dient te worden voor gebruik in een geparavirtualiseerde Xen omgeving. Gelukkig beperkt dit zich tot de kernel van het guest systeem, zodoende dat de applicaties die in user-mode draaien onaangeroerd blijven. Sinds versie 2.6.23 van de Linus’ Linux tree “Vanilla” zijn deze patches standaard in de Linux kernel opgenomen. Het is sinds versie 3 van Xen ook mogelijk om onaangepaste guest systemen als VM te draaien: de zogenaamde Hardware Virtual Machine (HVM). Hier gaan de voordelen van paravirtualisatie echter verloren; deze machines dienen namelijk in full virtualization mode te werken. Deze virtualisatie methode wordt in Xen verwezenlijkt door gebruik te maken van hardware extenties zoals Intel Virtualization Technology (Intel VT) en AMD Virtualization (AMD-V). In het artikel van J. De Gelas [10] wordt er uitgebreid op hardware assisted virtualization ingegaan. We gaan er hier niet verder op in. 14

Hoofdstuk 3. Xen

Figuur 3.2: Overzicht van de Xen architectuur.

3.3.2

De hypervisor en het Privileged Domain

Hypervisor Het centrale onderdeel van de Xen technologie is diens VMM. Deze hypervisor, gebaseerd op een kleine, autonome Linux 2.6.16 kernel, draait rechtstreeks bovenop de fysieke hardware en onder de VMs waar ze de resource scheduling en geheugenpartitionering verzorgt. Ze is verantwoordelijk voor de abstractie van de onderliggende hardware, en ze zorgt voor isolatie van de verschillende VMs. Om deze taken zo efficiënt mogelijk te bewerkstelligen, en omdat ze niet bekend is met de I/O hardware in het systeem, werkt de hypervisor nauw samen met het Dom0. De Xen hypervisor is opgebouwd uit enkele modules (fig. 3.2) met elk een gespecialiseerde taak: Control Interface Dit onderdeel van de hypervisor staat in voor het verdelen van resources onder de verschillende domains. Enkel Dom0 heeft exclusieve controle over dit onderdeel. Via deze interface verloopt de communicatie tussen de VMM en Dom0. Safe Hardware Interface Deze interface wordt aangeroepen door een native device driver binnen Dom0 of een driver domain, indien deze de fysieke hardware wil aanspreken. Event Channel Via dit onderdeel verloopt de communicatie tussen de verschillende domains. Een domain stuurt via dit kanaal een event, een hypercall genaamd, naar het 15

Hoofdstuk 3. Xen Dom0 en de VMM indien deze een geprivilegieerde taak wil uitvoeren. Hypercalls worden besproken in sectie 3.3.4. Virtual CPU (VCPU) De VCPU verzorgt de virtualisatie van de fysieke processoren. Het is mogelijk om meer Virtual CPUs (VCPUs) toe te wijzen aan een domain dan er fysiek in de machine aanwezig zijn. Vanuit performantie oogpunt wordt dit echter afgeraden. Virtual MMU (VMMU) Deze zorgt voor het virtueel geheugenbeheer van de domains. Met andere woorden, de virtuele MMU verzorgt de afscherming van de verschillende page tables per domain. De taken en werking van de Virtual MMU (VMMU) wordt in sectie 3.3.5 verder toegelicht. Domain0 De Xen VMM werkt niet alleen, maar wordt geassisteerd door Dom0 (fig. 3.2, VM0). Dit domain bevat het OS van waaruit het het beheer van de hypervisor en de DomUs gebeurt; de Domain Management and Control module (fig. 3.3, DM&C). Dit beheer wordt verwezenlijkt via een service die in dit domain draait; namelijk de xend daemon. Dom0 bevat ook alle native device drivers en een back-end interface om de fysieke I/O hardware aan te sturen. DomUs maken hypercalls vanuit hun front-end drivers, langs het event channel, naar de back-end in Dom0. Deze stuurt op zijn beurt de hardware aan, gebruik makende van de VMM’s safe hardware interface. In sectie 3.3.6 vindt men meer informatie terug over dit driver model. In dit domain draait ook de xenstore daemon, welke informatie verzamelt over de toestand van de hypervisor en de VMs.

Figuur 3.3: Basisorganisatie van de Xen componenten.

16

Hoofdstuk 3. Xen

3.3.3

CPU-tijd en scheduling

CPU-tijd Een goed tijdsbesef is van groot belang voor de werking van een kernel; het process scheduling systeem hangt hier immers van af. Een OS dat zonder virtualisatie op de hardware draait zal elk process een bepaalde hoeveelheid CPU-tijd, CPU-cycles, toekennen. Als een OS gevirtualiseerd wordt, kunnen er echter problemen optreden, daar een VM (of domain) zelf een process is binnen het hypervisor systeem. De VM krijgt zelf slechts een deel van de totaal beschikbare fysieke CPU-tijd, aangezien deze gedeeld dient te worden met andere virtuele instanties. Een guest systeem dient zich dus bewust te zijn van zowel werkelijke tijd, de wall clock, en z’n eigen domain virtual time. Xen houdt verschillende tijdssystemen bij, welke gebruikt worden voor CPU scheduling. Deze zijn: Cycle counter time Deze zorgt voor een precieze tijdsreferentie, dewelke wordt gebruikt voor het accuraat afleiden van de andere tijdsreferenties. Op Symmetric Multi Processing (SMP) systemen wordt er verondersteld dat de cycle counter time gesynchroniseerd wordt tussen de processoren. System time Dit is een 64-bit teller dewelke het aantal nanoseconden bijhoudt dat er verstreken is na het opstarten van het systeem. Wall clock time Dit is de reële systeemtijd, uitgedrukt in microseconden sinds 1 januari 1970 ; de zogenaamde Unix time 4 . De wall clock time kan accuraat gehouden worden door te synchroniseren met een Network Time Protocol (NTP) server. Domain virtual time Deze teller verloopt aan hetzelfde tempo als de system time, maar enkel als het domain wordt gescheduled. Op deze manier wordt het aandeel CPU-tijd dat een domain krijgt toegewezen, aangeduid door het tempo waarin zijn domain virtual time toeneemt. De Xen VMM exporteert de system time en de wall clock time via shared page tables (zie 3.3.5) naar de domains. De hypervisor stuurt elke tien milliseconden een timer event naar het guest systeem dat wordt uitgevoerd. Wanneer een domain gescheduled wordt, ontvangt deze ook een timer event, opdat deze de tijd die verlopen is terwijl het inactief is geweest, kan aanpassen. Ten slotte kan een guest OS ook een aanvraag doen naar de VMM om op een gespecifiëerde system time zo’n timer event te sturen. 4

http://en.wikipedia.org/wiki/Unix_time

17

Hoofdstuk 3. Xen CPU schedulers Xen biedt een uniforme API van CPU schedulers, zodat het mogelijk is om uit een aantal schedulers te kiezen, of er zelfs een toe te voegen. Men kan een scheduler specifiëren via de sched= Xen boot-parameter. Er zijn standaard al een aantal CPU schedulers ge¨ımplementeerd in een Xen systeem. Een vergelijkende beschrijving van deze schedulers vindt men terug in de paper van Cherkasova et al. [8]. Credit Deze scheduler is een proportional fair share CPU-scheduler, vanaf grond af opgebouwd voor gebruik op SMP systemen. Deze scheduler duidt een domain aan met een gewicht een optioneel maximum. Het gewicht van een domain bepaalt hoeveel recht deze heeft op CPU-tijd, zonder het maximum, uitgedrukt in een percentage, te overschreiden. Dit is de standaard gebruikte CPU-scheduler. Borrowed Virtual Time (BVT) is ook een proportional fair share CPU-scheduler, gebaseerd op het concept van virtual time, die de VM met de laagste domain virtual time eerst uitvoert. Bovendien biedt BVT low-latency ondersteunding voor VMs die realtime applicaties draaien, doordat deze domains de mogelijkheid geeft om hun virtual time terug te spoelen om zo voorang te krijgen bij het schedulen van CPU-tijd. Simple Earliest Deadline First (SEDF) Deze scheduler biedt een gewogen CPU aandeel aan aan een domain op een intu¨ıtieve manier, gebruik makend van realtime-algoritmen. Hierover is meer documentatie te vinden in de Xen distributie5 .

3.3.4

Hypercalls

Vanwege de paravirtualisatie vereist Xen dat de guest kernel hiervoor is aangepast. Dit bood de ontwikkelaars van Xen de kans om het systeem van calls en interupts te vereenvoudigen. Een kernel die in full virtualization mode draait, gaat er immers van uit dat deze op fysieke hardware draait en zal, vrij veel calls naar de hardware maken. Bepaalde evenementen, zoals bijvoorbeeld een context switch, zullen een hele reeks achtereenvolgende calls teweeg brengen die telkens dienen ge¨ınterpreteerd en uitgevoerd te worden door de virtualisatielaag. Dit hele systeem is erg omslachtig en kan voor een enorme performantie impact zorgen. In Xen wordt dit aangepakt doordat een guest OS zijn calls naar de hardware dient te maken via efficiënte, Xen-specifieke instructies, de zogenaamde hypercalls, dewelke het traditionele systeem vervangen. Waar traditioneel voor een bepaalde taak, zoals het uitvoeren van een context switch, een groot aantal geprivilegieerde calls gemaakt dient te worden, is het met Xen mogelijk om dit alles te combineren in slechts één hypercall, eventueel aangevuld met parameters, waarna de hypervisor het geheel afhandelt. Zo is er bijvoorbeeld de mmu update() hypercall, dewelke het hele geheugenbeheer, zoals het updaten van de page tables of het 5

Deze documentatie vindt men terug in docs/misc/sedf scheduler mini-HOWTO.txt.

18

Hoofdstuk 3. Xen uitvoeren van een TLB flush, voor z’n rekening neemt. Dit reduceren van het aantal systeem calls zorgt voor een verminderde virtualisatie overhead. Verder verloopt de communicatie tussen domains onderling, en met de VMM, alsook de verschillende events, via hypercalls. Zo bestaat de aanvraag van een domain naar een timer event (sectie 3.3.3) uit de set timer op() hypercall. Inter-domain communicatie verloopt via de event channel op() hypercall. Voor een overzicht van de beschikbare hypercalls en hun functies verwijzen we de lezer graag door naar de XenSource [5] documentatie.

3.3.5

Privileges en geheugenbeheer

De Virtual Memory Management Unit (VMMU) Xen maakt gebruikt van een geparavirtualiseerde MMU, de Virtual MMU (VMMU), dewelke verantwoordelijk is voor de virtualisatie van het geheugenbeheer. Er wordt gebruik gemaakt van direct-mode memory management of pseudo-physical memory (fig. 3.4); er wordt niet langer een kopie bijgehouden van de actuele page tables in shadow page tables (zie pagina 8), zoals bij binary translation, maar domains mogen rechtstreeks in het fysieke geheugen werken. Een VM krijgt van de hypervisor een deel van het fysiek geheugen, gespecificeerd in de configuratie van het domain met een standaardwaarde en een maximum, toegewezen en mag deze zelf beheren, onder strict toezicht van de VMM.

Figuur 3.4: Geheugenbeheer: Xen’s pseudo-physical memory versus shadow pages.

Wanneer een guest OS gescheduled staat voor een CPU, dan zal de VMM ervoor zorgen dat de page table base verandert en de VMMU enkel het geheugenbereik weergeeft waar het domain recht op heeft. Een domain heeft in principe enkel toegang tot zijn eigen page 19

Hoofdstuk 3. Xen tables, maar er is ook een mogelijkheid om bepaalde, gedeelde page tables aan te spreken. De tijdssynchronisatie (zie 3.3.3) steunt op deze shared page tables. Indien een operating system toegang wil tot nested page tables (64-bits werking), dan kan dat enkel read-only. De Xen hypervisor gebruikt zelf maar een klein, vast deel van het fysieke geheugen. Ze zal echter ook de bovenste 64 MiB van elke virtuele address space reserveren. Verder is Xen in staat om met Physical Address Extension (PAE) te werken op 32-bit systemen, zodat het systeem meer dan 4 GiB werkgeheugen kan aanspreken. Privileges In een Xen gebaseerd systeem, draait de VMM in ring 0, waardoor ze volledige toegang heeft tot het fysieke geheugen van het systeem en er delen van kan toewijzen aan de domains. Een guest OS krijgt plaats in een van de minder gepriviligeerde ringen6 . Hoe de indeling precies gebeurt hangt af van de architectuur en het OS. Op een 32-bit (x86) geparavirtualiseerd Linux systeem kan de VMM gebruik maken van memory segmentation om zichzelf af te schermen van de andere processen. De kernel van het guest systeem draait hier in ring 1. De userspace applicaties doen hun werk in ring 3, net zoals in een native situatie.

Figuur 3.5: Privilege ring model bij een 64-bit systeem.

Op een 64-bit systeem kan Xen echter geen gebruik maken van memory segmentation, waardoor het genoodzaakt is geheugen af te schermen op page-basis. De guest kernel draait hier nu ook in ring 3, zoals de usermode applicaties (fig. 3.5). Weliswaar is dit op basis van strikt gescheiden page tables. Indien een applicatie een system call uitvoert op de guest kernel, dan dient Xen in te grijpen door de page tables aan te passen. Deze context switch tussen ring 0 en ring 3 gebeurt door middel van het syscall/sysret 7 principe. 6 7

http://en.wikipedia.org/wiki/Supervisor_mode http://en.wikipedia.org/wiki/Call_gate

20

Hoofdstuk 3. Xen In beide gevallen is het een guest OS niet toegestaan om een gepriviligeerde taak uit te voeren, en kan het de de gepriviligeerde bits in (E)FLAGS 8 niet aanpassen. Als een OS in een domain zo’n taak wil uitvoeren, dient deze een hypercall naar de VMM te sturen.

3.3.6

Drivermodel

Xen maakt gebruik van een gesplitst model met frontend- en backend-drivers. Meer concreet wil dit zeggen dat alle native device drivers, nodig om de fysieke hardware aan te sturen, enkel aanwezig zijn in Dom0, dewelke een backend-interface naar deze drivers aanbiedt. Een DomU bevat een generieke frontend-interface, namelijk de xennet en xenblk drivers, die via hypercalls over het event channel met de driver backend communiceert (fig. 3.6 en 3.7). Er komt hier dus geen emulatie aan te pas; er wordt enkel vereenvoudigd.

Figuur 3.6: Domain0 bevat de native en backend drivers, dewelke DomainU aanspreekt via diens frontend-drivers.

Wanneer een DomU bijvoorbeeld de netwerkkaart wil aanspreken, dan zal de kernel de xennet driver aanspreken, dewelke de te versturen data in een shared memory page plaatst (zie 3.3.5) en een hypercall verzend. Als de VMM deze actie authoriseert, wordt de instructie die de DomU kernel wil uitvoeren naar de backend van het Dom0 gestuurd. Dom0 laat deze instructie dan uitvoeren door de native device drivers, over de safe hardware interface van de hypervisor. Doordat de communicatie over twee verschillende kanalen verloopt, namelijk het event channel voor de instructies en een shared memory page voor de datatransfer, is het mogelijk om requests samen te bundelen voor een efficiënte toegang tot het hardwareapparaat. Het is mogelijk om een DomU de rechten te geven om rechtstreeks bepaalde hardware apparaten aan te spreken. Dit domain, een driver domain genoemt, dient dan over een native 8

EFLAGS is de 32-bit opvolger van het 16-bit FLAGS status register op de Intel IA32 processor. Verder is er ook het 64-bit RFLAGS register.

21

Hoofdstuk 3. Xen

Figuur 3.7: Xen driver model.

device driver te beschikken, alsook de backend, voor dit apparaat. Dit maakt het mogelijk dat andere DomUs ook via dit driver domain de fysieke hardware kunnen aansturen.

3.3.7

Virtuele netwerking

Alle domains communiceren via een virtuele netwerkbrug xenbr0 die via de interface peth0 binnen het Dom0 verbonden is met de buitenwereld. De peth0 interface is eigenlijk de fysieke eth0 interface, en neemt dan ook diens instellingen over. Het is mogelijk de configuratie van de netwerkbrug in te stellen in de Xen configuratiebestanden, om bijvoorbeeld de brug aan een andre fysieke interface te koppelen, of om meerdere netwerkbruggen aan te maken. Figuur 3.8 geeft een schema weer van dit systeem.

Figuur 3.8: Netwerking binnen een Xen systeem.

22

Hoofdstuk 3. Xen

3.3.8

Hardware Virtual Machines

Sinds versie 3.0 van Xen is het mogelijk om onaangepaste OSs te virtualiseren. Hier wordt dan gebruik gemaakt van full virtualization, gebruik makend van de hardware extensies voor virtualisatie van de moderne processoren; Intel VT en AMD-V. Voor deze full virtualization wordt gebruik gemaakt van een speciale Xen versie van de QEMU emulator 9 , die de hardwareemulatie voorziet. Met Xen 3.2.0 en hoger is het ook mogelijk om gebruik te maken van hardware virtualisatie van de tweede generatie; namelijk Hardware Assisted Pages (HAP), dewelke besproken wordt in sectie 2.5.2.

Figuur 3.9: Xen full virtualization dmv. QEMU.

Zowel Novell als Citrix bieden geparavirtualiseerde I/O drivers aan voor HVMs in hun commerciële producten. Deze drivers berusten op hetzelfde front-end en back-end principe als het standaard Xen model (zie 3.3.6), en bieden een enorme performantieboost. Deze PV I/O drivers verkeren echter nog in BETA fase, en zijn dus nog niet stabiel te noemen.

9

http://bellard.org/qemu

23

Hoofdstuk 4

Praktisch gebruik van Xen 4.1

Inleiding

In dit hoofstuk vindt de lezer meer informatie terug over het praktisch gebruik van Xen. Zo wordt er uitgelegd welke de verschillende installatiemogelijkheden zijn, wat de systeemvereisten zijn, en de stappen die men moet ondernemen om een Xen omgeving op te zetten. Vervolgens wordt er beschreven hoe men virtuele machines aanmaakt, beheert en kan monitoren met de Xen Management (xm) tool. Ten slotte is er nog een kleine troubleshooting sectie.

4.2 4.2.1

Installatie Vereisten om Xen te gebruiken

Hier volgt een korte lijst met harden softwarevereisten voor het draaien van de Xen VMM, het Dom0 en een of meerdere DomUs. Voor een meer uitgebreide lijst verwijzen we de lezer graag door naar het boek van von Hagen [16] (3de hoofdstuk) en de XenSource [6] documentatie. Hardwarevereisten De volgende hardwarecomponenten zijn vereist om een werkende Dom0 host op te zetten met één of meerdere virtuele machines: Processor Een Pentium 4 compatibel systeem met een klokfrequentie van 1, 5 GHz of beter. Xen ondersteunt momenteel systemen met maximaal 32 processoren. Om HVMs te draaien heeft men een processor met Intel VT of AMD-V extensies nodig. Zie [2] voor een lijst van compatibele processoren. Moederbord Als men een processor met Intel VT of AMD-V gebruikt, dient deze optie ook in het BIOS van het moederbord ingeschakeld te zijn. Sommige moederborden onder24

Hoofdstuk 4. Praktisch gebruik van Xen steunen processoren met virtualisatie extensies, maar kunnen deze niet inschakelen. Zie [1] voor een lijst van compatibele moederborden. Geheugen Er wordt een minimum van 1 à 2 GiB werkgeheugen aangeraden voor degelijke werking. De hoeveelheid gebruikt geheugen is erg afhankelijk van het aantal, het type (bv. non-GUI of Graphical User Interface (GUI)) en de grootte van de virtuele machines die op het systeem zullen draaien. Harde schijf Men dient genoeg harde schijfruimte te voorzien voor de virtuele machines; elke DomU heeft namelijk zijn eigen bestandssysteem. Het is ook gebruikelijk om plaats te voorzien voor updates en snapshots van de VMs. Benodigde softwarepakketten De volgende softwarecomponenten zijn minimaal vereist in een Dom0 systeem: Bridge-utils verzorgt het beheer van virtuele netwerken. GRand Unified Bootloader (GRUB) is, op moment van schrijven, de enige bootloader die de Xen VMM kan laden. Iproute of iproute2 zorgt voor de configuratie van de netwerkinterfaces en de routering van ethernet pakketten. Lbsdl (optioneel) is nodig als men een grafische console naar een VM wenst over het Simple DirectMedia Layer (SDL) protocol. Libvncserver (optioneel) is nodig als men een grafische console naar een VM wenst over het Virtual Network Computing (VNC) protocol. Python (versie 2.4 of hoger) is de programmeertaal waarin de xend daemon en de Xen beheerprogramma’s zijn ontwikkeld. Pyxml of python-xml wordt gebruikt om de vele eXtensible Markup Language (XML) configuratiebestanden die Xen gebruikt te parsen. SSL cryptografische bibliotheken (libssl) voor beveiligde communicatie. Udev zorgt ervoor dat hardware nodes dynamisch worden aangemaakt tijdens het opstarten van het Linux systeem. Zlib wordt gebruikt voor datacompressie en -decompressie.

25

Hoofdstuk 4. Praktisch gebruik van Xen

4.2.2

Installatie van binaire pakketten

Xen in SUSE Linux Enterprise Server (Novell) SUSE Linux Enterprise Server (SLES) was de eerste enterprise Linux distributie die Xen officëel ondersteunde, en dit vanaf versie 10 van het besturingssysteem. De installatie van een volledig werkende Xen omgeving in SLES verloopt heel eenvoudig met het beheerprogramma SUSE Yet another Setup Tool (YaST2). Als men in YaST2 onder de kop Virtualization kijkt, dan kan daar de optie Install Hypervisor and Tools teruggevonden worden. Ook het creëren en beheren van virtuele machines is mogelijk met YaST2. Xen in Debian Linux Sinds Debian 4.0 zijn er Xen pakketten beschikbaar in de unstable en experimental software repositories. Deze pakketten kunnen ge¨ınstalleerd worden met de apt-get tool. Softwarepakketten van belang, volgens de Debian Wiki [4], zijn onder andere: • xen-linux-system-kernelversie • libc6-xen (enkel voor i386 systemen) • xen-tools (optioneel) • grub

4.2.3

Installatie vanaf de broncode

Xen is vrije software waardoor de broncode1 beschikbaar is voor download en gebruik. Hieronder worden de stappen beschreven die men moet ondernemen om Xen vanaf de broncode te installeren. Als voorbeeld gaan we uit van een SLES10 systeem waarop de virtualisatiesoftware wordt ge¨ınstalleerd. Installeren van de nodige softwarepakketten Voor het compileren van de Xen broncode dienen een aantal pakketten, opgesomd in tabel 4.1, op het systeem aanwezig te zijn. De manier van installeren van software hangt sterk af van de gebruikte Linux distributie, maar deze pakketten vindt men meestal terug in de officiële repositories van de distributie. Indien het nodig moest blijken, is het steeds mogelijk om de software te downloaden van de officiële 1

http://www.xen.org

26


Tabel 4.1: Benodigde software voor het compileren van Xen.

• • • • • •

GCC v3.4 of hoger GNU Binutils python-dev openssl-dev bridge-utils hotplug of udev

• • • • •

GNU Make zlib-dev libncurses-dev xorg-x11-dev iproute

website of vindt men ze terug in software databanken zoals RPMSeek 2 . In SLES kunnen deze softwarepakketten heel gemakkelijk ge¨ınstalleerd worden via volgend commando: 1

y a s t − i g c c make b i n u t i l s z l i b −d e v e l python−d e v e l n c u r s e s −d e v e l c u r l −d e v e l o p e n s s l − d e v e l xorg−x11−d e v e l b r i d g e − u t i l s i p r o u t e udev g e t t e x t −d e v e l

De Xen broncode downloaden en installeren De volgende stap bestaat eruit om de Xen broncode binnen te halen. Hiervoor zijn er twee methodes beschikaar; de eerste zijnde het downloaden van een tarball archief vanaf de Xen.org website, en de andere via het Version Controll System (VCS) Mercurial 3 . De voorkeur gaat naar het gebruik van Mercurial4 . Nadat we eventueel Mercurial op het systeem hebben ge¨ınstalleerd, kunnen we de laatste versie van de Xen broncode downloaden. Ook dient de broncode van een Linux kernel met Xen patches binnengehaald te worden. Nadat dit gebeurd is kunnen we het geheel compileren en installeren. 1

3

5

hg c l o n e −r RELEASE− 3 . 2 . 1 h t t p : / / x e n b i t s . x e n s o u r c e . com/ xen −3.2− t e s t i n g . hg hg c l o n e −r 406 h t t p : / / x e n b i t s . x e n s o u r c e . com/ l i n u x −2.6.18 − xen . hg cd xen −3.2− t e s t i n g . hg make world make i n s t a l l

Dit zal de Xen VMM, libraries, tools en een paravirtualiseerbare Linux kernel (2.6.18.8) compileren. Er kan ook geopteerd worden om zelf een Linux kernel te patchen. Indien dit gewenst is, kunnen de kernel patches gecompileerd worde met het make mkpatches commando, om ze vervolgens toe te passen op de broncode van een Vanilla 5 - of een custom-build Linux kernel. 2

http://www.rpmseek.com http://www.selenic.com/mercurial/wiki/index.cgi 4 http://www.selenic.com/mercurial 5 http://www.kernel.org 3

27

Hoofdstuk 4. Praktisch gebruik van Xen De meest gangbare distributies bieden ook speciale Xen-gecompileerde kernels aan en vanaf versie 2.6.23 van de Vanilla-tree bevat Linux standaard al ondersteuning voor virtualisatie. Vervolgens dient GRUB nog juist ingesteld te worden. We moeten namelijk de gloednieuwe Xen VMM en het Dom0 kunnen booten. Dit wordt verwezenlijkt door een nieuwe optie in het /boot/grub/menu.lst bestand te specifiëren. Het is ook wenselijk om Xen als standaard opstartsysteem in te stellen. Men dient als kernel optie de Xen VMM te specifiëren, de Dom0 kernel wordt met de module optie aangeduid. Concreet betekent dit dat eerst de hypervisor gestart wordt, waarna deze de Dom0 kernel aanroept. 1

3

5

t i t l e Xen 3 . 2 . 1 − 2 . 6 . 1 8 . 8 r o o t ( hd0 , 0 ) k e r n e l / boot / xen − 3 . 2 . 1 . gz module / boot / vmlinuz −2.6.18.8 − xen r o o t =/dev / sda4 r o vga=0x317 module / boot / i n i t r d −2.6.18.8 − xen

In de bootoptie hierboven wordt er ook een Initial RAM Disk als module gespecifiëerd. Dit is een image met een minimaal root bestandssysteem dat tijdens het opstarten in het geheugen wordt geladen en onder andere de essentiële opstartmodules bevat. Deze RAM Disk kan men in SLES aanmaken met het mkinitrd commando. Vervolgens dient men de rc scripts nog aan te passen zodat de xend daemon automatisch met het systeem wordt gestart. In SLES is dit gemakkelijk te verwijzenlijken door gebruik te maken van het YaST2 beheerprogramma. De optie vindt men terug in het System, System Services(Runlevel) menu. Ten slotte kunnen we het systeem opnieuw opstarten. Als alles goed is gegaan wordt men begroet met een werkende Xen omgeving en kan men aan de slag met het creëren van VMs. Indien xend niet kan starten, dient er gecontrolleerd te worden of alle benodigde softwarepakketten aanwezig zijn op het systeem (zie 4.2.1 en 4.4.2). 1

3

5

7

\ \/ / \ // / \ / /\ \

| / | \ ’ \ | \ / | | | ) | / | | | | | ( )

\ ) | / (

/ | | )

| | | |

(XEN) Xen v e r s i o n 3 . 2 . 1 ( r o o t @ s s l a b . l o c a l ) ( g c c v e r s i o n 4 . 1 . 2 20070115 ( p r e r e l e a s e ) ( SUSE Linux ) ) Mon May 26 1 6 : 3 6 : 2 1 CEST 2008 (XEN) L a t e s t ChangeSet : F r i Apr 25 1 4 : 0 3 : 3 9 2008 +0100 1 6 8 8 0 : d 2 e b 5 f a d 9 2 4 2

4.2.4

Commerci¨ ele Xen opties

XenSource, dat recent is overgenomen door Citrix6 , biedt zowel vrije als commerciële licenties aan op hun Xen producten. Dit bedrijf werd opgericht door het team van de University 6

http://www.citrix.com

28

Hoofdstuk 4. Praktisch gebruik van Xen of Cambridge, onder leiding van Ian Pratt, dat Xen oorspronkelijk heeft ontwikkeld. Zij zijn dan ook nog steeds verantwoordelijk voor het grootste gedeelte van de ontwikkeling van dit virtualisatieplatform. De broncode blijft gelicenseerd onder de GNU GPL en is ter download beschikbaar op het eerder vernoemde Xen.org. Meer informatie over dit bedrijf en hun producten kan men op de XenSource website7 terugvinden. Een ander commerciëel bedrijf is Virtual Iron8 . Hun geleverde diensten zijn gebaseerd op de Xen hypervisor.

4.3

Xen beheer met de Xen Manager

De standaard tool voor het beheer van een Xen omgeving is de Xen Management tool die aangeroepen wordt met het xm commando. Hiermee is het onder andere mogelijk om VMs aan te maken, af te sluiten, op te slaan, ze te monitoren en een (seriële) console ernaar te openen. Deze tool kan ook geavanceerde zaken zoals het dynamisch toevoegen en/of verwijderen van VCPUs, block- en netwerk apparaten en geheugen. Het commando laat zelfs toe om de gebruikte Xen scheduler te manipuleren. Kortom, de commandolijn gebaseerde Xen Manager kan alle taken op een Xen systeem aan.

Figuur 4.1: De interactie met de xend daemon, via het xm commando.

In deze sectie zullen we de meest gangbare opties van xm bespreken. Voor een volledige lijst kan er steeds beroep gedaan worden op de man-pagina (man xm) van het commando.

4.3.1

Algemene xm opties

Hier worden algemene xm opties beschreven die niet meteen invloed hebben op het manipuleren van VMs. 7 8

http://www.xensource.com http://www.virtualiron.com

29


2

Usage : xm <subcommand> [ a r g s ] C o n t r o l , l i s t , and m a n i p u l a t e Xen g u e s t i n s t a n c e s .

xm dmesg geeft de dmesg meldingen van de Xen VMM weer.

2

4

6

8

[...] (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) [...]

Using s c h e d u l e r : SMP C r e d i t S c h e d u l e r ( c r e d i t ) I n i t i a l i z i n g CPU#0 D e t e c t e d 2 3 1 1 . 8 5 4 MHz p r o c e s s o r . CPU: L1 I Cache : 64K ( 6 4 b y t e s / l i n e ) , D c a c h e 64K ( 6 4 b y t e s / l i n e ) CPU: L2 Cache : 512K ( 6 4 b y t e s / l i n e ) CPU 0 ( 4 ) −> Core 0 AMD SVM E x t e n s i o n i s e n a b l e d f o r cpu 0 .

xm help toont een lijst van beschikbare opties met telkens een korte beschrijving waar deze voor staan. xm info geeft info weer over Xen en de Xen host. 1

3

5

7

host : q u a d b a r c e l o n a −1u release : 2 . 6 . 1 6 . 5 4 − 0 . 2 . 5 − xen [...] : 3 xen major xen minor : 0 xen extra : . 4 13138 −0.60 : xen −3.0− x 8 6 6 4 xen −3.0− x 8 6 3 2 p hvm−3.0− x 8 6 3 2 hvm−3.0− xen caps x 8 6 3 2 p hvm−3.0− x 8 6 6 4 [...]

xm list [domain] Als dit commando wordt gebruikt zonder een domain te specifiëren, wordt er een lijst getoond van alle domains die geregistreerd staan bij het Xen Domain Management. Als men wel een domain specifiëert, wordt enkel de status van die VM weergegeven. In combinatie met de --long optie wordt de gehele configuratie van het domain in Simple XML Persistence (SXP) formaat op het scherm afgedrukt.

2

Name Domain−0 oltp64 1

ID Mem VCPUs 0 32195 16 9 4096 4

State r−−−−− −b−−−−

Time ( s ) 189.1 107.4

xm log drukt de xend log af. xm shell opent een interactieve xm shell zodoende er een hele hoop commando’s achter elkaar gegeven kunnnen worden zonder het xm voorvoegsel.

30


4.3.2

Cre¨ eeren van een DomainU systeem

Voor het aanmaken van een DomU dient men een configuratie en een root filesysteem voor de VM aan te maken. Het root filesysteem kan men bekomen door een image van een reeds ge¨ınstalleerd systeem aan te maken of te downloaden. Men kan ook gebruik maken van distributie-specifieke tools zoals Debian’s debootstrap en SUSE’s “Install into directory” YaST2 optie. Als het glsdom0 systeem een GUI bevat, dan is het ook mogelijk om een virtueel systeem aan te maken via het virt-manager programma. Een Xen DomU configuratiebestand kan in drie verschillende bestandsformaten gedefiniëerd worden. Om een nieuw DomU systeem aan te maken wordt meestal gebruik gemaakt van een Python configuratiebestand, maar intern werkt Xen voornamelijk met SXP of XML. Zo’n Python configuratiebestand ziet er als volgt uit: 1

3

5

7

9

11

13

15

17

19

ostype = ” s l e s 1 0 ” name = ” o l t p 6 4 1 ” memory = ”4096” vcpus = ”4” cpus = ”0−3” on crash = ” destroy ” on poweroff = ” destroy ” on reboot = ” r e s t a r t ” l o c a l t i m e = ”0” builder = ” linux ” # k e r n e l = ”/ boot / vmlinuz−xen ” # ramdisk = ”/ boot / i n i t r d −xen ” # r o o t = ”/ dev / xvda2 ” b o o t l o a d e r = ”/ u s r / l i b / xen / boot / domUloader . py” b o o t a r g s = ”−−e n t r y=xvda2 : / boot / vmlinuz −2.6.16.60 −0.23 − xen , / boot / i n i t r d −2.6.16.60 −0.23 − xen ” extra = ” ” d i s k = [ ’ f i l e : / v a r / l i b / xen / images / o l t p 6 4 1 / d i s k 0 , xvda , w’ , ’ phy : / dev / s t o r a g e / lun1 , xvdb1 , w’ , ] v i f = [ ’ mac = 0 0 : 1 6 : 3 e : 5 3 : 0 f : f 6 ’ ] v f b = [ ’ t y p e=s d l ’ ]

Vooral de bootloader en bootargs opties zijn hier interessant. Normaal dient de DomU kernel in het Dom0 systeem aanwezig te zijn om te starten (kernel, ramdisk en root opties), dewelke gewoonlijk ook de gebruikte Dom0 kernel is. Met het domUloader.py script is het echter mogelijk de DomU-kernel uit diens root filesysteem te extraheren en deze in een tijdelijke directory in het Dom0 systeem op te slaan, waarna deze vervolgens gestart wordt. Als men de configuratie en een filesysteem bezit, kan de nieuwe VM aangemaakt worden met het xm create commando. De machine zal worden opgestart, en indien gewenst kan er meteen een (virtuele) seriële console naar geopend worden door de -c optie bij het commando te specifiëren. Als de VM wordt afgesloten, zal deze niet meer beschikbaar zijn volgens xm list. Men dient het domain immers te registreren bij de Xen manager door gebruik te maken 31

Hoofdstuk 4. Praktisch gebruik van Xen van het xm new commando. Meer configuratie voorbeelden, met een beschrijving van elke optie, vindt men terug in /etc/xen/examples/. De configuratie van een HVM DomU verloopt gelijkaardig met dat van een Paravirtual Machine (PVM) met kleine verschillen in het configuratiebestand. Ook hiervan zijn voorbeelden te vinden op de eerder vernoemde locatie.

4.3.3

Het beheer van een DomU

Eenmaal een domain is aangemaakt, kunnen hier allerlei acties op losgelaten worden. Zo kan men domains starten, afsluiten of migreren naar een ander systeem waar Xen op draait. Bij elk van deze commando’s dient het domain gespecifiëerd te worden waarop het van toepassing is. xm console opent een virtuele, seriële console naar het domain. xm reboot zal het domain herstarten. xm shutdown sluit een domain af. xm destroy termineert een domain meteen. xm <pause|unpause> Met dit commando kan je het uitvoeren van een domain pauzeren of opnieuw starten. xm <save|restore> slaat de toestand van een domain op in een gespecifiëerd bestand om deze later te herstellen. xm biedt de mogelijkheid om het aantal actieve VCPUs of het gebruikte werkgeheugen van een domain in te stellen. xm migrate wordt gebruikt als men een domain van een Xen hostsysteem wil migreren naar een ander Xen systeem.

4.3.4

Monitoren van DomUs

Men kan de domains in de gaten houden met het interactieve xentop (of xm top) commando. Het toont onder andere VCPU gebruik, geheugengebruik en I/O gebruik. 1

# put xentop ou tp ut h e r e #

Het is mogelijk dit commando in batch-modus te gebruiken om voor een bepaalde tijd, met een bepaald interval, de monitorwaarden naar een tekstbestand weg te schrijven. Een voorbeeld van deze batch-mode is xentop -d2 -i150 -b > monitor; dit commando zal gedurende 150 32

Hoofdstuk 4. Praktisch gebruik van Xen iteraties, met telkens 2 seconden wachttijd, de output in het ”monitor”tekstbestand wegschrijven. Doordat voor elke output regel de naam van het domain wordt afgedrukt, kan men gemakkelijk in het bestand filteren door middel van het grep commando.

4.4 4.4.1

Xen troubleshooting Netwerkproblemen

Het kan voorvallen dat bij het draaien van Xen domains het netwerk problemen vertoont. Zo kan men bijvoorbeeld perfect naar andere machines op het netwerk pingen, maar toepassingen die op de applicatielaag van het TCP/IP model werken zullen falen. Dit fenomeen liet zich R 82575EB Gigabit Ethernet Controller 9 in combinatie met uiten bij het gebruik van de Intel de igb 10 netwerkdriver. De oorzaak hiervan ligt in de TCP checksum berekeningen die botst met bepaalde Xen optimalisaties. De oplossing bestaat erin deze TCP checksumming uit te schakelen in de domains. Het uitschakelen van TCP checksumming kan men met het ethtool -K tx off commando. Deze instelling gaat echter verloren tijdens een herstart van de VM. Het is dus interessant om dit proces te automatiseren. Eén van de mogelijke oplossingen is door het commando in een scriptje te steken dat aangeroepen wordt bij het inschakelen van de netwerkinterface. 1

3

echo ’#!/ b i n / bash ’ > / e t c / s y s c o n f i g / network / s c r i p t s / t x c h e c k s u m o f f echo ’ e t h t o o l −K e t h 0 t x o f f ’ >> / e t c / s y s c o n f i g / network / s c r i p t s / t x c h e c k s u m o f f l n −s / e t c / s y s c o n f i g / network / s c r i p t s / t x c h e c k s u m o f f / e t c / s y s c o v e r s c h i l n f i g / network / i f − up . d/15− t x c h e c k s u m o f f

4.4.2

De xend daemon wil niet opstarten

Indien de xend daemon niet wil starten na een verse Xen installatie en deze een cryptische Python foutmelding weergeeft, is het mogelijk dat de oorzaak ligt bij het ontbreken van bepaalde vereiste softwarepakketten. Een lijst van deze pakketten kan de lezer terugvinden in sectie 4.2.1. Onder onze SLES10 SP1 installatie, bijvoorbeeld, dienden we de XML extensies voor Python nog te installeren. 1

y a s t − i pyxml python−xml

9

http://www.intel.com/design/network/products/lan/controllers/82575EB.htm http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Inst=Yes&ProductID=2874&DwnldID= 13663&strOSs=All&OSFullName=All%20Operating%20Systems&lang=eng 10

33

Hoofdstuk 5

VMware ESX

Figuur 5.1: VMware

5.1

VMware

5.1.1

inleiding

VMware werd opgericht in 1998 en is uitgegroeid tot de virtualisatie-marktleider. Met meer dan 100.000 klanten, 10.000 partners en een omzet van $ 1,3 miljard is VMware één van de grootste groeiende software bedrijven in de wereld. In 1999 kwam hun eerste product op de markt, VMware Workstation. Vooral bedoeld voor desktop virtualisatie werd het al snel populair voor devoloppers om hun software te testen. In 2001 ging VMware van start op de servermarkt met de GSX en ESX sever. Later kwam dan de gratis versie van GSX, VMware Server genaamd. VMware houdt er een hele virtualisatie-filosofie op na. Deze heeft de naam VMware Infrastructure en bestaat uit vele onderdelen waaronder ESX Server en Virtual Center. In dit document beperken we ons tot de VMware ESX Server 3.5. Voor meer info omtrend de producten van VMware of voor toepassingen die hier niet aan bod komen, zie website VMware [3].

34

Hoofdstuk 5. VMware ESX

5.1.2

VMware ESX

VMware ESX behoort tot de hypervisor familie, een techniek die VMware al jaren beheerst en ook verder heeft verfijnd. De afkorting ESX heeft geen betekenis maar zou vroeger gestaan hebben voor Electric Sky eXclamation”. VMware ESX installeert men op de fysieke server ” , ook wel bare metal genoemd, en voegt zo een virtualisatielaag toe tussen hardware en het virtueel OS. VMware ESX zorgt ervoor dat er verschillende VMs tegelijk naast elkaar draaien op één virtuele server. Elke VM is uitgerust met processoren, geheugen, netwerk, opslag, en bios zodat Windows, Linux, Solaris en Netware OSs virtueel kunnen ge¨ınstalleerd worden.

5.1.3

De console

Als VMware ESX wordt ge¨ınstalleerd krijg je automatisch een console die je kan gebruiken voor allerhande configuraties en het beheren van de VMs. Deze console is een aangepaste Red Hat 7.2 distributie zodat deze de VMkernel kan beheren. Om op afstand deze console te gebruiken is SSH default enabled. De console wordt door de VMkernel aanzien als een VM. Probeer dus geen zware toepassingen te gebruiken op de console omdat deze resources van de virtuele machines gebruikt. De /proc/vmware directory bevat informatie over de VMware ESX server virtualisatie laag in de virtuele machines. Hiervoor kan je het cat commando gebruiken om info op te vragen of het echo commando om bepaalde waarden weg te schrijven naar bestanden in het proc filesysteem. Deze informatie is echter ook beschikbaar via de VMware Management interface (VMware Infrastructure Client (VI client)) en het is aangeraden dat je via deze weg informatie opvraagt of wegschrijft. Zie 5.1 voor extra commando’s in de console.

5.1.4

Architectuur van VMware ESX

Bare-metal architectuur. VMware ESX plaatst een robuuste virtualisatie laag op de server hardware om zo dicht mogelijk bij de native prestaties te komen en toch betrouwbaar en schaalbaar te zijn.

5.1.5

VMware ESX 3.5 nieuwigheden

-Sata disk drivers support voor ESX Server 3.5 installatie. -Nieuw File systeem : VMFS3 (Virtual Machine File System) Oudere versies van vmware kunnen niet werken met dit filesysteem. -Nieuw virtueel machine formaat : VM3 -Update van de VMware tools. -VI Client installatie files downloadbaar via een webinterface op de VMware ESX server. Deze interface is bereikbaar door te surfen naar het IP adres van de server.

35

Hoofdstuk 5. VMware ESX -64GB RAM toegelaten voor virtuele machines. De meest geheugen intensieve workloads in VMs met een geheugen limit zijn nu uitgebreid tot 64GB. -Support voor krachtige fysieke machines. Gebruik maken van zware server systemen tot 32 cpu kernen en 256GB Ram voor consolidatie op grote schaal. -Lokaal SATA opslag support. Maak gebruik van Servers met locale SATA opslag voor een verdere daling van de total cost of ownership en tegelijk het consolideren van workloads. -Support Windows Vista OS -Verbeterde virtuele machine performantie door: Netwerk optimalisatie:

reduceren van de CPU overhead geassocieerd met netwerk i/o.

Support voor hardware nested page tables : Optimalisatie van memory translition time tussen guest OS en fysiek geheugen. Support voor large memory pages : verbeteren van geheugen toegang en efficientie voor guest OS en de hypervisor. Parvirtualisatie voor Linux OS : vanaf Linux kernel 2.6.21, performanter werken door virtualisatie bewuste Operating systems te gebruiken.

5.2 5.2.1

VMware ESX ontleding VMFS

Het Virtual Machine File System is een performant cluster file systeem dat geoptimaliseerd is voor de virtuele server opslag omgeving. Alle onderdelen van de virtuele machine worden automatisch in één map geplaatst. Er wordt ook voor elke nieuwe VM een subdirectory aangemaakt. VMFS zorgt voor de fundamenten van virtualisatie gespreid over verschillende servers waardoor services zoals Vmotion, Distributed Resource Scheduler en VMware High Availability kunnen toegepast worden. Omdat dit een cluster filesysteem is moeten we rekening houden met alignment. Eigenschappen van VMFS - Maximum virtual disk size: 2 TB - Maximum file size:2 TB max - Block size: 1MB to 8MB

5.2.2

Onderdelen van een VM

Uit welke files bestaat een VM in VMware ESX nu?

36


1

3

5

7

9

l s − l / vmfs / volumes / s u n f i r e \ : s t o r a g e 1 / Win2K3 32Oltp / t o t a l 15729344 −rw−r−−r−− 1 root root 37738 May 23 1 6 : 3 4 vmware . l o g −rw−−−−−−− 1 root root 16106127360 May 23 1 6 : 3 4 Win2K3 32Oltp− f l a t . vmdk −rw−−−−−−− 1 root root 8684 May 23 1 6 : 3 4 Win2K3 32Oltp . nvram −rw−−−−−−− 1 root root 406 May 23 1 6 : 2 7 Win2K3 32Oltp . vmdk −rw−−−−−−− 1 root root 0 Apr 22 1 6 : 0 2 Win2K3 32Oltp . vmsd −rw−r−−r−− 1 root root 1878 May 23 1 6 : 2 6 Win2K3 32Oltp . vmx −rw−−−−−−− 1 root root 268 May 21 1 2 : 0 6 Win2K3 32Oltp . vmxf

.log Deze file houdt de logging van de virtuele machine bij. Dit kan handig zijn bij eventuele trouble shooting. .nvram Deze file houdt de instellingen van de VM zijn BIOS bij. .vmdk Dit is een Disk DescriptorFile, hier worden de instellingen van de virtuele harde schijf bijgehouden.. inhoud: 1

3

5

7

# Disk D e s c r i p t o r F i l e v e r s i o n =1 CID=6f a 5 e 0 0 2 parentCID= f f f f f f f f c r e a t e T y p e=”vmfs ” # Extent d e s c r i p t i o n RW 31457280 VMFS ” Win2K3 32Oltp− f l a t . vmdk”

9

11

13

15

17

19

# The Disk Data Base #DDB ddb . t o o l s V e r s i o n = ”7299” ddb . adapterType = ” l s i l o g i c ” ddb . geometry . s e c t o r s = ”63” ddb . geometry . heads = ”255” ddb . geometry . c y l i n d e r s = ”1958” ddb . uuid = ”60 00 C2 91 83 a6 9 f 3a−ca b8 9d c3 64 5d 9 f be ” ddb . v i r tu a l HW V e rs i o n = ”4”

-flat.vmdk Dit is de eigenlijke virtuele harde schijf. .vmsd In dit bestand staat informatie en metadata ivm de snapshots. .vmx Dit is het hoofd configuratiebestand, de settings van de virtuele machine worden hier bijgehouden. Bij oudere versies van VMware ESX kan dit bestand de extensie .cfg hebben. .vmxf Dit is een extra bestand dat wordt gebruikt in een team van verschillende VMs. .vswp Swapfile voor de virtuele machine. De bios gebruikt voor de virtuele machines is PhoenixBIOS 4.0 Release 6. 37


5.2.3

VMware tools

Niet vergeten de VMware tools te installeren op uw virtuele machine. Deze tools verbeteren de grafische prestaties van de VMs aanzienlijk door gebruik te maken van de VMware tools SVGA driver. Ook krijg je door het VMware Tools package de mogelijkheid om gebruik te maken van ”shared folders”, en drag and drop operaties. Andere tools in de package zorgen voor tijdsynchronisatie met tussen guest en host, automatisch vastnemen en loslaten van de cursor, copy-paste tussen guest en host, optimalisatie van de muis-snelheid. De installers voor VMware Tools voor Windows, Linux, FreeBSD en NetWare guest operating systems zijn ingebouwd in de VMware Workstation als ISO files.

5.3 5.3.1

Monitoring in VMware ESX VMware Infrastructure Client

De eerste manier om esx te monitoren is via de VI client. Indien je de host of één van de VMs aanklikt dan kan je naar het tabblad Performance. Hier zie je realtime grafieken die de prestaties weergeven van bepaalde elementen. Deze kan je selecteren in het keuzevak bovenaan (zie 5.2).

Figuur 5.2: Performance in VIC.

5.3.2

esxtop

Met de VMware esxtop tool krijgen we een realtime (elke 5 seconden default) overzicht van de ESX Server worlds. De term world verwijst naar processen die draaien op de VMkernel. Er zijn 3 types van werelden : System Dit zijn de verschillende system services. Deze bevatten één idle world per fysieke CPU die runt als er geen belasting is op die fysieke CPU, helper worlds voor asynchrone taken en driver worlds. 38

Hoofdstuk 5. VMware ESX Service Console Dit is de wereld van de service console, die runt altijd op CPU0. Virtual Machine Dit is de wereld voor elke virtuele CPU. (belangrijk bij het troubleshooten) Esxtop laat ons dus toe CPU en geheugen verbruik, Disk en network bandwidth te monitoren. Via redirection kunnen we dan de output doorverwijzen naar een (komma separated) tekstbestand. 1

e s x s e r v e r# e s x t o p > b e s t a n d . t x t

voor een volledige comandolijst voor esx verwijs ik u door naar de manual van esxtop. 1

e s x s e r v e r# man e s x t o p

5.4

Andere VMware toepassingen

Zoals eerder vermeld heeft VMware een volledige infrastructuur dus is het wel nodig een korte uiteenzetting te doen over al deze elementen.

5.4.1

VirtualCenter Agent :

De VirtualCenter Agent werkt als een mini-VirtualCenter Server en heeft volgende functionalliteit: -Bundelt en dwingt de beslissingen van resource toewijzingen af gemaakt door VirtualCenter en de DRS engine.] -Geeft commandos voor configuratie veranderingen van de host agent door aan de VM.] -Geeft host configuratie commandos door aan de host agent.] -Verzamelt performance statistieken, alarms, error condities van de host agent en zend die door naar de VirtualCenter Server.]

5.4.2

Consolidated Backup :

Maakt het altijd mogelijk om een backup van een draaiende VM te nemen.

5.4.3

Update Manager :

Zal alle patches en updates voor de virtuele infrastructuur automatisch laten uitvoeren.

5.4.4

VMware HA :

VMware High Availability laat toe om de virtuele machines op een VMware ESX Server automatisch te laten herstellen van een host failure. Als de host uitvalt worden alle virtuele machines onmiddelijk opgestart vanop een andere host in de infrastructuur. (zie 5.3) 39


Figuur 5.3: VMware HA.

5.4.5

VMotion :

VMotion maakt het mogelijk om virtuele machines over te zetten naar een andere fysieke server en dit allemaal zonder de virtuele machine te hoeven afsluiten.(zie 5.4)

Figuur 5.4: VMotion.

5.4.6

Storage VMotion :

Storage VMotion biedt de mogelijkheid om de extra opslag schijven van de virtuele machine te migreren naar een andere fysieke storage array.(zie 5.5)

5.4.7

VMware DRS :

Het Dynamically Allocate System Resources systeem zorgt ervoor dat de beschikbare resources dynamisch worden toegewezen aan de hand van VMware Distributed Resource Scheduler (DRS). DRS gaat het gebruik van de resources monitoren om zo de beschibare resources op een intelligente wijze toe te wijzen aan de verschillende VMs, dit allemaal gebaseerd op vooraf vastgestelde regels. Wanneer de resources van een VM te klein worden kan een overschot van capaciteit op een andere fysieke server gebruikt worden door live migration aan de hand van VMotion. (zie 5.6) 40


Figuur 5.5: Storage VMotion.

Figuur 5.6: DRS.

5.4.8

Virtual Center Server :

Dit is een centrale management service voor het configureren, aanmaken en het beheren van de virtuele omgevingen. Met virtual center is het mogelijk meerdere VMware ESX hosts samen te brengen en hun fysische resources gecombineerd en efficiënt te gebruiken. Virtualisatie services zoals VMotion, HA, DRS en VCB gebruiken de informatie van de Virtual Center Server om zo een optimaal, efficiënt en high available datacenter te creëren De vier onderdelen van Virtual Center Server zijn: VirtualCenter Management agent op elke VMware ESX host. VMware Infrastructure API bevat interfaces met andere VMware Virtual Center clients alsook met third party” oplossingen. ” Database Interface om data van host configuraties ,virtuele machine configuraties, resources, preformance statistieken, events, alarms, permissies van gebruikers en dergelijke op te slaan. Een Active Directory interface om gebruikers toegang te controleren.

41


5.5

Maintenance en Standby Modes

Je kan de VMware ESX server in maintenance mode en standby mode gaan plaatsen, beide modes hebben vele gelijkenissen. Zo verhinderen beide modes dat er nog virtuele machines werken. Toch hebben beide modes een verschillend doel. De VMware ESX server kan je in één van de gewenste modes plaatsen via de VI client.

5.5.1

Maintenance Mode

Zowel standalone hosts als hosts in een cluster kunnen in maintenance mode geplaatst worden. Deze mode beperkt de activiteiten van VMs zodat deze kunnen uitgeschakeld worden in voorbereiding voor de uitschakeling van de host. Zolang de host in maintenance mode zit laat hij niet toe dat er VMs worden opgestart. Als de server in een cluster zit kan je de optie evacuate powerd-off VMs” meegeven , dit zorgt ervoor dat de uitgeschakelde VMs worden ” gemigreerd naar een andere host.Deze mode wordt gebruikt om bijvoorbeeld extra geheugen toe te voegen aan de fysieke server.

5.5.2

Standby Mode

Wanneer een host machine in standby mode staat is die eigenlijk uitgeschakeld.

42


Tabel 5.1: Speciale console commando’s. /proc/vmware Entry chipset config debug filters interrupts log loglevels mem net pci procstats pshare rpcstats sched scsi shrdev stats swap thermmon timers uptime vm vmkperf watchpoints

Console commando’s Description State of interrupt controllers. Advanced ESX Server parameters available through the VMware Management Interface. Debugging information. Network traffic shaping. Used, together with chipset, to determine the state of interrupt controllers. VMkernel log output. Amount of debug logging. Memory parameters. Configuration and statistics for virtual NICs and bond devices State of PCI adapters in the system. Statistics for the /proc/vmware directory Page sharing statistics for memory resource management. Statistics on remote procedure calls (RPCs). Scheduler statistics on memory and CPU. Information on SCSI devices and mappings between storage controllers and virtual machines. Statistics on shared devices. Counts of various low-level events in ESX Server. Swap statistics. Thermal monitoring information for each processor. State of ESX Server internal timed event scheduler. ESX Server uptime. Statistic for individual virtual machines by VMID. Statistics on ESX Server performance. Statistics for debugging.

43

Hoofdstuk 6

Praktisch gebruik van VMware ESX 6.1

VMware ESX 3.5 installatie

De installatie van VMware ESX 3.5 is snel en eenvoudig. Starten doet men zoals bij vele installaties door de cd-rom in de server te plaatsen. Bij het booten van de server krijgen we volgend startscherm:

Figuur 6.1: Installatie VMware ESX.

We kunnen de keuze maken tussen Graphical of Text Mode installatie van VMware ESX 3.5. De Text Modus wordt enkel gebruikt indien de muis of video controller van uw server niet goed werkt, de Graphical Mode wordt aangeraden. Na het testen van de cd-rom op enige gebreken start de installatie wizard van VMware ESX, 44

Hoofdstuk 6. Praktisch gebruik van VMware ESX hier worden enkele configuraties gevraagd zoals keyboard en muis instellingen.Om te kunnen installeren moeten we de licentie overeenkomst aanvaarden.Er wordt gekozen voor de default partitionering. Vervolgens krijgen we een overzicht van de partitionering.

Figuur 6.2: Partitionering VMware ESX.

Deze lay-out wordt standaard genomen en zullen we dus niet wijzigen,op het volgende scherm is de optie Edit default bootloader configuration vereist. Zo zal VMware ESX ervoor zorgen dat er een (grub) bootloader op de machine komt. Hierna kan de netwerk configuratie gewijzigd worden. Het voorlaatste scherm laat ons toe om de tijdzone te gaan instellen. Als laatste scherm krijgen we nog een overzicht van de gekozen installatie, klik hier op next en dan wordt VMware ESX op de server ge¨ınstalleerd. Eens de installatie is afgelopen moet er nog eenmaal op finish geklikt worden. Hierna wordt de server herstart in VMware ESX.

Figuur 6.3: VMware ESX startscherm.

45

Hoofdstuk 6. Praktisch gebruik van VMware ESX

6.2

Aligneren

Track alignment van de VMFS partities zorgt voor een verbetering van I/O performantie (lagere latency an betere throughput). De ”best practice”,aangeraden door VMware, is het aanmaken van partities via VI client. Dit zal automatisch resulteren in 64KB-gealigneerde partitie tabel. 1

3

f d i s k / dev / s d c ”n” ( nieuwe p a r t i t i e ) , ”p” ( primary ) , ”1” ( p a r t i t i e #1) , 2 xEnter ( d e f a u l t s ) , ”x” ( e x p e r t mode ) , ”b” ( s t a r t b l o k k e n s p e c i f i r e n ) , ”1” ( p a r t i t i e #1) , ”128” ( a l i g n e r e n ) , ” r ” ( normale mode ), ” t ” ( p a r t i t i e t y p e ) , ”1” ( p a r t i t i e #1) , ” f b ” (= vmfs volume ) , ”w” ( o p s l a a n en f d i s k afsluiten )

Nu zien we dat in de folder /vmfs/devices/disks/vmhbaxxx er een vmhbax:x:x:1 bijgekomen is, dit is de nieuwe partitie die we nog moeten formateren om in te kunnen zetten. Dit kan met de vmkfstools utility: v m k f s t o o l s −C vmfs3 −b 1m −S mijnLUN / vmfs / d e v i c e s / d i s k s /vmhba1 : 1 : 0 : 1

-C is verplicht en is het type filesysteem, -b is optioneel en is de blokgrootte (1 m, 2 m, 4 m & 8 m mogelijk), -S is het optionele label.

6.3

VMware Infrastructure Client (VIC)

De VI client is de” tool om uw virtuele machines te beheren, instellingen te veranderen, en ” storage toe te voegen aan de fysieke server. Deze handige tool kan men afhalen door gewoon te surfen naar het IP adres van de VMware ESX server.

6.3.1

Overzicht van de host

Algemeen Hiervoor selecteren we de host in het rechterveld, deze wordt aangeduid aan de hand van de computernaam van de fysieke server.

Figuur 6.4: Host overzicht in VIC.

46

Hoofdstuk 6. Praktisch gebruik van VMware ESX Getting Started : Hier staat een korte uitleg wat een host is en kan er wat extra uitleg over de VMware Infrastructure worden opgevraagd. Ook kan men hier een VM aanmaken of importeren. Summary : Geeft u een overzicht over de fysieke server, merk, model, aantal processoren, type processoren, gebruik van de machine en hoeveel opslag er is. Hier kan men de fysieke server ook afleggen, herstarten, in Maintenance Mode” gaan, een resource pool ” toevoegen of een nieuwe virtuele machine aanmaken. Virtual Machines : Hier is er een overzicht van de VMs met hun status en verbruik. Men kan de kolommen naar wens aanvullen met extra data of een lijst van die data exporteren naar een bepaald formaat (.html, .csv, .xml, .xls) Resource Allocation : Hier krijgt men een overzicht welke VM bepaalde resources gebruikt. Ook worden bovenaan de totalen weergegeven. Performance : Deze pagina geeft u realtime grafieken van prestaties, men kan deze prestaties opslaan als .jpg maar nog handiger is report performance (zie monitorring). De grafiek kan losgekoppeld en handmatig herladen worden. Configuration : Op deze pagina kunt u verschillende hardware settings bekijken en instellen. Een in mijn ogen belangrijke instelling is bijvoorbeeld Virtual Machine Startup/S” hutdown” , ga hier naar properties en u hebt de mogelijkheid de virtuele machines te laten opstarten met esx. Dit kan handig zijn na bijvoorbeeld stroompanne, eens de VMware ESX server is gestart starten de virtuele machines automatisch op. Ook firewallsettings kunnen hier worden aangepast. Users & Groups : Hier krijgt men een overzicht van de gebruikers en de groepen het is natuurlijk mogelijk om hier extra gebruikers en groepen toe te voegen. Events : Hier krijgt men een overzicht van alle events die hebben plaatsgevonden op de VMware ESX Server. Permissions : Hier kan men de persmissies van bepaalde gebruikers instellen de keuzes zijn read only”, Administrator”, no access”. ” ” ”

6.4

Virtual Machine (VM)

U krijgt deze tabs ook als men een VMaanklikt links in het overzicht. De meeste tabs geven hetzelfde terug als bij de host maar dan over de geselecteerde virtuele machine, er zitten echter twee nieuwigheden bij.

47


Figuur 6.5: VM overzicht in VIC.

Getting Started : Hier kan men de VM gaan starten of de settings ervan aanpassen, ook is er een korte uitleg over VMs. Console : Hier kan men remote inloggen op uw virtuele machine, hier merkt men ook de voordelen als de VMware tools hebt ge¨ınstalleerd. Dit venster kan losgekoppeld worden door rechts te klikken op de virtuele machine en open console” te kiezen. ”

6.4.1

Toolbar

Deze handige toolbar bovenaan laat u toe verschillende toepassingen, commando’s te lanceren. Terug is er een verschillende layout voor de fysieke server of een virtuele server. De functionaliteit wanneer de fysieke server geselecteerd wordt is eerder beperkt, men kan een nieuwe VM aanmaken of een resource pool creëren. Bij de virtuele machine krijgt men echter de volgende toolbar te zien:

Figuur 6.6: Toolbar in VIC.

De twee blauwe pijlen zijn volgende of vorige. De rode vierkant sluit de virtuele machine af, vergelijkbaar met het uittrekken van de stroom. De pauze knop staat voor suspend. In de suspend mode wordt de huidige staat van de virtuele machine opgeslaan alvorens die uit te schakelen zo is het mogelijk, als de VM terug wordt opgestart, om verder werken. Met de groene play knop schakelt een VM aan. De groene en rode pijl herstarten een VM De belangrijkste knoppen zijn echter connect floppy en connect cd/dvd hiermee is het mogelijk een iso ,vanaf de pc waar VI client draait, mounten in de VM De knoppen hiernaa dienen om snapshots te nemen, terug te keren naar een bepaald snapshot of de snapshots beheren. Met de laatste knop opent één console naar de machine.

48


6.4.2

Nieuwe Machine aanmaken

Om een nieuwe virtuele machine aan te maken gebruiken we,in dit voorbeeld, VI client. we selecteren de fysieke machine en dan via rechtsklik, file/new/virual machine of de sneltoets ’ctrl+n’ om de New Virtual Machine Wizard” te starten. De volgende manieren om de ” nieuwe machine te configureren kunnen gekozen worden: Typical Name and Location De naam van de nieuwe virtuele machine. Datastore Hier kan men kiezen waar de virtuele machine wordt opgeslaan. Guest OS Welk besturingssysteem komt op de viruele machine? Microsoft,Linux,Novell Netware, Solaris, Other. Elke keuze geeft u onderaan een combobox die verschillende versies (bijvoorbeeld Windows Server 2003, 32 of 64bit). CPU’s Het aantal VCPUs, minimum 1 en maximum 4, die worden toegewezen aan de virtuele machine. Memory Hoeveelheid ram die de virtuele machine kan/mag gebruiken. Network Aantal virtuele netwerkkaarten. Zet het vinkje Connect at Power On aan, dan wordt de netwerkkaart ingeschakeld bij het opstarten van de VM. Afhankelijk van het gekozen OS is er de keuze uit een van de volgende netwerk adapters: vlance - AMD Lance PCNet32 ethernet adapter De meeste OSs,zowel 32bit1 als 64bit, bieden support voor de vlance ethernet adapter. Hierdoor kan de vlance virtuele adapter gebruikt worden zonder extra drivers te installeren. e1000 - Intel e1000 ethernet adapter De vlance adapter werd vervangen door de e1000. De enige adapter die support heeft in Windows Vista 32bit, wordt gebruikt voor alle 64bit guest OSs. De e1000 driver zit ook ingebakken in de meeste OSs en voorziet hierdoor een snel werkende netwerk connectie en betere performantie dan de vlance adapter. vmxnet - VMware high speed virtual ethernet adapter Vmxnet, een geparavirtualiseerde adapter gebruikt voor hoge I/O performantie, werd ondersteund door de meeste 32bit guest OSs. Het is wel vereist de VMware tools te installeren om toegang te hebben tot de vmxnet driver. Zonder de VMware tools werkt deze adapter zoals een vlance adapter. ESX Server 3.5 heeft nu een enhanced-vmxnet adapter aan boord voor de meeste OSs. Voor deze adapter is er support voor de 64bit OSs en voegt extra features toe, bijvoorbeeld TCP 1

Bij 32bit systemen wordt deze adapter afgebeeld als ’flexible’ adapter.

49

Hoofdstuk 6. Praktisch gebruik van VMware ESX Virual Disk Capacity: Hoe groot moet de virtuele harde schijf zijn die wordt toegewezen aan deze nieuwe virtuele machine? Ready to Complete New Virtual Machine: Hier staat een overzicht van alle gekozen instellingen en is het mogelijk nog eens extra opties gaan aanpassen door onderaan Edit the virtual machin settings before submitting” aan te vinken. ” Custom Name and Location: Zie Typical. Datastore: Zie Typical. Guest Operating System: Zie Typical. CPU’s: Zie Typical. Memory: Zie Typical. Network: Zie Typical. I/O Adapters: Er zijn twee soorten adapters SCSI en IDE. Voor IDE wordt er altijd gekozen voor de ATAPI driver. Verder kan men kiezen welke soort van SCSI Adapter, er is de keuze tussen LSI logic of Buslogic. Default gebruiken virtuele machines de BusLogic adapter gebruikt.Uitzonderingen zijn Windows Server 2003,Red Hat Enterprise Linux 3 en Netware die default de LSI logic adapter gebruiken. Indien men de LSI logic adapter wenst te gebruiken op een andere virtuele machine (bijvoorbeeld Windows XP of 2000) dan moet de LSI20320 SCSI adapter driver gedownload worden van op de site van LSI2 . Belangrijk Linux distributies met een kernel vanaf 2.4.18 bieden support voor de LSI Logic adapter. Hier moet dan ook de driver gedownload worden bij LSI. Select a Disk: Hier is het mogelijk een nieuwe virtuele harde schijf aanmaken, een bestaande gebruiken of gewoon geen hard disk aanmaken. Disk Capacity: Zie Typical. Advanced Options: Disk mode : Normal of Independent: De default, Normal mode omvat de huidige staat van de disk in elke snaphot die genomen wordt.Als men niet wenst dat de data op de disk wordt meengenomen in de snaphot dan kan Independent aangevinkt worden. Wanneer voor de optie Independent gekozen 2

http://www.lsi.com

50

Hoofdstuk 6. Praktisch gebruik van VMware ESX wordt is er de mogelijkheid de mogelijkheid om Persistent of Nonpersistent te kiezen. De eerste optie zorgt ervoor dat alle data onmiddelijk en permanent naar de disk wordt geschreven, de tweede optie doet dat niet ook al wordt de machine uitgeschakeld. Ready to Complete New Virtual Machine: Zie Typical

6.5 6.5.1

Installatie VMware Tools Windows 2003 Server

Hier volstaat om in de VI client uw Windows VM, die moet geboot zijn, rechts aan te klikken en kies Install VMware Tools. Log als administrator in op de VM en als autorun enabled is op die machine wordt er gevraagd of de installatie wizard gestart mag worden, klik yes. Op Windows 2003 Server wordt de SVGA driver geinstalleerd en zal de VM automatisch herstarten.

6.5.2

Sles10

VMware tools installeren op een linux client doen we het best via de command line. Natuurlijk moet de machine eerst aangezet worden, eens volledig opgestark klik rechts op de machine in de VI client en kies Install VMware Tools. Vervolgens werken we via de console, om de commandline 3 van de guest te gebruiken, de rest van de installatie af. 1

E e r s t moeten we de k e r n e l s o u r c e i n s t a l l e r e n : y a s t − i g c c k e r n e l −s o u r c e

3

5

7

De cd−rom−d r i v e moet gemount worden : mount / dev / cdrom /mnt/ cdrom De t a r met f i l e s v o o r vmware t o o l s moeten we ” ‘ u i t p a k k e n ” ’ : t a r z x p f /mnt/ cdrom /VMwareTools −5.0.0−<xxxx >. t a r . gz

9

11

13

De cd−rom d r i v e unmounten : umount / dev / cdrom Ga naar de j u i s t e map : cd vmware−t o o l s −d i s t r i b

15

17

19

S t a r t de \vmw T o o l s i n s t a l l e r : . / vmware− i n s t a l l . p l H i e r moeten e r e n k e l e v r a g e n beantwoord worden , om d e f a u l t i n s t e l l i n g e n t e a c c e p t e r e n h o e f t men e n k e l Enter t e drukken .

3

Voor deze configuraties zijn root rechten vereist.

51


6.6

Settings van de Virtuele machines

De settings van een virtuele machine kunnen aangepast worden door rechts te klikken op de virtuele machine , in de VMware Infrastructure Client, en dan edit settings” te selecteren. ” Let wel: vele opties kunnen niet verandert worden wanneer de VM ingeschakeld is. Hier worden enkele van de meest gebruikte opties besproken.

6.6.1

Hardware

Figuur 6.7: VMware virtual machine options.

Memory: de grote van de virtuele ram. CPUs: het aantal virtuele CPU’s. Floppy Drive1: Device Status: Het vinkje Connect at power on is beschikbaar wanneer kiezen voor een floppy image aan te maken of een bestaande floppy image te gebruiken. Dit zal image als floppy disk mounten bij het opstarten van de VM. Device Type: Client Device : dit is de floppy drive op de pc waarop de VI client runt. Host Device : dit is de floppy drive op de fysieke server waarop VMware ESX staat. Use existing floppy image in datastore : dit is een iso file die is opgeslaan op de VMware ESX server en die gemount wordt als floppy drive. Create new floppy image in datastore : hier is er de mogelijkheid een floppy image te gaan creëren en op te slaan op de VMware ESX server. 52

Hoofdstuk 6. Praktisch gebruik van VMware ESX CD/DVD Drive1: Device Status: Het vinkje Connect at power on is beschikbaar wanneer kiezen voor het gebruik van Host Device of Datastore ISO file. Wat het doet is de image als floppy disk mounten bij het opstarten van de VM. Device Type : -Client Device: dit is de cd-rom drive op de pc waarop de VI clientrunt. -Host Device: dit is de cd-rom drive op de fysieke server waarop VMware ESX staat. -Datastore ISO file: hier kan er een iso file van op de datastore gemount en gebruikt worden als cd-rom. Mode : Deze settings kunnen enkel aangepast worden als er voor Client Device wordt gekozen. Passtrough Integrated Drive Electronics (IDE) : dit geeft ons de mogelijkheid om de cd-rom drive te reserveren enkel voor deze VM. Emulate IDE : hiermee wordt de IDE ADD : met deze knop kan er extra virtuele hardware toevoegt worden.

6.6.2

Options

Hier kunnen we verschillende algemene opties van de VM overlopen en instellen. Deze instellingen worden echter zelden gebruikt.


6.6.3

Resources

De belangrijkste setting hier vindt men bij Advanced CPU. Hier is het mogelijk de affinity instellen van processoren, dit betekent dat de VM enkel de aangevinkte processoren zal 53

Hoofdstuk 6. Praktisch gebruik van VMware ESX gebruiken. Zo kunnen we zorgen voor een totale afscheiding tussen de verschillende VMs.


6.7 6.7.1

Troubleshooting KERNEL MOUNTING FAILED

Na de installatie van VMware ESX Server 3.5 op enkele machines met de onboard nVidia MCP55 sata controller krijgt men bij de eerste herstart :

3

I n v a l i d c o m p r e s s e d f o r m a t ( e r r =2) <6>F r e e i n g i n i t r d memory : 7508K f r e e d VFS Cannot open r o o t d e v i c e UUID=a 1f 2 8d 4 9 −8a1a−4 c c f −9abf −8a 3 8 a e 7 6 8 a 9 8 o r 0 P l e a s e append a c o r r e c t r o o t= boot o p t i o n

5

K e r n e l p a n i c : VFS Unable t o mount r o o t f s on 0 0 : 0 0

7

K e r n e l 0 xc0100000 s . data 0 x c 0 3 8 c 0 0 0 −s . b s s 0 xc0443380

1

Dit komt omdat VMware ESX een xml bestand aanmaakt met een lijst van alle SATA controllers en hun id’s.Door een bug in VMware ESX 3.5 maakt hij maar 1 controllerpoort aan voor de MCP55. Dit kunnen wij handmatig aanpassen: Start VMware ESX in troubleshoot mode. In de console : Eerst de rechten aanpassen om te kunnen schrijven in het xml bestand

2

#chmod +w / e t c /vmware/ p c i i d / s a t a n v . xml #v i / e t c /vmware/ p c i i d / s a t a n v . xml

Onderaan moeten we dit toevoegen. Let erop dat het device met id ’037e’ reeds bestaat en we een device met ’037f’ moeten toevoegen: 54


2

4

6

s a t a n v MCP55 SATA C o n t r o l l e r

We testen of deze aanpassing correct is door volgende programma te runnen 1

#e s x c f g −p c i i d

Nu zien we een aantal loading, writing en replacing lijnen. We moeten de rechten nu opnieuw juist zetten 1

#chmod −w / e t c /vmware/ p c i i d / s a t a n v . xml

Herstart nu het systeem, het probleem is opgelost.

6.7.2

Problemen met de AMD Opteron 8356 CPU.

Hieronder geef ik een overzicht wat er allemaal nodig was om een bepaalde machine klaar te stomen voor een werkende VMware ESX installatie. De Hardware: Type server : SuperMicro A+ Server 201M-UR+B Chipset/Moederbord : SuperMicro H8DMU+ CPU 2x AMD Opteron 8356

Figuur 6.10: QuadBarcelona CPU.

Ram : 8x 1 GB 55

Hoofdstuk 6. Praktisch gebruik van VMware ESX Storage : DAS 6x Seagate Cheetah 300 GB 15K5 , 1 x Baracuda 250 GB (OS), 1x Barracuda 7200.10 320 GB (opslag VM) Raid kaart : LSI Logic MegaRAID SAS 8344ELP Het eerste werk was een verse installatie van VMware ESX 3.5 hier dook al echter een probleem op, de installatie die uiteraard via de grafsiche interface zou moeten verlopen versprong naar de text interface. Toen de installatie beëindigd was en de machine wenste te booten in VMware ESX dook het eerste probleem op , plots kreeg ik onderstaande code. 1

0 xbad001e

Het gevolg hiervan was dat VMware ESX niet volledig gestart was en er dus niet veel met de machine kon worden aanvangen. Na wat opzoekwerk bleek deze fout hetvolgende te zijn :

1

VMK UNSUPPORTED CPU 195887134 0 xbad001e ENODEV Unsupported CPU

Ondertussen werden de CPU’s terug uit de machine verwijderd en vervangen door de oudere AMD Opteron K8 versies. Met deze CPU’s werkte de machine optimaal en zo was het mogelijk alle instellingen op VMware ESX te vervolledigen. Toen de processoren terug vrij kwamen werd een nieuwe versie van de BIOS ge¨ınstalleerd, eenmaal dit gedaan te hebben leek alles goed te verlopen tot de volgende melding verscheen tijdens het opstarten: 1

3

5

7

I n i t i a l i z i n g C r y p t o g r a p h i c API NET4 : Linux TCP/ IP 1 . 0 f o r NET4. 0 IP : r o u t i n g c a c h e hash t a b l e o f 2048 b u c k e t s , 16 k b y t e s TCP : Hash t a b l e c o n f i g u r e d ( e s t a b l i s h e d 32768 bind 6 5 5 3 6 ) NET4 : Unix domain s o c k e t s 1 . 0 /SMP f o r Linux NET4. 0 VFS : Cannot open r o o t d e v i c e ”UUID=534860 c5−a65c −4e29 −8a7d−5e 9 3 f 7 d 4 f 3 d 1 ” o r 0 0 : 0 0 P l e a s e append a c o r r e c t ” r o o t =” boot o p t i o n K e r n e l p a n i c : VFS : Unable t o mount r o o t f s on 0 0 : 0 0

9

k e r n e l 0 xc0100000 −s . data 0 xc0380000 −s . b s s 0 xc0438380

Om dit op te lossen moest er worden opgestart in troubleshooting mode, inloggen en hetvolgende commando werdt uitgevoerd. e s x c f g −boot −b

Dit commando herbouwt de boot record. Eens dit gedaan te hebben kon de server heropgestart worden. De boot procedure verliep vlekkenloos tot de server op het inlog scherm kwam :

56


Figuur 6.11: Snapshot disabeling access.

Hier werd gedacht aan een probleem met VMware ESX omdat de CPU’s recenter waren dan de gebruikte VMware ESX. Dus werd er een upgrade gedaan naar een recentere versie van esx. Hiermee was het probleem echter niet opgelost, na wat verder opzoekwerk hebben we de oplossing gevonden. Desondanks de foutmeldingen kon de VI client worden gestart. Hier bleek ook dat al de luns met data niet meer zichtbaar waren. Toen moest hetvolgende gebeuren: select de host (rootnode), ga naar de Configuratie tab en kies Advanced Settings. Kies LVM en verander dan LVM.EnableResignature op optie 1. Ga dan naar Storage en klik Refresh, alle opslag is terug zichtbaar, de optie LVM.EnableResignature kon terug op optie 0 gezet worden. De server werd hierna heropgestart en alle fouten waren weg. Ook al mijn virtuele machines waren echter verdwenen, dit komt door LVM.EnableResignature. Als deze optie op 1 wordt gezet kunnen er snapshots of replicas van de VMFS volumes terug gebruikt worden maar krijgen ze een nieuw ID. Hierdoor kunnen de virtuele machines niet worden geladen omdat er nog verwezen wordt naar een ander harde schijf ID. Dit heb ik, wegens tijdsgebrek, opgelost door het creéren van nieuwe machines en de bestaande harde schijven te gebruiken.

57

Hoofdstuk 7

Benchmarks: Worst load scenario 7.1

Inleiding

De bedoeling van dit testscenario is om een vergelijking op VMM niveau te kunnen maken. Meer concreet betekent dit dat we het systeem zwaar proberen te belasten, om zo het maximum uit de beschikbare resources te halen. In deze test zou hierdoor de efficiëntie van de hypervisor in het verdelen van de fysieke resources naar boven moeten komen. Deze situatie komt niet overeen met hoe het er in een productie omgeving aan toe gaat.

Figuur 7.1: Schematische weergave van de Linux worst load testopstelling.

Dit testscenario bestaat uit vier Linux VMs met de MySQL databasesoftware ge¨ınstalleerd. Elke VM heeft de beschikking over een Logical Unit (LUN) op een RAID array voor de database. Deze machines worden als Online Transaction Processing (OLTP) systemen ingezet en er wordt gebruik gemaakt van de sysbench 1 benchmark. Onze opstelling verschilt van opzet 1

http://sysbench.sourceforge.net/

58

Hoofdstuk 7. Benchmarks: Worst load scenario met het bekende vConsolidate 2 van Intel daar we hier elke VM dezelfde workload toewijzen. Verder sluiten we een extra scheduling factor uit door de som van de VCPUs niet boven het aantal beschikbare fysieke processoren te laten komen. Onze real world testopstelling (hoofdstuk 8) voorziet wél een verschillende workload per VM; namelijk een OLTP systeem, een Online Analytical Processing (OLAP) systeem en twee webservers.

7.2 7.2.1

Opzet Sysbench: Online Transaction Processing (OLTP) benchmark

Online Transaction Processing (OLTP) systemen zijn operationele systemen, oftewel transactie verwerkende systemen, voor de ondersteuning van operationele processen zoals invoer en verwerking van data. In een OLTP omgeving dient de database dus geoptimaliseerd te zijn voor grote schrijfacties en kleine leesacties. Voorbeelden van OLTP systemen zijn Enterprise Resource Planning (ERP) en/of Manufacturing Execution Systems (MES) systemen. Naast OLTP systemen zijn er ook nog Descision Support Systems (DSSs)3 zoals OLAP4 . In ons Linux worst load testscenario maakten we gebruik van de sysbench OLTP5 benchmark. Deze test laat ons toe de database performantie in schrijfacties van een server te testen. Zo worden hier vooral de processoren en de beschikbare geheugenbandbreedte gestressed, alsook de gebruikte storage. Deze OLTP test wordt toegepast op een MySQL6 database. Belangrijk is hier de versie van MySQL, daar deze databasesoftware in het verleden niet goed van twee naar vier CPUs schaalde.

7.2.2

Algemeen sysbench testprotocol

Hier wordt het algemeen sysbench on Linux testprotocol beschreven. Dit is het standaard protocol, gegroeid uit research en verschillende testrondes, van waaruit verder gewerkt wordt, telkens door slechts één parameter te wijzigen. Het algemeen testprotocol dat geldig is over de gehele benchmarkfase, wordt nog eens samengevat in bijlage C. De gedetailleerde testconfiguraties, met bijvoorbeeld BIOS instellingen, kan men in bijlage E terugvinden. Virtuele machines Een VM krijgt vier VCPUs toegedeeld. Er wordt ook gezorgd dat deze vastgepinned zijn op de vier cores van een fysieke quadcore CPU. Verder heeft elke VM de beschikking over 4 GiB geheugen. Er is een extra harde shijf voorzien voor de images van de VMs. Ten slotte 2

http://www.intel.com/technology/itj/2006/v10i3/7-benchmarking/6-vconsolidate.htm http://en.wikipedia.org/wiki/Decision_support_system 4 http://en.wikipedia.org/wiki/Olap 5 http://en.wikipedia.org/wiki/OLTP 6 http://www.mysql.com/ 3

59

Hoofdstuk 7. Benchmarks: Worst load scenario heeft elk virtueel systeem de beschikking over een LUN op de externe Redundant Array of Independent Disks (RAID) storage. RAID configuratie De gebruikte Serial Attached SCSI (SAS) controller is de Adaptec RAID 5085 7 . Als Direct Attached Storage (DAS) wordt er gebruik gemaakt van de Promise VTrak J300s 8 met zes Seagate Cheetah 15K5 300 GiB9 SAS schijven. De snelheid van de gebruikte controller en de schijven is belangrijk, opdat deze geen beperkende factor zouden zijn in de tests. In tabel 7.1 vindt men de gebruikte RAID configuratie terug. Tabel 7.1: overzicht van de gebruikte RAID configuratie.

RAID Controller instellingen RAID Level: Stripe Size: Read Caching: Write Caching:

0 64 KiB Yes Enable Always

LUN filesysteem Om de RAID storage in verschillende LUNs te verdelen, wordt er gebruik gemaakt van Logical Volume Management (LVM). Bijkomed voordeel is dat de LUNs automatisch gealligneerd worden op fysieke onderlaag (zie sectie ?? voor meer over disk alignment). LVM zal er voor zorgen dat een Logical Volume (LV) steeds start op een veelvoud van 64 KiB vanaf het begin van het fysieke volume. Deze offset is te manipuleren door de grootte van de voorziene metadata ruimte aan te passen via de --metadatasize=<size> optie van het pvcreate commando. Een LV zal starten op het volgende veelvoud van 64 KiB, na de metadata; als men dus de standaard metadatasize van 192 gebruikt, zal de eerstvolgende LV starten op 256 KiB. Het gebruikte filesysteem op een LUN is ext3, met de -E stride=16 optie. Deze stride bekomt men door de RAID stripe size, 64 KiB te delen door de gebruikte block size, vier kilobyte, van het filesysteem. De maximale block size in een Linux systeem komt overeen met de gebruikte page size [14]; dewelke 4 KiB is voor IA-32 systemen. Het is mogelijk de Linux kernel te patchen om grotere block sizes toe te staan. 7

http://www.adaptec.com/en-US/products/sas_cards/performance/SAS-5085 http://www.promise.com/product/product_detail_eng.asp?segment=VTrak&product_id=163 9 http://www.seagate.com/www/en-us/products/servers/cheetah/cheetah_15k.5/ 8

60

Hoofdstuk 7. Benchmarks: Worst load scenario SLES10 installatie Het gebruikte Linux systeem is een SLES10 installatie (SP1/2; x86 en x86-64). Er wordt voor een installatie van het basissysteem gekozen (zonder X en dergelijke). Men dient er rekening mee te houden dat de systeempartitie geformateerd wordt met het ext3 bestandssysteem. Er wordt ook ge¨ opteerd voor de No Access Time (noatime) optie voor elke gemounte partitie in de fstab configuratie; dit is een “best practice” dat voor een (kleine) performantiewinst kan zorgen. Ten slotte dient er gecontrolleerd te worden dat het standaard runlevel ingesteld staat op 3; er is geen GUI aanwezig. Na installatie wordt het systeem volledig geupdated. De gebruikte SP1 kernel (uname -r) is 2.6.16.54-0.2.5 ; voor SP2 is dit 2.6.16.60-0.23. Verder wordt het gcc pakket nog ge¨ınstalleerd (yast -i gcc). MySQL De gebruikte MySQL versie is 5.1.23, met de large configuratie file. Er wordt een testdatabase, “sbtest”, aangemaakt. De MySQL databases (/var/lib/mysql/ ) dienen op een LUN van de RAID storage te komen. Deze LUN wordt ook gemount met de noatime optie. Sysbench De gebruikte sysbench versie is 0.4.8, en wordt vanaf source gecompileerd. Benchmarking De benchmark fase kan geheel geautomatiseerd worden door middel van een paar scripts, dewelke men terug kan vinden in bijlage F.1. Vanaf een Linux werkstation wordt het sysbench master.sh script gestart, dewelke gelijktijdig Secure Shell (SSH) connecties legt met een gespecifiëerde lijst servers. Op deze servers wordt dan het sysbench client.sh script aangeroepen. Dit script reset en prepareert MySQL (prepmysql.sh) om vervolgens het monitorscript en de benchmark te starten. Het sysbench script zal verscheidene malen een benchmark starten, naargelang de meegeleverde parameters. In ons geval wordt sysbench vier maal achtereenvolgens uitgevoerd, startende met acht threads om zo, in stappen van 8, tot 32 threads te komen. Per test zullen er 25K transacties uigevoerd worden op een recordset van 1M. De gemeten waarde is de uitvoertijd van de test, dat we omrekenen naar het aantal transacties dat uitgevoerd worden per seconde. Ook de 95 percentile latency wordt gemonitorred; deze wordt bekomen door 5 % van de langst durende transacties te laten vallen, om vervolgens het maximum van het overige deel te nemen. Met andere woorden, we meten de lanste wachttijd, na het elimineren van de grootste uitschieters. 61

Hoofdstuk 7. Benchmarks: Worst load scenario Om te kunnen vergelijken dienen de benchmarks ook in een native situatie, zonder virtualisatielaag, te worden uitgevoerd. Door de maxcpus= boot parameter te specifiëren kan men de native Linux kernel duidelijk maken hoeveel CPUs er maximaal geactiveerd mogen worden. In ons geval was dit vier voor de quad tests, en twee voor de dual tests. De waardes voor de test met vier VMs worden bekomen door de gemiddelde score te nemen van de VMs samen.

7.3 7.3.1

Xen benchmarks RAID configuratie - WriteBack vs. WriteThrough

Met deze test wilden we de impact van de Write Policy optie van de RAID controller onderzoeken. Hier zijn twee mogelijkheden, namelijk WriteBack en WriteThrough. Met de WriteThrough optie zal de controller de data die toekomt, meteen wegschrijven naar de schijven. De WriteBack optie daarentegen zal datablokken eerst bufferen in diens onboard geheugen, alvorens deze weg te schrijven. Dit brengt als voordeel, onder andere, mee dat de controller de kans krijgt om de toegezonden data te sorteren en deze dan in grote blokken kan wegschrijven. Als de WriteBack optie is ingeschakeld, dient er een batterij op de controller aangesloten te zijn opdat deze de gebufferde data veilig kan stellen bij een stroomuitval van de server.

Figuur 7.2: Sysbench: WriteBack versus WriteThrough resultaten.

Uit de resultaten, volgens figuur 7.2 en tabellen D.1 en D.2, kunnen we afleiden dat er een performantiewinst van bijna 250 % te behalen is in onze OLTP test door het inschakelen van de WriteBack optie.

62

Hoofdstuk 7. Benchmarks: Worst load scenario

7.3.2

Xen 3.0.4 - Quad Opteron 8356

Als eerste werd de AMD Opteron machine (E.1) aan de tand gevoeld. Dit is een 1U server met vier sockets aan boord, welke elk een gloednieuwe quad-core Opteron 8356 bevatten die geklokt staat op 2.3 GHz. De VMs kregen hier de beschikking over 4 VCPUs en 4 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=4 boot parameter om het OS te beperken tot vier cores.

Figuur 7.3: Sysbench: Xen 3.0.4 - Quad Opteron 8356.

Hier zien we dat deze machine in de native situatie een snelle uitvoeringstijd van gemiddeld 44, 57 s weet te behalen. Wat opvalt uit de resultaten (fig. 7.3 en tabel D.3) is de vrij grote performance drop van 24 % van een DomU tegenover de native situatie. Als we de vergelijking maken met vier draaiende VMs tegenover de native situatie, dan kunnen we een daling van 48 % opmeten. Deze waarden staven het belang van I/O performantie al; de beloofde nearnative performantie steunt enkel op CPU-intensieve taken; dewelke het meest van de tijd in usermode hun werk verrichten.

7.3.3

Xen 3.0.4 - Quad Opteron 8356 numa=on

Tijdens het uitpluizen van de xm dmesg logs, viel er ons een eigenaardigheid op. Non-Uniform Memory Access (NUMA) ondersteuning, de architectuur gebruikt door deze Opterons, werd namelijk door de Xen VMM uitgeschakeld. Na wat research bleek dat NUMA support in deze bepaalde Xen versie (3.0.4), nog in een experimentele staat verkeert. Uit nieuwsgierigheid hebben we de ondersteuning afgedwongen door de numa=on Xen bootparameter te gebruiken. De testopstelling is exact dezelfde als deze hierboven. Als we de resultaten, uit figuur 7.4 en tabel D.4, vergelijken met de vorige, kunnen we een klein 63


Figuur 7.4: Sysbench: Xen 3.0.4 - Quad Opteron 8356 numa=on.

verschil opmeten van ongeveer twee percent. Deze waardes zijn niet meteen schokkerend te noemen, en daarbij dienen we nog op te merken dat in de vorige testopstelling de architectuur al artificiëel werd afgedwongen door de VMs op de juiste CPU nodes vast te pinnen.

7.3.4

Xen 3.0.4 - Quad Xeon E7330

Vervolgens was de Intel machine (E.2) aan de beurt. Zoals de AMD server, is dit ook een 1U machine met vier sockets. In deze test werd er gebruik gemaakt van vier quad-core Xeon E7330 processoren met een klokfrequentie van 2.4 GHz. De VMs kregen hier ook de beschikking over 4 VCPUs en 4 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=4 boot parameter om het OS te beperken tot vier cores. Uit figuur 7.5 en tabel D.5 blijkt dat er hier een verlies van 10 − 12 % in OLTP prestaties optreedt als we de prestaties van een enkele DomU tegenover de native situatie plaatst. Dit is zowat een de helft minder dan bij de AMD processoren; echter liggen de native scores bij Intel ook een stuk lager met een gemiddelde van 505 transacties per seconde tegenover 565. Een verdere vergelijking tussen de machines wordt voortgezet in sectie 7.5.1. Als we vier domains draaien merken we een prestatieverlies op van 26 % tegenover de native situatie.

7.3.5

Xen 3.0.4 - Quad Xeon E7340

In deze testopstelling hebben we de Xeon E7330 processoren vervangen door de E7340. Deze CPUs verschillen maar op één punt, en dat is cache; waar de E7330 twee maal 3 MiB L2 cache heeft, bevat de E7340 twee maal 4 MiB. Op de processoren na, komt de testopstelling overeen

64


Figuur 7.5: Sysbench: Xen 3.0.4 - Quad Xeon E7330.

met de vorige (E.3). Ook hier hebben de VMs weer toegang tot vier VCPUs en wordt de native situatie wederom beperkt met de maxcpus=4 boot parameter.

Figuur 7.6: Sysbench: Xen 3.0.4 - Quad Xeon E7340.

Onze vraag is uiteraard: “Wat valt er hier te winnen door de L2 cache met 2 MiB op te drijven?”. Uit onze resultaten (fig. 7.6, tabel D.6) blijkt dat er een winst geboekt wordt van amper 2 − 4 % tegenover de E7330 processoren. In deze situatie is het dus niet meteen interessant te investeren in processoren met een iets grotere L2 cache. De grootste overhead ligt namelijk bij de hypervisor.

65


7.3.6

Xen 3.0.4 - Dual Opteron 8356

Om de schaalbaarheid van de Opteron processoren te meten, werden de sysbench tests nog eens herhaald met twee, in plaats van vier, sockets. In deze test werd er gebruik gemaakt van de AMD machine E.1, na het verwijderen van twee quadcore CPUs. De VMs kregen hier de beschikking over 2 VCPUs en 3 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=2 boot parameter om het OS te beperken tot twee cores.

Figuur 7.7: Sysbench: Xen 3.0.4 - Dual Opteron 8356.

Uit de resultaten, volgens figuur 7.7 en tabel D.7, merken we dat er een valt te behalen is van 36 % door twee extra processoren bij te voegen. Dit is minder dan we verwachtten en hier wordt in de conclusie (7.5.1) dan ook verder op ingegaan.

7.3.7

Xen 3.0.4 - Dual Xeon E7330

Om ook de schaalbaarheid van de Xeon processoren te meten, werden de sysbench tests nog eens herhaald met twee, in plaats van vier, sockets. In deze test werd er gebruik gemaakt van de Intel machine E.2, na het verwijderen van twee quadcore CPUs. De VMs kregen hier de beschikking over 2 VCPUs en 3 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=2 boot parameter om het OS te beperken tot twee cores. Ook hier merken we dat er een maar een winst optreedt van 33 % als we het systeem met vier CPUs tegenover dat met twee plaatsen (fig. 7.8, tabel D.8). In de conclusie (7.5.1) wordt hier verder op ingegaan.

66


Figuur 7.8: Sysbench: Xen 3.0.4 - Dual Xeon E7330.

7.3.8

Xen 3.2.1 - Quad Opteron 8356

Ten slotte wilden we de performantie van Xen3.0.4, dat geleverd wordt met SLES10 SP1 eens vergelijken met de laatste beschikbare versie van de VMM; namelijk versie 3.2.1. Deze diende vanaf de broncode gecompileerd te worden, waarover meer in sectie 4.2.3. Behalve de gebruikte Xen versie, is deze testconfiguratie gelijk aan E.1.

Figuur 7.9: Sysbench: Xen 3.2.1 - Quad Opteron 8356.

De scores (fig. 7.8 en tabel D.8) volgen ook hier het reeds bekende gedrag. Beide Xen versies zijn aan elkaar gewaagd; er is namelijk een kleine perfomantie winst van 3 % als er gebruik

67

Hoofdstuk 7. Benchmarks: Worst load scenario wordt gemaakt van de nieuwste Xen versie. Er dient hier wel opgemerkt te worden dat deze versie wél de NUMA architectuur volledig ondersteund. Verder ondersteund Xen3.2 ook de HAP, dewelke belangrijk zijn in een HVM opstelling (zoals in testscenario 2, sectie 8).

7.4 7.4.1

VMware benchmarks Dual Opteron 8356

Wegens driverproblemen en tijdgebrek hebben we enkel de kans gehad om VMware ESX aan deze test te onderwerpen op de Dual Opteron 8356 opstelling (zie hierboven 7.3.6). De meegeleverde VMware ESX tools werden in de VMs ge¨ınstalleerd. De resultaten zijn terug te vinden in tabel D.10. Wat opvalt zijn de enorme prestatieverliezen tegenover de native situatie. Zo zijn er verliezen gemeten van 50 − 55 % tegenover de native situatie met 32-bit VMs. Met 64-bit VMs is de situatie al beter. Er is hier namelijk een verlies in prestaties van 30 tot 40 %. Deze winst in prestaties van 64-bit tegenover 32-bit is onder andere te verklaren door het feit dat VMware ESX gebruik maakt van HAP in 64-bit mode.

7.5 7.5.1

Conclusies Xen

In de meeste publicaties zijn de testscenario’s vaak onrealistisch; men wil hun product uiteraard in een zo goed mogelijk daglicht plaatsen. Deze publicaties laten gewoonlijk een vergelijking zien tussen een native situatie, en een situatie waar het geheel gevirtualiseerd wordt uitgevoerd. Hier toont men echter steeds het resultaat in een situatie waar slechts een enkel VM draait. Van het feit uitgaande dat consolidatie de meest aangeworven toepassing is van hypervisor gebaseerde virtualisatie, is dit een zeer onrealistische testopstelling. Bij consolidatie wordt er namelijk getracht om de fysieke machine ten volle te benutten, door er zo veel mogelijk virtuele systemen op te plaatsen. Verder wordt er het vaakst getest met synthetische benchmarks, die vooral CPU intensief zijn. Maar puur rekenwerk is probleemloos te virtualiseren. De grootste virtualisatie overhead treedt echter op als er veel calls naar de hardware gemaakt worden en er veel interrupts gegenereerd worden. Met andere woorden, als er veel op I/O apparaten wordt gesteund. Als we al onze Xen sysbench resultaten met elkaar vergelijken (zie ook fig. 7.10), kan men toch heel wat interessante waarnemingen afleiden. Zo wordt ons vermoeden bevestigt dat de near-native performance uitdrukking, hier in onze testopstelling, niet opgaat. We hebben verliezen gemeten van 10 tot 25 % als we slechts een enkele VM draaien. Virtualisatie wordt echter vooral voor consolidatie ingezet, en daarom zijn de tests waar we vier VMs simultaan

68

Hoofdstuk 7. Benchmarks: Worst load scenario draaien, van groter belang. Hier kan men plots een grotere virtualisatie overhead waarnemen. Hier liggen de prestatieverliezen, vergeleken met een native situatie, al op 25 − 35 %. Hieruit kan men afleiden dat de overhead aan virtualisatie stijgt, naarmate er VMs worden toegevoegd. Een van de redenen hiervoor is de I/O afhandeling. In Xen dient deze namelijk via het Dom0 te verlopen en dient Dom0 deze van de vier guests te verwerken. Een mogelijke optimalisatie hier zou het opzetten van een extra driver domain kunnen zijn, zodoende een extra kanaal naar de fysieke hardware te creëeren. Verder wordt de scheduler capaciteiten van de VMM op de proef gesteld, alsook dienen er meer hypercalls gevalideert te worden. AMD tegenover Intel In x86 land is er de eeuwige strijd tussen Intel en AMD. De concurrentie wordt steeds hoog gehouden door het introduceren van nieuwe features, het opdrijven van snelheid, of het, tegenwoordig populaire, toevoegen van cores. De laatste twee jaar was er een grote innovatieboost, mede dankzij de stijgende populariteit van virtualisatie, en binnen nu en een jaar mogen we van beide fabrikanten weer eens nieuwe micro-architecturen verwachten.

Figuur 7.10: Sysbench: Quad Opteron 8356 en Quad Xeon E7330.

In onze tests zijn beiden aan elkaar gewaagd op vlak van virtualisatie (zie figuur 7.10). Wat opvalt is dat de Opteron processoren een vrij hoog aantal transacties per seconde weten te verwerken in de native situatie. Deze CPU’s halen gemiddeld 565, 40 transactions/s tegenover de 504, 78 transaction/s van de Xeon processoren. Dit is een winst van 12 % tegonver de Intel CPU. Als we de resultaten in een gevirtualiseerde oplossing bekijken, merken we dat de Intel CPU’s het net iets beter doen bij het uitvoeren van één VM, maar daartegenover presteert de AMD Opteron dan weer een tikkeltje beter in de situatie met vier draaiende domains. 69

Hoofdstuk 7. Benchmarks: Worst load scenario We kunnen concluderen dat AMD met de Opteron 8356 een sterk alternatief heeft voor Intel’s Xeon E7330, zeker als we daar nog eens de strommetingen van J. De Gelas bijnemen (zie fig. 7.11). Zo zien we dat de AMD processoren in alle gevallen minder stroom verbruikt dan de Intel Xeon’s. Daarbij heeft de Opteron nog eens ondersteuning voor HAP, dat een sterke impact heeft op de resultaten, bekomen in het real world Windows testscenario (zie sectie 8).

Figuur 7.11: Power metingen bij de Opteron 8356 en Xeon 7330 (lager is beter).

Schaling van twee naar vier CPUs We wilden ook eens de impact weergeven die veroorzaakt wordt door het toevoegen van processoren. Daarom werden de sysbench tests nog eens herhaald, maar deze maal werden twee CPU sockets leeggelaten. Zo kreeg elke VM ook twee VCPUs toegedeeld. Merkwaardig is dat de prestatiewinst dat wordt bekomen met vier processoren, niet in de verwachte lijn van 60 % valt. Uit onze resultaten blijkt dat de winst die men bekomt met vier processoren tussen de 30 en de 40 procent ligt. Als we de monitorgegevens van de CPU’s er nog een bijhalen (fig. 7.12), dan blijkt dat de processoren een gemiddelde load hebben van 77 % in de dual situatie, tegenover een gemiddelde load van amper 56 % in de quad situatie.

Dit zal dus nog verder onderzocht moeten worden. Zo dienen we eens een code analyzer op sysbench los te laten om deze benchmarktool beter te kunnen profileren. Anderzijds zou het probleem bij MySQL kunnen liggen; in het verleden schaalde deze database software helemaal niet, er was zelfs een verlies in prestaties als men meer dan twee processoren had10 . Dit is 10

citation needed

70


Figuur 7.12: Sysbench native: CPU load bij Dual en Quad Opteron 8356 opstellingen.

sinds versie 5 onder handen genomen, maar dat sluit niet uit dat er nog steeds ergens een bottleneck zit. Dit dient ook nog onderzocht te worden. Echte schaalbaarheid kan men echter niet berekenen door transacties per seconde waarden met elkaar te vergelijken en dat enkel met vier tegenover twee processoren. Om schaalbarheid te onderzoeken, dient men volgens “An Introduction to Parallell Computing” van Grama et al. [12] de uitvoertijd te vergelijken in de verschillende situaties. Zo moet de probleemgrootte gelijk gehouden worden (het aantal uit te voeren transacties) en dient men een vergelijking te maken beginend vanaf een processor, gaande naar twee,vervolgens naar vier, enzovoort. Als klein voorbeeld hoe dit in z’n werk gaat, berekenen we even de efficiëntie van het process, dewelke volgens Amdahl11 daalt naargelang het toevoegen van processoren, als we schalen van twee naar vier CPUs.

Speedup S

=

Ef f iciency E

= =

11

Sequentiele uitvoertijd Ts P arallelle uitvoertijd Tp S CP U s p Ts p ∗ Tp

http://en.wikipedia.org/wiki/Amdahl_law

71


E(2 → 4)

= = = =

Ts Ts / 4 ∗ Tp4 2 ∗ Tp2 Tp2 2 ∗ Tp4 59, 87 0.5 ∗ 44, 57 67%

We bekomen dus een efficiëntie van 67 %, waar we verwachten dat deze eerder rond 80 % moet liggen. Zoals eerder aangehaald zal hieromtrent nog een uitgebreid onderzoek verricht worden. Dit is echter niet meer weggelegt voor dit document.

7.5.2

VMware tegenover Xen

VMware, opgericht sinds 1999, is al geruime tijd marktleider op vlak van hypervisor gebaseerde virtualisatie. Een vergelijking met de nieuwe speler Xen is dan ook niet uit te sluiten. Bij deze testopstelling konden we alle kracht uit Xen halen, doordat we hier gebruik maakten van diens paravirtualisatietechnieken. We kunnen dan ook merken dat VMware ESX de verliezende hand heeft als het gaat om Linux te virtualiseren (fig. 7.10). In deze zware I/O test krijgt de binary translator van VMware veel werk voor de boeg. Telkens als er een call naar de storage controller gemaakt wordt, dient deze immers vertaalt te worden. Daartegenover kan de guest in Xen gewoon een hypercall maken naar de desbetreffende native driver maken, via het frontend-backend driversysteem, zonder vertaalslag.

Figuur 7.13: Sysbench: Xen en VMware ESX op de dual Opteron 8356.

72

Hoofdstuk 8

Benchmarks: Real world scenario 8.1

Opstelling

Voor de Windows test is er gekozen om twee database intensieve applicaties, OLTP (Zie 7.2.1) en DSS, en twee webservers gelijktijdig te testen. Het gebruikte OS op alle VMs is Windows 2003 enterprise server. Voor de database test maken we gebruik van een DSS1 op basis van OLAP. DSS is een computer gebaseerd systeem om mensen aan de hand van verschillende technologieën beslissingen te helpen nemen. De technologie hier gebruikt heet Online Analytical Processing (OLAP). Dit is een methode om snel antwoord te geven op complexe vragen die een veelheid van gegevens in een database verwerken. De twee webservers zijn servers die via IIS een php website draaien, de sites maken connectie met een Oracle database die op een andere server staat. De websites die op de webservers staan zijn eigendom van het bedrijf MCS ,dit staat voor Management Consultancy Software, en is een facillity management bedrijf. Deze website biedt de mogelijkheid aan gebruikers om in te loggen, iets wijzigen, iets posten, uit te loggen, ... Voor de database tests wordt ervoor gezorgd dat de database op een DAS staat zodat er zich geen botleneck vormt door disk prestaties. Deze opstelling zorgt ervoor dat we zowel I/O intensieve en CPU intensieve operaties hebben en dus een real world situatie. We hebben gekozen om tijdens de tests hoge prestaties van de VM te eisen zonder de functionalliteit te verliezen. 1

http://en.wikipedia.org/wiki/Decision_support_system

73

Hoofdstuk 8. Benchmarks: Real world scenario

Figuur 8.1: Windows test opstelling.

8.2 8.2.1

Testsoftware vApus

vApus is software, ontwikkeld op het Sizing servers lab, die toelaat bepaalde tests op servers uit te voeren. vApus verzamelt alle resultaten zodat men die kan groeperen en vergelijken met voorgaande tests. Allerhande parameters kunnen voor de test worden aangepast bijvoorbeeld concurrency en precision. Met concurrency bedoelen we het aantal gesimuleerde gebruikers die simultaan een actie2 gaan uitvoeren op een web/database server. Hoe hoger de concurrency hoe meer gesimuleerde gebruikers en hoe zwaarder de belasting. De precision is het aantal keer de volledige log3 per concurrency herhaald wordt. Dit kunnen we hoger zetten om meer afvlakking te hebben maar dan duurt de test ook wat langer. vApus werkt volgens een master slave principe. Dit wil zeggen dat er een master instantie van vApus verschillende slave instanties aanspreekt, die slaves kunnen ook op andere fysieke computers staan. Elke slave kunnen we ook een processor affinity toewijzen zodat we de belasting op de machine die de tests uitvoert gaan verspreiden. De master kent enkel projecten toe, doet monitoring en zorgt ervoor dat alle resultaten op één plaats verzameld worden.

8.2.2

Soorten tests

vApus heeft momenteel twee verschillende soorten test die dan opnieuw te groeperen zijn in twee categorieën. Aan de ene kant zijn er de WebHttpBenchmark en de DatabaseBenchmark die dan elk ofwel ASAP (As Soon As Possible) of CR (Continuous Rate) kunnen uitgevoerd worden. 2 3

Een actie is bijvoorbeeld. een select op de database of inloggen op een webpagina Een log bevat querrys die in acties worden gestopt.

74


Figuur 8.2: Testopstelling vApus.

Figuur 8.3: As Soon As Possible.

ASAP betekent dat er in een zo kort mogelijk tijd zoveel mogelijk requests naar de server worden gestuurd.

Figuur 8.4: Continous Rate.

CR verschilt er dan in dat er een wachttijd tussen de verschillende requests kan ingesteld worden om zo gebruikers realistisch te simuleren. Net daarom hebben wij voor de tests enkel de continous rate tests uitgevoerd. CRWebHttpBenchmark De webtest gaat op een webserver handelingen simuleren van gebruikers zoal het klikken op urls en het opvragen van webpagina’s, inloggen een nieuwbericht posten en terug uitloggen,... CRDBBenchmark De database test gaat selects uitvoeren op de database. Hiervoor hebben we een database nodig die niet op dezelfde harde schijf staat als het os.

75

Hoofdstuk 8. Benchmarks: Real world scenario De handelingen die eender welke test gaat uitvoeren zijn opgeslagen in logs, deze logs worden dan geimporteerd in vApus en in actions gestopt. Tijdens de tests worden de actions uitgevoerd, dit randomsgewijs om zo enige vormen van caching te voorkomen.

Figuur 8.5: vApus.

Op bovenstaande afbeelding is er een vApus Master een test aan het uitvoeren op verschillende servers (twee webservers en een database server). Rechts in de solution explorer staan alle onderdelen die nodig zijn om deze test uit te voeren. Centraal zien we de monitoring van de slave computers en de specificaties van de test, er zijn al reeds enkele concurrency’s uitgevoerd dan krijgen we de resultaten in een overzichtje dat, indien gewenst, kan worden opgeslaan in een csv file. Opwarming servers Het opwarmen van servers is een techniek die we hanteren om zo de overblijvende caching vol te krijgen. Deze techniek is eenvoudig we laten relatief lage concurrencies (5 of 10 hangt af van het soort toepassing) lopen op de server en gaan onmiddelijk daarna de uiteindelijke test starten. De machine zelf wordt dan ook niet opgeschrokken door een plotse zware belasting. Praktisch Wat moet er nu worden ingesteld op vApus? Eerst moeten we een project aanmaken, dit project zal worden gevuld met alle elementen die nodig zijn om een test uit te voeren. CRDBBenchmark De database benchmark bevat natuurlijk een connectie naar de database, test altijd uw connectie vooraleer een test met het SlaveControlCenter te starten. Verder dienen de logs ge´ımporteerd te worden in een QuerryStructure (verschillend 76

Hoofdstuk 8. Benchmarks: Real world scenario volgens database type. Vervolgens stellen we de defaultwaarden voor de tests correct in.

Figuur 8.6: Apus Webbenchmark.

CRWebBenchmark De webbenchmark verschilt niet zoveel van opstelling met de database benchmark.Hier is het instellen van de connectie met de webserver eenvoudiger daar er enkel een IP address vereist is. Wederom wordt de raad gegeven om telkens de connectie te testen alvorens een test te runnen. Ook hier worden er logs ge¨ımporteerd maar ditmaal in een WebHTTPStructure en worden de defaultwaarden ingesteld.

Figuur 8.7: Apus Database Benchmark.

SlaveControlCenter Hier gaan we dus andere instanties van vApus een test gaan toewijzen. Eerst en vooral gaan we een slavegroup toevoegen, daarna de slaves. Men heeft de keuze ofwel wordt het volledige netwerk gescand, dit kan afhankelijk van de grootte van het netwerk lang duren, of men gaat specifiek zoeken naar instanties van apus op een bepaald ip adres. Dan gaan we slave per slave instellen, bij de master instantie zetten we altijd het vinkje enabled” af want we gebruiken deze instantie immers niet om een test te ” runnen maar om slaves te besturen.

77


Figuur 8.8: Apus SlaveControlCenter.

Verder gaan we iedere slave een project en eventueel processor affinity toewijzen. We kunnen terug de concurrency en precision instellen deze zullen de eerder gekozen default waardes gaan overschrijven. Hou bij ieder slave veld ook de linker bovenhoek in het oog. Als daar staat Slave online is alles goed, staat er echter Client Online betekent dit dat de client computer aanwezig is maar dat er op de gekozen poort geen instantie van vApus staat. Eens alles ingesteld dan kunnen we de test starten door op de groene knop te drukken.

Figuur 8.9: SlaveGroup.

78


8.3

Swingbench (charbench)

Swingbench is een OLTP test (zie 7.2.1) die bestaat voor zowel Linux als Windows. Swingbench is de grafische variant wij gebruiken voor onze test charbench (text based in command line) in combinatie met een Oracle database.

8.3.1

Praktisch

Hier wordt een OLTP test opgesteld op een Windows server 2003 machine. Benodigdheden: Java: download Java http://www.java.com/nl/download/index.jsp. Swingbench: Download Swingbench http://www.dominicgiles.com/swingbench/swingbench22. zip Een geldige Oracle 10G Basic. Installatie Oracle Maak eerst en vooral dat de naam en ip van de computer vast zijn en niet meer veranderen. Indien dit wel na de installatie van Oracle gebeurt dan kunnen er zich heel wat problemen zijn. Installatie Swingbench en voorbereiding Order Entry test. Unpack swingbench22.zip naar C:\ Zoek vervolgens het bestand swingbenchenv.bat” en pas de eerste 3 lijnen: ” 1

3

s e t ORACLE HOME=C: \ o r a c l e \ p r o d u c t \ 1 0 . 2 . 0 \ db 1 s e t JAVAHOME=C: \ Program F i l e s \ Java \ j r e 1 . 6 . 0 0 5 s e t SWINGHOME=C: \ swingbench

Lokaliseer \swingbench\winbin\oewizard.xml” en verander de customercount- en ordercount ” value naar 1500000. Dit is nodig om een database van 1,5GB te bekomen. 1

<Parameter Key=”c u s t o m e r c o u n t ” Value =”1500000”/> <Parameter Key=”o r d e r c o u n t ” Value =”1500000”/>

Vervolgens starten we de wizard (oewizard.bat) om de Order Entry database te creëren. connectionstring: vervan DOM102” met de eerder gekozen DB. ” Kies type IV(thin).We kiezen deze driver omdat hij algemeen een betere performantie geeft. Geef het correcte wachtwoord op. (De username blijf sys as sysdba”.) ” Vervang het wachtwoord soe”. ” Vervang directory voor de index en tablespace met het juiste pad. bv. C:\oracle\product\10.2.0\oradata\orcl ” Of wanneer we een externe DAS schijf gebruiken : D:\soe.dbf”. ” 79

Hoofdstuk 8. Benchmarks: Real world scenario OLTP test starten Ga via de commandprompt naar de directory \swingbench\winbin” en typ het commando: ” c h a r b e n c h −c o e c o n f i g . xml −r r e s u l t a a t . xml −vc −max 0 −min 0 −uc 90 −a −r t 0 0 : 1 0

De parameters zijn : -c oeconfig.xml = de configuration file -r resultaat.xml is het bestand waarnaar het resultaat zal worden geschreven. -vc Hierdoor wordt de output getoond. -max en -min is de maximum en minimum think time -uc is de usercount -a starten zonder bevestiging -rt is de runtime vorm hh:mm

8.4

Test instellingen 2008

De instellingen van apus waren als volgt:

8.4.1

2cpu’s per virtuele machine

CRDBBenchmark Concurrency : 600; 700; 800 CRDBBenchmark Precision : 1 CRWebHTTPBenchmark Concurrency : 90;100;110 CRWebHTTPBenchmark Precision : 1 De Oltp test werd gerund met een interval van 10 minuten en een gebruikersaantal van 90.

8.4.2

4cpu’s per virtuele machine

CRDBBenchmark Concurrency : 600;700;800 CRDBBenchmark Precision : 1 CRWebHTTPBenchmark Concurrency : 80;85;90;100;110 CRWebHTTPBenchmark Precision : 1

80


8.5

VMware benchmarks

8.5.1

7330 dual vs 7330 quad

Voor de eerste test heb ik de Sun Fire x4450 (E.4) uitgerust met Intel 7330 CPU’s. Er zijn in deze configuratie twee tests gebeurt, eerst met twee dan met vier sockets. De VMs werden dan ook aangepast, eerst werken met twee en daarna met vier VCPUs per VM.Ook de ram evolueerde mee ,dit komt omdat we in ons protocol hebben vastgelegt dat er 1GiB per core mag gebruikt worden. Deze test hebben we uitgevoerd om het gedrag van de VM in VMware ESX te kunne schalen volgens het aantal VCPUs. Als we de resultaten onder de loep nemen komen we tot devolgende vaststellingen. Voor de OLTP test(Zie ??) is er ongeveer 36% verlies, dit verlies komt door het tekort aan rekenkracht daar charbench een vrij belastende benchmark is voor de CPU. Als we de processor belasting bekijken zien we dat de dual configuratie een 14% zwaarder wordt belast.

Figuur 8.10: 7330 dual vs 7330 quad charbench.

81


Figuur 8.11: 7330 dual vs 7330 quad CPU belasting charbench.

Kijken we even naar de resultaten van de vApus tests dan zien we een gelijkaardig fenomeen bij de VMs

Figuur 8.12: 7330 dual vs 7330 quad CRDBBenchmark.

82


Figuur 8.13: 7330 dual vs 7330 quad CRWebHttpBenchmark.

Uit deze eerste test hebben we gezien dat zowel virtuele web als database-applicaties een daling in prestaties geven door het verminderen van aantal VCPUs en werkgeheugen. Bij de web-applicaties zien we een gemiddelde daling van 30% , database applicaties verliezen ongeveer een daling met gemiddeld 20%. Wanneer we op de database meer dan alleen selects uitvoeren (zoals OLTP) dan zien we een fellere daling. De CPU’s worden echter 15% zwaarder belast als ze worden gehalveerd.

8.5.2

7330 quad vs 7350 quad

Voor deze test heb hebben we eerst Intel 7330 en daarna Intel 7350 CPU’s in de Sun Fire x4450 (E.4) geplaats. De configuratie van de VMs bleef ongewijzigd dus enkel de kracht van de CPU’s was verschillend. Door de grotere L2 cache , van 6 naar 8MiB, en de snellere klokfrequentie van de cpu zien we een algemene stijging in prestaties van 21%. De grootste stijging krijgen we te zien bij de WebBenchmark die een stijging van 42% laat optekenen. Het belastingsverschil tussen de twee types processoren bedraagt ongeveer 12%.

83


Figuur 8.14: 7330 quad vs 7350 quad charbench.

Figuur 8.15: 7350 quad vs 7330 quad CPU belasting charbench.

8.5.3

VMware vs Xen

Natuurlijk was één van de doelen het vergelijken van Xen tegenover VMware. Wegens tijdnood hebben wij dit op zowel linux als windows test slechts één maal kunnen doen. We hebben elk met dezelfde configuratie getest op de Sun Fire x4450E.4. De processoren waren Intel 7330’s, elke Windows machine had dus recht op 4 VCPUs en 4 GiB werkgeheugen. Iedere machine is uitgerust met VMware tools of de Novell SLES VM driver pack v1.1. Op alle tests mogen we een verschil van 32% in het nadeel van Xen optekenen. Als we wat dieper naar de resultaten kijken zien we dat er een groot verschil zit in de OLTP test. Hier 84

Hoofdstuk 8. Benchmarks: Real world scenario presteert VMware 65% beter dan Xen. De andere tests weet Xen af te werken een minder groot verschil. Slechts 8% verschil voor de vApus database benchmark en 22% verschil op de webtest.

Figuur 8.16: Xen vs VMware OLTP.

Figuur 8.17: Xen vs VMware WebBench.

8.5.4

Opteron 8356 vs Xeon 7330

Met deze test willen we het voordeel van Nested Pages bij AMD in het licht zetten. De test werd uitgevoerd op Xen 3.2 met 4 windows machines elk uitgerust met 4 VCPUs en 4 GiB werkgeheugen. Er werd getest met de Opteron 8356 tegenover Xeon 7330, op respectievelijk SuperMicro AMD platform E.2 en Intel platform E.1. De resultaten spreken voor zich, maar 85

Hoofdstuk 8. Benchmarks: Real world scenario liefst Voor de webtest laten we tot 49% winst optekenen voor de Opteron, de Oltp test heeft echter slechts een verschil van 1,4%. Voor de vApus database benchmark hebben we een verschil van 16%. Deze waardes geven aan dat de nieuwe technologieën toch een pak beter presteren.

Figuur 8.18: 8356 vs 7330 WebBench.

Figuur 8.19: 8356 vs 7330 BenchDB.

86


Figuur 8.20: 8356 vs 7330 Oltp.

8.6

Conclussies

CPU verandering Als we nu CPU’s verwijderen uit de machine of vervangen door een nieuw type de conclussie omtrend prestaties blijft hetzelfde. Telkens hebben we te maken met een verandering van cache. We weten al dat Binary Translation een probleem heeft met shadow pages wanneer er veelvuldig toegang tot het fysieke geheugen nodig is(zie ??). Hoe lager de beschikbare cache, hoe minder er kan gecached worden, hoe meer toegang nodig is naar het fysieke geheugen. Hierdoor worden de shadow pages vaker vernieuwd wat een negatieve weerslag heeft naar de prestaties van de machine toe. Door het verwijderen van 2 fysieke processoren in de eerste test wordt de cache gehalveerd en krijgen we dus ook slechtere prestaties. Bij de tweede test hebben nieuwe CPU’s (Intel 7350) 25% meer cache ,twee maal 4MiB, wat zich onmiddelijk laat tonen in de prestaties van de VMs. We kunnen dus besluiten dat bij geheugenintensieve applicaties er best voor processoren word gekozen die voldoende cache aan boord hebben. Indien er niet voldoende cache is gaan de prestaties van de VM er onder lijden. Ook kunnen dalende prestaties afhangen van de applicatie, heb je een applicatie die threads slecht beheert dan is er veel toegang naar het geheugen nodig waar we dan terug gaan botsen op het probleem met shadow pages. Ook bij veel context switches, dit is het proces waar de cpu van de ene applicatie op halt zet om verder te doen met een andere applicatie, wordt veel naar de ram geschreven. Dit kan eveneens een probleem in prestaties opleveren.

87

Hoofdstuk 8. Benchmarks: Real world scenario Bij het vergelijk tussen de Opteron en Xeon procesoren kunnen we opmerken dat de nested paging tabels hun werk naar behoren doen. De Xeon processor is niet uitgerust met enige vorm van HAP. De Opteron heeft dit wel aan boord en dus kunnen we interessante prestatieverschillen opmerken. Er is een grote snelheidswinst voor applicaties die veel beroep doen op het werkgeheugen. Bij de OLTP test is er een klein verschil merkbaar, dit komt omdat de data onmiddelijk naar de hard disks kan geschreven worden. Er reste ons echter te weinig tijd om te vergelijken hoe VMware op dit gebied presteerd tegen over Xen.

8.6.1

Xen vs VMware

Helaas is er slechts één test om te vergelijken maar men kan duidelijk merken dat VMware ESX nog altijd een prestatie voordeel heeft tegenover Xen in deze Windows-gebaseerde testopstelling. Hier dient ook Xen gebruik te maken van full virtualization. VMware heeft binary translation in die mate uitgewerkt dat er nog altijd een prestatie voordeel is tegenover Xen HVM.

88

Hoofdstuk 9

Algemene Conclusies Met dit project wilden we als een van de eersten onderzoeken hoe Xen en VMware ESX omgaan met I/O, met andere woorden hoe applicaties die veel calls naar de hardware maken, presteren in een gevirtualiseerd systeem. Zo kunnen we concluderen dat hier inderdaad een grote virtualisatie overhead optreedt. Als KMO dient men de uitspraken van de softwareontwikkelaars, zoals het vaak gebruikte “near native performance”, met een korrel zout te nemen. Deze uitspraak doelt immers op usermode applicaties. Verder kan er ook geconcludeert worden dat de virtualisatie overhead toeneemt naarmate het toevoegen van VMs. Met de real world testopstelling prikkelen we vooral de interesse van KMO’s. Hier lag de nadruk niet zozeer op het vergelijken van de prestaties tegenover een native situatie, maar eerder op een vergelijking tussen de gebruikte technologiën van AMD, Intel, Xen en VMware. We hebben helaas de tijd niet gehad om de vergelijking tussen Xen en VMware ESX verder uit te diepen. Maar uit de resultaten die we al hebben kan er geconcludeert worden dat Xen een geduchtige tegenstander biedt tegenover de marktleider. Op vlak van Linux virtualisatie komt Xen er met kop en schouders bovenuit, gebruik makend van diens paravirtualisatie implementatie. Daartegenover moet Xen de bijl neerleggen in het virtualiseren van Windows. In deze situatie wordt er teruggegrepen naar full virtualization en hardware assisted virtualization, waar VMware al bijna een decenium ervaring heeft in deze technologie. Zelfs als Xen gebruik maakt van geparavirtualiseerde I/O drivers in het HVM domain, weet VMware ESX Xen nog steeds te verpletteren. Dit komt vooral boven in de charbench OLTP test. Tenslotte verloopt het virtualiseren van Windows in Xen niet altijd even stabiel; regelmatig waren er wel crashes tot Blue Screens of Death toe. Bij VMware ESX hebben we doorheen het testen nooit VM crashes ondervonden. Een nadeel aan VMware ESX is echterde nood aan specifieke, VMware gecertifiëerde hardware, waar Xen op bijna alles draait waar Linux drivers voor te vinden zijn. We kunnen met een glimlach terugblikken op deze stage. Dit lab gaf ons de mogelijkheid om veel bij te leren over een vrij zwaar concept: virtualisatie. Op momenten kregen we het 89

Hoofdstuk 9. Algemene Conclusies gevoel dat niet de servers, maar wij, gestresstest werden. Doch gingen we het project steeds met volle moed en enthousiasme aan. We hebben met de mensen van het Sizing Servers lab een goede band opgebouwd, en kijken uit naar een verdere samenwerking. Thomas De Ly Philip Dubois

90

Bijlage A

Google Ganeti A.1

Omschrijving

Google Ganeti1 is een open source virtuele server manager, gebouwd bovenop Xen en andere Open Source Software (OSS). Het is ontwikkeld om het beheer van geclusterde VMs te bevorderen; door simpele tools kan men bijvoorbeeld makkelijk een OS op een nieuwe VM installeren. Verder biedt Ganeti N-node High-Availability (HA) cluster mogelijkheden en promoot het failover beheer tussen fysieke machines.

Figuur A.1: Opbouw van een Ganeti cluster.

Het project wordt al geruime tijd bij Google intern toegepast om zo het efficiënt gebruik van hun hardware te optimaliseren. Zodoende treedt er een winst op in onder andere plaatsge1

http://code.google.com/p/ganeti

91

Bijlage A. Google Ganeti bruik, consumptie en koeling. Eén van de belangrijkste voordelen is de mogelijkheid om snel en simpel te herstellen van crashes.

A.2

Mogelijkheden

Ganeti biedt een HA oplossing door gebruik te maken van de Xen VMM. Het systeem is gebaseerd op de principes van N-node HA met een aanbevolen clustergrootte van één tot vijfentwintig nodes. Door gebruik te maken van LVM, local-disk of across-the-network RAID en Distributed Replicated Block Device (DRBD), kan men het systeem behoorlijk snel herstellen in geval van fysieke systeemcrashes. Ook is er een importeer- en exporteermechanisme voorzien voor de backup van VMs of de migratie ervan tussen verschillende clusters.

A.3

Vergelijking traditionele HA & Ganeti

Figuur A.2: Traditionele High Availability oplossing.

Het nadeel aan traditionele HA (fig. A.2) oplossingen is dat het door een verhoogde complexiteit gepaard gaat met veel onderhoud en de nood aan uitgebreide testing. Dit gaat uiteraard gepaard met een hoge Total Cost of Ownership (TCO). Een Google Ganeti cluster (fig. A.3) zou deze problemen kunnen verhelpen doordat het systeem opgedeeld is in zogenaamde subsets, waardoor men een zeer flexibel geheel bekomt. Er wordt voorzien in snelle failover en een gemakkelijk beheer. Omwille het feit dat nodes geen fysieke machines dienen te zijn, en de software open source is, kan de TCO verlaagt worden.

92

Bijlage A. Google Ganeti

Figuur A.3: De Google Ganeti High Availability oplossing.

A.4

Ganeti DRBD System Recovery

Een Ganeti cluster kan snel van crashende nodes herstellen door gebruik te maken van het DRBD systeem. Hier wordt dit recovery proces even kort toegelicht.

Figuur A.4: Schijf failover met Google Ganeti

Node 1 en Node 2 vormen een HA cluster die bijvoorbeeld een webapplicatie aanbieden. De cluster maakt gebruik van de donkerblauwe DRBD set. Door bepaalde omstandigheden crashed één van de nodes, namelijk Node 2, behorend tot de donkerblauwe DRBD set. Doordat failover nog niet is geautomatiseerd, dient de systeembeheerder via het gnt-instance replace-disks commando het failover mechanisme op te roepen, waarna Node 3 wordt toegevoegd. De lichtblauwe DRBD set wordt hierdoor actief, zodoende dat de synchronisatie 93

Bijlage A. Google Ganeti kan starten. Op dit ogenblik verzorgt Node 1 het hosten van de webapplicatie. Als de synchronisatie voltooid is, kan de donkerblauwe DRBD set verwijderd worden en heeft Node 3 de gecrashte Node 2 vervangen.

A.5

Toekomst

Op de roadmap staat uiteraard transparante, automatische failover van een instance gepland, wat tot op heden nog steeds handmatig wordt uitgevoerd. Verder wordt er gewerkt aan support voor verschillende virtualisatietechnologiën, en staat Multiple Granularity Locking 2 op de planning. In de toekomst worden er features verwacht zoals een GUI om het geheel te beheren, automatic node allocation en master node election.

A.6

Meer informatie

Meer informatie kan er op een van onderstaande websites terugvinden. • Google Ganeti home pagina: http://code.google.com/p/ganeti.

• Ganeti op de LinuxConf EU 2007: http://www.linuxconf.eu/2007/programme/abstract-RMarxer-1 shtml. • Handige tutorial voor Debian: http://www.howtoforge.com/ganeti_xen_cluster_ management_debian_etch.

2

http://en.wikipedia.org/wiki/Multiple_granularity_locking

94

Bijlage B

OpenVZ B.1

Omschrijving

OpenVZ1 is een open source OS level server virtualisatie oplossing, gebaseerd op Linux. Het steunt daarbij niet op hypervisor-virtualisatie, maar de technologie berust op containers 2 . Bij OpenVZ is er een fysieke server, waarop men verschillende, ge¨ısoleerde en beveiligde Virtual Environments (VEs) kan laten draaien. Dit heeft als voordeel dat er een optimaler server resource gebruik is en dat applicaties niet met elkaar in conflict komen. Deze VEs worden ook wel ”Virtual Private Servers (VPSs)” genoemd. Elke VE gedraagt zich als een standalone server, waarbij er maar een klein percentage (1-3 %) aan virtualisatie overhead optreedt. Elke VE kan onafhankelijk herstart worden, en heeft z’n eigen root access, gebruikers, IP adressering, geheugen, processen, files, applicaties, system libraries en configuratiebestanden. VE resources worden beheert met Beancounters [11]. Deze virtualisatie-oplossing kan enkel gebruikt worden met Linux als hosten guest systeem.

Figuur B.1: OpenVZ: container based virtualisatie. 1 2

http://www.openvz.org http://en.wikipedia.org/wiki/Operating_system-level_virtualization

95

Bijlage B. OpenVZ OpenVZ is een open source community project, gesteund door Parallels 3 en gelicenseerd onder de GNU GPL versie 2. OpenVZ vormt ook de basis voor Virtuozzo 4 , de commerciële virtualisatie oplossing van Parallels.

B.2 B.2.1

OpenVZ Virtualisatie OS Virtualisatie

Dankzij de virtualisatielaag in de kernel van het host OS, wordt elke VE door applicaties beschouwd als een onafhankelijk systeem. Zoals eerder vermeld is er maar een kleine virtualisatie overhead van één tot drie percent. Dit is mogelijk doordat het host systeem steeds dezelfde kernel draait, terwijl er nog steeds verschillende Linux distributies, elk in hun VE, bovenop kunnen draaien. Een VE ziet eruit, en gedraagt zich ook als een normaal Linux systeem. Het heeft standaard startup scripts en applicaties kunnen binnen een VE draaien, zonder specifieke aanpassingen voor OpenVZ. Een VE ziet dus enkel z’n eigen processen, startende van init. Zo worden ook Process IDs (PIDs) gevirtualiseerd, zodoende init PID 1 heeft. Verder heeft elke VE z’n eigen gebruikers en groepen (alsook zijn eigen root gebruiker). Een gebruiker kan elk configuratiebestand aanpassen en extra software installeren, indien deze de nodige rechten heeft. VEs zijn volledig van elkaar ge¨ısoleerd. Processen die bij een VE horen, worden gescheduled om uitgevoerd te worden op elke beschikbare processor. Met andere woorden, een VE is niet gekoppeld aan een specifieke CPU, maar heeft de beschikking tot de volledige beschikbare resources.

B.2.2

Netwerk Virtualisatie

Ook hier zorgt de OpenVZ netwerk virtualisatielaag ervoor dat elke VE van elkaar en van het fysieke netwerk ge¨ısoleerd is. Elke VE heeft zijn eigen netwerk en IP configuratie en het is perfect mogelijk om netfilter (iptables) regels binnen een VE in te stellen. Verder is er ook ondersteuning voor routering en het manipuleren van de routeringtabellen.

B.3

Resource Management

OpenVZ resource management beheert de hoeveelheid resources (CPU, geheugen, disk, ...) die beschikbaar zijn voor een VE. Deze resources worden beheert via zogenaamde Beancounters [11]. Features zijn onder ander: 3 4

www.parallels.com http://www.parallels.com/en/products/virtuozzo

96

Bijlage B. OpenVZ • Het delen van beschikbare Hardware Node resources tussen VEs op een efficiënte manier. • Gegarandeerde Quality-Of-Service. • Het leveren van performantie en resource isolatie, alsook bescherming tegen Denial of Service aanvallen. • Verzamelen gebruiksinformatie voor system health monitoring.

B.4

Meer Informatie

Meer informatie kan er op een van onderstaande websites terugvinden. • OpenVZ home pagina: http://openvz.org. • Vergelijking tegenover andere virtualisatietechnieken: http://wiki.openvz.org/Introduction_ to_virtualization. • Technische info over OpenVZ: http://download.openvz.org/doc/openvz-intro.pdf.

97

Bijlage C

Test Protocol Teneinde correcte testresultaten te verkrijgen die bovendien zonder probleem kunnen worden vergeleken met elkaar is er natuurlijk een testprotocol vereist.

C.1

Virtuele machines :

Voor de resources die we toekennen aan de virtuele machines zijn de volgende regels opgesteld: Ram : De hoeveelheid geheugen die wordt toegekend aan een machine hangt af van het aantal cpu cores. De regel hier is dat we 1024MB toekennen per core. Virtuele CPU’s : het minimum aantal VCPUs is 2 maximum is 4. Dit is natuurlijk afhankelijk door het aantal cores dat de fysieke server bezit. Elke virtuele machine dient vast te worden gepind op unieke CPU’s. Virtuele harde schijven : Deze worden bepaald door het OS die er op staat. Hier is er gekozen om voor zowel windows als linux OSs 15GB te voorzien. Extra data schijven zijn vrij te kiezen (volgens de nood). De disks dienen wel correct gealligneerd te zijn.

C.2

Fysieke Server

Bij vergelijkende tests wensen we ook vergelijkende hardware te hebben een korte opsomming : Ram : Dezelfde hoeveelheid RAM met dezelfde eigenschappen. Opslag : Zorg ervoor dat indien nodig de opslag schijven correct gealligneerd zijn. Test telkens met dezelfde diskopstelling teneinde vergelijkende resultaten te hebben. Indien er vermoedens zijn dat een andere opstelling betere prestaties zou leveren wordt dit op voorhand getest en geëvalueerd.

98

Bijlage C. Test Protocol

C.3

Rapportering en monitoring

De prestaties van de machines dienen opgevolgd te worden teneinde bedrieglijke resultaten te voorkomen. Ook alle instellingen van de machine’s , updates, gebruikte hardware,... dienen bijgehouden te worden.

99

Bijlage D

Resultaat tabellen Tabel D.1: Writeback performantie in sysbench.

Threads

Transactions (#/s)

95% latency (s)

8 16 24 32

392.18 375.02 356.73 353.81

0.0457 0.0794 0.1239 0.1625

Tabel D.2: Writethrough performantie in sysbench.

Threads

Transactions (#/s)

95% latency (s)

8 16 24 32

107.75 107.39 106.59 105.33

0.1202 0.2043 0.3025 0.4224

100

Bijlage D. Resultaat tabellen

Tabel D.3: Xen 3.0.4 - Quad Opteron 8356 sysbench resultaten.

Threads 8 16 24 32 Threads 8 16 24 32 Threads 8 16 24 32 Threads 8 16 24 32 Threads 8 16 24 32

Native (64-bit) Transactions (#/s) 95% latency (s) 652.81 557.69 530.57 520.52

0.0304 0.0613 0.0966 0.1268

1x DomainU (32-bit) Transactions (#/s) 95% latency (s) 483.40 432.78 417.64 387.81

0.0425 0.0758 0.1154 0.1643


0.0414 0.0741 0.1207 0.1634


0.0519 0.0869 0.1323 0.1774


101

0.0515 0.0882 0.1340 0.1800


Tabel D.4: Xen 3.0.4 - Quad Opteron 8356 numa=on sysbench resultaten.



0.0304 0.0613 0.0966 0.1268


0.0415 0.0755 0.1151 0.1565


0.0427 0.0795 0.1243 0.1681


0.0515 0.0868 0.1337 0.1784


102

0.0510 0.0895 0.1382 0.1848


Tabel D.5: Xen 3.0.4 - Quad Xeon E7330 sysbench resultaten.



0.0335 0.0688 0.0988 0.1327


0.0390 0.0735 0.1119 0.1551


0.0392 0.0739 0.1189 0.1581


0.0515 0.0880 0.1369 0.1816


103

0.0515 0.0900 0.1404 0.1849


Tabel D.6: Xen 3.0.4 - Quad Xeon E7340 sysbench resultaten.



0.0332 0.0683 0.0966 0.1294


0.0383 0.0709 0.1123 0.1541


0.0388 0.0736 0.1146 0.1541


0.0498 0.0854 0.1331 0.1773


104

0.0515 0.0882 0.1340 0.1800


Tabel D.7: Xen 3.0.4 - Dual Opteron 8356 sysbench resultaten.



0.0429 0.0825 0.1159 0.1517


0.0575 0.1068 0.1577 0.2096


0.0602 0.1147 0.1687 0.2261


0.0658 0.1242 0.1862 0.2254


105

0.0666 0.1268 0.1836 0.2399


Tabel D.8: Xen 3.0.4 - Dual Xeon E7330 sysbench resultaten.



0.0445 0.0877 0.1175 0.1566


0.0558 0.1067 0.1541 0.1983


0.0569 0.1084 0.1619 0.2060


0.0662 0.1247 0.1806 0.2341


106

0.0673 0.1279 0.1827 0.2367


Tabel D.9: Xen 3.2.1 - Quad Opteron 8356 sysbench resultaten.



0.0304 0.0613 0.0966 0.1268


0.0408 0.0733 0.1152 0.1601


0.0412 0.0746 0.1192 0.1624


0.0466 0.0807 0.1242 0.1668


107

0.0470 0.0835 0.1300 0.1725


Tabel D.10: VMware ESX 3.5 - Dual Opteron 8356 sysbench resultaten.



0.0429 0.0825 0.1159 0.1517


0.0862 0.1501 0.2165 0.2770


0.0648 0.1217 0.1687 0.2266


0.0867 0.1487 0.2162 0.2889


108

0.0724 0.1261 0.1778 0.2334


Tabel D.11: VMware esx 3.5 - Dual Xeon E7330 Windows resultaten.

Concurrency

CRDBbenchmark Items (#/s) Response time (ms)

600 700 800

396.41 397.26 459.95

1.03 1.23 1.05

CRwebhttpbenchmark(mcs1) Concurrency Items (#/s) Response time (ms) 90 100 110

14.04 61.16 13.13 67.24 14.08 62.85 CRwebhttpbenchmark(mcs2)

Benchmark

Items (#/s)

Response time (ms)

90 100 110

13.95 13.63 14.09

61.74 64.38 62.76

Charbench(OLTP) Transactions (#/s) Response time (ms) 181.51

1074.67

109


Tabel D.12: VMware esx 3.5 - Quad Xeon E7330 Windows resultaten.

Concurrency


600 700 800

435.25 476.24 469.85

0.80 0.82 1.01

CRwebhttpbenchmark(mcs1) Concurrency Items (#/s) Response time (ms) 80 85 90 100 110

21.39 24.33 23.31 22.96 17.00

35.45 30.61 32.94 34.58 50.49

CRwebhttpbenchmark(mcs2) Benchmark Items (#/s) Response time (ms) 80 85 90 100 110

21.39 23.71 23.22 22.58 16.07

35.03 31.63 32.98 35.23 51.86


679.67

110


Tabel D.13: VMware esx 3.5 - Quad Xeon E7350 Windows resultaten.

Concurrency


600 700 800

478.82 499.41 518.28

0.58 0.71 0.80


26.39 26.48 23.12 14.58 29.39

26.65 27.03 32.12 59.54 28.84


27.56 26.24 24.97 14.83 28.54

24.84 27.40 30.04 58.46 26.95


581.33

111


Tabel D.14: Xen 3.2.0 - Quad Xeon E7330 Windows resultaten.

Concurrency


600 700 800

472.79 413.69 419.22

0.83 1.13 1.26


19.42 17.54 15.61 16.70 13.21

40.24 46.61 54.24 50.85 67.50


19.72 17.70 15.36 16.61 12.96

39.48 45.79 55.07 51.19 68.90


256

112

Bijlage E

Testconfiguraties

Tabel E.1: Opteron 8356 testconfiguratie CPU Vendor & Model Core frequency # Cores per CPU FSB/HT frequency L1 Cache L2 Cache L3 Cache Instructions

AMD Quad-Core Opteron Barcelona (B3) 8356 2300 MHz 4 1000 MHz 4x 64 KiB 4x 512 KiB 2 MiB MMX, 3DNow!, SSE 1-3, SSE4A, x86-64 Platform

Server Motherboard Vendor & Model Motherboard Chipset # CPU Sockets BIOS Name BIOS Version BIOS Settings

Colfax (SuperMicro) SuperChassis 818TQ+-1000B SuperMicro H8QME-2+ nVidia MCP55 Pro + AMD 8132 4 American Megatrend, Inc. - AMIBIOS v2.59 H8QM8/E-2 v2.0b (15/03/2008) GART Error Reporting: Disabled; Microcode Update: Enabled; Secure Virtual Machine Mode: Enabled; PowerNow: Disabled; ACPI SRAT Table: Enabled; Thermal Throttling: Disabled; CPU Page Translation Table: Enabled; Memory

Vendor & Model Type Speed Timing/Latency (tCL-tRCD-iRP-tRAS) Size # Modules Total Size

ATP AH56K72J4BHE6S PC2-5300 ECC 667 MHz X-x-x-x 2048 MiB 16 32 GiB Hard Disk

OS Disk VM Image Disk External Storage

Seagate Barracuda ES ST3250620NS 250 GB Seagate Barracuda 7200.10 ST3320620AS 320 GB Promise VTrak J300s 6x Seagate Cheetah 15K5 320 GB Adaptec RAID 5805 SAS, BIOS v5.2-0 Build 15728 RAID Level: 0; Stripe Size: 64 KiB; Read Caching: Yes; Write Caching: Enable Always; LVM, ext3 stride=16; noatime

113

Bijlage E. Testconfiguraties

Tabel E.2: Xeon E7330 testconfiguratie CPU Vendor & Model Core frequency # Cores per CPU FSB/HT frequency L1 Cache L2 Cache L3 Cache Instructions

Intel Quad-Core Xeon Tigerton E7330 2400 MHz 4 1066 MHz 4x 32 KiB 2x 3 MiB N/A MMX, SSE 1-3, SSSE3, EM64T Platform


Colfax (SuperMicro) 8015C-TB SuperMicro X7QC3 Intel 7300 Clarksboro + ESB2 4 American Megatrend, Inc. - AMIBIOS v2.26 X7QC3 v1.0a (16/11/2007) Hardware Prefetcher: Disabled; Adjacent Cache Line Prefetch: Disabled; Intel Virtualization Tech: Enabled; Execute-Disable Bit Capability: Enabled; Intel SpeedStep tech: Disabled; Memory


ATP AP56K72G4BHE6S PC2-5300 ECC 667 MHz 5-5-5-15 2048 MiB 16 32 GiB Hard Disk



114





Colfax (SuperMicro) 8015C-TB SuperMicro X7QC3 Intel 7300 Clarksboro + ESB2 4 American Megatrend, Inc. - AMIBIOS v2.26 X7QC3 v1.0a (16/11/2007) Hardware Prefetcher: Disabled; Adjacent Cache Line Prefetch: Disabled; Intel Virtualization Tech: Enabled; Execute-Disable Bit Capability: Enabled; Intel SpeedStep tech: Disabled; Memory


ATP AP56K72G4BHE6S PC2-5300 ECC 667 MHz 5-5-5-15 2048 MiB 16 32 GiB Hard Disk



115





Sun Fire x4450 Sun Fire x4450 Intel 7300 Clarksboro + ESB2 4 AMI SUN BIOS 3B16 Hardware Prefetcher: Disabled; Adjacent Cache Line Prefetch: Disabled; Intel Virtualization Tech: Enabled; Execute-Disable Bit Capability: Enabled; Intel SpeedStep tech: Disabled; Memory

Type Speed Size # Modules Total Size

PC2-5300 ECC 667 MHz 4192 MiB 8 32 GiB


10K.2 RPM 2,5”Seagate SAS-disks ST914602SSUN146G146 GB 110K.2 RPM 2,5”Seagate SAS-disks ST914602SSUN146G 146 GB Promise VTrak J300s 6x Seagate Cheetah 15K5 320 GB Adaptec RAID 5805 SAS, BIOS v5.2-0 Build 15728 RAID Level: 0; Stripe Size: 64 KiB; Read Caching: Yes; Write Caching: Enable Always; LVM, ext3 stride=16; noatime

Hard Disk

116

Bijlage F

Scripts F.1

Linux sysbench scripts

sysbench master.sh 1

3

5

7

9

11

13

15

17

#!/ b i n / bash ## Master s c r i p t t o c r e a t e s i m u l t a n e o u s c o n n e c t i o n s t o t h e ## t e s t i n g s e r v e r s and s t a r t s y s b e n c h + m o n i t o r on them . ## Don ’ t f o r g e t t o exchange your s s h pub key with t h e t a r g e t ## s e r v e r s s o you don ’ t need t o i n p u t a password when SSHing ! ## G e n e r at e p r i v a t e /pub key p a i r with ” ssh−keygen −t r s a ” . ## Copy pub key o v e r t o a u t h o r i z e d h o s t s on t a r g e t s e r v e r with ## ” ssh−copy−i d u s e r @ s e r v e r ” . ## $1 i s t h e p r e f i x /name f o r t h e g e n e r a t e d f i l e s # S p e c i f y h e r e t h e s e r v e r s t h i s s c r i p t s h o u l d c o n n e c t to , # each s e p e r a t e d by a s p a c e . s e r v e r l i s t =” s e r v e r 1 s e r v e r 2 s e r v e r 3 s e r v e r 4 ” echo ’ C r e a t i n g c o n n e c t i o n s . . . ’ f o r s e r v e r i n $ s e r v e r l i s t ; do xterm −e ” s s h r o o t @ $ s e r v e r / r o o t / sysbench −t e s t s / s y s b e n c h c l i e n t . sh $1 ” & done

19

exit 0

sysbench client.sh

2

4

6

#!/ b i n / bash ## C l i e n t s c r i p t t o c r e a t e s i m u l t a n e o u s c o n n e c t i o n s t o t h e ## t e s t i n g s e r v e r s and s t a r t s y s b e n c h + m o n i t o r on them . ## $1 i s t h e p r e f i x /name f o r t h e g e n e r a t e d f i l e s echo ’ C o n f i g u r i n g & F l u s h i n g MySQL . . . ’ / r o o t / sysbench −t e s t s / prepmysql . sh

8

117

Bijlage F. Scripts

10

12

echo ’ S t a r t i n g m o n i t o r . . . ’ / r o o t / sysbench −t e s t s / m o n i t s c r i p t . sh $1 & echo ’ S t a r t i n g benchmark . . . ’ / r o o t / sysbench −t e s t s / s b s c r i p t . sh 1000000 8 32 8 $1 &

14

exit 0

prepmysql.sh

2

4

#!/ b i n / bash ## S c r i p t t h a t f l u s h e s and p r e p a r e s MySQL f o r u s e with ## s y s b e n c h . Dont f o r g e t t o s p e c i f y t h e d i s k where t h e MySQL ## d a t a f i l e s a r e s t o r e d . ### P h i l i p Dubois

6

8

# S p e c i f y h e r e t h e d i s k where t h e MySQL d a t a b a s e s h o u l d be # placed . d i s k =”/dev / sdb1 ”

10

12

# S p e c i f y t h e MySQL password . p a s s=”PASSWORD”

28

s e r v i c e mysql s t o p umount $ d i s k mount $ d i s k /mnt/ cp −rp / v a r / l i b / mysql /∗ /mnt/ cp / u s r / s h a r e / mysql /my−l a r g e . c n f /mnt/my . c n f rm /mnt/ i b ∗ rm /mnt/ mysql−b i n ∗ rm /mnt/∗ l o g ∗ rm /mnt / ∗ . e r r umount /mnt mount $ d i s k / v a r / l i b / mysql / chown −R mysql : mysql / v a r / l i b / mysql / s e r v i c e mysql s t a r t echo ” drop schema s b t e s t ; ” | mysql −u r o o t −p $ p a s s echo ” c r e a t e schema s b t e s t ; ” | mysql −u r o o t −p $ p a s s

30

exit 0

14

16

18

20

22

24

26

monit script.sh

2

4

#!/ b i n / bash ## S c r i p t f o r m o n i t o r i n g t h e s e r v e r . The data g e t s e x p o r t e d ## i n t o a CSV f i l e . ### P h i l i p Dubois ## $1 i s t h e p r e f i x s t r i n g

6

# S p e c i f y t h e MySQL password .

118

Bijlage F. Scripts

8

p a s s=”PASSWORD”

10

#d s t a t −tcmgsd −C , 0 , 1 , 2 , 3 −D xvdb1 −−o ut pu t s y s b e n c h m o n i t o r $ 1 ‘ hostname ‘ d s t a t . c s v 2 150 > / dev / n u l l &

12

18

x=1 w h i l e [ $x − l e 150 ] do echo ” show innodb s t a t u s ” | mysql −p $ p a s s >> s y s b e n c h m o n i t o r $ 1 ‘ hostname ‘ innodbstatusfile sleep 2 x=$ [ $x +1] done

20

exit 0

14

16

sb script.sh

2

4

6

8

10

12

14

16

#!/ b i n / bash ## S c r i p t t o s t a r t t h e s y s b e n c h benchmark ### Johan De G e l a s and P h i l i p Dubois ## $1 i s s i z e o f d a t a b a s e ## $2 i s t h e min number o f t h r e a d s ## $3 i s t h e max number o f t h r e a d s ## $4 i s t h e s t e p o f t h r e a d s ## $5 i s t h e o ut pu t f i l e p r e f i x p a s s=”PASSWORD” # With t a s k s e t / numactl we can bind s y s b e n c h t o a s p e c i f i c # CPU/ c o r e , i f needed . #a f f =’ t a s k s e t −−cpu− l i s t 0 ’ echo ” Database s i z e i s $1 rows ” echo ” Going from $2 t o $3 t h r e a d s i n s t e p s o f $4 ”

18

20

22

24

26

28

30

32

echo P r e p a r i n g f o r t e s t . . . sleep 3 ## This l i n e must be c h e c k e d t o s e e i f t h e u s e r and password ## a r e c o r r e c t ! s y s b e n c h −−t e s t=o l t p −−o l t p −t a b l e −s i z e=$1 −−mysql−t a b l e −e n g i n e=innodb −−mysql−s o c k e t =/v a r / l i b / mysql / mysql . s o c k −−mysql−u s e r=r o o t −−mysql−password=$ p a s s p r e p a r e echo ” T e s t i n g . . . ” date x=$2 w h i l e [ $x − l e $3 ] do b e s t a n d=” s y s b e n c h r e s u l t $ 5 ‘ hostname ‘ $x−t h r e a d s ” echo ” T e s t i n g with $x t h r e a d s . . . ” $ a f f s y s b e n c h −−num−t h r e a d s=$x −−max−r e q u e s t s =25000 −−t e s t=o l t p −−o l t p −read− o n l y=o f f −−mysql−t a b l e −e n g i n e=innodb −−o l t p −t a b l e −s i z e=$1 −−mysql−s o c k e t =/

119

Bijlage F. Scripts v a r / l i b / mysql / mysql . s o c k −−mysql−u s e r=r o o t −−mysql−password=$ p a s s run > $bestand cat $bestand x=$ [ $x+$4 ] echo $x

34

36

done 38

echo 40

date 42

44

echo ” C l e a n i n g up . . . ” s y s b e n c h −−t e s t=o l t p −−mysql−s o c k e t =/v a r / l i b / mysql / mysql . s o c k −−mysql−u s e r=r o o t −− mysql−password=$ p a s s c l e a n u p

46

exit 0

120

Woordenlijst In dit document wordt er veelvuldig gebruik gemaakt van acroniemen en gespecialiseerde termen. Hier volgt een opsomming van deze termen met hun definitie.

AMD-V AMD Virtualization. Een synoniem is Secure Virtual Machines (SVM). 9, 14, 23, 24 API Application Programming Interface. 14, 18 ATAPI Advanced Technology Attachment Packet Interface. 50 BT Binary Translator. 6, 7, 9 BVT Borrowed Virtual Time. 18 DAS Direct Attached Storage. 60 Dom0 Privileged Domain. 13, 15, 16, 21, 22, 24, 25, 28, 31, 69 DomU Unprivileged Domain. 13, 14, 16, 21, 22, 24, 25, 31, 32, 63, 64 DRBD Distributed Replicated Block Device. 92–94 DSS Descision Support System. 59, 73 ERP Enterprise Resource Planning. 59 GNU GPL GNU General Public Licence. 13, 29, 96 GRUB GRand Unified Bootloader. 25, 28 GUI Graphical User Interface. 25, 31, 61, 94 HA High-Availability. 91–93 HAP Hardware Assisted Pages. Synoniemen zijn Nested Page Tables (NPT) en Extended Page Tables (EPT). 10, 13, 23, 68, 70, 88 121

Woordenlijst HVM Hardware Virtual Machine. 14, 23, 24, 32, 68, 88, 89 IDE Integrated Drive Electronics. 50, 53 Intel VT Intel Virtualization Technology. 9, 14, 23, 24 LUN Logical Unit. 58, 60, 61 LV Logical Volume. 60 LVM Logical Volume Management. 60, 92 MES Manufacturing Execution Systems. 59 MMU Memory Management Unit. 8, 10, 16, 19 NTP Network Time Protocol. 17 NUMA Non-Uniform Memory Access. 63, 68 OLAP Online Analytical Processing. 59, 73 OLTP Online Transaction Processing. 58, 59, 62, 64, 73, 79, 83, 84, 88 OS Operating System. ii, 4–9, 11, 16–21, 23, 35, 36, 49, 56, 63, 64, 66, 73, 91, 95, 96, 98 OSS Open Source Software. 13, 91 PAE Physical Address Extension. 20 PID Process ID. 96 PVM Paravirtual Machine. 14, 32 RAID Redundant Array of Independent Disks. 58, 60–62, 92 SAS Serial Attached SCSI. 60 SATA Serial Advanced Technology Attachment. 36 SCSI Small Computer System Interface. 50 SDL Simple DirectMedia Layer. 25 SEDF Simple Earliest Deadline First. 18 SLES SUSE Linux Enterprise Server. 26–28, 33, 61, 67, 84 122

Woordenlijst SMP Symmetric Multi Processing. 17, 18 SSH Secure Shell. 61 SXP Simple XML Persistence. 30, 31 TC Translator Cache. 6 TCO Total Cost of Ownership. 92 TCP Transmission Control Protocol. 49 TLB Translation Lookaside Buffer. 8, 10, 19 VCPU Virtual CPU. 16, 29, 32, 49, 59, 63–66, 70, 81, 83–85, 98 VCS Version Controll System. 27 VE Virtual Environment. 95–97 VI client VMware Infrastructure Client. 35, 38, 42, 46, 48, 49, 51–53, 57 VM Virtual Machine. 2, 5–19, 25, 28–31, 33, 35–40, 42, 47–49, 51–54, 56, 58, 59, 62–66, 68–70, 73, 81–84, 87, 89, 91, 92, 134, 135 VMM Virtual Machine Monitor. 4–10, 12–17, 19–21, 24, 25, 27, 28, 30, 58, 63, 67, 69, 92 VMMU Virtual MMU. 16, 19 VNC Virtual Network Computing. 25 xend De Xen Daemon verzorgt management van zowel de domains, als de hypervisor. 13, 16, 25, 28, 30, 33 XML eXtensible Markup Language. 25, 31, 33 YaST2 SUSE Yet another Setup Tool. 26, 28, 31

123

Bibliografie [1] (????). Hvm compatible motherboards. http://wiki.xensource.com/xenwiki/HVM_ Compatible_Motherboards. [2] (????). HVM Compatible Processors. Compatible_Processors.

http://wiki.xensource.com/xenwiki/HVM_

[3] (????). Vmware website. Http: www.vmware.com. [4] (????). Xen. http://wiki.debian.org/Xen. [5] (????). Xen Interface Manual. XenSource. [6] (????). XenServer Installation Guide, Release 4.1.0 - System Requirements. XenSource. http://docs.xensource.com/XenServer/4.1.0/1.0/en_gb/installation.html# sys_requirements. [7] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt & A. Warfield (2008). Xen and the art of virtualization. ACM. University of Cambridge. [8] L. Cherkasova, D. Gupta & A. Vahdat (2007). Comparison of the three cpu schedulers in xen. ACM. [9] D. Chisnall (2007). The Definitive Guide to the Xen Hypervisor. Prentice Hall PTR. [10] J. De Gelas (2008). Hardware virtualization: the nuts and bolts. AnandTech. http: //it.anandtech.com/IT/showdoc.aspx?i=3263. [11] P. Emelianov, D. Lunev & K. Korotaev (2007). Resource management: Beancounters. [12] A. Grama, G. Karypis, V. Kumar & A. Gupta (2003). Introduction to Parallel Computing (2nd Edition). Addison Wesley. [13] J. Humphreys & T. Grieser (2006). Mainstreaming server virtualization: The intel approach. IDC.

124

Bibliografie [14] R. Love (2005). Linux Kernel Development (2nd Edition). Novell Press. [15] S. Verslycken (2007). Vlaanderen, Dep. PIH.

Xen Paravirtualisatie.

Afstudeerwerk, Hogeschool West-

[16] W. von Hagen (2008). Xen Virtualization. Wiley Publishing, Inc. [17] D. E. Williams & J. Garcia (2007). Virtualization with Xen. Syngress. [18] Xen.org (2008). Xen architecture overview.

125

126

Bijlage F. Projectfiche en -samenvatting

Projectfiche en -samenvatting Projectsamenvatting

127

Bijlage F. Projectfiche en -samenvatting

Projectfiche Hieronder volgt de oorspronkelijke projectfiche. Deze klopt echter niet meer. Zo hebben Thomas en Philip zich op virtualisatie met Xen en VMware ESX toegespitst (het onderwerp van dit document). Aswin werkte rond shared storage.

128

Stageverslagen en planning Planning Het schema dat afgewerkt diende te worden:

129

Bijlage F. Stageverslagen en planning

Stageverslagen Philip Week 1 Virtualisatie Deze week heb ik me vooral bezig gehouden met de theorie omtrent virtualisatie. Meer bepaald over Xen en paravirtualisatie. Verder heeft Johan ons ook een spoedcursus gegeven omtrent dit onderwerp. De machine’s zijn ook verdeeld onder de stagairs. Zo maak ikzelf vooral gebruik van de Barcelona, omdat deze als enige al nested paging ondersteund. SSLab & Netwerk Zoals elk netwerk, dient dat van het Sizing Server Lab ook onderhouden te worden. Als er problemen en/of vragen waren stonden Thomas en ik paraat om deze aan te pakken. Er werd ook gespeculeerd over PR voor de opendeurdag. Planning Ik heb besloten om in week 2 m’n sysbench tests op de Barcelona opnieuw uit te voeren. Deze keer met een geupdate versie van SLES10 SP1 en Novell Xen. Ik dien mijn configuratie zorgvuldig bij te houden. De tests zullen deze keer ook verlopen met een aantal draaiende VM’s. Verder is er ook gepland om woensdag 19 maart, samen met Thomas, naar de LinuxWorld en InfoSecurity 2008 Expo’s te gaan in Brussel.

Week 2 Virtualisatie Deze week heb ik een eerste testing protocol opgesteld voor sysbench. Dit was nodig zodat we allemaal met eenzelfde configuratie benchmarken. Ik heb dan ook verscheidene testen gedaan en wat opzoekwerk voor ”best practice”configuraties van het systeem. Uiteraard heb ik dan ook al een eerste benchmarksessie gedaan bovenop Novell Xen (v3.0.4). De resultaten zijn wat teleurstellend: een domU machine levert ongeveer 28% slechtere prestaties tegenover een native machine in de OLTP (sysbench) test op de Barcelona machine. SSLab & Netwerk Zoals elk netwerk, dient dat van het Sizing Server Lab ook onderhouden te worden. Als er problemen en/of vragen waren stonden we paraat om deze aan te pakken.

130


Week 3 Virtualisatie De eerste dagen was ik niet aanwezig door ziekte. Het sysbench testing protocol is bijgewerkt. Deze week heb ik me ook wat meer vertrouwd gemaakt met Xen, mede dankzij dit boek. En heb ik de source van Xen.org gecompileerd en ge¨ınstalleerd. Ten slotte heb ik nog wat extra tests gedaan. SSLab & Netwerk Zoals elk netwerk, dient dat van het Sizing Server Lab ook onderhouden te worden. Als er problemen en/of vragen waren stonden we paraat om deze aan te pakken. Het was eindelijk tijd om de oude en nieuwe fileservers te wisselen. Er waren nog een paar kinderziektes, maar die zijn zo goed als opgelost. Backupstrategie moet nog eens herzien worden, en de SMTP server dient wat te worden uitgebreid. Planning • Testen op Xen 3.2.0 (installatie vanaf source Xen.org) • Afronden van sysbench op de Barcelona • Opendeurdag

Week 4 Virtualisatie Na de installatie van Xen 3.2 was ik wat teleurgesteld. De compilatie/installatie was niet goed verlopen en ik kreeg geen enkele DomU meer aan de praat. Dom0 performantie was ook ondermaats. Na de de¨ınstallatie was het nog niet in orde; ik kreeg Novell Xen ook niet meer goed werkende. Ik kon de week dus al beginnen met een herinstallatie van mijn systeem. Ik heb deze week ook opzoekingswerk gedaan over het feit dat ik geen 64KiB grote blocksizes als parameter kon opgeven voor het ext3 of het XFS bestandsysteem. Dit omdat ik het bestandssysteem dan perfect kon aligneren met de onderliggende RAID set, die een stripe size van 64KiB heeft. Ik ben tot de conclusie gekomen dat dit niet mogelijk is in x86 (én x86 64) Linux, zonder de kernel speciaal te gaan patchen. Verder zijn er nieuwe machines binnengekomen en het materiaal voor de opendeurdag. Zo heb ik dan ook de SLI PC in elkaar gestoken dat onze ”screen wall”zou aansturen. Ten slotte maakten we het lab ook klaar voor de opendeurdag: alles diende oa te worden opgekuist en het presentatiemateriaal gereed te leggen.

131

Bijlage F. Stageverslagen en planning SSLab & Netwerk De nieuwe machines moesten worden ge¨ınstalleerd en gecatalogiseerd. Ook werd het lab in gereedheidgebracht voor de opendeurdag. Planning • Overschakelen naar de nieuwe machines: QuadTigerton-1U en QuadBarcelona-1U. • Xen performantie in OLTP met verschillende VM’s naast elkaar.

Week 5 Virtualisatie Om de week goed te starten hebben we eens met z’n allen een kleine vergadering gehouden als update naar de stand van zaken, en hoe we beter zouden kunnen samenwerken op bepaalde punten. We hebben verschillende richtlijnen vastgelegd en onze planning kenbaar gemaakt naar onze collega’s toe. Verder heb ik m’n Linux sysbench testopstelling opgebouwd voor de QuadTigerton-1U. Ik heb dan ook het sysbench testprotocol ge¨ updated en los gemaakt van de Werken met sysbench wiki pagina. Benchmarks wijzen uit dat er zo’n 20% prestatieverlies is tussen SLES10 native en een SLES10 DomU in de OLTP test. SSLab & Netwerk We hebben een VPN (PPTP) ge¨ımplementeerd om connectie te maken met het Sizing Servers Lab. Ook wordt de hosting van de wiki (en de toekomstige website) verzorgd door een nieuwe (virtuele) server. Verder hebben we de domeinnaam sizingservers.be opgekocht. Planning • Afronden Linux sysbench op de QuadTigerton-1U • Start thesis paper (LATEX)

Week 6 Virtualisatie Sysbench op de Intel machine is afgerond! Wat, volgens ons vermoeden, opvalt is dat er een groot verschil in OLTP preformantie is tussen 1 VM draaien, of 4 VM’s. Waar 1 VM een verlies van slechts 20% tegenover native heeft, ligt dat bij het simultaan draaien van 4 VM’s op een 40%. Uiteraard hebben al deze machines dezelfde eigenschappen om de benchmarks zo eerlijk mogelijk te laten verlopen. Om deze cijfers extra te staven (en zodat ik me ervan 132

Bijlage F. Stageverslagen en planning kon vergewissen dat de bottleneck niet bij de storage lag) heb ik de benchmarks opnieuw gedaan met 12 snelle Seagate Cheetah SAS schijven ipv. 8 (in RAID0), alsook een snellere SAS controller. De cijfers vertonen nog steeds dezelfde trend. Nu is het tijd om over te gaan naar de AMD machine en deze te toetsen aan de Linux OLTP test. Vervolgens zal ik mijn Windows testopstelling bovenop Xen moeten opbouwen. Tijdens het verlengd weekend ben ik van plan om wat te werken aan m’n eindverslag. SSLab & Netwerk Nu dat de VPN er is, en deze deftig is getest, kon ik de firewall rules eens herzien. Al die port forwards naar de verschillende servers zijn immers niet meer nodig. De machine zelf heeft ook van een herinstallatie kunnen genieten; voor een clean and lean systeem. De andere Linux machines hebben een update naar Ubuntu Server 8.04 LTS ”Hardy Heron”gekregen en ik werk aan een beter backupstrategie voor deze servers. Planning • Afronden Linux sysbench op de QuadTigerton-1U • Afronden Linux sysbench op de QuadTigerton-1U • Opstellen Windows testopstelling (HVM; 2x MCS website, 1x Heimdall vApus database, 1x Charbench OLTP) • Uitkijken naar een gelijkwaardige Linux testopstelling != sysbench only (cfr. Windows opstelling)

Week 7 Virtualisatie De OLTP tests op de Opteron machine werden uitgevoerd met 12 schijven. Tussendoor heb ik nog getracht om al wat bruikbaars neer te pennen in onze thesis. SSLab & Netwerk De nieuwe firewall heeft zijn stabiliteit bewezen. Daarom hebben we de oude uitgeschakeld en deze vervangen. Verder is de IP adressering van het netwerk grondig herzien en is IP via DHCP de standaard manier geworden om machines in het netwerk te plaatsen. Dit gebeurt door ze statisch in de DHCP server in te stellen, zodoende dat bij het (her)installeren van een OS, niet steeds eer dient opgezocht te worden welk adres een server nu moet hebben.

133

Bijlage F. Stageverslagen en planning Planning • Opstellen Windows testopstelling (HVM; 2x MCS website, 1x Heimdall vApus database, 1x Charbench OLTP)

Week 8 Virtualisatie Zodat Thomas en ik simultaan kunnen werken is er besloten om ieder 6 schijven als RAID storage te gebruiken, doordat we hebben ontdekt dat de Promise SAN ook als DAS kan dienen. Door eerder tests had ik al afgeleid dat er bij de disks geen bottleneck lag (verschil van maximaal 5% tussen 6-12 schijven). Dit wil wel zeggen dat ik een hele hoop benchmarks weeral opnieuw kan doen; namelijk alles met 6 schijven. Hiervoor heb ik besloten wat te gaan scripten dat het gehele proces automatiseert. Verder SSLab & Netwerk Deze week is de nieuwe backupstrategie ge¨ımplementeerd. Verder dienden er wat problemen opgelost te worden met de SVN- en webserver. Planning • Xen 3.2.1 testen • Opstellen Windows testopstelling (HVM; 2x MCS website, 1x Heimdall vApus database, 1x Charbench OLTP)

Week 9 Virtualisatie Deze week zijn de nieuwe OLTP tests op Quad (weeral eens) afgerond. Om deze tests snel uit te kunnen voeren heb ik, zoals vorige week vermeld, wat scripts gemaakt die het gehele proces automatiseren. Het master script legt vanaf m’n laptop een connectie naar de gespecifiëerde VM’s en start daar het client script op. Deze prepareert op zijn beurt de VM en MySQL, en als alles opgeschoont is wordt de monitor en de eigenlijke sysbench-benchmark opgestart, waarna de resultaten teruggeraporteerd kunnen worden. Wat het helaas niet doet is alle data in een mooie spreadsheet parsen :-). Vervolgens heb ik Xen 3.2.1 gecompileerd, daar deze de Hardware Assisted Pages van de Opteron 8356 ondersteund, en ondersteuning biedt voor NUMA. De OLTP tests op Xen 3.2.1 zijn deze week ook afgerond.

134

Bijlage F. Stageverslagen en planning Planning • Schaalbaarheid onderzoeken door de OLTP tests te herdoen met 2 Quad CPU’s. VM’s worden dan ook teruggeschroefd naar 2 VCPU’s. • Opstellen Windows testopstelling (HVM; 2x MCS website, 1x Heimdall vApus database, 1x Charbench OLTP)

Week 10 Virtualisatie Deze week zijn de OLTP Dual banchmarks afgerond op zowel de Opteron 8356 als Xeon E7330 machines. Als extra heb ik ook eens getest met 4 Xeon E7340’s. Het verschil met de E7330 is dat deze CPU 2x 4MiB L2 cache heeft ipv 2x 3MiB. Hiermee is de Linux testopstelling eindelijk goed afgerond, en kan ik me de laatste weken concentreren op iets veel interessanter: de Windows HVM testopstelling op Xen. Deze week heb ik al m’n (goede) gecollecteerde data in een spreadsheet gestopt voor leuke visualisaties. Donderdag was er dan de gebruikerscommissie die een bezoek bracht aan het lab. Er was een hoge interesse naar ons onderzoek en komene resultaten. SSLab & Netwerk De webserver had weer eens zijn kuren, welke in ijltempo diende opgelost te worden opdat onze nieuwe PR website beschikbaar zou zijn voor de gebruikerscommissie op donderdag. Na het herstellen van een backup (lang leve m’n backupstrategie!) en een herinstallatie af te dwingen van elke package in het systeem waren de problemeen snel aan banden gelegd. Email via het contactformulier werkt ook eindelijk. Planning • Opstellen Windows testopstelling (HVM; 2x MCS website, 1x Heimdall vApus database, 1x Charbench OLTP) • Windows testing op Opteron 8356, Xen 3.0.4 en Xen 3.2.1.

Week 11 Virtualisatie Het was eindelijk dan zo ver. Deze week liepen m’n eerste Windows resultaten binnen. Helaas ging dat weer niet van een leien dakje; in SLES10SP1 met Xen 3.0.4 was het gewoon rampzalig; voortdurend BSODs na het installeren van Novell’s speciale driver pack (PV I/O drivers voor HVM’s), wat eigenlijk niet verwonderlijk is daar HVM support ppas sinds versie 135

Bijlage F. Stageverslagen en planning 3 van Xen is ge¨ıntroduceert. SP2 met Xen 3.2.0 is echter recentelijk uitgekomen, dus ik heb m’n zelfgecompileerde Xen installatie door SLES10SP2 vervangen. De Windows HVM machines lijken hier behoorlijk te werken, samen met een nieuw driver pack, en m’n volgende benchmarks zullen in deze opstelling gebeuren. Verder kwam Chris, een fervente open source goeroe die we op de linuxConf hadden onmoet, een kijkje nemen in het lab. We hebben wat contacten kunnen uitwisselen en hopen op een succesvolle samenwerking. Misschien nog interessant voor m’n sollicitaties na de master? Planning • Afronden Windows testen. • Afronden thesis. • Proefpresentatie.

Week 12 De laatste officiële stageweek was nogal hectisch. Zo diende Thomas zijn Linux sysbench tests nog te doen. Helaas liep dit niet van een leien dakje, doordat VMware ESX niet op de Opteron machine wilde installeren. Uiteindelijk hebben we slecht één VMware Linux test kunnen afronden. Ik heb me zelf bezig gehouden met het werken aan het projectdossier, dat ondertussen wel een stevig document is geworden denk ik. Er is nog zoveel dat dient uitgetest en geprofileerd dient te worden. Helaas is de stageperiode afgelopen, en zal die materie dus niet meer voor het projectdossier zijn. De volgende weken zal ik het onderzoek echter nog verder zetten, samen met een vaste medewerker, zodat deze na afloop van de maand m’n werk kan voortzetten.

Stageverslagen Thomas Week 1 Eerste opdracht was het begrijpen van virtualisatie, hoe werkt het welke technieken zijn er? Opzoeken van papers, opzoeken van configuraties, hoe werkt VMware ESX? Extra configuraties aan servers waar nodig, installatie van Windows 64 bit machine voor 3D rendering. Brainstorm voor opendeurdag. planning verder verdiepen in ESX en virtualisatie

136


Week 2-3 Verder vertrouwd geraken met esx, zowel op theoretish als op praktisch gebied. ESX installeren op een server, de server geeft een fout en we hebben deze opgelost. Veel opzoekingswerk moeten doen maar uiteindelijk toch gevonden. Verder een begin uitleg gehad over vApus en virtualisatie.Verder ideeën opdoen voor de opendeurdag. Hier en daar nog kleine wijzigingen in het netwerkt van het sslab doorvoeren. planning Alles klaarzetten voor testing, en opendeurdag Machines configureren met Oracle op, Mcs zin werkende te krijgen. Nieuwe machines in de racks

Week 4-5 Leren werken met esx, installaties van VMs en de correcte configuratie voor het latere testen.Dit bracht heel wat problemen met zich te weeg zo is er een probleem met de Oracle die we wensten te gebruiken voor de vApus database test op te doen. Het duurde maarliefst 18u om de database over te zetten. Eens deze was overgezet bleek na wat testing dat de database te goed presteerde en de VM te weinig werd belast. Ik heb ook de virtuele harde schijven op de fileserver gezet zodat die later op andere machines kunnen gebruikt worden. Voor mcs heb ik met VMware converter een VMware server harde schijf omgezet naar een VMware ESX. Afspraken rond een protocol voor de VMs want er is echt een gelijke manier van werken nodig. Verder zijn er nieuwe machines binnengekomen en het materiaal voor de opendeurdag. Installatie van een screen-wall, verder was ik natuurlijk paraat op de opendeurdag om ook wat uitleg te geven aan toekomstige leerlingen. planning nieuwe machine gebruiken, configuraties opslaan op wiki, das tijdig doorgeven aan Philip Monitor tool vinden voor ESX, Apus leren begrijpen en gebruiken. Verderwerken aan de thesis.

Week 6-7 Overschakeling naar Sun Fire x4450 wat een totale overzetting van alle data van de ene machine naar de andere teweeg heeft gebracht.Terug databases overzetten... later na wat testing beslist om de Oracle op de VM voor database testing ongedaan te maken en te vervangen door Mysql nu duurt het overzetten van de database slechts 1u30min. Ook is het eerste testen met vApus gestart hier en daar doken pobleempjes op. Ook heb ik wat problemen gehad met de DAS om die correct te kunnen configureren dit is uiteindelijk gelukt met allignatie.We werken met 1 DAS waardoor we moeten afwisselen wat vertraging voor ons 137

Bijlage F. Stageverslagen en planning allemaal opbrengt. Ik heb een goeie monitor tool gevonden voor VMware ESX. Ook heb ik voor de instellingen van Apus wat screenshots genomen zodat ik philip uitleg kan geven over wat er allemaal moet ingesteld worden. Ook het wikiwerk gaat verder , aanpassingen op de wiki van allerhande instellingen op de VMs. planning Testing , limieten van de machines zoeken en concluderen welke waardes er gebruikt zullen worden voor de instellingen van de machines. Overschakelen naar andere das en de volledige configuratie opnieuwdoen Verderwerken aan de thesis.

Week 8-9 Nu ben ik eindelijk volop aan het testen geslaan, ik had de das terug midden week8. In de periodes dat ik niet kan testen doe ik wat opzoekwerk voor de Thesis. Ik heb terug een test gedaan met apus, ik moet uizoeken waar de meest gunstige configuraties liggen inzake belasting van de host machines zonder de VMs te overbelasten. Uit testen blijkt echter dat de webservers niet zo goed bestand zijn tegen vApus. De tests duren wel echt lang en even iets halen voor te drinken zit er niet bij omdat de monitoring in het oog moet worden gehouden. Op het einde van week8 hebben we gezien dat de affinity van de VMs niet was ingesteld dit zorgt er dan ook meteen voor dat alle voorgaande tests niet meer representatief zijn. Hierna kon ik terug beginnen testen, resultaten verwerken , opnieuw testen. Echter zijn de results van weinig belang omdat ik en philip nu elk een eigen DAS krijgen met 6 hard disks erin. Zo kunnen we tegelijk testen. om telkenmale de das terug te configurerren moet ik images met database overzetten van de fileserver. De tests duren ook te lang waardoor ik teveel tijd verlies. Dit wordt volgende week opgelost. Ook heb ik deze week veel cpu’s vervangen , voor testdoeleinden. planning Representatieve data verzamelen om te vergelijken met andere tests. testen op verschillende hardware platformen en zowel op linux als windows guests. Verderwerken aan de thesis.

Week 10-11 Eindelijk alle puzelstukjes vallen op hun plaats. De installaties zijn ok en kunnen behouden worden. Wel was opnnieuw testing nodig omde correcte belasting van de VMs te vinden. Hetzelfde voor de oltp test die de machine te weinig belaste. Verder werken aan de thesis was ook een must. Voor een groep bedrijfsleiders van kmo’s heb ik tesamen met dieter een vApus test voorbereid en die dan ook gedemonstreerd. Verder terug een sessie theorie over virtualisatie van johan bijgewoond. Deze was opnieuw heel verreikend. Ook zijn de eerste

138

Bijlage F. Stageverslagen en planning resultaten binnen, nl deze op de quad 7350, dual 7330, quad 7330. Het verwerken van de data neemt echter heel wat tijd in beslag omdat er veel data ,die de monitor opslaat, moet gewist worden. We wilden ook een test doen met quad barcelona (AMD) cpu’s maar esx kon niet ge/¨ınstalleerd worden op de server. Na veel proberen , testen, met enkele mensen de koppen samensteken en brainstormen zijn we tot de conclussie gekomen dat er blijkbaar een probleem is met de onboard netwerkkaart. VMware ESX herkent deze niet, dit werd bevestigd na een telefoon met mensen van amd die ook testing doen met VMware en Xen (het was niet om die reden dat we telefonisch contact hadden maar Johan had eerder al een afspraak met die mensen). planning testing afwerken testen op AMD met linux guests. Thesis afwerken

Week 12 De laatste week was in één woord hectisch. Opnieuw moest ik installeren op een amd machine omdat we toch enige testresultaten wensten te verkrijgen dit verliep echter niet zo vlot na veel proberen zijn we er eindelijk in geslaagd een werkende installatie van VMware ESX op de server te krijgen. Vervolgens heb ik tesamen met philip de Linux tests in orde gezet op die machine, ik zorgde hier en daar voor begeleiding met zijn windows testing. Verder gewerkt aan de thesis, data verwerkt vergeleken gebrainstormd wat de oorzaak is voor bepaalde resultaten.

139

Hypervisor gebaseerde x86 virtualisatie Xen en VMware ESX

Recommend Documents