Tato referenční architektura představuje sadu osvědčených postupů ke spuštění n-vrstvé aplikace v několika oblastech Azure, aby bylo možné dosáhnout dostupnosti a robustní infrastruktury pro zotavení po havárii.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Workflow
Primární a sekundární oblasti. Abyste dosáhli vysoké dostupnosti, použijte dvě oblasti. Jedna bude primární oblastí. Druhá oblast bude sloužit k převzetí služeb při selhání.
Azure Traffic Manager. Traffic Manager směruje příchozí žádosti do jedné z oblastí. V normálním provozu směruje žádosti do primární oblasti. Pokud se tato oblast stane nedostupnou, Traffic Manager zajistí převzetí služby při selhání sekundární oblastí. Další informace najdete v části konfigurace Traffic Manageru.
Skupiny prostředků. Vytvořte samostatné skupiny prostředků pro primární oblast, sekundární oblast a pro Traffic Manager. Tato metoda poskytuje flexibilitu při správě jednotlivých oblastí jako jedné kolekce prostředků. Můžete například znovu nasadit jednu oblast, aniž byste museli zastavovat tu druhou. Skupiny prostředků propojte, abyste mohli spustit dotaz, který vypíše všechny prostředky pro danou aplikaci.
Virtuální sítě. Vytvořte samostatnou virtuální síť pro každou oblast. Ujistěte se, že se adresní prostory nepřekrývají.
Skupina dostupnosti AlwaysOn systému SQL Server. Pokud používáte SQL Server, doporučujeme skupiny dostupnosti SQL AlwaysOn pro zajištění vysoké dostupnosti. Vytvořte jednu skupinu dostupnosti, která obsahuje instance SQL Serveru v obou oblastech.
Poznámka:
Zvažte také použití databáze Azure SQL Database, která poskytuje relační databáze jako cloudovou službu. S touto databází nemusíte konfigurovat skupinu dostupnosti ani spravovat převzetí služeb při selhání.
Partnerský vztah virtuálních sítí Vytvoření partnerského vztahu mezi dvěma virtuálními sítěmi a povolením replikace dat z primární oblasti do sekundární oblasti. Další informace najdete v tématu Partnerské vztahy virtuálních sítí.
Komponenty
- Skupiny dostupnosti zajišťují distribuci virtuálních počítačů nasazených v Azure napříč několika izolovanými hardwarovými uzly v clusteru. Pokud dojde k selhání hardwaru nebo softwaru v Rámci Azure, ovlivní to jenom podmnožinu virtuálních počítačů a celé řešení zůstane dostupné a funkční.
- Zóny dostupnosti chrání vaše aplikace a data před selháním datacentra. Zóny dostupnosti jsou samostatná fyzická umístění v rámci oblasti Azure. Každá zóna se skládá z jednoho nebo více datacenter vybavených nezávislým napájením, chlazením a sítěmi.
- Azure Traffic Manager je nástroj pro vyrovnávání zatížení provozu založený na DNS, který distribuuje provoz optimálně. Poskytuje služby napříč globálními oblastmi Azure s vysokou dostupností a odezvou.
- Azure Load Balancer distribuuje příchozí provoz podle definovaných pravidel a sond stavu. Nástroj pro vyrovnávání zatížení poskytuje nízkou latenci a vysokou propustnost, vertikální navýšení kapacity až na miliony toků pro všechny aplikace TCP a UDP. Veřejný nástroj pro vyrovnávání zatížení se v tomto scénáři používá k distribuci příchozího klientského provozu do webové vrstvy. V tomto scénáři se používá interní nástroj pro vyrovnávání zatížení k distribuci provozu z obchodní vrstvy do back-endového clusteru SQL Serveru.
- Azure Bastion poskytuje zabezpečené připojení RDP a SSH ke všem virtuálním počítačům ve virtuální síti, ve které je zřízená. Pomocí služby Azure Bastion můžete chránit virtuální počítače před zveřejněním portů RDP/SSH do vnějšího světa a zároveň zajistit zabezpečený přístup pomocí protokolu RDP/SSH.
Doporučení
Architektura pro více oblastí může poskytnout vyšší dostupnost než nasazení do jedné oblasti. Pokud oblastní výpadek ovlivní primární oblast, můžete použít Traffic Manager a převzít služby při selhání sekundární oblastí. Tato architektura může také pomoct, když jednotlivý subsystém aplikace selže.
Existuje několik obecných přístupů k dosažení vysoké dostupnosti napříč oblastmi:
- Aktivní/pasivní vysoká dostupnost s aktivním pohotovostním režimem: provoz směruje do jedné oblasti, zatímco ta druhá čeká v aktivním pohotovostním režimu. Aktivní pohotovostní režim znamená, že virtuální počítače v sekundární oblasti jsou přidělené a jsou vždy spuštěné.
- Aktivní/pasivní vysoká dostupnost s pasivním pohotovostním režimem: provoz směruje do jedné oblasti, zatímco ta druhá čeká v pasivním pohotovostním režimu. Studený pohotovostní režim znamená, že virtuální počítače v sekundární oblasti se nepřidělují, dokud nebude potřeba převzetí služeb při selhání. Tento přístup je méně nákladný, ale obecně bude trvat déle, než v případě selhání přejde do režimu online.
- Aktivní/aktivní vysoká dostupnost: obě oblasti jsou aktivní, žádosti se mezi ně rozdělují a vyrovnává se tak zatížení. Pokud bude jedna oblast nedostupná, vytáhne se z obměna.
Tato referenční architektura se zaměřuje na aktivní/pasivní vysokou dostupnost s aktivním pohotovostním režimem a pro převzetí služeb při selhání používá Traffic Manager. Můžete nasadit několik virtuálních počítačů pro aktivní pohotovostní režim a podle potřeby škálovat kapacitu.
Oblastní párování
Každá oblast Azure je spárovaná s jinou oblastí na stejném území. Obecně byste měli volit oblasti ze stejného páru oblastí (například USA – východ 2 a USA – střed). Výhody tohoto postupu jsou následující:
- Pokud dojde k rozsáhlému výpadku, je u každého páru upřednostněno obnovení alespoň jedné oblasti.
- Plánované aktualizace systému Azure se u spárovaných oblastí nasazují postupně, aby se minimalizovala doba případného výpadku.
- Páry se nacházejí ve stejné geografické oblasti, aby splňovaly požadavky na rezidenci dat.
Ujistěte se však, že obě oblasti podporují všechny služby Azure, které vaše aplikace potřebuje (viz Služby v jednotlivých oblastech). Další informace o oblastních párech najdete v článku Provozní kontinuita a zotavení po havárii (BCDR): Spárované oblasti Azure.
Konfigurace Traffic Manageru
Při konfiguraci Traffic Manageru zvažte následující body:
- Směrování: Traffic Manager podporuje několik algoritmů směrování. U scénáře popsaném v tomto článku použijte prioritní směrování (dříve nazývané směrování s převzetím služeb při selhání). S tímto nastavením odešle Traffic Manager všechny žádosti do primární oblasti (pokud se nestane nedostupnou). Od tohoto okamžiku služby při selhání automaticky převezme sekundární oblast. Viz Konfigurace metody směrování s převzetím služeb při selhání.
- Sonda stavu: Traffic Manager používá ke sledování dostupnosti každé oblasti sondu protokolu HTTP (nebo HTTPS). Tato sonda kontroluje odpověď HTTP 200 pro zadanou cestu adresy URL. Osvědčeným postupem je vytvořit koncový bod, který bude hlásit celkový stav aplikace, a použít tento koncový bod pro sondu stavu. Jinak by sonda mohla ohlásit funkční koncový bod, přestože by důležité části aplikace ve skutečnosti selhávaly. Další informace najdete v tématu Model monitorování koncových bodů stavu.
Když Traffic Manager převezme služby při selhání, je čas, kdy se klienti nemůžou spojit s aplikací. Dobu trvání ovlivňují následující faktory:
- Sonda stavu musí odhalit, že primární oblast už není dostupná.
- Servery DNS musí aktualizovat záznamy DNS v mezipaměti pro danou IP adresu, která je závislá na DNS hodnotě TTL (Time to Live). Výchozí hodnotou TTL je 300 sekund (5 minut), ale tuto hodnotu můžete při vytváření profilu Traffic Manageru upravit.
Podrobnosti najdete v tématu o monitorování Traffic Manageru.
Pokud Traffic Manager převezme služby při selhání, raději než provést navrácení služeb po obnovení automaticky, ho doporučujeme udělat ručně. Jinak může nastat situace, kdy aplikace přebíhá mezi různými oblastmi. Před navrácením služeb po obnovení si ověřte, že všechny subsystémy aplikace jsou v pořádku.
Traffic Manager automaticky obnoví služby po obnovení ve výchozím nastavení. Pokud chcete tomuto problému zabránit, ručně snižte prioritu primární oblasti po události převzetí služeb při selhání. Předpokládejme například, že priorita primární oblasti je 1 a priorita sekundární oblasti je 2. Po převzetí služeb při selhání nastavte prioritu primární oblasti na 3, abyste automatickému navrácení služeb po obnovení předešli. Až budete připraveni přepnout zpět, aktualizujte prioritu na 1.
Následující příkaz Azure CLI tuto prioritu aktualizuje:
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --priority 3
Dalším přístupem je dočasné zakázání koncového bodu, dokud nebudete připraveni na navrácení služeb po obnovení:
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --endpoint-status Disabled
V závislosti na příčině převzetí služeb při selhání možná budete muset v rámci oblasti znovu nasadit prostředky. Před navrácením služby po obnovení proveďte test provozní připravenosti. Test by měl ověřit například:
- správnou konfiguraci virtuálních počítačů (veškerý software je nainstalovaný, služba IIS je spuštěná atd.)
- stav subsystémů aplikace
- funkční testování (například že databázová vrstva je dostupná z webové vrstvy)
Konfigurace skupin dostupnosti AlwaysOn pro SQL Server
Skupiny dostupnosti AlwaysOn pro SQL Server vyžadují před Windows Serverem 2016 řadič domény a všechny uzly ve skupině dostupnosti musí být ve stejné doméně Active Directory (AD).
Postup konfigurace skupiny dostupnosti:
Umístěte do každé oblasti alespoň dva řadiče domény.
Přiřaďte každému řadiči domény statickou IP adresu.
Vytvoření partnerského vztahu mezi těmito dvěma virtuálními sítěmi, aby mezi nimi bylo možné komunikovat.
Pro každou virtuální síť přidejte IP adresy řadičů domény (z obou oblastí) do seznamu serverů DNS. Můžete k tomu použít následující příkaz rozhraní příkazového řádku. Další informace najdete v tématu Změna serverů DNS.
az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"Vytvořte clustering převzetí služeb při selhání ve Windows Serveru, který obsahuje instance SQL Serveru v obou oblastech.
Vytvořte skupinu dostupnosti AlwaysOn pro SQL Server, která obsahuje instance SQL Serveru jak v primárních, tak i v sekundárních oblastech. Postup najdete v tématu o rozšíření skupiny dostupnosti AlwaysOn na vzdálené datacentrum Azure (PowerShell).
Primární repliku dejte do primární oblasti.
Do primární oblasti dejte také jednu nebo více sekundárních replik. Nakonfigurujte tyto repliky tak, aby používaly synchronní potvrzení s automatickým převzetím služeb při selhání.
Jednu nebo více sekundárních replik dejte do sekundární oblasti. Nakonfigurujte tyto repliky tak, aby používaly asynchronní potvrzení z důvodů výkonu. (Jinak všechny transakce T-SQL musí čekat na dobu odezvy ze sítě do sekundární oblasti.)
Poznámka:
Asynchronní repliky potvrzení nepodporují automatické převzetí služeb při selhání.
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Dostupnost
U komplexní n-vrstvé aplikace nemusíte v sekundární oblasti replikovat celou aplikaci. Místo toho můžete replikovat pouze hlavní subsystém, který je potřeba k podpoře kontinuity podnikových procesů.
Traffic Manager je možným bodem selhání v systému. Pokud služba Traffic Manager selže, klienti nebudou mít během výpadku přístup k vaší aplikaci. Zkontrolujte smlouvu SLA pro Traffic Manager a rozhodněte se, zda použití samotného Traffic Manageru splňuje vaše podnikové požadavky na vysokou dostupnost. Pokud ne, zvažte přidání jiného řešení správy provozu jako navrácení služeb po obnovení. Pokud služba Azure Traffic Manager selže, změňte záznamy CNAME v DNS tak, aby odkazovaly na jinou službu pro správu provozu. (Tento krok je nutné provést ručně a vaše aplikace nebude dostupná, dokud se změny DNS nerozšíří.)
U clusteru SQL Serveru musíte zvážit dva scénáře převzetí služeb při selhání:
Všechny repliky databáze SQL Serveru v primární oblasti selžou. K tomuto selhání může dojít například během regionálního výpadku. V takovém případě musíte služby při selhání skupiny dostupnosti převzít ručně, přestože Traffic Manager služby při selhání převezme na front-endu automaticky. Postupujte podle pokynů v tématu o provedení vynuceného ručního převzetí služeb při selhání skupiny dostupnosti SQL Serveru, které popisuje, jak provést vynucené převzetí služeb při selhání použitím aplikací SQL Server Management Studio, Transact-SQL nebo prostředí PowerShell v SQL Serveru 2016.
Upozorňující
Při vynuceném převzetí služeb při selhání hrozí riziko ztráty dat. Jakmile se primární oblast vrátí do režimu online, pořiďte snímek databáze a použijte nástroj tablediff, abyste našli rozdíly.
Traffic Manager převezme služby při selhání sekundární oblastí, ale primární replika databáze SQL Serveru bude stále k dispozici. Front-endová vrstva může například selhat, aniž by ovlivnila virtuální počítače SQL Serveru. V takovém případě je internetový provoz směrován do sekundární oblasti a ta se stále může připojit k primární replice. Zvýší se však latence, protože připojení SQL Serveru cestují napříč oblastmi. V takovém případě byste měli následujícím způsobem provést ruční převzetí služeb při selhání:
- Repliku databáze SQL Serveru v sekundární oblasti dočasně přepněte na synchronní potvrzování. Tento krok zajistí, že během převzetí služeb při selhání nedojde ke ztrátě dat.
- Převezměte služby při selhání touto replikou.
- Když převezmete služby zpět primární oblastí, obnovte nastavení asynchronního potvrzování.
Možnosti správy
Při aktualizaci nasazení aktualizujte současně pouze jednu oblast, abyste snížili riziko globálního selhání z nesprávné konfigurace nebo chyby v aplikaci.
Otestujte odolnost systému vůči chybám. Zde jsou některé běžné scénáře selhání, které byste měli testovat:
- Vypnutí instancí virtuálních počítačů
- Přetížení prostředků – například procesorů nebo pamětí
- Odpojení nebo zpoždění sítě
- Násilné ukončení procesů
- Vypršení certifikátů
- Simulace hardwarových chyb
- Vypnutí služby DNS na řadičích domény
Změřte dobu zotavení a ověřte, zda splňuje vaše obchodní požadavky. Otestujte také kombinace různých typů selhání.
Optimalizace nákladů
Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.
K odhadu nákladů použijte cenovou kalkulačku Azure. Tady je několik dalších aspektů.
Virtual Machine Scale Sets
Škálovací sady virtuálních počítačů jsou k dispozici ve všech velikostech virtuálních počítačů s Windows. Poplatky se účtují jenom za virtuální počítače Azure, které nasazujete, a všechny přidané základní prostředky infrastruktury, které se spotřebovávají, například úložiště a sítě. Za službu Virtual Machine Scale Sets se neúčtují žádné přírůstkové poplatky.
Cenové možnosti pro jednotlivé virtuální počítače najdete v tématu s cenami virtuálních počítačů s Windows.
SQL server
Pokud zvolíte Azure SQL DBaas, můžete ušetřit náklady, protože nemusíte konfigurovat skupinu dostupnosti AlwaysOn a počítače řadiče domény. Existuje několik možností nasazení od jedné databáze až po spravovanou instanci nebo elastické fondy. Další informace najdete v tématu o cenách Azure SQL.
Informace o cenách virtuálních počítačů s SQL Serverem najdete v tématu Ceny virtuálních počítačů SQL.
Nástrojů pro vyrovnávání zatížení
Účtuje se vám jenom počet nakonfigurovaných pravidel vyrovnávání zatížení a odchozích přenosů. Pravidla příchozího překladu adres (NAT) jsou bezplatná. Za Load Balancer úrovně Standard se neúčtují žádné hodinové poplatky, pokud nejsou nakonfigurovaná žádná pravidla.
Traffic Manager – informace o cenách
Fakturace Traffic Manageru vychází z počtu přijatých dotazů DNS. Na služby, které přijmou víc než jednu miliardu dotazů měsíčně, se poskytuje sleva. Za každý monitorovaný koncový bod se vám také účtují poplatky.
Další informace najdete v části věnované nákladům v tématu Dobře navržená architektura Microsoft Azure.
Ceny partnerských vztahů virtuálních sítí
Nasazení s vysokou dostupností, které používá více oblastí Azure, bude využívat partnerský vztah virtuálních sítí. V rámci stejné oblasti a globálního partnerského vztahu virtuálních sítí se účtují různé poplatky.
Další informace najdete v tématu Ceny virtuální sítě.
DevOps
Ke zřízení prostředků Azure a jejích závislostí použijte jednu šablonu Azure Resource Manageru. Stejnou šablonu použijte k nasazení prostředků do primární i sekundární oblasti. Zahrňte všechny prostředky do stejné virtuální sítě, aby byly izolované ve stejné základní úloze. Zahrnutím všech prostředků usnadníte přidružení konkrétních prostředků úlohy k týmu DevOps, aby tým mohl nezávisle spravovat všechny aspekty těchto prostředků. Tato izolace umožňuje týmům a službám DevOps provádět kontinuální integraci a průběžné doručování (CI/CD).
Můžete také použít různé šablony Azure Resource Manageru a integrovat je se službou Azure DevOps Services k zřizování různých prostředí během několika minut, například k replikaci produkčního prostředí, jako jsou scénáře nebo prostředí zátěžového testování, pouze v případě potřeby, což šetří náklady.
Zvažte použití služby Azure Monitor k analýze a optimalizaci výkonu infrastruktury a monitorování a diagnostice problémů se sítěmi bez protokolování na virtuálních počítačích. Application Insights je ve skutečnosti jednou z komponent služby Azure Monitor, která poskytuje bohaté metriky a protokoly pro ověření stavu kompletního prostředí Azure. Azure Monitor vám pomůže sledovat stav vaší infrastruktury.
Nezapomeňte monitorovat nejen výpočetní prvky podporující kód aplikace, ale také datovou platformu, zejména vaše databáze, protože nízký výkon datové vrstvy aplikace může mít vážné důsledky.
Aby bylo možné otestovat prostředí Azure, ve kterém běží aplikace, mělo by být řízeno verzí a nasazeno pomocí stejných mechanismů jako kód aplikace, pak je možné ho otestovat a ověřit pomocí testovacích paradigmat DevOps.
Další informace najdete v části Efektivita provozu v architektuře Microsoft Azure Well-Architected Framework.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Donnie Trumpower | Vedoucí architekt cloudových řešení
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Související prostředky
Následující architektura používá některé ze stejných technologií: