Spolehlivost ve službě Aplikace Azure Service

Tento článek popisuje podporu spolehlivosti ve službě Aplikace Azure Service a popisuje jak vnitřní odolnost zón dostupnosti, tak zotavení po havárii napříč oblastmi a provozní kontinuitu. Podrobnější přehled principů spolehlivosti v Azure najdete v tématu Spolehlivost Azure.

Aplikace Azure Service je služba založená na protokolu HTTP pro hostování webových aplikací, rozhraní REST API a mobilních back-endů a přidává do vaší aplikace výkon Microsoft Azure, například:

• Zabezpečení
• Vyrovnávání zatížení
• Automatické škálování
• Automatizovaná správa

Pokud chcete zjistit, jak služba Aplikace Azure Může zvýšit spolehlivost a odolnost úloh aplikace, přečtěte si téma Proč používat App Service?

Podpora zón dostupnosti

Zóny dostupnosti Azure jsou aspoň tři fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Datová centra v každé zóně jsou vybavena nezávislou infrastrukturou napájení, chlazení a sítě. V případě selhání místní zóny jsou zóny dostupnosti navrženy tak, aby v případě ovlivnění jedné zóny, regionální služby, kapacity a vysoké dostupnosti podporovaly zbývající dvě zóny.

Selhání můžou být v rozsahu od selhání softwaru a hardwaru až po události, jako jsou zemětřesení, záplavy a požáry. Odolnost vůči selháním se dosahuje redundancí a logickou izolací služeb Azure. Podrobnější informace o zónách dostupnosti v Azure najdete v tématu Oblasti a zóny dostupnosti.

Služby s podporou zón dostupnosti Azure jsou navržené tak, aby poskytovaly správnou úroveň spolehlivosti a flexibility. Dají se nakonfigurovat dvěma způsoby. Můžou být buď zónově redundantní, s automatickou replikací napříč zónami, nebo zónově, s instancemi připnutými ke konkrétní zóně. Tyto přístupy můžete také kombinovat. Další informace o zónové a zónově redundantní architektuře najdete v tématu Doporučení pro použití zón dostupnosti a oblastí.

Aplikace Azure Službu je možné nasadit napříč zónami dostupnosti (AZ), abyste dosáhli odolnosti a spolehlivosti pro důležité obchodní úlohy. Tato architektura se také označuje jako redundance zón.

Když nakonfigurujete službu App Service jako zónově redundantní, platforma automaticky rozšíří instance plánu služby Aplikace Azure napříč třemi zónami ve vybrané oblasti.

Rozšíření instance s zónově redundantním nasazením se určuje uvnitř následujících pravidel, i když se aplikace škáluje a zvětší:

• Minimální počet instancí plánu služby App Service je tři.
• Pokud zadáte kapacitu větší než tři a počet instancí je dělitelný třemi, jsou instance rovnoměrně rozloženy.
• Všechny počty instancí nad rámec 3*N jsou rozloženy do zbývajících jedné nebo dvou zón.

Podpora zóny dostupnosti je vlastností plánu služby App Service. Plány služby App Service je možné vytvořit ve spravovaném prostředí s více tenanty nebo ve vyhrazeném prostředí pomocí služby App Service Environment v3. Další informace o službě App Service Environment v3 najdete v přehledu služby App Service Environment v3.

U služeb App Services, které nejsou nakonfigurované tak, aby byly zónově redundantní, instance virtuálních počítačů nejsou odolné vůči zónám a můžou během výpadku v jakékoli zóně v dané oblasti dojít k výpadku.

Informace o architektuře podnikového nasazení najdete v tématu Nasazení podniku s vysokou dostupností pomocí služby App Service Environment.

Požadavky

Aktuální požadavky a omezení pro povolení zón dostupnosti:

• Podporují se Windows i Linux.

