Hoe load op host van virtuele machines te interpreteren?

[chronoz]

Op een machine heb ik 10 VPS'en draaien, hieronder zitten 2 VPS'en die een redelijk hoge load hebben van 3.0. De oorzaak hiervan is dat ik nauwelijks CPU, geheugen en I/O kracht heb toegewezen aan die VM's, om te snelheid van het systeem te bewaken. De VM's hebben nu een load van 3.5 gemiddeld.

Hierdoor is wel de load van de hele node 7.0. Dit houdt in dat er gemiddeld 6 processen tegelijk zijn die moeten wachten op hun beurt. Er is dus vertraging, maar slechts op 2 VM's.

Maar hoe kan ik nu zien of een host nu overbeladen is? Want het is gewoon mogelijk dat de load van een host 200 is, omdat er 2 VM's veel te weinig resources toegewezen hebben gekregen, waardoor zij allebei 100 processen gemiddeld hebben die nog

Mijn doelstelling van dit topic is het bewaken van de integriteit van de hosts. Binnenkort verwacht ik dat er tientallen hosts zullen hangen met veel VM's, maar ik dien te weten hoe ik kan zien of een host overbeladen is.

Zonder virtualisatie was load altijd een goede graadmeter, maar nu niet meer.

[_eXistenZ_]

Je kunt toch gewoon per virtual machine kijken wat de load is? De limieten liggen vast, dus ook al heeft één VM een load van 3 miljard, dan zullen de andere VM's daar echt niks van merken hoor

[Clementine]

"bookmarked"

Intressante vraag en ik heb ook geen idee maar wil wel graag t antwoord weten

[chronoz]

Het gaat mij erom dat ik kan zien of ik nog nieuwe VM's kan plaatsen op een host. Het kan zijn dat een host met een load van 200 sneller en minder beladen is dan een host met een load van 5, omdat de load opgebouwd is uit de load van alle VM's bij elkaar.

Wanneer moet ik stoppen met het toevoegen van VM's op een host? Ik heb namelijk vorige maand een nieuwe server ophangen met 64GB geheugen en 6xSAS RAID5 en de load is al 7.0 door 2 VM's die erg beperkt zijn in hun resources, en hiervoor afzonderlijk een hoge load hebben, maar geen zware impact hebben op de load van de server, terwijl de 'linux load' wel gewoon op 7.0 staat.

Mijn probleem is dat load geen goede graadmeter meer is voor het bepalen van de vrije capaciteit van een server. Het is namelijk de bedoeling dat er 75 VM's komen te staan op deze machine, terwijl de load nu met enkele VM's al 7.0 is.

Indien iemand het fenomeen duidelijker kan beschrijven, graag!

[ Voor 11% gewijzigd door chronoz op 03-04-2010 15:10 ]

[WiebeV]

Wat voor virtualisatie product gebruik je ?

Factoren die erg belangrijk zijn om te bepalen of er nog een VM bij kan zijn natuurlijk:
- RAM geheugen
- Hardeschijf ruimte
- Hardeschijf I/O snelheid
- CPU power
- Netwerk verkeer

Dit moet je controleren op je host machine.
Hoe je dit in de gaten kan houden hangt weer af van je virtualisatie product.

[ Voor 4% gewijzigd door WiebeV op 03-04-2010 15:30 . Reden: typo ]

[Verwijderd]

WiebeV schreef op zaterdag 03 april 2010 @ 15:26:
Wat voor virtualisatie product gebruik je ?

Hetzelfde vroeg ik mij ook al af. Misschien kan de TS dit even duidelijk maken?

[chronoz]

Verwijderd schreef op zaterdag 03 april 2010 @ 15:34:
[...]
Hetzelfde vroeg ik mij ook al af. Misschien kan de TS dit even duidelijk maken?

Virtuozzo, maar ik denk dat dit ook speelt voor andere virtualisatie platformen. Binnenkort wil ik ook gebruik namelijk ook gaan maken van VMWare ESXi.

Het is erg belangrijk om te weten of er nog rekencapaciteit is voor het plaatsen van nieuwe VM's, om een hoge stabiliteit en snelheid te realiseren.

[wasted247]

Ik weet niet wat voor een hardware je exact gebruikt, maar 75 VM's op een enkele hardware bak is erg ambitieus. Op zijn zachts gezegd

Je kunt toch de resources van de host in de gaten houden om te bepalen of hier nog VM's bij kunnen:

- Zijn er nog voldoende CPU cycles beschikbaar.
- Is er nog voldoende RAM beschikbaar.
- Zijn er geen disk io queue's.
- Is er nog netwerk bandbreedte vrij.

