Le 5 tattiche comprovate che hanno ridotto i nostri costi Azure del 30%

Nel 2017, ShareGate ha speso 250.000 dollari su Azure. Anche con un MVP Azure nel nostro team che ci aiutava a mantenere i costi più bassi possibile, il nostro conto è comunque aumentato del 45% in meno di 12 mesi. Il principale colpevole, ovviamente, era il cloud sprawl.

Sapevamo che erano possibili risparmi massicci, quindi abbiamo chiesto ai nostri esperti di costruirci una lista di metodi di controllo dei costi del cloud pratici ed efficaci per ridurre la nostra spesa Azure.

Abbiamo raccolto le nostre scoperte in questa guida in modo che anche voi possiate iniziare subito a identificare i potenziali risparmi di Azure negli ambienti della vostra organizzazione.

Consider B-Series virtual machines

While platform-as-a-service (PaaS) offerings have been gaining significant ground over the past few years, virtual machines—be it for legacy reasons or due to specific software requirements—still represent a large portion of cloud usage.

Le macchine virtuali basate sul cloud presentano una sfida in termini di controllo dei costi: di solito richiedono specifiche minime per funzionare e sono spesso inattive con picchi di utilizzo periodici, ma continuano a sostenere il costo completo finché sono accese.

Nel settembre 2017, Microsoft ha annunciato la famiglia B-Series di macchine virtuali, note anche come macchine virtuali burstable. Queste macchine sono specificamente progettate per i carichi di lavoro che devono essere sempre disponibili, ma sono tipicamente inattivi con picchi occasionali di utilizzo. Le macchine virtuali della serie B offrono un significativo potenziale di riduzione dei costi: tra il 15 e il 55% del prezzo di una macchina equivalente della serie D, a seconda del sistema operativo utilizzato.

Raccomandiamo di leggere: Azure cost-saving tips: dos and don’ts from industry insiders, di Leigh Ryan

Così dovrei convertire tutte le mie VM esistenti in B-Series e risparmiare molto?

Attenzione ora! Non tutti i carichi di lavoro possono essere convertiti alla cieca alla serie B. È necessario trovare un equilibrio tra i costi e il consumo di CPU. Alla serie B viene assegnata una quantità base di potenza di CPU. Finché il suo utilizzo è al di sotto della linea di base, la VM accumula crediti, che possono poi essere utilizzati per consumare la CPU che supera la linea di base. Se la macchina virtuale diventa troppo impegnativa dal punto di vista della CPU, tuttavia, verrà ridotta alle prestazioni della linea di base finché non saranno disponibili abbastanza crediti.

Le linee di base e i limiti di credito variano a seconda delle dimensioni di ciascuna VM della serie B. Inoltre, ogni volta che la VM viene spenta, tutti i crediti accumulati vengono persi. Come tali, le VM della serie B sono veramente progettate per carichi di lavoro prevedibili o a basso utilizzo che devono essere sempre disponibili.

Per aiutarvi a determinare se la vostra macchina virtuale può essere convertita in sicurezza in una serie B, è possibile eseguire script personalizzati come lo script Azure-Burst-Check di Dave Hall.

Identificare e agire sulle risorse inattive

Grazie ad Azure, non è mai stato così facile ottenere un nuovo ambiente attivo e funzionante con un attimo di preavviso ogni volta che è il momento di soddisfare un nuovo bisogno della vostra organizzazione. Fast-forward a few years, however, and you’ll start noticing a buildup of resources in your Azure subscription that are likely racking up a hefty bill. It isn’t always easy to tell which workloads are still being used and which ones can safely be decommissioned.

The best solution would be to go back in time and implement a basic cloud asset governance plan. Date un’occhiata al nostro primer sulla creazione di un piano di governance dei costi del cloud per una panoramica degli elementi fondamentali da considerare: visibilità, proprietà e permessi, ciclo di vita e ottimizzazione – o, come ci piace chiamarli, VOLO.

In poche parole, per ogni risorsa creata, vorrete:

• Usare tag e altre strategie per categorizzare come la risorsa sarà utilizzata (dev, test, prod, ecc.)
• Specificare un unico proprietario per la risorsa (tipicamente la persona che ha richiesto la risorsa)
• Determinare una data di scadenza o di controllo per la risorsa (e assicurarsi di seguire il programma ed eliminare prontamente le risorse non necessarie)

Una volta che si hanno queste informazioni, è molto più facile determinare se una data risorsa è ancora necessaria o meno e agire di conseguenza.

Lettura consigliata: How to start and stop your VMs with Azure Automation, by Antoine Jagueneau

Non ho un piano di governance dei costi. E adesso?

Azure vi dà accesso a una serie di statistiche di utilizzo che misurano quanta attività stanno vedendo le vostre risorse. Questi valori possono essere esaminati dal portale Azure, accedendo all’API di Azure e utilizzando codice personalizzato, o attraverso una soluzione di gestione dei costi dedicata. Esaminando questi numeri di utilizzo, è possibile identificare quali risorse non sono più in uso (o significativamente sottoutilizzate) e prendere le misure appropriate. Inoltre, tenete a mente che la governance dei costi del cloud è un processo iterativo, quindi non è mai troppo tardi per iniziare a lavorare su un piano.

Trovare la giusta dimensione delle risorse

Un problema comune quando si creano nuove risorse cloud è capire la giusta dimensione da utilizzare. Azure offre un gran numero di opzioni per soddisfare diverse esigenze (più RAM, più potenza della CPU, unità SSD, GPU, ecc.), ma anche all’interno della stessa famiglia di macchine, la scelta della giusta dimensione è importante.

Leggi: How does Azure VM pricing work?, di Leigh Ryan

Sbagliate e pagherete più del necessario mentre la vostra macchina è inattiva, oppure vi ritroverete con una macchina bloccata al 100% di utilizzo della CPU (o peggio ancora, con lo swapping nella memoria virtuale perché ha finito la RAM fisica). Tutto questo, naturalmente, può avere un impatto significativo sulle prestazioni delle applicazioni.

Non è sempre facile capire in anticipo i requisiti di un dato sistema, quindi si può essere tentati di andare un po’ più in alto di quanto si ha bisogno solo per essere al sicuro. È anche abbastanza comune dimenticarsene e lasciarlo fuori misura, portando a costi inutili mese dopo mese.

Come si può evitare questo? Vedremo alcune strategie in questo articolo.

Il modo più semplice per evitare di sprecare denaro per il consumo di risorse non necessarie, però, è quello di lasciare che uno strumento di ottimizzazione cloud dedicato monitori il vostro tenant e vi notifichi ogni volta che c’è un’opportunità per ridimensionare, ridimensionare o ridurre in altro modo una data risorsa.

Quando ridimensionare

Se credete che questo possa essere il caso del vostro ambiente, niente panico! Ci sono alcuni modi semplici per determinare se dovresti ridimensionare una data VM. Il metodo più semplice è quello di dare un’occhiata ai grafici della percentuale di CPU e della percentuale di memoria per ogni risorsa in Azure Portal.

In genere, le dimensioni delle istanze in Azure raddoppiano con ogni livello: una S1 avrà 1 core di CPU insieme a 1,75 GB di RAM, mentre una S2 avrà 2 core e 3,5 GB di RAM. Lo stesso modello si applica anche alle dimensioni del database e alle DTU.

In tutti i casi, se vedete che per un lungo periodo di tempo entrambe le statistiche di utilizzo sono sotto il 50%, potete tranquillamente ridimensionare la vostra istanza senza preoccuparvi di ostacolare le prestazioni.

Perché non posso vedere l’utilizzo della memoria per la mia VM?

Purtroppo, non avrai i grafici della percentuale di memoria per le macchine virtuali, classiche o gestite, fuori dalla scatola. Per accedere a queste informazioni, dovrai abilitare il monitoraggio a livello di ospite e controllare i contatori di prestazioni corretti. Quello che dovresti controllare in particolare è MemoryCommitted Bytes. Con queste informazioni, dovreste essere in grado di determinare se un servizio può essere ridimensionato in modo sicuro o meno.

Localizzare ed eliminare i dischi inutilizzati

Se state usando Azure da un po’, probabilmente avete creato ed eliminato un buon numero di macchine virtuali. Ma il tuo conto continua a salire e non sei sicuro del perché. Un probabile colpevole sono i dischi di archiviazione; in particolare, i dischi per le macchine virtuali cancellate che sono ancora in sospeso nel tuo account e ti costano denaro mese dopo mese. Questo è ancora più probabile se hai usato macchine virtuali classiche piuttosto che la nuova varietà ARM. La ragione di questo è abbastanza semplice: Azure non cancella sistematicamente i tuoi dischi quando cancelli una macchina virtuale. Questo per proteggervi da perdite accidentali di dati, ma significa anche che se non state attenti, continuerete a pagare per dischi di cui non avete più bisogno.

Potete risolvere questo problema dal portale Azure. The procedure will be a bit different depending on whether you’re dealing with managed disks or classic disks.

Managed disks

For managed disks, go to the Azure portal, search for Disks in the search bar, and select “Disks”.

This will display all your managed disks. If the Owner column is empty, it means that the disk is not currently attached to anything and you can probably delete it.

To delete the disk, select the row, go to Overview and click Delete in the top bar.

Classic disks

For classic disks, go to the Azure portal, click in the Search bar up top and search for Disks. Select “Disks (classic)”.

You’ll see all of your disks and a column indicating which VM each disk is currently attached to. If you see a disk that isn’t attached to a VM, you can probably delete it safely.

Deleting classic disks is a bit of a process, as the underlying file (the VHD), which is stored in a storage account, will still be there until you manually remove it. Here are the steps:

1. Click on the classic disk and take note of its Storage account and Media link information

2. Click Delete and confirm

3. Utilizzare la barra di ricerca di Azure per trovare l’account di archiviazione che avete annotato al punto 1, quindi aprire il pannello Proprietà

4. Fare clic su Blob, quindi selezionare la riga con il contenitore di archiviazione giusto