• Zóny dostupnosti se podporují jenom na novějších stopách služby App Service. I když používáte některou z podporovaných oblastí, zobrazí se chyba, pokud vaše skupina prostředků nepodporuje zóny dostupnosti. Pokud chcete zajistit, aby vaše úlohy přistály na razítku, které podporuje zóny dostupnosti, možná budete muset vytvořit novou skupinu prostředků, plán služby App Service a službu App Service.

• Váš plán služby App Services musí být jedním z následujících plánů, které podporují zóny dostupnosti:

  • V prostředí s více tenanty s využitím plánů App Service Premium v2 nebo Premium v3.
  • Ve vyhrazeném prostředí s využitím služby App Service Environment v3, které se používá s plány izolované služby App Service v2.

• Pro vyhrazená prostředí musí být služba App Service Environment v3.

  Důležité

  App Service Environment v2 a v1 budou vyřazeny 31. srpna 2024. App Service Environment v3 je jednodušší používat a běží na výkonnější infrastruktuře. Další informace o službě App Service Environment v3 najdete v přehledu služby App Service Environment. Pokud aktuálně používáte App Service Environment v2 nebo v1 a chcete upgradovat na verzi 3, postupujte podle kroků v tomto článku a migrujte na novou verzi.

• Vynucuje se minimální počet instancí tří zón. Pokud zadáte méně než tři instance, platforma vynutí tento minimální počet na pozadí.

• Zóny dostupnosti je možné zadat pouze při vytváření nového plánu služby App Service. Existující plán služby App Service nejde převést na použití zón dostupnosti.

• Následující oblasti podporují Aplikace Azure Služby spuštěné v prostředích s více tenanty:

  • Austrálie – východ
  • Brazílie – jih
  • Střední Kanada
  • Indie – střed
  • USA – střed
  • Východní Asie
  • East US
  • USA – východ 2
  • Francie – střed
  • Německo – středozápad
  • Izrael - střed
  • Itálie - sever
  • Japonsko – východ
  • Jižní Korea – střed
  • Mexiko – střed
  • Severní Evropa
  • Norsko – východ
  • Střední Polsko
  • Střední Katar
  • Jižní Afrika – sever
  • Středojižní USA
  • Southeast Asia
  • Španělsko – střed
  • Švédsko – střed
  • Švýcarsko – sever
  • Spojené arabské emiráty – sever
  • Velká Británie – jih
  • Západní Evropa
  • Západní USA 2
  • USA – západ 3
  • Microsoft Azure provozovaný společností 21Vianet – Čína – sever 3
  • Azure Government – US Gov – Virginie

• Pokud chcete zjistit, které oblasti podporují zóny dostupnosti pro App Service Environment v3, přečtěte si oblasti.

Vytvoření prostředku s povolenou zónou dostupnosti

Nasazení zónově redundantní služby App Service s více tenanty

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

"resources": [
  {
    "type": "Microsoft.Web/serverfarms",
    "apiVersion": "2018-02-01",
    "name": "your-appserviceplan-name-here",
    "location": "West US 3",
    "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "size": "P1v3",
        "family": "Pv3",
        "capacity": 3
    },
    "kind": "app",
    "properties": {
        "zoneRedundant": true
    }
  }
]

Nasazení zónově redundantní služby App Service pomocí vyhrazeného prostředí

Informace o vytvoření služby App Service Environment v3 v plánu Izolované verze 2 najdete v tématu Vytvoření služby App Service Environment.

Řešení problému

Odolnost proti chybám

Pokud se chcete připravit na selhání zóny dostupnosti, měli byste kapacitu služby nadříznout, abyste zajistili, že řešení dokáže tolerovat ztrátu kapacity 1/3 a dál fungovat bez snížení výkonu během výpadků v celé zóně. Vzhledem k tomu, že platforma rozloží virtuální počítače mezi tři zóny a potřebujete počítat s alespoň selháním jedné zóny, vynásobte počet instancí úloh ve špičce faktorem zón/(zóny-1) nebo 3/2. Pokud například typická úloha ve špičce vyžaduje čtyři instance, měli byste zřídit šest instancí: (2/3 × 6 instancí) = 4 instance.

Prostředí pro zónu dolů

Provoz se směruje do všech dostupných instancí služby App Service. V případě výpadku zóny platforma služby App Service rozpozná ztracené instance a automaticky se pokusí najít nové náhradní instance a podle potřeby rozloží provoz. Pokud máte nakonfigurované automatické škálování a pokud se rozhodnete, že je potřeba více instancí, automatické škálování také vydá žádost službě App Service o přidání dalších instancí. Všimněte si, že chování automatického škálování je nezávislé na chování platformy služby App Service a že specifikace počtu instancí automatického škálování nemusí být násobkem tří.

Aplikace nasazené v plánu služby App Service s povolenými zónami dostupnosti budou dál spouštět a obsluhovat provoz, i když dojde k výpadku jiných zón ve stejné oblasti. Je však možné, že chování mimo modul runtime, včetně škálování plánu služby App Service, vytváření aplikací, konfigurace aplikace a publikování aplikací, může mít stále vliv na výpadky v jiných Zóny dostupnosti. Redundance zón pro plány služby App Service zajišťuje pouze trvalou dobu provozu pro nasazené aplikace.

Když platforma App Service přiděluje instance zónově redundantnímu plánu služby App Service, využívá vyrovnávání zón s nejlepším úsilím, které nabízí základní škálovací sady virtuálních počítačů Azure. Plán služby App Service bude "vyvážený", pokud každá zóna má buď stejný počet virtuálních počítačů, nebo +/- jeden virtuální počítač ve všech ostatních zónách používaných plánem služby App Service.

Migrace zóny dostupnosti

Z podpory zóny dostupnosti nemůžete migrovat existující instance služby App Service ani prostředky prostředí z podpory zóny dostupnosti. Pokud chcete získat podporu zón dostupnosti, budete muset vytvořit prostředky s povolenými zónami dostupnosti.

Ceny

Pro víceklientská prostředí využívající plány App Service Premium v2 nebo Premium v3 nejsou žádné další náklady spojené s povolením zón dostupnosti, pokud máte v plánu služby App Service tři nebo více instancí. Budou se vám účtovat poplatky na základě skladové položky plánu služby App Service, vámi zadané kapacity a všech instancí, na které škálujete na základě kritérií automatického škálování. Pokud povolíte zóny dostupnosti, ale zadáte kapacitu menší než tři, platforma vynutí minimální počet instancí tří a za tyto tři instance se vám bude účtovat poplatek. App Service Environment v3 má jiný cenový model pro zóny dostupnosti. Informace o cenách služby App Service Environment v3 najdete v tématu Ceny.

Zotavení po havárii napříč oblastmi a provozní kontinuita

Zotavení po havárii (DR) se týká zotavení z událostí s vysokým dopadem, jako jsou přírodní katastrofy nebo neúspěšná nasazení, která vedou k výpadkům a ztrátě dat. Bez ohledu na příčinu je nejlepším řešením havárie dobře definovaný a otestovaný plán zotavení po havárii a návrh aplikace, který aktivně podporuje zotavení po havárii. Než začnete přemýšlet o vytvoření plánu zotavení po havárii, přečtěte si doporučení pro návrh strategie zotavení po havárii.

Pokud jde o zotavení po havárii, Microsoft používá model sdílené odpovědnosti. V modelu sdílené odpovědnosti Microsoft zajišťuje, aby byly dostupné základní služby infrastruktury a platformy. Současně mnoho služeb Azure automaticky nereplikuje data nebo se vrátí z oblasti, která selhala, aby se křížově replikovala do jiné povolené oblasti. Za tyto služby zodpovídáte za nastavení plánu zotavení po havárii, který funguje pro vaši úlohu. Většina služeb, které běží na nabídkách PaaS (Platforma jako služba) Azure, poskytuje funkce a pokyny pro podporu zotavení po havárii a pomocí funkcí specifických pro služby můžete podporovat rychlé obnovení , které vám pomůže s vývojem plánu zotavení po havárii.

