Azure Event Hubs – Geografické zotavení po havárii
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 Event Hubs už šíří 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 i nadále provozoval 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ů Event Hubs s povolenou možností pro zóny dostupnosti,riziko výpadku je dále rozloženo do tří fyzicky oddělených zařízení a služba má dostatek rezerv kapacity, aby se okamžitě dokázala vypořádat s kompletní a katastrofickou ztrátou celého zařízení.
Model clusterů se všemi aktivními Azure Event Hubs s podporou zóny dostupnosti poskytuje odolnost proti selhání hardwaru hardwaru a dokonce i 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í nemohou dostatečně bránit.
Funkce Event Hubs 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.
Funkce obnovení Geo-Disaster zajišťuje, že se při spárování průběžně replikuje celá konfigurace oboru názvů (Event Hubs, skupiny uživatelů a nastavení) 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í přemístí zvolený název aliasu pro obor názvů na sekundární obor 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é.
Důležité
- Tato funkce umožňuje okamžitou kontinuitu operací se stejnou konfigurací, ale nereplikuje data události. Pokud havárie nez způsobovala ztrátu všech zón, data událostí, která se po převzetí služeb při selhání zachovají v primárním centru událostí, budou obnovitelná a po obnovení přístupu je možné získat historické události. Pokud chcete replikovat data událostí a provoz odpovídajících oborů názvů v konfiguracích aktivní/aktivní, abyste se dokázali vypořádat s výpadky a haváriemi, neopíráte se o tuto sadu funkcí geografického zotavení po havárii, ale postupujte podle pokynů k replikaci.
- Azure Active Directory (Azure AD) řízení přístupu na základě role (RBAC) k 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ů, abyste k nim zabezpečili přístup.
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 Event Hubs, 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ší, Event Hubs 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 Event Hubs, 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 Azure Event Hubs ř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 standardní, prémiové a vyhrazené skladové oblasti. 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ů.
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 centra událostí a skupiny uživatelů. a jejich vlastnosti služby, které jsou přidruženy 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ího a sekundárního oboru názvů:
| Úroveň primárního oboru názvů | Povolená úroveň sekundárního oboru názvů |
|---|---|
| Standard | Standard, Dedicated |
| Premium | Premium |
| Vyhrazená | Vyhrazená |
Poznámka
Nemůžete spárovat obory názvů, které jsou ve stejném vyhrazeném clusteru. 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í.
Nastavení
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ů.
Vytvořte primární obor názvů.
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.
V Azure Portal přejděte do 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 vytvořte obor názvů v jiné oblasti. V tomto příkladu je vybrán existující obor názvů.
- Jako Alias zadejte alias pro párování geografické geografické dr.
- Potom vyberte Vytvořit.
Měla by se zobrazit stránka Alias geografické geografické dr. 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é 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ů.
Na této stránce Přehled můžete provést následující akce:
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í).
Ruční převzetí služeb při selhání sekundárním oborem názvů. Na panelu nástrojů vyberte Převzetí služeb při selhání.
Upozornění
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.
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.
Příklad
V jednom příkladu tohoto scénáře zvažte řešení poprodejní aplikace, které vysílá zprávy nebo události. Event Hubs události předá do nějakého řešení mapování nebo přeformátování, které pak přeposílá mapovaná data do jiného systému k dalšímu 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 jakou část převezme 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ď 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.
Postup převzetí služeb při selhání
Pokud zahájíte převzetí služeb při selhání, vyžadují se dva kroky:
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í.
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ů.
Poznámka
Jsou podporovány pouze sémantiky při předání služeb při selhání. V tomto scénáři převezmete služby při selhání a pak znovu spárujte s novým oborem názvů. Navrácení služeb po obnovení není podporováno. například v clusteru SQL.
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.
Požadavky
Vezměte na vědomí následující skutečnosti:
V rámci návrhu Event Hubs geograficky zotavení po havárii nereplikují data, a proto nemůžete znovu použít starou hodnotu posunu primárního centra událostí v sekundárním centru událostí. K restartování přijímače událostí doporučujeme použít jednu z následujících metod:
- 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 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 od daného data a času.
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í.
Skutečnost, že nejsou replikována žádná data znamená, že aktuální aktivní relace nebudou replikovány. Kromě toho nemusí fungovat duplicita duplicit a naplánované zprávy. Budou fungovat nové relace, naplánované zprávy a nové duplicity.
Převzetí služeb při selhání přes složitou distribuovanou infrastrukturu by mělo být alespoň jednou vyzkoušeno .
Synchronizace entit může nějakou dobu trvat přibližně 50-100 entit za minutu.
Zóny dostupnosti
Event Hubs podporuje zóny dostupnostia poskytuje umístění s izolací chyb v oblasti Azure. Podpora Zóny dostupnosti je dostupná jenom v oblastech Azure se zónami dostupnosti. Metadata i data (události) se replikují napříč datovými centry v zóně dostupnosti.
Při vytváření oboru názvů se zobrazí následující zvýrazněná zpráva, když vyberete oblast, která má zóny dostupnosti.
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 Event Hubs obecně 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 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.
Poznámka
Když se pokusíte spárovat primární obor názvů se soukromým koncovým bodem a sekundárním oborem názvů, proces ověření kontroluje pouze to, zda privátní koncový bod existuje v sekundárním oboru názvů. Nekontroluje, jestli koncový bod funguje nebo bude po převzetí služeb při selhání fungovat. Je vaše zodpovědnost za to, že sekundární obor názvů s privátním koncovým bodem bude po převzetí služeb při selhání fungovat podle očekávání.
Pokud chcete otestovat, jestli jsou konfigurace privátních koncových bodů stejné na primárních a sekundárních oborech názvů, pošlete žádost o čtení (třeba získat centrum událostí) do sekundárního oboru názvů mimo virtuální síť a ověřte, že se od této služby zobrazila chybová zpráva.
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ů.
Poznámka
I když povolujeme přístup jen pro čtení k sekundárnímu oboru názvů, jsou povoleny aktualizace konfigurací privátního koncového bodu.
Doporučená konfigurace
Při vytváření konfigurace zotavení po havárii pro vaše aplikace a Event Hubs obory názvů je nutné vytvořit privátní koncové body pro primární i sekundární obory názvů Event Hubs na virtuálních sítích hostujících primární i sekundární instanci 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. Je třeba provést následující kroky:
- V EventHubs-Namespace1-Primary vytvořte dva privátní koncové body, které používají podsítě z VNET-1 a VNET-2.
- V EventHubs-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 Event Hubs 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.
Event Hubs 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.
Poznámka
Pokyny pro obnovení geografických havárií virtuální sítě najdete v tématu Virtual Network – provozní kontinuita.
Řízení přístupu na základě role
přiřazení řízení přístupu na základě role (RBAC) Azure Active Directory (služba Azure AD) k 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
Přečtěte si následující ukázky nebo referenční dokumentaci.