Spolehlivost ve službě Azure Service Bus

Azure Service Bus je plně spravovaná podniková služba zprostředkovatele zpráv, která poskytuje spolehlivé asynchronní zasílání zpráv pro oddělení aplikací a služeb. Service Bus podporuje fronty pro komunikaci typu point-to-point a témata s předplatným pro vzory zasílání zpráv typu publikování-odběr. Služba poskytuje integrované funkce spolehlivosti, včetně uchovávání zpráv, záruk doručení alespoň jednou a fronty mrtvých dopisů, které zpracovávají neúspěšné zpracování zpráv.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby Service Bus vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti a výpadků oblastí. Zvýrazňuje také některé klíčové informace o smlouvě o úrovni služeb (SLA) služby Service Bus.

Doporučení pro nasazení do produkčního prostředí

Azure Well-Architected Framework poskytuje doporučení týkající se spolehlivosti, výkonu, zabezpečení, nákladů a provozu. Informace o tom, jak tyto oblasti vzájemně ovlivňují a přispívají ke spolehlivému řešení služby App Service, najdete v tématu Osvědčené postupy architektury pro Azure Service Bus v architektuře Azure Well-Architected Framework.

Přehled architektury spolehlivosti

Tato část popisuje některé důležité aspekty fungování služby, které jsou z hlediska spolehlivosti nejrelevantní. Tato část představuje logickou architekturu, která obsahuje některé prostředky a funkce, které nasazujete a používáte. Popisuje také fyzickou architekturu, která poskytuje podrobnosti o tom, jak služba funguje v zákulisí.

Logická architektura

Obor názvů slouží jako kontejner pro správu služby Service Bus a lze ho nakonfigurovat tak, aby používal úroveň Basic, Standard nebo Premium. Službu nakonfigurujete na úrovni oboru názvů přidělením kapacity, konfigurací zabezpečení sítě a povolením Geo-Replication a Geo-Disaster Recovery.

V rámci jmenného prostoru nasadíte fronty a témata, což jsou entity zasílání zpráv s různou sémantikou. Další informace najdete v tématu Fronty, témata a odběry služby Service Bus.

Volitelně můžete nakonfigurovat oddíly ve svém oboru názvů, které rozkládají fronty a témata přes několik zprostředkovatelů zpráv a úložišť zpráv. Jmenný prostor může použít více particí k provádění paralelního zpracování a horizontálního škálování. Service Bus zaručuje pouze řazení v rámci jedné partice. Dělení hraje klíčovou roli při návrhu spolehlivosti vaší aplikace. Při návrhu aplikace můžete využít kompromis mezi maximalizací dostupnosti a konzistencí. Pro úroveň Premium povolíte particionování v oboru názvů. Pro obory názvů úrovně Basic a Standard nakonfigurujete oddíly v entitě a volitelně při odesílání zpráv.

Ke zvýšení dostupnosti aplikací můžete použít Service Bus a přístupy k asynchronnímu návrhu. Další informace najdete v tématu Vzory asynchronního zasílání zpráv a vysoká dostupnost.

Fyzická architektura

Service Bus poskytuje základní výpočetní prostředky a prostředky úložiště. Pro každý obor názvů zpracovává několik zprostředkovatelů zpráv zprávy a několik úložišť zpráv ukládá zprávy. Existují tři kopie úložiště zpráv: jeden primární a dva sekundární. Service Bus uchovává všechny tři kopie synchronizované pro operace správy a dat. Pokud primární kopie selže, jedna ze sekundárních kopií se zvýší na primární bez vnímaných výpadků.

Pro obory názvů, které používají úroveň Basic nebo Standard, poskytuje Service Bus redundanci prostřednictvím sdílené víceklientové infrastruktury, která automaticky replikuje zprávy napříč zónami dostupnosti, pokud jsou k dispozici. Služba udržuje více úložišť zpráv a uchovává všechny kopie synchronizované pro operace správy i dat.

Pro obory názvů úrovně Premium poskytuje Service Bus vyhrazené jednotky zasílání zpráv, z nichž každý má vyhrazené prostředky procesoru a paměti. Obory názvů úrovně Premium se můžou automaticky škálovat na základě požadavků na úlohy. Další informace viz též Aktualizace automatických jednotek zasílání zpráv v oboru názvů služby Azure Service Bus.

