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

Po celé oblasti Azure nebo datových centrech (Pokud ne zóny dostupnosti se používají) dojít k výpadku, je velmi důležité pro zpracování dat i nadále fungovat v jiné oblasti nebo datového centra.When entire Azure regions or datacenters (if no availability zones are used) experience downtime, it is critical for data processing to continue to operate in a different region or datacenter. V důsledku toho zotavení po havárii geograficky a geografickou replikaci jsou důležité funkce pro všechny podniky.As such, Geo-disaster recovery and Geo-replication are important features for any enterprise. Azure Event Hubs podporuje geo-zotavení po havárii a geografická replikace, na úrovni oboru názvů.Azure Event Hubs supports both geo-disaster recovery and geo-replication, at the namespace level. 

Funkce zotavení po havárii geograficky je globálně dostupná pro Event Hubs úrovně Standard a Dedicated SKU.The Geo-disaster recovery feature is globally available for both Event Hubs Standard and Dedicated SKU. Mějte prosím na paměti, můžete pouze obory názvů geo pár napříč na stejné úrovni SKU.Please note that you can only geo-pair namespaces across the same tier of SKU. Například pokud máte obor názvů v clusteru, který je k dispozici jenom v SKU naše vyhrazené ji pouze se dají párovat s oborem názvů v jiném clusteru.For instance, if you have a namespace in a cluster which is offered only in our Dedicated SKU, it can only be paired with a namespace in another cluster.

Výpadků a haváriíOutages and disasters

Je důležité si uvědomit rozdíl mezi "výpadků" a "havárií."It's important to note the distinction between "outages" and "disasters." Výpadek je dočasná nedostupnost služby Azure Event Hubs a může mít vliv na některé součásti služby, jako je například úložiště, nebo dokonce celé datové centrum.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. Ale po byl problém vyřešen, Event Hubs opět k dispozici.However, after the problem is fixed, Event Hubs becomes available again. Kvůli výpadku obvykle nezpůsobí ztrátu zprávy nebo jiná data.Typically, an outage does not cause the loss of messages or other data. Příkladem takových výpadek 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 jsou pouze krátkou připojení ztráty kvůli problémům s přechodným nebo sítě.Some outages are only short connection losses due to transient or network issues.

A po havárii je definován jako trvalý, nebo dlouhodobější ztráty clusteru služby Event Hubs, Azure oblasti nebo datového centra.A disaster is defined as the permanent, or longer-term loss of an Event Hubs cluster, Azure region, or datacenter. Oblasti nebo datového centra může nebo nemusí opět k dispozici nebo je pravděpodobně mimo provoz pro hodiny nebo i dny.The region or datacenter may or may not become available again, or may be down for hours or days. Příkladem takové jiného problému ovlivňujícího jsou fire, zahlcení nebo zemětřesení.Examples of such disasters are fire, flooding, or earthquake. Po havárii, který se stane trvalé může způsobit ztrátu některé zprávy, události nebo jiná data.A disaster that becomes permanent might cause the loss of some messages, events, or other data. Ale ve většině případů by měl být nulové ztráty a zprávy lze obnovit zálohování po datové centrum.However, in most cases there should be no data loss and messages can be recovered once the data center is back up.

Funkce zotavení po havárii geograficky služby Azure Event Hubs je řešení pro zotavení po havárii.The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. Koncepty a pracovní postup popsaný v tomto článku použít scénáře po havárii a není přechodná nebo dočasné výpadky.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 části v tomto článku.For a detailed discussion of disaster recovery in Microsoft Azure, see this article.

Základními koncepcemi a termínyBasic concepts and terms

Funkce zotavení po havárii implementuje zotavení po havárii metadata a spoléhá na obory názvů zotavení po havárii primární a sekundární.The disaster recovery feature implements metadata disaster recovery, and relies on primary and secondary disaster recovery namespaces. Všimněte si, že je k dispozici pro funkce zotavení po havárii geograficky standardní SKU pouze.Note that the Geo-disaster recovery feature is available for the Standard SKU only. Není potřeba nic měnit připojovací řetězec, protože připojení se provádí prostřednictvím alias.You do not 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í termíny:The following terms are used in this article:

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

  • Obor názvů primárního a sekundárního: Obory názvů, které odpovídají na alias.Primary/secondary namespace: The namespaces that correspond to the alias. Primární obor názvů je "aktivní" a přijímá zprávy (to může být existující nebo nový obor názvů).The primary namespace is "active" and receives messages (this 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 does not receive messages. Metadata mezi oběma jsou synchronizované, tak i hladce přijmout zprávy bez nutnosti jakkoli měnit aplikace kódu nebo připojovací řetězec.The metadata between both is in sync, so both can seamlessly accept messages without any application code or connection string changes. Aby bylo zajištěno, že pouze aktivní obor názvů přijímá zprávy, musíte použít alias.To ensure that only the active namespace receives messages, you must use the alias.

  • Metadata: Entity, jako jsou event hubs a skupiny uživatelů. a jejich vlastnosti služby, které jsou spojeny s oborem názvů.Metadata: Entities such as event hubs and consumer groups; and their properties of the service that are associated with the namespace. Všimněte si, že se automaticky replikují jenom entity a jejich nastavení.Note that only entities and their settings are replicated automatically. Zprávy a události se nereplikují.Messages and events are not replicated.

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

Instalační program a převzetí služeb při selhání tokuSetup and failover flow

Následující části je uveden 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

Můžete nejprve vytvořit, nebo použijte existující primární obor názvů a nový sekundární obor názvů, a spárujte dvě.You first create or use an existing primary namespace, and a new secondary namespace, then pair the two. Toto párování získáte alias, který používáte pro připojení.This pairing gives you an alias that you can use to connect. Vzhledem k tomu, že používáte alias, není nutné změnit připojovací řetězce.Because you use an alias, you do not have to change connection strings. Nové obory názvů lze přidat na váš párování převzetí služeb při selhání.Only new namespaces can be added to your failover pairing. A konečně měli byste přidat, některá monitorování ke zjištění, pokud je nutné převzetí služeb při selhání.Finally, you should add some monitoring to detect if a failover is necessary. Ve většině případů je jednou ze součástí sady rozsáhlého ekosystému služby, proto jsou automatické převzetí služeb při selhání jen zřídka je to možné, jak často převzetí služeb při selhání se musí provádět synchronizované s zbývající subsystému nebo infrastruktury.In most cases, the service is one part of a large ecosystem, thus automatic failovers are rarely possible, as very often failovers must be performed in sync with the remaining subsystem or infrastructure.

Příklad:Example

V příkladem tohoto scénáře vezměte v úvahu bodu prodej (POS) řešení, které generuje 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 se předá tyto události některé mapování nebo přeformátování řešení, které potom předává mapovaná 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 tu chvíli se všech těchto systémech může být hostovaná ve stejné oblasti Azure.At that point, all of these systems might be hosted in the same Azure region. Rozhodnutí o a jaká část převzít služby při selhání závisí na toku dat ve vaší infrastruktuře.The decision on when and what part to fail over depends on the flow of data in your infrastructure.

Můžete automatizovat převzetí služeb při selhání se systémy pro monitorování nebo s vlastními silami sestavených řešení monitorování.You can automate failover either with monitoring systems, or with custom-built monitoring solutions. Tato automatizace však trvá dodatečné plánování a činnosti, což je mimo rámec tohoto článku.However, such automation takes extra planning and work, which is out of the scope of this article.

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

Pokud spustíte převzetí služeb při selhání, jsou požadovány dva kroky:If you initiate the failover, two steps are required:

  1. Pokud dojde k jinému výpadku, chcete být schopni převzetí služeb při selhání znovu.If another outage occurs, you want to be able to failover again. Proto nastavit jiný obor názvů pasivní a aktualizujte párování.Therefore, set up another passive namespace and update the pairing.

  2. Jakmile je opět k dispozici vytahují zprávy z předchozí primární obor názvů.Pull messages from the former primary namespace once it is available again. Potom použijte tento obor názvů pro zasílání zpráv regulární mimo nastavení geografického zotavení 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

Pouze dopředné sémantiku selhání jsou podporovány.Only fail forward semantics are supported. V tomto scénáři převzetí služeb při selhání a potom znovu spárovat nový obor názvů.In this scenario, you fail over and then re-pair with a new namespace. Navrácení služeb po obnovení není podporována. například v clusteru serveru SQL.Failing back is not supported; for example, in a SQL cluster.

2

SprávaManagement

Pokud se jedná o chybu; například spárované nesprávné oblasti při počátečním nastavení, můžete přerušit párování dané dva obory názvů v každém okamžiku.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žít jako regulární obory názvů spárované 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 spustit 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í pojmy:This sample demonstrates the following concepts:

  • Nastavení v Azure Active Directory pro použití Azure Resource Manageru pomocí služby Event Hubs.Settings required in Azure Active Directory to use Azure Resource Manager with Event Hubs.
  • Kroky potřebné ke spuštění vzorového kódu.Steps required to execute the sample code.
  • Odesílání a příjem z aktuální primární obor názvů.Send and receive from the current primary namespace.

PožadavkyConsiderations

Mějte na paměti následující aspekty brát v úvahu v této vydané verzi:Note the following considerations to keep in mind with this release:

  1. Při plánování převzetí služeb při selhání, měli byste také zvážit faktor čas.In your failover planning, you should also consider the time factor. Například pokud ztratíte připojení po dobu delší než 15 až 20 minut, můžete se rozhodnout k zahájení 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. Fakt, že žádná data se replikují znamená, že momentálně se nereplikují aktivní relace.The fact that no data is replicated means that currently active sessions are not replicated. Plánované zprávy a duplicit navíc nemusí fungovat.Additionally, duplicate detection and scheduled messages may not work. Nové relace, plánované zprávy a nové duplikáty budou fungovat.New sessions, scheduled messages, and new duplicates will work.

  3. Přebírání služeb při selhání komplexní distribuované infrastruktury by měla být vyzkoušená alespoň jednou.Failing over a complex distributed infrastructure should be rehearsed at least once.

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

Zóny dostupnostiAvailability Zones

Event Hubs standardní skladová jednotka podporuje zóny dostupnosti, poskytuje umístění s izolací chyb v rámci oblasti Azure.The Event Hubs Standard SKU supports Availability Zones, providing fault-isolated locations within an Azure region.

Poznámka

Podpora zóny dostupnosti Azure Event Hubs úrovně Standard je k dispozici pouze oblastí Azure kde zóny dostupnosti jsou k dispozici.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 na pouze nové obory názvů pomocí webu Azure portal.You can enable Availability Zones on new namespaces only, using the Azure portal. Event Hubs nepodporuje migraci z existující oborů názvů.Event Hubs does not support migration of existing namespaces. Po povolení na váš obor názvů nejde zakázat redundanci zón.You cannot disable zone redundancy after enabling it on your namespace.

3

Další postupNext steps

  • Ukázka na Githubu provede jednoduchý pracovní postup, který vytvoří geograficky párování a iniciuje převzetí služeb při selhání pro scénář 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.
  • Reference k rozhraní REST API popisuje rozhraní API pro provádění konfigurace zotavení po havárii Geo.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: