Resource monitoring shared hyper-v

[knifto]

ik heb een 10 node hyper-v cluster met een HP P4500 storage cluster erachter. Het hyper-v platform wordt gebruikt om IAAS aan te bieden.

Nu is het vanaf Hyper-v 3.0 mogelijk om resource monitoring aan te zetten per VM.

Ik vind echter geen praktijkvoorbeelden hoe dit het beste te monitoren/rapporteren.

Ik heb N-Able en eventueel SCOM tot mijn beschikking.

RAM en CPU vindt ik niet zo heel spannend. Het gaat mij vooral om de load die de VM's richting het storage platform geven. Iemand die mij op weg kan helpen?

[MAX3400]

Resource Monitoring of Resource Metering? Het aantal karakters is amper anders maar de aanpak des te groter.

Je zal voor Metering met PowerShell aan de gang moeten (op je Hyper-V hosts of op een machine met alle Hyper-V cmdlets geinstalleerd en WinRM) en dan kan je met Metering zien wat elke VM "binnen zijn eigen schil" aan het verzieken/doen is qua resources.

Maar als je de load op het storage-platform wil meten/weten, zal je toch echt op host-niveau of op je storage-protocol moeten ingrijpen en daar wat uithalen. De manier waarop je startpost is opgebouwd, zeg ik voorlopig even dat je bij HP moet gaan kijken hoe je je P4500 gaat monitoren.

/edit: je zou eventueel ook nog even kunnen kijken naar de hele Microsoft System Center Suite; die is uitermate ontwikkeld voor (onder andere) Azure / IAAS environments inclusief back-end en front-end ACL's.

[ Voor 14% gewijzigd door MAX3400 op 01-03-2016 08:12 ]

[hans_lenze]

Klinkt als zoiets: https://gallery.technet.m...tering-script-to-19dd9a95
Met een simpele rekensom is de delta van de disk prima te berekenen waardoor storage ook toe te voegen is aan het rapportje.

Edit: de achterliggende cmdlet https://technet.microsoft.../hh848471(v=wps.630).aspx
Hij heeft een meetperiode van een uur (langer is in te stellen, korter niet) dus eens per uur verzamelen is handig. Disk IO houdt hij gesplitst bij (reads en writes) dus daar kun je ook nog dingen mee doen.

[ Voor 40% gewijzigd door hans_lenze op 01-03-2016 08:35 ]

[knifto]

@Max3400
Met de totale load op het storage platform kan ik niet zo veel, ik wil juist weten welke VM de load genereerd. Agents in de VM is geen optie, ik wil het monitoren vanuit de host.

@hans_lenze
De CSV generator kan ik wel wat mee in het begin, al zal ik het liever opnemen in een monitorpakket.
De SystemCenterSuite heb ik tot mijn beschikking maar ik vind het wat lastig om hier mijn weg in te vinden

[MAX3400]

knifto schreef op dinsdag 01 maart 2016 @ 08:45:
@Max3400
Met de totale load op het storage platform kan ik niet zo veel, ik wil juist weten welke VM de load genereerd. Agents in de VM is geen optie, ik wil het monitoren vanuit de host.

Sorry maar klok/klepel?

Het komt op mij allemaal een beetje vrijblijvend over; je wil iets meten/weten maar hebt, voor zover ik kan lezen, geen enkele informatie opgeleverd wat je zelf al had bedacht. Ook staat er absoluut niets vermeld over een (gedeeltelijke) technische inrichting waardoor er tips/hints kunnen worden gegeven over waar je iets moet gaan zoeken. Beetje posten "dit heb ik aan hardware; doe mij eens een getal".

- 0 info over wat voor generation VM's
- 0 info over wat voor host-OS
- 0 info over networking
- 0 info over storage / protocollen
- 0 info over enige policies whatsoever zoals Storage QoS

For all I know heb je gewoon je NIC's al op de verkeerde OSI-laag "getrunkt" en heb je nu te maken met minstens 4% overhead op die laag. Of je P4500 draait op een firmware waar je ergens in een ini-file een 1 ipv 0 hebt staan om je caching anders te gebruiken.

Load (whatever that may be) meten en daadwerkelijk benoemen zijn 2 hele aparte onderwerpen; het lijkt me zinvol om even naar de (Paint-) tekentafel terug te gaan en meer handvatten aan te leveren in dit topic voor een redelijker/duidelijker antwoord.

[knifto]

MAX3400 schreef op dinsdag 01 maart 2016 @ 08:56:
[...]

Sorry maar klok/klepel?

Het komt op mij allemaal een beetje vrijblijvend over; je wil iets meten/weten maar hebt, voor zover ik kan lezen, geen enkele informatie opgeleverd wat je zelf al had bedacht. Ook staat er absoluut niets vermeld over een (gedeeltelijke) technische inrichting waardoor er tips/hints kunnen worden gegeven over waar je iets moet gaan zoeken. Beetje posten "dit heb ik aan hardware; doe mij eens een getal".

- 0 info over wat voor generation VM's
- 0 info over wat voor host-OS
- 0 info over networking
- 0 info over storage / protocollen
- 0 info over enige policies whatsoever zoals Storage QoS

For all I know heb je gewoon je NIC's al op de verkeerde OSI-laag "getrunkt" en heb je nu te maken met minstens 4% overhead op die laag. Of je P4500 draait op een firmware waar je ergens in een ini-file een 1 ipv 0 hebt staan om je caching anders te gebruiken.

Load (whatever that may be) meten en daadwerkelijk benoemen zijn 2 hele aparte onderwerpen; het lijkt me zinvol om even naar de (Paint-) tekentafel terug te gaan en meer handvatten aan te leveren in dit topic voor een redelijker/duidelijker antwoord.

Generatie VM's zijn gemixed Gen1 en Gen2
Host OS is 2012r2
Networking is middels 2x1GBit iSCSI (MPIO) per host naar het storage cluster (4x HP P4500)
Policies en storage QoS zijn (nog) niet geimplementeerd, ik wil eerst weten of dit zinvol is door boven water te krijgen of het nodig is/zin heeft.

Ik denk dat je wat voorzichtig moet zijn met conclusies trekken over hoe ik mijn NICS/Networking heb ingeregeld, deze zitten dus niet getrunkt, maar werken middels MPIO.
(Ik zie echter niet wat deze informatie met het uitlezen van IOPS per VM er mee te maken hebben, maar goed).

Load meten, watever that may be, heb ik duidelijk aangegeven. Ik wil weten welke VM er verantwoordelijk is voor de totale load richting mijn storage cluster.
De IOPS op het storage cluster heb ik in beeld, alleen is dit een totaal plaatje wat niet terug te herleiden is naar een bepaalde VM.

Wat ik zelf al had bedacht;

VM-ResourceMetering is wat ik wil gebruiken (had ik ook al aangegeven). Ik krijg middels powershell de informatie die ik wil hebben, maar deze zit nog niet in een grafiek of in een rapport.
Vandaar ook de vraag of iemand dit heeft geimplementeerd binnen N-Able of SCOM.

[Question Mark]

knifto schreef op dinsdag 01 maart 2016 @ 10:02:
[...]
Load meten, watever that may be, heb ik duidelijk aangegeven. Ik wil weten welke VM er verantwoordelijk is voor de totale load richting mijn storage cluster.

Leg dan eens uit wat jouw definitie van load is?

• Is dat het aantal gemiddelde aantal iops over een x-periode?
• Is dat het maximaal aantal iops wat een VM verbruikt?
• Wil je weten wat de avg used bandwith is op je SAN over een x-periode?
• Wil je weten wat de max used bandwith is op je SAN?

MAX3400 vraagt veel door, maar dat vind ik eigenlijk alleen maar goed. Er is niks mis met wat achtergrondinformatie.

[MAX3400]

knifto schreef op dinsdag 01 maart 2016 @ 10:02:
[...]

Generatie VM's zijn gemixed Gen1 en Gen2

Dus 2 exact dezelfde VMs van andere Gen kunnen dus wisselende performance ten opzichte van elkaar halen/genereren; dat lijkt me al een onwenselijke tot slecht meetbare/herleidbare situatie. Ik weet uit ervaring dat 2 exact dezelfde SQL-inrichtingen op Gen1 en Gen2 tot wel 15% performance-verschil hadden naar "shared" iSCSI-storage. Als je al kan uitsluiten dat Gen1 of Gen2 issues bij jou veroorzaakt, ben je al een heeeel stuk verder.

Host OS is 2012r2
Networking is middels 2x1GBit iSCSI (MPIO) per host naar het storage cluster (4x HP P4500)
Policies en storage QoS zijn (nog) niet geimplementeerd, ik wil eerst weten of dit zinvol is door boven water te krijgen of het nodig is/zin heeft.

Geen QoS policies? Het kan maar is geen best practice voor dit soort setups. Tenminste, op het moment dat je een N+1 cluster (dus hot migration en ander zaken) inricht, doe ik uit mijn hoofd dat je minimaal 3 NIC's moet inzetten voor mgmt-vlan, vm-vlan en storage-vlan. Ga je trunken/MPIO'n/ whatever om meer bandbreedte te generen, zal je voor elk vlan dus minstens 1 extra fysieke NIC moeten koppelen en configureren.

Ook het type/merk/firmware van elke NIC, zowel virtueel als fysiek, zou je op alle fronten zo veel mogelijk hetzelfde moeten hebben. Dit houdt dus ook in dat je je Integration Services moet slipstreamen na een update van het host OS, over het algemeen. Ongetwijfeld is je update-policy voor de hosts & VM's volledig in orde maar bedenk toch even of je niet iets triviaals over het hoofd hebt gezien.

Load meten, watever that may be, heb ik duidelijk aangegeven. Ik wil weten welke VM er verantwoordelijk is voor de totale load richting mijn storage cluster.

Zeker lastig; op een 10-node Hyper-V cluster, waar ik voor het gemak even 64GB RAM per node in zet, kan ik alles draaien van ongeveer 56 2003DC's per node of misschien 1 vette 60GB RAM / 64TB storage Exchange 2013 Server. Natuurlijk is dit een onzinnig voorbeeld maar de rollen van elke VM alsmede de virtuele storage (fat/thin-provisioned, dedup/non-dedup, etc. etc.) hebben een enorme invloed op de performance van een VM en mogelijk ook de performance van je LeftHands.

Ik weet ook niet of je kan beginnen met bepaalde metrics op je storage-layer uit te lezen; mijn sterke kant lag op NetApp niveau en daar had je alleen al een handboek 2 duimen dik om het cache/flash-geheugen te installeren, configureren en monitoren; dat was ook voordat er maar 1 disk daadwerkelijk opspinde of als aggregate/lun/volume werd toegekend.

Overbodig om te melden maar ik neem aan dat alle hosts ook 100% gelijk zijn? Nog geen firmware verschil tussen de eigen controllers / chipsets? Allemaal exact dezelfde type RAM? Zelfde CPU's (want L1 tot L3 caching) etc. etc. etc.? Geen wazige/overboekte NUMA nodes?