Strategie architektury pro navrhování pro redundanci

vztahuje se na toto doporučení seznamu pro spolehlivost v rámci architektury Azure Well-Architected Framework:

RE:05	Přidejte redundanci na různých úrovních, zejména pro kritické toky, abyste splnili cíle spolehlivosti. Zvažte redundantní komponenty infrastruktury, jako jsou výpočetní prostředky a síť, a několik instancí vašeho řešení.

Tato příručka popisuje doporučení pro přidání redundance v rámci kritických toků v různých vrstvách úloh, což optimalizuje odolnost. Splnění požadavků definovaných cílů spolehlivosti použitím správných úrovní redundance na výpočetní prostředky, data, sítě a další úrovně infrastruktury. Využijte tuto redundanci, abyste svým úlohám poskytli silnou a spolehlivou základnu, na které můžete stavět. Když sestavíte úlohu bez redundance infrastruktury, hrozí vysoké riziko delšího výpadku z důvodu potenciálních selhání.

definice

Termín	Definice
Nadbytečnost	Implementace více identických instancí komponenty pracovního zatížení.
Región	Umístění datacentra Azure.
Polyglotní trvalost	Koncept použití různých technologií úložiště stejnou aplikací nebo řešením k využití nejlepších možností jednotlivých komponent.
Konzistence dat	Míra toho, nakolik je daná datová sada synchronizovaná či nesynchronizovaná v různých úložištích.
Rozkládání	Proces fyzického rozdělení dat do samostatných úložišť dat.
Střep	Strategie horizontálního dělení databáze, která podporuje více instancí úložiště se společným schématem. Data se ve všech instancích nereplikují.

V kontextu spolehlivosti použijte redundanci k tomu, aby obsahovala problémy, které mají vliv na jeden prostředek, a ujistěte se, že tyto problémy nemají vliv na spolehlivost celého systému. Pomocí informací, které jste identifikovali o důležitých tocích a cílech spolehlivosti, můžete provádět informovaná rozhodnutí, která jsou nutná pro redundanci jednotlivých toků.

Můžete mít například několik uzlů webového serveru, které běží najednou. Pokud je tok, který podporují, kritický, můžou všechny uzly potřebovat repliky, které můžou přijímat provoz okamžitě, pokud problém ovlivní celý fond, například úplný výpadek datacentra. Alternativně, protože rozsáhlé problémy jsou vzácné a je nákladné nasadit celou sadu replik, můžete nasadit omezený počet replik, aby tok fungoval ve sníženém stavu, dokud problém nevyřešíte.

Když navrhujete redundanci v kontextu efektivity výkonu, distribuujte zatížení mezi několik redundantních uzlů, abyste zajistili optimální výkon každého uzlu. V souvislosti se spolehlivostí sestavte volnou kapacitu tak, aby absorbovaly selhání nebo poruchy, které ovlivňují jeden nebo více uzlů. Ujistěte se, že náhradní kapacita dokáže absorbovat selhání po celou dobu potřebnou k obnovení ovlivněných uzlů. S tímto rozdílem musí obě strategie spolupracovat. Pokud rozdělíte provoz mezi dva uzly kvůli výkonu a oba běží na 60% využití a jeden uzel selže, je váš zbývající uzel ohrožen zahlceným, protože nemůže fungovat na 120%. Rozložte zatížení na jiný uzel, abyste zajistili, že vaše výkonové a spolehlivostní cíle budou zachovány.

Kompromisy:

• Větší redundance úloh odpovídá většímu počtu nákladů. Pečlivě zvažte přidání redundance a pravidelně prověřujte svou architekturu, abyste měli jistotu, že zajišťujete správnou správu nákladů, zejména když používáte nadbytečné kapacity. Pokud používáte overprovisioning jako strategii odolnosti, vyvažte toto dobře definovanou strategií škálování , abyste minimalizovali neefektivity nákladů.