Tato část popisuje některé běžné strategie pro webové aplikace nasazené do služby App Service.

Když ve službě App Service vytvoříte webovou aplikaci a během vytváření prostředků zvolíte oblast Azure, jedná se o aplikaci v jedné oblasti. Když se oblast během havárie stane nedostupnou, vaše aplikace bude také nedostupná. Pokud vytvoříte stejné nasazení v sekundární oblasti Azure pomocí geografické architektury s více oblastmi, bude vaše aplikace méně náchylná k havárii v jedné oblasti, která zaručuje kontinuitu podnikových procesů. Veškerá replikace dat napříč oblastmi umožňuje obnovit poslední stav aplikace.

Pro IT jsou plány provozní kontinuity z velké části řízeny plánovanou dobou obnovení (RTO) a cílem bodu obnovení (RPO). Další informace o cílech obnovení (RTO) a RPO najdete v tématu Cíle obnovení.

Za normálních okolností je udržování smlouvy SLA kolem RTO nepraktické pro regionální havárie a obvykle byste navrhli strategii zotavení po havárii kolem samotného cíle zotavení po havárii (tj. zaměřte se na obnovení dat a ne na minimalizaci přerušení). S Azure je to ale nejen praktické, ale může být i jednoduché nasadit službu App Service pro automatické geografické převzetí služeb při selhání. Díky tomu můžete aplikace dále prokazovat havárií tím, že se postaráte o RTO i RPO.

V závislosti na požadovaných metrikách RTO a RPO se tři architektury zotavení po havárii běžně používají pro víceklientské služby App Service i pro službu App Service Environment. Každá architektura je popsaná v následující tabulce:

Zotavení po havárii v geografické oblasti s více oblastmi

Existuje několik způsobů, jak replikovat obsah a konfigurace webových aplikací napříč oblastmi Azure v architektuře aktivní-aktivní nebo aktivní-pasivní, například pomocí zálohování a obnovení služby App Service. Zálohování a obnovení ale vytváří snímky k určitému bodu v čase a nakonec vedou k problémům s vytvářením verzí webových aplikací napříč oblastmi. V následující tabulce najdete porovnání pokynů k obnovení zpět a obnovení v porovnání s pokyny k obnovení diaster:

Zálohování a obnovení vs. zotavení po havárii

Abyste se vyhnuli omezením metod zálohování a obnovení, nakonfigurujte kanály CI/CD tak, aby nasazovali kód do obou oblastí Azure. Zvažte použití Azure Pipelines nebo GitHub Actions. Další informace najdete v tématu Průběžné nasazování do služby Aplikace Azure Service.

Detekce výpadků, oznámení a správa

• Doporučujeme nastavit monitorování a výstrahy pro webové aplikace tak, aby v případě havárie včas zobrazovaly oznámení. Další informace najdete v tématu Testy dostupnosti Application Insights.

• Ke správě prostředků aplikace v Azure použijte mechanismus infrastruktury jako kódu (IaC). Při složitém nasazení napříč několika oblastmi je potřeba spravovat oblasti nezávisle a udržovat konfiguraci synchronizovanou napříč oblastmi spolehlivým způsobem, což vyžaduje předvídatelný, testovatelný a opakovatelný proces. Zvažte nástroj IaC, jako jsou šablony Azure Resource Manageru nebo Terraform.

Nastavení detekce zotavení po havárii a výpadku

Pokud se chcete připravit na zotavení po havárii v geografické oblasti s více oblastmi, můžete použít architekturu typu aktivní-aktivní nebo aktivní-pasivní.

Architektura Active-Active

V architektuře zotavení po havárii aktivní-aktivní se identické webové aplikace nasazují ve dvou samostatných oblastech a Služba Azure Front Door se používá ke směrování provozu do obou aktivních oblastí.

S touto ukázkovou architekturou:

