Geografické zotavení po havárii služby Azure Service Bus

Pomocí funkce Obnovení služby Service Bus Geo-Disaster můžete izolovat aplikace Azure Service Bus před výpadky a haváriemi. Pomáhá zachovat integritu konfigurace složené aplikace.

Poznámka:

Tato funkce je dostupná pro úroveň Premium služby Azure Service Bus.

Funkce Geo-Disaster Recovery nepřetržitě replikuje celou konfiguraci oboru názvů (entity, konfigurace, vlastnosti) z primárního oboru názvů do sekundárního spárovaného oboru názvů. Jednorázové přesunutí při selhání můžete kdykoli zahájit z primárního systému do sekundárního. Převzetí služeb při selhání přejmenuje zvolený název aliasu oboru názvů na sekundární obor názvů a poté přeruší párování. Převzetí služeb při selhání je téměř okamžité, jakmile je aktivováno.

Porovnání s Geo-Replication

Azure Service Bus nabízí dvě funkce pro geografickou odolnost: Geo-Replication a Geo-Disaster Recovery. Klíčovým rozdílem je, že Geo-Replication replikuje metadata i data (zprávy, stavy zpráv, změny vlastností), zatímco Geo-Disaster Recovery replikuje pouze metadata. Pro většinu scénářů zotavení po havárii se doporučuje Geo-Replication. Podrobné porovnání najdete v tématu Spolehlivost ve službě Azure Service Bus – Odolnost vůči selháním v celé oblasti.

Důležité body ke zvážení

• Tato funkce umožňuje okamžitou kontinuitu operací se stejnou konfigurací, ale nereplikuje zprávy uchovávané ve frontách nebo odběrech témat ani ve frontách nedoručených zpráv. K zachování sémantiky fronty taková replikace vyžaduje nejen replikaci dat zpráv, ale také všechny změny stavu u zprostředkovatele. Tato replikace se nabízí ve funkciGeo-Replication.
• Přiřazení řízení přístupu na základě role (RBAC) služby Microsoft Entra k entitám Service Bus 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ásledující konfigurace se nereplikují:
  • Konfigurace virtuální sítě
  • Připojení k privátním koncovým bodům
  • Povolen přístup ke všem sítím
  • Povolený přístup k důvěryhodné službě
  • Přístup k veřejné síti
  • Výchozí síťová akce
  • Identity a nastavení šifrování (šifrování pomocí klíče spravovaného zákazníkem nebo šifrování s použitím vlastního klíče (BYOK))
  • Povolení automatického škálování
  • Zakázání místního ověřování
  • Předplatná služby Azure Event Grid
• Spárování děleného oboru názvů s neděleným oborem názvů není podporováno.
• Pokud povolíte AutoDeleteOnIdle entitu, nemusí být entita v sekundárním oboru názvů, když dojde k převzetí služeb při selhání. Když se sekundární stane primární, poslední stav přístupu, který není součástí metadat, není k dispozici pro nový primární server a entita může být odstraněna v rámci AutoDeleteOnIdle vyčištění.

Tip

Pokud chcete replikovat obsah front a odběrů témat a provozovat odpovídající obory názvů v konfiguracích aktivní/aktivní, abyste se mohli vypořádat s výpadky a haváriemi, nespoléhejte se na sadu funkcí Geo-Disaster Recovery. Místo toho použijte funkciGeo-Replication nebo postupujte podle pokynů k replikaci.

Základní koncepce a pojmy

Funkce Geo-Disaster Recovery implementuje zotavení metadat po havárii a spoléhá na primární a sekundární obory názvů pro zotavení po havárii. Funkce Geografické zotavení po havárii je dostupná jenom pro úroveň Premium. Nemusíte provádět žádné změny připojovacího řetězce, protože se připojení provádí prostřednictvím aliasu.

V tomto článku se používají následující termíny:

• Alias: Název konfigurace zotavení po havárii, kterou jste nastavili. Alias poskytuje stabilní připojovací řetězec s jediným plně kvalifikovaným názvem domény (FQDN). Aplikace používají tento aliasový řetězec připojení pro připojení k oboru názvů. Když použijete alias, připojovací řetězec zůstane stejný, když začne přepnutí po selhání.

• Primární/sekundární obory názvů: Obory názvů, které odpovídají aliasu. Primární obor názvů je aktivní a přijímá zprávy (může to být existující nebo nový obor názvů). Sekundární obor názvů je pasivní a nepřijímá zprávy. Metadata mezi oběma je synchronizované, takže oba můžou bezproblémově přijímat zprávy bez jakéhokoli změny kódu aplikace nebo připojovacího řetězce. Pokud chcete zajistit, aby zprávy přijímal pouze aktivní obor názvů, musíte použít alias.

• Metadata: Entity, jako jsou fronty, témata a odběry, a jejich vlastnosti služby, které jsou přidružené k oboru názvů. Automaticky se replikují jenom entity a jejich nastavení. Zprávy se nereplikují.

• Převzetí služeb při selhání: Proces aktivace sekundárního jmenného prostoru.

Nastavení

Následující část obsahuje přehled nastavení párování mezi obory názvů.

Nejprve vytvořte nebo použijte existující primární obor názvů a vytvořte nový sekundární obor názvů. Potom dva obory názvů spárujte. Toto párování vám poskytne alias, který můžete použít k připojení. Protože používáte alias, nemusíte měnit připojovací řetězec. Do párování failoveru lze přidat pouze nové jmenové prostory.

1. Vytvořte primární obor názvů úrovně Premium.

2. Vytvořte sekundární obor názvů úrovně Premium v jiné oblasti. Tento krok je nepovinný. Sekundární obor názvů můžete vytvořit během vytváření párování v dalším kroku.

3. V Azure Portal přejděte do svého primárního oboru názvů.

4. V nabídce vlevo vyberte Geografické obnovení a na panelu nástrojů vyberte Zahájit párování .

   

5. Při inicializaci párování postupujte takto:

   1. Vyberte existující sekundární obor názvů nebo ho vytvořte v jiné oblasti. V tomto příkladu se jako sekundární obor názvů používá existující obor názvů.

   2. Zadejte alias pro párování Geo-Disaster Recovery jako Alias.

   3. Vyberte Vytvořit.

      

6. Měli byste vidět stránku aliasu Geo-DR služby Service Bus, jak je znázorněno na následujícím obrázku. Na stránku aliasu Geo-DR také můžete přejít ze stránky primárního oboru názvů výběrem Geo-Recovery v levé nabídce.

   

7. Na stránce Geo-DR Alias vyberte v levé nabídce zásady sdíleného přístupu a získejte přístup k primárnímu připojovacímu řetězci aliasu. Tento řetězec připojení použijte namísto připojovacího řetězce přímo k primárnímu nebo sekundárnímu jmennému prostoru. Alias zpočátku odkazuje na primární obor názvů.

8. Přepněte na stránku Přehled . Můžete provést následující akce:

   1. Rozdělte párování mezi primárními a sekundárními obory názvů. Na panelu nástrojů vyberte Zrušit párování.
   2. Ručně přepněte na sekundární obor názvů.

      1. Na panelu nástrojů vyberte Failover.

      2. Potvrďte, že chcete přepnout na sekundární obor názvů zadáním svého aliasu.

      3. Zapněte možnost Bezpečné převzetí služeb při selhání, aby došlo k bezpečnému přepnutí na sekundární obor názvů.

         Poznámka:

         • Bezpečné převzetí služeb při selhání zajišťuje dokončení čekajících replikací geografického zotavení po havárii před přepnutím na sekundární instanci. Případně vynucená nebo ruční přepnutí nečekají na dokončení nedokončených replikací před přepnutím na sekundární server.
         • V současné době bezpečné převzetí služeb selže, pokud primární a sekundární jmenné prostory nejsou ve stejném Azure předplatném.

      4. Vyberte záložní režim.

         

         Důležité

         Přepnutí při selhání aktivuje sekundární obor názvů a primární obor názvů je odstraněn z párování Disaster Recovery. Vytvořte další obor názvů, který bude mít nový pár geografického zotavení po havárii.

9. Nakonec přidejte monitorování, abyste zjistili, zda je nutné přepnout na jiné služby při selhání. Ve většině případů je služba jednou z částí velkého ekosystému, takže automatické převzetí služeb při selhání je zřídka možné, protože často je potřeba provést převzetí služeb při selhání synchronizované se zbývajícím subsystémem nebo infrastrukturou.

Service Bus Standard až Premium

Pokud jste migrovali obor názvů Azure Service Bus Standard do služby Azure Service Bus Premium, musíte použít existující alias (připojovací řetězec oboru názvů Service Bus Standard) a vytvořit konfiguraci zotavení po havárii prostřednictvím rozhraní příkazového řádku nebo rozhraní REST API.

Během migrace se připojovací řetězec standardního oboru názvů Azure Service Bus a název DNS stanou aliasem vašeho oboru názvů Azure Service Bus Premium.

Klientské aplikace musí použít tento alias (připojovací řetězec standardního oboru názvů služby Azure Service Bus) pro připojení k oboru názvů Premium, ve kterém nastavíte párování zotavení po havárii.

Pokud k nastavení konfigurace zotavení po havárii použijete Azure Portal, portál za vás zpracuje tyto podrobnosti.

Proces převzetí služeb při selhání

Zákazník ručně aktivuje převzetí služeb při selhání, a to buď explicitně pomocí příkazu, nebo prostřednictvím klientem vlastněné obchodní logiky, která příkaz aktivuje. Azure nikdy nespouští automatické převzetí při selhání. Tento přístup poskytuje zákazníkovi úplné vlastnictví a přehled o řešení výpadků v páteřní síti Azure.

Po spuštění mechanismu převzetí služeb při selhání –

1. Alias alias připojovací řetězec se aktualizuje tak, aby odkázal na sekundární obor názvů Premium.

2. Klienti (odesílatelé a příjemci) se automaticky připojují k sekundárnímu oboru názvů.

3. Existující párování mezi primárním a sekundárním prémiovým oborem názvů je přerušené.

Po zahájení převzetí služeb při selhání –

1. Pokud dojde k jinému výpadku, budete chtít být schopni přepnout znovu. Nastavte tedy další sekundární obor názvů a aktualizujte párování.

2. Jakmile bude znovu k dispozici, přetáhněte zprávy z bývalého primárního oboru názvů. Potom použijte tento obor názvů pro pravidelné zasílání zpráv mimo nastavení geografického zotavení po havárii nebo odstraňte starý primární obor názvů.

Poznámka:

Podporuje se pouze sémantika pokračovat při selhání. Když zahájíte převzetí služeb při selhání pomocí geografického zotavení po havárii, můžete po dokončení převzetí služeb při selhání znovu spárovat nový obor názvů. Nelze vrátit zpět na předchozí primární repliku. Tato sémantika se může lišit od jiných úložišť dat, na která jste zvyklí, jako jsou clustery Microsoft SQL Serveru.

Převzetí služeb při selhání můžete automatizovat buď pomocí monitorovacích systémů, nebo pomocí vlastních monitorovacích řešení. Taková automatizace ale vyžaduje dodatečné plánování a práci, která je mimo rozsah tohoto článku.

Správa

Pokud uděláte chybu, například spárování nesprávných oblastí během počátečního nastavení, můžete kdykoli přerušit párování těchto dvou oborů názvů. Pokud chcete spárované obory názvů použít jako běžné obory názvů, odstraňte alias.

Použijte existující obor názvů jako alias

Pokud máte scénář, ve kterém nemůžete změnit připojení producentů a konzumentů, můžete název prostoru názvů použít znovu jako alias. Tady najdete ukázkový kód na GitHubu.

Ukázky

Ukázky na GitHubu ukazují, jak nastavit a zahájit převzetí služeb při selhání. Tyto ukázky ukazují následující koncepty:

• Ukázka a nastavení .NET, která jsou vyžadována v Microsoft Entra ID pro použití Azure Resource Manageru se službou Service Bus, nastavení a povolení geografického zotavení po havárii.
• Kroky potřebné ke spuštění ukázkového kódu
• Jak použít existující obor názvů jako alias.
• Postup alternativního povolení geografického zotavení po havárii prostřednictvím PowerShellu nebo rozhraní příkazového řádku
• Odesílejte a přijímejte z aktuálního primárního nebo sekundárního prostoru názvů pomocí aliasu

Úvahy

Mějte na paměti následující aspekty v této verzi:

• Při plánování převzetí služeb při selhání zvažte časový faktor. Pokud například ztratíte připojení na dobu delší než 15 až 20 minut, můžete se rozhodnout zahájit převzetí služeb při selhání.
• Protože se nereplikují žádná data, aktuálně aktivní relace nejsou replikovány. Kromě toho nemusí fungovat detekce duplicit a zprávy plánované na určitý čas. Nové relace, nové naplánované zprávy a nové duplicáty fungují.
• Aspoň jednou byste měli zkoušet převzetí služeb při selhání komplexní distribuované infrastruktury.
• Synchronizace entit může nějakou dobu trvat, přibližně 50 až 100 entit za minutu. Předplatná a pravidla se také počítají jako entity.

Privátní koncové body

Tato část poskytuje další úvahy při použití Geo-Disaster Recovery s jmennými prostory, které využívají privátní koncové body. Obecné informace o používání privátních koncových bodů se službou Service Bus najdete v tématu Integrace služby Azure Service Bus se službou Azure Private Link.

Nové párování

Pokud se pokusíte vytvořit párování mezi primárním oborem názvů s privátním koncovým bodem a sekundárním oborem názvů bez privátního koncového bodu, párování selže. Párování proběhne úspěšně pouze v případě, že primární i sekundární obory názvů mají privátní koncové body. Použijte stejné konfigurace v primárních a sekundárních oborech názvů a ve virtuálních sítích, ve kterých vytváříte privátní koncové body.

Poznámka:

Když se pokusíte spárovat primární obor názvů s privátním koncovým bodem a sekundárním oborem názvů, proces ověření pouze zkontroluje, jestli v sekundárním oboru názvů existuje privátní koncový bod. Nekontroluje, jestli koncový bod funguje nebo funguje po převzetí služeb při selhání. Je vaší odpovědností zajistit, aby sekundární obor názvů s privátním koncovým bodem fungoval podle očekávání po přepnutí při selhání.

Pokud chcete otestovat, že konfigurace privátních koncových bodů jsou stejné, odešlete požadavek Get queues do sekundárního oboru názvů mimo virtuální síť a ověřte, že se ve službě zobrazí chybová zpráva.

Existující párování

Pokud už párování mezi primárním a sekundárním oborem názvů existuje, vytvoření privátního koncového bodu v primárním oboru názvů selže. Pokud chcete tuto chybu vyřešit, nejprve v sekundárním oboru názvů vytvořte privátní koncový bod a pak vytvořte privátní koncový bod pro primární obor názvů.

Poznámka:

Sekundární obor názvů lze sice přistupovat pouze pro čtení, ale nastavení soukromých koncových bodů můžete aktualizovat.

Doporučená konfigurace

Při vytváření konfigurace zotavení po havárii pro vaši aplikaci a Service Bus musíte vytvořit privátní koncové body pro primární i sekundární obory názvů služby Service Bus pro virtuální sítě hostující primární i sekundární instance vaší aplikace.

Předpokládejme, že máte dvě virtuální sítě, VNET-1 a VNET-2 a tyto primární a sekundární obory názvů: ServiceBus-Namespace1-Primary a ServiceBus-Namespace2-Secondary. Proveďte následující kroky:

• Na ServiceBus-Namespace1-Primary vytvořte dva privátní koncové body, které používají podsítě z virtuální sítě VNET-1 a VNET-2.
• Vytvořte na ServiceBus-Namespace2-Secondary dva privátní koncové body, které používají stejné podsítě ve VNET-1 a VNET-2.

Výhodou tohoto přístupu je, že převzetí služeb při selhání může probíhat v aplikační vrstvě nezávisle na oboru názvů služby Service Bus. Zvažte následující scénáře:

Převzetí služeb při selhání pouze pro aplikace: Aplikace není přítomna v síti VNET-1, ale přesouvá se do virtuální sítě VNET-2. Vzhledem k tomu, že oba privátní koncové body jsou nakonfigurované pro primární i sekundární obory názvů jak na VNET-1, tak na VNET-2, aplikace funguje bez problémů.

Převzetí služeb při selhání pouze s oborem názvů služby Service Bus: Zde opět, jelikož oba privátní koncové body jsou nakonfigurované v obou virtuálních sítích pro primární i sekundární obory názvů, aplikace funguje bez problémů.

Poznámka:

Pokyny k geografickému zotavení po havárii virtuální sítě najdete v tématu Virtuální síť – Provozní kontinuita.

Řízení přístupu na základě role

Přiřazení řízení přístupu na základě role (RBAC) služby Microsoft Entra k entitám Service Bus 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ů.

Další kroky

• Informace o rozhraní REST API geografického zotavení po havárii najdete tady.
• Spusťte ukázku geografického zotavení po havárii na GitHubu.
• Podívejte se na ukázku geografického zotavení po havárii , která odesílá zprávy do aliasu.

Další informace o zasílání zpráv služby Service Bus najdete v následujících článcích:

• Fronty, témata a odběry služby Service Bus
• Začínáme se službou Service Bus a jejími frontami
• Jak používat témata a odběry Service Bus
• REST API