• Při sestavování ve vysokém stupni redundance může dojít k kompromisům z hlediska výkonu. Například prostředky, které se šíří mezi zónami dostupnosti nebo umístěním, můžou ovlivnit výkon, protože musíte odesílat provoz přes připojení s vysokou latencí mezi redundantními prostředky, jako jsou webové servery nebo databázové instance.

• Různé toky ve stejné úloze můžou mít různé požadavky na spolehlivost. Návrhy redundance specifické pro toky můžou potenciálně zavádět do celkového návrhu složitost.

• Návrh redundance s nízkou latencí znamená, že přijmete riziko ztráty těchto komponent v případě rozsáhlé události, jako je geografická havárie, která přenese všechny instance do offline režimu. Geograficky vzdálené prostředí zotavení po havárii pomáhá toto riziko zmírnit, ale zvyšuje náklady.

Preferujte bezserverové a plně spravované služby, abyste snížili provozní zátěž.

Využijte výhod bezserverových řešení, softwaru jako služby (SaaS) a řešení PaaS (Platforma jako služba), abyste mohli snadno přidávat redundanci k úlohám bez nutnosti spravovat replikaci dat nebo operace převzetí služeb při selhání. Tyto služby implementují redundanci transparentně, což eliminuje provozní zátěž při navrhování a udržování vlastních mechanismů redundance. Při vyhodnocování možností služby upřednostňují spravované služby, které zpracovávají redundanci automaticky oproti přístupům založeným na infrastruktuře, které vyžadují ruční konfiguraci redundance.

Spravované služby Azure poskytují redundanci prostřednictvím různých modelů. Každý model poskytuje různé úrovně abstrakce a jednoduchosti provozu.

Globální služby s integrovanou redundancí: Služby jako Microsoft Entra ID, Azure DNS a Azure Key Vault fungují jako globální služby s automatickou redundancí napříč několika oblastmi. Tyto služby poskytují vlastní odolnost, aniž by od vás vyžadovaly konfiguraci redundance. Automaticky zpracovávají scénáře převzetí služeb při selhání a obnovení transparentně.

Abstraktní modely kapacity: Nabídky, jako jsou Azure Cosmos DB, Azure Databricks a spravované koncové body Azure OpenAI, abstrahují základní složitost infrastruktury za jednotkami kapacity, DTU nebo jinými logickými metrikami. Tyto služby automaticky distribuují vaši úlohu mezi více instancí, zón a oblastí a současně představují zjednodušený model fakturace a správy. Místo správy jednotlivých redundantních instancí zadáte požadavky na kapacitu.

Při návrhu řešení vyhodnoťte, jestli pro každou komponentu existuje možnost spravované služby, a teprve potom implementujete redundanci založenou na infrastruktuře. Spravované služby snižují provozní režii a často poskytují robustnější implementace redundance než vlastní řešení, i když můžou zahrnovat kompromisy v řízení a potenciálně vyšší náklady na každou jednotku kapacity.

Sestavení redundance do úlohy s několika instancemi komponent

Nasaďte několik instancí komponent a služeb infrastruktury, abyste dosáhli odolnosti, kterou vaše úlohy potřebují. Tato základní strategie redundance zajišťuje, že pokud jedna instance selže, ostatní instance můžou i nadále zpracovávat úlohy. Pomocí různých přístupů můžete dosáhnout více instancí. Některé scénáře vyžadují ruční konfiguraci redundance nasazením více prostředků jednotlivě, například několika okruhů Azure ExpressRoute nebo konfigurací Azure Traffic Manageru ve více oblastech. Další služby jsou navržené tak, aby podporovaly více instancí přímo, například nastavení škálovacích sad virtuálních počítačů Azure na pět instancí nebo konfiguraci služby Azure App Service tak, aby spouštěla 10 instancí. Pokud je to možné, upřednostněte služby, které poskytují integrovanou podporu více instancí a možností automatického škálování, protože zjednodušují správu redundance a můžou reagovat na požadavky na spolehlivost i výkon.

