ESXi 5 - Langzaam netwerk tussen VM's

[Hoicks]

Ik heb op dit moment een N36L HP Microserver draaien met daarop twee vm's: Windows 2008 R2. De een is Domaincontroller en de ander is een Terminal Server.

Als ik echter tussen de twee vm's een 4GB imagebestand wil kopieren dan kom ik niet boven de 21MB/sec uit. Ik heb echter het idee dat de CPU de bottleneck is. Ik heb allerlei trucs uitgehaald om de cpu load omlaag te krijgen door TCP offloading uit te schakelen, maar dit helpt bijna niets.

iPerf haalt ook maar max 600Mbps tussen de twee VM''s, maar de schijven zijn wel snel genoeg. (getest met HDtune) Ik moet minimaal het dubbele kunnen halen.

Zou ik een performancewinst kunnen krijgen door geen gebruik te maken van de Broadcom onboard NIC, maar door gebruik te maken van een PCI-E NIC?

Ik ben bang dat dit niet gaat werken omdat het netwerkverkeer niet eens naar buiten komt en dat dit binnen Vmware wordt afgehandeld. Zijn er nog andere opties om CPU load te verlagen?

Beide machines gebruiken 2 vcpu's (de N36L heeft 1 CPU met 2 cores) en de OSén van de VM draaien op een Kingston SSD die minimaal 135MB/sec moet kunnen leveren tegen lage responstijd)

De N36L heeft 8GB totaal en de VM's hebben beiden 3GB toegewezen gekregen.