Infrastruktura Service Bus zahrnuje několik fyzických počítačů a racků, které jsou rozprostřeny napříč doménami poruch, což snižuje riziko fatálních poruch ovlivňujících váš namespace. V oblastech, ve kterých jsou zóny dostupnosti, se infrastruktura rozšiřuje napříč samostatnými fyzickými datovými centry. Služba implementuje mechanismy transparentní detekce selhání a převzetí služeb při selhání tak, aby fungovala v rámci zaručených úrovní služeb a obvykle bez znatelných přerušení, pokud k takovým selháním dojde.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly při komunikaci se všemi cloudovými rozhraními API, databázemi a dalšími komponentami postupovat podle pokynů pro zpracování přechodných chyb Azure. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Sada SDK služby Azure Service Bus zahrnuje logiku automatického opakování s exponenciálním zpožděním pro operace, které selžou kvůli přechodným podmínkám, jako jsou vypršení časového limitu sítě nebo dočasná nedostupnost služby. Když aplikace dojde k přechodnému odpojení od služby Service Bus, sada SDK se automaticky pokusí znovu připojit pomocí nakonfigurovaných zásad opakování.

Pokud chcete optimalizovat zpracování přechodných chyb ve vašich aplikacích, použijte nejnovější sadu SDK služby Service Bus, která obsahuje nejnovější funkce logiky opakování a správy připojení. Další informace najdete v klientské knihovně služby Azure Service Bus pro .NET.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Service Bus podporuje zónově redundantní nasazení ve všech úrovních služby. Když vytvoříte obor názvů služby Service Bus v podporované oblasti, redundance zón se automaticky povolí bez dalších poplatků. Model zónově redundantního nasazení se vztahuje na všechny funkce služby Service Bus, včetně dělení a relací.

Service Bus transparentně replikuje vaši konfiguraci, metadata a data zpráv napříč několika zónami dostupnosti v dané oblasti. Zónová redundance poskytuje automatické převzetí při selhání bez nutnosti vašeho zásahu. Všechny komponenty služby Service Bus, včetně výpočetních prostředků, sítí a úložiště, se replikují napříč zónami. Service Bus má dostatečné kapacitní rezervy k okamžitému zvládnutí úplné ztráty zóny. I když se celá zóna dostupnosti stane nedostupnou, service Bus bude dál fungovat bez ztráty dat nebo přerušení zasílání zpráv.

Požadavky

• Podpora oblastí: Zónově redundantní obory názvů služby Service Bus je možné nasadit do oblastí Azure s podporou zón dostupnosti. Service Bus automaticky povolí podporu zóny dostupnosti v podporovaném regionu při vytváření oboru názvů, a to bez nutnosti další konfigurace.

• Řady: Všechny úrovně služby Service Bus (Basic, Standard a Premium) podporují zóny dostupnosti bez dalších požadavků.

Úvahy

Obory názvů služby Service Bus zahrnují zoneRedundant vlastnost. Dříve byla tato vlastnost nutná k povolení zón dostupnosti, ale toto chování se změnilo a zoneRedundant vlastnost je zastaralá. Tato vlastnost se může i nadále zobrazovat jako false, i když je povolená redundance zóny. Všechny obory názvů v oblastech se zónami dostupnosti jsou zónově redundantní.

Náklady

Redundance zón ve službě Service Bus nepřidává další náklady.

Konfigurujte podporu zón dostupnosti

Obory názvů služby Service Bus automaticky podporují redundanci zón při nasazení v podporovaných oblastech. Není nutné provádět žádnou další konfiguraci.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když jsou obory názvů služby Service Bus nakonfigurované pro redundanci zón a všechny zóny dostupnosti jsou funkční.

• Směrování provozu mezi zónami Service Bus používá model aktivní - aktivní, kde se zprávy distribuují přes několik zón dostupnosti. Klientská připojení jsou automaticky vyvážená mezi zónami a služba směruje operace do dostupné infrastruktury zasílání zpráv bez ohledu na zónu.

• Replikace dat mezi zónami Service Bus používá synchronní replikaci napříč zónami dostupnosti, včetně metadat a dat zpráv. Více kopií úložiště zpráv musí potvrdit operace zápisu, než budou považovány za úplné a zajistit konzistenci dat napříč zónami během normálních operací.

Chování při selhání zóny

Tato část popisuje, co očekávat, když jsou obory názvů služby Service Bus nakonfigurované pro redundanci zón a dojde k výpadku zóny dostupnosti.

• Detekce a odpověď: Microsoft automaticky rozpozná selhání zóny a spustí přechod do fungujících zón. Pro převzetí služeb při selhání na úrovni zóny se nevyžaduje žádná akce zákazníka.

• Oznámení: Microsoft vás automaticky neoznámí, když je zóna mimo provoz. Azure Service Health ale můžete použít k pochopení celkového stavu služby, včetně jakýchkoli selhání zón, a můžete nastavit upozornění služby Service Health , která vás upozorní na problémy.

• Aktivní žádosti: Během selhání zóny může Service Bus vypustit aktivní žádosti. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

• Očekávaná ztráta dat: Během selhání zóny nedojde ke ztrátě dat, protože Service Bus synchronně replikuje zprávy napříč zónami před potvrzením.

• Očekávaný výpadek: Selhání zóny může způsobit několik sekund výpadku. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

