Rätt-dimensionera virtuella Azure-maskiner: en praktisk guide

Rätt-dimensionering av virtuella Azure-maskiner är praktiken att matcha en virtuell maskins storlek, dess SKU, mot den CPU, det minne och det nätverk den faktiskt använder, i stället för den storlek den råkade driftsättas med. I de flesta miljöer dimensionerades vissa maskiner för en lanseringstopp eller lyftes över från lokal utrustning, och har kört under det taket sedan dess. För att rätt-dimensionera virtuella Azure-maskiner ordentligt samlar du in utnyttjandeunderlag under en representativ period, vanligtvis 30 dagar, hittar de maskiner vars ihållande och toppanvändning ligger väl under deras provisionerade kapacitet, och flyttar dem sedan till en mindre SKU med rimlig marginal. Gjort med underlag snarare än en gissning är det ett av de mest repeterbara sätten att minska Azures beräkningskostnad medan arbetsbelastningen fortsätter köra.

Den här guiden går igenom hela loopen: varför maskiner blir överdimensionerade, hur du samlar in underlaget, läser Advisor-rekommendationerna, väljer en målstorlek, ändrar storlek på en Azure-VM säkert, och registrerar resultatet. Siffrorna är riktgivande, eftersom de beror på din miljö, men metoden gäller överallt.

Varför virtuella maskiner blir överdimensionerade

Överdimensionering börjar sällan som ett misstag. Den börjar som försiktighet som aldrig blir omprövad.

• Dimensionerad för lanseringstoppen. En maskin provisioneras för den mest belastade dag den någonsin kan möta, en migreringsövergång, en lansering, en säsongstopp, sedan passerar den belastade dagen och storleken stannar.
• Lift-and-shift-vanor. När en arbetsbelastning flyttas från en fysisk eller lokal server matchar team ofta de gamla kärn- och minnesantalen ett-till-ett, trots att den maskinen själv köptes med år av marginal inbakad.
• Marginal som försäkring. En större storlek känns säkrare än ett beslut som visar sig aningen snävt, så det säkrare alternativet vinner som standard.
• Ingen äger granskningen. Storleken sätts en gång vid driftsättning och kontrolleras aldrig mot vad maskinen gör, så räkningen återspeglar i tysthet ett beslut som inte längre håller.

Inget av detta är orimligt i stunden. Problemet är att stunden tar slut men storleken gör det inte.

Samla in underlaget med Azure Monitor

Rätt-dimensionering utan data är gissning med extra steg, så börja med utnyttjandet. Azure Monitor samlar in plattformsmätvärden för varje virtuell maskin automatiskt, utan att någon agent eller konfiguration krävs.

I portalen, öppna Virtuella maskiner, välj maskinen, och välj sedan under Övervakning antingen Mätvärden för råa diagram eller Insikter och sedan fliken Prestanda för en kurerad vy. Det mätvärde som betyder mest för beräkningsdimensionering är Percentage CPU, ett plattformsmätvärde på värdnivå som rapporteras som en procentandel med en kornstorlek på en minut och ett genomsnitt som standardaggregering. Bedöm inte på genomsnittet ensamt: diagrammera den ihållande linjen och 95:e percentilen tillsammans, eftersom en maskin kan se lugn ut i genomsnitt men ändå behöva marginal för korta, regelbundna toppar. Prestandavyns diagram för CPU-användning visar som standard genomsnittet och den översta 95:e percentilen.

Minne kräver lite omsorg. Plattformsmätvärdena på värdnivå exponerar Available Memory Bytes, men de granulära räknarna på gästnivå som spårar hur mycket minne operativsystemet faktiskt allokerar samlas in via Azure Monitor-agenten inuti maskinen, inte som standard. Om du planerar att dimensionera på minne såväl som CPU, sätt agenten på plats först, och läs sedan tillgängligt minne över samma fönster. Prestandavyns diagram för tillgängligt minne visar som standard genomsnittet plus den översta 5:e och 10:e percentilen, och visar de snäva stunderna snarare än de bekväma.

Titta över minst 30 dagar så att en lugn helg eller en belastad vecka inte förvränger bilden. Det du vill ha innan du agerar är en maskin vars CPU på 95:e percentilen och lägsta tillgängliga minne båda ligger bekvämt under dess provisionerade storlek.

Rätt-dimensioneringsloopen körs på underlag: mät, kortlista, kontrollera gränser, ändra storlek, och verifiera och registrera sedan.

Läs Azure Advisor-rekommendationerna

När du väl har en känsla för utnyttjandet, låt Azure Advisor göra det tunga mönstermatchandet. Under Advisor och sedan fliken Kostnad, leta efter Rätt-dimensionera eller stäng av underutnyttjade virtuella maskiner. Advisor använder maskininlärningsmodeller över din användning för att föreslå en storleksändring eller en avstängning för varje kandidat, och visar aktuell och målstorlek för en storleksändring.

Det hjälper att på en övergripande nivå veta hur dessa härleds, så att du kan lita på dem utan att behandla dem som sanning:

• Avstängningsrekommendationer flaggar maskiner som i praktiken är oanvända över tillbakablicksfönstret. Kriterierna använder CPU- och utgående nätverksutnyttjande, inte minne, och en avstängning föreslås när till exempel 95:e percentilen av maximal CPU summerad över kärnorna håller sig under 3 procent och utgående nätverk under 2 procent.
• Storleksändringsrekommendationer kan korsa SKU-familj och -version, och väger in begränsningar som huruvida målet stöder accelererat nätverk och premiumlagring, om det är tillgängligt i regionen, och om maskinen ligger i en tillgänglighetsuppsättning.
• Tillbakablicksperioden är som standard sju dagar men kan konfigureras till 7, 14, 21, 30, 60 eller 90 dagar, och en ändring kan ta upp till 48 timmar att slå igenom. Du kan också filtrera vilka maskiner som visas genom att ställa in en tröskel för genomsnittlig CPU under Konfiguration och sedan fliken VM/VMSS right sizing (rättigheter som prenumerationsägare, upp till 24 timmar att tillämpa), vilket ändrar vad du ser, inte hur rekommendationer genereras.

Två ärliga reservationer. Advisors besparingssiffror använder listpriser och bortser från eventuella reservations- eller sparplansrabatter du har, så rubriksiffran kan läsas högre än vad du faktiskt kommer att realisera. Och den fulla potentiella årsbesparing som visas gäller för att stänga av en maskin eller ta bort den; en storleksändring sparar vanligtvis riktiga pengar, men inte det fulla beloppet. Behandla rekommendationerna som en starkt underbyggd kortlista, inte ett löfte.

Välj mål-SKU:n

Advisor-förslaget är en utgångspunkt, inte det enda alternativet. När du väljer en målstorlek, väg samman några saker.

• Familjematchning. Den allmänna D-serien passar balanserade arbetsbelastningar, den minnesoptimerade E-serien passar databaser och cacheminnen, den beräkningsoptimerade F-serien passar CPU-bunden arbetsbelastning, och den burstbara B-serien passar arbetsbelastningar med lågt genomsnitt och toppar. Att gå ner inom rätt familj är renare än att hoppa mellan familjer.
• Storlekar med begränsade kärnor. Där licensiering per kärna är den verkliga kostnadsdrivaren behåller storlekar med begränsad vCPU en större SKU:s minne, lagring och bandbredd samtidigt som de minskar det fakturerbara antalet kärnor.
• Regiontillgänglighet. En storlek som erbjuds i en region kanske inte finns i en annan, så bekräfta att målet är tillgängligt där maskinen finns.
• Disk- och nätverksgränser. Maximalt antal datadiskar, IOPS, genomströmning och nätverksgränssnitt är alla knutna till storleken. Att sänka för långt kan strypa en maskin som aldrig var CPU-bunden, så kontrollera målets gränser mot vad arbetsbelastningen ansluter och driver.

Lämna marginal. Målet är en storlek som bekvämt täcker belastningen på 95:e percentilen, inte en som går varm den första belastade eftermiddagen.

Utför storleksändringen, och förvänta dig en omstart

En storleksändring går snabbt, men är störande, så planera den därefter. Att ändra storlek på en körande virtuell maskin får den att starta om, bäst gjort under lågtrafik. Om målstorleken inte är tillgänglig på det hårdvarukluster som för närvarande är värd för maskinen, måste du först avallokera den, vilket stoppar maskinen, frigör eventuell dynamisk publik IP-adress och kan rensa den temporära disken; OS- och datadiskarna påverkas inte.

Det finns tre vanliga sätt att göra det:

• Portal. Öppna maskinen, gå till Tillgänglighet + skala och sedan Storlek, välj från den tillgängliga listan och välj Ändra storlek.
• Azure CLI. Lista klusteralternativ med az vm list-vm-resize-options, och kör sedan az vm resize --size <NewSize>. Om storleken inte finns med i listan, az vm deallocate först, ändra storlek, och sedan az vm start.
• PowerShell. Lista alternativ med Get-AzVMSize, sätt $vm.HardwareProfile.VmSize, och tillämpa sedan med Update-AzVM.

Om maskinen ligger i en tillgänglighetsuppsättning och den nya storleken inte finns på det aktuella klustret kan du behöva avallokera varje maskin i uppsättningen först. Schemalägg det och berätta för arbetsbelastningens ägare i förväg, inte efteråt.

Verifiera ändringen och registrera besparingen

En storleksändring är inte klar när maskinen startar om. Kontrollera samma mätvärden i Azure Monitor för CPU-användning och tillgängligt minne igen under de följande dagarna för att bekräfta att den mindre storleken håller under verklig belastning med marginalen intakt. Om den går varm, kliv tillbaka upp; det är en del av loopen, inte ett misslyckande.

Registrera sedan underlaget. Notera storleken före och efter och den månatliga kostnadsrörelsen, och behåll Advisors kostnadsexport (Advisor-fliken Kostnad, ladda ner som CSV) som en utgångspunkt. Det där före-och-efter-underlaget förvandlar en teknisk ändring till en försvarbar besparing när ekonomiavdelningen eller en ägare frågar vad som ändrades.

Gör det till en kadens, inte en engångsåtgärd

Storleksdrift är kontinuerlig, så en enda genomgång räcker inte. Användningsmönster förskjuts och arbetsbelastningar flyttar, så gårdagens rätta beslut blir nästa kvartals överdimensionering. Sätt rätt-dimensionering på en månatlig eller kvartalsvis granskning så att miljön fortsätter att spåra observerat utnyttjande snarare än en gissning från driftsättningsdagen. Det hör ihop med att rensa slöseri mer brett; för resurser som fakturerar medan de gör lite eller inget arbete, se hur vilande Azure-resurser blir designskuld på räkningen.

Var EtherInsights passar in

Att köra den här loopen för hand över en handfull maskiner är hanterbart. Över en växande miljö, eller många kunder för en leverantör av hanterade tjänster, blir det snabbt ett jobb i sig, och det är där EtherInsights förtjänar sin plats. Det lyfter fram överdimensionerade och underutnyttjade virtuella maskiner från utnyttjandeunderlag, ramar in var och en som en ägarförankrad åtgärd snarare än ett rått mätvärde, och följer före och efter så att en storleksändring vilar på bevis snarare än en gissning.

Den bevisförst-ansatsen är hela poängen med vår tjänst rätt-dimensionering av virtuella Azure-maskiner, som förvandlar utnyttjandedata till storleksändringsåtgärder som ditt team kan bedöma och äga, med siffrorna som stöder dem. Beräkning är bara en rad på räkningen, så att föra samman rätt-dimensionering med licens-, lagrings- och vilande-resurs-arbete under ett enda program för kostnadsoptimering i molnet håller miljön betalande för det arbete den faktiskt utför, inte den form den först fick.

Rätt-dimensionering är inte en engångsupprensning eller en trubbig kostnadsnedskärning. Det är en disciplinerad, bevisledd loop: mät, kortlista, kontrollera gränserna, ändra storlek med omsorg, och verifiera och registrera sedan. Arbeta den på en kadens så fortsätter Azures beräkning att matcha verklig efterfrågan i stället för ett antagande som löpte ut för länge sedan.

Utforska rätt-dimensionering av virtuella Azure-maskiner för att se hur utnyttjandeunderlag blir ägarförankrade storleksändringsåtgärder med beviset som stöder dem.