Azure VM's juist dimensioneren: een praktische gids

Azure VM right-sizing is de praktijk van het afstemmen van de grootte van een virtual machine, de SKU, op de CPU, het geheugen en het netwerk die deze werkelijk gebruikt, in plaats van de grootte waarop deze toevallig is geïmplementeerd. In de meeste omgevingen zijn sommige machines gedimensioneerd voor een lanceringspiek of overgezet van on-premises hardware, en draaien ze sindsdien onder dat plafond. Om Azure virtual machines goed juist te dimensioneren, verzamelt u gebruiksbewijs over een representatieve periode, meestal 30 dagen, vindt u de machines waarvan het aanhoudende en piekgebruik ruim onder hun toegewezen capaciteit liggen, en verplaatst u ze vervolgens naar een kleinere SKU met verstandige marge. Gedaan met bewijs in plaats van een vermoeden, is het een van de meest herhaalbare manieren om Azure-computekosten te verlagen terwijl de workload blijft draaien.

Deze gids doorloopt de volledige lus: waarom machines te groot worden, hoe u het bewijs verzamelt, de Advisor-aanbevelingen leest, een doelgrootte kiest, een Azure VM veilig van formaat wijzigt, en het resultaat vastlegt. De cijfers zijn indicatief, omdat ze afhangen van uw omgeving, maar de methode is overal toepasbaar.

Waarom virtual machines te groot worden

Te groot dimensioneren begint zelden als een fout. Het begint als voorzichtigheid die nooit opnieuw wordt bekeken.

• Gedimensioneerd voor de lanceringspiek. Een machine wordt toegewezen voor de drukste dag die deze ooit zou kunnen zien, een migratieomschakeling, een lancering, een seizoenspiek, en dan gaat de drukke dag voorbij en blijft de grootte.
• Lift-and-shift-gewoonten. Wanneer een workload verhuist van een fysieke of on-premises server, matchen teams vaak de oude core- en geheugenaantallen één op één, ook al was die machine zelf gekocht met jaren aan marge ingebouwd.
• Marge als verzekering. Een grotere grootte voelt veiliger dan een keuze die iets te krap uitvalt, dus de veiliger ogende optie wint standaard.
• Niemand is eigenaar van de review. De grootte wordt eenmaal bij implementatie ingesteld en nooit getoetst aan wat de machine doet, dus de rekening weerspiegelt geruisloos een beslissing die niet langer klopt.

Geen van deze is onredelijk op het moment zelf. Het probleem is dat het moment eindigt en de grootte niet.

Verzamel het bewijs met Azure Monitor

Juist dimensioneren zonder gegevens is gokken met extra stappen, dus begin met het gebruik. Azure Monitor verzamelt automatisch platformmetrieken voor elke virtual machine, zonder dat een agent of configuratie vereist is.

Open in de portal Virtuele machines, selecteer de machine, en kies vervolgens onder Bewaking de optie Metrische gegevens voor ruwe grafieken of Insights en vervolgens het tabblad Prestaties voor een samengestelde weergave. De metriek die het meest telt voor het dimensioneren van compute is Percentage CPU, een platformmetriek op hostniveau die als percentage wordt gerapporteerd met een korrel van één minuut en een gemiddelde als standaardaggregatie. Beoordeel niet op het gemiddelde alleen: breng de aanhoudende lijn en het 95e percentiel samen in kaart, want een machine kan gemiddeld rustig lijken maar toch marge nodig hebben voor korte, regelmatige uitschieters. De grafiek van CPU-gebruik in de Prestaties-weergave staat standaard op het gemiddelde en het bovenste 95e percentiel.

Geheugen vraagt enige zorg. De platformmetrieken op hostniveau tonen Available Memory Bytes, maar de granulaire tellers op gastniveau die bijhouden hoeveel geheugen het besturingssysteem werkelijk vastlegt, worden verzameld via de Azure Monitor-agent binnen de machine, niet standaard. Als u van plan bent op geheugen én CPU te dimensioneren, plaats dan eerst de agent, en lees vervolgens het beschikbare geheugen over hetzelfde venster. De grafiek van beschikbaar geheugen in de Prestaties-weergave staat standaard op het gemiddelde plus het bovenste 5e en 10e percentiel, en toont de krappe momenten in plaats van de comfortabele.

Kijk over ten minste 30 dagen zodat één rustig weekend of drukke week het beeld niet vertekent. Wat u wilt voordat u handelt, is een machine waarvan de CPU op het 95e percentiel en het laagste beschikbare geheugen beide comfortabel onder de toegewezen grootte liggen.

De right-sizing-lus draait op bewijs: meten, shortlisten, limieten controleren, formaat wijzigen, en vervolgens verifiëren en vastleggen.

Lees de Azure Advisor-aanbevelingen

Zodra u een gevoel hebt voor het gebruik, laat u Azure Advisor het zware patroonwerk doen. Zoek onder Advisor en vervolgens het tabblad Kosten naar Onderbenutte virtuele machines juist dimensioneren of afsluiten. Advisor gebruikt machine-learning-modellen over uw gebruik om voor elke kandidaat een formaatwijziging of afsluiting voor te stellen, en toont de huidige en de doelgrootte voor een formaatwijziging.

Het helpt om op hoofdlijnen te weten hoe deze worden afgeleid, zodat u ze kunt vertrouwen zonder ze als evangelie te behandelen:

• Afsluitaanbevelingen markeren machines die over het terugkijkvenster feitelijk ongebruikt zijn. De criteria gebruiken CPU- en uitgaand netwerkgebruik, niet geheugen, en een afsluiting wordt voorgesteld wanneer bijvoorbeeld het 95e percentiel van de maximale CPU, opgeteld over de cores, onder de 3 procent blijft en het uitgaande netwerk onder de 2 procent.
• Formaatwijzigingsaanbevelingen kunnen SKU-familie en -versie overschrijden, en houden rekening met beperkingen zoals of het doel accelerated networking en premium storage ondersteunt, of het beschikbaar is in de regio, en of de machine zich in een availability set bevindt.
• De terugkijkperiode staat standaard op zeven dagen maar is instelbaar op 7, 14, 21, 30, 60 of 90 dagen, en een wijziging kan tot 48 uur duren om door te werken. U kunt ook filteren welke machines verschijnen door een gemiddelde CPU-drempel in te stellen onder Configuratie en vervolgens het tabblad VM/VMSS right sizing (rechten van abonnementseigenaar, tot 24 uur om toe te passen), wat verandert wat u ziet, niet hoe aanbevelingen worden gegenereerd.

Twee eerlijke kanttekeningen. De besparingscijfers van Advisor gebruiken retailtarieven en negeren eventuele reserverings- of savings plan-kortingen die u hebt, dus het koptekstcijfer kan hoger uitlezen dan u werkelijk realiseert. En de getoonde volledige potentiële jaarbesparing geldt voor het afsluiten of verwijderen van een machine; een formaatwijziging bespaart meestal echt geld, maar niet dat volledige bedrag. Behandel de aanbevelingen als een sterk onderbouwde shortlist, geen belofte.

Kies de doel-SKU

De Advisor-suggestie is een startpunt, niet de enige optie. Wanneer u een doelgrootte kiest, weegt u een paar zaken tegen elkaar af.

• Passende familie. De general-purpose D-serie past bij gebalanceerde workloads, de geheugengeoptimaliseerde E-serie past bij databases en caches, de compute-geoptimaliseerde F-serie past bij CPU-gebonden werk, en de burstable B-serie past bij workloads met een laag gemiddelde en pieken. Omlaag gaan binnen de juiste familie is schoner dan tussen families springen.
• Groottes met beperkte cores. Waar licentiëring per core de werkelijke kostenaanjager is, behouden groottes met beperkte vCPU het geheugen, de opslag en de bandbreedte van een grotere SKU terwijl ze het factureerbare aantal cores verlagen.
• Regiobeschikbaarheid. Een grootte die in de ene regio wordt aangeboden, bestaat mogelijk niet in een andere, dus bevestig dat het doel beschikbaar is waar de machine zich bevindt.
• Schijf- en netwerklimieten. Het maximale aantal dataschijven, IOPS, doorvoer en netwerkinterfaces zijn allemaal gebonden aan de grootte. Te ver zakken kan een machine afknijpen die nooit CPU-gebonden was, dus toets de limieten van het doel aan wat de workload koppelt en aanstuurt.

Laat marge. Het doel is een grootte die de belasting op het 95e percentiel comfortabel dekt, niet een die de eerste drukke middag heet loopt.

Voer de formaatwijziging uit, en verwacht een herstart

