Základní architektura virtuálních počítačů Azure

Tento článek obsahuje základní referenční architekturu pro úlohu nasazenou ve službě Azure Virtual Machines.

Ukázková úloha, kterou tato architektura předpokládá, je internetová vícevrstvé webová aplikace, která je nasazená na samostatných sadách virtuálních počítačů. Virtuální počítače se zřizují jako součást nasazení služby Azure Virtual Machine Scale Sets. Tuto architekturu je možné použít pro tyto scénáře:

• Soukromé aplikace. Mezi tyto aplikace patří interní obchodní aplikace nebo komerční řešení mimo provoz.
• Veřejné aplikace. Tyto aplikace jsou internetové aplikace. Tato architektura není určená pro vysokovýkonné výpočetní prostředí, klíčové úlohy, aplikace vysoce ovlivněné latencí nebo jinými specializovanými případy použití.

Primárním cílem této architektury není aplikace. Místo toho tento článek obsahuje pokyny ke konfiguraci a nasazení komponent infrastruktury, se kterými aplikace komunikuje. Mezi tyto komponenty patří výpočetní prostředky, úložiště, sítě a monitorovací komponenty.

Tato architektura slouží jako výchozí bod pro úlohy hostované jako infrastruktura jako služba (IaaS). Datová vrstva je záměrně vyloučena z těchto pokynů, aby se zachovala zaměření na výpočetní infrastrukturu.

Rozložení článku

Architektura	Rozhodnutí o návrhu	Dobře navržená architektura
▪ Diagram architektury ▪ Prostředky úloh ▪ Podpůrné zdroje ▪ Toky uživatelů	▪ Možnosti návrhu virtuálních počítačů ▪ Disky ▪ Síťování ▪ Monitorování ▪ Správa aktualizací	▪ Spolehlivost ▪ Bezpečnost ▪ Optimalizace nákladů

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Informace o těchto prostředcích najdete v dokumentaci k produktům Azure uvedeným v souvisejících prostředcích.

Komponenty

Tato architektura se skládá z několika služeb Azure pro prostředky úloh i podpůrné prostředky úloh. Služby pro každou a jejich role jsou popsány v následujících částech.

Prostředky úloh

• Azure Virtual Machines slouží jako výpočetní prostředek pro aplikaci a distribuuje se napříč zónami dostupnosti. Pro ilustrativní účely se používá kombinace virtuálních počítačů s Windows i Linuxem.

  Škálovací sady virtuálních počítačů Azure v flexibilním režimu orchestrace se používají ke zřizování a správě virtuálních počítačů.

  Ukázková aplikace může být reprezentována ve dvou úrovních, z nichž každá vyžaduje vlastní výpočetní prostředky.

  • Front-end spouští webový server a přijímá požadavky uživatelů.
  • Back-end spouští jiný webový server fungující jako webové rozhraní API, které zveřejňuje jeden koncový bod, kde se spouští obchodní logika.

  Front-endové virtuální počítače mají připojené datové disky (Premium_LRS), které se dají použít k nasazení bezstavové aplikace. Back-endové virtuální počítače uchovávají data do Premium_ZRS místních disků v rámci operace. Toto rozložení je možné rozšířit tak, aby zahrnovalo databázovou vrstvu pro ukládání stavu z front-endu a back-endového výpočetního prostředí. Tato úroveň je mimo rozsah této architektury.

• Azure Virtual Network poskytuje privátní síť pro všechny prostředky úloh. Síť je segmentovaná do podsítí, které slouží jako hranice izolace.

• Aplikace Azure lication Gateway je jediný bod příchozího přenosu dat, který směruje požadavky na front-endové servery. Vybraná skladová položka zahrnuje integrované firewall webových aplikací Azure (WAF) pro přidání zabezpečení.

• Interní Azure Load Balancer směruje provoz z front-endové vrstvy na back-endové servery.

• Skladová položka Azure Load Balanceru úrovně Standard poskytuje odchozí internetový přístup k virtuálním počítačům pomocí tří veřejných IP adres.

• Azure Key Vault ukládá certifikáty používané ke komunikaci protokolu TLS (Transport Layer Security). Dá se použít také pro tajné kódy aplikací.

Úlohy podporující prostředky

• Azure Bastion poskytuje provozní přístup k virtuálním počítačům přes zabezpečené protokoly.

• Application Insights shromažďuje protokoly a metriky z aplikace. Vzhledem k tomu, že aplikace není zaměřená na tuto architekturu, není v implementaci ukázaná kolekce protokolů.

• Log Analytics je jímka dat monitorování, která shromažďuje protokoly a metriky z prostředků Azure a Application Insights. Účet úložiště je zřízený jako součást pracovního prostoru.

Toky uživatele

Existují dva typy uživatelů, kteří pracují s prostředky úloh: uživatel a operátor úlohy. Toky pro tyto uživatele se zobrazují v předchozím diagramu architektury.

Uživatel úloh

1. Uživatel přistupuje k webu pomocí vystavené veřejné IP adresy služby Application Gateway.

2. Application Gateway přijímá provoz HTTPS, dešifruje data pomocí externího certifikátu pro kontrolu WAF a znovu ho zašifruje pomocí interního certifikátu se zástupným znakem pro přenos do front-endu.

3. Application Gateway vyrovnává provoz mezi front-endovými virtuálními počítači a předává požadavek front-end virtuálnímu počítači.

4. Vybraný front-endový virtuální počítač komunikuje s back-endovým virtuálním počítačem pomocí privátní IP adresy nástroje pro vyrovnávání zatížení, nikoli IP adresy jednotlivých virtuálních počítačů. Tato komunikace je také šifrovaná pomocí interního certifikátu se zástupným znakem.

5. Back-endový virtuální počítač dešifruje požadavek pomocí interního certifikátu. Jakmile back-end zpracuje požadavek, vrátí výsledek front-endu, který vrátí výsledek do aplikační brány a nakonec vrátí výsledek uživateli.

Operátor

Virtuální počítače v této architektuře můžou vyžadovat přímý přístup operátory, ale doporučujeme minimalizovat vzdálený přístup prostřednictvím automatizace a monitorování přístupu. Přístup může být určený pro situace, řešení potíží nebo část procesu automatizovaného nasazení. Tato architektura nemá veřejné IP adresy pro přístup k řídicí rovině. Azure Bastion funguje jako bezserverová brána, která umožňuje operacím přístup k virtuálním počítačům přes SSH nebo RDP. Toto nastavení zajišťuje zabezpečenou a efektivní správu přístupu.

1. Operátor se přihlásí k webu Azure Portal nebo Azure CLI.
2. Operátor přistupuje ke službě Azure Bastion a vzdáleně se připojí k požadovanému virtuálnímu počítači.

Možnosti návrhu virtuálních počítačů

Při výběru skladových položek je důležité mít standardní očekávané výkony. Rozhodovací proces ovlivňuje několik charakteristik, mezi které patří:

• Procesor, paměť a vstupně-výstupní operace disku za sekundu (IOPS).
• Architektura procesorů
• Velikost image operačního systému

Pokud například migrujete úlohu z místního prostředí, které vyžaduje procesory Intel, zvolte skladové položky virtuálních počítačů, které podporují procesory Intel.

Informace o podporovaných skladových posílacích virtuálních počítačů najdete v tématu Velikosti virtuálních počítačů v Azure.

Bootstrapping

