Azure Event Hubs – Geografické zotavení po havárii
Tento článek popisuje funkci geografického zotavení po havárii, která replikuje metadata a je obecně dostupná. Nepopisuje funkci geografické replikace ve verzi Public Preview, která replikuje data i metadata. Další informace najdete v tématu Geografická replikace.
Model clusteru Azure Event Hubs s aktivní podporou zóny dostupnosti zajišťuje odolnost proti výpadkům hardwaru a datacentra. Pokud ale dojde k havárii, kde je celá oblast a všechny zóny nedostupné, můžete pomocí geografického zotavení po havárii obnovit úlohu a konfiguraci aplikace. Geografické zotavení po havárii zajišťuje, že se při spárování nepřetržitě replikuje celá konfigurace oboru názvů (Event Hubs, Skupiny příjemců a nastavení) z primárního oboru názvů do sekundárního oboru názvů.
Funkce geografického zotavení po havárii služby Azure Event Hubs je řešení zotavení po havárii. Koncepty a pracovní postup popsané v tomto článku se vztahují na scénáře havárie, a ne na dočasné výpadky. Podrobné informace o zotavení po havárii v Microsoft Azure najdete v tomto článku. Díky geografickému zotavení po havárii můžete kdykoli zahájit přechod z primárního do sekundárního převzetí služeb při selhání pouze jednou. Přesunutí převzetí služeb při selhání odkazuje na zvolený název aliasu pro obor názvů do sekundárního oboru názvů. Po přesunutí se párování odebere. Převzetí služeb při selhání je téměř okamžité po zahájení.
Důležité
- Tato funkce umožňuje okamžitou kontinuitu operací se stejnou konfigurací, ale nereplikuje data událostí. Pokud havárie způsobila ztrátu všech zón, data událostí, která se zachovají v primárním centru událostí po převzetí služeb při selhání, budou obnovitelná a po obnovení přístupu se z ní dají získat historické události. Pokud chcete replikovat data událostí a provozovat odpovídající obory názvů v konfiguracích aktivní/aktivní, abyste se mohli vypořádat s výpadky a haváriemi, nespočívejte na tuto sadu funkcí geografického zotavení po havárii, ale postupujte podle pokynů k replikaci.
- Přiřazení řízení přístupu na základě role (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ů.
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 úrovně Standard, Premium a Dedicated. 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ů.
- 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 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 centra událostí a skupiny příjemců, a jejich vlastnosti služby přidružené k oboru názvů. Automaticky se replikují jenom entity a jejich nastavení. Zprávy a události se nereplikují.
- Převzetí služeb při selhání: Proces aktivace sekundárního oboru názvů.
Podporované páry oborů názvů
Podporují se následující kombinace primárních a sekundárních oborů názvů:
Primární úroveň oboru názvů | Povolená sekundární úroveň oboru názvů |
---|---|
Standard | Standard, Dedicated |
Premium | Premium |
Vyhrazené | Vyhrazené |
Důležité
Obory názvů, které jsou ve stejném vyhrazeném clusteru, nemůžete spárovat. Obory názvů, které jsou v samostatných clusterech, můžete spárovat.
Nastavení a tok převzetí služeb při selhání
Následující část obsahuje přehled procesu převzetí služeb při selhání a vysvětluje, jak nastavit počáteční převzetí služeb při selhání.
Poznámka:
Funkce geografického zotavení po havárii nepodporuje automatické převzetí služeb při selhání.
Nastavení
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ů.
Vytvořte primární obor názvů.
Vytvořte sekundární obor názvů 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.
Na webu Azure Portal přejděte do svého primárního oboru názvů.
V nabídce vlevo vyberte Geografické obnovení a na panelu nástrojů vyberte Zahájit párování .
Na stránce Zahájit párování postupujte takto:
- Vyberte existující sekundární obor názvů nebo ho vytvořte v jiné oblasti. V tomto příkladu je vybraný existující obor názvů.
- Jako alias zadejte alias pro párování geografického zotavení po havárii.
- Potom vyberte Vytvořit.
Měla by se zobrazit stránka Alias geografického zotavení po havárii. Na tuto stránku můžete přejít také z primárního oboru názvů tak, že v nabídce vlevo vyberete Geografické obnovení .
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ů.
Na této stránce Přehled můžete provést následující akce:
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í .
Ruční převzetí služeb při selhání do sekundárního oboru názvů Na panelu nástrojů vyberte Převzetí služeb při selhání .
Upozorňující
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.
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, a proto je automatické převzetí služeb při selhání 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.
Příklad
V jednom příkladu tohoto scénáře zvažte řešení typu Point of Sale (POS), které generuje zprávy nebo události. Event Hubs tyto události předá některému řešení mapování nebo přeformátování, které pak mapovaná data předá jinému systému pro další zpracování. V tomto okamžiku můžou být všechny tyto systémy hostované ve stejné oblasti Azure. Rozhodnutí o tom, kdy a jaká část se má převzít služby při selhání, závisí na toku dat ve vaší infrastruktuře.
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.
Tok převzetí služeb při selhání
Pokud zahájíte převzetí služeb při selhání, jsou potřeba dva kroky:
- Pokud dojde k jinému výpadku, chcete být schopni převzít služby při selhání znovu. Proto nastavte další pasivní obor názvů a aktualizujte párování.
- 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.
Ruční převzetí služeb při selhání
V této části se dozvíte, jak ručně převzít služby při selhání pomocí webu Azure Portal, rozhraní příkazového řádku, PowerShellu, C# atd.
Na webu Azure Portal přejděte do svého primárního oboru názvů.
V nabídce vlevo vyberte Geografické obnovení .
Ruční převzetí služeb při selhání do sekundárního oboru názvů Na panelu nástrojů vyberte Převzetí služeb při selhání .
Upozorňující
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.
Správa
Pokud jste udělali chybu; Například jste během počátečního nastavení spárovali nesprávné oblasti, 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.
Důležité informace
Mějte na paměti následující aspekty:
Geografická zotavení po havárii služby Event Hubs záměrně nereplikuje data, a proto nemůžete znovu použít starou hodnotu posunu primárního centra událostí v sekundárním centru událostí. Doporučujeme restartovat příjemce událostí jedním z následujících způsobů:
- EventPosition.FromStart() – Pokud chcete číst všechna data v sekundárním centru událostí.
- EventPosition.FromEnd() – Pokud chcete číst všechna nová data z doby připojení k vašemu sekundárnímu centru událostí.
- EventPosition.FromEnqueuedTime(dateTime) – Pokud chcete číst všechna data přijatá v sekundárním centru událostí počínaje daným datem a časem.
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 nereplikují aktuální aktivní relace. Kromě toho nemusí fungovat detekce duplicit a naplánované zprávy. Nové relace, naplánované zprávy a nové duplicity budou fungovat.
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.
Některé aspekty roviny správy sekundárního oboru názvů se stanou jen pro čtení, zatímco párování geografického obnovení je aktivní.
Datová rovina sekundárního oboru názvů bude jen pro čtení, zatímco párování geografického obnovení je aktivní. Rovina dat sekundárního oboru názvů přijme požadavky GET, které umožní ověření připojení klienta a řízení přístupu.
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 Event Hubs najdete v tématu Konfigurace privátních koncových bodů.
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 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í zkontroluje, jestli v sekundárním oboru názvů existuje privátní koncový bod. Nekontroluje, jestli koncový bod funguje nebo bude fungovat 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, jestli jsou konfigurace privátního koncového bodu stejné v primárních a sekundárních oborech názvů, odešlete požadavek na čtení (například: Získat centrum událostí) 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še aplikace a obory názvů služby Event Hubs musíte vytvořit privátní koncové body pro primární i sekundární obory názvů služby Event Hubs 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ů: EventHubs-Namespace1-Primary
, EventHubs-Namespace2-Secondary
. Potřebujete provést následující kroky:
- Při
EventHubs-Namespace1-Primary
vytváření dvou privátních koncových bodů, které používají podsítě zVNET-1
aVNET-2
- Při
EventHubs-Namespace2-Secondary
vytváření dvou privátních koncových bodů, které používají stejné podsítě zVNET-1
aVNET-2
Výhodou tohoto přístupu je, že převzetí služeb při selhání může na aplikační vrstvě probíhat nezávisle na oboru názvů služby Event Hubs. Zvažte následující scénáře:
Převzetí služeb při selhání pouze aplikace: V tomto případě aplikace neexistuje VNET-1
, ale přesune se na VNET-2
. Vzhledem k tomu, že jsou oba privátní koncové body nakonfigurované pro VNET-1
primární i sekundární obory názvů, VNET-2
bude aplikace fungovat jenom.
Převzetí služeb při selhání pouze s oborem názvů služby Event Hubs: Tady znovu platí, že obě privátní koncové body jsou nakonfigurované v obou virtuálních sítích pro primární i sekundární obory názvů, aplikace bude fungovat jenom.
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) 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ů.
Související obsah
Projděte si následující ukázky nebo referenční dokumentaci.
Váš názor
https://aka.ms/ContentUserFeedback.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu:Odeslat a zobrazit názory pro