Azure Service Bus Geo-zotavení po haváriiAzure Service Bus 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 důležitou součást pro všechny podniky.As such, Geo-disaster recovery is an important feature for any enterprise. Azure Service Bus podporuje geo-zotavení po havárii na úrovni oboru názvů.Azure Service Bus supports geo-disaster recovery at the namespace level.

Funkce zotavení po havárii geograficky je globálně dostupná pro skladovou Položku služby Service Bus úrovně Premium.The Geo-disaster recovery feature is globally available for the Service Bus Premium SKU.

Poznámka

Geografické zotavení aktuálně pouze zajistí, že metadata (fronty, témata, odběry, filtry) se překopírují z primárního oboru názvů sekundární obor názvů v kombinaci.Geo-Disaster recovery currently only ensures that the metadata (Queues, Topics, Subscriptions, Filters) are copied over from the primary namespace to secondary namespace when paired.

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 Service Bus 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 Service Bus, 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, Service Bus opět k dispozici.However, after the problem is fixed, Service Bus 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átu clusteru služby Service Bus, oblasti Azure nebo datacenter.A disaster is defined as the permanent, or longer-term loss of a Service Bus 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 Azure Service Bus je řešení pro zotavení po havárii.The Geo-disaster recovery feature of Azure Service Bus 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 SKU úrovně Premium pouze.Note that the Geo-disaster recovery feature is available for the Premium 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. Používání aliasu zajišťuje, že připojovací řetězec beze změn při aktivaci převzetí služeb při selhání.Using an alias ensures that the connection string is unchanged when the failover is triggered.

  • 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 fronty, témata a odběry; a jejich vlastnosti služby, které jsou spojeny s oborem názvů.Metadata: Entities such as queues, topics, and subscriptions; 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 se nereplikují.Messages 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.

InstalaceSetup

Následující části je uveden přehled nastavení párování mezi obory názvů.The following section is an overview to setup pairing between the namespaces.

1

Proces instalace je takto:The setup process is as follows -

  1. Zřízení primární služby Service Bus Premium Namespace.Provision a Primary Service Bus Premium Namespace.

  2. Zřízení sekundární služby Service Bus Premium Namespace v oblasti liší od kde primární obor názvů zřizován.Provision a Secondary Service Bus Premium Namespace in a region different from where the primary namespace is provisioned. To vám pomůže povolit izolaci chyb napříč oblastmi jiném datovém centru.This will help allow fault isolation across different datacenter regions.

  3. Vytvoření párování mezi primární obor názvů a sekundární obor názvů získat alias.Create pairing between the Primary namespace and Secondary namespace to obtain the alias.

    Poznámka

    Pokud máte migraci vašeho oboru názvů Azure Service Bus úrovně Standard pro Azure Service Bus Premium, pak je třeba použít existující alias (například Service Bus úrovně Standard obor názvů připojovací řetězec) nevytvořil zotavení po havárii konfigurace prostřednictvím PS/CLI nebo rozhraní REST API.If you have migrated your Azure Service Bus Standard namespace to Azure Service Bus Premium, then you must use the pre-existing alias (i.e. your Service Bus Standard namespace connection string) to create the disaster recovery configuration through the PS/CLI or REST API.

    Důvodem je, že během migrace, Azure Service Bus úrovně Standard názvu vašeho oboru názvů připojovací řetězec/DNS samotné stane alias do svého oboru názvů Azure Service Bus úrovně Premium.This is because, during migration, your Azure Service Bus Standard namespace connection string/DNS name itself becomes an alias to your Azure Service Bus Premium namespace.

    Tento alias (například Azure Service Bus úrovně Standard obor názvů připojovací řetězec) pro připojení k oboru názvů úrovně Premium, kde párování pro zotavení po havárii po nastavení musí využívat klientské aplikace.Your client applications must utilize this alias (i.e. the Azure Service Bus Standard namespace connection string) to connect to the Premium namespace where the disaster recovery pairing has been setup.

    Pokud používáte portál pro nastavení konfigurace zotavení po havárii, pak na portálu abstraktní tento výstrahou od vás.If you use the Portal to setup the Disaster recovery configuration, then the portal will abstract this caveat from you.

  4. Použití alias získaný v kroku 3 pro připojení klientských aplikací pro Geo-DR povolené primární obor názvů.Use the alias obtained in step 3 to connect your client applications to the Geo-DR enabled primary namespace. Na začátku aliasem, který se odkazuje na primární obor názvů.Initially, the alias points to the primary namespace.

  5. [Volitelné] Přidáte monitorování ke zjištění, pokud je nutné převzetí služeb při selhání.[Optional] Add some monitoring to detect if a failover is necessary.

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

Převzetí služeb při selhání se aktivuje ručně tak, že zákazník (buď explicitně prostřednictvím příkaz nebo vlastní obchodní logiky, která se spustí příkaz klienta) a nikdy Azure.A failover is triggered manually by the customer (either explicitly through a command, or through client owned business logic that triggers the command) and never by Azure. Díky tomu zákazník úplné vlastnictví a viditelnost pro překlad výpadek v páteřní síti Azure.This gives the customer full ownership and visibility for outage resolution on Azure's backbone.

4

Jakmile převzetí služeb při selhání se aktivuje-After the failover is triggered -

  1. Alias připojovací řetězec aktualizuje tak, aby odkazoval na sekundární Premium obor názvů.The alias connection string is updated to point to the Secondary Premium namespace.

  2. Klienti (odesílateli a příjemci) se automaticky připojí na sekundární obor názvů.Clients(senders and receivers) automatically connect to the Secondary namespace.

  3. Existující párování mezi primární a sekundární obor názvů úrovně premium je poškozená.The existing pairing between Primary and Secondary premium namespace is broken.

Jakmile převzetí služeb při selhání je zahájeno-Once the failover is initiated -

  1. Pokud dojde k jinému výpadku, chcete mít možnost převzetí služeb při selhání znovu.If another outage occurs, you want to be able to fail over 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.

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.

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.

Použití existujícího oboru názvů jako aliasUse existing namespace as alias

Pokud máte scénáře, ve kterém nelze změnit připojení producenti a spotřebitelé, můžete znovu použít název vašeho oboru názvů jako název aliasu.If you have a scenario in which you cannot change the connections of producers and consumers, you can reuse your namespace name as the alias name. Zobrazit ukázkový kód na Githubu tady.See the sample code on GitHub here.

Ukázky kóduSamples

Ukázky na Githubu ukazují, jak nastavit a spustit převzetí služeb při selhání.The samples on GitHub show how to set up and initiate a failover. Tyto ukázky ukazují následující pojmy:These samples demonstrate the following concepts:

  • Ukázka .NET a nastavení, které jsou nutné ve službě Azure Active Directory pomocí Azure Resource Manageru pomocí služby Service Bus, nastavení a povolení geografické zotavení.A .NET sample and settings that are required in Azure Active Directory to use Azure Resource Manager with Service Bus, to set up and enable Geo-disaster recovery.
  • Kroky potřebné ke spuštění vzorového kódu.Steps required to execute the sample code.
  • Jak používat existujícího oboru názvů jako alias.How to use an existing namespace as an alias.
  • Kroky, případně aby Geo-zotavení po havárii prostřednictvím Powershellu nebo rozhraní příkazového řádku.Steps to alternatively enable Geo-disaster recovery via PowerShell or CLI.
  • Odesílání a příjem z aktuálního primárního nebo sekundárního oboru názvů pomocí aliasu.Send and receive from the current primary or secondary namespace using the alias.

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, nové plánované zprávy a nové duplikáty budou fungovat.New sessions, new 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. Předplatná a pravidla i počítat jako entity.Subscriptions and rules also count as entities.

Zóny dostupnostiAvailability Zones

SKU služby Service Bus úrovně Premium podporuje také zóny dostupnosti, poskytuje umístění s izolací chyb v rámci oblasti Azure.The Service Bus Premium SKU also supports Availability Zones, providing fault-isolated locations within an Azure region.

Poznámka

Podpora zóny dostupnosti Azure Service Bus úrovně Premium je k dispozici pouze oblastí Azure kde zóny dostupnosti jsou k dispozici.The Availability Zones support for Azure Service Bus Premium 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. Service Bus nepodporuje migraci z existující oborů názvů.Service Bus 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

Další informace o zasílání zpráv Service Bus, najdete v následujících článcích:To learn more about Service Bus messaging, see the following articles: