Azure Event Hubs – geografická zotavení po haváriiAzure Event Hubs - Geo-disaster recovery

Odolnost proti katastrofální důsledkym výpadků prostředků zpracování dat je požadavkem pro mnoho podniků a v některých případech i v případě potřeby i podle odvětví.Resilience against disastrous outages of data processing resources is a requirement for many enterprises and in some cases even required by industry regulations.

Azure Event Hubs už šíří riziko závažných chyb jednotlivých počítačů nebo dokonce kompletních stojanů napříč clustery, které v rámci datového centra přesahují více domén selhání, a implementuje transparentní mechanismy detekce selhání a převzetí služeb při selhání, takže služba bude dále fungovat 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í.Azure Event Hubs already spreads the risk of catastrophic failures of individual machines or even complete racks across clusters that span multiple failure domains within a datacenter and it implements transparent failure detection and failover mechanisms such that the service will continue to operate within the assured service-levels and typically without noticeable interruptions in the event of such failures. Pokud byl vytvořen obor názvů Event Hubs s možností povolení pro zóny dostupnosti, riziko výpadku je dále rozdělené mezi tři fyzicky oddělená zařízení a služba má dostatečné rezervy na kapacitu, aby se okamžitě vypořádat s kompletní a velmi závažnou ztrátou celého zařízení.If an Event Hubs namespace has been created with the enabled option for availability zones, the risk is outage risk is further spread across three physically separated facilities, and the service has enough capacity reserves to instantly cope with the complete, catastrophic loss of the entire facility.

Model clusteru pro všechny aktivní služby Azure Event Hubs s podporou zóny dostupnosti poskytuje odolnost proti čárkám, které nestačí k selhání hardwaru, i i k závažným ztrátám celých zařízení Datacenter.The all-active Azure Event Hubs cluster model with availability zone support provides resiliency against grave hardware failures and even catastrophic loss of entire datacenter facilities. Pořád se může stát, že v případě vysokého fyzického zničení dojde k závažné situaci, že i tyto míry nemůžou dostatečně bránit.Still, there might be grave situations with widespread physical destruction that even those measures cannot sufficiently defend against.

Event Hubs funkce geografického zotavení po havárii je navržená tak, aby se usnadnilo zotavení po havárii této velikosti, aby nedošlo k selhání oblasti Azure pro zajištění dobrého a nemusíte měnit konfigurace aplikace.The Event Hubs Geo-disaster recovery feature is designed to make it easier to recover from a disaster of this magnitude and abandon a failed Azure region for good and without having to change your application configurations. Opuštění oblasti Azure obvykle zahrnuje několik služeb a tato funkce primárně směřuje k tomu, že pomáhá zachovat integritu konfigurace složených aplikací.Abandoning an Azure region will typically involve several services and this feature primarily aims at helping to preserve the integrity of the composite application configuration.

Funkce obnovení Geo-Disaster zajišťuje, aby byla celá konfigurace oboru názvů (Event Hubs, skupiny uživatelů a nastavení) průběžně replikována z primárního oboru názvů do sekundárního oboru názvů, pokud je spárována, a umožňuje kdykoli spustit pouze jednou převzetí služeb při selhání z primární na sekundární.The Geo-Disaster recovery feature ensures that the entire configuration of a namespace (Event Hubs, Consumer Groups and settings) is continuously replicated from a primary namespace to a secondary namespace when paired, and it allows you to initiate a once-only failover move from the primary to the secondary at any time. Přesunutí převzetí služeb při selhání znovu nasměruje zvolený název aliasu oboru názvů na sekundární obor názvů a potom přeruší párování.The failover move will re-point the chosen alias name for the namespace to the secondary namespace and then break the pairing. Převzetí služeb při selhání je skoro okamžité po zahájení.The failover is nearly instantaneous once initiated.

Důležité

Tato funkce umožňuje okamžitou kontinuitu operací se stejnou konfigurací, ale nereplikuje data události.The feature enables instantaneous continuity of operations with the same configuration, but does not replicate the event data. Pokud havárie nezpůsobí ztrátu všech zón, data události se po převzetí služeb při selhání v primárním centru událostí zachovají a historické události se dají získat hned po obnovení přístupu.Unless the disaster caused the loss of all zones, the event data is preserved in the primary Event Hub after failover will be recoverable and the historic events can be obtained from there once access is restored. Pokud chcete replikovat data událostí a provozovat odpovídající obory názvů v aktivních/aktivních konfiguracích a vypořádat se s výpadky a katastrofami, nevybírejte tuto sadu funkcí geografického zotavení po havárii, ale postupujte podle pokynů pro replikaci.For replicating event data and operating corresponding namespaces in active/active configurations to cope with outages and disasters, don't lean on this Geo-disaster recovery feature set, but follow the replication guidance.

Výpadky a havárieOutages and disasters

Je důležité poznamenat rozdíl mezi "výpadky" a "katastrofami".It's important to note the distinction between "outages" and "disasters." Výpadek je dočasná nedostupnost Azure Event Hubs a může ovlivnit některé součásti služby, jako je třeba úložiště pro zasílání zpráv nebo i celé datacentrum.An outage is the temporary unavailability of Azure Event Hubs, and can affect some components of the service, such as a messaging store, or even the entire datacenter. Po vyřešení problému však bude Event Hubs opět k dispozici.However, after the problem is fixed, Event Hubs becomes available again. Obvykle výpadek nezpůsobí ztrátu zpráv nebo jiných dat.Typically, an outage doesn't cause the loss of messages or other data. Příkladem takového výpadku může být výpadek napájení v datovém centru.An example of such an outage might be a power failure in the datacenter. Některé výpadky představují jenom krátké ztráty připojení kvůli přechodným nebo síťovým problémům.Some outages are only short connection losses because of transient or network issues.

Havárie se definuje jako trvalá nebo dlouhodobá ztráta Event Hubs clusteru, oblasti Azure nebo datového centra.A disaster is defined as the permanent, or longer-term loss of an Event Hubs cluster, Azure region, or datacenter. Oblast nebo datové centrum může nebo nemusí být k dispozici znovu nebo může být vypnuté hodiny nebo dny.The region or datacenter may or may not become available again, or may be down for hours or days. Příklady takových katastrof jsou požáry, zahlcení nebo zemětřesení.Examples of such disasters are fire, flooding, or earthquake. Havárie, která se stala trvalo, může způsobit ztrátu některých zpráv, událostí nebo jiných dat.A disaster that becomes permanent might cause the loss of some messages, events, or other data. Ve většině případů by ale nemělo dojít ke ztrátě dat a po zálohování datového centra se dají obnovit zprávy.However, in most cases there should be no data loss and messages can be recovered once the data center is back up.

Funkce geografického zotavení po havárii v Azure Event Hubs je řešení zotavení po havárii.The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. Koncepty a pracovní postupy popsané v tomto článku se týkají scénářů po havárii a nepřechodných nebo dočasných výpadků.The concepts and workflow described in this article apply to disaster scenarios, and not to transient, or temporary outages. Podrobnou diskuzi o zotavení po havárii v Microsoft Azure najdete v tomto článku.For a detailed discussion of disaster recovery in Microsoft Azure, see this article.

Základní pojmy a pojmyBasic concepts and terms

Funkce zotavení po havárii implementuje zotavení po havárii metadat a závisí na primárních a sekundárních oborech názvů pro zotavení po havárii.The disaster recovery feature implements metadata disaster recovery, and relies on primary and secondary disaster recovery namespaces.

Funkce geografického zotavení po havárii je dostupná jenom pro standardní a vyhrazené SKU .The Geo-disaster recovery feature is available for the standard and dedicated SKUs only. Nemusíte dělat žádné změny připojovacího řetězce, protože připojení se provádí pomocí aliasu.You don't need to make any connection string changes, as the connection is made via an alias.

