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ě trvanlivosti zpráv, záruky doručení alespoň jednou a fronty nedoručených zpráv, pro zpracování neúspěšných 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 různý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í. Upozorňuje také na 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 Azure Service Bus, najdete v tématu Osvědčené postupy architektury pro Service Bus.

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 oboru názvů nasadíte fronty a témata, což jsou prvky pro zasílání zpráv, které mají různé sémantika. 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 využívat více oddílů pro paralelní zpracování a horizontální š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 povolte rozdělení v oboru názvů. Pro obory názvů úrovně Basic a Standard nakonfigurujte 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. Každé úložiště zpráv má tři kopie: jednu primární a dvě sekundární kopie. Service Bus uchovává všechny tři kopie synchronizované pro operace správy a dat. Pokud primární kopie selže, Service Bus povýší sekundární kopii na primární bez výpadků pro klienty.

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( MU), které mají 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 najdete v tématu Automatická aktualizace jednotek MU v oboru názvů služby 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 transparentní mechanismy detekce selhání a převzetí služeb při selhání, aby fungovala v rámci zaručených úrovní služeb a obvykle bez znatelných přerušení, když k těmto 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 Service Bus SDK obsahuje logiku automatického opakování s exponenciálním ústupem pro operace, které selžou kvůli přechodným podmínkám, jako jsou síťové vypršení časového limitu 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 naleznete v tématu Klientská knihovna služby 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í služeb při selhání bez 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. Nadále funguje bez ztráty nebo přerušení přenosu dat do aplikací pro zasílání zpráv, i když je celá zóna dostupnosti nedostupná.

Diagram znázorňující zónově redundantní obor názvů služby Service Bus

Požadavky

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

  • Úrovně: 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 tento požadavek se změnil a zoneRedundant vlastnost je zastaralá. Tato vlastnost se může zobrazit jako false, i když je povolená zonová redundance. Všechny obory názvů v oblastech, ve kterých jsou zóny 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, když je nasadíte 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í, ve kterém se zprávy distribuují napříč několika zónami 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ž je služba považuje za dokončenou, což zajišťuje 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 přepne služby na zdravé zóny. 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 při výpadku zóny automaticky neoznámí. 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í požadavky: 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 zjistí 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 pak přijímá nová připojení a zpracovává zprávy společně s ostatními zónami. Data replikovaná 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í nebo 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é musí 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 nepotřebují replikaci dat.

Následující tabulka shrnuje klíčové rozdíly mezi těmito dvěma funkcemi:

Schopnost Geografická replikace Obnova IT po geografické katastrofě
Co se replikuje Metadata a data (zprávy, stavy zpráv, změny vlastností) Pouze metadata (entity, konfigurace, vlastnosti)
Ztráta dat při převzetí služeb Žádná ztráta dat s plánovaným povýšením; možná ztráta dat s vynuceným povýšením. Zprávy se nereplikují; musí být ručně obnoveny ze starého primárního oboru názvů.
Chování při selhání Proměňuje sekundární na primární; původní primární se stane sekundární Jednorázové převzetí služeb při selhání; párování se po převzetí služeb při selhání přeruší
Schopnost obnovit původní konfiguraci Ano, může být povýšen zpět na původní primární úroveň. Ne, je třeba nastavit nové párování.
Režimy replikace Synchronní nebo asynchronní Nevztahuje se (pouze metadata)

U většiny scénářů zotavení po havárii Geo-Replication je doporučená volba, protože poskytuje úplnou ochranu dat. Zvažte Geo-Disaster Recovery pouze v případě, že konkrétně potřebujete replikaci pouze metadat.

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í nebo povýšení, i když vaše primární oblast nefunguje.

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

Geografická replikace

Úroveň Premium podporuje geografickou replikaci. Tato funkce replikuje metadata, jako jsou entity, konfigurace a vlastnosti, pro obor názvů. Replikuje také data, například zprávy ve vašich frontách a tématech, spolu s jejich vlastnostmi a stavem. 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ů.

Diagram znázorňující obor názvů služby Service Bus nakonfigurovaný pro geografickou replikaci

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 se má 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). Termín failover se také používá k popisu tohoto obecného procesu.

Tato část shrnuje důležité aspekty geografické replikace. Projděte si úplnou dokumentaci a zjistěte, jak 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, proto vyberte 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í některá omezení. Další informace najdete v tématu Geografické replikace služby Service Bus.

  • Privátní koncové body: Pokud pro připojení k jmennému prostoru používáte privátní koncové body, musíte také nakonfigurovat síťové nastavení v primárních a sekundárních oblastech. Další informace najdete v tématu Privátní koncové body.

Náklady

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

Konfigurace podpory více oblastí

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-Replication 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á 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 párování replikace používá 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í i sekundární oblasti. Synchronní replikace ale výrazně 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í: Služba zapisuje zprávy do primární oblasti a pak dokončí operaci zápisu. Krátce později replikuje zprávy do sekundární oblasti.

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

      Při konfiguraci asynchronní replikace nastavíte 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á. Pokud se chcete této situaci vyhnout, vyberte sekundární oblasti, které nejsou příliš geograficky vzdálené, a ujistěte se, že vaše kapacita stačí pro 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. Kritéria, která je potřeba vzít v úvahu při rozhodování o přepnutí při selhání, najdete v Doporučené scénáře pro spuštění povýšení.

    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 mezi plánovaným povýšením nebo vynuceným povýšením. Plánované nasazení čeká, až se sekundární oblast synchronizuje, než přijme nový provoz. Tento přístup brání ztrátě dat, ale vede k výpadkům.

    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 místo toho zvolit plánované povýšení.

  • Oznámení: Microsoft vás při výpadku oblasti automaticky neoznámí. 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 tom, jestli provádíte plánované nebo vynucené povýšení a jestli je režim replikace synchronní nebo asynchronní:

    • Plánované povýšení: Neočekává se žádná ztráta dat. Během výpadku oblasti ale nemusí být možné plánované povýšení, protože vyžaduje, aby byly dostupné 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 pro změny stavu, které se nereplikují, 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 provedete 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, jestli jejich servery DNS dodržují hodnotu TTL (Time to Live) záznamů DNS oboru názvů.

Obnovení oblasti

Po zotavení původního primárního regionu, pokud chcete vrátit obor názvů do tohoto regionu, postupujte podle stejného procesu povýšení regionu.

Pokud jste během výpadku regionu 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 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ů a nereplikuje data o zprávách. 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 zprávy obsahují velké obrázky, které později převedete na miniatury, může být ztráta některých zpráv z oblasti, která selhala, přijatelná, pokud můžete rychle pokračovat ve zpracování nových zpráv v jiné oblasti a později ztracené zprávy rekonstruovat.

Důležité

Geo-Disaster Recovery umožňuje kontinuitu operací se stejnou konfigurací, ale nereplikuje data zpráv. Pokud je nutné 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ů.

Diagram znázorňující dva obory názvů služby Service Bus nakonfigurované pro metadata Geo-Disaster Recovery

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 provést bezpečné převzetí služeb při selhání, které čeká na dokončení replikace, než se přepne na sekundární systém. Tato možnost nemusí být během výpadku oblasti dostupná. Po spuštění převzetí služeb při selhání se dokončí téměř okamžitě. 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 zjistěte, jak funguje. Další informace najdete v tématu Service Bus Geo-Disaster Recovery.

Požadavky

  • Podpora oblastí: Můžete zvolit libovolnou oblast Azure, která podporuje Service Bus jako primární nebo sekundární obor názvů. Spárované oblasti Azure nemusíte používat, proto vyberte 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.

  • Parcování: Není možné spárovat parcovaný obor názvů s neparcovaný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, platí některá 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 těmto entitám, 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 je váš obor názvů na úrovni Standard a migrujete 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í

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 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 neinicializuje převzetí při selhání, ani neprovede automatickou podporu sekundární oblasti, i když je vaše primární oblast nedostupná.

    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í služeb při selhání, zvolte, jestli chcete provést bezpečné převzetí služeb při selhání , nebo standardní převzetí služeb při selhání, jako je vynucené nebo ruční převzetí služeb při selhání. 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ím regionu obvykle musíte provést vynucené převzetí služeb při selhání. 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 je nutné později znovu vytvořit párování obnovy geografické obnovy po katastrofě. Další informace najdete v tématu Obnovení oblasti.

  • Oznámení: Microsoft vás při výpadku oblasti automaticky neoznámí. 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 probíhá 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é znovu ručně nastavit párování a volitelně provést navrácení. Vytvořte novou dvojici Geo-Disaster Recovery s obnovenou oblastí jako sekundární a poté proveďte opětovné 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, které byly odeslány do dočasného primárního jmenného prostoru.

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 jsou data zpráv, která zůstávají v primárním oboru názvů před převzetím služeb při selhání, obnovitelná. 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ů

Pokud chcete otestovat procesy reakce a zotavení po havárii, proveďte řízené přepnutí během okna údržby. Zahajte failover z primárního oboru názvů do sekundárního oboru názvů a ověřte, že vaše aplikace se mohou připojit 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. Tyto funkce nemusí vyhovovat vašim potřebám v následujících situacích:

  • 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 několik vzorů návrhu, které poskytují různé typy podpory více oblastí ve službě Service Bus. Mnoho z těchto vzorů vyžaduje, abyste nasadili více oborů názvů a nakonfigurovali aplikaci tak, aby je používala odpovídajícím způsobem. Další informace najdete v následujících zdrojích informací:

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

Service Bus provede pravidelnou údržbu. Během plánované údržby se obory názvů přesunou do redundantního uzlu, který obsahuje nejnovější aktualizace. Během přesunu se klientská sada SDK odpojí a pak se automaticky připojí k jmennému prostoru. Upgrady se obvykle dokončí do 30 sekund. Je důležité, aby vaše aplikace byly připravené na přechodné odpojení sítě , ke kterým může dojít během období údržby.

Další informace najdete v tématu Události údržby Azure pro Service Bus.

Zálohování a obnovení

Service Bus není určený pro dlouhodobé ukládání dat. Data jsou obvykle uložená v tématu nebo frontě pouze po krátkou dobu. Pak se zpracuje nebo uloží do jiného systému úložiště dat a pak se odstraní. Kvůli tomuto návrhu service Bus automaticky udržuje repliky dat zpráv, ale neposkytuje žádné možnosti zálohování a obnovení pro tato data.

V případě scénářů, které vyžadují dlouhodobé uchovávání zpráv, zvažte implementaci archivace na úrovni aplikace do Služby 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ů. Dostupnost SLA je vyšší, když váš obor názvů splňuje následující kritéria:

  • Používá úroveň Premium.
  • Nachází se v oblasti, ve které jsou zóny dostupnosti.
  • Používá particionování.

Související obsah

  • Last updated on