Virtuální počítače je často potřeba spustit, což je proces, ve kterém jsou virtuální počítače připravené a vyladěné pro spuštění aplikace. Mezi běžné úlohy spouštění patří instalace certifikátů, konfigurace vzdáleného přístupu, instalace balíčků, ladění a posílení konfigurace operačního systému a formátování a připojení datových disků. Je důležité co nejvíce automatizovat proces spouštění, aby se aplikace na virtuálním počítači spustila bez zpoždění nebo ručního zásahu. Tady jsou doporučení pro automatizaci:

• Rozšíření virtuálních počítačů. Tato rozšíření jsou objekty Azure Resource Manageru, které se spravují prostřednictvím nasazení infrastruktury jako kódu (IaC). Tímto způsobem se všechna selhání hlásí jako neúspěšné nasazení, se kterým můžete provést akci. Pokud pro vaše potřeby spouštění neexistuje rozšíření, vytvořte vlastní skripty. Doporučujeme spouštět skripty prostřednictvím rozšíření vlastních skriptů Azure.

  Tady jsou některá další rozšíření, která se dají použít k automatické instalaci nebo konfiguraci funkcí na virtuálních počítačích.

  • Agent služby Azure Monitor (AMA) shromažďuje data monitorování z hostovaného operačního systému a doručuje je do služby Azure Monitor.
  • Rozšíření vlastních skriptů Azure (Windows, Linux) verze 2 stáhne a spustí skripty na virtuálních počítačích Azure. Toto rozšíření je užitečné pro automatizaci konfigurace po nasazení, instalace softwaru nebo jiných úloh konfigurace nebo správy.
  • Rozšíření virtuálního počítače azure Key Vault (Windows, Linux) poskytuje automatickou aktualizaci certifikátů uložených ve službě Key Vault zjišťováním změn a instalací odpovídajících certifikátů.
  • Rozšíření Služby Application Health se škálovacími sadami virtuálních počítačů je důležité, když Azure Virtual Machine Scale Sets provede automatické postupné upgrady. Azure k aktualizaci spoléhá na monitorování stavu jednotlivých instancí. Rozšíření můžete použít také ke sledování stavu aplikace jednotlivých instancí ve škálovací sadě a provádění oprav instancí pomocí automatických oprav instancí.
  • Microsoft Entra ID a OpenSSH (Windows, Linux) se integrují s ověřováním Microsoft Entra. Teď můžete použít Microsoft Entra ID jako základní ověřovací platformu a certifikační autoritu pro připojení SSH k virtuálnímu počítači s Linuxem pomocí Microsoft Entra ID a ověřování založeného na certifikátech OpenSSH. Tato funkce umožňuje spravovat přístup k virtuálním počítačům pomocí řízení přístupu na základě role v Azure (RBAC) a zásad podmíněného přístupu.

• Konfigurace založená na agentech. Virtuální počítače s Linuxem můžou používat jednoduchou nativní konfiguraci požadovaného stavu dostupnou prostřednictvím cloud-init na různých imagích virtuálních počítačů poskytovaných v Azure. Konfigurace je určena a verze s vašimi artefakty IaC. Další možností je přinést si vlastní řešení správy konfigurace. Většina řešení se řídí deklarativním přístupem při spouštění, ale podporuje vlastní skripty pro flexibilitu. Mezi oblíbené volby patří Desired State Configuration for Windows, Desired State Configuration for Linux, Ansible, Chef, Puppet a další. Všechna tato řešení konfigurace se dají spárovat s rozšířeními virtuálních počítačů, aby to bylo co nejlepší.

V referenční implementaci se veškeré spouštění provádí prostřednictvím rozšíření virtuálních počítačů a vlastních skriptů, včetně vlastního skriptu pro automatizaci formátování a připojení datového disku.

Projděte si dobře navrženou architekturu: RE:02 – Doporučení pro návrh automatizace.

Připojení virtuálního počítače

Pokud chcete povolit privátní komunikaci mezi virtuálním počítačem a dalšími zařízeními v konkrétní virtuální síti, je síťová karta virtuálního počítače připojená k jedné z podsítí virtuální sítě. Pokud pro virtuální počítač požadujete více síťových karet, je pro každou velikost virtuálního počítače definován maximální počet síťových karet.

Pokud úloha potřebuje komunikaci s nízkou latencí mezi virtuálními počítači ve virtuální síti, zvažte akcelerované síťové rozhraní, které podporují síťové karty virtuálních počítačů Azure. Další informace najdete v tématu Výhody akcelerovaných síťových služeb.

Škálovací sady virtuálních počítačů s flexibilní orchestrací

Virtuální počítače se zřizují jako součást škálovacích sad virtuálních počítačů s flexibilní orchestrací. Škálovací sady virtuálních počítačů jsou logické seskupení virtuálních počítačů, které se používají ke splnění obchodních potřeb. Typy virtuálních počítačů ve seskupení můžou být identické nebo odlišné. Umožňují spravovat životní cyklus počítačů, síťových rozhraní a disků pomocí standardních rozhraní a příkazů virtuálních počítačů Azure.

Flexibilní režim orchestrace usnadňuje operace ve velkém měřítku a pomáhá s podrobnými rozhodnutími o škálování.

Konfigurace domény selhání je nutná k omezení vlivu fyzických selhání hardwaru, výpadků sítě nebo přerušení napájení. Díky škálovacím sadám Azure rovnoměrně rozloží instance napříč doménami selhání kvůli odolnosti proti jednomu problému s hardwarem nebo infrastrukturou.

Kvůli maximálnímu šíření instancí, zvýšení odolnosti a dostupnosti doporučujeme přesměrování přidělení domény selhání do Azure.

Disky

Pokud chcete spustit komponenty operačního systému a aplikace, disky úložiště jsou připojené k virtuálnímu počítači. Zvažte použití dočasných disků pro operační systém a spravované disky pro úložiště dat.

Azure nabízí celou řadu možností z hlediska výkonu, všestrannosti a nákladů. Začněte s SSD úrovně Premium pro většinu produkčních úloh. Vaše volba závisí na skladové po straně virtuálního počítače. Skladové položky, které podporují SSD úrovně Premium, obsahují v názvu prostředku například Dsv4, ale ne Dv4.

Další informace o možnostech disku s metrikami, jako jsou kapacita, IOPS a propustnost, najdete v tématu Porovnání typů disků.

Při výběru disku zvažte charakteristiky disků a očekávání výkonu.

• Omezení skladové položky virtuálního počítače Disky fungují v rámci virtuálního počítače, ke kterému jsou připojené, a mají limity IOPS a propustnosti. Ujistěte se, že disk neomezuje limity virtuálního počítače a naopak. Vyberte velikost disku, výkon a možnosti virtuálního počítače (jádro, procesor, paměť), které optimálně spouští komponentu aplikace. Vyhněte se nadměrnému zřízení, protože ovlivňuje náklady.

• Změny konfigurace. V době, kdy je virtuální počítač spuštěný, můžete změnit konfiguraci výkonu disku a kapacity. Mnoho změn ale může vyžadovat opětovné zřízení a opětovné sestavení obsahu disku, což má vliv na dostupnost úloh. Proto pečlivě naplánujte výběr skladové položky disku a virtuálního počítače, abyste minimalizovali dopad na dostupnost a přepracování.

• Dočasné disky s operačním systémem Zřiďte disky operačního systému jako dočasné disky. Spravované disky používejte jenom v případě, že je potřeba zachovat soubory operačního systému. Nepoužívejte dočasné disky k ukládání komponent a stavu aplikací.

  Kapacita dočasných disků s operačním systémem závisí na zvolené skladové po straně virtuálního počítače. Ujistěte se, že velikost disku s imagí operačního systému je menší než dostupná mezipaměť SKU nebo dočasný disk. Zbývající prostor můžete použít pro dočasné úložiště.

• Výkon disku. Běžné je předběžné zřizování místa na disku na základě zatížení ve špičce, ale může vést k nedostatečně využitým prostředkům, protože většina úloh neudržuje zatížení ve špičce.

  Monitorujte vzory využití úloh, sledujte špičky nebo trvalé operace s vysokým čtením a zastavte tyto vzory do výběru skladové položky virtuálního počítače a spravovaného disku.

  Výkon na vyžádání můžete upravit změnou úrovní výkonu nebo použitím funkcí nárazového nárůstu nabízených v některých SKU spravovaných disků.

  I když nadměrné zřizování snižuje potřebu nárůstu kapacity, může to vést k nevyužité kapacitě, za kterou platíte. V ideálním případě zkombinujte obě funkce pro optimální výsledky.

• Vylaďte ukládání do mezipaměti pro úlohu. Nakonfigurujte nastavení mezipaměti pro všechny disky na základě využití komponent aplikace.

  Komponenty, které provádějí hlavně operace čtení, nevyžadují konzistenci transakcí s vysokým diskem. Tyto komponenty můžou těžit z ukládání do mezipaměti jen pro čtení. Komponenty náročné na zápis, které vyžadují konzistenci transakcí s vysokým diskem, jsou často zakázané ukládání do mezipaměti.

  Použití ukládání do mezipaměti pro čtení a zápis může způsobit ztrátu dat, pokud dojde k chybovému ukončení virtuálního počítače a nedoporučuje se pro většinu scénářů datového disku.

V této architektuře:

• Disky operačního systému všech virtuálních počítačů jsou dočasné a umístěné na disku mezipaměti.

  Aplikace úloh ve front-endu (Linux) a back-endu (Windows Server) jsou odolné vůči selhání jednotlivých virtuálních počítačů a obě používají malé image (přibližně 30 GB). Tyto atributy umožňují používat dočasné disky s operačním systémem vytvořené jako součást místního úložiště virtuálního počítače (oddíl mezipaměti) místo trvalého disku s operačním systémem, který je uložený ve vzdálených prostředcích úložiště Azure. Tato situace nemá žádné náklady na úložiště pro disky s operačním systémem a zvyšuje výkon tím, že poskytuje nižší latenci a snižuje dobu nasazení virtuálního počítače.

• Každý virtuální počítač má vlastní spravovaný disk SSD P1 úrovně Premium, který poskytuje základní zřízenou propustnost, která je vhodná pro danou úlohu.

Rozložení sítě

Tato architektura nasadí úlohu do jedné virtuální sítě. Síťové ovládací prvky jsou významnou součástí této architektury a jsou popsány v části Zabezpečení .

Toto rozložení lze integrovat s podnikovou topologií. Tento příklad je znázorněn v architektuře standardních hodnot virtuálních počítačů v cílové zóně Azure.

Virtuální síť

Jedno z vašich počátečních rozhodnutí o rozložení sítě souvisí s rozsahem adres sítě. Mějte na paměti očekávaný růst sítě během fáze plánování kapacity. Síť by měla být dostatečně velká, aby udržela růst, což může vyžadovat další síťové konstrukce. Například virtuální síť by měla mít kapacitu pro přizpůsobení ostatních virtuálních počítačů, které jsou výsledkem operace škálování.

Naopak, velikost adresního prostoru je správná. Nadměrně velká virtuální síť může vést k nedostatečnému využití. Je důležité si uvědomit, že po vytvoření virtuální sítě se rozsah adres nedá upravit.

V této architektuře je adresní prostor nastavený na /21, což je rozhodnutí na základě předpokládaného růstu.

Důležité informace o podsíti

V rámci virtuální sítě jsou podsítě rozdělené na základě požadavků na funkce a zabezpečení, jak je popsáno zde:

• Podsíť pro hostování aplikační brány, která slouží jako reverzní proxy server. Application Gateway vyžaduje vyhrazenou podsíť.
• Podsíť pro hostování interního nástroje pro vyrovnávání zatížení pro distribuci provozu do back-endových virtuálních počítačů.
• Podsítě pro hostování virtuálních počítačů úloh, jednu pro front-end a jednu pro back-end. Tyto podsítě se vytvářejí podle úrovní aplikace.
• Podsíť pro hostitele Služby Azure Bastion, která usnadňuje provozní přístup k virtuálním počítačům úloh. Hostitel Služby Azure Bastion podle návrhu potřebuje vyhrazenou podsíť.
• Podsíť pro hostování privátních koncových bodů vytvořených pro přístup k dalším prostředkům Azure přes Azure Private Link. I když pro tyto koncové body nejsou vyhrazené podsítě povinné, doporučujeme je použít.

Podobně jako u virtuálních sítí musí mít podsítě správnou velikost. Můžete například chtít použít maximální limit virtuálních počítačů podporovaných flexibilní orchestrací tak, aby splňovaly potřeby škálování aplikace. Podsítě úloh by měly být schopné tento limit využít.

Dalším případem použití, který je potřeba zvážit, jsou upgrady operačního systému virtuálních počítačů, které můžou vyžadovat dočasné IP adresy. Nastavení správné velikosti poskytuje požadovanou úroveň segmentace tím, že zajistí, aby se podobné prostředky seskupily tak, aby byla smysluplná pravidla zabezpečení prostřednictvím skupin zabezpečení sítě (NSG) použita na hranice podsítě. Další informace naleznete v tématu Zabezpečení: Segmentace.

Příchozí přenos dat

Pro toky příchozího přenosu dat se používají dvě veřejné IP adresy. Jednou adresou je služba Application Gateway, která slouží jako reverzní proxy server. Uživatelé se připojují pomocí této veřejné IP adresy. Zatížení reverzního proxy serveru vyrovnává příchozí provoz do privátních IP adres virtuálních počítačů. Druhou adresou je provozní přístup prostřednictvím služby Azure Bastion.

Stáhněte si soubor aplikace Visio s touto architekturou.

Výchozí přenos

Tato architektura používá standard SKU Load Balancer s odchozími pravidly definovanými z instancí virtuálních počítačů. Nástroj pro vyrovnávání zatížení byl zvolen, protože je zónově redundantní.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tato konfigurace umožňuje používat veřejné IP adresy vašeho nástroje pro vyrovnávání zatížení k poskytování odchozího připojení k internetu pro virtuální počítače. Odchozí pravidla umožňují explicitně definovat porty překladu zdrojových síťových adres (SNAT). Pravidla umožňují škálovat a ladit tuto schopnost prostřednictvím ručního přidělování portů. Ruční přidělování portu SNAT na základě velikosti a počtu back-endového frontendIPConfigurations fondu může pomoct vyhnout se vyčerpání SNAT.

Doporučujeme přidělit porty na základě maximálního počtu back-endových instancí. Pokud je přidáno více instancí, než je povolené zbývající porty SNAT, můžou být zablokované operace škálování služby Virtual Machine Scale Sets nebo nové virtuální počítače nedostávají dostatečné porty SNAT.

Vypočítat porty na instanci jako: Number of front-end IPs * 64K / Maximum number of back-end instances.

Existují další možnosti, které můžete použít, například nasazení prostředku azure NAT Gateway připojeného k podsíti. Další možností je použít Azure Firewall nebo jiné síťové virtuální zařízení s vlastní trasou definovanou uživatelem jako další segment směrování přes bránu firewall. Tato možnost se zobrazuje v architektuře standardních hodnot virtuálních počítačů v cílové zóně Azure.

Překlad DNS

Azure DNS se používá jako základní služba pro všechny případy použití překladu, například překlad plně kvalifikovaných názvů domén (FQDN) přidružených k virtuálním počítačům úloh. V této architektuře používají virtuální počítače hodnoty DNS nastavené v konfiguraci virtuální sítě, což je Azure DNS.

Privátní zóny DNS Azure se používají k překladu požadavků na privátní koncové body používané pro přístup k pojmenovaných prostředkům Private Link.

Sledování

Tato architektura má monitorovací zásobník, který je oddělený od nástroje úlohy. Zaměřuje se především na zdroje dat a aspekty shromažďování.

Metriky a protokoly se generují v různých zdrojích dat a poskytují přehledy pozorovatelnosti v různých nadmořské výšce:

• Základní infrastruktura a komponenty se považují za virtuální počítače, virtuální sítě a služby úložiště. Protokoly platformy Azure poskytují informace o operacích a aktivitách v rámci platformy Azure.

• Úroveň aplikace poskytuje přehled o výkonu a chování aplikací spuštěných ve vašem systému.

Pracovní prostor služby Log Analytics je doporučená jímka dat monitorování, která slouží ke shromažďování protokolů a metrik z prostředků Azure a Application Insights.

Tento obrázek znázorňuje zásobník monitorování standardních hodnot s komponentami pro shromažďování dat z infrastruktury a aplikace, jímek dat a různých nástrojů pro analýzu a vizualizaci. Implementace nasadí některé komponenty, jako je Application Insights, diagnostika spouštění virtuálních počítačů a Log Analytics. Další komponenty jsou znázorněny tak, aby předváděly možnosti rozšiřitelnosti, jako jsou řídicí panely a výstrahy.

Stáhněte si soubor aplikace Visio s touto architekturou.

Monitorování na úrovni infrastruktury

Tato tabulka odkazuje na protokoly a metriky shromážděné službou Azure Monitor. Dostupné výstrahy vám pomůžou aktivně řešit problémy, než ovlivní uživatele.

Prostředek Azure	Metriky a protokoly	Výstrahy
Application Gateway	Popis metrik a protokolů služby Application Gateway	Upozornění služby Application Gateway
Application Insights	Metriky Application Insights a rozhraní API pro protokolování	Upozornění Application Insights
Azure Bastion	Metriky služby Azure Bastion
Key Vault	Popisy metrik a protokolů služby Key Vault	Upozornění služby Key Vault
Load Balancer úrovně Standard	Protokoly a metriky nástroje pro vyrovnávání zatížení	Upozornění Load Balanceru
Veřejná IP adresa	Popis metrik a protokolů veřejných IP adres	Upozornění na metriky veřejných IP adres
Virtual Network	Referenční informace k metrikám a protokolům virtuální sítě	Upozornění virtuální sítě
Virtuální počítače a škálovací sady virtuálních počítačů	Referenční informace k metrikám a protokolům virtuálních počítačů	Upozornění a kurzy virtuálních počítačů
Firewall webových aplikací	Popis metrik a protokolů firewallu webových aplikací	Upozornění firewallu webových aplikací

Další informace o nákladech na shromažďování metrik a protokolů najdete v tématu Výpočty a možnosti nákladů a cenyslužby Log Analytics pro pracovní prostor služby Log Analytics. Povaha úlohy a frekvence a počtu metrik a protokolů shromážděných výrazně ovlivňuje náklady na metriku a shromažďování protokolů.

Virtuální počítače

Diagnostika spouštění Azure umožňuje sledovat stav virtuálních počítačů během spouštění shromažďováním informací o sériovém protokolu a snímky obrazovky. V této architektuře jsou tato data přístupná prostřednictvím webu Azure Portal a příkazu azure CLI boot-diagnostics get-boot-log. Data spravuje Azure a nemáte žádnou kontrolu ani přístup k podkladovému prostředku úložiště. Pokud ale vaše obchodní požadavky vyžadují větší kontrolu, můžete zřídit vlastní účet úložiště pro ukládání diagnostiky spouštění.

Přehledy virtuálních počítačů nabízejí efektivní způsob monitorování virtuálních počítačů a škálovacích sad. Shromažďuje data z pracovních prostorů služby Log Analytics a poskytuje předdefinované sešity pro trend dat o výkonu. Tato data je možné zobrazit na jeden virtuální počítač nebo agregovat napříč několika virtuálními počítači.

Application Gateway a interní nástroj pro vyrovnávání zatížení používají sondy stavu ke zjištění stavu koncových bodů virtuálních počítačů před odesláním provozu.

Sítě

V této architektuře se data protokolů shromažďují z několika síťových komponent, které se účastní toku. Mezi tyto komponenty patří Application Gateway, nástroje pro vyrovnávání zatížení a Azure Bastion. Zahrnují také komponenty zabezpečení sítě, jako jsou virtuální sítě, skupiny zabezpečení sítě, veřejné IP adresy a Private Link.

Spravované disky

Metriky disků závisí na vaší úloze a vyžadují kombinaci klíčových metrik. Monitorování by mělo tyto perspektivy kombinovat za účelem izolace problémů s propustností operačního systému nebo aplikací.

• Perspektiva platformy Azure představuje metriky, které označují službu Azure bez ohledu na úlohu, která je k ní připojená. Metriky výkonu disku (IOPS a propustnost) se dají zobrazit jednotlivě nebo souhrnně pro všechny disky připojené k virtuálním počítačům. K řešení potíží nebo upozorňování na potenciální omezování disku použijte metriky využití vstupně-výstupních operací úložiště. Pokud pro optimalizaci nákladů používáte rozšíření, monitorujte metriky procent kreditů a identifikujte příležitosti k další optimalizaci.

• Perspektiva hostovaného operačního systému představuje metriky, které by operátor úlohy zobrazil bez ohledu na základní diskovou technologii. Přehledy virtuálních počítačů se doporučují pro klíčové metriky na připojených discích, jako je využité místo na logickém disku, a perspektiva jádra operačního systému na IOPS disku a propustnost.

Monitorování na úrovni aplikace

I když se referenční implementace nepoužívá, application Insights se zřizuje jako správa výkonu aplikací (APM) pro účely rozšiřitelnosti. Application Insights shromažďuje data z aplikace a odesílá tato data do pracovního prostoru služby Log Analytics. Může také vizualizovat data z aplikací úloh.

Rozšíření stavu aplikace se nasadí do virtuálních počítačů za účelem monitorování binárního stavu každé instance virtuálního počítače ve škálovací sadě a v případě potřeby provede opravy instancí pomocí automatické opravy instance škálovací sady. Testuje stejný soubor jako Application Gateway a interní sondu stavu nástroje pro vyrovnávání zatížení Azure a kontroluje, jestli aplikace reaguje.

Správa aktualizací

Virtuální počítače je potřeba pravidelně aktualizovat a opravovat, aby neoslabovaly stav zabezpečení úlohy. Pro včasné zjišťování a použití oprav doporučujeme automatická a pravidelná posouzení virtuálních počítačů.

Aktualizace infrastruktury

Azure pravidelně aktualizuje svou platformu, aby zlepšila spolehlivost, výkon a zabezpečení hostitelské infrastruktury pro virtuální počítače. Mezi tyto aktualizace patří opravy softwarových komponent v hostitelském prostředí, upgrade síťových komponent nebo vyřazení hardwaru z provozu a další. Informace o procesu aktualizace najdete v tématu Údržba virtuálních počítačů v Azure.

Pokud aktualizace nevyžaduje restartování, virtuální počítač se při aktualizaci hostitele pozastaví nebo se virtuální počítač migruje za provozu na již aktualizovaného hostitele. Pokud údržba vyžaduje restartování, budete upozorněni na plánovanou údržbu. Azure také poskytuje časové období, ve kterém můžete zahájit údržbu, a to podle vašich pohodlí. Informace o okně samoobslužné údržby a o tom, jak nakonfigurovat dostupné možnosti, najdete v tématu Zpracování oznámení plánované údržby.

Některé úlohy nemusí tolerovat ani několik sekund zamrznutí nebo odpojení virtuálního počítače kvůli údržbě. Pokud chcete mít větší kontrolu nad všemi aktivitami údržby, včetně aktualizací bez dopadu na nulu a restartování, přečtěte si téma Konfigurace údržby. Vytvoření konfigurace údržby vám dává možnost přeskočit všechny aktualizace platformy a použít aktualizace podle vašich pohodlí. Když je tato vlastní konfigurace nastavená, Azure přeskočí všechny aktualizace bez nulového dopadu, včetně aktualizací bez restartování. Další informace najdete v tématu Správa aktualizací platformy pomocí konfigurací údržby.

Upgrady imagí operačního systému

Když provádíte upgrady operačního systému, máte otestovanou zlatou image. Zvažte použití Galerie sdílených imagí Azure a Galerie výpočetních prostředků Azure k publikování vlastních imagí. Měli byste mít zaveden proces, který upgraduje dávky instancí postupným způsobem pokaždé, když vydavatel publikuje novou image.

Vyřazení imagí virtuálních počítačů dřív, než se dostanou na konec životnosti, aby se snížila plocha.

Váš proces automatizace by měl zohledňovat nadměrné zřízení s dodatečnou kapacitou.

Azure Update Management můžete použít ke správě aktualizací operačního systému pro virtuální počítače s Windows a Linuxem v Azure.Azure Update Manager poskytuje řešení SaaS pro správu a řízení aktualizací softwaru pro počítače s Windows a Linuxem napříč Azure, místními a multicloudovými prostředími.

Opravy hostovaného operačního systému

Virtuální počítače Azure poskytují možnost automatických oprav hosta virtuálního počítače. Pokud je tato služba povolená, virtuální počítače se pravidelně vyhodnocují a klasifikují se dostupné opravy. Doporučuje se povolit režim posouzení, aby umožňoval denní vyhodnocení čekajících oprav. Hodnocení na vyžádání je ale možné provést tak, že neaktivuje použití oprav. Pokud režim posouzení není povolený, ručně zjistěte čekající aktualizace.

Ve všech oblastech Azure se automaticky použijí jenom opravy klasifikované jako kritické nebo zabezpečení . Definujte vlastní procesy správy aktualizací, které používají další opravy.

V případě zásad správného řízení zvažte možnost Vyžadovat automatické opravy imagí operačního systému ve službě Virtual Machine Scale Sets Azure Policy.

Automatické opravy můžou systém zatížit a mohou být rušivé, protože virtuální počítače používají prostředky a můžou se během aktualizací restartovat. Pro správu zatížení se doporučuje nadměrné zřizování. Nasaďte virtuální počítače v různých Zóny dostupnosti, abyste se vyhnuli souběžným aktualizacím a zachovali alespoň dvě instance na zónu pro zajištění vysoké dostupnosti. Virtuální počítače ve stejné oblasti můžou přijímat různé opravy, které by se měly sloučit v průběhu času.

Mějte na paměti kompromis mezi náklady souvisejícími s nadměrným zřízením.

Kontroly stavu jsou součástí automatických oprav hosta virtuálního počítače. Tyto kontroly ověřují úspěšnou aplikaci oprav a detekují problémy.

Pokud existují vlastní procesy pro použití oprav, použijte privátní úložiště pro zdroje oprav. Tím získáte lepší kontrolu nad testováním oprav, abyste měli jistotu, že aktualizace nemá negativní vliv na výkon nebo zabezpečení.

Další informace najdete v tématu Automatické opravy hosta virtuálního počítače pro virtuální počítače Azure.

Spolehlivost

Tato architektura používá zóny dostupnosti jako základní prvek k řešení problémů se spolehlivostí.

V tomto nastavení jsou jednotlivé virtuální počítače svázané s jednou zónou. Pokud dojde k selhání, tyto virtuální počítače je možné snadno nahradit jinými instancemi virtuálních počítačů pomocí škálovacích sad virtuálních počítačů.

Všechny ostatní komponenty v této architektuře jsou následující:

• Zónově redundantní, což znamená, že se replikují napříč několika zónami pro zajištění vysoké dostupnosti, jako jsou Application Gateway nebo veřejné IP adresy.
• Zóna odolná, což znamená, že mohou odolat selhání zón, jako je key vault.
• Regionální nebo globální prostředky, které jsou dostupné napříč oblastmi nebo globálně, jako je například ID Microsoft Entra.

Návrh úloh by měl zahrnovat záruky spolehlivosti v kódu aplikace, infrastruktuře a provozu. Následující části popisují některé strategie, které zajistí odolnost úlohy vůči selháním a jsou schopny se zotavit, pokud dojde k výpadkům na úrovni infrastruktury.

Strategie používané v architektuře vycházejí z kontrolního seznamu kontroly návrhu spolehlivosti, který je uveden v architektuře Azure Well-Architected Framework. Oddíly jsou opatřeny poznámkami z daného kontrolního seznamu.

Vzhledem k tomu, že není nasazena žádná aplikace, odolnost v kódu aplikace přesahuje rozsah této architektury. Doporučujeme zkontrolovat všechna doporučení v kontrolním seznamu a případně je přijmout ve vaší úloze.

Určení priorit záruk spolehlivosti na tok uživatele

Ve většině návrhů existuje několik toků uživatelů, z nichž každý má vlastní sadu obchodních požadavků. Ne všechny tyto toky vyžadují nejvyšší úroveň záruk, takže segmentace se doporučuje jako strategie spolehlivosti. Každý segment je možné spravovat nezávisle a zajistit, aby jeden segment neměl vliv na ostatní a poskytoval správnou úroveň odolnosti v každé vrstvě. Díky tomuto přístupu je systém také flexibilní.

V této architektuře implementují aplikační vrstvy segmentaci. Pro front-endovou a back-endovou vrstvu se zřizují samostatné škálovací sady. Toto oddělení umožňuje nezávislé škálování každé úrovně, což umožňuje mimo jiné implementaci vzorů návrhu na základě jejich specifických požadavků.

Projděte si dobře navrženou architekturu: RE:02 – doporučení pro identifikaci a hodnocení toků.

Identifikace potenciálních bodů selhání

Každá architektura je náchylná k selháním. Při analýze režimu selhání můžete předvídat selhání a připravit se na zmírnění rizik. Tady je několik potenciálních bodů selhání v této architektuře:

Komponenta	Riziko	Pravděpodobnost	účinek/ zmírnění rizik / poznámka	Výpadek
Microsoft Entra ID	Chybná konfigurace	Střední	Ops users unable to sign in. Žádný podřízený účinek. Helpdesk hlásí problém s konfigurací týmu identit.	Nic
Application Gateway	Chybná konfigurace	Střední	Během nasazování by se měly zachytit chybné konfigurace. Pokud k těmto chybám dojde během aktualizace konfigurace, tým DevOps musí vrátit změny zpět. Zřízení většiny nasazení, která používají skladovou položku v2, trvá přibližně 6 minut. V závislosti na typu nasazení ale může trvat déle. Například nasazení napříč několika zónami dostupnosti s mnoha instancemi může trvat déle než 6 minut.	Úplný
Application Gateway	Útok DDoS	Střední	Potenciál přerušení. Microsoft spravuje ochranu před útoky DDoS (L3 a L4). Potenciální riziko dopadu útoků L7.	Úplný
Virtual Machine Scale Sets	Výpadek služby	Nízká	Potenciální výpadek úloh, pokud nejsou v pořádku instance virtuálních počítačů, které aktivují autorepair Závisí na Microsoftu na nápravě.	Potenciální výpadek
Virtual Machine Scale Sets	Výpadek zóny dostupnosti	Nízká	Žádný vliv Škálovací sady se nasazují jako zónově redundantní.	Nic

Projděte si dobře navrženou architekturu: RE:03 – doporučení pro provádění analýzy režimu selhání.

Cíle spolehlivosti

Při rozhodování o návrhu je důležité vypočítat cíle spolehlivosti, jako jsou složeného cíle na úrovni služby (SLA) úlohy. To zahrnuje pochopení smluv o úrovni služeb (SLA) poskytovaných službami Azure používanými v architektuře. SLO úloh nesmí být vyšší než smlouvy SLA garantované Azure. Pečlivě prozkoumejte jednotlivé komponenty z virtuálních počítačů a jejich závislostí, sítí a možností úložiště.

Tady je příklad výpočtu, kde hlavním cílem je poskytnout přibližný složený SLO. I když je to hrubý návod, měli byste přijít na něco podobného. Pokud neuděláte změny architektury, neměli byste pro stejné toky získat vyšší maximální složených SLO.

Tok operace

Komponenta	SLO
Microsoft Entra ID	99,99 %
Azure Bastion	99,95 %

Slo složeného SLO: 99,94% | Výpadek za rok: 0d 5h 15m 20s

Tok uživatele aplikace

Komponenta	SLO
Application Gateway	99,95 %
Azure Load Balancer (interní)	99,99 %
Front-endové virtuální počítače s využitím služby Premium Storage (složené SLO)	99.70%
Back-endové virtuální počítače využívající úložiště Úrovně Premium (složené SLO)	99.70%

Slo složeného SLO: 99,34% | Prostoje za rok: 2d 9h 42m 18s

V předchozím příkladu jsou zahrnuty spolehlivost virtuálních počítačů a závislostí, jako jsou například disky přidružené k virtuálním počítačům. Smlouvy SLA přidružené k diskovým úložišti mají vliv na celkovou spolehlivost.

Při výpočtu složeného cíle úrovně služeb existují určité problémy. Je důležité si uvědomit, že různé úrovně služeb můžou mít různé smlouvy SLA, a ty často zahrnují finančně zajištěné záruky, které nastavují cíle spolehlivosti. Nakonec můžou existovat komponenty architektury, které nemají definované smlouvy SLA. Například z hlediska sítí, síťových karet a virtuálních sítí nemají vlastní smlouvy SLA.

Obchodní požadavky a jejich cíle musí být jasně definovány a začleněny do výpočtu. Mějte na paměti limity služeb a další omezení, která organizace ukládá. Sdílení předplatného s jinými úlohami může mít vliv na prostředky dostupné pro vaše virtuální počítače. Úloha může být povolená pro použití omezeného počtu jader dostupných pro virtuální počítače. Pochopení využití prostředků vašeho předplatného vám může pomoct efektivněji navrhovat virtuální počítače.

Projděte si dobře navrženou architekturu: RE:04 – doporučení pro definování cílů spolehlivosti.

Redundance

Tato architektura používá zónovou redundanci pro několik komponent. Každá zóna se skládá z jednoho nebo více datacenter s nezávislým napájením, chlazením a sítěmi. Instance spuštěné v samostatných zónách chrání aplikaci před selháními datacentra.

• Škálovací sady virtuálních počítačů přidělují zadaný počet instancí a distribuují je rovnoměrně napříč zónami dostupnosti a doménami selhání. Toto rozdělení se dosahuje maximálním rozložením , které doporučujeme. Šíření instancí virtuálních počítačů napříč doménami selhání zajišťuje, aby se všechny virtuální počítače neaktualizovaly současně.

  Představte si scénář, ve kterém existují tři zóny dostupnosti. Pokud máte tři instance, každá instance se přidělí jiné zóně dostupnosti a umístí se do jiné domény selhání. Azure zaručuje, že se v každé zóně dostupnosti aktualizuje vždy jenom jedna doména selhání. Může se ale stát, že všechny tři domény selhání hostující vaše virtuální počítače napříč třemi zónami dostupnosti se aktualizují současně. Všechny zóny a domény jsou ovlivněné. Při upgradu má alespoň dvě instance v každé zóně vyrovnávací paměť.

• Spravované disky je možné připojit jenom k virtuálnímu počítači ve stejné oblasti. Jejich dostupnost obvykle ovlivňuje dostupnost virtuálního počítače. Pro nasazení v jedné oblasti je možné nakonfigurovat disky tak, aby byly redundantní, aby vydržely chyby zón. V této architektuře jsou datové disky nakonfigurované zónově redundantní úložiště (ZRS) na back-endových virtuálních počítačích. Vyžaduje strategii obnovení, která využívá zóny dostupnosti. Strategie obnovení spočívá v opětovném nasazení řešení. V ideálním případě předem zřiďte výpočetní prostředky v alternativních zónách dostupnosti připravených k zotavení z zónového selhání.

• Zónově redundantní služba Application Gateway nebo standardní nástroj pro vyrovnávání zatížení můžou směrovat provoz do virtuálních počítačů napříč zónami pomocí jedné IP adresy, což zajišťuje kontinuitu i v případě selhání zón. Tyto služby používají sondy stavu ke kontrole dostupnosti virtuálního počítače. Dokud jedna zóna v oblasti zůstane funkční, směrování pokračuje i přes potenciální selhání v jiných zónách. Směrování mezi zónami ale může mít ve srovnání se směrováním uvnitř zóny vyšší latenci.

  Všechny veřejné IP adresy používané v této architektuře jsou zónově redundantní.

• Azure nabízí zónově odolné služby pro lepší spolehlivost, jako je key Vault.

• Globální prostředky Azure jsou vždy dostupné a v případě potřeby se můžou přepnout do jiné oblasti, jako je například základní zprostředkovatel identity, Microsoft Entra ID.

Projděte si dobře navrženou architekturu: RE:05 – doporučení pro navrhování redundance.

Strategie škálování

Pokud chcete zabránit snížení a selhání na úrovni služby, zajistěte spolehlivé operace škálování. Horizontální škálování úlohy (horizontální navýšení kapacity), vertikální (vertikální navýšení kapacity) nebo použití kombinace obou těchto přístupů. Pomocí automatického škálování služby Azure Monitor zřiďte dostatek prostředků pro podporu požadavků na vaši aplikaci, aniž byste museli přidělit větší kapacitu, než je potřeba, a účtují se zbytečné náklady.

Automatické škálování umožňuje definovat různé profily na základě různých typů událostí, jako je čas, plán nebo metriky. Profily založené na metrikách můžou používat integrované metriky (na základě hostitele) nebo podrobnější metriky (metriky virtuálních počítačů hosta), které vyžadují instalaci agenta služby Azure Monitor ke shromažďování. Každý profil obsahuje pravidla pro horizontální navýšení kapacity (zvýšení) a horizontální snížení kapacity (snížení). Zvažte prozkoumání všech různých scénářů škálování na základě navržených profilů a jejich vyhodnocení pro potenciální podmínky smyčky, které můžou způsobit řadu protichůdných událostí škálování. Azure Monitor se pokusí tuto situaci zmírnit tím, že před opětovným škálováním čeká na období cooldownu.

I když škálovací sady virtuálních počítačů Azure v flexibilním režimu podporují heterogenní prostředí, automatické škálování více profilů se nepodporuje. Pokud plánujete používat automatické škálování s více než jedním typem virtuálního počítače, zvažte vytvoření různých škálovacích sad pro jejich správu samostatně.

Při vytváření nebo odstraňování instancí virtuálních počítačů zvažte další aspekty, jako je spouštění, řádné vypnutí, instalace úlohy a všechny její závislosti a správa disků.

Stavové úlohy můžou vyžadovat dodatečnou správu spravovaných disků, které potřebují žít mimo instanci úlohy. Navrhněte svou úlohu pro správu dat v rámci událostí škálování pro konzistenci, synchronizaci, replikaci a integritu dat úlohy. Pro tyto scénáře zvažte přidání předem vyplněných disků do škálovacích sad. V případech, kdy se škálování používá k zabránění kritickým bodům při přístupu k datům, naplánujte dělení a horizontální dělení. Další informace najdete v tématu Osvědčené postupy automatického škálování.

Projděte si dobře navrženou architekturu: RE:06 – doporučení pro návrh spolehlivé strategie škálování.

Samoopravení a obnovitelnost

Automatické opravy instancí jsou povolené ve škálovacích sadách virtuálních počítačů, aby se automatizovala obnovení ze selhání virtuálních počítačů. Rozšíření stavu aplikace se nasadí do virtuálních počítačů, aby podporovalo detekci nereagovaných virtuálních počítačů a aplikací. U těchto instancí se automaticky aktivují akce opravy.

Podívejte se na dobře navrženou architekturu: Doporučení pro samoopravení a sebezáchování.

Zabezpečení

Tato architektura znázorňuje některé záruky zabezpečení uvedené v kontrolním seznamu pro kontrolu návrhu zabezpečení uvedené v architektuře Azure Well-Architected Framework. Oddíly jsou opatřeny poznámkami z daného kontrolního seznamu.

Zabezpečení neodkazuje jenom na technické kontroly. Doporučujeme postupovat podle celého kontrolního seznamu, abyste porozuměli provozním aspektům pilíře zabezpečení.

Segmentace

• Segmentace sítě. Prostředky úloh se umístí do virtuální sítě, která poskytuje izolaci od internetu. V rámci virtuální sítě je možné podsítě použít jako hranice důvěryhodnosti. Spoluvytáháte související prostředky potřebné ke zpracování transakce v jedné podsíti. V této architektuře je virtuální síť rozdělena do podsítí na základě logického seskupení aplikace a účelu různých služeb Azure používaných v rámci úlohy.

  Výhodou segmentace podsítě je, že můžete umístit kontrolní mechanismy zabezpečení na hraniční síť, která řídí provoz proudící do podsítě a z této podsítě, čímž omezíte přístup k prostředkům úloh.

• Segmentace identit Přiřaďte různé role různým identitám s oprávněními dostatečnými oprávněními k jejich úkolu. Tato architektura používá identity spravované id Microsoft Entra k segmentování přístupu k prostředkům.

• Segmentace prostředků Aplikace je segmentována podle vrstev do samostatných škálovacích sad, což zajišťuje, že komponenty aplikace nejsou společně přiděleny.

Projděte si dobře navrženou architekturu: SE:04 – doporučení pro vytváření strategie segmentace.

Správa identit a přístupu

Pro ověřování a autorizaci uživatelů a služeb doporučujeme Microsoft Entra ID .

Přístup k virtuálním počítačům vyžaduje uživatelský účet řízený ověřováním Microsoft Entra ID a podporovanými skupinami zabezpečení. Tato architektura poskytuje podporu nasazením rozšíření ověřování Microsoft Entra ID do všech virtuálních počítačů. Doporučujeme, aby uživatelé používali své firemní identity v tenantovi Microsoft Entra ID organizace. Také se ujistěte, že se mezi funkcemi nesdílí přístup založený na instančním objektu.

Prostředky úloh, jako jsou virtuální počítače, se ověřují pomocí přiřazených spravovaných identit k jiným prostředkům. Tyto identity založené na instančních objektech Microsoft Entra ID se automaticky spravují.

Rozšíření služby Key Vault se například instalují na virtuální počítače, které spouští virtuální počítače s nainstalovanými certifikáty. V této architektuře používají spravované identity přiřazené uživatelem služba Application Gateway, front-endové virtuální počítače a back-endové virtuální počítače pro přístup ke službě Key Vault. Tyto spravované identity se konfigurují během nasazování a používají se k ověřování ve službě Key Vault. Zásady přístupu ve službě Key Vault jsou nakonfigurované tak, aby přijímaly pouze požadavky z předchozích spravovaných identit.

Základní architektura používá kombinaci spravovaných identit přiřazených systémem a přiřazených uživatelem. Tyto identity jsou potřeba k použití ID Microsoft Entra pro autorizační účely při přístupu k jiným prostředkům Azure.

Projděte si dobře navrženou architekturu: SE:05 – doporučení pro správu identit a přístupu.

Síťové ovládací prvky

• Příchozí provoz. Virtuální počítače úloh nejsou přímo vystavené veřejnému internetu. Každý virtuální počítač má privátní IP adresu. Uživatelé úloh se připojují pomocí veřejné IP adresy služby Application Gateway.

  Větší zabezpečení je poskytováno prostřednictvím firewallu webových aplikací, který je integrovaný se službou Application Gateway. Obsahuje pravidla, která kontrolují příchozí provoz a mohou provádět odpovídající akce. WAF sleduje ohrožení zabezpečení aplikace Open Web Application Security Project (OWASP), která brání známým útokům.

• Výchozí přenos dat. U odchozího provozu neexistují žádné kontroly kromě pravidel odchozí skupiny zabezpečení sítě v podsítích virtuálních počítačů. Doporučujeme, aby veškerý odchozí internetový provoz procházel přes jednu bránu firewall. Tato brána firewall je obvykle centrální službou poskytovanou organizací. Tento případ použití se zobrazuje v architektuře standardních hodnot virtuálních počítačů v cílové zóně Azure.

• Východ-západ. Tok provozu mezi podsítěmi je omezený použitím podrobných pravidel zabezpečení.

  Skupiny zabezpečení sítě (NSG) slouží k omezení provozu mezi podsítěmi na základě parametrů, jako je rozsah IP adres, porty a protokoly. Skupiny zabezpečení aplikací (ASG) jsou umístěné na front-endových a back-endových virtuálních počítačích. Používají se se skupinami zabezpečení sítě k filtrování provozu do a z virtuálních počítačů.

• Provozní provoz. Doporučujeme zajistit zabezpečený provozní přístup k úloze prostřednictvím služby Azure Bastion, která eliminuje potřebu veřejné IP adresy. V této architektuře je komunikace přes SSH a je podporovaná virtuálními počítači s Windows i Linuxem. Microsoft Entra ID je integrován s SSH pro oba typy virtuálních počítačů pomocí odpovídajícího rozšíření virtuálního počítače. Tato integrace umožňuje ověření a autorizaci identity operátora prostřednictvím ID Microsoft Entra.

  Alternativně můžete použít samostatný virtuální počítač jako jump box nasazený do vlastní podsítě, kde si můžete nainstalovat výběr nástrojů pro správu a řešení potíží. Operátor přistupuje k jump boxu přes hostitele Služby Azure Bastion. Pak se přihlásí k virtuálním počítačům za nástrojem pro vyrovnávání zatížení z jump boxu.

  V této architektuře je provozní provoz chráněný pomocí pravidel NSG k omezení provozu a přístup k virtuálním počítačům za běhu (JIT) je na virtuálních počítačích povolený. Tato funkce programu Microsoft Defender for Cloud umožňuje dočasný příchozí přístup k vybraným portům.

  K lepšímu zabezpečení použijte Microsoft Entra Privileged Identity Management (PIM). PIM je služba v Microsoft Entra ID, která umožňuje spravovat, řídit a monitorovat přístup k důležitým prostředkům ve vaší organizaci. PIM poskytuje aktivaci rolí na základě času a schválení, aby se zmírnit rizika nadměrných, nepotřebných nebo zneužití přístupových oprávnění k prostředkům, které vás zajímají.

• Privátní připojení ke službám PaaS (Platforma jako služba). Komunikace mezi virtuálními počítači a službou Key Vault je přes Private Link. Tato služba vyžaduje privátní koncové body, které jsou umístěné v samostatné podsíti.

• Ochrana před útoky DDoS Zvažte povolení služby Azure DDoS Protection na veřejných IP adresách vystavených službou Application Gateway a hostitelem služby Azure Bastion k detekci hrozeb. DDoS Protection také poskytuje výstrahy, telemetrii a analýzy prostřednictvím monitorování. Další informace najdete v tématu Azure DDoS Protection: Osvědčené postupy a referenční architektury.

Projděte si dobře navrženou architekturu: SE:06 – doporučení pro sítě a připojení.

Šifrování

• Přenášená data. Uživatelský provoz mezi uživateli a veřejnou IP adresou služby Application Gateway se šifruje pomocí externího certifikátu. Provoz mezi aplikační bránou a front-endovými virtuálními počítači a mezi front-endovými a back-endovými virtuálními počítači se šifruje pomocí interního certifikátu. Oba certifikáty jsou uložené ve službě Key Vault:

  • app.contoso.com: Externí certifikát používaný klienty a službou Application Gateway pro zabezpečený veřejný internetový provoz.
  • *.workload.contoso.com: Certifikát se zástupným znakem používaný komponentami infrastruktury pro zabezpečení interního provozu.

• Neaktivní uložená data. Data protokolu se ukládají na spravovaný disk připojený k virtuálním počítačům. Tato data se automaticky šifrují pomocí šifrování poskytovaného platformou v Azure.

Projděte si dobře navrženou architekturu: SE:07 – doporučení pro šifrování dat.

Správa tajných kódů

Stáhněte si soubor aplikace Visio s touto architekturou.

Key Vault poskytuje zabezpečenou správu tajných kódů, včetně certifikátů TLS. V této architektuře se certifikáty TLS ukládají ve službě Key Vault a načítají se během procesu zřizování spravovanými identitami služby Application Gateway a virtuálními počítači. Po počátečním nastavení tyto prostředky při aktualizaci certifikátů přistupují pouze ke službě Key Vault.

Virtuální počítače používají rozšíření virtuálního počítače služby Key Vault k automatické aktualizaci monitorovaných certifikátů. Pokud se v místním úložišti certifikátů zjistí nějaké změny, rozšíření načte a nainstaluje odpovídající certifikáty ze služby Key Vault. Rozšíření podporuje typy obsahu certifikátů PKCS #12 a PEM.

Projděte si dobře navrženou architekturu: SE:09 – doporučení pro ochranu tajných kódů aplikací.

Optimalizace nákladů

Požadavky na úlohy musí být splněny s ohledem na omezení nákladů. Strategie použité v architektuře jsou založené na kontrolním seznamu pro kontrolu návrhu optimalizace nákladů uvedených v architektuře Azure Well-Architected Framework. Tato část popisuje některé možnosti optimalizace nákladů a obsahuje poznámky s doporučeními z tohoto kontrolního seznamu.

Náklady na komponenty

Místo použití imagí pro obecné účely vyberte image virtuálních počítačů, které jsou optimalizované pro danou úlohu. V této architektuře se pro Windows i Linux volí relativně malé image virtuálních počítačů, které jsou 30 GB. U menších imagí jsou skladové položky virtuálních počítačů s disky také menší, což vede k nižším nákladům, snížení spotřeby prostředků a rychlejšímu nasazení a spouštění. Výhodou je lepší zabezpečení z důvodu snížené plochy.

Implementace obměně protokolů s omezeními velikosti je další strategie úspory nákladů. Umožňuje používat malé datové disky, což může vést k nižším nákladům. Implementace této architektury používá 4 GB disků.

Použití dočasných disků s operačním systémem může také vést k úsporám nákladů a lepšímu výkonu. Tyto disky jsou navržené tak, aby používaly prostředky virtuálních počítačů, za které už platíte, protože jsou nainstalované na disku mezipaměti zřízeném s virtuálním počítačem. Eliminuje náklady na úložiště spojené s tradičními trvalými disky. Vzhledem k tomu, že tyto disky jsou dočasné, nejsou spojené žádné náklady spojené s dlouhodobým úložištěm dat.

Projděte si dobře navrženou architekturu: CO:07 – doporučení pro optimalizaci nákladů na komponenty.

Náklady na tok

Vyberte výpočetní prostředky na základě závažnosti toku. U toků navržených tak, aby tolerovala nedeterminační délku, zvažte použití spotových virtuálních počítačů s flexibilním režimem orchestrace škálovacích sad virtuálních počítačů. Tento přístup může být efektivní pro hostování toků s nízkou prioritou na virtuálních počítačích s nižší prioritou. Tato strategie umožňuje optimalizaci nákladů, ale stále splňuje požadavky různých toků.

Projděte si dobře navrženou architekturu: CO:09 – doporučení pro optimalizaci nákladů na tok.

Škálování nákladů

Pokud je hlavním nákladovým faktorem počet instancí, může být nákladově efektivnější vertikálně navýšit kapacitu zvýšením velikosti nebo výkonu virtuálních počítačů. Tento přístup může vést k úsporám nákladů v několika oblastech:

• Licencování softwaru. Větší virtuální počítače můžou zvládnout více úloh, což může snížit počet potřebných softwarových licencí.
• Doba údržby: Menší počet větších virtuálních počítačů může snížit provozní náklady.
• Vyrovnávání zatížení: Menší počet virtuálních počítačů může vést k nižším nákladům na vyrovnávání zatížení. V této architektuře je například několik vrstev vyrovnávání zatížení, jako je aplikační brána na přední straně a interní nástroj pro vyrovnávání zatížení uprostřed. Pokud je potřeba spravovat vyšší počet instancí, náklady na vyrovnávání zatížení by se zvýšily.
• Diskové úložiště. Pokud existují stavové aplikace, více instancí potřebuje více připojených spravovaných disků, což zvyšuje náklady na úložiště.

Projděte si dobře navrženou architekturu: CO:12 – doporučení pro optimalizaci nákladů na škálování.

Provozní náklady

Automatické opravy hosta virtuálního počítače snižují režii ručních oprav a souvisejících nákladů na údržbu. Tato akce pomáhá nejen zabezpečit systém, ale také optimalizuje přidělování prostředků, což přispívá k celkové efektivitě nákladů.

Projděte si dobře navrženou architekturu: CO:13 – doporučení pro optimalizaci personálního času.

Nasazení tohoto scénáře

Nasazení pro tuto referenční architekturu je k dispozici na GitHubu.

Související prostředky

Podrobnosti o konkrétních službách Azure najdete v dokumentaci k produktu:

• Azure Virtual Machines
• Škálovací sady virtuálních počítačů Azure
• Azure Virtual Network
• Standard_v2 brány Aplikace Azure lication
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Další krok

Projděte si referenční architektury IaaS, které zobrazují možnosti datové vrstvy:

• N-vrstvá aplikace s Windows s využitím SQL Serveru v Azure