Ridimensionamento delle VM Azure: una guida pratica

Il ridimensionamento delle VM Azure è la pratica di far corrispondere la dimensione di una macchina virtuale, la sua SKU, alla CPU, alla memoria e alla rete che utilizza effettivamente, anziché alla dimensione con cui è stata distribuita. Nella maggior parte degli ambienti alcune macchine sono state dimensionate per un picco di lancio o riprese da hardware on-premises, e da allora girano al di sotto di quel tetto. Per ridimensionare correttamente le macchine virtuali Azure si raccolgono evidenze di utilizzo su un periodo rappresentativo, di solito 30 giorni, si individuano le macchine il cui utilizzo prolungato e di picco resta ben al di sotto della capacità assegnata, poi le si sposta su una SKU più piccola con un margine ragionevole. Fatto con evidenze anziché con un'intuizione, è uno dei modi più ripetibili per ridurre il costo di calcolo di Azure mentre il carico di lavoro continua a funzionare.

Questa guida percorre l'intero ciclo: perché le macchine finiscono sovradimensionate, come raccogliere le evidenze, leggere le raccomandazioni di Advisor, scegliere una dimensione di destinazione, ridimensionare una VM Azure in sicurezza e registrare il risultato. Le cifre sono indicative, perché dipendono dal vostro ambiente, ma il metodo si applica ovunque.

Perché le macchine virtuali finiscono sovradimensionate

Il sovradimensionamento raramente nasce come errore. Nasce come cautela che non viene mai rivista.

• Dimensionata per il picco di lancio. Una macchina viene assegnata per il giorno più intenso che potrebbe mai vedere, un passaggio di migrazione, un lancio, un picco stagionale, poi il giorno intenso passa e la dimensione resta.
• Abitudini di lift-and-shift. Quando un carico di lavoro si sposta da un server fisico o on-premises, i team spesso replicano uno a uno il vecchio conteggio di core e memoria, anche se quella macchina era stata a sua volta acquistata con anni di margine incorporato.
• Il margine come assicurazione. Una dimensione più grande sembra più sicura di una scelta che si rivela un po' stretta, quindi l'opzione apparentemente più sicura vince per impostazione predefinita.
• Nessuno è responsabile della revisione. La dimensione viene impostata una volta al momento della distribuzione e mai confrontata con ciò che la macchina fa, quindi la fattura riflette silenziosamente una decisione che non regge più.

Nessuna di queste ragioni è irragionevole sul momento. Il problema è che il momento finisce, ma la dimensione no.

Raccogliere le evidenze con Azure Monitor

Ridimensionare senza dati è tirare a indovinare con passaggi in più, quindi partite dall'utilizzo. Azure Monitor raccoglie automaticamente le metriche di piattaforma per ogni macchina virtuale, senza agente né configurazione richiesti.

Nel portale, aprite Macchine virtuali, selezionate la macchina, poi sotto Monitoraggio scegliete Metriche per i grafici grezzi oppure Insights e poi la scheda Prestazioni per una vista curata. La metrica più importante per il dimensionamento del calcolo è Percentage CPU, una metrica di piattaforma a livello di host espressa in percentuale, con granularità di un minuto e aggregazione media per impostazione predefinita. Non giudicate solo sulla media: tracciate insieme la linea prolungata e il 95° percentile, perché una macchina può sembrare tranquilla in media pur avendo bisogno di margine per brevi picchi regolari. Il grafico di utilizzo della CPU della vista Prestazioni mostra per impostazione predefinita la media e il 95° percentile superiore.

La memoria richiede un po' di attenzione. Le metriche di piattaforma dell'host espongono Available Memory Bytes, ma i contatori granulari a livello di guest che tracciano quanta memoria il sistema operativo sta effettivamente impegnando vengono raccolti tramite l'agente di Azure Monitor all'interno della macchina, non per impostazione predefinita. Se prevedete di dimensionare sulla memoria oltre che sulla CPU, mettete prima in atto l'agente, poi leggete la memoria disponibile sulla stessa finestra. Il grafico di memoria disponibile della vista Prestazioni mostra per impostazione predefinita la media più il 5° e il 10° percentile superiore, evidenziando i momenti critici anziché quelli comodi.

Osservate almeno 30 giorni così che un fine settimana tranquillo o una settimana intensa non distorcano il quadro. Ciò che volete prima di agire è una macchina il cui 95° percentile di CPU e la memoria disponibile più bassa si collochino entrambi comodamente al di sotto della dimensione assegnata.

Il ciclo di ridimensionamento si basa sulle evidenze: misurare, preselezionare, controllare i limiti, ridimensionare, poi verificare e registrare.

Leggere le raccomandazioni di Azure Advisor

Una volta che avete un'idea dell'utilizzo, lasciate che Azure Advisor faccia il grosso del riconoscimento di schemi. Sotto Advisor e poi la scheda Costi, cercate Ridimensiona o arresta le macchine virtuali sottoutilizzate. Advisor usa modelli di apprendimento automatico sul vostro utilizzo per suggerire un ridimensionamento o un arresto per ogni candidato, e mostra la dimensione attuale e quella di destinazione per un ridimensionamento.

È utile sapere a grandi linee come vengono ricavate, così da potervi fidare senza prenderle come oro colato:

• Le raccomandazioni di arresto segnalano le macchine di fatto inutilizzate nella finestra di analisi. I criteri usano l'utilizzo della CPU e della rete in uscita, non della memoria, e un arresto viene suggerito quando, ad esempio, il 95° percentile della CPU massima sommata sui core resta sotto il 3 per cento e la rete in uscita sotto il 2 per cento.
• Le raccomandazioni di ridimensionamento possono attraversare famiglia e versione di SKU, e tengono conto di vincoli come il fatto che la destinazione supporti la rete accelerata e l'archiviazione premium, che sia disponibile nella regione, e che la macchina si trovi in un set di disponibilità.
• Il periodo di analisi è di sette giorni per impostazione predefinita ma configurabile a 7, 14, 21, 30, 60 o 90 giorni, e una modifica può richiedere fino a 48 ore per propagarsi. Potete anche filtrare quali macchine appaiono impostando una soglia media di CPU sotto Configurazione e poi la scheda Ridimensionamento VM/VMSS (diritti di proprietario della sottoscrizione, fino a 24 ore per applicarsi), il che cambia ciò che vedete, non il modo in cui le raccomandazioni vengono generate.

Due avvertenze oneste. Le cifre di risparmio di Advisor usano le tariffe al dettaglio e ignorano qualsiasi sconto di prenotazione o piano di risparmio che detenete, quindi il dato in evidenza può risultare più alto di quanto realizzerete. E il risparmio annuale potenziale totale mostrato riguarda l'arresto o la rimozione di una macchina; il ridimensionamento di solito fa risparmiare denaro reale, ma non quell'intero importo. Trattate le raccomandazioni come una preselezione fortemente comprovata, non come una promessa.

Scegliere la SKU di destinazione

Il suggerimento di Advisor è un punto di partenza, non l'unica opzione. Quando scegliete una dimensione di destinazione, valutate insieme alcuni elementi.

• Adeguatezza della famiglia. La serie D generica si adatta ai carichi bilanciati, la serie E ottimizzata per la memoria si adatta a database e cache, la serie F ottimizzata per il calcolo si adatta al lavoro vincolato dalla CPU, e la serie B burstable si adatta ai carichi a bassa media con picchi. Scendere all'interno della famiglia giusta è più pulito che saltare da una famiglia all'altra.
• Dimensioni a core vincolati. Dove la licenza per core è il vero fattore di costo, le dimensioni a vCPU vincolati mantengono la memoria, l'archiviazione e la banda di una SKU più grande riducendo al contempo il numero di core fatturabili.
• Disponibilità regionale. Una dimensione offerta in una regione può non esistere in un'altra, quindi confermate che la destinazione sia disponibile dove risiede la macchina.
• Limiti di disco e di rete. Il numero massimo di dischi dati, gli IOPS, il throughput e il numero di interfacce di rete sono tutti legati alla dimensione. Scendere troppo può strozzare una macchina che non era mai stata vincolata dalla CPU, quindi controllate i limiti della destinazione a fronte di ciò che il carico di lavoro collega e sollecita.

Lasciate margine. L'obiettivo è una dimensione che copra comodamente il carico al 95° percentile, non una che scaldi già dal primo pomeriggio intenso.

Eseguire il ridimensionamento, e aspettarsi un riavvio