• Přesměrování provozu: Service Bus detekuje ztrátu zóny a automaticky přesměruje nové požadavky na jinou repliku v jedné ze zón dostupnosti, která je v pořádku.

  Sada Service Bus SDK obvykle zpracovává správu připojení a logiku opakování transparentně.

Obnovení zóny

Když se zóna dostupnosti obnoví, Service Bus ji automaticky znovu integruje do aktivní topologie služby. Obnovená zóna začne přijímat nová připojení a zpracovávat zprávy spolu s ostatními zónami. Data, která byla replikována do přeživších zón během výpadku, zůstanou nedotčená a normální synchronní replikace se obnoví napříč všemi zónami. Pro obnovení a opětovné začlenění zóny nemusíte provádět akce.

Testování poruch zón

Service Bus spravuje směrování provozu, převzetí služeb při selhání a obnovu při selhání zón, takže nemusíte ověřovat procesy selhání zón dostupnosti ani poskytovat další informace.

Odolnost proti selháním v celé oblasti

Service Bus poskytuje dva typy podpory pro více oblastí, z nichž obě vyžadují obory názvů úrovně Premium:

• Geografická replikace poskytuje replikaci metadat i dat zpráv mezi primární oblastí a sekundární oblastí. Použijte Geo-Replication pro většinu aplikací, které potřebují zůstat odolné vůči výpadkům oblastí a mají nízkou toleranci pro ztrátu dat zpráv.

• Metadata Geo-Disaster Recovery poskytuje aktivní-pasivní replikování konfigurace a metadat mezi primární a sekundární oblastí, ale nereplikuje samotná data zpráv. Zvažte použití Geo-Disaster Recovery pro aplikace, které zpracovávají vlastní replikaci dat, nebo které nepotřebují replikaci dat.

Obnovení funkcí Geo-Replication a Geo-Disaster Recovery vyžaduje ruční zahájení převzetí služeb při selhání nebo povýšení sekundární oblasti na novou primární oblast. Microsoft neprovádí automaticky převzetí služeb při selhání ani povýšení, ani když vaše primární oblast nefunguje.

Obory názvů na úrovních Basic a Standard nezahrnují nativní funkce pro více oblastí, ale můžete implementovat vzory replikace na úrovni aplikace pomocí více oborů názvů napříč oblastmi. Další informace najdete v části Vlastní řešení pro více oblastí pro odolnost níže.

Geo-Replication

Úroveň Premium podporuje geografickou replikaci. Tato funkce replikuje metadata (například entity, konfiguraci a vlastnosti) a data (například zprávy ve frontách a tématech, včetně vlastností a stavu zpráv) pro jmenný prostor. Nakonfigurujete metodu replikace pro konfiguraci a data ve vašem oboru názvů. Tato funkce zajišťuje, že vaše zprávy zůstanou dostupné v jiné oblasti a v případě potřeby můžete přepnout do sekundární oblasti.

Použijte Geo-Replication pro scénáře, které vyžadují odolnost vůči výpadkům oblastí a mají nízkou toleranci pro ztrátu dat zpráv.

Obor názvů se v podstatě rozšiřuje napříč oblastmi. Jedna oblast slouží jako primární a druhá oblast slouží jako sekundární. Vaše předplatné Azure zobrazuje jeden obor názvů.

Sekundární oblast můžete kdykoli zvýšit na primární oblast. Když povýšíte sekundární oblast, Service Bus přenastaví plně kvalifikovaný název domény oboru názvů na vybranou sekundární oblast a přesune předchozí primární oblast na sekundární oblast. Rozhodnete se, jestli chcete provést plánované povýšení, což znamená, že čekáte na dokončení replikace dat nebo vynucené povýšení, což může vést ke ztrátě dat.

Poznámka:

Service Bus Geo-Replication používá termín povýšení, protože nejlépe vystihuje proces povýšení sekundární oblasti na primární oblast (a později degradování primární oblasti na sekundární oblast). Také se můžete setkat s termínem převzetí služeb při selhání, který se používá k popisu obecného procesu.

Tato část shrnuje důležité aspekty geografické replikace. Projděte si úplnou dokumentaci a seznamte se s tím, jak přesně funguje. Další informace najdete v tématu Geografické replikace služby Service Bus.

Požadavky

• Podpora oblastí: Můžete zvolit libovolnou oblast Azure, která podporuje Service Bus jako primární nebo sekundární oblast. Spárované oblasti Azure nemusíte používat, takže můžete zvolit sekundární oblasti na základě vašich požadavků na latenci, dodržování předpisů nebo rezidenci dat.

• Úroveň: Pokud chcete povolit geografickou replikaci, musí váš obor názvů používat úroveň Premium.

• Obnovení metadat pomocí Geo-Disaster Recovery: Nelze nakonfigurovat obor názvů tak, aby používal současně Geo-Replication a Geo-Disaster Recovery.

Úvahy

• Omezení funkcí: Když povolíte geografickou replikaci, platí určitá omezení. Další informace najdete v tématu Geografické replikace služby Service Bus.

• Privátní koncové body: Pokud pro připojení k namespace používáte privátní koncové body, je také nutné nakonfigurovat sítě v primárních a sekundárních oblastech. Další informace najdete v části Privátní koncové body dokumentace ke službě Azure Event Hubs.

Náklady

Informace o fungování cen pro geografickou replikaci najdete v tématu Ceny.

Konfigurace podpory více oblastí

• Povolte Geo-Replication v novém jmenném prostoru. Chcete-li povolit geografickou replikaci v jmenném prostoru při vytváření, použijte možnost Přepnout režim replikace.

• Migrace z metadat Geo-Disaster Recovery na geografickou replikaci.Můžete přepnout z použití metadat Geo-Disaster Recovery na geografickou replikaci.

• Změňte přístup replikace. Pokud chcete změnit mezi synchronními a asynchronními režimy replikace, přečtěte si téma Přepnout režim replikace.

• Zakažte geografickou replikaci. Pokud chcete zakázat Geo-Replication do sekundární oblasti, přečtěte si téma Odstranění sekundární oblasti.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když je obor názvů služby Service Bus nakonfigurovaný pro geografickou replikaci a primární oblast je funkční.

• Směrování provozu mezi oblastmi: Klientské aplikace se připojují prostřednictvím plně kvalifikovaného názvu domény pro váš jmenný prostor a jejich provoz je směrován do primární oblasti.

  Během normálního provozu aktivně zpracovává zprávy od klientů pouze primární oblast. Sekundární oblast přijímá replikované zprávy, ale jinak zůstává pasivní v pohotovostním režimu.

• Replikace dat mezi oblastmi: Chování replikace dat mezi primární a sekundární oblastí závisí na tom, jestli konfigurujete párování replikace tak, aby používalo synchronní nebo asynchronní replikaci.

  • Synchronní: Zprávy se před dokončením operace zápisu replikují do sekundární oblasti.

    Tento režim poskytuje největší jistotu, že data zpráv jsou v bezpečí, protože je nutné je potvrdit v primární a sekundární oblasti. Synchronní replikace ale podstatně zvyšuje latenci zápisu pro příchozí zprávy. Vyžaduje také, aby sekundární oblast byla k dispozici pro přijetí operace zápisu, takže výpadek v sekundární oblasti způsobí selhání operace zápisu.

    • Asynchronní: Zprávy se zapisují do primární oblasti a operace zápisu se dokončí. Krátce později replikuje zprávy do sekundární oblasti.

    Tento režim poskytuje vyšší propustnost zápisu než synchronní replikace, protože během operací zápisu neexistuje žádná latence replikace mezi oblastmi. Režim asynchronní replikace také může tolerovat ztrátu sekundární oblasti a zároveň povolit operace zápisu v primární oblasti. Pokud má ale primární oblast výpadek, můžou být všechna data, která ještě nebyla replikována do sekundární oblasti, nedostupná nebo ztracená.

    Při konfiguraci asynchronní replikace nakonfigurujete maximální přijatelnou dobu prodlevy pro replikaci. Aktuální prodlevu replikace můžete kdykoli ověřit pomocí metrik služby Azure Monitor.

    Pokud se prodleva asynchronní replikace zvýší nad rámec vámi zadaného maxima, primární oblast začne omezovat příchozí požadavky, aby replikace byla dohoněná. Abyste se této situaci vyhnuli, je důležité vybrat sekundární oblasti, které nejsou příliš geograficky vzdálené, a zajistit, aby vaše kapacita byla dostatečná pro danou propustnost.

    Některé typy metadat se replikují synchronně, i když vyberete režim asynchronní replikace.

    Další informace naleznete v tématu Režimy replikace.

Chování při výpadku oblasti

Tato část popisuje, co očekávat, když je obor názvů služby Service Bus nakonfigurovaný pro Geo-Replication a dojde k výpadku v primární nebo sekundární oblasti.

• Detekce a odpověď: Jste zodpovědní za rozhodnutí, kdy povýšit sekundární region oboru názvů, aby se stal novým primárním regionem. Microsoft toto rozhodnutí nevyvolá a ani za vás nezahájí proces, i když dojde k výpadku oblasti. Navrhovaná kritéria, která byste měli zvážit při rozhodování o převzetí služeb v případě poruchy, najdete v tématu Doporučené scénáře pro aktivaci převzetí.

  Další informace o tom, jak zvýšit úroveň sekundární oblasti na novou primární, naleznete v tématu Tok povýšení.

  Při povýšení sekundární oblasti zvolte, jestli chcete provést plánované povýšení nebo vynucené povýšení. Plánovaná aktualizace čeká, až se sekundární oblast dostane na úroveň, než přijme nový provoz. Tento přístup eliminuje ztrátu dat, ale představuje výpadek.

  Během výpadku v primární oblasti obvykle potřebujete provést vynucené povýšení. Pokud je primární oblast dostupná a aktivujete povýšení z jiného důvodu, můžete zvolit plánované povýšení.

• Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Můžete ale použít Azure Service Health k pochopení celkového stavu služby, včetně všech selhání oblastí, a můžete nastavit upozornění služby Health, která vás upozorní na problémy.

• Aktivní požadavky: Chování závisí na tom, jestli dojde k výpadku regionu v primárním nebo sekundárním regionu:

  • Výpadek primární oblasti: Pokud primární oblast není dostupná, všechny aktivní požadavky se ukončí. Klientské aplikace by měly po dokončení povýšení opakovat operace.

  • Výpadek sekundární oblasti: Výpadek v sekundární oblasti může způsobit problémy s aktivními požadavky v následujících situacích:

    • Pokud používáte synchronní režim replikace, primární oblast nemůže dokončit operace zápisu, pokud není k dispozici žádná sekundární oblast.

    • Pokud používáte režim asynchronní replikace, váš obor názvů omezuje příjem a nepřijímá nové zprávy, jakmile prodleva replikace dosáhne vámi nakonfigurovaného maxima.

    Pokud chcete pokračovat v používání oboru názvů v primární oblasti, odeberte sekundární obor názvů z konfigurace Geo-Replication.

• Očekávaná ztráta dat: Velikost ztráty dat závisí na typu povýšení, které provádíte (plánované nebo vynucené) a režimu replikace (synchronní nebo asynchronní):

  • Plánované povýšení: Neočekává se žádná ztráta dat. Během výpadku oblasti však nemusí být plánované povýšení možné, protože vyžaduje, aby byly k dispozici všechny primární a sekundární oblasti.

  • Vynucené povýšení, synchronní replikace: Neočekává se žádná ztráta dat.

  • Vynucené povýšení, asynchronní replikace: U nedávných zpráv, které se nereplikují do sekundární oblasti, a u změn stavu, které ještě nebyly replikovány, může dojít ke ztrátě dat. Částka závisí na prodlevě replikace. Pokud chcete ověřit aktuální prodlevu replikace, použijte metriky služby Azure Monitor.

  Pokud provedete vynucené povýšení, nemůžete obnovit ztracená data ani po zpřístupnění primární oblasti.

• Očekávaný výpadek: Očekávané výpadky závisí na tom, jestli provádíte plánované nebo vynucené povýšení:

  • Plánovaná aktualizace: První krok v plánované aktualizaci replikuje data do sekundárního regionu. Tento proces se obvykle dokončí rychle, ale v některých situacích může trvat až délku prodlevy replikace. Po dokončení replikace proces povýšení obvykle trvá přibližně 5 až 10 minut. Někdy může trvat delší dobu, než servery DNS (Domain Name System) aktualizují položky a plně replikují záznamy do klientů.

    Primární region neumožňuje operace zápisu během celého procesu promoce.

    Tato možnost nemusí být během výpadku oblasti možná, protože vyžaduje, aby byly dostupné všechny primární a sekundární oblasti.

  • Vynucené povýšení: Během vynuceného povýšení service Bus nečeká na dokončení replikace dat a okamžitě zahájí povýšení. Proces povýšení obvykle trvá přibližně 5 až 10 minut. Někdy může trvat delší dobu, než se položky DNS plně replikují a aktualizují mezi klienty.

    Primární region neumožňuje operace zápisu během celého procesu promoce.

• Přesměrování provozu: Po dokončení povýšení plně kvalifikovaný název domény oboru názvů odkazuje na novou primární oblast. Toto přesměrování ale závisí na tom, jak rychle se aktualizují záznamy DNS klientů, včetně toho, aby jejich servery DNS respektovaly hodnotu TTL (Time to Live) záznamů DNS oboru názvů.

Obnovení oblasti

Po obnovení původní primární oblasti, chcete-li vrátit obor názvů zpět do původní primární oblasti, postupujte podle stejného procesu povýšení oblasti.

Pokud jste během výpadku oblasti provedli vynucené povýšení, nemůžete obnovit ztracená data ani po zpřístupnění primární oblasti.

Testování selhání regionů

Pokud chcete otestovat geografickou replikaci, dočasně upřednostněte sekundární oblast na primární a ověřte, že klientské aplikace můžou přepínat mezi oblastmi s minimálním přerušením.

Monitorujte dobu trvání povýšení a ověřte, že runbooky a automatizace fungují správně. Po otestování můžete obnovit původní konfiguraci.

Porozumíte potenciálním výpadkům a ztrátě dat, ke kterým může dojít během procesu povýšení a po jeho povýšení. Otestujte Geo-Replication v neprodukčním prostředí, které zrcadlí konfiguraci vašeho produkčního jmenného prostoru.

Obnovení Geo-Disaster metadat

Úroveň Premium podporuje metadata pro Geo-Disaster Recovery. Tato funkce zlepšuje zotavení ze scénářů havárie, včetně katastrofické ztráty oblasti. Geo-Disaster Recovery replikuje pouze konfiguraci a metadata vašeho oboru názvů. Nereplikuje ale data zpráv. Aby bylo možné podpořit obnovu po havárii, tato funkce zajišťuje, že obor názvů v jiné oblasti je předem nakonfigurován a připraven okamžitě přijímat zprávy od klientů. Geo-Disaster Recovery slouží jako jednosměrné řešení pro obnovu a nepodporuje obnovení původního stavu do předchozího primárního regionu.

Metadata Geo-Disaster Recovery fungují nejlépe pro aplikace, které nemusí striktně udržovat každou zprávu a mohou tolerovat ztrátu některých dat během scénáře havárie. Obnovení geodat po katastrofě může být také vhodné pro aplikace, které replikují samotná data nebo vůbec nepotřebují replikaci dat. Pokud například vaše zprávy představují velké obrázky, které později převedete na miniatury, můžete se rozhodnout, že si můžete dovolit ztratit některé zprávy z oblasti, která selhala, pokud můžete rychle obnovit zpracování nových zpráv v jiné oblasti a později je můžete rekonstruovat, aby se zachytily.

Důležité

Geo-Disaster Recovery umožňuje kontinuitu operací se stejnou konfigurací, ale nereplikuje data zpráv. Pokud potřebujete replikovat data zpráv, zvažte použití geografické replikace.

Když nakonfigurujete metadata Geo-Disaster Recovery, vytvoříte alias , ke kterému se klientské aplikace připojí. Alias je FQDN, který ve výchozím nastavení směruje veškerý provoz do primárního oboru názvů.

Pokud primární oblast přestane fungovat nebo nastane jiný druh havárie, můžete ručně kdykoli zahájit jednorázový, jednosměrný proces převzetí služeb při selhání z primární oblasti do sekundární oblasti. Můžete se rozhodnout provést bezpečné převzetí služeb při selhání, které čeká na úplné dokončení replikací před přepnutím na sekundární systém, i když tato možnost nemusí být během výpadku regionu dostupná. Jakmile převzetí služeb při selhání začne, téměř okamžitě se dokončí. Během procesu převzetí služeb při selhání se Geo-Disaster Recovery alias přesměruje na sekundární obor názvů a připojení se odebere.

Tato část shrnuje důležité aspekty Geo-Disaster Recovery. Projděte si úplnou dokumentaci a seznamte se s tím, jak přesně funguje. Další informace najdete v tématu Service Bus Geo-Disaster Recovery.

Požadavky

• Podpora oblastí: Můžete vybrat libovolnou oblast Azure, která podporuje Service Bus jako primární nebo sekundární obor názvů. Spárované oblasti Azure nemusíte používat, takže můžete zvolit sekundární oblasti na základě vašich požadavků na latenci, dodržování předpisů nebo rezidenci dat.

• Úroveň: Pokud chcete povolit metadata Geo-Disaster Recovery, musí obě obory názvů používat úroveň Premium.

• Dělení: Není možné spárovat dělený obor názvů s nerozděleným oborem názvů.

• Obnovení metadat pomocí Geo-Disaster Recovery: Nelze nakonfigurovat obor názvů tak, aby používal současně Geo-Replication a Geo-Disaster Recovery.

Úvahy

• Omezení funkcí: Když povolíte Geo-Disaster Recovery, existují určitá omezení. Další informace najdete v tématu Důležité body, které je potřeba vzít v úvahu a co je potřeba vzít v úvahu.

• Přiřazení rolí: Přiřazení řízení přístupu na základě rolí (RBAC) Microsoft Entra k entitám v primárním oboru názvů se nereplikují do sekundárního oboru názvů. Pokud chcete zabezpečit přístup k nim, vytvořte přiřazení rolí ručně v sekundárním oboru názvů.

• Návrh aplikace: Geo-Disaster Recovery vyžaduje při návrhu klientských aplikací specifické aspekty. Další informace najdete v tématu Důležité informace.

• Privátní koncové body: Pokud používáte privátní koncové body pro připojení k jmenným prostorům, nakonfigurujte síťové připojení v primární i sekundární oblasti. Další informace najdete v tématu Privátní koncové body.

• Obory názvů migrované ze standardu na Premium: Pokud byl váš obor názvů dříve ve vrstvě Standard a migrovali jste ho na úroveň Premium, musíte alias zpracovat jinak. Další informace najdete v tématu Service Bus Standard až Premium.

Náklady

Když povolíte metadata Geo-Disaster Recovery, platíte za primární i sekundární obory názvů.

Konfigurace podpory více oblastí

• Vytvoření párování pro obnovu po geografických katastrofách pomocí metadat Informace o konfiguraci zotavení po havárii mezi primárními a sekundárními obory názvů najdete v tématu Nastavení a převzetí služeb při selhání.

• Zakažte metadata geografické zotavení při katastrofách. Pokud chcete přerušit párování mezi obory názvů, přečtěte si téma Nastavení a tok převzetí služeb při selhání.

Plánování a řízení kapacit

Pokud plánujete nasazení ve více oblastech, ujistěte se, že obě oblasti mají dostatečnou kapacitu pro zpracování úplného zatížení, pokud jedna oblast selže. Sekundární oblast zůstává během normálního provozu pasivní, ale musí okamžitě zpracovat provoz po přepnutí po selhání. Naplánujte, jak rozšířit kapacitu sekundárního oboru názvů, aby mohla bez zpoždění přijímat produkční provoz. Pokud během procesu převzetí služeb při selhání můžete tolerovat další výpadky, můžete během převzetí služeb při selhání nebo po převzetí služeb při selhání škálovat kapacitu sekundárního oboru názvů. Pokud chcete snížit prostoje, zřiďte kapacitu v sekundárním oboru názvů předem, aby zůstala připravená na příjem produkčního zatížení.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když je obor názvů služby Service Bus nakonfigurovaný pro Geo-Disaster Recovery a primární oblast je funkční.

• Směrování provozu mezi oblastmi: Klientské aplikace se připojují prostřednictvím aliasu Geo-Disaster Recovery pro váš obor názvů a jejich přenosy jsou směrovány do primárního oboru názvů v primární oblasti.

  Během normálních operací aktivně zpracovává zprávy od klientů pouze primární obor názvů. Sekundární obor názvů zůstává v pohotovostním režimu pasivní a všechny požadavky na přístup k datům selžou.

• Replikace dat mezi oblastmi: Mezi obory názvů se replikují pouze metadata konfigurace. Replikace konfigurace probíhá nepřetržitě a asynchronně.

  Všechna data zpráv zůstávají pouze v primárním oboru názvů a nereplikují se do sekundárního oboru názvů.

Chování při výpadku oblasti

Tato část popisuje, co očekávat, když je obor názvů služby Service Bus nakonfigurován pro geografické zotavení po havárii a dojde k výpadku v primární oblasti.

• Detekce a odpověď: Zodpovídáte za monitorování zdraví regionu a manuální spuštění převzetí při selhání. Microsoft neprovádí přepnutí při selhání ani automaticky neupřednostní sekundární oblast, i když není vaše primární oblast dostupná.

  Další informace o tom, jak spustit převzetí služeb při selhání, najdete v tématu Proces převzetí služeb při selhání.

  Když zahájíte převzetí, zvolte, jestli chcete provést bezpečné převzetí nebo standardní (vynucené nebo ruční převzetí). Bezpečné převzetí služeb při selhání čeká na dokončení replikace do sekundární oblasti, než začne samotné převzetí. Tento přístup snižuje ztrátu metadat, ale přináší výpadky. Bezpečné převzetí služeb při výpadku vyžaduje, aby obory názvů byly ve stejném předplatném Azure.

  Během výpadku v primární oblasti obvykle potřebujete provést vynucený převod. Pokud je primární oblast dostupná a aktivujete převzetí služeb při selhání z jiného důvodu, můžete zvolit plánované převzetí služeb při selhání.

  Převzetí služeb při selhání je jednosměrná operace, takže budete muset později znovu vytvořit párování pro geografické obnovování po havárii. Další informace najdete v tématu Obnovení oblasti.

• Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Můžete ale použít Azure Service Health k pochopení celkového stavu služby, včetně všech selhání oblastí, a můžete nastavit upozornění služby Health, která vás upozorní na problémy.

• Aktivní požadavky: Aktivní požadavky, které probíhají při spuštění převzetí služeb při selhání, se ukončí. Klientské aplikace by měly po dokončení převzetí služeb při selhání opakovat operace.

• Očekávaná ztráta dat:

  • Metadata: Konfigurace a metadata se obvykle replikují do sekundárního oboru názvů. Replikace metadat se ale provádí asynchronně, takže nedávné změny se nemusí replikovat, zejména složité změny. Před přístupem klientů ověřte konfiguraci sekundárního prostoru názvů.

  • Data zpráv: Data zpráv se mezi oblastmi nereplikují. Pokud primární region přestane fungovat, zprávy v primárním oboru názvů se stanou nedostupnými.

    Zprávy se trvale neztratí, pokud katastrofální katastrofa nezpůsobí celkovou ztrátu primární oblasti. Pokud se oblast obnoví, můžete později načíst zprávy z primárního jmenného prostoru.

• Očekávaný výpadek: Převzetí služeb při selhání obvykle probíhá během 5 až 10 minut. Úplné replikace a aktualizace záznamů DNS může klientům trvat déle.

• Přesměrování provozu: Klienti, kteří používají alias Geo-Disaster Recovery pro připojení k namespacem, se po převzetí služeb při selhání automaticky přesměrují do sekundárního namespacu. Toto přesměrování však závisí na tom, že DNS servery respektují hodnotu TTL záznamů DNS oboru názvů a že klienti obdrží tyto aktualizované záznamy DNS.

Obnovení oblasti

Po obnovení původní primární oblasti je nutné ručně znovu vytvořit párování a volitelně navrátit služby po obnovení. Vytvořte novou dvojici Geo-Disaster Recovery s obnovenou oblastí jako sekundární, pak proveďte další převzetí služeb při selhání, pokud se chcete vrátit do původní oblasti. Tento proces zahrnuje potenciální ztrátu dat zpráv odesílaných do dočasného primárního uzlu.

Pokud havárie způsobí ztrátu všech zón v primární oblasti, můžou být vaše data nedostupná. V jiných scénářích zůstanou data zpráv v primárním oboru názvů obnovitelné po obnovení po převzetí služeb při selhání. Po obnovení přístupu můžete získat historické zprávy z původního primárního oboru názvů. Zodpovídáte za konfiguraci aplikací pro příjem a zpracování těchto zpráv. Společnost Microsoft neobnoví automaticky data do vaší sekundární oblasti.

Testování selhání regionů

Chcete-li otestovat procesy reakce a zotavení po havárii, proveďte plánovaný failover během okna údržby. Zahajte přepnutí z primárního oboru názvů do sekundárního oboru názvů. Ověřte, že se vaše aplikace můžou připojovat a zpracovávat zprávy z nového primárního oboru názvů.

Monitorujte dobu trvání převzetí služeb při selhání a ověřte, že vaše provozní knihy a automatizace fungují správně. Po otestování můžete obnovit původní konfiguraci.

Seznamte se s potenciálními výpadky a ztrátou dat, ke kterým může dojít během a po procesu převzetí služeb při selhání. Otestujte metadata Geo-Disaster Recovery v neprodukčním prostředí, které zrcadlí konfiguraci vašeho produkčního oboru názvů.

Vlastní řešení pro více regionů pro odolnost systémů

Geo-Replication a metadata Geo-Disaster Recovery zajišťují odolnost vůči výpadkům v regionu a dalším problémům a jsou vhodné pro většinu úloh. V následujících situacích ale nemusí vyhovovat vašim potřebám:

• Máte požadavky na vlastní replikaci nebo pro zachování více aktivních oblastí současně.
• Používáte úroveň služby Service Bus, která tyto funkce nepodporuje.

Existuje řada vzorů návrhu pro dosažení různých typů podpory více oblastí ve službě Service Bus. Mnoho vzorů vyžaduje nasazení více oborů názvů a konfiguraci aplikace tak, aby používala obory názvů odpovídajícím způsobem. Další informace najdete v těchto článcích:

• Použijte více oborů názvů k izolaci aplikací proti výpadkům a haváriím služby Service Bus
• Replikace zpráv a federace mezi oblastmi

Odolnost vůči údržbě služeb

Service Bus provádí pravidelnou údržbu. Během plánované údržby se obory názvů přesunou do redundantního uzlu, který obsahuje nejnovější aktualizace. V tomto přesunu se klientská SDK automaticky odpojí a znovu připojí v namespace. K upgradům obvykle dochází během 30 sekund. Je důležité, aby vaše aplikace byly připravené na přechodné odpojení sítě , ke kterým dochází během období údržby.

Další informace najdete v tématu Pokyny k událostem údržby Azure pro Azure Service Bus.

Zálohování a obnovení

Service Bus není navržen jako dlouhodobé umístění úložiště pro vaše data. Obvykle jsou data uložená v tématu nebo frontě po krátkou dobu a pak se zpracovávají nebo uchovávají v jiném systému úložiště dat, ve kterém okamžiku se odstraní. Kvůli tomuto návrhu service Bus automaticky udržuje repliky dat zpráv, ale neposkytuje možnosti zálohování a obnovení dat zpráv.

V případě scénářů vyžadujících dlouhodobé uchovávání zpráv zvažte implementaci archivace na úrovni aplikace do Azure Storage nebo jiných trvalých služeb úložiště.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Service Bus poskytuje smlouvu SLA pro všechny obory názvů. Smlouva SLA o dostupnosti je vyšší, když váš obor názvů splňuje všechna následující kritéria:

• Používá úroveň Premium.
• Nachází se v oblasti se zónami dostupnosti.
• Používá particionování.

Související obsah

• Dokumentace ke službě Service Bus
• Geografické zotavení po havárii služby Azure Service Bus
• Geografická replikace služby Azure Service Bus