Cele 5 tactici dovedite care ne-au redus costurile Azure cu 30%

În 2017, ShareGate a cheltuit 250.000 de dolari pe Azure. Chiar și cu un MVP Azure în echipa noastră, care ne-a ajutat să menținem costurile la un nivel cât mai scăzut, factura noastră a crescut cu 45% în mai puțin de 12 luni. Principalul vinovat, bineînțeles, a fost sprawl-ul cloud.

Știam că sunt posibile economii masive, așa că le-am cerut experților noștri să ne construiască o listă de metode practice și eficiente de control al costurilor cloud pentru a ne reduce cheltuielile Azure.

Am compilat concluziile noastre în acest ghid, astfel încât și dumneavoastră să puteți începe imediat să identificați potențialele economii Azure în mediile organizației dumneavoastră.

.

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.

Mașinile virtuale bazate pe cloud reprezintă o provocare în ceea ce privește controlul costurilor: de obicei, acestea necesită specificații minime pentru a funcționa și sunt deseori inactive, cu vârfuri periodice de utilizare, dar continuă să suporte costul integral atâta timp cât sunt pornite.

În septembrie 2017, Microsoft a anunțat familia de mașini virtuale B-Series, cunoscute și sub numele de mașini virtuale bursabile. Aceste mașini sunt concepute special pentru sarcinile de lucru care trebuie să fie întotdeauna disponibile, dar care sunt de obicei inactive, cu vârfuri ocazionale de utilizare. Mașinile virtuale din seria B-Series oferă un potențial semnificativ de reducere a costurilor: între 15 și 55% din prețul unei mașini echivalente din seria D-Series, în funcție de sistemul de operare pe care îl utilizați.

Lectură recomandată: Azure cost-saving tips: do and don’ts from industry insider, de Leigh Ryan

Așa că ar trebui să-mi convertesc toate VM-urile existente în B-Series și să economisesc mult?

Atenție acum! Nu toate volumele de lucru pot fi convertite orbește la B-Series. Trebuie să găsiți un echilibru între costuri și consumul de CPU. Pentru B-Series se alocă o cantitate de bază de putere CPU. Atâta timp cât utilizarea sa este sub linia de bază, VM-ul acumulează credite, care pot fi apoi folosite pentru a consuma CPU care depășește linia de bază. Cu toate acestea, dacă mașina dvs. virtuală devine prea consumatoare de CPU, aceasta va fi limitată la performanța de bază până când vor fi disponibile suficiente credite.

Limitele de bază și limitele de credite variază în funcție de dimensiunea fiecărei mașini virtuale B-Series. În plus, ori de câte ori VM-ul este oprit, toate creditele acumulate se pierd. Ca atare, mașinile virtuale B-Series sunt concepute cu adevărat pentru sarcini de lucru cu utilizare redusă sau previzibile, care trebuie să fie disponibile în permanență.

Pentru a vă ajuta să determinați dacă mașina dvs. virtuală poate fi convertită în siguranță într-o B-Series, puteți rula scripturi personalizate, cum ar fi scriptul Azure-Burst-Check al lui Dave Hall.

Identificați și acționați asupra resurselor inactive

Grație Azure, nu a fost niciodată mai ușor să porniți și să puneți în funcțiune un nou mediu într-o clipă, ori de câte ori este timpul să satisfaceți o nouă nevoie a organizației dumneavoastră. 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. Consultați îndrumarul nostru privind crearea unui plan de guvernanță a costurilor în cloud pentru o prezentare generală a elementelor de bază care trebuie luate în considerare: vizibilitate, proprietate și permisiuni, ciclu de viață și optimizare – sau, așa cum ne place să le numim, VOLO.

Pe scurt, pentru fiecare resursă pe care o creați, veți dori să:

• Folosiți etichete și alte strategii pentru a clasifica modul în care activul va fi utilizat (dev, test, prod, etc.)
• Specificați un singur proprietar pentru resursă (de obicei persoana care a solicitat resursa)
• Determinați o dată de expirare sau de verificare pentru resursă (și asigurați-vă că respectați calendarul și eliminați prompt resursele inutile)

După ce aveți aceste informații, este mult mai ușor să determinați dacă o anumită resursă mai este sau nu necesară și să acționați în consecință.

Lectură recomandată: How to start and stop your VMs with Azure Automation, de Antoine Jagueneau

Nu am un plan de guvernanță a costurilor. Ce urmează?

Azure vă oferă acces la un set de statistici de utilizare care măsoară cât de multă activitate văd resursele dumneavoastră. Aceste valori pot fi examinate din Azure Portal, prin accesarea Azure API și utilizarea de cod personalizat sau printr-o soluție dedicată de gestionare a costurilor. Examinând aceste cifre de utilizare, puteți identifica ce resurse nu mai sunt utilizate (sau sunt semnificativ subutilizate) și puteți lua măsurile corespunzătoare. De asemenea, rețineți că guvernanța costurilor cloud este un proces iterativ, așa că nu este niciodată prea târziu pentru a începe să lucrați la un plan.

Găsește dimensiunea potrivită a resurselor

O problemă frecventă atunci când creați noi resurse cloud este să vă dați seama care este dimensiunea potrivită de utilizat. Azure oferă un număr mare de opțiuni pentru a se adapta diferitelor cerințe (mai multă memorie RAM, mai multă putere de procesare, unități SSD, GPU etc.), dar chiar și în cadrul aceleiași familii de mașini, alegerea dimensiunii potrivite contează.

Lectură recomandată: How does Azure VM pricing work?”, de Leigh Ryan

Să greșești și fie vei plăti mai mult decât ai nevoie în timp ce mașina ta stă în inactivitate, fie te vei trezi cu o mașină care este blocată la o utilizare de 100% a procesorului (sau chiar mai rău, care face swap în memoria virtuală pentru că a rămas fără memorie RAM fizică). Toate acestea, bineînțeles, pot avea un impact semnificativ asupra performanței aplicațiilor.

Nu este întotdeauna ușor să vă dați seama din timp de cerințele unui anumit sistem, așa că poate fi tentant să mergeți un pic mai sus decât aveți nevoie doar pentru a fi în siguranță. De asemenea, este destul de frecvent să uităm apoi de acest lucru și să îl lăsăm supradimensionat, ceea ce duce la costuri inutile lună de lună.

Cum puteți evita acest lucru? Vom analiza câteva strategii în acest articol.

Cel mai simplu mod de a evita risipa de bani din cauza consumului inutil de resurse, totuși, este să lăsați un instrument dedicat de optimizare a cloud-ului să vă monitorizeze chiriașul și să vă notifice ori de câte ori există o oportunitate de a redimensiona, de a micșora sau de a reduce în alt mod o anumită resursă.

Când să reduceți dimensiunea

Dacă credeți că acesta ar putea fi cazul mediului dumneavoastră, nu intrați în panică! Există câteva modalități simple de a determina dacă ar trebui să reduceți dimensiunea unui anumit VM. Cea mai simplă metodă este să aruncați o privire la graficele CPU Percentage (procentaj CPU) și Memory Percentage (procentaj memorie) pentru fiecare resursă din Azure Portal.

În mod obișnuit, dimensiunile instanțelor în Azure se dublează cu fiecare nivel: un S1 va avea 1 nucleu CPU împreună cu 1,75 GB de RAM, în timp ce un S2 va avea 2 nuclee și 3,5 GB de RAM. Același model se aplică, de asemenea, dimensiunilor bazelor de date și DTU-urilor.

În toate cazurile, dacă observați, pe o perioadă lungă de timp, că ambele statistici de utilizare sunt sub 50%, puteți reduce cu încredere dimensiunea instanței dvs. fără să vă faceți griji cu privire la împiedicarea performanței.

De ce nu pot vedea gradul de utilizare a memoriei pentru mașina mea virtuală?

Din păcate, nu veți primi din fabrică graficele Memory Percentage pentru mașinile virtuale, clasice sau administrate. Pentru a accesa aceste informații, va trebui să activați monitorizarea la nivel de oaspete și să bifați Contoarele de performanță corecte. Cel pe care trebuie să-l verificați în mod special este MemoryCommitted Bytes. Cu aceste informații, ar trebui să puteți determina dacă un serviciu poate fi redimensionat în siguranță sau nu.

Localizați și ștergeți discurile nefolosite

Dacă utilizați Azure de ceva timp, probabil că ați creat – și ați șters – un număr destul de mare de mașini virtuale. Dar factura dvs. continuă să crească și nu sunteți foarte sigur de ce. Un vinovat probabil sunt discurile de stocare; mai exact, discurile pentru mașinile virtuale șterse care încă mai zăbovesc în contul dvs. și care vă costă bani lună de lună. Acest lucru este cu atât mai probabil dacă ați folosit mașini virtuale clasice, mai degrabă decât noua varietate ARM. Motivul pentru acest lucru este destul de simplu: Azure nu vă șterge în mod sistematic discurile atunci când ștergeți o mașină virtuală. Acest lucru are rolul de a vă proteja împotriva pierderilor accidentale de date, dar înseamnă, de asemenea, că, dacă nu sunteți atent, veți continua să plătiți pentru discuri de care nu mai aveți nevoie.

Puteți rezolva această problemă din portalul 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. Utilizați bara de căutare Azure pentru a găsi contul de stocare pe care l-ați notat la pasul 1, apoi deschideți panoul Properties (Proprietăți)

4. Faceți clic pe Blobs (Blocuri), apoi selectați rândul cu containerul de stocare corect

5. Bifați căsuța cu numele corect al fișierului, apoi faceți clic pe Delete în meniul de sus

VHD-uri uitate

Inclusiv dacă urmați toți acești pași pentru identificarea discurilor neatacate, tot s-ar putea să nu observați VHD-uri uitate care stau abandonate în stocarea clasică. De obicei, Azure Portal creează un container „vhds” și le plasează acolo într-un cont de stocare. Pentru a le localiza, verificați în fiecare cont de stocare clasic dacă există un container „vhds” în Blobs. În interiorul containerului, uitați-vă la coloana Lease state pentru fiecare fișier. Dacă scrie Disponibil, înseamnă că nicio mașină virtuală nu utilizează în prezent acel VHD și este posibil să puteți să-l ștergeți în condiții de siguranță (dar ar trebui să verificați întotdeauna conținutul pentru a vă asigura!).

Utilizați bazele de date elastice de tip pool

Sunt șanse să vă fi început proiectul de migrare în cloud prin mutarea în Azure a unor sarcini de lucru care erau găzduite anterior la fața locului sau într-un centru de date privat. Un număr mare dintre aceste sarcini de lucru foloseau probabil baze de date SQL Server, care tindeau să fie coloana vertebrală a majorității proiectelor software înainte de apariția cloud-ului și a mișcării NoSQL. De asemenea, probabil că ați observat că prețurile pentru bazele de date SQL în Azure pot deveni destul de ridicate, destul de repede.

În timp ce, anterior, este posibil să fi folosit un singur server de baze de date pentru a găzdui zeci, dacă nu sute, de baze de date pentru diversele dvs. proiecte sau clienți, costul împărțirii acestora în baze de date SQL Azure separate ar putea fi cu câteva ordine de mărime mai mare decât vă așteptați. Acest lucru se datorează modului în care funcționează bazele de date în Azure. On-prem, erați obișnuit ca mai multe baze de date să împartă resursele limitate ale unui singur server. Cu Azure SQL, fiecare bază de date are o cantitate rezervată de resurse, pentru care veți fi taxat chiar dacă baza de date este inactivă. Modelul este excelent dacă aveți mai multe baze de date cu o utilizare constantă și previzibilă. Cu toate acestea, dacă aveți un număr mare de baze de date cu un tipar de utilizare în vîrfuri, s-ar putea ca prețul să vă pară mult mai puțin atrăgător. Acest lucru vă lasă cu două opțiuni:

• Utilizați un nivel de baze de date mai mare și mai scump pentru a face față vârfurilor de utilizare a bazelor de date
• Utilizați un nivel inferior pentru a economisi costuri, în detrimentul performanței în perioadele de vârf

Pentru a partaja resursele între bazele de date, cei care au adoptat Azure la început au fost nevoiți să creeze și să își mențină propriile mașini virtuale cu SQL Server instalat și, în esență, să reproducă condițiile în care au fost rulate în timp ce se aflau la fața locului sau într-un centru de date privat. Deși această metodă a funcționat bine, nu a permis accesul la toate caracteristicile extraordinare pe care Azure SQL le oferă, cum ar fi:

• Disponibilitate ridicată încorporată (nu este nevoie să configurați replicarea)
• Geo-replicare activă
• Restaurare în timp real

Aceste caracteristici nu sunt banale de implementat pe cont propriu și pot fi o provocare pentru întreținere.

Mai bine: Instanțe gestionate

Azure oferă un nivel mai nou de servicii de baze de date SQL numit Instanțe gestionate, care sunt, în esență, mașini virtuale gestionate care găzduiesc un SQL Server. Instanțele administrate nu vă vor oferi toate caracteristicile încorporate în serviciile Azure SQL cu o singură bază de date, dar nici nu va trebui să administrați sistemul de operare sau instalarea SQL Server. Practic, veți obține o mașină virtuală a cărei configurare și întreținere este în mare parte gestionată pentru dumneavoastră.

Cel mai bun: SQL elastic pools

Există însă o altă opțiune în Azure pentru a aborda acest scenariu comun: SQL elastic pools. În loc să rezervați o anumită cantitate de resurse pentru o singură bază de date, pool-urile elastice SQL vă permit să rezervați un număr de resurse și să le împărțiți între sute de baze de date. Acest model are toate avantajele oferite de Azure SQL și vă permite să gestionați în mod corespunzător modelele de utilizare cu vârf și îndesat în mai multe baze de date. Pool-urile elastice s-au dovedit a fi incredibil de populare și sunt o opțiune ideală pentru aplicațiile cu mai multe locații.

Cu toate acestea, trebuie să fiți precauți în utilizarea pool-urilor elastice. Dacă aveți una sau mai multe baze de date cu o utilizare semnificativ mai mare decât celelalte baze de date dintr-un pool, este posibil să fiți obligat să achiziționați un nivel de pool elastic mai scump pentru a gestiona vârfurile de utilizare. În unele cazuri, poate fi de fapt mai rentabil să împărțiți aceste baze de date cu utilizare ridicată în oferte de baze de date unice (scoțându-le din pool) și să plătiți un nivel mai mic de pool elastic pentru restul bazelor de date cu utilizare mai redusă. O bună regulă de bază este să vă uitați la utilizarea DTU a bazei de date: dacă o singură bază de date utilizează 40% sau mai mult din DTU ale bazei de date elastice la un moment dat, este posibil să puteți economisi costuri prin separarea acesteia din bazin, apoi prin reducerea bazei respective la un nivel mai puțin costisitor.

Ca întotdeauna, portalul Azure este punctul de reper pentru identificarea modelelor de utilizare a bazelor de date.

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?

Ensure external users have access to the right things in Teams.

Get full visibility into who’s shared what with whom, and automate external sharing reviews so they’re performed on an ongoing basis.