計画外の停止後のサイト B への実動の移動 (フェイルオーバー)

このシナリオでは、サイト A で予期しない障害が発生したことを想定します。サイト A での障害により、ボリュームが使用停止になったか、使用停止のボリューム・ペアと全二重のボリューム・ペアが混在しています。これは、障害が発生したときにこれらのボリュームに入力が書き込まれたからです。

災害時回復環境で、2 つのストレージ・ユニットが 2 つの地理的に離れた位置にセットアップされている場合、実動またはローカル・サイトのストレージ・ユニットをサイト A、リモートまたはリカバリー・サイトのストレージ・ユニットをサイト B と呼びます。

1 次側となるストレージ・ユニットに対してフェイルオーバー操作が実行されます。この停止時に実動サイトはサイト B に移動し、これによってサイト B のターゲット・ボリュームはソース・ボリュームに変換されます。ボリュームは使用停止状態に指定されます。サイト A の元のソース・ボリュームは、サイト切り替え時の状態のままとなります。サイト A が再度使用可能になると、アプリケーションの入出力がサイト B からサイト A に戻されます。

次の手順では、計画外の停止に対応して実動サイトをサイト B に移動し、リカバリー後に実動サイトをサイト A に戻すために必要な処置を要約します。

サイト B へのフェイルオーバー・リカバリー操作を実行します。フェイルオーバー操作が正常に処理されると、サイト B のボリュームがターゲット・ボリュームからソース・ボリュームに移行します。
サイト B のサーバーにターゲット・ボリュームをマウントします。
サイト B のサーバーでアプリケーションを開始します。
サイト A がリカバリーした後、以下のステップに進みます。以下のステップは、サイト A のボリュームをリカバリーするために最初に行われます。
1. サイト B とサイト A の LSS 間にパスを作成して、サイト A のボリュームがサイト B のボリュームと同期されるようにします。
2. ソース・ボリュームに存在するリモート・ミラーおよびコピー・ボリューム関係を削除します。
3. ボリュームが全二重状態になるまで待機します。次に、サイト A のボリュームを使用して、フェイルバック・リカバリー操作を実行する時間をスケジュールに入れます。この処理は、サイト A のボリュームをサイト B のボリュームに再同期させます。
  注: フェイルバック・リカバリー操作は、通常、逆方向 (リモート・サイトからローカル・サイトへ) または元の方向 (ローカル・サイトからリモート・サイトへ) のいずれかにミラーリングを再開するためにフェイルオーバー・リカバリーを実行した後で、使用します。