Indien je de bovenstaande vragen allemaal met ja kunt beantwoorden, kun je er VM's bij plaatsen. Al deze vragen hierboven staat uiteraard los van de load van de huidige VM's. Je vraag gaat over de fysieke hardware, daar dien je je onderzoek dan ook op te richten.

Hoeveel VM's je vervolgens nog kunt plaatsen hangt uiteraard geheel van je te plaatsen VM's af, en hoeveel load deze zullen genereren op de host.

Wel ben ik benieuwd op welke hardware jij 75 VM's wil gaan draaien.

Edit: Disclaimer, de bovenstaande regel gaat op tot op een bepaald punt, ook al genereren je VM's nagenoeg geen load, je fysieke cpu kan maar een bepaald aantal threads verwerken. Er is dus een omslag punt waarop jou VM's meer threads nodig hebben dan de fysieke CPU simultaan kan verwerken.

Vandaar ook de bovenstaande opmerking dat 75 VM's erg ambiteus is. De kans is erg groot dat deze VM's (ook al zouden het single core VM's zijn) meer threads simultaan zullen draaien dan jouw host aankan, en dat zorgt absoluut voor vertraging. Zelfs al heb je 4x4 cores in jouw fysieke bak, kunnen er dus maar 16 threads tegelijk verwerkt worden. Ik gok dat je daar met 75 VM's gauw aan zit.

Diskspace, IO, RAM en netwerk zijn gelukkig erg schaalbaar, CPU threads is over het algemeen het lastigste.

[ Voor 34% gewijzigd door wasted247 op 03-04-2010 16:04 ]

[serkoon]

Eigenlijk is de vraag te generiek om het te beantwoorden, afgezien van een generiek antwoord

Het hangt altijd af van je workload en wensen. Als je ruwe CPU-power nodig hebt, is de gemiddelde CPU-usage over een bepaalde tijd het belangrijkst. Als je veel disk iops wil doen, is het huidige gemiddelde aantal iops over een bepaalde tijd van belang. Memory is iets makkelijker: je wil in ieder geval dat elk guest OS z'n applicaties redelijk in geheugen kan houden en ook nog disk cache kan houden voor de set van data waar de applicaties op werken.

Op zich zegt load wel -iets- over al deze metrics, maar puur op load alleen kun je eigenlijk geen keuzes maken.

[WiebeV]

Met Virtuozzo en VMware ESXi heb ik geen ervaring, wel met VMware ESX.
Een ESX server kun je met de "VMware Infrastructure Client" beheren, hier kun je ook per host zien hoeveel resources er worden gebruikt zoiets dus.

Of dit ook met ESXi kan weet ik niet.

[wasted247]

WiebeV schreef op zaterdag 03 april 2010 @ 16:04:
Met Virtuozzo en VMware ESXi heb ik geen ervaring, wel met VMware ESX.
Een ESX server kun je met de "VMware Infrastructure Client" beheren, hier kun je ook per host zien hoeveel resources er worden gebruikt zoiets dus.

Of dit ook met ESXi kan weet ik niet.

Ja

Je gebruikt dezelfde client, die leest dezelfde metrics uit.

Edit: Enkel is de performance tab nog veel nuttiger

[ Voor 15% gewijzigd door wasted247 op 03-04-2010 16:16 ]

[Verwijderd]

Verschilt ook nog behoorlijk per virtualizatie pakket. In KVM bijvoorbeeld zijn je VM's gewoon een Linux process en kun je de load gewoon meten zoals met elk ander process. In VMWare en Xen bijvoorbeeld wordt dit toch wat moeilijker omdat dit exo-kernels zijn en je waarschijnlijk de managment tools in moet duiken.

In theorie is er geen limiet aan hoeveel VM's je kunt draaien zolang je maar genoeg opslag en virtueel geheugen hebt dus inclusief je swap schijf. Op een 1TB schijfje zou je 200 VM's met elk 1GB opslag en 4GB geheugen kunnen draaien. Echt lekker zal dat niet gaan aangezien je geen waarschijnlijk 800GB RAM geheugen hebt en je dus continue VM"s in en uit je swap schijf aan het stoppen bent maar zolang je nog swap hebt werk het, sort of.

Linux 2.6.32 echter komt met een leuke feature genaamd KSM waarin identieke geheugen pagina's slechts 1 keer in het geheugen worden gezet. Als je VM's dus erg identiek zijn kan dit een flinke besparing opleveren.

Klopt het dat Virtuozzo een soort managment schil om KVM heen is? meer ergens howto gezien te hebben daarover maar dan werken waarschijnlijk ook de virtio drivers welke behoorlijk wat overhead kunnen schelen.

Kortom, het hangt ook erg van je VM's af en of deze vooral CPU/RAM of I/O afhankelijk zijn. Een VM die vooral veel reken werk doet maar weinig RAM of I/O doet zoals een DPC koe zal meer hebben aan een snelle multi-core proccessor terwijl een file-server waarschijnlijk meer aan een snelle virtio schijf zal hebben.

[ Voor 21% gewijzigd door Verwijderd op 03-04-2010 16:22 ]

[wasted247]

Verwijderd schreef op zaterdag 03 april 2010 @ 16:11:
In theorie is er geen limiet aan hoeveel VM's je kunt draaien zolang je maar genoeg opslag en virtueel geheugen hebt dus inclusief je swap schijf.

Vergeet je nu niet hardstikke de CPU resources? Uiteraard is het limiet van de hoeveelheid VM's totaal afhankelijk van het soort VM's en de resources die deze gebruiken, al dan niet de fysieke hardware waar het zwikkie op draait.

Ik ben het met je eens dat je zoveel VM's kunt aanslingeren als je wilt, maar de vraag ik hier tot wanneer het verantwoord is, om zodoende redelijke performance te garanderen.

Verwijderd schreef op zaterdag 03 april 2010 @ 16:11:
Kortom, het hangt ook erg van je VM's af en of deze vooral CPU/RAM of I/O afhankelijk zijn. Een VM die vooral veel reken werk doet maar weinig RAM of I/O doet zoals een DPC koe zal meer hebben aan een snelle multi-core proccessor terwijl een file-server waarschijnlijk meer aan een snelle virtio schijf zal hebben.

Dat dus

[ Voor 24% gewijzigd door wasted247 op 03-04-2010 16:27 ]

[Verwijderd]

wasted247 schreef op zaterdag 03 april 2010 @ 16:19:
[...]


Vergeet je nu niet hardstikke de CPU resources? Uiteraard is het limiet van de hoeveelheid VM's totaal afhankelijk van het soort VM's en de resources die deze gebruiken, al dan niet de fysieke hardware waar het zwikkie op draait.

Ik ben het met je eens dat je zoveel VM's kunt aanslingeren als je wilt, maar de vraag ik hier tot wanneer het verantwoord is, om zodoende redelijke performance te garanderen.

(sorry van mijn post-edit hierboven, dacht dat ik de laatste was)

Klopt daarom zei ik ook in theorie. Er is vaak maar 1 manier om er echt achter te komen of het werkt en dat is uitproberen. Ik heb hier 7 VM's draaien onder KVM en elke VM (32bit) heeft 2GB RAM en geen swap. De host (64bit) heeft 2GB fysiek RAM en 16GB swap en dat werkt perfect. Ondanks dat de swap goed wordt gebruikt.

[ Voor 3% gewijzigd door Verwijderd op 03-04-2010 16:28 ]

[wasted247]

We snappen elkaar wel

Draait dat nog een beetje? Heb je er vast een fatsoenlijk disk setje onder hangen.

Ikzelf beheer een aantal ESX servers en hou kwa performance aan; RAM is RAM. Dus geen swap op de host. Maar dat is een overweging voor ieder opzich. Uiteraard is dit een bedrijfs omgeving welke klanten voorziet in hun servers, deze zouden er niet blij van worden als het toegewezen RAM op de achtergrond stiekum een HDD is

[chronoz]

Ik heb gistermiddag de tijd genomen om te kijken of er iets mis is op de 2 VM's en dat bleek wel het geval te zijn. De oorzaak van de hoge load op beide VM's bleek "cycling e-mail" te zijn. Hierdoor is de load van de VPS host nu niet meer 7.0, maar 0.4.

Echter tijdens de hoge load, bleek de server nog enorm snel en toen kwam ik tot de conclusie dat er echt actiever gekeken moet worden naar het CPU, geheugen- en I/O gebruik, omdat bij virtualisatie de load heel weinig zegt, omdat dit de accumulatieve load van de VM's is. In het geval van een enkele server, dan zegt de load vaak nog erg veel over de vrije capaciteit van een server.


De I/O is nu heel laag. Deze was gistermiddag ook 50mB per seconde, vanwege de cycling e-mail. De vraag welke CT/VM het meeste I/O nodig heeft gehad de afgelopen weken, vanwege de cycling mail is eenvoudig te beantwoorden. De CT/VM met 27TB aan totale I/O, puur e-mail I/O.

[Verwijderd]

wasted247 schreef op zaterdag 03 april 2010 @ 16:32:

Ikzelf beheer een aantal ESX servers en hou kwa performance aan; RAM is RAM. Dus geen swap op de host. Maar dat is een overweging voor ieder opzich. Uiteraard is dit een bedrijfs omgeving welke klanten voorziet in hun servers, deze zouden er niet blij van worden als het toegewezen RAM op de achtergrond stiekum een HDD is

Precies. Als het zuiver voor jezelf is, is dat misschien niet zo erg. Maar je kunt geen "RAM" aan je klanten verkopen als het geen fysieke RAM betreft.

[wasted247]

chronoz schreef op zaterdag 03 april 2010 @ 16:35:
De I/O is nu heel laag. Deze was gistermiddag ook 50mB per seconde, vanwege de cycling e-mail. De vraag welke CT/VM het meeste I/O nodig heeft gehad de afgelopen weken, vanwege de cycling mail is eenvoudig te beantwoorden. De CT/VM met 27TB aan totale I/O, puur e-mail I/O.

Ik zou me focussen op IOPS (I/O operations per second), niet de doorvoer snelheid. De IOPS bepalen je queue's, doorvoer snelheid is niet zo spannend cq. belangrijk (afhankelijk van de applicatie).

Verwijderd schreef op zaterdag 03 april 2010 @ 16:35:
Precies. Als het zuiver voor jezelf is, is dat misschien niet zo erg. Maar je kunt geen "RAM" aan je klanten verkopen als het geen fysieke RAM betreft.

Right on the money

Verwijderd schreef op zaterdag 03 april 2010 @ 16:45:
Ik gebruik trouwens een Intel Postville SSD. Met een 7200RPM schijf zou dat swappen waarschijnlijk wel tegenvallen. Vooral de lage zoektijden maken dat een VM niet lang hoeft te wachten totdat zijn geheugen er is.

Dat maakt het verschil. Hier (thuis) draai ik mijn VM's op een server met 8GB en een raid set van 6 disks in raid 5 op een dedicated controller met cache, die wil je geen RAM op de schijf geven. Met een SSD kan ik me voorstellen dat dat best te doen is.

[ Voor 44% gewijzigd door wasted247 op 03-04-2010 16:58 ]

[Verwijderd]

Klopt, als dit bedrijfs matig was en ik verkocht echt RAM dan zou ik een 4GB swap per VM toewijzen maar ik moet zeggen dat zo'n globale swap eigenlijk best goed werkt omdat zelden gebruikte pages automatische in de swap belanden en de VM's eigenlijk van elkaars RAM snoepen wordt mijn 2GB fysieke ram tot de max gebruikt.

Ik gebruik trouwens een Intel Postville SSD. Met een 7200RPM schijf zou dat swappen waarschijnlijk wel tegenvallen. Vooral de lage zoektijden maken dat een VM niet lang hoeft te wachten totdat zijn geheugen er is.

[ Voor 25% gewijzigd door Verwijderd op 03-04-2010 16:47 ]

[Verwijderd]

Volgensmij vergeten de meeste mensen hier dat Virtuozzo (commerciele versie van OpenVZ) heel wat anders is dan KVM, ESXi, Xen etc. OpenVZ, Linux VServer passen OS level virtualization toe. Het is niet nodig om tig hardware apparaten te emuleren. De host kernel wordt gedeeld met alle guest 'containers'. Geen behoefte aan Windows? Dan zou ik bij Virtuozzo blijven, want deze is velen malen efficienter dan KVM, Xen etc etc. Om de load te meten gebruik je standaard tools die op elk Linux systeem aanwezig zijn.

[Verwijderd]

Volgens mij vergeet Cagalli features van ESX zoals bijvoorbeeld vMotion en Disaster Recovery.

[wasted247]

Verwijderd schreef op zaterdag 03 april 2010 @ 21:22:
Volgens mij vergeten de meeste mensen hier dat Virtuozzo (commerciele versie van OpenVZ) heel wat anders is dan KVM, ESXi, Xen etc. OpenVZ, Linux VServer passen OS level virtualization toe. Het is niet nodig om tig hardware apparaten te emuleren. De host kernel wordt gedeeld met alle guest 'containers'. Geen behoefte aan Windows? Dan zou ik bij Virtuozzo blijven, want deze is velen malen efficienter dan KVM, Xen etc etc. Om de load te meten gebruik je standaard tools die op elk Linux systeem aanwezig zijn.

Het reken sommetje blijft toch hetzelfde? Je fysieke hardware heeft limieten, zolang die nog niet bereikt zijn is er meer ruimte voor VM's.