Azure Governance – OLDŘICH ŠRUBAŘ

Azure Governance díl III. – Cost Management

Dnešní v pořadí třetí disciplína, jak už sám název napovídá, se bude zabývat sledováním nákladů a toho, jak je důležité vnímat za co se v Azure spotřebovávají finanční prostředky. Na mém blogu najdete samozřejmě i dvě předchozí disciplíny – Resource Consistency a Security Baseline. Pokud vás téma Azure Governance zajímá v celkovém pojetí, doporučuji nejprve přečtení předchozích článků, ať vám vše do sebe hezky zapadne.

Správa nákladů je prakticky tou nejdiskutovanější disciplínou. Není se čemu divit, když jde o peníze, a navíc ty firemní, je nutné se zajímat za co se utrácí a jestli je možné někde ušetřit. Nejčastější otázka, která padne na většině prvních schůzek se zákazníkem: „Kolik to v tom Azure bude všechno stát?“ Odpověď většinou přichází vzápětí – záleží co všechno chce firma v Azure provozovat:

Jaké Azure služby se budou využívat? Co chce zákazník, aby v cloudu běželo?
Bude se využívat IaaS, PaaS nebo SaaS?
Může zákazník využít Azure Hybrid licence? – Jde o přenesení licencí pro Windows Server a SQL server z on-premise prostředí v případě aktivního programu Software Assurance.
Má zákazník v plánu být v Azure delší dobu nebo napořád? – V tom případě je rozumné využít možnost rezervovaných instancí služeb.

V disciplíně Cost Management je důležité se zaměřit na náklady z business pohledu společnosti, na odhalení a definici rizik, které jsou s tím spojené. Správa nákladů v tradičním on-premise světě je založena na životním cyklu zařízení v datacentrech, samotných serverů a problémech s údržbou systémů. Tyto náklady jsou předvídatelné, je možné s nimi plánovat a zpřesnit tak, aby odpovídaly ročním výdajovým rozpočtům. U cloudových řešení mnoho společností spoléhá na reaktivní přístup ke správě nákladů. To se může projevit tím, že si předplatí nebo se zavážou k určité spotřebě cloudových služeb. Tento model předpokládá maximální možnou míru slev na základě obchodních plánů a spotřeby kreditu u konkrétního dodavatele cloudu. Díky tomu, může mít společnost pocit, že proaktivně plánuje nákladový cyklus. Není tomu tak, tento pocit se může stát realitou pouze tehdy, pokud bude firma implementovat vyspělou disciplínu řízení nákladů. V podstatě jde o to, že cloudové služby nabízejí samoobslužné portály (Azure portál), které dříve u on-premise řešení neexistovaly. Díky těmto novým možnostem se dokáže společnost lépe adaptovat na nové technologie, být více agilní a méně restriktivní. Na druhou stranu to ale také přináší určitou větší zodpovědnost na straně uživatelů. Pokud si totiž nehlídají, jaké služby a za jakou cenu v cloudu nasazují, může rychle dojít k překročení nastaveného finančního limitu. Podobně tomu může být i při změně firemních plánů, které ovlivní množství nasazování zdrojů a může tak dojít k nenaplnění očekávané cloudové spotřeby, která byla předplacena.

Rizika spojená s se správnou nákladů se budou mezi společnostmi lišit, nicméně nejčastější společná rizika jsou:

Kontrola budgetu – bez kontroly limitu výdajů se může částka za náklady v cloudu dostat k astronomickým hodnotám.

Řešení: Nastavení budget limitů v Azure Cost Management + Billing.

Utilizace – většinou jde o nevyužívání zdrojů dle jejich kapacity nebo předkoupení zbytečného množství zdrojů, které pak nejsou stejně využívány.

Řešení: Sledování využívání zdrojů pomocí Azure Monitor nebo použití auto-scalingu.

Výdajové anomálie – nečekaně objevující se vysoké výdaje mohou být důsledkem špatného nastavení nebo nesprávného využívání služby.

Řešení: Nastavení alertů na Budget limit, které vás informují o překročení limitní částky.

Předimenzované zdroje – při nasazení zdrojů v Azure se může stát, že počáteční konfigurace služby/zdroje převyšuje nároky na běžící aplikaci nebo virtuální stroj. Tyto přebytky mohou tvořit značnou část měsíčních nákladů.

Řešení: Sledování využívání zdrojů v Azure Monitor a v případě nevyužívané kapacity snížení SKU služby.

Jak bylo zvykem v předešlých disciplínách, tak i zde v Cost Management disciplíně je potřeba sledovat metriky, díky kterým jsme schopni identifikovat rizika zmíněná výše. Níže uvedené metriky jsou ty nejdůležitější, které bychom měli sledovat.

Metrika	Popis
Roční výdaje	Celkové roční náklady na služby provozované v cloudu.
Měsíční náklady	Celkové měsíční náklady na služby provozované v cloudu.
Odhad nákladů versus opravdové náklady	Poměr vykazující rozdíl mezi odhadovanými náklady a skutečnou spotřebou.
Míra adopce nákladů	Rozdíl v procentech nákladů, které se liší měsíc od měsíce. Zda lze sledovat nárůst nebo pokles v nákladech.
Akumulované náklady	Celkové nahromaděné denní náklady počínaje začátkem měsíce.
Nákladové trendy	Porovnání nákladových trendů oproti stanovenému limitu. Sledování nákladů v čase, tzv. spending peeks – období kdy jsou náklady nejvyšší.

Pokud se v rámci analýzy podařilo úspěšně identifikovat nákladové metriky, tak je to pouze první krok k úspěchu. Další krokem by mělo být nastavení tolerančních indikátorů. Jde o to, že se musí definovat určitá hranice, která při překročení vyvolá reakci, například:

Metrika – Sledování měsíčních nákladů.

Toleranční indikátor – Limit měsíčních nákladů – Společnost si může dovolit náklady na cloudový provoz ve výši 150 000 kč měsíčně.

Akce při překročení stanoveného limitu – Pokud společnost identifikovala vyšší měsíční náklady, je potřeba udělat jejich analýzu (určitá investice do disciplíny Cost Management). To znamená zjistit za jaké služby se nejvíce utrácí, kontaktovat vlastníky daných zdrojů a analyzovat jejich potřeby. Zdali opravdu nutně potřebují například další virtuální stroj, který stojí 10 000 kč měsíčně.

Tento plán by se měl definovat pro každou metriku, kterou si společnost stanovila. Díky tomu bude zajištěn plynulý proces, který ačkoli se to nezdá bude zvyšovat úroveň této implementované disciplíny ve společnosti.

Důležitou součástí jsou cloudové nástroje nebo služby, které pomáhají při sledování, nastavování nebo analýze stanovených cílů pro každou disciplínu. Jinak tomu není ani v Cost Management disciplíně, kde pomáhají následující nástroje:

Doporučené techniky pro optimalizaci nákladů v Azure najdete v mém článku – Jak optimalizovat Azure infrastrukturu?

Na obrázku níže je praktická ukázka, jak může vypadat nastavení budget limitu s několika limity upozornění na výši spotřebovaného kreditu. Po každém překročení stanoveného upozornění přijde zpráva na nastavenou emailovou adresu. Lze vidět i automatický budoucí výpočet nákladů, pokud by trend spotřeby kreditu pokračoval rychlostí jako ke konci měsíce.

V příštím článku této série se můžete těšit na předposlední disciplínu Azure Governance a tou je Identity Baseline. Zjistíte, jak se chovat k firemním identitám v cloudu, jaká hrozí rizika a opět jaké nástroje mohou pomoci s adaptací této disciplíny.

Zdroj: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/cost-management/

