Az 5 bevált taktika, amely 30%-kal csökkentette Azure költségeinket

2017-ben a ShareGate 250 000 dollárt költött Azure-ra. Még úgy is, hogy a csapatunkban egy Azure MVP segített a költségeket a lehető legalacsonyabban tartani, a számlánk mégis 45%-kal nőtt kevesebb mint 12 hónap alatt. A fő bűnös természetesen a felhőterjedés volt.

Tudtuk, hogy hatalmas megtakarítások lehetségesek, ezért megkértük szakértőnket, hogy készítsen nekünk egy listát a gyakorlatias és hatékony felhőköltség-ellenőrzési módszerekről, amelyekkel csökkenthetjük Azure-kiadásainkat.

Eredményeinket ebben az útmutatóban foglaltuk össze, hogy Ön is azonnal elkezdhesse azonosítani a potenciális Azure-megtakarítási lehetőségeket a szervezeti környezetében.

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.

A felhőalapú VM-ek kihívást jelentenek a költségkontroll szempontjából: általában minimális specifikációt igényelnek a működésükhöz, és gyakran üresjáratban vannak, időszakos használati csúcsokkal, mégis folyamatosan a teljes költséget viselik, amíg bekapcsolva vannak.

2017 szeptemberében a Microsoft bejelentette a B-sorozatú virtuális gépcsaládot, más néven burstable virtuális gépeket. Ezeket a gépeket kifejezetten olyan munkaterhelésekhez tervezték, amelyeknek mindig rendelkezésre kell állniuk, de jellemzően üresjáratban vannak, időnkénti használati csúcsokkal. A B-sorozatú VM-ek jelentős költségcsökkentési potenciált kínálnak: a használt operációs rendszertől függően 15-55%-kal kevesebbet, mint egy egyenértékű D-sorozatú gép ára.

Elolvasásra ajánlott: Azure cost-saving tips: dos and don’ts from industry insider, by Leigh Ryan

Szóval az összes meglévő VM-emet át kellene alakítanom B-sorozatúra, és nagyot spórolhatnék?

Vigyázz most! Nem minden munkaterhelés konvertálható vakon B-sorozatúra. Meg kell találni az egyensúlyt a költségek és a CPU-fogyasztás között. A B-sorozatú VM-ek alapszintű CPU-teljesítményt kapnak. Amíg a felhasználása az alapszint alatt van, a VM krediteket gyűjt, amelyeket aztán az alapszintet meghaladó CPU-fogyasztásra lehet felhasználni. Ha azonban a virtuális gép túlságosan CPU-intenzívvé válik, az alapszintű teljesítményre leszűkítve, amíg elegendő kredit nem áll rendelkezésre.

Az alapszint és a kreditkorlátok az egyes B-sorozatú VM-ek méretétől függően változnak. Ezenkívül, amikor a VM kikapcsol, az összes felhalmozott kredit elveszik. Így a B-sorozatú VM-eket valóban alacsony kihasználtságú vagy kiszámítható munkaterhelésekhez tervezték, amelyeknek folyamatosan rendelkezésre kell állniuk.

Hogy segítsen meghatározni, hogy virtuális gépe biztonságosan átalakítható-e B-sorozatúvá, olyan egyéni szkripteket futtathat, mint például Dave Hall Azure-Burst-Check szkriptje.

Identification and act on idle resources

Az Azure-nak köszönhetően soha nem volt még ilyen egyszerű egy új környezetet egy pillanat alatt üzembe helyezni, amikor csak egy új igényt kell kielégíteni a szervezet számára. 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. Tekintse meg a felhőköltség-irányítási terv készítéséről szóló alapkönyvünket, ahol áttekintést kaphat a figyelembe veendő fő elemekről: láthatóság, tulajdonjog és jogosultságok, életciklus és optimalizálás – vagy ahogy mi szeretjük őket hívni, VOLO.

Dióhéjban összefoglalva, minden egyes létrehozott erőforrás esetében érdemes:

