De 5 beprövade taktikerna som minskade våra Azure-kostnader med 30 %

Under 2017 spenderade ShareGate 250 000 dollar på Azure. Även med en Azure MVP i vårt team som hjälpte oss att hålla kostnaderna så låga som möjligt, ökade vår räkning ändå med 45 % på mindre än 12 månader. Den största boven var förstås molnspridning.

Vi visste att det var möjligt att göra stora besparingar, så vi bad våra experter att skapa en lista med praktiska och effektiva metoder för kontroll av molnkostnader för att minska våra Azure-utgifter.

Vi sammanställde våra resultat i den här guiden så att du också kan börja identifiera potentiella Azure-besparingar i din organisations miljöer direkt.

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.

Molnbaserade virtuella maskiner utgör en utmaning när det gäller kostnadskontroll: de kräver vanligtvis minimala specifikationer för att köras och är ofta inaktiva med periodiska användningstoppar, men ändå fortsätter de att ådra sig full kostnad så länge de är påslagna.

I september 2017 tillkännagav Microsoft B-seriens familj av virtuella maskiner, även känd som burstable virtual machines. Dessa maskiner är särskilt utformade för arbetsbelastningar som alltid måste vara tillgängliga men som vanligtvis är inaktiva med tillfälliga toppar i användningen. De virtuella maskinerna i B-serien erbjuder en betydande potential för kostnadsreducering: mellan 15 och 55 procent av priset för en motsvarande maskin i D-serien, beroende på vilket operativsystem du använder.

Rekommenderad läsning: Läs mer: Azure cost-saving tips: dos and don’ts from industry insiders, av Leigh Ryan

Så jag ska konvertera alla mina befintliga virtuella maskiner till B-serien och spara stort?

Var försiktig nu! Alla arbetsbelastningar kan inte konverteras till B-Series i blindo. Du måste hitta en balans mellan kostnad och CPU-förbrukning. B-Series tilldelas en baslinje av processorkraft. Så länge dess användning ligger under baslinjen ackumulerar den virtuella maskinen krediter, som sedan kan användas för att förbruka CPU som överstiger baslinjen. Om din virtuella maskin blir för CPU-intensiv kommer den dock att strypas ner till baslinjeprestanda tills tillräckligt med krediter finns tillgängliga.

Baslinjer och kreditgränser varierar beroende på storleken på varje virtuell maskin i B-serien. Dessutom går alla ackumulerade krediter förlorade när den virtuella maskinen stängs av. Därför är VM:er i B-serien verkligen utformade för låganvändning eller förutsägbara arbetsbelastningar som måste vara tillgängliga hela tiden.

För att hjälpa dig att avgöra om din virtuella maskin kan konverteras till en B-serie på ett säkert sätt kan du köra anpassade skript, t.ex. Dave Halls Azure-Burst-Check-skript.

Identifiera och agera på outnyttjade resurser

Tack vare Azure har det aldrig varit enklare att få en ny miljö igång på ett ögonblick när det är dags att uppfylla ett nytt behov för din organisation. 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. Kolla in vår grundbok om hur man skapar en plan för styrning av molnkostnader för att få en översikt över de viktigaste delarna att ta hänsyn till: synlighet, ägande och behörigheter, livscykel och optimering – eller, som vi kallar dem, VOLO.

För varje resurs som du skapar vill du i korthet:

• Använda taggar och andra strategier för att kategorisera hur resursen kommer att användas (dev, test, prod osv.).)
• Specificera en enda ägare för resursen (vanligtvis den person som begärde resursen)
• Detektera ett utgångs- eller kontrolldatum för resursen (och se till att följa schemat och eliminera onödiga resurser omgående)

När du väl har den här informationen är det mycket lättare att avgöra om en viss resurs fortfarande behövs eller inte och agera därefter.

Rekommenderad läsning: Hur du startar och stoppar dina virtuella maskiner med Azure Automation, av Antoine Jagueneau

Jag har ingen plan för kostnadsstyrning. Vad händer nu?

Azure ger dig tillgång till en uppsättning användningsstatistik som mäter hur mycket aktivitet dina resurser har. Dessa värden kan undersökas från Azure-portalen, genom att få tillgång till Azure API och använda anpassad kod eller genom en dedikerad kostnadsstyrningslösning. Genom att undersöka dessa användningssiffror kan du identifiera vilka resurser som inte längre används (eller är betydligt underutnyttjade) och vidta lämpliga åtgärder. Tänk också på att styrning av molnkostnader är en iterativ process, så det är aldrig för sent att börja arbeta med en plan.

Hitta rätt resursstorlek

Ett vanligt problem när man skapar nya molnresurser är att ta reda på rätt storlek att använda. Azure erbjuder ett stort antal alternativ för att tillgodose olika krav (mer RAM-minne, mer CPU-kraft, SSD-enheter, GPU:er etc.), men även inom samma maskinfamilj är det viktigt att välja rätt storlek.

Rekommenderad läsning: Om du väljer fel betalar du antingen mer än vad du behöver medan maskinen går på tomgång, eller så får du en maskin med 100 % CPU-användning (eller ännu värre, som byter till virtuellt minne eftersom det fysiska RAM-minnet är slut). Allt detta kan naturligtvis påverka programmens prestanda avsevärt.

Det är inte alltid lätt att räkna ut ett visst systems krav i förväg, så det kan vara frestande att välja lite högre än vad du behöver bara för att vara på den säkra sidan. Det är också ganska vanligt att man sedan glömmer bort det och låter det vara överdimensionerat, vilket leder till onödiga kostnader månad efter månad.

Hur kan du undvika detta? Vi ska titta på några strategier i den här artikeln.

Det enklaste sättet att undvika att slösa pengar på onödig resursförbrukning är dock att låta ett dedikerat molnoptimeringsverktyg övervaka din hyresgäst och meddela dig när det finns en möjlighet att rätt dimensionera, nedskala eller på annat sätt skära ner på en viss resurs.

När du ska nedskala

Om du tror att det här kan vara fallet för din miljö, får du ingen panik! Det finns några enkla sätt att avgöra om du bör minska storleken på en viss virtuell maskin. Den enklaste metoden är att ta en titt på graferna CPU-procent och minnesprocent för varje resurs i Azure Portal.

Typiskt sett fördubblas instansstorlekarna i Azure med varje nivå: en S1 har 1 CPU-kärna tillsammans med 1,75 GB RAM, medan en S2 har 2 kärnor och 3,5 GB RAM. Samma mönster gäller även för databasstorlekar och DTU:er.

Om du ser att båda användningsstatistikerna under en längre tidsperiod ligger under 50 % kan du i alla fall med tillförsikt skala ner din instans utan att oroa dig för att det ska hämma prestandan.

Varför kan jag inte se minnesanvändningen för min virtuella maskin?

Tyvärr kommer du inte att få graferna för minnesprocent för virtuella maskiner, klassiska eller hanterade, direkt ur lådan. För att få tillgång till den här informationen måste du aktivera övervakning på gästnivå och kontrollera rätt prestandacontroller. Den du bör kontrollera specifikt är MemoryCommitted Bytes. Med den här informationen bör du kunna avgöra om en tjänst kan nedskalas på ett säkert sätt eller inte.

Lokalisera och ta bort oanvända diskar

Om du har använt Azure ett tag har du troligen skapat – och tagit bort – ett ganska stort antal virtuella maskiner. Men din räkning fortsätter att stiga och du vet inte riktigt varför. En trolig orsak är lagringsdiskar, närmare bestämt diskarna för raderade virtuella maskiner som fortfarande finns kvar på ditt konto och kostar dig pengar månad efter månad. Detta är ännu mer troligt om du har använt klassiska virtuella maskiner snarare än den nya ARM-varianten. Anledningen till detta är ganska enkel: Azure raderar inte systematiskt dina diskar när du raderar en virtuell maskin. Detta är för att skydda dig från oavsiktlig dataförlust, men det innebär också att om du inte är försiktig kommer du att fortsätta att betala för diskar som du inte längre behöver.

Du kan lösa det här problemet från Azure-portalen. 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. Använd Azure-sökfältet för att hitta lagringskontot som du noterade i steg 1. Öppna sedan fönstret Egenskaper

4. Klicka på Blobs och välj sedan raden med rätt lagringsbehållare

5. Markera rutan med rätt filnamn och klicka sedan på Ta bort i toppmenyn

Förlorade VHD:er

Även om du följer alla dessa steg för att identifiera oanslutna diskar, kan du ändå missa glömda VHD:er som ligger övergivna i klassisk lagring. Vanligtvis skapar Azure Portal en ”vhds”-behållare och placerar dem där i ett lagringskonto. Om du vill hitta dem kontrollerar du varje klassiskt lagringskonto för att hitta en vhds-behållare under Blobs. I behållaren tittar du på kolumnen Lease state för varje fil. Om det står Available betyder det att ingen virtuell maskin för närvarande använder den VHD:n och att det kan vara säkert för dig att ta bort den (men du bör alltid kontrollera innehållet för att vara säker!).

Använda elastic pool-databaser

Det är troligt att du har börjat ditt molnmigreringsprojekt med att flytta arbetsbelastningar som tidigare fanns på plats eller i ett privat datacenter över till Azure. Ett stort antal av dessa arbetsbelastningar använde förmodligen SQL Server-databaser, som tenderade att vara ryggraden i de flesta programvaruprojekt innan molnet och NoSQL-rörelsen kom fram. Du har också troligen lagt märke till att priserna för SQL-databaser i Azure kan bli ganska höga, ganska snabbt.

Och även om du tidigare kanske använde en enda databasserver för att vara värd för dussintals, om inte hundratals, databaser för dina olika projekt eller kunder, så kan kostnaden för att dela upp dessa till separata Azure SQL-databaser vara flera storleksordningar högre än vad du hade förväntat dig. Detta beror på hur databaser fungerar i Azure. På plats var du van vid att flera databaser delade de begränsade resurserna på en enda server. Med Azure SQL har varje databas en reserverad mängd resurser, som du fortfarande debiteras för även om databasen är inaktiv. Modellen är utmärkt om du har flera databaser med konsekvent, förutsägbar användning. Om du har ett stort antal databaser med ett spikrak användningsmönster kan du dock tycka att prislappen är betydligt mindre tilltalande. Då har du två alternativ:

• Använd en större, dyrare databasnivå för att hantera toppar i databasanvändningen
• Använd en lägre nivå för att spara kostnader, på bekostnad av prestandan under toppar

För att dela resurser mellan databaser tvingades tidiga användare av Azure att skapa och underhålla egna virtuella maskiner med SQL Server installerad och i huvudsak replikera de förhållanden som de kördes under när de fanns på plats eller i ett privat datacenter. Den här metoden fungerade visserligen bra, men den gav inte tillgång till alla de fantastiska funktioner som Azure SQL har att erbjuda, till exempel:

• Inbyggd hög tillgänglighet (inget behov av att konfigurera replikering)
• Aktiv georeplikering
• Punkt-i-tid-återställning

De här funktionerna är inte triviala att distribuera på egen hand och kan vara en utmaning att underhålla.

Bättre: Hanterade instanser

Azure erbjuder en nyare nivå av SQL-databastjänster som kallas Hanterade instanser, vilket i huvudsak är hanterade virtuella maskiner som är värd för en SQL Server. Hanterade instanser ger dig inte alla funktioner som är inbyggda i Azure SQL-tjänster för en enda databas, men du behöver inte heller hantera operativsystemet eller SQL Server-installationen. I princip får du en virtuell maskin vars konfiguration och underhåll till stor del sköts åt dig.

Bäst: SQL elastic pools

Men det finns ett annat alternativ i Azure för att hantera detta vanliga scenario: SQL elastic pools. Istället för att reservera en viss mängd resurser för en enda databas kan du med SQL elastic pools reservera ett antal resurser och dela dem mellan hundratals databaser. Den här modellen har alla fördelar med Azure SQL och gör att du kan hantera spikraka användningsmönster över flera databaser på rätt sätt. Elastiska pooler har visat sig vara otroligt populära och är ett idealiskt alternativ för applikationer med flera hyresgäster.

Du bör dock vara försiktig när du använder elastiska pooler. Om du har en eller flera databaser med betydligt högre användning än de andra databaserna i en pool kan du tvingas köpa en dyrare elastisk poolnivå för att hantera användningstopparna. I vissa fall kan det faktiskt vara mer kostnadseffektivt att dela upp dessa databaser med hög användning till erbjudanden med en enda databas (ta dem ur poolen) och betala för en mindre nivå av elastisk pool för de återstående databaserna med lägre användning. En bra tumregel är att titta på databasens DTU-användning: om en enskild databas använder 40 % eller mer av den elastiska poolens DTU:er vid en given tidpunkt kan du kanske spara kostnader genom att dela upp den från poolen och sedan skala ner den nämnda poolen till en billigare nivå.

Som alltid är Azure-portalen din bästa metod för att identifiera användningsmönster för databaser.

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?