Il ridimensionamento è rapido, ma perturbativo, quindi pianificatelo come tale. Cambiare la dimensione di una macchina virtuale in esecuzione ne provoca il riavvio, meglio farlo nelle ore di minor traffico. Se la dimensione di destinazione non è disponibile sul cluster hardware che ospita attualmente la macchina, dovete prima deallocarla, il che arresta la macchina, rilascia qualsiasi indirizzo IP pubblico dinamico e può cancellare il disco temporaneo; i dischi del sistema operativo e dei dati non ne risentono.

Ci sono tre modi comuni per farlo:

• Portale. Aprite la macchina, andate su Disponibilità + scalabilità e poi Dimensioni, scegliete dall'elenco disponibile e selezionate Ridimensiona.
• Azure CLI. Elencate le opzioni del cluster con az vm list-vm-resize-options, poi eseguite az vm resize --size <NewSize>. Se la dimensione non è elencata, fate prima az vm deallocate, ridimensionate, poi az vm start.
• PowerShell. Elencate le opzioni con Get-AzVMSize, impostate $vm.HardwareProfile.VmSize, poi applicate con Update-AzVM.

Se la macchina si trova in un set di disponibilità e la nuova dimensione non è sul cluster attuale, potreste dover prima deallocare ogni macchina del set. Pianificatelo e avvisate il responsabile del carico di lavoro prima, non dopo.

Verificare la modifica e registrare il risparmio

Un ridimensionamento non è finito quando la macchina si riavvia. Ricontrollate le stesse metriche di Azure Monitor di utilizzo della CPU e memoria disponibile nei giorni successivi per confermare che la dimensione ridotta regga sotto carico reale con il margine intatto. Se scalda, tornate su; questo fa parte del ciclo, non è un fallimento.

Poi registrate le evidenze. Annotate la dimensione prima e dopo e la variazione del costo mensile, e conservate l'esportazione dei costi di Advisor (scheda Costi di Advisor, download in formato CSV) come linea di base. Quel registro del prima e dopo trasforma una modifica tecnica in un risparmio difendibile quando la finanza o un responsabile chiede cosa è cambiato.

Renderlo una cadenza, non un evento isolato

La deriva del dimensionamento è continua, quindi un singolo passaggio non basta. Gli schemi di utilizzo cambiano e i carichi di lavoro si spostano, quindi la scelta giusta di ieri diventa il sovradimensionamento del prossimo trimestre. Mettete il ridimensionamento in una revisione mensile o trimestrale così che l'ambiente continui a seguire l'utilizzo osservato anziché una supposizione fatta il giorno della distribuzione. Va di pari passo con l'eliminazione dello spreco più in generale; per le risorse che fatturano mentre svolgono poco o nessun lavoro, guardate come le risorse Azure inattive diventano debito di progettazione sulla fattura.

Dove si inserisce EtherInsights

Eseguire questo ciclo a mano su una manciata di macchine è gestibile. Su un ambiente in crescita, o su molti clienti per un fornitore di servizi gestiti, diventa presto un lavoro a sé stante, ed è lì che EtherInsights si guadagna il suo posto. Fa emergere le macchine virtuali sovradimensionate e sottoutilizzate a partire dalle evidenze di utilizzo, inquadra ciascuna come un'azione supportata da un responsabile anziché come una metrica grezza, e traccia il prima e dopo affinché un ridimensionamento poggi su prove anziché su un'intuizione.

Quell'approccio che mette al primo posto le evidenze è tutto il senso del nostro servizio di ridimensionamento delle VM Azure, che trasforma i dati di utilizzo in azioni di ridimensionamento che il vostro team può valutare e assumere in carico, con i numeri a sostegno. Il calcolo è solo una voce sulla fattura, quindi riunire il ridimensionamento con il lavoro su licenze, archiviazione e risorse inattive all'interno di un unico programma di ottimizzazione dei costi cloud mantiene l'ambiente a pagare per il lavoro che svolge davvero, non per la forma che gli è stata data all'inizio.

Il ridimensionamento non è una pulizia una tantum né un taglio brutale dei costi. È un ciclo disciplinato e guidato dalle evidenze: misurare, preselezionare, controllare i limiti, ridimensionare con cura, poi verificare e registrare. Lavoratelo a cadenza e il calcolo di Azure continua a corrispondere alla domanda reale anziché a una supposizione scaduta da tempo.

Esplora il ridimensionamento delle VM Azure per scoprire come le evidenze di utilizzo diventano azioni di ridimensionamento supportate da un responsabile, con le prove a sostegno.