The 5 proven tactics that reduced our Azure costs by 30%

Każdą wskazówkę przygotowaliśmy w sposób krótki, łatwy do zastosowania i zrozumiały:

1. Rozważenie maszyn wirtualnych serii B-.Maszyny wirtualne serii B
2. Zidentyfikuj bezczynne zasoby i podejmij odpowiednie działania
3. Znajdź właściwy rozmiar zasobów
4. Zlokalizuj i usuń nieużywane dyski
5. Wykorzystaj elastyczne bazy danych

Działanie

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.

Maszyny wirtualne w chmurze stanowią wyzwanie pod względem kontroli kosztów: zazwyczaj wymagają minimalnych specyfikacji do działania i często są bezczynne z okresowymi skokami wykorzystania, a mimo to ponoszą pełne koszty, dopóki są włączone.

We wrześniu 2017 r. firma Microsoft ogłosiła rodzinę maszyn wirtualnych serii B, znanych również jako maszyny wirtualne typu burstable. Maszyny te są specjalnie zaprojektowane dla obciążeń roboczych, które zawsze muszą być dostępne, ale zazwyczaj są bezczynne z okazjonalnymi szczytami użycia. Maszyny wirtualne serii B oferują znaczny potencjał redukcji kosztów: od 15 do 55% w stosunku do ceny równoważnej maszyny serii D, w zależności od używanego systemu operacyjnego.

Zalecana lektura: Azure cost-saving tips: dos and don’ts from industry insiders, by Leigh Ryan

Więc powinienem przekonwertować wszystkie moje istniejące maszyny wirtualne na maszyny serii B i dużo zaoszczędzić?

Uwaga! Nie wszystkie obciążenia mogą być przekonwertowane na serię B na ślepo. Musisz znaleźć równowagę między kosztami a zużyciem procesora. Serii B przydzielana jest podstawowa ilość mocy procesora. Dopóki jej wykorzystanie jest poniżej poziomu bazowego, maszyna wirtualna gromadzi kredyty, które mogą być wykorzystane do zużycia CPU powyżej poziomu bazowego. Jeśli jednak maszyna wirtualna stanie się zbyt intensywnie wykorzystująca CPU, zostanie zdławiona do poziomu bazowego, dopóki nie będzie dostępna wystarczająca liczba kredytów.

Podstawy i limity kredytów różnią się w zależności od rozmiaru każdej maszyny wirtualnej B-Series. Ponadto, gdy maszyna wirtualna zostanie wyłączona, wszystkie zgromadzone kredyty zostaną utracone. W związku z tym maszyny wirtualne serii B są naprawdę przeznaczone do mało wymagających lub przewidywalnych obciążeń, które muszą być dostępne przez cały czas.

Aby określić, czy maszyna wirtualna może być bezpiecznie przekonwertowana na serię B, można uruchomić niestandardowe skrypty, takie jak skrypt Azure-Burst-Check Dave’a Halla.

Identyfikuj i działaj na bezczynnych zasobach

Dzięki Azure, nigdy nie było łatwiej uruchomić nowe środowisko w mgnieniu oka, gdy tylko nadejdzie czas, aby zaspokoić nową potrzebę Twojej organizacji. 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. Sprawdź nasz elementarz dotyczący tworzenia planu zarządzania kosztami w chmurze, aby zapoznać się z podstawowymi elementami, które należy rozważyć: widocznością, własnością i uprawnieniami, cyklem życia i optymalizacją – lub, jak lubimy je nazywać, VOLO.

W skrócie, dla każdego zasobu, który tworzysz, będziesz chciał:

• Użyć tagów i innych strategii, aby skategoryzować, w jaki sposób zasób będzie wykorzystywany (dev, test, prod itp.).)
• Zdefiniować pojedynczego właściciela zasobu (zazwyczaj jest to osoba, która zażądała zasobu)
• Określić datę wygaśnięcia lub sprawdzenia zasobu (i upewnić się, że postępujesz zgodnie z harmonogramem i szybko eliminujesz niepotrzebne zasoby)

