5 osvědčených taktik, které snížily naše náklady na Azure o 30 %

V roce 2017 společnost ShareGate utratila za Azure 250 000 dolarů. I když jsme měli v týmu Azure MVP, který nám pomáhal udržet náklady na co nejnižší úrovni, náš účet se přesto za necelých 12 měsíců zvýšil o 45 %. Hlavním viníkem byl samozřejmě cloud sprawl.

Věděli jsme, že je možné dosáhnout masivních úspor, a proto jsme požádali naše odborníky, aby nám sestavili seznam praktických a účinných metod kontroly nákladů na cloud, které nám pomohou snížit výdaje za Azure.

Naše zjištění jsme shrnuli do tohoto průvodce, abyste i vy mohli ihned začít zjišťovat potenciální úspory v prostředí Azure ve vaší organizaci.

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.

Cloudové virtuální počítače představují výzvu z hlediska kontroly nákladů: obvykle vyžadují minimální specifikace pro svůj provoz a často jsou v nečinnosti s pravidelnými nárůsty využití, přesto však nesou plné náklady, dokud jsou zapnuté.

V září 2017 společnost Microsoft oznámila rodinu virtuálních počítačů řady B, známou také jako burstable virtual machines. Tyto stroje jsou speciálně navrženy pro pracovní zátěže, které musí být vždy k dispozici, ale obvykle jsou nečinné s občasnými špičkami ve využití. Virtuální počítače řady B nabízejí významný potenciál snížení nákladů: 15 až 55 % z ceny ekvivalentního stroje řady D, v závislosti na používaném operačním systému.

Doporučená četba:

Měl bych tedy převést všechny své stávající virtuální počítače na řadu B a výrazně ušetřit?

Teď pozor! Ne všechny pracovní zátěže lze převést na řadu B naslepo. Musíte najít rovnováhu mezi náklady a spotřebou procesoru. Řadám B je přiděleno základní množství výkonu CPU. Dokud je jeho využití nižší než základní hodnota, virtuální počítač sbírá kredity, které lze následně použít ke spotřebě CPU přesahující základní hodnotu. Pokud však virtuální počítač začne být příliš náročný na výkon CPU, bude přiškrcen na základní výkon, dokud nebude k dispozici dostatek kreditů.

Základní hodnoty a limity kreditů se liší podle velikosti jednotlivých virtuálních počítačů řady B. Navíc kdykoli dojde k vypnutí virtuálního počítače, všechny nashromážděné kredity se ztratí. Virtuální počítače řady B jsou proto skutečně určeny pro málo využívané nebo předvídatelné pracovní zátěže, u kterých je vyžadována neustálá dostupnost.

Chcete-li zjistit, zda lze váš virtuální počítač bezpečně převést na řadu B, můžete spustit vlastní skripty, například skript Azure-Burst-Check od Davea Halla.

Identifikace nevyužitých prostředků a jednání s nimi

Díky službě Azure nebylo nikdy jednodušší zprovoznit nové prostředí v okamžiku, kdy je třeba splnit novou potřebu vaší organizace. 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. Podívejte se na náš úvodník k vytvoření plánu správy cloudových nákladů, kde najdete přehled základních prvků, které je třeba zvážit: viditelnost, vlastnictví a oprávnění, životní cyklus a optimalizace – nebo, jak jim rádi říkáme, VOLO.

Zjednodušeně řečeno, pro každý vytvořený prostředek budete chtít:

• Pomocí značek a dalších strategií kategorizovat, jak bude prostředek používán (dev, test, prod atd.)
• určit jediného vlastníka prostředku (obvykle osobu, která si prostředek vyžádala)
• určit datum vypršení platnosti nebo kontroly prostředku (a ujistit se, že dodržujete plán a nepotřebné prostředky neprodleně odstraňujete)

Jakmile máte tyto informace, je mnohem snazší určit, zda je daný prostředek stále potřebný, a podle toho jednat.

Doporučená četba: Jak spouštět a zastavovat virtuální počítače pomocí automatizace Azure, autor: Antoine Jagueneau

Nemám plán správy nákladů. Co teď?“

Azure vám poskytuje přístup k sadě statistik využití, které měří, jakou aktivitu vaše prostředky zaznamenávají. Tyto hodnoty lze zkoumat z portálu Azure, přístupem k rozhraní Azure API a pomocí vlastního kódu nebo prostřednictvím specializovaného řešení pro správu nákladů. Zkoumáním těchto čísel využití můžete zjistit, která aktiva již nejsou využívána (nebo jsou využívána výrazně nedostatečně), a přijmout příslušná opatření. Mějte také na paměti, že správa cloudových nákladů je opakující se proces, takže nikdy není pozdě začít pracovat na plánu.

