Geografické zotavení po havárii Azure Service Bus

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

Azure Service Bus už rozprostíří riziko katastrofických selhání jednotlivých počítačů nebo dokonce kompletních racků napříč clustery, které zahrnují více domén selhání v rámci datacentra, a implementuje transparentní mechanismy detekce selhání a převzetí služeb při selhání tak, aby služba pokračovala v provozu v rámci zajištěných úrovní služeb a obvykle bez znatelného přerušení v případě takových selhání. Pokud byl vytvořen obor názvů Service Bus s povolenou možností pro zóny dostupnosti,riziko je riziko výpadku dále rozdělené mezi tři fyzicky oddělená zařízení a služba má dostatek rezerv na kapacitu, aby se okamžitě dokázala vypořádat s úplnou a katastrofickou ztrátou celého zařízení.

Model clusteru Azure Service Bus s podporou zóny dostupnosti je vynikající než jakýkoli místní produkt zprostředkovatele zpráv z hlediska odolnosti proti selhání hardwaru a dokonce katastrofické ztrátě celých zařízení datacentra. Stále ale můžou být situace s rozsáhlou fyzickou likvidací, proti které se ani tato opatření dostatečně nezabrání.

Funkce Service Bus geografické zotavení po havárii je navržená tak, aby usnadnila zotavení po havárii tohoto rozsahu a v dobrém případě opustila neúspěšnou oblast Azure, aniž byste museli 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 Service Bus Premium SKU.

Funkce obnovení Geo-Disaster zajišťuje, že se při spárování průběžně 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řesun převzetí služeb při selhání z primárního do sekundárního. Přesun převzetí služeb při selhání znovu nasídí název zvoleného aliasu pro obor názvů do sekundárního oboru názvů a pak párování přeruší. Převzetí služeb při selhání je po zahájení téměř okamžité.

Výpadky a havárie

Je důležité si rozlišovat mezi "výpadky" a "haváriemi".

Výpadkem je dočasná nedostupnost služby Azure Service Bus, která může mít vliv na některé komponenty služby, jako je úložiště zasílání zpráv nebo dokonce celé datacentrum. Jakmile se ale problém vyřeší, Service Bus znovu k dispozici. Výpadky obvykle nezpůsobí ztrátu zpráv nebo jiných dat. Příkladem takového výpadku může být výpadek napájení v datacentru. Některé výpadky jsou jen 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á ztráta clusteru Service Bus, oblasti Azure nebo datacentra. Oblast nebo datacentrum může nebo nemusí být znovu dostupné nebo může být po dobu hodin nebo dnů neschová. Příkladem takových havárií 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 však neměla dohrat data a zprávy je možné po zálohování datového centra obnovit.

Funkce geografické 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. Podrobnou diskuzi o zotavení po havárii v Microsoft Azure v tomto článku.

Základní pojmy a pojmy

Funkce zotavení po havárii implementuje zotavení po havárii metadat 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 Premium SKU. Nemusíte provádět žádné změny připojovacího řetězce, protože připojení se 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í připojovací řetězec plně kvalifikovaného názvu domény (FQDN). Aplikace používají tento připojovací řetězec aliasu pro připojení k oboru názvů. Použití aliasu zajistí, že se připojovací řetězec 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 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 typy jsou synchronizovaná, takže obě mohou bez problémů přijímat zprávy beze změny kódu aplikace nebo připojovacího řetězce. Abyste zajistili, že zprávy obdrží jenom 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ženy 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 tyto dva obory názvů spárujete. Toto párování poskytuje alias, který můžete použít pro připojení. Protože používáte alias, nemusíte měnit připojovací řetězce. 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ů.

2. Vytvořte sekundární obor názvů v jiné oblasti. Tento krok je volitelný. Sekundární obor názvů můžete vytvořit při vytváření párování v dalším kroku.

3. V Azure Portal přejděte do 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 vytvořte obor názvů 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é geografické dr.

   3. Potom vyberte Vytvořit.

      

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

   

7. Na stránce Alias geografické ochrany před internetem vyberte v levé nabídce Zásady sdíleného přístupu a přejděte k primárnímu připojovacímu řetězci aliasu. Tento připojovací řetězec použijte místo přímého použití připojovacího řetězce k primárnímu/sekundárnímu oboru názvů. Zpočátku alias 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. Přerušení párování mezi primárním a sekundárním oborem názvů Na panelu nástrojů vyberte Break pairing (Přerušit párování).
   2. Ruční převzetí služeb při selhání sekundárním oborem názvů.

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

      2. Zadáním svého aliasu potvrďte, že chcete převzetí služeb při selhání do sekundárního oboru názvů.

      3. Zapněte možnost převzetí služeb Sejf převzetí služeb při selhání, aby se služby při selhání bezpečně přehodí do sekundárního oboru názvů. Tato funkce zajišťuje, aby se před přepnutím na sekundární dokončily čekající geografické replikace po selhání.

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

         

         Důležité

         Při selhání se aktivuje sekundární obor názvů a odebere se primární obor názvů z párování Geo-Disaster Recovery. Vytvořte další obor názvů, který bude mít nový pár geografických zotavení po havárii.

9. Nakonec byste měli přidat monitorování, které zjistí, jestli je převzetí služeb při selhání nezbytné. Ve většině případů je služba jednou ze součástí velkého ekosystému, takže automatické převzetí služeb při selhání je zřídka možné, protože převzetí služeb při selhání se často musí provádět synchronizovaně se zbývajícím subsystémem nebo infrastrukturou.

Service Bus z úrovně Standard na Premium

Pokud jste migroval obor názvů Azure Service Bus Standarddo Azure Service Bus Premium , pak musíte pomocí existujícího aliasu (to znamená připojovacího řetězce oboru názvů Service Bus Standard) vytvořit konfiguraci zotavení po havárii prostřednictvím Ps/CLI nebo REST API.

Je to proto, že během migrace se připojovací řetězec oboru názvů Azure Service Bus Standard nebo samotný název DNS stane aliasem pro váš obor názvů služby Azure Service Bus Premium.

Klientské aplikace musí tento alias (to znamená připojovací řetězec oboru názvů Azure Service Bus Standard) využít pro připojení k oboru názvů Premium, kde je nastavené párování zotavení po havárii.

Pokud k nastavení konfigurace zotavení po havárii použijete portál, portál toto upozornění od vás abstrahuje.

Postup 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ě prostřednictvím příkazu, nebo prostřednictvím obchodní logiky vlastněné klientem, která spouští příkaz) a nikdy neplatí pro Azure. Poskytuje zákazníkům ú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. připojovací řetězec aliasu je aktualizovaný, aby odkazoval na sekundární obor názvů Premium.

2. Klienti (odesílatelé a přijímače) se automaticky připojí 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šeno.

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

1. Pokud dojde k dalšímu výpadku, budete chtít být schopni převzít služby po obnovení. Proto nastavte další pasivní obor názvů a aktualizujte párování.

2. Vyžádat zprávy z bývalého primárního oboru názvů, jakmile budou opět k dispozici. Potom tento obor názvů použijte pro běžné zasílání zpráv mimo instalaci geografického obnovení, nebo odstraňte starý primární obor názvů.

Převzetí služeb při selhání můžete automatizovat buď s monitorovacími systémy, nebo s vlastními řešeními monitorování. Tato automatizace ale má dodatečné plánování a práci, což není v rozsahu tohoto článku.

Správa

Pokud jste udělali chybu; například jste spároval nesprávné oblasti při počátečním nastavení, můžete kdykoli rozdělit párování obou oborů názvů. Pokud chcete používat spárované obory názvů jako běžné obory názvů, odstraňte alias.

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

Pokud máte scénář, ve kterém nemůžete změnit připojení výrobců a uživatelů, můžete název oboru názvů použít jako název aliasu. podívejte se na ukázkový kód v GitHub.

ukázky

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

• ukázka a nastavení .net, které jsou požadovány v Azure Active Directory pro použití Azure Resource Manager s Service Bus, k nastavení a povolení geografického zotavení po havárii.
• Postup potřebný ke spuštění ukázkového kódu.
• Jak používat existující obor názvů jako alias.
• Postup nebo umožnění geografického zotavení po havárii prostřednictvím PowerShellu nebo rozhraní příkazového řádku.
• Odeslat a přijmout z aktuálního primárního nebo sekundárního oboru názvů pomocí aliasu