V tomto článku se používají následující výrazy:The following terms are used in this article:

  • Alias: název pro konfiguraci zotavení po havárii, kterou jste nastavili.Alias: The name for a disaster recovery configuration that you set up. Alias poskytuje jediný stabilní řetězec plně kvalifikovaného názvu domény (FQDN).The alias provides a single stable Fully Qualified Domain Name (FQDN) connection string. Aplikace používají tento připojovací řetězec aliasu pro připojení k oboru názvů.Applications use this alias connection string to connect to a namespace.

  • Primární nebo sekundární obor názvů: obory názvů, které odpovídají aliasu.Primary/secondary namespace: The namespaces that correspond to the alias. 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ů).The primary namespace is "active" and receives messages (can be an existing or new namespace). Sekundární obor názvů je "pasivní" a nepřijímá zprávy.The secondary namespace is "passive" and doesn't receive messages. Metadata mezi oběma je synchronizována, takže obě můžou bezproblémově přijímat zprávy bez nutnosti změny kódu aplikace nebo připojovacího řetězce.The metadata between both is in sync, so both can seamlessly accept messages without any application code or connection string changes. Chcete-li zajistit, že pouze aktivní obor názvů přijímá zprávy, je nutné použít alias.To ensure that only the active namespace receives messages, you must use the 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ů.Metadata: Entities such as event hubs and consumer groups; and their properties of the service that are associated with the namespace. Automaticky se replikují jenom entity a jejich nastavení.Only entities and their settings are replicated automatically. Zprávy a události nejsou replikovány.Messages and events aren't replicated.

  • Převzetí služeb při selhání: proces aktivace sekundárního oboru názvů.Failover: The process of activating the secondary namespace.

Podporované páry oboru názvůSupported namespace pairs

Podporovány jsou následující kombinace primárních a sekundárních oborů názvů:The following combinations of primary and secondary namespaces are supported:

Primární obor názvůPrimary namespace Sekundární obor názvůSecondary namespace PodporovánoSupported
StandardníStandard StandardníStandard AnoYes
StandardníStandard VyhrazenáDedicated AnoYes
VyhrazenáDedicated VyhrazenáDedicated AnoYes
VyhrazenáDedicated StandardníStandard NoNo

Poznámka

Obory názvů, které jsou ve stejném vyhrazeném clusteru, nelze spárovat.You can't pair namespaces that are in the same dedicated cluster. Obory názvů, které jsou v samostatných clusterech, můžete spárovat.You can pair namespaces that are in separate clusters.

Nastavení a postup převzetí služeb při selháníSetup and failover flow

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í.The following section is an overview of the failover process, and explains how to set up the initial failover.

1

NastaveníSetup

Nejprve vytvoříte nebo použijete existující primární obor názvů a nový sekundární obor názvů a potom oba dvojici.You first create or use an existing primary namespace, and a new secondary namespace, then pair the two. Toto párování vám poskytne alias, který můžete použít k připojení.This pairing gives you an alias that you can use to connect. Protože používáte alias, nemusíte měnit připojovací řetězce.Because you use an alias, you don't have to change connection strings. Do párování převzetí služeb při selhání se dají přidat jenom nové obory názvů.Only new namespaces can be added to your failover pairing.

  1. Vytvořte primární obor názvů.Create the primary namespace.

  2. Vytvořte sekundární obor názvů.Create the secondary namespace. Tento krok je volitelný.This step is optional. Sekundární obor názvů můžete vytvořit při vytváření párování v dalším kroku.You can create the secondary namespace while creating the pairing in the next step.

  3. V Azure Portal přejděte k primárnímu oboru názvů.In the Azure portal, navigate to your primary namespace.

  4. V nabídce vlevo vyberte geografické obnovení a na panelu nástrojů vyberte Zahájit párování .Select Geo-recovery on the left menu, and select Initiate pairing on the toolbar.

    Iniciace párování z primárního oboru názvů

  5. Na stránce Zahájit párování vyberte existující sekundární obor názvů nebo ho vytvořte a pak vyberte vytvořit.On the Initiate pairing page, select an existing secondary namespace or create one, and then select Create. V následujícím příkladu je vybrán existující sekundární obor názvů.In the following example, an existing secondary namespace is selected.

    Vybrat sekundární obor názvů

  6. Když teď pro primární obor názvů vyberete geografické obnovení , zobrazí se stránka s aliasem geografického Dr , která vypadá jako na následujícím obrázku:Now, when you select Geo-recovery for the primary namespace, you should see the Geo-DR Alias page that looks like the following image:

    Stránka alias geografického DR

  7. Na této stránce přehledu můžete provádět následující akce:On this Overview page, you can do the following actions:

    1. Přerušit párování mezi primárními a sekundárními obory názvů.Break the pairing between primary and secondary namespaces. Na panelu nástrojů vyberte přerušení párování .Select Break pairing on the toolbar.

    2. Ruční převzetí služeb při selhání sekundárnímu oboru názvů.Manually failover to the secondary namespace. Na panelu nástrojů vyberte převzetí služeb při selhání .Select Failover on the toolbar.

      Upozornění

      Při selhání dojde k aktivaci sekundárního oboru názvů a odebrání primárního oboru názvů z párování obnovení Geo-Disaster.Failing over will activate the secondary namespace and remove the primary namespace from the Geo-Disaster Recovery pairing. Vytvořte jiný obor názvů, abyste měli novou dvojici geografického zotavení po havárii.Create another namespace to have a new geo-disaster recovery pair.

  8. Na stránce alias geografického dru vyberte zásady sdíleného přístupu pro přístup k primárnímu připojovacímu řetězci pro daný alias.On the Geo-DR Alias page, select Shared access policies to access the primary connection string for the alias. Místo přímého použití připojovacího řetězce k primárnímu nebo sekundárnímu oboru názvů použijte tento připojovací řetězec.Use this connection string instead of using the connection string to the primary/secondary namespace directly.

Nakonec byste měli přidat nějaké monitorování, abyste zjistili, jestli je převzetí služeb při selhání nezbytné.Finally, you should add some monitoring to detect if a failover is necessary. Ve většině případů je služba jednou ze velkých ekosystémů, takže automatické převzetí služeb při selhání je možné provést jenom v rámci synchronizace se zbývajícím subsystémem nebo infrastrukturou.In most cases, the service is one part of a large ecosystem, thus automatic failovers are rarely possible, as often failovers must be performed in sync with the remaining subsystem or infrastructure.

PříkladExample

V jednom z těchto scénářů zvažte řešení prodejního bodu (POS), které vysílá buď zprávy, nebo události.In one example of this scenario, consider a Point of Sale (POS) solution that emits either messages or events. Event Hubs tyto události předá do některého řešení mapování nebo přeformátování, které pak předává namapovaná data do jiného systému pro další zpracování.Event Hubs passes those events to some mapping or reformatting solution, which then forwards mapped data to another system for further processing. V tomto okamžiku můžou být všechny tyto systémy hostované ve stejné oblasti Azure.At that point, all of these systems might be hosted in the same Azure region. Rozhodnutí o tom, kdy a jakou část převezme služby při selhání, závisí na toku dat ve vaší infrastruktuře.The decision of when and what part to fail over depends on the flow of data in your infrastructure.

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í.You can automate failover either with monitoring systems, or with custom-built monitoring solutions. Tato automatizace ale má dodatečné plánování a práci, což není v rozsahu tohoto článku.However, such automation takes extra planning and work, which is out of the scope of this article.

Postup převzetí služeb při selháníFailover flow

Pokud zahájíte převzetí služeb při selhání, vyžadují se dva kroky:If you initiate the failover, two steps are required:

  1. Pokud dojde k dalšímu výpadku, budete chtít být schopni převzít služby po obnovení.If another outage occurs, you want to be able to fail over again. Proto nastavte další pasivní obor názvů a aktualizujte párování.Therefore, set up another passive namespace and update the pairing.

  2. Vyžádat zprávy z bývalého primárního oboru názvů, jakmile budou opět k dispozici.Pull messages from the former primary namespace once it's available again. 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ů.After that, use that namespace for regular messaging outside of your geo-recovery setup, or delete the old primary namespace.

Poznámka

Jsou podporovány pouze sémantiky při předání služeb při selhání.Only fail forward semantics are supported. V tomto scénáři převezmete služby při selhání a pak znovu spárujte s novým oborem názvů.In this scenario, you fail over and then re-pair with a new namespace. Navrácení služeb po obnovení není podporováno. například v clusteru SQL.Failing back is not supported; for example, in a SQL cluster.

2

SprávaManagement

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ů.If you made a mistake; for example, you paired the wrong regions during the initial setup, you can break the pairing of the two namespaces at any time. Pokud chcete používat spárované obory názvů jako běžné obory názvů, odstraňte alias.If you want to use the paired namespaces as regular namespaces, delete the alias.

ukázkySamples

Ukázka na GitHubu ukazuje, jak nastavit a iniciovat převzetí služeb při selhání.The sample on GitHub shows how to set up and initiate a failover. Tato ukázka demonstruje následující koncepty:This sample demonstrates the following concepts:

  • Nastavení požadovaná v Azure Active Directory pro použití Azure Resource Manager s Event Hubs.Settings required in Azure Active Directory to use Azure Resource Manager with Event Hubs.
  • Postup potřebný ke spuštění ukázkového kódu.Steps required to execute the sample code.
  • Odeslat a přijmout z aktuálního primárního oboru názvůSend and receive from the current primary namespace.

PožadavkyConsiderations

Vezměte na vědomí následující skutečnosti:Note the following considerations to keep in mind:

  1. 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í.By design, Event Hubs geo-disaster recovery does not replicate data, and therefore you cannot reuse the old offset value of your primary event hub on your secondary event hub. K restartování přijímače událostí doporučujeme použít jednu z následujících metod:We recommend restarting your event receiver with one of the following methods:
  • EventPosition. FromStart () – Pokud chcete číst všechna data v sekundárním centru událostí.EventPosition.FromStart() - If you wish read all data on your secondary event hub.
  • EventPosition. FromEnd () – Pokud chcete číst všechna nová data z doby připojení k sekundárnímu centru událostí.EventPosition.FromEnd() - If you wish to read all new data from the time of connection to your secondary event hub.
  • 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.EventPosition.FromEnqueuedTime(dateTime) - If you wish to read all data received in your secondary event hub starting from a given date and time.
  1. Při plánování převzetí služeb při selhání byste měli také zvážit časový faktor.In your failover planning, you should also consider the time factor. 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í.For example, if you lose connectivity for longer than 15 to 20 minutes, you might decide to initiate the failover.

  2. Skutečnost, že nejsou replikována žádná data znamená, že aktuální aktivní relace nebudou replikovány.The fact that no data is replicated means that current active sessions aren't replicated. Kromě toho nemusí fungovat duplicita duplicit a naplánované zprávy.Additionally, duplicate detection and scheduled messages may not work. Budou fungovat nové relace, naplánované zprávy a nové duplicity.New sessions, scheduled messages, and new duplicates will work.

  3. Převzetí služeb při selhání přes složitou distribuovanou infrastrukturu by mělo být alespoň jednou vyzkoušeno .Failing over a complex distributed infrastructure should be rehearsed at least once.

  4. Synchronizace entit může nějakou dobu trvat přibližně 50-100 entit za minutu.Synchronizing entities can take some time, approximately 50-100 entities per minute.

Zóny dostupnostiAvailability Zones

SKU Event Hubs standard podporuje zóny dostupnostia poskytuje umístění s izolací chyb v oblasti Azure.The Event Hubs Standard SKU supports Availability Zones, providing fault-isolated locations within an Azure region.

Poznámka

Podpora Zóny dostupnosti pro Azure Event Hubs Standard je dostupná jenom v oblastech Azure , kde se nacházejí zóny dostupnosti.The Availability Zones support for Azure Event Hubs Standard is only available in Azure regions where availability zones are present.