Gdy masz już te informacje, dużo łatwiej jest określić, czy dany zasób jest nadal potrzebny i podjąć odpowiednie działania.

Polecana lektura: How to start and stop your VMs with Azure Automation, by Antoine Jagueneau

Nie mam planu zarządzania kosztami. Co teraz?

Azure daje Ci dostęp do zestawu statystyk użytkowania, które mierzą aktywność Twoich zasobów. Wartości te mogą być badane z poziomu portalu Azure, poprzez dostęp do API Azure i użycie niestandardowego kodu lub poprzez dedykowane rozwiązanie do zarządzania kosztami. Badając te liczby użycia, można zidentyfikować, które aktywa nie są już używane (lub są znacznie niewykorzystywane) i podjąć odpowiednie działania. Należy również pamiętać, że zarządzanie kosztami chmury jest procesem iteracyjnym, więc nigdy nie jest za późno na rozpoczęcie pracy nad planem.

Znajdź właściwy rozmiar zasobu

Powszechnym problemem podczas tworzenia nowych zasobów chmury jest określenie właściwego rozmiaru do użycia. Azure oferuje wiele opcji, aby dostosować się do różnych wymagań (więcej pamięci RAM, więcej mocy procesora, dyski SSD, procesory graficzne itp.), ale nawet w obrębie tej samej rodziny maszyn, wybór odpowiedniego rozmiaru ma znaczenie.

Zalecana lektura: How does Azure VM pricing work?, autorstwa Leigh Ryan

Zleć to źle, a albo będziesz płacić więcej niż potrzebujesz, podczas gdy twoja maszyna będzie pracować na biegu jałowym, albo skończysz z maszyną, która jest w 100% wykorzystana przez procesor (lub co gorsza, przełącza się do pamięci wirtualnej, ponieważ skończyła się jej fizyczna pamięć RAM). Wszystko to oczywiście może znacząco wpłynąć na wydajność aplikacji.

Nie zawsze łatwo jest określić wymagania danego systemu z wyprzedzeniem, więc może być kuszące, aby pójść trochę wyżej niż potrzebujesz tylko po to, aby być po bezpiecznej stronie. Często zdarza się również, że zapominamy o tym i pozostawiamy to niedopracowane, co prowadzi do niepotrzebnych kosztów miesiąc po miesiącu.

Jak można tego uniknąć? Przyjrzymy się kilku strategiom w tym artykule.

Najprostszym sposobem na uniknięcie marnowania pieniędzy na niepotrzebne zużycie zasobów, jest pozwolenie dedykowanemu narzędziu do optymalizacji chmury na monitorowanie twojego najemcy i powiadamianie cię, gdy jest okazja do zmiany rozmiaru, zmniejszenia skali lub w inny sposób ograniczenia danego zasobu.

Kiedy zmniejszyć skalę

Jeśli uważasz, że tak może być w przypadku twojego środowiska, nie panikuj! Istnieje kilka łatwych sposobów na określenie, czy powinieneś zmniejszyć rozmiar danej maszyny wirtualnej. Najprostszym z nich jest spojrzenie na wykresy CPU Percentage i Memory Percentage dla każdego zasobu w portalu Azure.

Typowo, rozmiary instancji w Azure podwajają się z każdą warstwą: S1 będzie mieć 1 rdzeń CPU wraz z 1,75 GB pamięci RAM, podczas gdy S2 będzie mieć 2 rdzenie i 3,5 GB pamięci RAM. Ten sam schemat dotyczy również rozmiarów baz danych i DTU.

W każdym przypadku, jeśli widzisz przez dłuższy czas, że obie statystyki użycia są poniżej 50%, możesz śmiało zmniejszyć rozmiar swojej instancji bez obaw o spadek wydajności.

Dlaczego nie widzę zużycia pamięci dla mojej maszyny wirtualnej?

Niestety, nie otrzymasz wykresów procentowego zużycia pamięci dla maszyn wirtualnych, klasycznych lub zarządzanych, po wyjęciu z pudełka. Aby uzyskać dostęp do tych informacji, musisz włączyć monitorowanie na poziomie gościa i sprawdzić odpowiednie liczniki wydajności. Tym, który powinieneś szczególnie sprawdzić jest MemoryCommitted Bytes. Mając te informacje, powinieneś być w stanie określić, czy usługa może być bezpiecznie skalowana w dół, czy nie.

Lokalizowanie i usuwanie nieużywanych dysków

Jeśli korzystasz z Azure od jakiegoś czasu, prawdopodobnie stworzyłeś i usunąłeś sporą liczbę maszyn wirtualnych. Ale Twój rachunek wciąż rośnie, a Ty nie jesteś pewien dlaczego. Jednym z prawdopodobnych winowajców są dyski magazynowe, a konkretnie dyski usuniętych maszyn wirtualnych, które wciąż zalegają na twoim koncie i kosztują cię z miesiąca na miesiąc. Jest to jeszcze bardziej prawdopodobne, jeśli używasz klasycznych maszyn wirtualnych, a nie nowej odmiany ARM. Powód tego jest dość prosty: Azure nie usuwa systematycznie twoich dysków, gdy usuwasz maszynę wirtualną. Ma to na celu ochronę przed przypadkową utratą danych, ale oznacza również, że jeśli nie będziesz ostrożny, będziesz płacił za dyski, których już nie potrzebujesz.

Możesz rozwiązać ten problem z poziomu portalu 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. Użyj paska wyszukiwania Azure, aby znaleźć konto Storage, które zauważyłeś w kroku 1, a następnie otwórz panel Properties

4. Kliknij Blobs, a następnie wybierz wiersz z właściwym kontenerem pamięci masowej

5. Zaznacz pole z poprawną nazwą pliku, a następnie kliknij przycisk Usuń w górnym menu

Zapomniane dyski VHD

Nawet jeśli wykonasz wszystkie te kroki, aby zidentyfikować niezałączone dyski, nadal możesz przegapić zapomniane dyski VHD, które siedzą porzucone w klasycznej pamięci masowej. Zazwyczaj Portal Azure tworzy kontener „vhds” i umieszcza je tam na koncie pamięci masowej. Aby je zlokalizować, sprawdź każde klasyczne konto pamięci masowej dla kontenera vhds pod Blobs. Wewnątrz kontenera, spójrz na kolumnę Lease state dla każdego pliku. Jeśli widnieje tam napis Available, oznacza to, że żadna maszyna wirtualna nie używa obecnie tego dysku VHD i można go bezpiecznie usunąć (ale zawsze należy sprawdzić zawartość, aby się upewnić!).

Wykorzystaj bazy danych elastic pool

Możliwe, że rozpocząłeś projekt migracji do chmury, przenosząc obciążenia, które wcześniej były hostowane na miejscu lub w prywatnym centrum danych na Azure. Duża część tych obciążeń prawdopodobnie korzystała z baz danych SQL Server, które stanowiły podstawę większości projektów programistycznych przed pojawieniem się chmury i ruchu NoSQL. Prawdopodobnie zauważyłeś również, że ceny baz danych SQL w Azure mogą być dość wysokie, dość szybko.

Poprzednio mogłeś używać pojedynczego serwera bazy danych do hostowania dziesiątek, jeśli nie setek, baz danych dla różnych projektów lub klientów, ale koszt podzielenia ich na oddzielne bazy danych SQL w Azure może być o rząd wielkości wyższy niż się spodziewałeś. Wynika to z tego, jak działają bazy danych w Azure. On-prem, byłeś przyzwyczajony do wielu baz danych dzielących ograniczone zasoby pojedynczego serwera. W Azure SQL, każda baza danych ma zarezerwowaną ilość zasobów, za które nadal będziesz obciążany, nawet jeśli baza danych jest bezczynna. Model ten jest świetny, jeśli posiadasz wiele baz danych o stałym, przewidywalnym wykorzystaniu. Jeśli jednak posiadasz dużą liczbę baz danych o zmiennym wzorcu użytkowania, cena może okazać się znacznie mniej atrakcyjna. Pozostają więc dwie opcje:

• Użycie większej, droższej warstwy bazy danych do obsługi szczytowego wykorzystania bazy danych
• Użycie niższej warstwy w celu zaoszczędzenia kosztów, kosztem wydajności w godzinach szczytu

Aby dzielić zasoby pomiędzy bazy danych, pierwsi użytkownicy Azure byli zmuszeni do tworzenia i utrzymywania własnych maszyn wirtualnych z zainstalowanym SQL Server i zasadniczo replikować warunki, w jakich były one uruchamiane podczas pracy on-prem lub w prywatnym centrum danych. Podczas gdy ta metoda działała dobrze, nie pozwalała na dostęp do wszystkich wspaniałych funkcji, które Azure SQL ma do zaoferowania, takich jak:

• Wbudowana wysoka dostępność (bez potrzeby konfigurowania replikacji)
• Aktywna georeplikacja
• Przywracanie w czasie

Te funkcje nie są trywialne do wdrożenia na własną rękę i mogą być wyzwaniem do utrzymania.

Lepsze: Instancje zarządzane

Azure oferuje nowszą warstwę usług baz danych SQL o nazwie Instancje zarządzane, które są zasadniczo zarządzanymi maszynami wirtualnymi hostującymi serwer SQL. Instancje zarządzane nie zapewnią Ci wszystkich funkcji, które są wbudowane w usługi Azure SQL z jedną bazą danych, ale nie będziesz musiał również zarządzać systemem operacyjnym lub instalacją SQL Server. W zasadzie otrzymujemy wirtualną maszynę, której konfiguracją i utrzymaniem zajmujemy się w dużej mierze sami.

Najlepsze: SQL elastic pools

Jest jednak jeszcze jedna opcja w Azure, która pozwala rozwiązać ten częsty scenariusz: SQL elastic pools. Zamiast rezerwować określoną ilość zasobów dla pojedynczej bazy danych, pule elastyczne SQL pozwalają zarezerwować pewną liczbę zasobów i podzielić je między setki baz danych. Model ten posiada wszystkie zalety Azure SQL i pozwala na prawidłową obsługę zmiennych wzorców użycia w wielu bazach danych. Elastyczne pule okazały się niezwykle popularne i są idealną opcją dla aplikacji typu multi-tenanted.

Jednakże należy zachować ostrożność w korzystaniu z elastycznych pul. Jeśli masz jedną lub więcej baz danych o znacznie wyższym wykorzystaniu niż inne bazy danych w puli, możesz być zmuszony do zakupu droższej warstwy elastycznej puli, aby obsłużyć szczyty wykorzystania. W niektórych przypadkach, bardziej opłacalne może być rozdzielenie takich baz danych na pojedyncze bazy danych (usunięcie ich z puli) i opłacenie mniejszej warstwy elastycznej puli dla pozostałych baz danych o niższym zużyciu. Dobrą zasadą jest spojrzenie na wykorzystanie DTU bazy danych: jeśli pojedyncza baza danych wykorzystuje 40% lub więcej DTU puli elastycznej w danym momencie, możesz być w stanie zaoszczędzić koszty poprzez wydzielenie jej z puli, a następnie skalowanie w dół do tańszego poziomu.

Jak zawsze, portal Azure jest najlepszym narzędziem do identyfikacji wzorców wykorzystania baz danych.

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?