5. Selezionare la casella con il nome del file corretto, quindi fare clic su Elimina nel menu in alto

VHD dimenticati

Anche se si seguono tutti questi passaggi per identificare i dischi non collegati, potreste ancora perdere dei VHD dimenticati che rimangono abbandonati nello storage classico. Di solito, il portale Azure crea un contenitore “vhds” e li mette lì in un account di storage. Per localizzarli, controlla ogni account di storage classico per un contenitore vhds sotto Blobs. All’interno del contenitore, guarda la colonna Lease state per ogni file. Se c’è scritto Available, significa che nessuna VM sta attualmente utilizzando quel VHD, e potrebbe essere sicuro per te eliminarlo (ma dovresti sempre controllare il contenuto per esserne sicuro!).

Utilizzare i database Elastic Pool

È probabile che tu abbia iniziato il tuo progetto di migrazione al cloud spostando i carichi di lavoro che erano precedentemente ospitati on-prem o in un data center privato su Azure. Un gran numero di questi carichi di lavoro probabilmente utilizzava database SQL Server, che tendevano ad essere la spina dorsale della maggior parte dei progetti software prima dell’ascesa del cloud e del movimento NoSQL. Probabilmente avete anche notato che i prezzi per i database SQL in Azure possono diventare piuttosto alti, abbastanza rapidamente.

Mentre prima avreste potuto usare un singolo server di database per ospitare decine, se non centinaia, di database per i vostri vari progetti o clienti, il costo della suddivisione di questi in database SQL Azure separati potrebbe essere ordini di grandezza più alto di quello che vi aspettavate. Questo è dovuto a come funzionano i database in Azure. On-prem, eri abituato a più database che condividono le risorse limitate di un singolo server. Con Azure SQL, ogni database ha una quantità riservata di risorse, che vi verrà comunque addebitata anche se il database è inattivo. Il modello è ottimo se avete più database con un utilizzo costante e prevedibile. Se avete un gran numero di database con un modello di utilizzo irregolare, tuttavia, potreste trovare il cartellino del prezzo significativamente meno attraente. Questo vi lascia con due opzioni:

• Utilizzare un tier di database più grande e più costoso per gestire i picchi di utilizzo del database
• Utilizzare un tier inferiore per risparmiare sui costi, a scapito delle prestazioni nei momenti di picco

Per condividere le risorse tra i database, i primi adottatori di Azure sono stati costretti a creare e mantenere le proprie macchine virtuali con SQL Server installato ed essenzialmente replicare le condizioni in cui venivano eseguite mentre erano on-prem o in un data center privato. Mentre questo metodo funzionava bene, non permetteva l’accesso a tutte le grandi caratteristiche che Azure SQL ha da offrire, come:

• Alta disponibilità incorporata (nessuna necessità di configurare la replica)
• Geo-replicazione attiva
• Ripristino point-in-time

Queste caratteristiche non sono banali da implementare da soli e possono essere una sfida da mantenere.

Meglio: Istanze gestite

Azure offre un nuovo livello di servizi di database SQL chiamato Istanze gestite, che sono essenzialmente macchine virtuali gestite che ospitano un SQL Server. Le istanze gestite non vi forniranno tutte le caratteristiche che sono incorporate nei servizi Azure SQL a singolo database, ma non avrete nemmeno bisogno di gestire il sistema operativo o l’installazione di SQL Server. Fondamentalmente, si sta ottenendo una macchina virtuale la cui configurazione e manutenzione è in gran parte gestita per voi.

Meglio: SQL elastic pools

Ma c’è un’altra opzione in Azure per affrontare questo scenario comune: I pool elastici SQL. Invece di riservare una certa quantità di risorse per un singolo database, i pool elastici SQL permettono di riservare un certo numero di risorse e condividerle tra centinaia di database. Questo modello ha tutti i vantaggi di Azure SQL e consente di gestire correttamente i modelli di utilizzo spikey su più database. I pool elastici si sono dimostrati incredibilmente popolari e sono un’opzione ideale per le applicazioni multi-tenanted.

Tuttavia, si dovrebbe essere cauti nell’uso dei pool elastici. Se avete uno o più database con un utilizzo significativamente più elevato rispetto agli altri database in un pool, potreste essere costretti ad acquistare un tier di pool elastico più costoso per gestire i picchi di utilizzo. In alcuni casi, può essere effettivamente più conveniente dividere questi database ad alto utilizzo in offerte di database singoli (togliendoli dal pool) e pagare per un livello più piccolo di pool elastico per i restanti database a basso utilizzo. Una buona regola empirica è quella di guardare l’utilizzo delle DTU dei database: se un singolo database sta utilizzando il 40% o più delle DTU del pool elastico in un dato momento, si può essere in grado di risparmiare sui costi separandolo dal pool, quindi scalando il suddetto pool a un livello meno costoso.

Come sempre, il portale Azure è il vostro punto di riferimento per identificare i modelli di utilizzo del database.

Time to take action and start saving on Azure

By acting on the five areas outlined in this guide, our team managed to shrink our Azure spend by 30%.

Can you do better?