Při nasazování redundantních komponent infrastruktury určete, kolik instancí jednotlivých komponent vyhovuje vašim cílům spolehlivosti. Zvažte, jestli potřebujete více instancí všech komponent nebo jenom konkrétních kritických komponent, a určete geografickou distribuci těchto instancí, aby splňovaly vaše požadavky na odolnost. Při nasazování redundantní infrastruktury zvažte následující doporučení.

Výpočetní prostředky:

• Preferují služby, které mají podporu pro integrovanou redundanci. Tyto služby umožňují určit počet instancí, které potřebujete, a mohou za vás zpracovávat distribuci a správu těchto instancí.

• Udržujte výpočetní vrstvu čistou od jakéhokoli stavu, protože jednotlivé uzly, které obsluhují požadavky, mohou být kdykoli odstraněny, poruchové nebo nahrazené.

• Navrhněte a otestujte strategii škálování tak, aby odpovídala vašemu přístupu k redundanci.

Datové prostředky:

• Replikace dat napříč geografickými oblastmi za účelem zajištění odolnosti vůči oblastním výpadkům a katastrofickým selháním.

• Seznamte se s integrovanými možnostmi replikace a redundance služeb stavové platformy , které používáte.

• Určete, jestli je pro funkčnost vaší úlohy nezbytná synchronní nebo asynchronní replikace dat. Další informace najdete v tématu Doporučení pro použití zón dostupnosti a oblastí.

• Geograficky distribuujte data podle podpory vaší služby, abyste minimalizovali dopad geograficky lokalizovaných selhání.

• Automatizovat převzetí funkcí po selhání instance databáze. Automatické převzetí služeb při selhání můžete nakonfigurovat ve více datových službách Azure PaaS. Automatické přepnutí při selhání není vyžadováno pro úložiště dat, která podporují zápisy do více regionů, jako je Azure Cosmos DB. Další informace najdete v tématu Doporučení pro návrh strategie zotavení po havárii.

• Pro svá data používejte nejlepší úložiště dat. Využijte polyglotní trvalost nebo řešení, která používají kombinaci technologií úložiště dat. Data zahrnují více než jen trvalá data aplikace. Zahrnuje také protokoly aplikací, události, zprávy a mezipaměti.

• Zvažte požadavky na konzistenci dat a použijte konečnou konzistenci, pokud to požadavky umožňují. Při distribuci dat použijte odpovídající koordinaci k vynucení záruk silné konzistence. Koordinace může snížit propustnost a zajistit, aby vaše systémy byly úzce propojené, což z nich může být slabší. Pokud například operace aktualizuje dvě databáze, místo aby ji umístila do jednoho oboru transakce, je lepší, pokud systém dokáže přizpůsobit konečnou konzistenci.

• Rozdělte data pro dostupnost. dělení databáze zlepšuje škálovatelnost a může také zlepšit dostupnost. Pokud jeden fragment selže, ostatní fragmenty jsou stále dostupné. Selhání v jednom shardu přeruší pouze podmnožinu celkových transakcí.

• Pokud horizontální dělení není možné, můžete k oddělení datových modelů jen pro čtení a čtení použít model CQRS (Command Query Responsibility Segregation). Přidejte další redundantní databázové instance jen pro čtení, abyste zajistili větší odolnost.

Síťové prostředky:

• Rozhodněte se o spolehlivé a škálovatelné síťové topologii. Použití hvězdicového modelu nebo modelu Azure Virtual WAN vám pomůže uspořádat cloudovou infrastrukturu do logických vzorů, které usnadňují sestavování a škálování návrhu redundance.

• Vyberte odpovídající síťovou službu pro vyrovnávání a přesměrování požadavků v rámci oblastí. Pokud je to možné, použijte globální nebo zónově redundantní služby vyrovnávání zatížení, abyste splnili cíle spolehlivosti.

• Ujistěte se, že jste ve virtuálních sítích a podsítích přidělili dostatečný adresní prostor IP adres pro účely plánovaného využití, včetně požadavků na horizontální navýšení kapacity.