Een formaatwijziging is snel, maar verstorend, dus plan het als zodanig. Het wijzigen van de grootte van een draaiende virtual machine veroorzaakt een herstart, het best uitgevoerd tijdens daluren. Als de doelgrootte niet beschikbaar is op het hardwarecluster dat de machine momenteel host, moet u deze eerst de-alloceren, wat de machine stopt, elk dynamisch openbaar IP-adres vrijgeeft en de tijdelijke schijf kan wissen; de OS- en dataschijven blijven ongemoeid.

Er zijn drie gangbare manieren om het te doen:

• Portal. Open de machine, ga naar Beschikbaarheid + schaal en vervolgens Grootte, kies uit de beschikbare lijst en selecteer Formaat wijzigen.
• Azure CLI. Vermeld clusteropties met az vm list-vm-resize-options, en voer vervolgens az vm resize --size <NewSize> uit. Als de grootte niet in de lijst staat, eerst az vm deallocate, formaat wijzigen, en dan az vm start.
• PowerShell. Vermeld opties met Get-AzVMSize, stel $vm.HardwareProfile.VmSize in, en pas vervolgens toe met Update-AzVM.

Als de machine zich in een availability set bevindt en de nieuwe grootte niet op het huidige cluster staat, moet u mogelijk eerst elke machine in de set de-alloceren. Plan het in en informeer de eigenaar van de workload vooraf, niet achteraf.

Verifieer de wijziging en leg de besparing vast

Een formaatwijziging is niet klaar wanneer de machine herstart. Controleer dezelfde Azure Monitor-metrieken voor CPU-gebruik en beschikbaar geheugen opnieuw over de volgende dagen om te bevestigen dat de kleinere grootte standhoudt onder werkelijke belasting met de marge intact. Als deze heet loopt, ga dan een stap terug omhoog; dat is onderdeel van de lus, geen mislukking.

Leg vervolgens het bewijs vast. Noteer de grootte vóór en na en de maandelijkse kostenverschuiving, en bewaar de Advisor-kostenexport (Advisor-tabblad Kosten, downloaden als CSV) als nulmeting. Dat voor-en-na-overzicht maakt van een technische wijziging een verdedigbare besparing wanneer finance of een eigenaar vraagt wat er is veranderd.

Maak er een ritme van, geen eenmalige actie

Dimensioneringsafwijking is continu, dus één ronde is niet genoeg. Gebruikspatronen verschuiven en workloads verplaatsen, dus de juiste keuze van gisteren wordt de te grote maat van volgend kwartaal. Zet right-sizing op een maandelijkse of driemaandelijkse review zodat de omgeving het waargenomen gebruik blijft volgen in plaats van een gok op implementatiedag. Het staat naast het breder opruimen van verspilling; voor resources die factureren terwijl ze weinig of geen werk doen, ziet u hoe inactieve Azure-resources ontwerpschuld op de rekening worden.

Waar EtherInsights past

Deze lus met de hand draaien over een handvol machines is behapbaar. Over een groeiende omgeving, of vele klanten voor een managed-serviceprovider, wordt het al snel een taak op zich, en daar verdient EtherInsights zijn plaats. Het brengt te grote en onderbenutte virtual machines aan het licht op basis van gebruiksbewijs, verwoordt elke als een door een eigenaar gedragen actie in plaats van een ruwe metriek, en volgt het voor en na zodat een formaatwijziging rust op bewijs in plaats van een vermoeden.

Die bewijs-eerst-aanpak is de hele bedoeling van onze dienst Azure VM right-sizing, die gebruiksgegevens omzet in formaatwijzigingsacties die uw team kan beoordelen en bezitten, met de cijfers om ze te onderbouwen. Compute is slechts één post op de rekening, dus door right-sizing samen te brengen met licentie-, opslag- en inactieve-resource-werk onder één cloudkostenoptimalisatie-programma blijft de omgeving betalen voor het werk dat deze werkelijk doet, niet voor de vorm die deze eerst kreeg.

Right-sizing is geen eenmalige opschoning of botte kostenbesparing. Het is een gedisciplineerde, door bewijs geleide lus: meten, shortlisten, de limieten controleren, zorgvuldig het formaat wijzigen, en vervolgens verifiëren en vastleggen. Draai het op een ritme en Azure-compute blijft aansluiten op de werkelijke vraag in plaats van op een aanname die allang is verlopen.

Ontdek Azure VM right-sizing om te zien hoe gebruiksbewijs verandert in door een eigenaar gedragen formaatwijzigingsacties met het bewijs om ze te onderbouwen.