同期ミラーリングが操作不可の場合の役割の変更

役割の切り替えにおけるさらに複雑な状態は、2 つのサイト間に通信が存在しない (ネットワークの誤動作のため、または 1 次サイトが操作可能でなくなったため) 場合です。

このシナリオの CLI コマンドは、mirror_change_role です。2 つのサイト間に通信が存在しないため、このコマンドは、両方のサイトで同時に発行するか、少なくとも通信が再開する前に発行してください。そのようにしないと、サイトが通信を確立できなくなります。

1 次ボリュームと 2 次ボリュームが接続されているか否かによって、切り替え手順は異なります。一般的な規則として、以下が当てはまります。
  • カップリングが非アクティブ化されている場合、一方のサイドのみで役割を変更することができます。通信の再開前に他方のサイドでも変更が行われることを想定しています。
  • カップリングがアクティブ化されても、リンク・エラーが原因で非同期状態または操作不可状態になっている場合、管理者はカップリングが同期されるのを待つか、カップリングを非アクティブ化する必要があります。
  • カップリングがアクティブな場合でも、管理者は 2 次ボリュームで役割を変更できます。これは、1 次ボリュームでカップリングが非アクティブ化され、1 次ボリュームでも役割の切り替えが並行して実行されるであろうという前提に基づきます。前提どおりにならない場合、元の 1 次ボリューム上で構成エラーが発生します。

1 次ボリュームへの 2 次ボリュームの変更

Hyper-Scale Manager または CLI を使用して、2 次ボリュームの役割を 1 次ボリュームに変更できます。 この切り替えの後、次のようになります。
  • 2 次ボリュームが 1 次ボリュームになっています。
  • カップリングの状況が「非同期」になります。
  • カップリングは、スタンバイ・モードのまま残ります。つまり、リモート・ミラーリングは非アクティブ化されています。これにより、他方のサイトの役割が切り替えられた場合に、確実に正しい順序でアクティブ化することができます。

新しい 1 次ボリュームは、ローカル・ホストからの書き込みコマンドの受け入れを開始します。カップリングがアクティブではないため、すべての 1 次ボリュームと同じ方法で、通信が再開されたときにどの書き込み操作を 2 次ボリュームに送信するかをログに記録して保持します。

通常は、2 次ボリュームを 1 次ボリュームに切り替えた後、少なくとも通信が再開する前に管理者が 1 次ボリュームを 2 次ボリュームに切り替えます。両方のボリュームが同じ役割のまま放置されると、構成エラーが発生します。

2 次ボリュームへの 1 次ボリュームの変更

カップリングが非アクティブの場合、1 次マシンの役割を切り替えることができます。 そのような切り替えを行うと、1 次ボリュームが 2 次になります。

役割を切り替える前は、1 次ボリュームは非アクティブになっています。そのため、非同期状態になっていて、複製されていないデータを格納している可能性があります。そのようなデータは失われます。1 次ボリュームが 2 次になると、ピア・ボリューム (新しく 1 次ボリュームとなったボリューム) 上のデータと一致するように、このデータは破棄される必要があります。この場合、イベントが作成され、失われたデータのサイズの要約が示されます。

接続を再確立するときに、リカバリー・ボリューム (現在の 2 次、元の 1 次) は、この非コミット・データ・リストを使用してリモート・ボリューム (新しい 1 次) を更新します。これらのリストをローカル・ボリューム (新しい 2 次) に同期するのは新しい 1 次ボリュームの責任です。