• Identické aplikace App Service se nasazují ve dvou samostatných oblastech, včetně cenové úrovně a počtu instancí.
• Veřejný provoz přímo do aplikací app Service je blokovaný.
• Azure Front Door se používá ke směrování provozu do obou aktivních oblastí.
• Během havárie se jedna z oblastí stane offline a Azure Front Door směruje provoz výhradně do oblasti, která zůstává online. RtO během takového geografického převzetí služeb při selhání je téměř nula.
• Soubory aplikací by se měly nasadit do obou webových aplikací s řešením CI/CD. Tím se zajistí, že cíl bodu obnovení je prakticky nulový.
• Pokud vaše aplikace aktivně upravuje systém souborů, nejlepším způsobem, jak minimalizovat cíl bodu obnovení, je zapisovat pouze do připojené sdílené složky Azure Storage místo zápisu přímo do sdílené složky obsahu /home webové aplikace. Pak pro připojenou sdílenou složku použijte funkce redundance služby Azure Storage (GZRS nebo GRS), které mají cíl bodu obnovení přibližně 15 minut.

Kroky vytvoření architektury aktivní-aktivní pro vaši webovou aplikaci ve službě App Service jsou shrnuty takto:

1. Vytvořte dva plány služby App Service ve dvou různých oblastech Azure. Nakonfigurujte dva plány služby App Service stejně.

2. Vytvořte dvě instance webové aplikace s jednou v každém plánu služby App Service.

3. Vytvořte profil služby Azure Front Door pomocí:

   • Koncový bod.
   • Dvě skupiny původu, z nichž každá má prioritu 1. Stejná priorita říká službě Azure Front Door, aby směrovat provoz do obou oblastí rovnoměrně (tedy aktivní-aktivní).
   • Trasa.

4. Omezte síťový provoz na webové aplikace jenom z instance služby Azure Front Door.

5. Nastavte a nakonfigurujte všechny ostatní back-endové služby Azure, jako jsou databáze, účty úložiště a zprostředkovatelé ověřování.

6. Nasaďte kód do obou webových aplikací s průběžným nasazováním.

Kurz: Vytvoření vysoce dostupné aplikace pro více oblastí ve službě Aplikace Azure Service vám ukáže, jak nastavit architekturu aktivní-pasivní. Stejný postup s minimálními změnami (nastavením priority na 1 pro oba původy ve skupině původu ve službě Azure Front Door) získáte aktivní-aktivní architekturu.

Architektura aktivní-pasivní

V tomto přístupu pro zotavení po havárii se identické webové aplikace nasazují ve dvou samostatných oblastech a Služba Azure Front Door se používá ke směrování provozu pouze do jedné oblasti ( aktivní oblast).

S touto ukázkovou architekturou:

• Identické aplikace App Service se nasazují ve dvou samostatných oblastech.

• Veřejný provoz přímo do aplikací app Service je blokovaný.

• Azure Front Door se používá ke směrování provozu do primární oblasti.

• Aby se ušetřily náklady, je sekundární plán služby App Service nakonfigurovaný tak, aby měl méně instancí nebo byl v nižší cenové úrovni. Existují tři možné přístupy:

  • Upřednostňovaný sekundární plán služby App Service má stejnou cenovou úroveň jako primární plán se stejným počtem instancí nebo menším počtem instancí. Tento přístup zajišťuje paritu ve velikosti funkcí i virtuálních počítačů pro dva plány služby App Service. Plánovaná doba obnovení během geografického převzetí služeb při selhání závisí pouze na době horizontálního navýšení kapacity instancí.

  • Méně upřednostňovaný sekundární plán služby App Service má stejný typ cenové úrovně (například PremiumV3), ale menší velikost virtuálního počítače s menšími instancemi. Primární oblast může být například na úrovni P3V3, zatímco sekundární oblast je ve vrstvě P1V3. Tento přístup stále zajišťuje paritu funkcí pro dva plány služby App Service, ale nedostatek parity velikosti může vyžadovat ruční vertikální navýšení kapacity, když se sekundární oblast stane aktivní oblastí. RtO během geografického převzetí služeb při selhání závisí na době vertikálního navýšení kapacity i horizontálního navýšení kapacity instancí.

  • Nejméně upřednostňovaný sekundární plán služby App Service má jinou cenovou úroveň než primární a menší instance. Primární oblast může být například na úrovni P3V3, zatímco sekundární oblast je ve vrstvě S1. Ujistěte se, že sekundární plán služby App Service má všechny funkce, které vaše aplikace potřebuje ke spuštění. Rozdíly v dostupnosti funkcí mezi těmito dvěma můžou způsobit zpoždění obnovení webové aplikace. RtO během geografického převzetí služeb při selhání závisí na době vertikálního navýšení kapacity i horizontálního navýšení kapacity instancí.

• Automatické škálování se konfiguruje v sekundární oblasti v případě, že aktivní oblast přestane být aktivní. Doporučuje se mít podobná pravidla automatického škálování v aktivních i pasivních oblastech.

• Během havárie se primární oblast stane neaktivní a sekundární oblast začne přijímat provoz a stane se aktivní oblastí.

• Jakmile se sekundární oblast aktivuje, aktivuje zatížení sítě předem nakonfigurovaná pravidla automatického škálování pro horizontální navýšení kapacity sekundární webové aplikace.

• Možná budete muset vertikálně navýšit cenovou úroveň sekundární oblasti ručně, pokud ještě nemá potřebné funkce ke spuštění jako aktivní oblast. Například automatické škálování vyžaduje úroveň Standard nebo vyšší.

• Když je primární oblast znovu aktivní, Azure Front Door automaticky směruje provoz zpět do ní a architektura je zpět na aktivní-pasivní jako předtím.

• Soubory aplikací by se měly nasadit do obou webových aplikací s řešením CI/CD. Tím se zajistí, že cíl bodu obnovení je prakticky nulový.

• Pokud vaše aplikace aktivně upravuje systém souborů, nejlepším způsobem, jak minimalizovat cíl bodu obnovení, je zapisovat pouze do připojené sdílené složky Azure Storage místo zápisu přímo do sdílené složky obsahu /home webové aplikace. Pak pro připojenou sdílenou složku použijte funkce redundance služby Azure Storage (GZRS nebo GRS), které mají cíl bodu obnovení přibližně 15 minut.

Kroky vytvoření architektury aktivní-pasivní pro vaši webovou aplikaci ve službě App Service jsou shrnuty takto:

1. Vytvořte dva plány služby App Service ve dvou různých oblastech Azure. Sekundární plán služby App Service je možné zřídit pomocí některého z dříve uvedených přístupů.
2. Nakonfigurujte pravidla automatického škálování pro sekundární plán služby App Service tak, aby se škáluje na stejný počet instancí jako primární, když se primární oblast stane neaktivní.
3. Vytvořte dvě instance webové aplikace s jednou v každém plánu služby App Service.
4. Vytvořte profil služby Azure Front Door pomocí:
   • Koncový bod.
   • Skupina původu s prioritou 1 pro primární oblast.
   • Druhá skupina původu s prioritou 2 pro sekundární oblast. Rozdíl v prioritě dává službě Azure Front Door pokyn, aby preferuje primární oblast, když je online (tedy aktivní-pasivní).
   • Trasa.
5. Omezte síťový provoz na webové aplikace jenom z instance služby Azure Front Door.
6. Nastavte a nakonfigurujte všechny ostatní back-endové služby Azure, jako jsou databáze, účty úložiště a zprostředkovatelé ověřování.
7. Nasaďte kód do obou webových aplikací s průběžným nasazováním.

Kurz: Vytvoření vysoce dostupné aplikace pro více oblastí ve službě Aplikace Azure Service vám ukáže, jak nastavit architekturu aktivní-pasivní.

Pasivní studená architektura

Pomocí pasivní/studené architektury můžete vytvářet a udržovat pravidelné zálohy webových aplikací v účtu Azure Storage, který se nachází v jiné oblasti.

S touto ukázkovou architekturou:

• Jedna webová aplikace se nasadí do jedné oblasti.

• Webová aplikace se pravidelně zálohuje do účtu Azure Storage ve stejné oblasti.

• Replikace záloh mezi oblastmi závisí na konfiguraci redundance dat v účtu úložiště Azure. Pokud je to možné, měli byste svůj účet Azure Storage nastavit jako GZRS . GZRS nabízí synchronní redundanci zón v rámci oblasti i asynchronní v sekundární oblasti. Pokud GZRS není k dispozici, nakonfigurujte účet jako GRS. GZRS i GRS mají cíl bodu obnovení přibližně 15 minut.

• Abyste měli jistotu, že můžete načíst zálohy, když primární oblast účtu úložiště přestane být dostupná, povolte přístup jen pro čtení do sekundární oblasti (z účtu úložiště RA-GZRS nebo RA-GRS). Další informace o navrhování aplikací tak, aby využívaly geografickou redundanci, najdete v tématu Použití geografické redundance k návrhu vysoce dostupných aplikací.

• Během havárie v oblasti webové aplikace musíte ručně nasadit všechny požadované závislé prostředky služby App Service pomocí záloh z účtu Azure Storage, s největší pravděpodobností ze sekundární oblasti s přístupem pro čtení. RtO může být hodiny nebo dny.

• Pokud chcete minimalizovat rto, důrazně doporučujeme mít komplexní playbook, který obsahuje všechny kroky potřebné k obnovení zálohy webové aplikace do jiné oblasti Azure.

Kroky vytvoření pasivní studené oblasti pro webovou aplikaci ve službě App Service jsou shrnuty takto:

1. Vytvořte účet úložiště Azure ve stejné oblasti jako vaše webová aplikace. Zvolte úroveň výkonu Standard a vyberte redundanci jako geograficky redundantní úložiště (GRS) nebo geograficky zónově redundantní úložiště (GZRS).

2. Povolte RA-GRS nebo RA-GZRS (přístup pro čtení pro sekundární oblast).

3. Nakonfigurujte vlastní zálohování pro webovou aplikaci. Můžete se rozhodnout nastavit plán zálohování webových aplikací, například každou hodinu.

4. Ověřte, že záložní soubory webové aplikace je možné načíst sekundární oblast vašeho účtu úložiště.

Zotavení po havárii v geografické oblasti s jednou oblastí

Pokud oblast vaší webové aplikace nemá úložiště GZRS nebo GRS nebo jste v oblasti Azure, která není jedním z párů oblastí, budete muset k vytvoření podobné architektury využít zónově redundantní úložiště (ZRS) nebo místně redundantní úložiště (LRS). Můžete například ručně vytvořit sekundární oblast pro účet úložiště následujícím způsobem:

Kroky vytvoření pasivní studené oblasti bez GRS a GZRS jsou shrnuty takto:

1. Vytvořte účet úložiště Azure ve stejné oblasti vaší webové aplikace. Zvolte úroveň výkonu Standard a vyberte redundanci jako zónově redundantní úložiště (ZRS).

2. Nakonfigurujte vlastní zálohování pro webovou aplikaci. Můžete se rozhodnout nastavit plán zálohování webových aplikací, například každou hodinu.

3. Ověřte, že záložní soubory webové aplikace je možné načíst sekundární oblast vašeho účtu úložiště.

4. Vytvořte druhý účet úložiště Azure v jiné oblasti. Zvolte úroveň výkonu Standard a vyberte redundanci jako místně redundantní úložiště (LRS).

5. Pomocí nástroje, jako je AzCopy, replikujte vlastní zálohování (soubory ZIP, XML a protokol) z primární oblasti do sekundárního úložiště. Příklad:

   azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'
   

   Ke spuštění skriptu replikace podle plánu můžete použít Azure Automation s runbookem pracovního postupu PowerShellu. Ujistěte se, že plán replikace dodržuje podobný plán zálohování webových aplikací.

Další kroky

• Kurz: Vytvoření vysoce dostupné aplikace pro více oblastí ve službě Aplikace Azure Service
• Spolehlivost v Azure