災害時回復のシナリオ例でのミラーリングの使用

このエンドツーエンドの災害復旧シナリオでは、大規模なインシデントが IBM Cloud のフル・リージョンに影響を与える場合に、ミラーリングを使用して可用性を高め、アプリケーションの動作を維持する方法を示します。

2つのクラスタが異なるリージョンにプロビジョニングされ、クラスタのエイリアスとしてAとBを使用してミラーリング用に構成されました（ミラーリングの有効化の情報に従ってください）。プロデューサーは accounting.invoices というトピックにレコードをパブリッシュし、コンシューマーはクラスター A 内のそのトピックからメッセージを読み取ります。

ソース・クラスターが使用不可になる

ソース・クラスタのリージョンで災害が発生した場合を考えてみよう。

ソース・クラスターでの災害の図。 — Disaster in source cluster's region

イベントの影響が災害を宣言するほどかどうかを判断するのは、Event Streamsインスタンス所有者の責任である。サービス・インスタンス所有者は、必要に応じて、再構成、再デプロイメント、再始動など、アプリケーションのフェイルオーバーを調整する必要があります。

プロデューサーのフェイルオーバー

フェイルオーバーするには、以下の手順を実行します。

クラスター A を指していたプロデューサーを停止します。
クラスタAおよびAからクラスタBへのリンクがまだ動作可能な場合は、クラスタB上のトピックのラグがゼロであることを確認して、可能な限り多くのデータがミラーリングされていることを確認します。
プロデューサを再起動して、クラスタBのエンドポイントを指すようにする。
クラスター A からクラスター B へのトピックでまだ有効になっているミラーリングを無効にします。これは、ユーザー制御を使用して行うことができます。

ターゲット・クラスター B 上のプロデューサーの概要図。 — Producer switched to cluster B.

これで、プロデューサーがクラスター B に切り替わり、元のトピックと同じ名前の新しいローカル・トピックにメッセージが送信されます。

コンシューマーのフェイルオーバー

フェイルオーバーするには、以下の手順を実行します。

クラスター A および A からクラスター B へのリンクがまだ作動可能な場合は、コンシューマーがクラスター A 上のトピック内のすべてのメッセージ・データを読み取り、トピックの終わりでそれらのオフセットをコミットできるようにします。
クラスターAを指していた消費者を止める。
クラスタBのエンドポイントを指すようにコンシューマを再起動します。

クラスター B のコンシューマーの図。 — The consumer continues to consume the existing messages.

コンシューマは、新しいメッセージが accounting.invoices から来る間、クラスタBからの accounting.invoices.A トピックから既存のメッセージを消費し続けることができるようになった。

アプリケーションに厳密な順序付けが必要な場合、ローカル・トピックからの消費を開始する前に、まずリモート・トピックを完全に消費する。このようにして、メッセージはプロデュースされた順序で処理されます。

ミラーリング環境のリセット

Event Streams サービス・インスタンス所有者は、クラスター A のリカバリー時に何が行われるかを決定する責任があります。

クラスター A がリカバリー可能でない場合は、Event Streams サービス・インスタンス所有者は、クラスター B と新しくプロビジョンされたインスタンスの間のミラーリングを有効にする必要があります。新規インスタンスへのミラーリングを有効にするには、以下の手順を実行します。

前述のように、プロデューサーとコンシューマーを A から B にフェイルオーバーします。
クラスター A からクラスター B への現行ミラーリングを無効にします。詳しくは、ミラーリングの無効化を参照してください。
ミラーリングが使用不可になった後、新しくプロビジョンされたクラスター (ターゲット) へのクラスター B (現在はソース) 間のミラーリングを使用可能にします。詳しくは、ミラーリングの有効化を参照してください。

あるいは、クラスタAが回復した場合、通常、ユーザーは操作をクラスタAに戻す。 1 次操作をクラスター A に戻すには、以下のステップを実行します。

フェイルバックする前に、逆方向のミラーリングを有効にしなければならない：

クラスター A が完全に作動可能であることを確認します。
クラスター A からクラスター B への現行ミラーリングを無効にします。詳しくは、ミラーリングの無効化を参照してください。
ミラーリングが使用不可になった後、クラスター B (現在はソース) とクラスター A (現在はターゲット) の間でミラーリングを使用可能にします。詳しくは、ミラーリングの有効化を参照してください。
ソース・クラスター A がターゲット・クラスターになります。
ターゲット・クラスター B が新しいソース・クラスターになります。
すべてのトピックをクラスター B からクラスター A にミラーリングできるようにします。これは、ユーザー制御を使用して行うことができます。

次に、クラスター A にあるクラスター B のトピックを調べて、データがクラスター A に複製されていることを確認します。これらのトピックには、新しいソース・クラスターのサフィックス B が付きます。

逆方向の図ではミラーリングが有効。 — Mirroring enabled in opposite direction.

クラスタBの元のターゲットトピックをミラーバックしないでください。図のように、クラスターBからクラスターAへaccounting.invoicesをミラーリングするのであって、accounting.invoices.Aをミラーリングするのではない。

フェイルバック

フェイルバックの決定も Event Streams インスタンス所有者が行います。サービス・インスタンス所有者は、必要に応じて、再構成、再デプロイメント、再始動など、アプリケーションのフェイルバックを調整する必要があります。

フェイルオーバーの場合とは異なり、このケースではクラスタBに災害は発生していない。そのため、フェイルバックは制御された操作であり、データの損失または再処理を最小限に抑えて行うことができます。

ミラーリングは元の構成図に戻った。 — Mirroring switched back to the original configuration.

最後に、ミラーリングを元の構成に戻します。つまり、クラスタAが再びソースとなり、クラスタBがターゲットとして再開します。

クラスター A とクラスター B が完全に作動可能であることを確認します。
クラスター B からクラスター A への現行ミラーリングを無効にします。詳しくは、ミラーリングの無効化を参照してください。
ミラーリングが使用不可になった後、クラスター A (現在はソース) とクラスター B (現在はターゲット) の間でミラーリングを使用可能にします。詳しくは、ミラーリングの有効化を参照してください。