Vraag vSphere-educatie - Wat zijn de nadelen van het configureren van VM's met * te veel RAM-geheugen?


VMware-geheugenbeheer lijkt een lastige evenwichtsoefening te zijn. Met cluster-RAM, Resource Pools, VMware's managementtechnieken (TPS, ballonvaren, host-swapping), in-guest RAM-gebruik, swappen, reserveringen, aandelen en limieten, zijn er veel variabelen.

Ik zit in een situatie waarin clients toegewijde vSphere-clustervoorzieningen gebruiken. Ze configureren echter de virtuele machines alsof ze op fysieke hardware staan. Dit betekent op zijn beurt dat een standaard VM-build 4 vCPU's en 16 GB of meer RAM-geheugen kan hebben. Ik kom van de school voor klein beginnen (1 vCPU, minimale RAM), controleer het gebruik in de echte wereld en pas het zo nodig aan. Helaas vragen veel leveranciersvereisten en mensen die onbekend zijn met virtualisatie om meer middelen dan nodig is ... Ik ben geïnteresseerd in het kwantificeren van de impact van deze beslissing.


Enkele voorbeelden van een "probleem" -cluster.

Resource pool samenvatting - Ziet er bijna 4: 1 overbelast. Let op de grote hoeveelheid gebufferde RAM. enter image description here

Resourcetoewijzing - De kolom Slechtste caseallocatie laat zien dat deze VM's onder beperkte voorwaarden toegang hebben tot minder dan 50% van hun geconfigureerde RAM. enter image description here

De grafiek voor real-time geheugengebruik van de bovenste VM in de bovenstaande lijst. 4 vCPU en 64 GB RAM toegewezen. Het gemiddelde is minder dan 9 GB. enter image description here

Samenvatting van dezelfde VM enter image description here


  • Wat zijn de nadelen van overcommitterende en overconfigurerende bronnen (met name RAM) in vSphere-omgevingen?

  • Ervan uitgaande dat de VM's in minder RAM kunnen worden uitgevoerd, is het redelijk om te stellen dat er overhead is om virtuele machines te configureren met meer RAM dan ze werkelijk nodig hebben?

  • Wat is het tegenargument om: "als een VM 16 GB RAM heeft toegewezen, maar slechts 4 GB gebruikt, wat is dan het probleem?"? Bijvoorbeeld, moeten klanten dat leren VM's zijn niet hetzelfde als fysieke hardware?

  • Welke specifieke statistiek (en) moeten worden gebruikt om het RAM-gebruik te meten. De pieken van "Actief" versus tijd volgen? "Verbruikt" kijken?


Bijwerken: ik gebruikte vCenter Operations Manager om deze omgeving te profileren en meer informatie te krijgen over de bovenstaande clusterstatistieken. Hoewel dingen absoluut te zwaar worden belast, zijn de VM's dat wel zo overconfigureerd met onnodig RAM-geheugen dat de echte (kleine) geheugenvoetafdruk geen geheugenconflict toont op het cluster- / hostniveau ...

Mijn conclusie is dat VM's echt de juiste grootte moeten hebben met een klein beetje buffer voor caching op OS-niveau. Overcommando uit onwetendheid of 'eisen van leveranciers' leidt tot de hier gepresenteerde situatie. Geheugen ballonvaren lijkt in elk geval slecht te zijn, omdat er een impact op de prestaties is, dus het rechtzetten kan dit helpen voorkomen.

Update 2: Sommige van deze VM's beginnen vast te lopen met:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware beschrijft dit als een symptoom van overcommitment van zwaar geheugen. Dus ik denk dat dat de vraag beantwoordt.

enter image description here


vCops "Oversized Virtual Machines" -rapport ... enter image description here

vCops "Reclaimable Waste" -grafiek ...

enter image description here


54
2017-08-02 15:14


oorsprong




antwoorden:


vSphere's geheugenbeheer is redelijk, hoewel de gebruikte termen vaak voor veel verwarring zorgen.

Over het algemeen moet geheugenoverschrijding worden vermeden omdat dit precies dit type probleem veroorzaakt. Er zijn echter momenten waarop het niet kan worden vermeden, dus een gewaarschuwd mens telt voor twee!

Wat zijn de nadelen van overcommiterende en overconfigurerende bronnen   (specifiek RAM) in vSphere-omgevingen?

Het grootste nadeel van overcommiteerde bronnen is dat, als je ruzie hebt, je hosts gedwongen worden om achter de schermen te balloneren, verwisselen of intelligent te plannen / decoderen om elke VM de RAM te geven die hij nodig heeft.

Voor ballonvaren zal vSphere een "ballon" RAM in een gekozen VM oppompen, en dan dat lege RAM geven aan de gast die het nodig heeft. Dit is niet echt "slecht" - VM's stelen elkaars RAM, dus er vindt geen schijfruil plaats - maar het kan leiden tot foutieve waarschuwingen en scheve statistieken als deze afhankelijk zijn van het analyseren van het RAM-gebruik van de VM, omdat de RAM heeft gewonnen niet gemarkeerd als "geblokt", alleen dat het door het besturingssysteem "in gebruik" is.

De andere functie die vSphere kan gebruiken, is Transparent Page Sharing (TPS) - in feite RAM-de-duplicatie. vSphere scant periodiek alle toegewezen RAM-geheugen, op zoek naar dubbele pagina's. Wanneer het wordt gevonden, zal het dupliceren en de gedupliceerde pagina's vrijmaken.

Kijk eens naar vSphere's whitepaper over geheugenbeheer (PDF) - specifiek "Geheugenterugloop in ESXi" (pagina 8) - als u een meer diepgaande uitleg nodig hebt.

Ervan uitgaande dat de VM's kunnen werken in minder RAM, is het eerlijk om dat te zeggen   er is overhead voor het configureren van virtuele machines met meer RAM dan   Zij hebben nodig?

Er is geen zichtbare overhead - u kunt 100 GB RAM toewijzen aan een host met 16 GB (maar dat betekent niet dat u dat doet moeten, om de redenen hierboven).

Het totale geheugen dat door al uw VM's wordt gebruikt, is de curve 'Actief' die in uw grafieken wordt weergegeven. Natuurlijk moet je nooit alleen op dat getal rekenen bij het berekenen van hoeveel je wilt overcommiteren, maar als je historische meetwaarden hebt zoals je hebt, kun je het analyseren en uitwerken op basis van daadwerkelijk gebruik.

Het verschil tussen "Actief" en "Verbruikt" RAM wordt hier besproken VMWare Community-thread.

Wat is het tegenargument om: "als een VM 16 GB RAM heeft toegewezen,   maar gebruikt slechts 4GB, wat is het probleem ?? "? Bijv. moeten klanten zijn   geleerd?

Het korte antwoord hierop is Ja - klanten zouden dat moeten doen altijd worden opgeleid in best practices, ongeacht de tools die ze tot hun beschikking hebben.

Klanten moeten worden opgeleid om hun VM's op maat te maken op basis van wat zij doen gebruik, in plaats van wat zij willen. Vaak zullen mensen hun VM's te veel specificeren alleen maar omdat ze dat doen macht hebben 16 GB RAM nodig, ook als ze van oudsher dag in, dag uit op 2 GB stuntelen. Als een vSphere-beheerder beschikt u over de kennis, statistieken en de kracht om ze uit te dagen en hen te vragen of ze het RAM-geheugen dat ze hebben toegewezen, daadwerkelijk nodig hebben.

Dat gezegd hebbende, als u vSphere's geheugenbeheer combineert met zorgvuldig gecontroleerde overcommit limieten, zou u in de praktijk zelden een probleem moeten hebben, de waarschijnlijkheid dat een RAM-geheugen voor een langere periode opraakt, is betrekkelijk ver weg.

In aanvulling hierop, geautomatiseerde vMotion (genoemd Distributed Resource Scheduling door VMware) is in wezen een load-balancer voor uw VM's - als een enkele VM een resource hog wordt, moet DRS VM's migreren om optimaal gebruik te maken van de resources van de cluster.

Welke specifieke statistiek moet worden gebruikt om het RAM-gebruik te meten. Volg de   pieken van "Actief" versus tijd?

Meestal wordt hierboven behandeld - uw belangrijkste zorg moet "Actief" RAM-gebruik zijn, maar u moet uw overcommit drempelwaarden zorgvuldig definiëren, zodat als u een bepaalde verhouding bereikt (dit is een fatsoenlijk voorbeeld, hoewel het enigszins verouderd kan zijn). Normaal gesproken zou ik zeker binnen 120% van het totale cluster-RAM blijven, maar het is aan jou om te beslissen met welke ratio je je comfortabel voelt.

Enkele goede artikelen / discussies over geheugen over-commit:


43
2017-08-02 17:09



Ik heb begrepen dat meer RAM toegewezen aan een VM betekent dat het voor DRS moeilijker is om de VM te migreren - het kost meer tijd om te migreren tussen knooppunten omdat het langer duurt om de RAM te kopiëren; en hoe meer RAM nodig is, hoe minder waarschijnlijk het is dat DRS een groot genoeg deel kan vinden dat gratis is. Dit kan met name lastig zijn (ik heb het laten geloven) als je een gebeurtenis hebt (bijvoorbeeld een hardwaredefect) die de capaciteit in het cluster vermindert. Kleine VM's zijn gemakkelijk te shufflen en zullen waarschijnlijk niet snel uitvallen, grote VM's kunnen lastig zijn. Ben ik op de hoogte gebracht? - James Polley
@James - alleen actief (dat wil zeggen in gebruik) geheugen wordt gemigreerd tijdens vMotion, dus de hoeveelheid RAM die u toewijst aan uw VM's maakt niet zoveel uit. Referentie: vmware.com/files/pdf/VMware-VMotion-DS-EN.pdf - Craig Watson
Goed antwoord. Ik heb mijn vraag met meer detail van deze specifieke cluster bijgewerkt. Je punten zijn echter goed. Het blijkt dat de VM's in deze opstelling zwaar overconfigureerd zijn. Het gebruik van actieve RAM ligt ver onder de fysieke bronnen van het cluster, dus er is geen discussie ... gewoon zwaar ballonvaren / wisselen / lelijkheid. Ik vermoed dat een juiste dimensionering van de VM's deze druk zal verlichten. - ewwhite


Naast het uitstekende antwoord van Craig Watson zou ik het volgende willen toevoegen:

Een overdreven geheugen in VMware is niet iets dat je expres moet doen. Het laat meestal zien dat u of uw klant de hardware oversubscribeert.

Als over-committing de enige keuze is dan ik sterk adviseren dat u prioriteitsregels afdwingt. Als iemand erop uit is om een ​​niet-kritieke VM 16GB aan vRam te geven wanneer deze slechts 4 GB nodig heeft, dan moet die VM tenminste in een lage resourcepool worden geplaatst of een lage prioriteit krijgen. Je wilt echt niet dat een kritieke productiedatabase wordt uitgewisseld door de hypervisor. Niet alleen zullen de prestaties in de put lopen, het zal ook de I / O-wachtrijen opeten tegen uw back-endopslag.

Als je op razendsnelle opslag draait (FusionIO, Viool, lokale SSD's enz.) Dan is ruilen misschien geen grote zorg, maar met traditionele SAN-opslag zul je uiteindelijk elke afzonderlijke VM en host die op dezelfde array / controller is aangesloten beïnvloeden.


19



Goede observatie van de storage-impact van swapping. Dit verklaart enkele van de VNX-prestatieproblemen die ik heb gezien ... - ewwhite
Schitterend punt, ik heb nooit gedacht om het IO-argument voor opslag te nemen, - Dan