Wat ik niet snap is dat ik ook de mogelijkheid om 2 sockets toe te wijzen (naast 2 vcpu's). Kan iemand mij uitleggen wat dit inhoudt?

Onderstaande specs: de SSD is een 128GB SSD van Kingston en de andere HDD's zijn allemaal volledig toegewezen per guest.(Dus niet opgedeeld)

DC001
2vCPU
3GB RAM
C:\ 30GB SSD min 59.0MB/Sec max 562.9MB/Sec avg 91.9MB/sec Accesstime 0.6ms Burst 59.7 Cpu = -1.0%
D:\ 15GB SSD min 66.9MB/sec max 528.1 avg 299.4 Accesstime 0.4ms Burst 56.2 Cpu = -1.0%
E:\ 930GB HDD1 min 69.4MB/sec max 553.2MB/sec avg 146.3mB/sec Accesstime 12.1ms Burst 59.2MB/sec Cpu = -1.0
F:\ 232 GB HDD2 min 59.0MB/sec max 85.4MB/sec avg 78.4MB/sec Accesstime 13.2ms Burst 51.0MB/sec CPU = -1.0

TS001
2 VCPU
3GB RAN
C:\ 30GB SSD min 24.6 max 138.5 avg 66.7 Accesstime 0.9ms Burst 46.9 Cpu = -1.0%
D:\ 80GB HDD3 min 24.4 max 58.0 avg 46.2 Accesstime 14.1ms Burst 43.7 Cpu = -1.0%

Copy actie loopt van de 80GB HDD3 op TS001 naar de 930GB HDD1 op DC001

[ Voor 52% gewijzigd door Hoicks op 12-01-2012 13:18 ]

[Question Mark]

Wat voor diskconfig zit in het systeem en hoe heb je deze performance getest?

600Mbps is ~ 75 MB per seconde en dat zit ruim boven de snelheid die je nu haalt. Lijkt me dan niet dat je netwerk de bottleneck is. Zitten je vm's overigens op dezelfde vSwitch?

[Hoicks]

Question Mark schreef op donderdag 12 januari 2012 @ 12:44:
Wat voor diskconfig zit in het systeem en hoe heb je deze performance getest?

600Mbps is ~ 75 MB per seconde en dat zit ruim boven de snelheid die je nu haalt. Lijkt me dan niet dat je netwerk de bottleneck is. Zitten je vm's overigens op dezelfde vSwitch?

600Mbps is iperf en dat lijkt idd wel ok. Hoewel ik dit aan de lage kant vindt omdat het tenslotte wel 1Gbps zou moeten kunnen halen, lijkt mij.

De VM's draaien op een SSD en de data gaat van 1 fysieke disk (HDD) naar een andere fysieke disk (HDD).

Ik heb geen RAID opstelling. En de Vm's zitten op de zelfde vSwitch.

Ik heb de startpost even aangevuld met meer info

[ Voor 5% gewijzigd door Hoicks op 12-01-2012 12:56 ]

[Question Mark]

Inter-VM communicatie verloopt (als de vm's op dezelfde vswitch zitten) niet via het externe netwerk. Het aanpassen van fysieke nic's levert dan ook niets op.

Ik mis nog even de resultaten van de snelheidstest van de niet SSD disken, dat zijn immers de disken die je gebruikt voor je kopieerslag.

Hoicks schreef op donderdag 12 januari 2012 @ 12:39:
Wat ik niet snap is dat ik ook de mogelijkheid om 2 sockets toe te wijzen (naast 2 vcpu's). Kan iemand mij uitleggen wat dit inhoudt?

Je hebt hiermee de keuze om bv. 4 cpu's op 1 socket toe te kennen (quad-core cpu) of bv. 2 cpu's op 2 sockets (je deelt dan 2x een dual-core cpu uit). Sommige software-licenties kennen bv. restricties op max. aantal cpu-cores per socket, daarvoor kan deze instelling handig zijn.

Hoicks schreef op donderdag 12 januari 2012 @ 12:46:
[...]
600Mbps is iperf en dat lijkt idd wel ok. Hoewel ik dit aan de lage kant vindt omdat het tenslotte wel 1Gbps zou moeten kunnen halen, lijkt mij.

Let even op dat je dan wel jumbo-frames moet enablen...

[ Voor 16% gewijzigd door Question Mark op 12-01-2012 13:12 ]

[Hoicks]

Question Mark schreef op donderdag 12 januari 2012 @ 13:12:
Inter-VM communicatie verloopt (als de vm's op dezelfde vswitch zitten) niet via het externe netwerk. Het aanpassen van fysieke nic's levert dan ook niets op.

Ik mis nog even de resultaten van de snelheidstest van de niet SSD disken, dat zijn immers de disken die je gebruikt voor je kopieerslag.

De HDtune resultaten staan in de startpost nu.

[...]
Je hebt hiermee de keuze om bv. 4 cpu's op 1 socket toe te kennen (quad-core cpu) of bv. 2 cpu's op 2 sockets (je deelt dan 2x een dual-core cpu uit). Sommige software-licenties kennen bv. restricties op max. aantal cpu-cores per socket, daarvoor kan deze instelling handig zijn.

Maar er zit maar één dual core cpu in het systeem. Is het dan handig om twee sockets en 2 cores uit te delen?

[...]
Let even op dat je dan wel jumbo-frames moet enablen...

Jumbo frames staan uit, maar heb ik in het verleden weinig succes mee gehad. Ik zal dat zo nog eens testen

[Question Mark]

Hoicks schreef op donderdag 12 januari 2012 @ 13:21:
[...]
Maar er zit maar één dual core cpu in het systeem. Is het dan handig om twee sockets en 2 cores uit te delen?

Je overcommit dan eigenlijk je cpu. Kijk in de performance-tab van je vm's eens naar de waarde van "cpu-ready". Dit is een indicator dat de vm eigenlijk cpu-time wilt, maar dit niet kan krijgen van de scheduler omdat er geen cpu capaciteit beschikbaar is.

[Hoicks]

Ik heb Jumbo frames op 9000 gezet (enige waarde die ik behalve 1500 kan kiezen) de snelheid van copy actie van DC001\E naar TS001\D is met ongeveer 8MB/sec toegenomen (nu 30MB/sec). Van TS001\D naar DC001\E is nu met ongeveer 2MB/sec toegenomen (nu 23MB/sec)

[Hoicks]

Kan je mij uitleggen hoe ik die grafiek moet lezen?



Die hoge rode lijn zijn uitschieters tijdens de kopie actie.

[ralpje]

Wellicht vragen naar de bekende weg, maar heb je VMWare Tools geïnstalleerd in de beide guests?

[Hoicks]

ralpje schreef op donderdag 12 januari 2012 @ 14:09:
Wellicht vragen naar de bekende weg, maar heb je VMWare Tools geïnstalleerd in de beide guests?

Ja. VMWARE tools zijn op beide VM's geinstalleerd.

[Question Mark]

Je vm's wachten tijdens de cpu-ready time totdat er twee fysieke cores "gelijktijdig" vrij zijn. Aangezien ze beiden nu moeten vechten om cpu-time (je hebt immers maar twee cores) staan de vm's gewoon te wachten.

Geef ze eens 1 cpu en test dan nog eens? Post ook even de cpu-ready waardes.

[Hoicks]

Question Mark schreef op donderdag 12 januari 2012 @ 14:38:
Je vm's wachten tijdens de cpu-ready time totdat er twee fysieke cores "gelijktijdig" vrij zijn. Aangezien ze beiden nu moeten vechten om cpu-time (je hebt immers maar twee cores) staan de vm's gewoon te wachten.

Geef ze eens 1 cpu en test dan nog eens? Post ook even de cpu-ready waardes.

Allebei hebben u 1 vcpu en kopieren gaat nu met 30MB/sec constadus van DC001 naar TS001 en vice versa.

Vanavond maar eens kijken hoe snel kopieren gaat tussen VM en niet VM. Het is eigenlijk wel zonde om beide machines hun eigen core te geven om een beetje netwerksnelheid te krijgen.

CPU ready waardes liggen nu voor beide machines bijna op 0ms. Niet zo vreemd omdat ze beiden nu een dedicated core hebben toegewezen lijkt het.

[hans_lenze]

Hoicks schreef op donderdag 12 januari 2012 @ 15:22:
[...]
Vanavond maar eens kijken hoe snel kopieren gaat tussen VM en niet VM. Het is eigenlijk wel zonde om beide machines hun eigen core te geven om een beetje netwerksnelheid te krijgen.

Waarom is het zonde om een eigen core te geven? Best practise van VMware zegt: 1 core voor de hypervisor reserveren. Dat betekent dat je op een quadcore machine maximaal 3 vCPU's aan een VM geeft.

Idee is altijd dat je zo min mogelijk vCPU's toewijst zodat er zoveel mogelijk tegelijk kunnen werken. Pas als er een performance bottleneck ontstaat door het aantal vCPU's hoor je er meer toe te voegen. (En dus niet vanaf de start omdat het 'dan vast sneller gaat'.)