Požadavky

Vezměte v úvahu následující skutečnosti:

1. Při plánování převzetí služeb při selhání byste měli také zvážit časový faktor. Pokud například ztratíte připojení po dobu delší než 15 až 20 minut, můžete se rozhodnout zahájit převzetí služeb při selhání.

2. Skutečnost, že se žádná data nereplikují, znamená, že aktuálně aktivní relace nejsou replikované. Kromě toho nemusí fungovat duplicita duplicit a naplánované zprávy. Nové relace, nové naplánované zprávy a nové duplicity budou fungovat.

3. Převzetí služeb při selhání přes složitou distribuovanou infrastrukturu by mělo být alespoň jednou vyzkoušeno .

4. Synchronizace entit může nějakou dobu trvat přibližně 50-100 entit za minutu. Předplatná a pravidla se také počítají jako entity.

Zóny dostupnosti

SKU Service Bus Premium podporuje Zóny dostupnostia poskytuje umístění izolovaných chyb v rámci stejné oblasti Azure. Service Bus spravuje tři kopie úložiště pro zasílání zpráv (1 primární a 2 sekundární). Service Bus udržuje všechny tři kopie synchronizovány s daty a operacemi správy. Pokud primární kopie neproběhne úspěšně, jedna ze sekundárních kopií bude povýšena na primární bez pozorovaného výpadku. pokud se aplikace zobrazí jako přechodné odpojení od Service Bus, logika opakování v sadě SDK se automaticky znovu připojí k Service Bus.

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

Zóny dostupnosti můžete povolit jenom pro nové obory názvů pomocí Azure Portal. Service Bus nepodporuje migraci stávajících oborů názvů. Po povolení v oboru názvů nelze zakázat redundanci zóny.

Privátní koncové body

V této části najdete další informace o použití geografického zotavení po havárii s obory názvů, které používají privátní koncové body. další informace o používání privátních koncových bodů s Service Bus obecně najdete v tématu integrování azure Service Bus s privátním propojením azure.

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í bude úspěšné pouze v případě, že oba primární i sekundární obory názvů mají privátní koncové body. Doporučujeme použít stejné konfigurace na primárních a sekundárních oborech názvů a na virtuálních sítích, ve kterých jsou vytvořeny privátní koncové body.

Existující párování

Pokud párování mezi primárním a sekundárním oborem názvů už existuje, vytvoření privátního koncového bodu na primárním oboru názvů se nezdaří. Chcete-li tento problém vyřešit, vytvořte nejprve privátní koncový bod v sekundárním oboru názvů a potom jej vytvořte pro primární obor názvů.

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ů Service Bus pro virtuální sítě, které hostují 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 druhé obory názvů: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Je třeba provést následující kroky:

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

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

Převzetí služeb při selhání jen pro aplikace: V tomto případě aplikace nebude existovat v VNET-1, ale přesune se do sítě VNET-2. Jak jsou oba privátní koncové body konfigurovány pro virtuální i sekundární obory názvů VNET-1 i VNET-2, bude aplikace pracovat pouze.

Service Bus převzetí služeb při selhání jen pro obor názvů: tady se nakonfigurují oba privátní koncové body v obou virtuálních sítích pro primární i sekundární obory názvů. aplikace bude jenom fungovat.

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

Azure Active Directory (Azure AD) přiřazení řízení přístupu na základě role (RBAC) k Service Bus entitám v primárním oboru názvů se nereplikují do sekundárního oboru názvů. Ručně vytvořte přiřazení rolí v sekundárním oboru názvů a zabezpečte přístup k nim.

Další kroky

• Tady najdete referenčníinformace o geografickém zotavení po havárii REST API.
• Spusťte ukázku geografického zotavení po havárii na GitHub.
• Podívejte se na ukázku obnovení geografického po havárii , které odesílá zprávy do aliasu.

další informace o Service Bus zasílání zpráv 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
• Rozhraní REST API