Published by Oldřich Šrubař on 14/03/2022 | Permalink

Orphaned resources – cleanup your cloud!

Many of you are using Azure every day, have you ever stopped and thought about to make a cleanup of your cloud environment? If not, you should do that because there is many reasons behind why to do this. I like Azure Governance approaches and one of them is cutting off the cost for cloud service – understand that as cost optimization 😊 and make infrastructure and resources well-arranged. When you often deploy and remove resources for testing or development it can happen that some parts of resources will stay in your environment alone – so called orphans. As a nice example is deployment of virtual machine in Azure. Basically virtual machine needs resource group and virtual network where it will be deployed, then as a core parts NIC interface, sometimes public IP, definitely some managed disks and network security group. Quite lot of resources but needed ones!

What happens when you just remove VM from the portal? Mostly virtual machine itself is removed but the rest like NIC interface, public IP, managed disk stays in your subscription:

The fact is that you still pay for some of these resources – managed disks, public IPs and you definitely don’t want to pay for this! The rest of resources is for no cost but you also don’t want to have mess in growing environment, right?

To have a good overview of such “orphaned” resources I am using workbook which I created with few simple Kusto queries. It will tell me which resources are left in environment alone and I can think about their deletion:

Queries which I used in this workbook:

DISKs

Resources
| where type has "microsoft.compute/disks"
| extend diskState = tostring(properties.diskState)
| where managedBy == ""
or diskState == 'Unattached'
| project id, diskState, resourceGroup, location, subscriptionId

NICs

Resources
| where type has "microsoft.network/networkinterfaces"
| where properties !has 'privateLinkConnectionProperties'
| where properties !has 'virtualmachine'
| project id, resourceGroup, location, subscriptionId, properties.macAddress

NSGs

Resources
| where type =~ 'microsoft.network/networksecuritygroups' and isnull(properties.networkInterfaces) and isnull(properties.subnets)
| project Resource=id, resourceGroup, subscriptionId, location

Static PIPs

resources
| where type has "microsoft.network/publicipaddresses"
| where properties.publicIPAllocationMethod == "Static"
| where properties !has "ipConfiguration"
| project id, name, subscriptionId, location, resourceGroup

Dynamic PIPs

resources
| where type has "microsoft.network/publicipaddresses"
| where properties.publicIPAllocationMethod == "Dynamic"
| where properties !has "ipConfiguration"
| project id, name, subscriptionId, location, resourceGroup

You can find template for this workbook on my Github. You can import it or just copy/paste code when creating new Template Specs in Azure:

If you want to extend this workbook with your own Kusto queries for another resources which you would like to monitor if they left alone, then just simply edit workbook in Azure monitor and let me know what to add eventually in comments on my Github so I can add it directly to template.

There are of course other options how to automatically remove these leftovers and one of them is to check the options for auto-delete for disks, NIC, public IP when you are creating VM in Azure portal:

Another option should be adding the parameters into ARM templates if you deploy machines via DevOps or by TerraForm and other automatization tools.

Hopefully this article will help some of you to reduce some costs and make your environment better well-arranged for easy management.

Published by Oldřich Šrubař on 21/02/2022 | Permalink

Azure Governance díl II. – Security Baseline

V předchozím článku jsem detailněji rozebral disciplínu Resource Consistency, na kterou bude dnes navazovat další z celkem pěti disciplín Azure Governance a tou je konkrétně disciplína Security Baseline.

Pokud bychom chtěli převést do češtiny tento anglický název – Security Baseline, tak se budeme bavit o základních bezpečnostních opatřeních z pohledu IT v cloudovém prostředí. Bezpečnost je dnes základní komponentou každého IT oddělení, které má svou část nebo celou infrastrukturu v cloudu. Mnoho firem je regulováno z pohledu ochrany citlivých dat, což je při zvažování přechodu do cloudu jedna z hlavních priorit. Pro týmy kyberbezpečnosti musí být identifikace potencionálních hrozeb v cloudovém prostředí, stabilizace procesů a procedur na prvním místě v jejich pracovním žebříčku. V praktickém pojetí se při provádění Security Baseline disciplíny jedná zejména o definování a automatické vynucování základních bezpečnostních nastavení v cílovém prostředí tak, aby odpovídala bezpečnostní politice pro celé prostředí. Důležitou částí v této disciplíně je seznámení se s interními bezpečnostními směrnicemi pro IT a zákonným rámcem, ve kterém se zákazník musí pohybovat. Součástí je také sběr relevantních požadavků, které chce zákazník technicky promítnout do cloudového prostředí. Na základě těchto požadavků jsou definovány bezpečnostní politiky, standardy, šablony pro nasazení a další nastavení v rámci Azure, které budou auditovat a případně vynucovat specifikovaná nastavení.

Stejně jako při řešení disciplíny Resource Consistency se musíme i u Security Baseline zaměřit na rizika spojené s IT službami a firemního pohledu. U bezpečnosti nám jde především o ochranu dat, jejich klasifikaci, čerstvé bezpečnostní aktualizace a ochranu proti útokům. Všechny tyto aspekty lze sledovat v následujících ukázkových metrikách, které poskytnou lepší přehled o tom, čím je důležité se v této disciplíně zabývat. V podstatě se dá říct, že čím více vaše organizace v cloudu poroste, tím je potřeba se více zabývat bezpečnostními pravidly a sofistikovanějšími způsoby, jak tyto pravidla dodržovat, sledovat a případně vynucovat.

Metrika	Popis
Klasifikace dat	Množství dat nebo služeb, které jsou uloženy v cloudu a nemají žádnou klasifikaci vzhledem k firemním politikám o soukromí, dodržování zásad nebo standardům, které by měly dopad na podnikání.
Úložiště s citlivými údaji	Počet koncových bodů úložišť nebo databází, které obsahují citlivá data a měla by být chráněna.
Úložiště s nešifrovanými daty	Počet úložišť s citlivými daty, která nejsou šifrována.
Rozsah případného útoku	Jaké množství dat, služeb a aplikací bude hostováno v cloudu. Kolik procent těchto zdrojů s daty jsou klasifikována jako „citlivé“. Kolik procent aplikací a služeb jsou kriticky důležité.
Standardy zabezpečení	Množství bezpečnostních standardů definovaných bezpečnostním týmem.
Zabezpečené zdroje	Množství nasazených zdrojů, které jsou chráněny bezpečnostními standardy.
Přehled dodržování zásad (Compliance)	Poměr zdrojů, které jsou ve shodě s bezpečnostními zásadami.
Útoky dle vážnosti	Jaké množství koordinovaných pokusů o přerušení služeb (DDoS) bylo zaznamenáno. Jaká byla jejich velikost a vážnost?
Ochrana proti Malware	Procento nasazených virtuálních strojů, které mají všechny vyžadované způsoby ochrany – anti-malware, firewall nebo jiný nainstalovaný software zajišťující ochranu.
Čerstvost aktualizací	Doba, která uplynula od poslední aktualizace operačního systému nebo jiného nainstalovaného software.
Bezpečnostní doporučení	Počet bezpečnostních doporučení, které pomohou vyřešit vynucené standardy na nasazených zdrojích seřazených dle vážnosti.

Samotné definování zásad organizace není účinné, pokud je nelze automaticky vynucovat. Klíčovým aspektem plánování jakékoli migrace do cloudu je určení toho, jak nejlépe zkombinovat nástroje poskytované cloudovou platformou s vašimi stávajícími IT procesy a maximalizovat tak dodržování zásad napříč celou cloudovou infrastrukturou. Pro jedinou subskripci a základní nasazení zdrojů může být využito předem připravených funkcí, které nativně nabízí samotný Azure portál. Nastavení jednotnosti vychází ze samotného Cloud Adoption Frameworku, který pomáhá budovat základní stupeň dodržování zásad bez jakýchkoliv vstupních investic do Azure Governance. Funkce, které mohou být využity v rámci Azure portálu:

Šablony nasazení – možnost standardizované struktury a nastavení jednotlivých konfigurací.
Tagování a jmenný standard – pomůže organizovat zdroje, které jsou snadno identifikovatelné.
Správa přenosu a síťové omezení – možnost implementace pomocí Software Defined Networking.
RBAC – možnost zabezpečení a izolace zdrojů jen pro určité skupiny či uživatele.

Při rozhodování, kdy nasadit automatické vynucování bezpečnostních pravidel nebo pravidla nechat na samotných uživatelích závisí na velikosti firmy, počtu subskripcí a také jak moc máme schopné uživatele. Pomocníkem může být následující rozhodovací průvodce podobně jako u Resource Consistency disciplíny:

Na první pohled je viditelné, že čím je organizace větší, tím více je potřeba automatizovat aplikování bezpečnostních zásad a jejich vynucování. Přichází s tím ruku v ruce i větší zodpovědnost za cloudové zdroje a jejich množství. Proto je potřeba myslet na nutnost mít dobré monitorovací nástroje a využívat je co nejefektivněji.

Monitorování dodržování zásad (Compliance)

V reálném světe nelze spoléhat na to, že po nasazení politik a pravidel bude vše krásně zelené a budeme spokojení s tím, jak jsme nasadili Security Baseline. Důležité je samozřejmě sledovat, zdali se vše,, co jsme definovali, dodržuje, případně jaké zdroje dané politiky se nedodržují. Azure poskytuje nativní využívání notifikací, které mohou vlastníky zdrojů upozorňovat na nedodržování zásad a jejich nápravu. Součástí monitoringu by mělo být logování akcí a měsíční reportování s přehledem zdrojů a jejich stav splňující či nesplňující nastavené politiky. U rozsáhlejších prostředí může s tímto pomoci Azure Security Center, které poskytuje výše uvedené funkce.

Vynucování politik

Z pohledu vynucování politik a pravidel existují v podstatě dva způsoby, jak docílit cíleného efektu. První způsob je proaktivní, kdy jsme už například při vytváření zdroje omezeni určitými pravidly. Například můžeme pomocí Azure Policy definovat pouze povolené SKU velikosti virtuálních strojů, čímž zamezíme vytváření zbytečně drahých strojů, které nejsou potřeba. Druhý způsob je reaktivní a jde o nastavení politik, které budou sloužit pouze jako sledovače. Na základě jejich reportování uvidíme, které zdroje nesplňují chtěná nastavení, Ty pak můžeme vynucovat jinými způsoby nebo automatizovaně pomocí jiných politik či Azure Blueprints. Azure Blueprints nám pomáhají nasazovat a aktualizovat cloudová prostředí způsobem, který lze opakovat. To je zajištěno díky možnosti přidávat do blueprintů artefakty, jako jsou šablony Azure Resource Manager, řízení přístupu na základě RBAC rolí a Azure politiky. Azure Blueprints jsou skvělý způsob, jak zrychlit nasazování kompatibilních prostředí.

Disciplína Security Baseline je nikdy nekončící běh a měl by na to myslet každý IT architekt nebo administrátor. Jde o to, že se neustále objevují nové typy útoků a společnosti by se měly adaptovat a měnit své návyky, aby jejich prostředí bylo dostatečně zabezpečeno. Postupem času každá firma aktualizuje svá vnitrofiremní pravidla, přičemž jejich změna by se měla promítnout i v IT oblasti a nasazení politik.

V příštím článku této pětidílné série se podíváme na disciplínu Cost Management, kde vysvětlím důležitost sledování měsíčních nákladů na provoz cloudu a jaké nástroje nám pomohou s jejich sledováním a reportováním.

Published by Oldřich Šrubař on 13/12/2021 | Permalink

Azure Governance díl I. – Resource Consistency

Azure Governance je rozsáhlou metodologií, která říká, jak správně řídit Azure prostředí. Nejde jen o samotné zdroje, ale o promítnutí firemních politik a procesů do praxe a technické konfigurace. Správné řízení Azure cloudu se skládá z celkem pěti hlavních disciplín. Jednotlivé disciplíny budou postupně hlouběji rozebírány v jednotlivých článcích.

V dnešním článku si rozebereme disciplínu Resource Consistency – což je v překladu konzistence zdrojů, řekněme jakási jejich přehlednost a struktura. Touto disciplínou je dobré začít proto, že nám říká, jak začít budovat své Azure prostředí lépe, přehledně a strukturovaně. Nemusí se vyloženě jednat jen o budování nového prostředí, praktiky pro Resource Consistency se mohou aplikovat i do již vytvořených struktur. Jejich adopce bude však o něco složitější, než když se začíná na „zelené louce“. Přehlednost zdrojů a jejich konzistenci můžeme v Azure řídit pomocí několika nástrojů, které budou vynucovat některá nastavení automaticky a nedovolí tak nekontrolovatelné rozšiřování prostředí, které může být časem nepřehledné a měsíční faktury mohou být noční můrou všech účetních.

Resource Consistency se také zaměřuje na řešení rizik souvisejících se správou provozu cloudových služeb jak z pohledu IT, tak i z business pohledu. Součástí analýzy rizik je shromáždění dat souvisejících s operacemi, které se provádí na daných zdrojích. Díky tomu se dá zjistit, jak velkému riziku čelíte a jak moc je důležitá investice do této disciplíny. Každá organizace má různé provozní scénáře, nicméně níže uvedený seznam položek přináší hezký příklad toho, jaké metriky je potřeba sbírat a sledovat. Na základě těchto metrik můžeme vytvořit sledovací nebo automatizované mechanismy, které zajistí, že budou dodrženy nastavená pravidla a procesy.

Metrika	Popis
Cloudové zdroje	Celkový počet nasazených zdrojů v cloudu.
Neoznačené zdroje	Počet zdrojů, které nejsou označeny. Nemají žádné tagy pro účetnictví, dopadu na business nebo označení organizační struktury.
Nevyužité zdroje	Počet zdrojů, kde jejich RAM paměť, CPU nebo síťové vytížení neodpovídá jejich kapacitě a jsou většinou nevyužité.
Přetěžované zdroje	Počet zdrojů, kde jsou jejich kapacity RAM, CPU a sítě velmi často přetěžované.
Stáří zdroje	Čas, kdy byl zdroj vytvořen nebo změněn. Vhodné je uvést i datum, kdy už zdroj nebude potřeba a může být smazán (vývoj, testování, dema atd.).
Virtuální servery s kritickou kondicí	Počet VM, které nemají dobrou kondici a je potřebný zásah pro jejich opětovné uvedení do normálního provozu.
Upozornění dle vážnosti	Celkový počet upozornění na nasazeném zdroji v členění podle závažnosti.
Problém na síťový zařízeních	Počet zdrojů, které mají problém se síťovým připojením.
Problém se servisními koncovými body	Počet problémů s koncovými body externí sítě.
Incidenty služeb cloudového providera	Počet výpadků nebo problémů se sítí způsobených poskytovatelem služeb.
SLA	Sledování SLA, které může obsahovat, zda byly dodrženy podmínky ze strany Microsoftu, ale i tak podmínky, kterými se zavazujete u zákazníků nebo externích partnerů.
Dostupnost služby	Procenta, kdy byla služba skutečné dostupná v porovnání s očekávanou dostupností.
Čas pro obnovu (RTO)	Maximální akceptovatelný čas, kdy může být služba nebo aplikace nedostupná v případě poruchy.
Bod obnovy dat (RPO)	Míra času, ve které akceptujeme ztrátu dat při havárii. Například data uložená v jediné databázové instanci bez replikace s hodinovou zálohou znamená maximálně hodinovou ztrátu dat.
Průměrný čas pro obnovení (MTTR)	Průměrný čas potřebný pro obnovení služby po chybě.
Průměrný čas mezi incidenty (MTBF)	Průměrné určení času, kdy může služba nebo aplikace bezproblémově běžet mezi výpadky. Tato metrika nám může pomoci predikovat a určit, jak často bude služba nedostupná.
Stav zálohy	Stav a počet záloh, které byly úspěšně dokončeny. Případně synchronizovány bez problému.
Stav obnovení	Počet úspěšných operací obnovy služby nebo aplikace.

Pomůckou, která definuje nástroje a etapy jejich použití, je Resource Consistency rozhodovací průvodce, který popisuje následující obrázek:

Zdroj: Microsoft

Ve své podstatě nám říká, jak začít, kde pokračovat a jaké nástroje bychom měli použít. Rozhodujícími faktory, jestli v Azure Governance pokračovat v pojetí konzistence zdrojů závisí na velikosti společnosti a množstvím zdrojů, které v cloudu má. Prakticky nemá smysl řešit hierarchii subskripcí, když máme jen jednu, případně dvě. K tomu je samozřejmě navázaná komplexnost samotného prostředí a také to, jestli jsme nějakým způsobem do řízení zdrojů v cloudu nuceni vnějšími nařízeními, certifikacemi nebo normami. Při větším množství subskripcí nám pak mohou pomoci vytvořit smysluplnou strukturu Azure Management Groups.

Zdroj: Microsoft

Podobnou pomůcku jako u rozhodovacího průvodce pro konzistenci můžeme použít i pro „tagování“ (označování) zdrojů. Následující obrázek popisuje spojení tagů z IT a business pohledu.

Zdroj: Microsoft

Základní jmenná konvence nám říká, jak pojmenovávat zdroje – skvělou pomůckou je tento jmenný standard definovaný Microsoftem. Podle něj jsme již na první pohled schopni určit typ zdroje a k čemu pravděpodobně slouží.

Označení funkce zdroje nám říká, k čemu využíváme ten nebo onen virtuální server – app, data, archive, automation atd.

Klasifikace pomůže rozeznat, jestli jde o privátní, veřejný nebo přísné tajný zdroj, případně klasifikaci SLA, důležitost a jiné.

Účetní označení slouží k lepšímu sledování výdajů jednotlivých zdrojů a ke komu půjde příslušná faktura – může to být oddělení, název projektu, případně region.

Vlastník zdroje je velmi používaný tag, protože říká, na koho se obrátit v případě problémů se zdrojem nebo v případě jeho vysokých nákladů nebo při překročení času, po který měl být zdroj vytvořen.

Posledním označením zdroje je business pohled, který definuje hodnotu zdroje a pomůže při investičním rozhodování – např. business critical, revenue impact, business process a jiné. Tagy přináší opravdu neomezené a užitečné možnosti, je však zapotřebí jejich správná definice, která bude dávat smysl.

V příštím článku se podíváme na zoubek disciplíně Security Baseline.

Published by Oldřich Šrubař on 16/11/2021 | Permalink

Jaké nástroje lze použít pro řízení Azure prostředí?

Jestliže v cloudu teprve začínáte, určitě si lámete hlavu nad tím, co všechno a jakým způsobem budete muset řešit. Cloud je pro vás novou výzvou, se kterou by vám měl být schopen poradit váš dodavatel IT služeb. Pokud tomu tak není, jste odkázáni sami na sebe nebo případně můžete hledat pomoc u konzultantských společností, které vám přechod do cloudu usnadní. Pokud se s cloudem budete seznamovat sami, nabízíme vám popis většiny užitečných nástrojů, které vám mohou v Azure pomoci. Pokud se již v Azure cloudu pohybujete nějaký čas, bude tento článek pro vás menším opakováním. Opakování je matka moudrosti a možná narazíte na něco, co jste ještě nevyužili, neznali nebo nevyzkoušeli 😊. Všechny uvedené nástroje jsou součástí Azure Governance disciplín (Resource Consistency, Security Baseline, Identity Baseline, Cost Management a Deployment Acceleration), nicméně se s nimi můžete setkat i pokud tyto disciplíny vyloženě neřešíte. Postupně přejdu od těch nejsnadnějších, které nepotřebují žádnou implementaci a mohou se používat ihned, až po ty složitější, které už potřebují hlubší znalosti.

Azure Tags

Tagy přestavují základní nástroj, který poskytuje přehled o nasazených prostředcích. Jedná se o označení zdrojů různými tagy, které jsou pro vás důležité. Může se jednat o označení vlastníka, typu zdroje, jeho důležitosti nebo označení pod jaké spadá oddělení. Díky možnosti filtrování tagů máte pak skvělý přehled o prostředí a jeho nákladech.

Azure Management Groups

Slouží k hierarchickému uspořádání více subskripcí ve větších firmách, kde každé oddělení může mít teoreticky svou vlastní subskripci. Jejich využití se pak promítá do dalších nástrojů, kde jsme schopni například zacílit aplikaci politik právě na vybrané skupiny.

Způsob použití Azure management Groups

Azure Cost Management + Billing

Tento nástroj vám poskytuje kompletní přehled o nákladech ve vašem prostředí. Díky detailním přehledům a grafům, máte možnost zjistit co přesně vás stojí nejvíce peněz, nebo případně jiné nákladové anomálie. Cost Management + Billing má několik funkcí, které je vhodné využívat, a to zejména upozornění při překročení nastavených limitů na kredit s následným zasláním upozorněním na uvedený email. Skvělou pomůckou jsou také doporučení, které pomohou s optimalizací nákladů. V analýze nákladů si pak můžete jednotlivé položky filtrovat na základě tagů nebo sledovat trend jakým se budou náklady v budoucnu vyvíjet.

Ukázka přehledu nákladů

Azure RBAC (Role-based access control)

Řízení přístupu je jedna z klíčových oblastí správy cloudu. V Azure je řízení přístupu ve dvou úrovních – Azure AD a Azure zdroje. Obě úrovně mají předem definované role pro přidělování oprávnění, tyto role jsou pro každou úroveň jiné a s tím i jejich princip. U Azure zdrojů se využívá principu RBAC, kde platí vlastnost dědění oprávnění z vyšších úrovní hierarchie. To znamená, že pokud má někdo práva vlastníka na subskripci, tak je automaticky vlastníkem všech zdrojů v dané subskripci. Základem pro přiřazování rolí jsou: uživatel, role, rozsah. Vybereme daného uživatele, kterému přiřadíme roli na určitém rozsahu zdrojů (subskripce, skupina zdrojů, virtuální stroje, sítě atd.).

Princip přiřazování RBAC rolí

Zdroj: https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

Privileged Identity Management (PIM)

Služba Azure AD PIM umožňuje spravovat, řídit a monitorovat přístup k důležitým prostředkům ve vaší organizaci. Poskytuje časovou a schvalovací aktivaci rolí na cloudové zdroje, které jsou pod vaší správou. Zmírňuje se tím riziko přidělení práv špatné osobě nebo nadměrné či nechtěné přihlašování na váš zdroj. Zjednodušeně řečeno, když někdo potřebuje přístup nebo práva, tak si o ně musí říct a někdo to musí posoudit, zda je požadavek relevantní a schválit ho. Proces lze samozřejmě automatizovat a manuální schvalování si můžete nastavit jen pro role s nejvyšším oprávněním. Pro využívání této služby musíte mít licence pro Azure AD Premium P2 a Enterprise Mobility + Security (EMS) E5.

Azure Templates (ARM)

Jedná se o nástroj/službu, která umožňuje automatizované nasazení zdrojů. To se hodí zejména při časté změně infrastruktury nebo při opakovaném nasazování různých částí nebo celé aplikace. Případně pokud chcete implementovat infrastrukturu jako kód (IaaC) pro vaše Azure prostředí, tak jsou šablony Azure Resource Manager (ARM) tím pravým. Šablona je soubor JSON (JavaScript Object Notation), který definuje infrastrukturu a konfiguraci vašeho nasazení. Šablona používá deklarativní syntaxi, která umožňuje uvést, co chcete nasadit, aniž byste museli psát sekvenci programovacích příkazů k jejímu vytvoření. V šabloně určíte prostředky, které se mají nasadit a vlastnosti těchto prostředků. Pokud by vás tento typ automatizace zajímal více, můžete si projít detailního průvodce vaším první šablonou ZDE. Pokud jde o další nástroje pro automatické nasazování, tak je vhodné zmínit TerraForm, Ansible, Chef, Azure Automation, Azure CLI, Bash nebo Cloud Shell.

Azure Monitor

Azure Monitor maximalizuje dostupnost a výkon vašich aplikací a služeb tím, že poskytuje komplexní řešení pro shromažďování, analýzu a telemetrii dat z vašich cloudových nebo on-premise prostředí. Pomůže vám pochopit, jak aplikace fungují, proaktivně identifikuje problémy, které je ovlivňují a prostředky, na kterých závisí.

High-level přehled pro Azure Monitor

Zdroj: https://docs.microsoft.com/cs-cz/azure/azure-monitor/overview

Ve středu obrázku jsou dva základní typy úložiště dat, které Azure Monitor používá, což jsou metriky a logy. Vlevo jsou zdroje monitorovacích dat, která naplňují tato datová úložiště. Na pravé straně jsou různé funkce, které Azure Monitor provádí s těmito shromážděnými daty, jako je analýza, upozornění a streamování do externích systémů.

Azure Policy

Jedná se o nástroj, který pomáhá nastavovat a sledovat dodržování zásad společnosti. Může se jednat jak o bezpečnostní zásady nebo nastavení, které nám pomáhají udržet pořádek a přehlednost. Díky Azure Policy můžete jednotlivé konfigurace vynucovat nebo jen auditovat, což je velký pomocník v případě přípravy pro nějaký větší audit společnosti. Pokud bychom měli tento nástroj porovnat s on-premise nástrojem, tak se nejvíce blíží Group Policy v Active Directory nebo Desired State Configuration (DSC). V případě, že si vystačíte s předem definovanými politikami, tak nemusíte mít hlubší znalost ARM šablon a JSON syntaxe politik, pokud ne, tak se těmto nárokům nevyhnete.

Přehled o tom, jak jsou dodržovány nastavené politiky

Azure Blueprints

Umožňují definovat sadu prostředků (politiky, skupiny zdrojů, zdroje a přiřazení rolí), které lze opakovaně nasadit a tím zajistit dodržování standardů, šablon, bezpečnostních zásad a jiných požadavků organizace v rámci jednoho automatizačního nástroje. Využití je vhodné zejména tam, kde je potřeba rychle postavit kompletní infrastrukturu menších rozměrů včetně sady politik a integrovaných komponent jako je síťování. Příkladem může být prostředí pro testování nebo vývojový tým, přičemž bude toto prostředí po odvedené práci smazáno.

Jak fungují Azure Blueprints

Zdroj: https://francescomolfese.it/en/2020/02/azure-governance-panoramica-di-azure-blueprints/

Věřím, že výše uvedené nástroje pomohou vyřešit nejednu svízelnou situaci, kterou řešíte. Pokud byste se chtěli dozvědět více o jednotlivých nástrojích, tak doporučuji na našem blogu sledovat seriál Azure Governance, který se zabývá detailnějším popisem každé disciplíny včetně využívaných nástrojů.

Published by Oldřich Šrubař on 18/10/2021 | Permalink

5 TOP best practices v Azure Governance – 2. díl

Dnešní díl navazuje na předchozí článek 5 TOP best practices v Azure Governance – 1. díl, kde jsem rozebral vhodné praktiky z pohledu Azure Governance pro první dvě disciplíny – Cost Management a Resource Consistency. Dnes se zaměřím na zbývající tři disciplíny včetně rad a doporučení, které by měl následovat každý, kdo to s Microsoft Azure myslí vážně a chce mít své prostředí pod kontrolou, zabezpečené a za přijatelnou cenu.

Mějte dostatečné zabezpečení – Security Baseline

V dnešní době se musí bezpečnosti věnovat hodně času, přece jen jsou útoky poslední dobou sofistikovanější a častější než dříve. Na druhou stranu by nemělo panovat přesvědčení „Bezpečnost nadevše“, to by totiž mohlo způsobit složité a nepříjemné používání systémů pro koncové uživatele včetně IT správců, a to nikdo nechce. Je tedy rozumné najít kompromis mezi použitelností systému a dobrým zabezpečením. Bezpečnost v Azure lze rozdělit na základní tři stavební kameny:

Ochrana dat
Zabezpečení infrastruktury před hackerskými útoky
Aplikování a dodržování bezpečnostních zásad

Ochranu dat zajistíme dostatečným šifrováním komunikace v síti, úložišť, VM disků, uchováváním tajemství v Azure KeyVault a samozřejmě dostatečným zálohováním. Co se týče hackerských útoků, tak je opět celá řada nástrojů, díky kterým si můžeme prostředí více zabezpečit. Azure jako takový už nativně poskytuje mnoho vrstev (Network Security Groups, Basic DDoS Protection, fyzické zabezpečení datacenter, auditování a další), které chrání vaše zdroje, a navíc k nim můžete přidat například Standard Protection DDoS plány pro veřejné IP adresy, které detekují útok a ihned vás o něm informují včetně reportingu, Azure Firewall, Azure Site Recovery, Traffic Manager, Application proxy a spoustu dalších.

Pokud jde o vynucování bezpečnostních zásad v Azure, tak s tím velmi pomohou Azure Policy. Firma má nějaké vnitrofiremní bezpečnostní politiky pro IT a ty je potřeba promítnout i do cloudového prostředí. Azure Policy využívá pro definici politik a nastavení JSON formát. Přímo v Azure portálu je již připravených několik šablon, které lze ihned aplikovat. Je potřeba si však ujasnit, zda chceme dodržování politik jen sledovat nebo je rovnou i vynucovat – lze automaticky nebo manuálně.

Jak vypadá přehled politik a jejich dodržování můžete vidět na obrázku níže:

Doporučovanou službou je také Azure Security Center, která poskytuje kompletní přehled stavu zabezpečení. Díky tomu máte vše na jednom místě, včetně doporučených postupů, jak zabezpečení zlepšit.

Skóre zabezpečení na Security Center řídicím panelu

Zdroj: Sledování skóre zabezpečení v Azure Security Center | Microsoft Docs

Sledujte, kdo má jaká práva – Identity Baseline

Častým nešvarem v nekontrolovaných prostředích je zmatek při udělování práv a přehled o tom kdo disponuje vlastnickými právy. Často se setkáváme s tím, že práva vlastníka (což jsou ty nejvyšší, pokud nebereme v potaz administrátora tenantu 😊) jsou přidělovány velmi často a také zbytečně. Jde o to, že se nikomu nechce zamýšlet nad tím, jaká práva daný uživatel vůbec potřebuje, a raději mu dá všechny, než aby ho později uživatel zase obtěžoval, že mu něco nefunguje. Azure má vynikající Role-Based Access Model – RBAC, který má již předdefinované role s určitými právy, a tak odpadá skutečnost, že byste se musel jako IT správce topit v detailním rozboru práv. Rolí existuje opravdu mnoho a ve většině případů si s nimi vystačíte. Existuje i možnost vytvoření vlastních rolí, což ale moc osobně nedoporučuji, protože se špatně hlídají Pokud si každý začne vytvářet vlastní role dle potřeby, tak v rolích začne být opět zmatek. Doporučením je používat princip least-privilege u kritických zdrojů vaší infrastruktury.

Least-Privilege – jde o koncept a praktiky, které udělují uživatelům, servisním účtům a procesům pouze taková práva, která jsou nutná pro vykonávání rutinních nebo legitimovaných operací.

Součástí identit je určitě i jejich zabezpečení. Ukradená identita dokáže nadělat spoustu škody, a to opravdu nikdo nechce. Proto je vhodné využívat služby typu Multi-Factor Authentication, Conditional Access, Single Sign-On pro přihlašování (Azure AD password hash synchronization nebo Azure AD Pass-through Authentication), Privileged Identity Management, který se používá na straně Azure a Privileged Access Management, který se využívá v lokálních AD.

Privileged Identity Management & Privileged Access Managementposkytují časovou a schvalovací aktivaci rolí na zdroje, které jsou pod vaší správou. Zmírňuje se tím riziko přidělení práv špatné osobě nebo nadměrné či nechtěné přihlašování na váš zdroj. Zjednodušeně řečeno, když někdo potřebuje přístup nebo práva, tak si o ně musí říct a někdo to musí posoudit, zda je požadavek relevantní a schválit ho.

Poskytují just-in-time privilegovaný přístup do Azure AD nebo Azure zdrojům, případně on-premise AD (PAM).
Dokážou přiřadit určitý čas, kdy bude zdroj přístupný.
Vyžádání schválení při přiřazení privilegovaných práv.
Dokážou vynutit MFA pro aktivaci jakékoli role na vašem zdroji.
Poskytují notifikace při přidělení práv, možnost využít i vynucení informace při aktivaci rolí.
Provádí kontroly přidělených práv, zdali jsou stále potřeba.
Možnost stažení audit historie.

Automatizujte ve váš prospěch – Deployment Acceleration

Už ze samotného principu cloudu nám jde o to co nejvíce automatizovat. Šetříme tím čas a peníze, což jsou dva podstatné faktory. Automatizovat se má tam, kde to dává smysl a není to spíše na škodu, protože úplně všechno automatizovat nelze (zatím😊). V Azure nám jde především o automatizaci při nasazování zdrojů, aplikací nebo kódu.

Automatizace nasazení zdrojů – existuje několik možností od nativních až po ty více složité. Nejjednodušším příkladem je využívání Azure Resource Manager šablon (ARM templates). Principem automatizace v tomto případě může být nejprve manuální nasazení zdroje a poté vyexportování šablony do knihovny. Jakmile máme šablonu připravenou dle našich představ, tak opětovné nasazení stejného zdroje, byť i s jinými parametry může být mnohem rychlejší než předtím.

Poměrně novou Azure službou, která je zatím stále v public preview jsou Azure Blueprints – slouží k rychlému vybudování předem definovaného prostředí, které je v souladu s firemními politikami. V podstatě si předem připravíte šablonu s veškerými zdroji, které chcete nasadit a k tomu přidáte předem vytvořené politiky, které mohou řešit dodržování bezpečnostních zásad nebo principy řízení zdrojů. Díky tomu dokážete vytvořit v Azure celé prostředí během několika kliknutí.

S automatizací u vývoje dokáže pomoct služba Azure DevOps, která poskytuje vývojářské služby pro podporu plánování práce, kolaboraci na vývoji kódu a kompilaci včetně nasazování aplikací. Azure DevOps je cloudová verze tohoto pracovního prostoru, pro on-premise se využívá Azure DevOps Server, který byl dříve znám jako Visual Studio Team Foundation Server (TFS).

Azure DevOps poskytuje integrované funkce, které jsou klasicky přístupné přes webový prohlížeč nebo IDE klienta:

Azure Repos poskytuje Git repositáře nebo Team Foundation Version Control (TFVC) pro kontrolu verzí kódu.
Azure Pipelines poskytuje „build a release“ služby pro podporu kontinuální integrace a doručení aplikací.
Azure Boards obsahuje balík agilních nástrojů pro podporu plánování, sledování práce, chyb v kódu a dalších problémů pomocí Kanban a Scrum metod.
Azure Test Plans poskytují několik nástrojů pro otestování vašich aplikací včetně manuálního/průzkumného testování a kontinuálního testování.
Azure Artifacts dovoluje týmům sdílet Maveny, npm a NuGet balíčky z veřejných a soukromých zdrojů, přičemž integruje sdílení balíčků do vaší CI/CD pipeliny.

Níže je přehled nejběžnějších automatizačních nástrojů pro dané oblasti:

Automatická konfigurace VM
- Ansible, Chef, Puppet a Azure Resource Manager šablony
- Další specifické VM nástroje pro přizpůsobení jako např. cloud-init pro Linux VM nebo PowerShell Desired State Configuration (DSC) a Azure Custom Script Extension pro všechny Azure VM.
Automatizace infrastruktury
- Nástroj Packer pro automatické vytváření vlastních VM imagí
- TerraForm pro automatické nasazení celé infrastruktury nebo její části.
- Azure Automation, který vykonává automatické akce skrze Azure nebo on-premise infrastrukturu.
Automatizace pro nasazení aplikací a jejich doručení
- Azure DevOps nebo Jenkins

Published by Oldřich Šrubař on 06/10/2021 | Permalink

5 TOP best practices v Azure Governance – 1. díl

V dnešním článku, který je rozdělen na dva díly uvedu několik užitečných praktik, které pomohou udržet vaše Azure prostředí přehledné a cenově efektivní. Uvedené praktiky spadají do oblasti Azure Governance, které se na našem blogu věnujeme v několika směrech.

Úvodem je vhodné říct, že zavádění a vyladění Azure Governance k dokonalé spokojenosti je běh na delší trať. Je potřeba pochopit, že pokud nikdo během dvou let, co vaše společnost využívá Azure služeb neřešil řízení zdrojů, pořádné zabezpečení, aplikování politik nebo správu nákladů, tak se to určitě nezmění o 180° k lepšímu během několika dnů nebo týdnů. Větší společnosti stráví nad Azure Governance i několik let, než je opravdu všechno nastaveno, tak jak má být. Navíc během času, ve kterém se firma vyvíjí, tak by se mělo vyvíjet i samotné řízení cloudu a přizpůsobovat se novým změnám ve společnosti.

V prvopočátku Azure Governance je na místě zvážit důvody proč ji chceme řešit, za jakým účelem a co je cílem. Nejprve doporučuji stanovovat menší cíle na kratší období, kdy můžete velmi dobře sledovat jejich průběh a plnění. Pokud jde vše zdárnou cestou, tak se mohou volit větší cíle na delší období s celofiremním dopadem. V tomto článku popisuji pět nejlepších praktik, se kterými můžete v Azure začít kdykoli. Jsou to ty nejzákladnější pravidla, která při dodržování uleví firemní peněžence a zpřehlední celé vaše Azure prostředí.

Sledujte kolik utrácíte – Cost Management

V cloudu jde velmi často o finanční prostředky, které jsou k dispozici a mohou být proinvestovány. Náklady na cloudové služby jako takové jsou brány jako Opex – operativní náklady. Většinou neplatíte nic předem, platíte pouze za to, co spotřebováváte. Zní to jednoduše, ale realita je někdy jiná. Bez dozoru totiž stěží uhlídáte Frantu z IT nebo Lenku z vývoje, kteří si nasadí tu nejdražší variantu databázové služby, třeba jen proto, že si ji chtěli vyzkoušet, ale zapomněli ji smazat. Taková malá nepozornost může vyjít na několik desítek tisíc korun měsíčně, a přitom zcela zbytečně. V Cost Managementu jde o odhalení rizik spojených se zbytečnými výdaji za infrastrukturu v Azure dříve, než nastanou. Mezi nejčastěji opomenuté aspekty týkající se běžící infrastruktury v Azure patří:

Kontrola budgetu – bez kontroly limitu výdajů se může částka za náklady v cloudu dostat k astronomickým hodnotám.

Rada: Nastavte si budget limity v Azure Cost Management + Billing.

Utilizace – většinou jde o nevyužívání zdrojů dle jejich kapacity nebo předkoupení zbytečného množství zdrojů, které pak nejsou stejně využívány.

Rada: Sledujte využívání zdrojů pomocí Azure Monitor nebo využijte auto scalingu.

Výdajové anomálie – nečekaně objevující se vysoké výdaje mohou být důsledkem špatného nastavení nebo nesprávného využívání služby.

Rada: Nastavte si Upozornění na Budget limitu, které vás informuje o překročení limitní částky.

Předimenzované zdroje – při nasazení zdrojů v Azure se může stát, že počáteční konfigurace služby/zdroje převyšuje nároky na běžící aplikaci nebo virtuální stroj. Tyto přebytky mohou tvořit značnou část měsíčních nákladů.

Rada: Sledujte využívání zdrojů v Azure Monitor a v případě nevyužívané kapacity snižte SKU služby.

Základním rozcestníkem při analýze výdajů bude nástroj Cost Analysis v Cost Management + Billing službě. Jde o přehledný dashboard, na které vidíte kolik aktuálně utrácíte, za co a jaký bude vývoj nákladů, pokud již v prostředí nic nepřibude. Ukázka, jak může takový dashboard vypadat je na obrázku níže.

Z pohledu těch nejlepších praktik bychom se na Cost management měli dívat ze dvou směrů – náklady na provoz a náklady při zřizování služby/zdroje. Je vhodné dodržovat jmenné konvence a využívat tagů, identifikovat správné velikosti zdrojů (např. virtuálních strojů), automatické vypínání neprodukčních a jiných virtuálních strojů, když nejsou zrovna potřeba, využívat správných parametrů při automatickém rozšiřování infrastruktury a nezapomínat na vyřazené stroje z provozu a jejich smazání. Tyto praktiky detailněji vysvětluje následující kapitola.

Udržujte přehled a pořádek – Resource Consistency

Pro správce Azure prostředí není nic horšího než nepřehledné a chaotické uspořádání zdrojů a služeb. Nejen že se tím navyšují náklady pro správu těchto zdrojů, ale často tato prostředí obsahují „věci“, které jsou už nevyužívané, zastaralé a zranitelné. Přitom stačí málo , aby to dávalo smysl. Začít se musí od začátku, takže je nejprve vhodné promyslet Azure hierarchii a způsob jakým se bude udržovat základní přehlednost celé infrastruktury. Hezký příkladem je obrázek níže.

Efektivní uspořádání prostředků Azure - Cloud Adoption Framework | Microsoft Docs

Už jen toto malé opatření dokáže efektivně zpřehlednit vaše prostředí. Pokud je společnost větší a má více oddělení, tak se to dá vyřešit jejich rozčleněním do dalších Management Groups. Výbornou praktikou je i rozdělování aplikačních celků do jednotlivých Resource Groups. Další základní kameny pro přehledné a učesané prostředí jsou:

Tagování – každý zdroj v Azure byl měl mít nastavené tagy, které specificky určují například vlastníka, datum vytvoření zdroje, oddělení, SLA, jeho důležitost, klasifikaci atd.
Automatické vypínání virtuálních strojů – proč by měly VM běžet, když nejsou využívané? Samozřejmě to nelze aplikovat v produkčních prostředích, kde musí být vaše služba dostupná 24/7, ale takové vývojové nebo testovací prostředí, které přes noc nikdo nepoužívá může být dobrým kandidátem.
Smazání nepotřebných zdrojů – zde platí pravidlo 90/90. Pokud nebyl zdroj v posledních 90 dnech využíván, doporučuji ho vypnout a dealokovat (jde o náklady na Storage, které by byly i tak účtovány). Pokud je VM dalších 90 dnů vypnutá a nikdo ji během této doby nepotřeboval, tak doporučuji tento zdroj kompletně smazat.
Zálohování – zde je to bez debat, pokud se jedná o produkční VM, je nutné ji zálohovat. Jak často a jak dlouho držet kopii zálohy by měla určit vaše vnitrofiremní politika.
Obnova při havárii – pokud provozujete služby, které jsou pro zákazníky kritické, tak musíte být připraveni i na možnost Disaster Recovery. Při jakékoli nečekané události musíte být schopni vaše služby co nejrychleji obnovit – zde pomohou Availability Sets, Zones, VM Scale Sets, Geo Redundance Storage a mnoho dalších Azure High Availability řešení. Řešení je však vždy nutné přizpůsobit požadavkům na RPO a RTO.

Ve druhém díle rozeberu doporučení a vhodné praktiky pro dostatečné zabezpečení, přiřazování identit a práv s tím spojených a v neposlední řadě pár tipu pro automatizace, která je nedílnou součástí cloudového prostředí.

Published by Oldřich Šrubař on 01/10/2021 | Permalink

Jak optimalizovat Azure infrastrukturu?

Představte si, že začínáte s Azure cloudem a nemáte vůbec žádné zkušenosti, nicméně je to pro vás zajímavá výzva a chcete do toho jít. Velmi pravděpodobný scénář bude ten, že si koupíte předplatné Azure, vytvoříte nějakou skupinu zdrojů a do ní začnete umisťovat všechny zdroje, které potřebujete. Pro začátek a otestování funkčnosti řešení je to akceptovatelný postup. Nicméně pokud tento způsob implementace nezměníte a nezačnete systematicky a efektivně plánovat, tak se při rozrůstajícím prostředí začnou objevovat určité problémy. Například se může stát, že ve shluku všech zdrojů budou již některé zbytečné a nepoužívané, jenže vy to nebudete vědět, protože nebudete mít přehled o tom k čemu jsou a pro co jsou využívány. Výsledkem je špatný přehled a vysoká částka na faktuře, kterou dostanete každý měsíc za využívání zdrojů v Azure. Toto byl pouze jeden z mnoha příkladů proč optimalizovat, níže se podíváme na pár tipů, jak optimalizovat a jak nám s tím může pomoci Well-Architected Framework spolu s Azure Governance.

A screenshot of a cell phone Description automatically generated

Jak je z výše uvedeného obrázku patrné, tak se tyto dvě oblasti v některých bodech částečně prolínají. Well-Architected Framework nám v podstatě říká, jak správně budovat infrastrukturu v Azure už od počátku, jak vše správně naplánovat při vytváření architektury a na co si dát pozor. Azure Governance je všeobecně správné řízení Azure cloudu, to znamená, že už pravděpodobně nějaké zdroje máte a nyní je čas je začít správně řídit a bezpečně spravovat včetně jejich nákladů na provoz.

Správa a výběr zdrojů

Jak jsem již na začátku nastínil, sledování zdrojů a jejich správa je extrémně důležitá disciplína. Pokud vám uživatelé nebo administrátoři chrlí hromady zdrojů do subskripce, tak je na místě začít tím nejjednodušším, a to je označování zdrojů pomocí tagů. Tagy mohou obsahovat informace o oddělení, vlastníkovi zdroje, prostředí, do kterého daný zdroj spadá a spoustu dalších parametrů, které jsou jen na vás. Použití tagů je skvělý způsob, jak agregovat a seskupovat prostředky mnoha způsoby, data lze také použít pro zpětné zúčtování. Neméně důležitým faktorem je také správný výběr úrovně služby a velikost virtuálního stroje, který musí odpovídat stanoveným požadavkům. Pokud dobře vyberete velikost virtuálního zdroje bude to mít okamžitý efekt na možnosti, kapacitu a výkon vašich služeb v Azure, především pak na cenu, která je s typem virtuálního stoje úzce spjatá. Velikost a úroveň služby virtuálního stroje nemusí být permanentní stav, v průběhu času a změn požadavků, se může velikost změnit, proto je potřeba se efektivně přizpůsobovat správným výběrům velikostí.

Plánování pro vypnutí systémů

Pokud máte nějaké virtuální stroje, které se používají pouze periodicky – v určitém čase, ale jsou neustále v provozu, tak zbytečně plýtváte penězi. Ideálním řešením je tyto servery vypínat právě v době kdy nejsou potřeba, čas, po který je server vypnutý šetří vaše náklady za výpočetní kapacitu. Hezkým kandidátem je například prostředí pro development, které se většinou využívá pouze během klasické pracovní doby, takže přes noc mohou být servery vypnuté. Existuje několik možností, jak vypínání zdrojů řešit:

Pro běh serverů pouze v čase, kdy to potřebujeme, můžeme využít službu Azure Automation.
Pro jednorázové automatické vypnutí virtuálního stroje můžeme využít nativní funkci auto-shutdown.
Manuální vypnutí serveru, když víme že už jej nebudeme ten den potřebovat. Zde je nutné zmínit, že je potřeba použít nativní Stop VM z ovládacího panelu virtuálního stoje v Azure, jinak nebude VM dealokována a budou stále účtovány náklady.

Spot instance

Jde o zajímavý typ virtuálních strojů, které běží, pokud má Azure nějaké nevyužité kapacity, které potřebuje zaplnit. V případě, že Azure potřebuje kapacitu zpět, tak jsou virtuální stoje vypnuty a dealokovány nebo úplně smazány. Při dealokaci stále platíte za úložiště, které virtuální stoje využívají, při smazání je vše odebráno včetně disků a neplatíte nic. Teď si určitě říkáte: „K čemu je to vlastně dobré?“ Toto řešení je možné používat pro testovací či vývojářské účely, zpracování batch procesů, kterým nevadí přerušení, pro velké výpočetní operace a další. V porovnání s normálními zdroji jsou spot instance za zlomek ceny, což je jejich největší výhoda.

Rezervované instance

Jsou Azure zdroje, které si můžete rezervovat na určitou dobu, konkrétně na jeden nebo tři roky. Díky rezervaci získáte okamžitou slevu až 72% oproti Pay-as-you-Go. V Azure si můžete rezervovat tyto typy zdrojů:

Virtuální stroje Windows a Linux
Azure SQL Database
Azure Cosmos DB
Azure Synapse Analytics
Azure Storage

Využívání „managed“ služeb

Pokud je to možné doporučujeme využívat tzv. „Managed Services“. Výhodou těchto služeb je, že kombinují nižší náklady za zdroje spolu s nižšími operativními náklady za údržbu. Důvodem je to, že se nemusíme starat o nižší vrstvy infrastruktury pod naší aplikací. Neřešíte patchování, instalaci aplikací, správu operačního systému a další komponenty, které jsou nutné pro běh vaší aplikace. Jedním z příkladů je Azure SQL Database – můžete nasadit jednu i více databázových instancí, a přitom neřešíte na jakém operačním systému běží, aktualizace, zálohování, vysokou dostupnout a jiné. Vše je obsaženo automaticky v dané službě. Azure App Service je další spravovanou službou, která je navržena k hostování webových aplikací. Místo nasazení a správy virtuálních počítačů pro vaše webové aplikace můžete své aplikace nasadit přímo do App Service a dramaticky snížit operativní náklady, které jsou vyžadovány pro údržbu infrastruktury.

Optimalizace nákladů na Azure SQL databáze

Když vytváříte Azure SQL databázi, tak musíte vybrat jednu z několika možností, která stanovuje výkon služby. Každá úroveň poskytuje určitý výkon v databázových transakčních jednotkách (DTU) nebo počtu virtuálních jader (vCore). Pokud máte databázi, která má stabilní zatížení v čase, tak je celkem jednoduché vybrat příslušnou úroveň výkonu. Jakou úroveň však vybrat, pokud máte databáze, které mají nekonstantní zatížení v různých časech během dne? V tomto případě může pomoci „elastic pool“.

SQL databázové elastic pooly jsou jednoduchým a nákladově efektivním řešením pro správu a škálování několika databází, které mají různé a nepředvídatelné nároky na zatížení. Databáze v elastic poolu jsou na jednom Azure SQL Database serveru a sdílejí stanovený počet prostředků za stanovenou cenu. Charakteristický model pro toto řešení je větší množství databází s nízkým průměrem zátěže, ale s relativně nepravidelnými zátěžovými špičkami.

K dispozici jsou celkem tři elastic pooly:

Zdroj: Microsoft Docs

Sledování nákladů a tipů Azure Advisor

Využívání služby Azure Cost Management + Billing vám poskytne přehled o tom, za co přesně utrácíte, a také o nevyužitých zdrojích. Jsou sledovány celkové výdaje, náklady podle služeb a náklady v průběhu času. Můžete se proklikávat až do podrobností jednotlivých zdrojů a získat informace o typech prostředků a instancích. Své přehledy nákladů můžete také rozdělit podle organizace nebo nákladového střediska, a to díky již dříve zmíněným tagům.

Výborným pomocníkem je také služba Azure Advisor, která vám automaticky napovídá, co udělat jinak nebo jak danou službu zlepšit za účelem zvýšení výkonu a dostupnosti, zabezpečení či snížením nákladů.

V případě potřeby doporučuje změnu velikosti virtuálního počítače.
Identifikuje nepoužívané linky Azure ExpressRoute a nečinné virtuální brány sítě.
Doporučuje, kdy zvážit nákup rezervovaných instancí, ve chvíli, kdy by to mohlo být nákladově efektivnější než použití instancí typu pay-as-you-go.

Pokud se při sledování a shromažďování nákladů zjistí nějaká výdajová anomálie, měli byste ji nahlásit ihned vlastníkům daných zdrojů nebo zúčastněným stranám. Aktivní zapojení těchto stran může zajistit identifikaci potencionálního překročení nákladů dříve, než se stane problematickým. Transparentnost při komunikaci se zúčastněnými stranami je důležitá, aby mohli plně porozumět veškerým technickým nebo obchodním rozhodnutím, která způsobila neobvyklé náklady.

Věřím, že výše uvedené tipy dokážou ušetřit alespoň nějakou část financí, které byste jinak museli zaplatit. Zkoušejte optimalizovat po malých částech a hlavně tam, kde to opravdu dává smysl. Zaměřte se na služby, za které platíte nejvíce, tam totiž existuje pravděpodobnost, že půjde nějakým způsobem minimalizovat náklady.

Published by Oldřich Šrubař on 14/09/2021 | Permalink

OLDŘICH ŠRUBAŘ

Nejnovější příspěvky

Nejnovější komentáře

Archivy

Rubriky

Základní informace