• Ujistěte se, že aplikace může škálovat v rámci limitů portů zvolené platformy pro hostování aplikací. Pokud aplikace zahájí několik odchozích připojení TCP (Transmission Control Protocol) nebo UDP (User Datagram Protocol), může vyčerpat všechny dostupné porty a způsobit nízký výkon aplikace.

• Zvolte skladové položky a nakonfigurujte síťové služby, které můžou splňovat vaše požadavky na šířku pásma a dostupnost. Propustnost brány VPN se liší podle jejich skladové položky. Podpora redundance zón je dostupná pouze pro určité typy modelů nástroje pro vyrovnávání zatížení.

• Ujistěte se, že váš návrh pro zpracování dns (Domain Name System) je vytvořený se zaměřením na odolnost a podporuje redundantní infrastrukturu.

Použití vzoru Razítka nasazení ke zjednodušení přístupu k redundanci

Kromě redundance jednotlivých komponent infrastruktury a služeb rozšiřte strategii redundance na úroveň úloh nasazením více instancí celé úlohy nebo logických skupin prostředků. Postupujte podle vzoru návrhu razítka nasazení a vytvořte opakovatelné samostatné jednotky, které zahrnují všechny prostředky potřebné k doručování úloh konkrétnímu podmnožině uživatelů nebo požadavků.

Razítka nasazení představují posun z úrovně komponenty na redundanci na úrovni úloh. Každé razítko slouží jako úplná jednotka škálování obsahující všechny potřebné prostředky – výpočetní prostředky, úložiště, sítě a závislosti – které můžou fungovat nezávisle. Tento přístup poskytuje klíčové výhody, včetně domén izolovaných selhání, které obsahují poloměr výbuchu, horizontální škálování prostřednictvím dodatečného nasazení kolku místo škálování jednotlivých komponent, flexibilní segmentace podle zeměpisné oblasti nebo požadavků a zjednodušené operace prostřednictvím identických opakovatelných jednotek.

Bez ohledu na to, jestli nasadíte razítka v modelu aktivní-aktivní (kde všechna razítka aktivně obsluhují provoz současně) nebo pasivní model typu aktivní-pasivní (kde jedno razítko obsluhuje provoz, zatímco ostatní zůstávají v pohotovostním režimu), navrhujte každé razítko tak, aby bylo kompletní, samoobslužné nasazení, které dokáže zpracovat jeho určenou úlohu nezávisle.

Dosažení nulového výpadku prostřednictvím redundance aktivní-aktivní

Nasazení aktivní-aktivní maximalizují dostupnost služby spuštěním více instancí úlohy současně, přičemž každý aktivně zpracovává provoz. Toto nastavení zajišťuje okamžité převzetí služeb při selhání, eliminuje výpadky a optimalizuje využití prostředků tím, že zajistí produktivitu všech instancí. Pokud jedna instance selže, provoz se automaticky znovu směruje na instance, které jsou v pořádku, aniž by došlo k narušení služby.

Například platforma elektronického obchodování během období špičky může udržovat bezproblémové operace i v případě, že jedno nasazení narazí na problémy. Konfigurace aktivní-aktivní jsou ideální pro klíčové úlohy, které vyžadují nepřerušenou dostupnost, ale mají vyšší náklady na infrastrukturu a složitost. Pokročilé provozní strategie se vyžadují ke správě více živých prostředí, zajištění konzistence dat a koordinaci aktualizací ve všech instancích.

Následující části popisují možnosti konfigurace pro nasazení aktivní-aktivní.

• Aktivní-aktivní v kapacitě: Zrcadlené razítka nasazení ve dvou nebo více umístěních, z nichž každá je nakonfigurovaná tak, aby zpracovávala produkční úlohy pro umístění nebo umístění, která obsluhují, a škálovatelná pro zpracování zatížení z jiných umístění, pokud dojde k výpadku oblasti.

  • Síťování: K rozložení provozu mezi umístění použijte latenci nebo vážené globální směrování.

  • Replikace a konzistence dat: Použijte globálně distribuované úložiště dat, jako je Azure Cosmos DB , pro funkce čtení a zápisu ve více oblastech. Pro relační databáze použijte čtecí repliky s připojovacími řetězci pro čtení.

  • Výhody tohoto návrhu: Nižší provozní náklady než nadměrně zřízený návrh.

  • Nevýhodou tohoto návrhu: Možné snížení uživatelského prostředí při vertikálním navýšení kapacity tak, aby splňovalo požadavky plného zatížení, pokud dojde k výpadku jiného umístění.

• Nadměrné zřízení aktivní-aktivní: Zrcadlené razítka nasazení ve dvou nebo více umístěních, z nichž každá je nadměrná, aby zpracovávala produkční úlohy pro umístění nebo umístění, která obsluhují, a zpracovávala zatížení z jiných umístění, pokud dojde k regionálnímu výpadku.

  • Síťování: K rozložení provozu mezi umístění použijte latenci nebo vážené globální směrování.

  • Replikace a konzistence dat: Použijte globálně distribuované úložiště dat, jako je Azure Cosmos DB , pro funkce čtení a zápisu ve více oblastech. Pro relační databáze použijte čtecí repliky s připojovacími řetězci pro čtení.

  • Výhody tohoto návrhu: Nejodolnější možný návrh.

  • Nevýhodou tohoto návrhu: Vyšší provozní náklady než škálovatelný návrh.

• Běžné výhody obou návrhů: Vysoká odolnost a nízké riziko výpadku plné úlohy

• Běžné nevýhody obou návrhů: Vyšší provozní náklady a režijní zátěž z důvodu různých faktorů, včetně nutnosti správy synchronizace stavu aplikace a dat.

Použití návrhu architektury typu aktivní-pasivní jako nákladově efektivní přístup k obnově po havárii

Konfigurace aktivního pasivního nasazení poskytují nákladově efektivní způsob, jak zajistit zotavení po havárii spuštěním primární instance, která zpracovává veškerý provoz a současně udržuje sekundární instance nečinné, ale připravené. Tyto pohotovostní instance jsou aktivovány pouze v případě, že primární instance selže nebo projde údržbou. Tento přístup minimalizuje využití prostředků a současně poskytuje spolehlivé možnosti převzetí služeb při selhání.

Například finanční obchodní platforma může toto nastavení použít k zachování kontinuity služeb. Primární systém spravuje všechny transakce, zatímco sekundární systém zůstává synchronizovaný na pozadí. Pokud primární systém přestane fungovat, sekundární systém rychle převezme a obnoví operace s minimálním přerušením. Tento přístup vyrovnává spolehlivost a náklady, což je ideální pro úlohy, které mohou tolerovat krátké doby obnovení bez složitosti nebo nákladů na nasazení aktivní-aktivní.

Zvažte následující možnosti konfigurace pro nasazení typu aktivní-pasivní.

• Teplé náhradní díly: Jedno primární umístění a jedno nebo více sekundárních umístění. Sekundární umístění se nasadí s minimální možnou velikostí výpočetních prostředků a dat a spustí se bez načtení. Toto místo se označuje jako teplé náhradní místo. Po převzetí služeb při selhání se výpočetní a datové prostředky škálují tak, aby zpracovávaly zatížení z primárního umístění.

  • Síťování: Použijte globální směrování podle priority .

  • Replikace a konzistence dat: Replikujte databázi do pasivního umístění a použijte funkce automatického převzetí služeb při selhání řešení PaaS, jako je Azure Cosmos DB a Azure SQL Database.

  • Výhody tohoto návrhu: Nejkratší doba obnovení mezi návrhy aktivní-pasivní.

  • Nevýhodou tohoto návrhu: Nejvyšší provozní náklady mezi návrhy aktivní-pasivní.

• Náhradní chlad: Jedno primární umístění a jedno nebo více sekundárních umístění. Sekundární umístění se škáluje tak, aby zvládlo úplné zatížení, ale všechny výpočetní prostředky se zastaví. Toto umístění se označuje jako studené náhradní místo. Před převzetím služeb při selhání je potřeba spustit prostředky.

  • Síťování: Použijte globální směrování podle priority .

  • Replikace a konzistence dat: Replikujte databázi do pasivního umístění a použijte funkce automatického převzetí služeb při selhání řešení PaaS, jako je Azure Cosmos DB a SQL Database.

  • Výhody tohoto návrhu: Nižší provozní náklady než teplá náhradní konstrukce.

  • Nevýhodou tohoto návrhu: Delší doba obnovení než teplá náhradní konstrukce.

Distribuce úloh mezi nezávislou infrastrukturu proximate

Nasazení úloh napříč blízkými nezávislými datovými centry nebo sektory datacentra poskytuje redundanci bez ohrožení výkonu. Díky použití geograficky blízkých, ale fyzicky oddělených zařízení toto nastavení zajišťuje izolaci chyb s minimálním dopadem na latenci. Zajišťuje odolnost distribuované infrastruktury při zachování odezvy nasazení s jednou lokalitou. Zóny dostupnosti v Azure tuto funkci poskytují. Zóny dostupnosti jsou fyzicky nezávislá datacentra nebo sektory datacentra, které jsou navržené tak, abyste mohli snadno nasazovat úlohy odolné proti chybám a nízkou latenci.

U aplikací citlivých na latenci, jako je hraní her v reálném čase, tento přístup umožňuje bezproblémové převzetí služeb při selhání a nepřerušované uživatelské prostředí. Herní servery distribuované napříč místními datacentry můžou okamžitě přesměrovat provoz během výpadků, přičemž transparentní vyrovnávání zatížení a replikace dat téměř v reálném čase zachovává kontinuitu hraní. Tato strategie ale nese určité riziko, protože rozsáhlé regionální události můžou mít stále vliv na všechny weby současně.

Posílení odolnosti proti chybám pomocí geograficky vzdálených nasazení

Nasazení napříč geograficky distribuovanými datovými centry poskytuje nejsilnější ochranu před rozsáhlými katastrofami tím, že rozprostírá úlohy napříč oblastmi stovky nebo tisíce kilometrů od sebe. Tento přístup zajišťuje kontinuitu podnikových procesů během událostí, jako jsou přírodní katastrofy, selhání infrastruktury nebo geopolitické přerušení, které můžou ovlivnit celé metropolitní oblasti. V Azure můžete nasadit úlohy do oblastí, které jsou rozložené po celém světě. Při použití tohoto přístupu k návrhu zvolte oblasti, které jsou blízko uživatelům, ale jsou geograficky vzdálené, například USA – západ a USA – východ.

Globální finanční platforma může například udržovat nepřerušenou službu směrováním provozu do ovlivněných oblastí, pokud dojde k významnému výpadku jedné oblasti. Tento přístup maximalizuje odolnost a podporuje dodržování právních předpisů napříč jurisdikcemi, ale přináší vyšší latenci, složité požadavky na konzistenci dat a vyšší provozní režii. Tyto faktory musíte pečlivě zvážit proti výhodám globální redundance.

Usnadnění pro Azure

Platforma Azure pomáhá optimalizovat odolnost vaší úlohy a přidat redundanci provedením následujících akcí:

• Pomůže vám vybrat nejlepší oblasti Azure pro vaši architekturu s více oblastmi pomocí průvodce Vybrat oblasti Azure.

• Poskytuje integrovanou redundanci s mnoha řešeními PaaS a SaaS, z nichž některé jsou konfigurovatelné.

• Poskytuje globální spravované služby, jako je Microsoft Entra ID, Azure DNS a Key Vault, které transparentně implementují redundanci bez nutnosti konfigurace.

• Umožňuje navrhovat a implementovat redundanci uvnitř oblastí pomocí zón dostupnosti a redundance mezi oblastmi.

• Poskytuje zónově redundantní výpočetní řešení, jako jsou škálovací sady virtuálních počítačů, která můžou automaticky rozložit výpočetní prostředky rovnoměrně mezi zóny dostupnosti při nasazování virtuálních počítačů.

• Poskytuje služby vyrovnávání zatížení pracující s replikou, jako je Azure Application Gateway, Azure Front Door a Azure Load Balancer.

• Poskytuje snadno implementovaná řešení geografické replikace, jako je aktivní geografická replikace pro SLUŽBU SQL Database. Implementujte globální distribuci a transparentní replikaci pomocí služby Azure Cosmos DB. Azure Cosmos DB nabízí dvě možnosti pro zpracování konfliktních zápisů. Zvolte nejlepší možnost pro vaši úlohu.

• Poskytuje možnosti obnovení k určitému bodu v čase (PITR) pro mnoho datových služeb PaaS.

• Snižuje vyčerpání portů přes Azure NAT Gateway nebo Azure Firewall.

Usnadnění specifické pro DNS Azure

• Pro scénáře interního překladu názvů použijte privátní zóny Azure DNS, které mají integrovanou redundanci zón a geografickou redundanci. Další informace najdete v tématu odolnost privátní zóny Azure DNS.

• Pro scénáře překladu externích názvů použijte veřejné zóny Azure DNS, které mají integrovanou redundanci zón a geografickou redundanci.

• Veřejné a privátní služby Azure DNS jsou globální služby odolné vůči oblastním výpadkům, protože data zón jsou globálně dostupná.

• Pro scénáře hybridního překladu názvů mezi místním a cloudovým prostředím použijte Azure DNS Private Resolver. Tato služba podporuje redundanci zón, pokud je vaše úloha umístěná v oblasti, která podporuje zóny dostupnosti. Výpadek na úrovni zóny nevyžaduje během obnovení zóny žádnou akci. Služba se automaticky sama opravuje a přizpůsobuje, aby efektivně využila zdravou zónu. Další informace viz Odolnost v Azure DNS Private Resolver.

• Pokud chcete odstranit jediný bod selhání a dosáhnout odolnějšího hybridního překladu ip adres napříč oblastmi, nasaďte dva nebo více privátních překladačů Azure DNS napříč různými oblastmi. Převzetí služeb při selhání DNS ve scénáři podmíněného předávání se dosahuje přiřazením překladače jako primárního serveru DNS. Přiřaďte druhý resolver v jiném regionu jako sekundární server DNS. Další informace najdete v tématu Nastavení převzetí služeb při selhání DNS pomocí privátních překladačů.

Použití ochrany proti odstranění za účelem zachování redundance

Redundance pomáhá pouze v případě, že komponenty, které ji poskytují, zůstanou na místě. Náhodné odstranění úložiště dat, zóny DNS nebo vrstvy směrování provozu naruší odolnost a vyžaduje kompletní akce obnovení. Snižte dopad lidských chyb použitím zámků Azure CanNotDelete.

Kompromis: Použití zámků zpomaluje legitimní procesy obnovy a může vytvářet provozní problémy. Zámky blokují odstranění prostředku, ale nikoliv změny či data uvnitř prostředku. Zacházejte se zámky jako s tenkou bezpečnostní sítí, která doplňuje, nikdy nenahrazuje zálohy, replikaci a řízení přístupu.

Příklad

Příklad nasazení s více oblastmi a redundancí najdete v tématu Základní parametry vysoce dostupné webové aplikace s redundancí zón.

Následující diagram znázorňuje další příklad.

Související odkazy

Další informace o redundanci najdete v následujících zdrojích informací:

• Průvodce oblastmi Azure
• redundance služby Azure Storage
• zónově redundantní úložiště
• Aktivní geografická replikace služby SQL Database
• Konfigurace replikace mezi dvěma spravovanými instancemi

Kontrolní seznam pro spolehlivost

Projděte si kompletní sadu doporučení.

kontrolní seznam spolehlivosti