• Címkék és más stratégiák segítségével kategorizálni, hogy az eszközt hogyan fogják használni (dev, test, prod stb.)
• Meghatározni az erőforrás egyetlen tulajdonosát (általában azt a személyt, aki az erőforrást kérte)
• Meghatározni az erőforrás lejárati vagy ellenőrzési dátumát (és ügyeljen arra, hogy kövesse az ütemtervet, és azonnal megszüntesse a felesleges erőforrásokat)

Amikor már rendelkezik ezekkel az információkkal, sokkal könnyebb meghatározni, hogy egy adott erőforrásra még szükség van-e, és ennek megfelelően cselekedni.

Referált olvasmány: Antoine Jagueneau

Nincs költségirányítási tervem. Most mi legyen?

Az Azure hozzáférést biztosít egy sor használati statisztikához, amelyek azt mérik, hogy az erőforrásai mekkora aktivitást mutatnak. Ezeket az értékeket az Azure portálról, az Azure API elérésével és egyéni kód használatával, vagy egy dedikált költségkezelési megoldáson keresztül lehet vizsgálni. E felhasználási számok vizsgálatával azonosíthatja, hogy mely eszközök nincsenek már használatban (vagy jelentősen kihasználatlanok), és megfelelő intézkedéseket hozhat. Ne feledje azt sem, hogy a felhőköltségek irányítása iteratív folyamat, ezért sosem késő elkezdeni a terv kidolgozását.

A megfelelő erőforrásméret megtalálása

Az új felhőerőforrások létrehozásakor gyakori probléma a megfelelő méret kitalálása. Az Azure számos lehetőséget kínál a különböző igények kielégítésére (több RAM, nagyobb CPU-teljesítmény, SSD-meghajtók, GPU-k stb.), de még ugyanazon gépcsaládon belül is számít a megfelelő méret kiválasztása.

Az ajánlott olvasmány: Leigh Ryan

Ha rosszul választ, akkor vagy többet fizet, mint amennyire szüksége van, miközben a gép üresjáratban van, vagy egy olyan gépet kap, amely 100%-os CPU-kihasználtsággal dolgozik (vagy ami még rosszabb, virtuális memóriára vált, mert elfogyott a fizikai RAM). Mindez természetesen jelentősen befolyásolhatja az alkalmazások teljesítményét.

Nem mindig könnyű előre kitalálni egy adott rendszer követelményeit, ezért csábító lehet, hogy a biztonság kedvéért a szükségesnél egy kicsit magasabbat válasszunk. Az is elég gyakori, hogy aztán megfeledkezünk róla, és túlméretezve hagyjuk, ami hónapról hónapra felesleges költségekhez vezet.

Hogyan lehet ezt elkerülni? Ebben a cikkben megnézünk néhány stratégiát.

A legegyszerűbb módja azonban annak, hogy elkerülje a felesleges erőforrás-fogyasztásra való pénzpazarlást, ha hagyja, hogy egy dedikált felhőoptimalizáló eszköz figyelje a bérlőjét, és értesítse, amikor lehetőség van arra, hogy egy adott erőforrás méretét csökkentsék, vagy más módon csökkentsék.

Mikor kell csökkenteni

Ha úgy véli, hogy ez lehet a helyzet a környezetében, ne essen pánikba! Van néhány egyszerű módszer annak megállapítására, hogy érdemes-e lekicsinyíteni egy adott VM-et. A legegyszerűbb módszer, ha vet egy pillantást az Azure Portálon az egyes erőforrások CPU százalékos és memória százalékos grafikonjaira.

Tipikusan az Azure-ban a példányok mérete minden egyes réteggel megduplázódik: egy S1 1 CPU-maggal rendelkezik 1,75 GB RAM mellett, míg egy S2 2 maggal és 3,5 GB RAM-mal. Ugyanez a minta érvényes az adatbázisméretekre és a DTU-kra is.

Minden esetben, ha hosszú időn keresztül azt látja, hogy mindkét használati statisztika 50% alatt van, akkor bátran csökkentheti a példány méretét anélkül, hogy aggódnia kellene a teljesítmény csökkenése miatt.

Miért nem látom a VM-em memóriahasználatát?

A memória százalékos grafikonjait a klasszikus vagy kezelt virtuális gépekhez sajnos nem fogja kapni a dobozból. Ahhoz, hogy hozzáférjen ezekhez az információkhoz, engedélyeznie kell a vendégszintű felügyeletet, és be kell jelölnie a megfelelő Teljesítményszámlálókat. Kifejezetten a MemoryCommitted Bytes-ot kell ellenőriznie. Ennek az információnak a segítségével meg kell tudnia állapítani, hogy egy szolgáltatás biztonságosan csökkenthető-e vagy sem.

Kihasználatlan lemezek keresése és törlése

Ha már egy ideje használja az Azure-t, akkor valószínűleg elég sok virtuális gépet hozott létre – és törölt – már. A számlája azonban folyamatosan emelkedik, és nem egészen biztos benne, hogy miért. Az egyik valószínű bűnös a tárolólemezek; pontosabban a törölt virtuális gépekhez tartozó lemezek, amelyek még mindig a számláján vannak, és hónapról hónapra pénzébe kerülnek. Ez még valószínűbb, ha klasszikus virtuális gépeket használ, nem pedig az új ARM változatot. Ennek oka nagyon egyszerű: Az Azure nem törli szisztematikusan a lemezeket, amikor törli a virtuális gépet. Ez a véletlen adatvesztéstől való védelmet szolgálja, de azt is jelenti, hogy ha nem vigyáz, továbbra is fizetni fog olyan lemezekért, amelyekre már nincs szüksége.

Az Azure portálon keresztül megoldhatja ezt a problémát. 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. Az Azure keresősáv segítségével keresse meg az 1. lépésben megjegyzett Tárolófiókot, majd nyissa meg a Tulajdonságok ablaktáblát

4. Kattintson a Blobok gombra, majd válassza ki a megfelelő tárolóedényt tartalmazó sort

5. Válassza ki a megfelelő tárolóedényt tartalmazó sort

. Jelölje be a megfelelő fájlnevet tartalmazó négyzetet, majd kattintson a felső menüben a Törlés gombra

Elfelejtett VHD-k

Még ha követi is ezeket a lépéseket a nem csatolt lemezek azonosításához, akkor is előfordulhat, hogy elfelejtett VHD-k maradnak ki, amelyek elhagyatottan ülnek a klasszikus tárolóban. Általában az Azure Portal létrehoz egy “vhds” konténert, és ott helyezi el őket egy tárolófiókban. Ha meg szeretné találni őket, keressen minden egyes klasszikus tárolófiókban egy vhds konténert a Blobok alatt. A konténeren belül nézze meg az egyes fájlok Lease state (Bérlési állapot) oszlopát. Ha azt írja, hogy Elérhető, az azt jelenti, hogy jelenleg egyetlen VM sem használja az adott VHD-t, és lehet, hogy nyugodtan törölheti (de mindig ellenőrizze a tartalmát, hogy megbizonyosodjon róla!).

Elastic pool adatbázisok kihasználása

Valószínűleg azzal kezdte felhőmigrációs projektjét, hogy a korábban helyben vagy egy privát adatközpontban hosztolt munkaterheket áthelyezte az Azure-ra. E munkaterhelések nagy része valószínűleg SQL Server-adatbázisokat használt, amelyek a felhő és a NoSQL-mozgalom megjelenése előtt általában a legtöbb szoftverprojekt gerincét képezték. Valószínűleg azt is észrevette, hogy az SQL-adatbázisok árazása az Azure-ban elég gyorsan elég magasra tud emelkedni.

Míg korábban egyetlen adatbázis-kiszolgálót használhatott a különböző projektjei vagy ügyfelei számára több tucat, ha nem több száz adatbázis hosztolására, ezek külön Azure SQL-adatbázisokra való felosztásának költsége nagyságrendekkel magasabb lehet, mint amire számított. Ennek oka az Azure-ban az adatbázisok működésének módja. On-prem rendszerben Ön ahhoz volt hozzászokva, hogy több adatbázis osztozik egyetlen kiszolgáló korlátozott erőforrásain. Az Azure SQL esetében minden egyes adatbázisnak van egy lefoglalt erőforrásmennyisége, amelyért akkor is fizetnie kell, ha az adatbázis üresen áll. Ez a modell nagyszerű, ha több adatbázissal rendelkezik, amelyek kihasználtsága egyenletes és kiszámítható. Ha azonban nagyszámú, szaggatott használati mintázatú adatbázissal rendelkezik, akkor az árcédulát jelentősen kevésbé találhatja vonzónak. Így két lehetőség marad:

• Egy nagyobb, drágább adatbázisszintet használjon a csúcsidőszaki adatbázis-használat kezelésére
• Egy alacsonyabb szint használatával költséget takaríthat meg, a csúcsidőszaki teljesítmény rovására

Az Azure korai alkalmazói az erőforrások adatbázisok közötti megosztásához kénytelenek voltak saját virtuális gépeket létrehozni és karbantartani a telepített SQL Serverrel, és lényegében azokat a feltételeket replikálni, amelyek mellett a saját vagy egy privát adatközpontban futottak. Bár ez a módszer jól működött, nem tette lehetővé a hozzáférést az Azure SQL által kínált összes nagyszerű funkcióhoz, mint például:

• Beépített magas rendelkezésre állás (nem szükséges a replikáció konfigurálása)
• Active geo-replikáció
• Point-in-time restore

Ezeket a funkciókat nem triviális önállóan telepíteni, és a karbantartásuk is kihívást jelenthet.

Jobb: Kezelt példányok

AzAzure az SQL-adatbázis-szolgáltatások egy újabb szintjét kínálja, az úgynevezett kezelt példányokat, amelyek lényegében kezelt virtuális gépek, amelyek egy SQL Server-nek adnak otthont. A menedzselt példányok nem biztosítják az Azure SQL egyadatbázisú szolgáltatásaiba beépített összes funkciót, de nem kell kezelnie az operációs rendszert vagy az SQL Server telepítését sem. Alapvetően egy olyan virtuális gépet kap, amelynek konfigurációját és karbantartását nagyrészt Ön helyett kezelik.

A legjobb: SQL elasztikus poolok

Az Azure-ban azonban van egy másik lehetőség is ennek a gyakori forgatókönyvnek a kezelésére: Az SQL elasztikus poolok. Ahelyett, hogy egy bizonyos mennyiségű erőforrást foglalna le egyetlen adatbázis számára, az SQL elasztikus poolok segítségével számos erőforrást foglalhat le és oszthat meg több száz adatbázis között. Ez a modell rendelkezik az Azure SQL összes előnyével, és lehetővé teszi, hogy több adatbázisban megfelelően kezelje a szikár felhasználási mintákat. Az elasztikus poolok hihetetlenül népszerűnek bizonyultak, és ideális megoldást jelentenek a több bérlővel rendelkező alkalmazások számára.

Az elasztikus poolok használatakor azonban óvatosan kell eljárni. Ha egy vagy több olyan adatbázisa van, amelynek használata jelentősen nagyobb, mint a többi adatbázisé a poolban, akkor előfordulhat, hogy kénytelen lesz egy drágább elasztikus pool szint megvásárlására, hogy kezelni tudja a használati csúcsokat. Bizonyos esetekben valójában költséghatékonyabb lehet ezeket a nagy kihasználtságú adatbázisokat egyetlen adatbázis-ajánlatokra szétválasztani (kivenni őket a poolból), és a fennmaradó alacsonyabb kihasználtságú adatbázisok számára egy kisebb elasztikus pool-szintet fizetni. Jó ökölszabály, ha az adatbázisok DTU-használatát nézzük: ha egy adatbázis a rugalmas pool DTU-inak 40%-át vagy annál többet használ egy adott időpontban, akkor költségmegtakarítást érhetünk el, ha kivesszük a poolból, majd az említett poolt egy kevésbé drága szintre csökkentjük.

Az adatbázis-használati minták azonosításához – mint mindig – az Azure-portálon tájékozódhat.

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.