Najděte správnou velikost prostředků

Častým problémem při vytváření nových cloudových prostředků je zjištění správné velikosti. Azure nabízí velké množství možností, jak vyhovět různým požadavkům (více paměti RAM, větší výkon CPU, disky SSD, GPU atd.), ale i v rámci stejné rodiny strojů záleží na výběru správné velikosti.

Doporučená četba:

Jestliže se rozhodnete špatně, budete buď platit více, než potřebujete, zatímco váš stroj bude nečinný, nebo skončíte se strojem, který bude využívat procesor na 100 % (nebo ještě hůře, bude swapovat do virtuální paměti, protože mu dojde fyzická paměť RAM). To vše samozřejmě může výrazně ovlivnit výkon aplikací.

Není vždy snadné dopředu zjistit požadavky daného systému, takže může být lákavé pro jistotu sáhnout po vyšším výkonu, než potřebujete. Je také poměrně časté, že na to pak zapomenete a necháte to předimenzované, což vede ke zbytečným nákladům měsíc co měsíc.

Jak se tomu můžete vyhnout? V tomto článku se podíváme na některé strategie.

Nejjednodušší způsob, jak se vyhnout plýtvání penězi na zbytečnou spotřebu prostředků, je však nechat specializovaný nástroj pro optimalizaci cloudu monitorovat vašeho nájemce a upozornit vás, kdykoli se naskytne příležitost k úpravě velikosti, snížení rozsahu nebo jinému omezení daného prostředku.

Kdy snížit rozsah

Pokud se domníváte, že to může být případ vašeho prostředí, nepanikařte! Existuje několik snadných způsobů, jak zjistit, zda byste měli snížit velikost daného virtuálního počítače. Nejjednodušší metodou je podívat se na grafy procentuálního podílu procesoru a procentuálního podílu paměti pro jednotlivé prostředky na portálu Azure.

Typicky se velikosti instancí v Azure s každou úrovní zdvojnásobují: S1 bude mít 1 jádro procesoru spolu s 1,75 GB paměti RAM, zatímco S2 bude mít 2 jádra a 3,5 GB paměti RAM. Stejný vzorec platí také pro velikosti databází a DTU.

Ve všech případech, pokud dlouhodobě vidíte, že obě statistiky využití jsou pod 50 %, můžete bez obav snížit velikost instance, aniž byste se museli obávat snížení výkonu.

Proč nemohu vidět využití paměti pro svůj virtuální počítač?

Naneštěstí se vám grafy procenta paměti pro virtuální počítače, ať už klasické nebo spravované, po vybalení z krabice nezobrazí. Pro přístup k těmto informacím budete muset povolit monitorování na úrovni hostů a zaškrtnout správné Čítače výkonu. Konkrétně byste měli zkontrolovat položku MemoryCommitted Bytes. Na základě těchto informací byste měli být schopni určit, zda lze službu bezpečně zmenšit, nebo ne.

Lokalizace a odstranění nepoužívaných disků

Pokud službu Azure používáte již delší dobu, pravděpodobně jste vytvořili – a odstranili – dostatečný počet virtuálních počítačů. Váš účet se však stále zvyšuje a vy si nejste zcela jisti proč. Jedním z pravděpodobných viníků jsou disky úložiště; konkrétně disky pro smazané virtuální počítače, které stále zůstávají na vašem účtu a měsíc co měsíc vás stojí peníze. Je to ještě pravděpodobnější, pokud jste používali klasické virtuální počítače, a ne novou odrůdu ARM. Důvod je jednoduchý: Azure systematicky neodstraňuje disky, když odstraníte virtuální počítač. Důvodem je ochrana před náhodnou ztrátou dat, ale také to znamená, že pokud si nedáte pozor, budete dál platit za disky, které už nepotřebujete.

Tento problém můžete vyřešit na portálu 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. Pomocí vyhledávacího panelu Azure najděte účet úložiště, který jste zaznamenali v kroku 1, a poté otevřete panel Vlastnosti

4. Klikněte na položku Blobs a poté vyberte řádek se správným kontejnerem úložiště

5. Zaškrtněte políčko se správným názvem souboru a klikněte na tlačítko Odstranit v horní nabídce

Zapomenuté disky VHD

I když provedete všechny tyto kroky k identifikaci nepřipojených disků, stále vám mohou uniknout zapomenuté disky VHD, které leží opuštěné v klasickém úložišti. Portál Azure obvykle vytvoří kontejner „vhds“ a umístí je tam do účtu úložiště. Chcete-li je najít, zkontrolujte každý účet klasického úložiště, zda v něm není kontejner vhds v části Bloby. Uvnitř kontejneru se podívejte na sloupec Lease state (Stav pronájmu) u každého souboru. Pokud je v něm napsáno Available (Dostupný), znamená to, že daný VHD momentálně nepoužívá žádný virtuální počítač a můžete jej bezpečně odstranit (ale vždy byste měli pro jistotu zkontrolovat jeho obsah!).

Využití databází elastic pool

Pravděpodobně jste svůj projekt migrace do cloudu zahájili přesunem pracovních úloh, které byly dříve hostovány on-prem nebo v soukromém datovém centru, do Azure. Velká část těchto pracovních zátěží pravděpodobně používala databáze SQL Server, které byly obvykle páteří většiny softwarových projektů před nástupem cloudu a hnutí NoSQL. Pravděpodobně jste si také všimli, že ceny za databáze SQL v Azure mohou být poměrně vysoké, a to poměrně rychle.

Zatímco dříve jste možná používali jeden databázový server pro hostování desítek, ne-li stovek databází pro různé projekty nebo zákazníky, náklady na jejich rozdělení do samostatných databází SQL v Azure mohou být řádově vyšší, než jste očekávali. Je to způsobeno tím, jak databáze v Azure fungují. Na lokálním serveru jste byli zvyklí, že více databází sdílelo omezené zdroje jednoho serveru. V Azure SQL má každá databáze vyhrazené množství prostředků, které vám budou účtovány, i když je databáze nečinná. Tento model je skvělý, pokud máte více databází s konzistentním a předvídatelným využitím. Pokud však máte velký počet databází s nepravidelným využitím, může pro vás být cenovka podstatně méně atraktivní. Zbývají vám tedy dvě možnosti:

• Použít větší, dražší databázovou úroveň, abyste zvládli špičkové využití databází
• Použít nižší úroveň, abyste ušetřili náklady na úkor výkonu v době špičky

Pro sdílení prostředků mezi databázemi byli první uživatelé služby Azure nuceni vytvářet a udržovat vlastní virtuální počítače s nainstalovaným serverem SQL Server a v podstatě replikovat podmínky, za kterých byly provozovány, když byly on-prem nebo v soukromém datovém centru. Tento způsob sice fungoval dobře, ale neumožňoval přístup ke všem skvělým funkcím, které Azure SQL nabízí, jako například:

• Vestavěná vysoká dostupnost (není třeba konfigurovat replikaci)
• Aktivní georeplikace
• Obnovení v čase

Tyto funkce není triviální nasadit vlastními silami a jejich údržba může být náročná.

Lepší: Spravované instance

Azure nabízí novější úroveň databázových služeb SQL nazvanou Spravované instance, což jsou v podstatě spravované virtuální počítače, které hostí server SQL Server. Spravované instance vám neposkytnou všechny funkce, které jsou součástí služeb Azure SQL pro jednu databázi, ale nebudete muset spravovat ani operační systém nebo instalaci SQL Serveru. V podstatě získáte virtuální stroj, jehož konfigurace a údržba je z velké části řešena za vás.

Nejlepší: elastické pooly SQL

V systému Azure však existuje ještě jedna možnost, jak tento častý scénář řešit: SQL elastic pools. Namísto vyhrazení určitého množství prostředků pro jednu databázi umožňují elastické pooly SQL vyhradit určitý počet prostředků a sdílet je mezi stovkami databází. Tento model má všechny výhody Azure SQL a umožňuje správně řešit prudké vzorce využití napříč více databázemi. Elastické pooly se ukázaly jako neuvěřitelně populární a jsou ideální volbou pro aplikace s více nájemci.

Při používání elastických poolů byste však měli být obezřetní. Pokud máte jednu nebo více databází s výrazně vyšším využitím než ostatní databáze v poolu, můžete být nuceni zakoupit dražší úroveň elastického poolu, abyste zvládli špičky využití. V některých případech může být ve skutečnosti cenově výhodnější rozdělit tyto databáze s vysokým využitím do jednotlivých databázových nabídek (vyjmout je z poolu) a pro zbývající databáze s nižším využitím zaplatit menší úroveň elastického poolu. Dobrým pravidlem je podívat se na využití DTU databází: pokud jedna databáze využívá v daném okamžiku 40 % nebo více DTU elastického poolu, můžete ušetřit náklady tím, že ji oddělíte od poolu a poté snížíte uvedený pool na méně nákladnou úroveň.

K identifikaci vzorců využití databází vám jako vždy poslouží portál Azure.

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?