Zóny dostupnosti můžete povolit jenom pro nové obory názvů pomocí Azure Portal.You can enable Availability Zones on new namespaces only, using the Azure portal. Event Hubs nepodporuje migraci stávajících oborů názvů.Event Hubs doesn't support migration of existing namespaces. Po povolení v oboru názvů nemůžete zakázat redundanci zóny.You can't disable zone redundancy after enabling it on your namespace.

3

Privátní koncové bodyPrivate endpoints

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.This section provides more considerations when using Geo-disaster recovery with namespaces that use private endpoints. 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ů.To learn about using private endpoints with Event Hubs in general, see Configure private endpoints.

Nové párováníNew pairings

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.If you try to create a pairing between a primary namespace with a private endpoint and a secondary namespace without a private endpoint, the pairing will fail. 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.The pairing will succeed only if both primary and secondary namespaces have private endpoints. 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.We recommend that you use same configurations on the primary and secondary namespaces and on virtual networks in which private endpoints are created.

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ů.When you try to pair the primary namespace with private endpoint and a secondary namespace, the validation process only checks whether a private endpoint exists on the secondary namespace. Nekontroluje, jestli koncový bod funguje nebo bude po převzetí služeb při selhání fungovat.It doesn't check whether the endpoint works or will work after failover. 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í.It's your responsibility to ensure that the secondary namespace with private endpoint will work as expected after failover.

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.To test that the private endpoint configurations are same on primary and secondary namespaces, send a read request (for example: Get Event Hub) to the secondary namespace from outside the virtual network, and verify that you receive an error message from the service.

Existující párováníExisting pairings

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ří.If pairing between primary and secondary namespace already exists, private endpoint creation on the primary namespace will fail. 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ů.To resolve, create a private endpoint on the secondary namespace first and then create one for the primary namespace.

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.While we allow read-only access to the secondary namespace, updates to the private endpoint configurations are permitted.

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.When creating a disaster recovery configuration for your application and Event Hubs namespaces, you must create private endpoints for both primary and secondary Event Hubs namespaces against virtual networks hosting both primary and secondary instances of your application.

Ř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.Let's say you have two virtual networks: VNET-1, VNET-2 and these primary and secondary namespaces: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Je třeba provést následující kroky:You need to do the following steps:

  • V EventHubs-Namespace1-Primary vytvořte dva privátní koncové body, které používají podsítě z VNET-1 a VNET-2.On EventHubs-Namespace1-Primary, create two private endpoints that use subnets from VNET-1 and 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.On EventHubs-Namespace2-Secondary, create two private endpoints that use the same subnets from VNET-1 and VNET-2

Privátní koncové body a virtuální sítě

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ů.Advantage of this approach is that failover can happen at the application layer independent of Event Hubs namespace. Zvažte následující scénáře:Consider the following scenarios:

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.Application-only failover: Here, the application won't exist in VNET-1 but will move to 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.As both private endpoints are configured on both VNET-1 and VNET-2 for both primary and secondary namespaces, the application will just work.

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.Event Hubs namespace-only failover: Here again, since both private endpoints are configured on both virtual networks for both primary and secondary namespaces, the application will just work.

Poznámka

Pokyny pro obnovení geografických havárií virtuální sítě najdete v tématu Virtual Network – provozní kontinuita.For guidance on geo-disaster recovery of a virtual network, see Virtual Network - Business Continuity.

Další krokyNext steps

  • Ukázka na GitHubu vás provede jednoduchým pracovním postupem, který vytvoří geografickou spárování a zahájí převzetí služeb při selhání ve scénáři zotavení po havárii.The sample on GitHub walks through a simple workflow that creates a geo-pairing and initiates a failover for a disaster recovery scenario.
  • Odkazy na REST API popisují rozhraní API pro konfiguraci obnovení geografického zotavení po havárii.The REST API reference describes APIs for performing the Geo-disaster recovery configuration.

Další informace o službě Event Hubs naleznete pod těmito odkazy:For more information about Event Hubs, visit the following links: