Azure Event Hubs - geo ディザスター リカバリーAzure Event Hubs - Geo-disaster recovery

Azure リージョン全体または (可用性ゾーンが使用されていない) データ センター全体にダウンタイムが発生した場合に、別の地域またはデータ センターでデータ処理が続行されることが重要です。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. そのため、geo ディザスター リカバリーgeo レプリケーションは、どの企業にとっても重要な機能です。As such, Geo-disaster recovery and Geo-replication are important features for any enterprise. Azure Event Hubs では、geo ディザスター リカバリーと geo レプリケーションの両方が名前空間レベルでサポートされています。Azure Event Hubs supports both geo-disaster recovery and geo-replication, at the namespace level. 

注意

geo ディザスター リカバリー機能は、Standard SKU と専用 SKU にのみ使用できます。The Geo-disaster recovery feature is only available for the standard and dedicated SKUs.

故障と災害Outages and disasters

"故障" と "災害" の違いに注意してください。It's important to note the distinction between "outages" and "disasters." "故障" とは、Azure Event Hubs が一時的に使用不可能になっていることです。メッセージング ストアなどサービスの一部のコンポーネントや、場合によってはデータセンター全体に影響を与えることがあります。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. しかし、問題が解決されると、Event Hubs は再び使用可能になります。However, after the problem is fixed, Event Hubs becomes available again. 通常、故障によってメッセージなどのデータが失われることはありません。Typically, an outage does not cause the loss of messages or other data. 故障の例として、データセンターでの電源障害があります。An example of such an outage might be a power failure in the datacenter. 一時的な問題やネットワークの問題から短時間、接続が失われるだけの故障もあります。Some outages are only short connection losses due to transient or network issues.

"災害" は、Event Hubs クラスター、Azure リージョン、またはデータ センターの永久または長期間損失として定義されています。A disaster is defined as the permanent, or longer-term loss of an Event Hubs cluster, Azure region, or datacenter. リージョンまたはデータセンターは、再び利用可能になる場合も、ならない場合もあります。また、数時間や数日間の停止になる場合もあります。The region or datacenter may or may not become available again, or may be down for hours or days. このような災害の例としては、火災、洪水、地震があります。Examples of such disasters are fire, flooding, or earthquake. 永続的な災害により、メッセージやイベントなどのデータが失われる可能性があります。A disaster that becomes permanent might cause the loss of some messages, events, or other data. ただし、ほとんどの場合、データ センターがバックアップされていればデータが失われることはなく、メッセージを復元できます。However, in most cases there should be no data loss and messages can be recovered once the data center is back up.

Azure Event Hubs の geo ディザスター リカバリー機能はディザスター リカバリー ソリューションです。The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. この記事で説明する概念とワークフローは、一時的な故障ではなく、災害のシナリオに適用されます。The concepts and workflow described in this article apply to disaster scenarios, and not to transient, or temporary outages. Microsoft Azure でのディザスター リカバリーの詳細については、こちらの記事をご覧ください。For a detailed discussion of disaster recovery in Microsoft Azure, see this article.

基本的な概念と用語Basic concepts and terms

ディザスター リカバリー機能は、メタデータの災害復旧を実装しており、一次および二次障害復旧の名前空間に依存しています。The disaster recovery feature implements metadata disaster recovery, and relies on primary and secondary disaster recovery namespaces.

geo ディザスター リカバリー機能は、Standard SKU と専用 SKU にのみ使用できます。The Geo-disaster recovery feature is available for the standard and dedicated SKUs only. 別名を使用して接続を確立するので、接続文字列に変更を加える必要はありません。You do not need to make any connection string changes, as the connection is made via an alias.

この記事では、次の用語を使用します。The following terms are used in this article:

  • エイリアス: 設定したディザスター リカバリー構成の名前です。Alias: The name for a disaster recovery configuration that you set up. エイリアスは、1 つの不変の完全修飾ドメイン名 (FQDN) の接続文字列を示します。The alias provides a single stable Fully Qualified Domain Name (FQDN) connection string. アプリケーションでは、このエイリアスの接続文字列を使用して名前空間に接続します。Applications use this alias connection string to connect to a namespace.

  • プライマリ/セカンダリ名前空間: エイリアスに対応する名前空間です。Primary/secondary namespace: The namespaces that correspond to the alias. プライマリ名前空間が "アクティブ" となり、メッセージを受け取ります (既存の名前空間の場合もあれば、新しい名前空間の場合もあります)。The primary namespace is "active" and receives messages (this can be an existing or new namespace). セカンダリ名前空間は "パッシブ" で、メッセージを受け取りません。The secondary namespace is "passive" and does not receive messages. 両者間のメタデータは同期しているため、どちらでもアプリケーション コードや接続文字列を変更せずにメッセージをシームレスに受信できます。The metadata between both is in sync, so both can seamlessly accept messages without any application code or connection string changes. 確実にアクティブな名前空間にだけメッセージを送信するためには、エイリアスを使用する必要があります。To ensure that only the active namespace receives messages, you must use the alias.

  • メタデータ: 名前空間に関連付けられているサービスのエンティティ (イベント ハブ、コンシューマー グループなど) とそのプロパティです。Metadata: Entities such as event hubs and consumer groups; and their properties of the service that are associated with the namespace. 自動的にレプリケートされるのはエンティティとその設定だけであることに注意してください。Note that only entities and their settings are replicated automatically. メッセージやイベントはレプリケートされません。Messages and events are not replicated.

  • フェールオーバー: セカンダリの名前空間をアクティブ化するプロセスです。Failover: The process of activating the secondary namespace.

サポートされている名前空間のペアSupported namespace pairs

プライマリ名前空間とセカンダリ名前空間の次の組み合わせがサポートされています。The following combinations of primary and secondary namespaces are supported:

プライマリ名前空間Primary namespace セカンダリ名前空間Secondary namespace サポート対象Suppported
StandardStandard StandardStandard はいYes
StandardStandard 専用Dedicated はいYes
専用Dedicated 専用Dedicated はいYes
専用Dedicated StandardStandard いいえNo

注意

同じ専用クラスター内にある名前空間を組み合わせることはできません。You can't pair namespaces that are in the same dedicated cluster. 別々のクラスター内にある名前空間を組み合わせることができます。You can pair namespaces that are in separate clusters.

セットアップとフェールオーバーの流れSetup and failover flow

次のセクションでは、フェールオーバー プロセスの概要を示したうえで、最初のフェールオーバーを設定する方法について説明します。The following section is an overview of the failover process, and explains how to set up the initial failover.

1

セットアップSetup

まず (新規作成または既存の) プライマリ名前空間と新しいセカンダリ名前空間をペアリングします。You first create or use an existing primary namespace, and a new secondary namespace, then pair the two. このペアリングによって、接続に使用できる別名が決定されます。This pairing gives you an alias that you can use to connect. 別名を使用するので、接続文字列を変更する必要はありません。Because you use an alias, you do not have to change connection strings. フェールオーバーのペアリングに追加できるのは、新しい名前空間だけです。Only new namespaces can be added to your failover pairing. 最後に、フェールオーバーが必要であるかどうかを検出する監視機構を追加する必要があります。Finally, you should add some monitoring to detect if a failover is necessary. ほとんどの場合、このサービスは大きなエコシステムの一部分であるため、自動フェールオーバーが実行できることはまれです。フェールオーバーは、他のサブシステムやインフラストラクチャと同調して実行しなければならないケースが多いためです。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.

Example

このシナリオの一例として、メッセージまたはイベントを出力する販売時点管理 (POS) ソリューションを考えてみましょう。In one example of this scenario, consider a Point of Sale (POS) solution that emits either messages or events. Event Hubs は、何らかのマッピング (または再フォーマット) ソリューションにそれらのイベントを渡します。マッピングされたデータは、後続の処理のために、そこから別のシステムに転送されます。Event Hubs passes those events to some mapping or reformatting solution, which then forwards mapped data to another system for further processing. このとき、これらすべてのシステムが、同じ Azure リージョン内でホストされている可能性があります。At that point, all of these systems might be hosted in the same Azure region. いつ、どの部分をフェールオーバーするかの判断は、実際のインフラストラクチャにおけるデータのフローによって異なります。The decision on when and what part to fail over depends on the flow of data in your infrastructure.

フェールオーバーは、監視システムを使用して自動化できるほか、独自に構築した監視ソリューションを使用して自動化することもできます。You can automate failover either with monitoring systems, or with custom-built monitoring solutions. ただしそのような自動化は、特別な計画と作業が伴い、この記事で取り上げる範囲を超えています。However, such automation takes extra planning and work, which is out of the scope of this article.

フェールオーバーの流れFailover flow

フェールオーバーを開始する場合、次の 2 つのステップが必要となります。If you initiate the failover, two steps are required:

  1. 別の故障が発生した場合は、もう一度フェールオーバーしたいと考えます。If another outage occurs, you want to be able to failover again. そのために、別のパッシブな名前空間を設定して、ペアリングを更新します。Therefore, set up another passive namespace and update the pairing.

  2. 以前のプライマリ名前空間が再び利用可能になったら、以前のプライマリ名前空間からメッセージをプルします。Pull messages from the former primary namespace once it is available again. 以後、通常のメッセージングにその名前空間を geo リカバリーのセットアップ外で使用するか、または、以前のプライマリ名前空間を削除します。After that, use that namespace for regular messaging outside of your geo-recovery setup, or delete the old primary namespace.

注意

サポートされるのは、フェール フォワードのセマンティクスだけです。Only fail forward semantics are supported. このシナリオでは、フェールオーバー後、新しい名前空間との間で再度ペアリングを行います。In this scenario, you fail over and then re-pair with a new namespace. フェールバックはサポートされません (SQL クラスターでのフェールバックなど)。Failing back is not supported; for example, in a SQL cluster.

2

管理Management

間違ったリージョンをペアリングしたなど、初期設定にミスがあった場合、2 つの名前空間のペアリングはいつでも解除することができます。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. ペアリングした名前空間を通常の名前空間として使用する必要がある場合、エイリアスは削除してください。If you want to use the paired namespaces as regular namespaces, delete the alias.

サンプルSamples

GitHub のサンプルには、フェールオーバーの設定と開始の方法が紹介されています。The sample on GitHub shows how to set up and initiate a failover. このサンプルで紹介されている概念は次のとおりです。This sample demonstrates the following concepts:

  • Azure Resource Manager を Event Hubs で使用するために Azure Active Directory に必要な設定。Settings required in Azure Active Directory to use Azure Resource Manager with Event Hubs.
  • サンプル コードを実行するために必要な手順。Steps required to execute the sample code.
  • 現在のプライマリ名前空間との間で行う送受信。Send and receive from the current primary namespace.

考慮事項Considerations

このリリースでは次の考慮事項にご注意ください。Note the following considerations to keep in mind with this release:

  1. 設計上、Event Hubs の geo ディザスター リカバリーではデータがレプリケートされないため、セカンダリ イベント ハブでプライマリ イベント ハブの古いオフセット値を再利用することはできません。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. 次のいずれかを使用して、イベント レシーバーを再起動することをお勧めします。We recommend restarting your event receiver with one of the following:
  • EventPosition.FromStart() - セカンダリ イベント ハブのすべてのデータを読み取る場合。EventPosition.FromStart() - If you wish read all data on your secondary event hub.
  • EventPosition.FromEnd() - セカンダリ イベント ハブに接続してからのすべての新しいデータを読み取る場合。EventPosition.FromEnd() - If you wish to read all new data from the time of connection to your secondary event hub.
  • EventPosition.FromEnqueuedTime(dateTime) - 指定した日付と時刻以降にセカンダリ イベント ハブで受信したすべてのデータを読み取る場合。EventPosition.FromEnqueuedTime(dateTime) - If you wish to read all data received in your secondary event hub starting from a given date and time.
  1. フェールオーバー計画では、時間的要因も考慮する必要があります。In your failover planning, you should also consider the time factor. たとえば、接続の喪失時間が 15 ~ 20 分を超えた場合にフェールオーバー開始の判断を下すことが考えられます。For example, if you lose connectivity for longer than 15 to 20 minutes, you might decide to initiate the failover.

  2. レプリケートされるデータが存在しないということは、現在アクティブなセッションがレプリケートされないことを意味します。The fact that no data is replicated means that currently active sessions are not replicated. また、重複の検出やスケジュールされたメッセージが正しく機能しない可能性があります。Additionally, duplicate detection and scheduled messages may not work. 新しいセッションやスケジュールされたメッセージ、新しい重複については正しく機能します。New sessions, scheduled messages, and new duplicates will work.

  3. 複雑な分散インフラストラクチャのフェールオーバーは、少なくとも 1 回はリハーサルを行うようお勧めします。Failing over a complex distributed infrastructure should be rehearsed at least once.

  4. エンティティの同期には、ある程度時間がかかる場合があります (1 分あたり約 50 ~ 100 エンティティ)。Synchronizing entities can take some time, approximately 50-100 entities per minute.

可用性ゾーンAvailability Zones

Event Hubs Standard SKU では、Azure リージョン内に障害から分離された場所を提供する Availability Zones がサポートされています。The Event Hubs Standard SKU supports Availability Zones, providing fault-isolated locations within an Azure region.

注意

Azure Event Hubs Standard に対する Availability Zones のサポートは、可用性ゾーンが存在する Azure リージョン内でのみ利用できます。The Availability Zones support for Azure Event Hubs Standard is only available in Azure regions where availability zones are present.

Azure Portal を使用して、新しい名前空間でのみ Availability Zones を有効にすることができます。You can enable Availability Zones on new namespaces only, using the Azure portal. Event Hubs では、既存の名前空間の移行はサポートされていません。Event Hubs does not support migration of existing namespaces. 名前空間でゾーン冗長を有効にした後に、無効にすることはできません。You cannot disable zone redundancy after enabling it on your namespace.

3

次の手順Next steps

  • GitHub のサンプルで、geo ペアリングを作成してディザスター リカバリー シナリオのフェールオーバーを開始する簡単なワークフローの手順について説明します。The sample on GitHub walks through a simple workflow that creates a geo-pairing and initiates a failover for a disaster recovery scenario.
  • REST API リファレンスで、geo ディザスター リカバリーの構成を実行するための API について説明します。The REST API reference describes APIs for performing the Geo-disaster recovery configuration.

Event Hubs の詳細については、次のリンクを参照してください。For more information about Event Hubs, visit the following links: