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

Odolnost proti katastrofálním výpadkům prostředků zpracování dat je požadavkem pro mnoho podniků a v některých případech dokonce vyžaduje oborová nařízení.

Azure Service Bus už rozšiřuje riziko katastrofických selhání jednotlivých počítačů nebo dokonce dokončuje racky napříč clustery, které zahrnují více domén selhání v rámci datacentra, a implementuje mechanismy transparentní detekce selhání a převzetí služeb při selhání tak, aby služba dál 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. Obor názvů Premium může mít dvě nebo více jednotek zasílání zpráv a tyto jednotky zasílání zpráv jsou rozložené do několika domén selhání v rámci datacentra, které podporují model clusteru Service Bus, který je aktivní.

V případě oboru názvů úrovně Premium se riziko výpadku dále rozprostírá mezi tři fyzicky oddělená zařízení (zóny dostupnosti) a služba má dostatek rezerv kapacity, aby se okamžitě dokázala vypořádat s kompletní, katastrofickou ztrátou datacentra. Plně aktivní model clusteru Azure Service Bus v rámci domény selhání spolu s podporou zóny dostupnosti je nadřazený všem místním produktům zprostředkovatele zpráv z hlediska odolnosti proti vážným selháním hardwaru a dokonce i katastrofické ztrátě celých zařízení datacentra. Přesto může dojít k vážným situacím s rozsáhlou fyzickou zničením, proti kterým ani tato opatření nemohou dostatečně bránit.

Funkce geografického zotavení po havárii služby Service Bus je navržená tak, aby usnadnila zotavení po havárii této velikosti a opustila neúspěšnou oblast Azure pro dobré a bez nutnosti měnit konfigurace aplikací. Opuštění oblasti Azure obvykle zahrnuje několik služeb a tato funkce primárně pomáhá zachovat integritu konfigurace složené aplikace. Tato funkce je globálně dostupná pro skladovou položku Service Bus Premium.

Funkce geografického zotavení po havárii zajišťuje, že se při párování nepřetržitě replikuje celá konfigurace oboru názvů (fronty, témata, odběry, filtry) z primárního oboru názvů do sekundárního oboru názvů a umožňuje kdykoli zahájit přechod z primárního na sekundární převzetí služeb při selhání pouze jednou. Přesun převzetí služeb při selhání znovu odkazuje na zvolený název aliasu pro obor názvů do sekundárního oboru názvů a potom přeruší párování. Převzetí služeb při selhání je téměř okamžité po zahájení.

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 nebo ve frontách nedoručených zpráv. Aby se zachovala sémantika fronty, vyžaduje taková replikace nejen replikaci dat zpráv, ale i všech změn stavu v zprostředkovatele. U většiny oborů názvů služby Service Bus by požadovaný provoz replikace daleko překročil provoz aplikace a s frontami s vysokou propustností by se většina zpráv stále replikovala do sekundární, zatímco se už odstraňují z primárního serveru, což způsobuje nadměrně plýtvání provozem. U tras replikace s vysokou latencí, které platí pro mnoho párů, které byste zvolili pro geografické zotavení po havárii, může být také nemožné, aby provoz replikace trvale udržoval krok s provozem aplikace kvůli latenci vyvolanému omezováním.
• Přiřazení řízení přístupu na základě role (RBAC) společnosti Microsoft k entitám služby 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í klíče spravovaného zákazníkem nebo používání vlastního klíče (BYOK)
  • Povolení automatického škálování
  • Zakázání místního ověřování
• Spárování děleného oboru názvů s neděleným oborem názvů se nepodporuje.
• Pokud AutoDeleteOnIdle je pro entitu povolená, entita nemusí být 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ím stavem posledního přístupu, který není součástí metadat, nebude k dispozici pro novou primární entitu a entita se může odstranit při AutoDeleteOnIdle čištění.

Tip

Pokud chcete replikovat obsah front a odběrů témat a provoz odpovídajících oborů názvů v konfiguracích aktivní/aktivní, abyste se mohli vypořádat s výpadky a haváriemi, nezaklánějte se na tuto sadu funkcí geografického zotavení po havárii, ale postupujte podle pokynů k replikaci.

Výpadky a havárie

Je důležité si uvědomit rozdíl mezi "výpadky" a "haváriemi".

Výpadek je dočasná nedostupnost služby Azure Service Bus a může mít vliv na některé komponenty služby, jako je úložiště zpráv nebo dokonce celé datové centrum. Po vyřešení problému se ale service Bus znovu zpřístupní. Výpadek obvykle nezpůsobí ztrátu zpráv nebo jiných dat. Příkladem takového výpadku může být selhání napájení v datacentru. Některé výpadky jsou pouze krátké ztráty připojení kvůli přechodným problémům nebo problémům se sítí.

Havárie se definuje jako trvalá nebo dlouhodobější ztráta clusteru Service Bus, oblasti Azure nebo datacentra. Oblast nebo datacentrum může nebo nemusí být znovu k dispozici nebo může být po dobu hodin nebo dnů nedostupná. Příkladem takových katastrof jsou požáry, záplavy nebo zemětřesení. Havárie, která se stane trvalou, může způsobit ztrátu některých zpráv, událostí nebo jiných dat. Ve většině případů by ale nemělo dojít ke ztrátě dat a po zálohování datového centra je možné obnovit zprávy.

Funkce geografického zotavení po havárii služby Azure Service Bus je řešení zotavení po havárii. Koncepty a pracovní postupy popsané v tomto článku se vztahují na scénáře havárie, nikoli na přechodné nebo dočasné výpadky. Podrobné informace o zotavení po havárii v Microsoft Azure najdete v tomto článku.

Základní pojmy a pojmy

Funkce zotavení po havárii implementuje zotavení po havárii metadata a spoléhá na primární a sekundární obory názvů zotavení po havárii. Funkce geografického zotavení po havárii je dostupná jenom pro skladovou položku Premium. Nemusíte provádět žádné připojovací řetězec změny, 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 jeden stabilní plně kvalifikovaný název domény (FQDN) připojovací řetězec. Aplikace používají tento alias připojovací řetězec pro připojení k oboru názvů. Použití aliasu zajišťuje, že připojovací řetězec se při aktivaci převzetí služeb při selhání nezmění.

• Primární/sekundární obor názvů: Obory názvů, které odpovídají aliasu. Primární obor názvů je aktivní a přijímá zprávy (může se jednat o existující nebo nový obor názvů). Sekundární obor názvů je "pasivní" a nepřijímá zprávy. Metadata mezi oběma se synchronizují, takže oba můžou bezproblémově přijímat zprávy bez jakéhokoli kódu aplikace nebo připojovací řetězec změn. 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 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 oboru názvů.

Nastavení

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

Nejprve vytvoříte nebo použijete existující primární obor názvů a nový sekundární obor názvů a pak oba spárujete. 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í převzetí služeb při selhání je možné přidat pouze nové obory názvů.

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 při vytváření párování v dalším kroku.

3. Na webu 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. Na stránce Zahájit 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. Jako alias zadejte alias pro párování geografického zotavení po havárii.

   3. Potom vyberte Vytvořit.

      

6. Měla by se zobrazit stránka aliasu Geografické zotavení po havárii služby Service Bus, jak je znázorněno na následujícím obrázku. Na stránku Alias geografického zotavení po havárii můžete přejít také ze stránky primárního oboru názvů tak, že v nabídce vlevo vyberete Geografické obnovení.

   

7. Na stránce Alias geografického zotavení po havárii vyberte v nabídce vlevo zásady sdíleného přístupu a přejděte k primárnímu připojovací řetězec aliasu. Použijte tuto připojovací řetězec místo použití připojovací řetězec přímo k primárnímu nebo sekundárnímu oboru názvů. 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 Zalomit párování .
   2. Ruční převzetí služeb při selhání do sekundárního oboru názvů

      1. Na panelu nástrojů vyberte Převzetí služeb při selhání .

      2. Potvrďte, že chcete převzít služby při selhání sekundárního oboru názvů zadáním do svého aliasu.

      3. Zapněte možnost Sejf převzetí služeb při selhání, abyste mohli bezpečně převzít služby při selhání sekundárního oboru názvů.

         Poznámka:

         • Bezpečné převzetí služeb při selhání zajišťuje, aby se před přepnutím na sekundární replikaci dokončily čekající replikace geografické zotavení po havárii. Zatímco vynucené nebo ruční převzetí služeb při selhání nečeká na dokončení čekajících replikací před přepnutím na sekundární.
         • V současné době bezpečné převzetí služeb při selhání selže, pokud primární a sekundární obory názvů nejsou ve stejném předplatném Azure.

      4. Pak vyberte převzetí služeb při selhání.

         

         Důležité

         Převzetí služeb při selhání aktivuje sekundární obor názvů a odebere primární obor názvů z párování Geografické zotavení po havárii. Vytvořte další obor názvů, který bude mít nový pár geografického zotavení po havárii.

9. Nakonec byste měli přidat monitorování, abyste zjistili, jestli je potřeba převzetí služeb 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í 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 (tj. obor názvů Service Bus Standard připojovací řetězec) a vytvořit konfiguraci zotavení po havárii prostřednictvím rozhraní PŘÍKAZOVÉho řádku nebo rozhraní REST API.

Je to proto, že během migrace se váš standardní obor názvů služby Azure Service Bus připojovací řetězec/DNS stane aliasem vašeho oboru názvů Azure Service Bus Premium.

Klientské aplikace musí používat tento alias (tj. standardní obor názvů služby Azure Service Bus připojovací řetězec) pro připojení k oboru názvů premium, ve kterém je nastavené párování zotavení po havárii.

Pokud k nastavení konfigurace zotavení po havárii použijete Azure Portal, portál od vás tuto výstrahu abstrahuje.

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

Převzetí služeb při selhání se aktivuje ručně zákazníkem (buď explicitně příkazem, nebo prostřednictvím obchodní logiky vlastněné klientem, která příkaz aktivuje) a nikdy azure. Poskytuje zákazníkovi úplné vlastnictví a přehled o řešení výpadků v páteřní síti Azure.

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

1. Alias připojovací řetězec se aktualizuje tak, aby odkazovat 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 oborem názvů premium je přerušené.

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

1. Pokud dojde k jinému výpadku, chcete být schopni převzít služby při selhání znovu. Nastavte tedy další pasivní 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 obnovení nebo odstraňte starý primární obor názvů.

Poznámka:

Podporují se pouze sémantika předávání selhání. V tomto scénáři převezmete služby při selhání a pak znovu spárujete s novým oborem názvů. Navrácení služeb po obnovení se nepodporuje; Například v clusteru SQL.

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

Správa

Pokud jste například udělali chybu, spárovali jste nesprávné oblasti 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žití existujícího oboru názvů jako aliasu

Pokud máte scénář, ve kterém nemůžete změnit připojení producentů a příjemců, můžete název oboru názvů znovu použít jako název aliasu. 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ílání a příjem z aktuálního primárního nebo sekundárního oboru názvů pomocí aliasu

Důležité informace

Mějte na paměti následující aspekty, které je potřeba vzít v úvahu v této verzi:

• Při plánování převzetí služeb při selhání byste také měli zvážit časový faktor. Pokud například ztratíte připojení delší než 15 až 20 minut, můžete se rozhodnout zahájit převzetí služeb při selhání.
• Skutečnost, že se nereplikují žádná data, znamená to, že se aktuálně aktivní relace nereplikují. Kromě toho nemusí fungovat detekce duplicit a naplánované zprávy. Nové relace, nové naplánované zprávy a nové duplicity fungují.
• Převzetí služeb při selhání komplexní distribuované infrastruktury by mělo být na zkoušku alespoň jednou.
• 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.

Zóny dostupnosti

Skladová položka Service Bus Premium podporuje zóny dostupnosti a poskytuje izolovaná umístění v izolovaném stavu v rámci stejné oblasti Azure. Service Bus spravuje tři kopie úložiště zpráv (1 primární a 2 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ů. Pokud aplikace uvidí přechodné odpojení od služby Service Bus, logika opakování v sadě SDK se automaticky znovu připojí ke službě Service Bus.

Když používáte zóny dostupnosti, metadata i data (zprávy) se replikují napříč datovými centry v zóně dostupnosti.

Poznámka:

Podpora služby Azure Service Bus Premium Zóny dostupnosti je dostupná jenom v oblastech Azure, kde jsou k dispozici zóny dostupnosti.

Při vytváření oboru názvů úrovně Premium prostřednictvím portálu se pro obor názvů automaticky povolí podpora zón dostupnosti (pokud je dostupná ve vybrané oblasti). Při vytváření oboru názvů úrovně Premium prostřednictvím jiných mechanismů, jako jsou šablony ARM / Bicep, rozhraní příkazového řádku nebo PowerShell, musí být vlastnost zoneRedundant explicitně nastavená tak, aby true povolovat zóny dostupnosti (pokud jsou dostupné ve vybrané oblasti). Za použití této funkce nejsou žádné další náklady a po vytvoření oboru názvů nemůžete tuto funkci zakázat ani povolit.

Privátní koncové body

Tato část obsahuje další aspekty použití geografického zotavení po havárii s obory názvů, které použí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. Doporučujeme používat stejné konfigurace v primárních a sekundárních oborech názvů a ve virtuálních sítích, ve kterých se vytvářejí 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ší zodpovědností zajistit, aby sekundární obor názvů s privátním koncovým bodem fungoval očekávaným způsobem po převzetí služeb 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 problém vyřešit, nejprve vytvořte privátní koncový bod v sekundárním oboru názvů a pak vytvořte privátní koncový bod pro primární obor názvů.

Poznámka:

I když povolíme přístup jen pro čtení k sekundárnímu oboru názvů, jsou povoleny aktualizace konfigurací privátních koncových bodů.

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.

Řekněme, že máte dvě virtuální sítě: VNET-1, VNET-2 a tyto primární a sekundární obory názvů: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Potřebujete provést následující kroky:

• Vytvořte ServiceBus-Namespace1-Primarydva privátní koncové body, které používají podsítě z virtuální sítě VNET-1 a VNET-2.
• Vytvořte ServiceBus-Namespace2-Secondarydva privátní koncové body, které používají stejné podsítě z virtuální sítě 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: V této části neexistuje v síti VNET-1, ale přesune 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ů VNET-1 i VNET-2, aplikace funguje jenom.

Převzetí služeb při selhání pouze s oborem názvů služby Service Bus: Tady je opět k dispozici, protože 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 prostě funguje.

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) společnosti Microsoft k entitám služby 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 s frontami služby Service Bus
• Jak používat témata a odběry Service Bus
• REST API