Nasazení podniku s vysokou dostupností pomocí služby App Service Environment

Zóny dostupnosti jsou fyzicky oddělené kolekce datacenter v dané oblasti. Nasazení prostředků napříč zónami zajišťuje, že výpadky omezené na zónu neovlivní dostupnost vašich aplikací. Tato architektura ukazuje, jak můžete zlepšit odolnost nasazení služby App Service Environment tak, že ji nasadíte v zóně znovududantní architektuře. Tyto zóny nesouvisí s blízkostí. Můžou se mapovat na různá fyzická umístění pro různá předplatná. Architektura předpokládá nasazení s jedním předplatným.

Služby Azure, které podporují zóny dostupnosti, můžou být zónově redundantní nebo obojí. Zónové služby je možné nasadit do konkrétní zóny. Zónově redundantní služby je možné automaticky nasadit napříč zónami. Podrobné pokyny a doporučení najdete v tématu Podpora zón dostupnosti. App Service Environment podporuje zónově redundantní nasazení.

Když nakonfigurujete službu App Service Environment tak, aby byla zónově redundantní, platforma automaticky nasadí instance plánu služby Aplikace Azure ve třech zónách ve vybrané oblasti. Proto minimální počet instancí plánu služby App Service je vždy tři.

Referenční implementace pro tuto architekturu je k dispozici na GitHubu.

Architektura

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

Prostředky v podsítích služby App Service Environment v této referenční implementaci jsou stejné jako prostředky ve standardní architektuře nasazení služby App Service Environment. Tato referenční implementace využívá zónově redundantní funkce služby App Service Environment v3 a Azure Cache for Redis k zajištění vyšší dostupnosti. Všimněte si, že rozsah této referenční architektury je omezený na jednu oblast.

Workflow

Tato část popisuje povahu dostupnosti služeb používaných v této architektuře:

• App Service Environment v3 je možné nakonfigurovat pro redundanci zón. Redundanci zón můžete nakonfigurovat pouze při vytváření služby App Service Environment a pouze v oblastech, které podporují všechny závislosti služby App Service Environment v3. Každý plán služby App Service v zónově redundantním prostředí App Service Environment musí mít minimálně tři instance, aby je bylo možné nasadit ve třech zónách. Minimální poplatek je pro devět instancí. Další informace najdete v těchto doprovodných materiálech k cenám. Podrobné pokyny a doporučení najdete v tématu Podpora služby App Service Environment pro Zóny dostupnosti.

• Azure Virtual Network zahrnuje všechny zóny dostupnosti, které jsou v jedné oblasti. Podsítě ve virtuální síti také překračují zóny dostupnosti. Další informace najdete v požadavcích na síť pro App Service Environment.

• Application Gateway v2 je zónově redundantní. Podobně jako virtuální síť zahrnuje více zón dostupnosti na každou oblast. Jedna aplikační brána je proto dostatečná pro vysoce dostupný systém, jak je znázorněno v referenční architektuře. Referenční architektura používá skladovou položku WAF služby Application Gateway, která poskytuje zvýšenou ochranu před běžnými hrozbami a ohroženími zabezpečení na základě implementace základní sady pravidel (CRS) projektu OWASP (Open Web Application Security Project). Další informace najdete v tématu Škálování služby Application Gateway v2 a WAF v2.

• Azure Firewall má integrovanou podporu vysoké dostupnosti. Může překračovat více zón bez jakékoli další konfigurace.

  Pokud potřebujete, můžete při nasazování brány firewall také nakonfigurovat konkrétní zónu dostupnosti. Další informace najdete v tématu Azure Firewall a Zóny dostupnosti. (Tato konfigurace se nepoužívá v referenční architektuře.)

• Microsoft Entra ID je vysoce dostupná, vysoce redundantní globální služba, která zahrnuje zóny dostupnosti a oblasti. Další informace naleznete v tématu Postupování dostupnosti Microsoft Entra.

• GitHub Actions poskytuje v této architektuře funkce kontinuální integrace a průběžného nasazování (CI/CD). Vzhledem k tomu, že služba App Service Environment je ve virtuální síti, virtuální počítač se ve virtuální síti používá jako jumpbox k nasazení aplikací v plánech služby App Service. Akce sestaví aplikace mimo virtuální síť. Pokud chcete zvýšit zabezpečení a bezproblémové připojení RDP/SSH, zvažte použití služby Azure Bastion pro jumpbox.

• Azure Cache for Redis je zónově redundantní služba. Zónově redundantní mezipaměť běží na virtuálních počítačích nasazených napříč několika zónami dostupnosti. Tato služba poskytuje vyšší odolnost a dostupnost.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Dostupnost

App Service Environment

Službu App Service Environment můžete nasadit napříč zónami dostupnosti, abyste zajistili odolnost a spolehlivost pro důležité obchodní úlohy. Tato konfigurace se také označuje jako redundance zón.

Když implementujete redundanci zón, platforma automaticky nasadí instance plánu služby App Service napříč třemi zónami ve vybrané oblasti. Proto minimální počet instancí plánu služby App Service je vždy tři. Pokud zadáte kapacitu větší než tři a počet instancí je dělitelný třemi, instance se nasadí rovnoměrně. V opačném případě se všechny zbývající instance přidají do zbývající zóny nebo se nasadí ve zbývajících dvou zónách.

• Při vytváření služby App Service Environment nakonfigurujete zóny dostupnosti.
• Všechny plány služby App Service vytvořené v této službě App Service Environment vyžadují minimálně tři instance. Budou automaticky zónově redundantní.
• Zóny dostupnosti můžete zadat pouze při vytváření nové služby App Service Environment. Nemůžete převést existující službu App Service Environment tak, aby používala zóny dostupnosti.
• Zóny dostupnosti se podporují jenom v podmnožině oblastí.

Další informace najdete v tématu Migrace služby App Service Environment do podpory zóny dostupnosti.

Odolnost

Aplikace, které běží ve službě App Service Environment, tvoří back-endový fond služby Application Gateway. Když požadavek na aplikaci pochází z veřejného internetu, brána předá požadavek aplikaci spuštěné ve službě App Service Environment. Tato referenční architektura implementuje kontroly stavu v rámci hlavního webového front-endu . votingApp Tato sonda stavu zkontroluje, jestli je webové rozhraní API a mezipaměť Redis v pořádku. Kód, který implementuje tuto sondu, uvidíte v Startup.cs:

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Následující kód ukazuje, jak skript commands_ha.azcli konfiguruje back-endové fondy a sondu stavu pro službu Application Gateway:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
  {
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "probePath": "/health"
  }
]

Pokud některý z komponent (webový front-end, rozhraní API nebo mezipaměť) selže se sondou stavu, služba Application Gateway přesměruje požadavek na jinou aplikaci v back-endovém fondu. Tato konfigurace zajišťuje, aby se požadavek vždy směroval do aplikace v plně dostupné podsíti služby App Service Environment.

Sonda stavu se také implementuje ve standardní referenční implementaci. Tam brána jednoduše vrátí chybu, pokud sonda stavu selže. Implementace s vysokou dostupností ale zlepšuje odolnost aplikace a kvalitu uživatelského prostředí.

Optimalizace nákladů

Optimalizace nákladů se týká snížení zbytečných výdajů a zlepšení efektivity provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

Náklady na architekturu s vysokou dostupností jsou podobné nákladům jako u standardního nasazení.

Náklady můžou ovlivnit následující rozdíly:

• Účtuje se vám alespoň devět instancí plánu služby App Service v zónově redundantním prostředí App Service Environment. Další informace najdete v tématu s cenami služby App Service Environment.
• Azure Cache for Redis je také zónově redundantní služba. Zónově redundantní mezipaměť běží na virtuálních počítačích nasazených napříč několika zónami dostupnosti, aby byla zajištěna vyšší odolnost a dostupnost.

Kompromis mezi vysoce dostupným, odolným a vysoce zabezpečeným systémem je vyšší náklady. Pomocí cenové kalkulačky vyhodnoťte své potřeby s ohledem na ceny.

Aspekty nasazení

Tato referenční implementace používá stejný kanál CI/CD na úrovni produkčního prostředí jako standardní nasazení, přičemž pouze jeden jump boxový virtuální počítač. Můžete se ale rozhodnout použít jeden jumpbox pro každou ze tří zón. Tato architektura používá jenom jeden jumpbox, protože jump box nemá vliv na dostupnost aplikace. Jumpbox se používá jenom pro nasazení a testování.

Nasazení tohoto scénáře

Informace o nasazení referenční implementace pro tuto architekturu najdete v souboru readme GitHubu. Použijte skript pro nasazení s vysokou dostupností.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Deep Bhattacharya | Architekt cloudového řešení
• Suhas Rao | Architekt cloudového řešení

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Tuto architekturu můžete upravit horizontálním škálováním aplikací v rámci stejné oblasti nebo napříč několika oblastmi na základě očekávané kapacity zatížení ve špičce. Replikace aplikací v několika oblastech může pomoct zmírnit rizika širších selhání geografických datacenter, jako jsou například zemětřesení nebo jiné přírodní katastrofy. Další informace o horizontálním škálování najdete v tématu Geografické distribuované škálování s využitím služby App Service Environment. U globálního a vysoce dostupného řešení směrování zvažte použití služby Azure Front Door.