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

実動場所 (サイト A) での計画停止をスケジュールに入れると、実動をリカバリー・サイト (サイト B) に切り替えることができます。これにより、データの処理をサイト B で再開することができます。このプロセスはフェイルオーバー・リカバリーと呼ばれています。

1. 計画停止の時期になったら、アプリケーションを静止して、書き込み入出力によるソース・ボリュームの更新をすべて停止します。アプリケーションの静止は、計画停止の一環として行うこともできますが、静止処置によって生じる処理の遅延は短時間にする必要があります。
   注: AIX^®、Windows^®、Linux^® など、一部のホスト・システム上では、FlashCopy 操作を実行する前に、FlashCopy ソース・ボリュームにアクセスするアプリケーションを静止する必要があります。ソース・ボリュームは、FlashCopy 操作中にアンマウント (ホスト・オペレーティング・システムによって異なります) する必要があります。 これにより、バッファーにデータがない状態になり、バッファーのデータがターゲット・ボリュームに流れてターゲット・ボリュームを破壊することを防止できます。
2. サイト B へのフェイルオーバー・リカバリー操作を実行します。 フェイルオーバー操作が正常に処理されると、サイト B のボリュームがターゲット・ボリュームからソース・ボリュームに移行します。
3. パス設計に応じて、ソース・ストレージ・ユニットが使用可能になったときに、サイト B からサイト A への反対方向のパスを作成します。 更新情報をサイト A に戻したい場合は、反対方向へのパスが必要です。
4. ファイバー・チャネル装置を再スキャンします (これはご使用のオペレーティング・システムによって異なります)。再スキャンにより、サイト A ボリュームの装置オブジェクトが除去され、新規ソース・ボリュームが認識されます。
5. サイト B でターゲット・ボリューム (現在は新規ソース・ボリューム) をターゲット・ストレージ・ユニットにマウントします。
6. すべてのアプリケーションを開始します。アプリケーションが開始すると、ソース・ボリュームに対するすべての書き込み入出力操作がトラッキングされます。サイト A に関する計画によっては、ボリューム・ペアが延期状態のままになることがあります (オフライン保守を行いたい場合)。
7. 定期保守が完了したときに、フェイルバック・リカバリー操作を開始します。 フェイルバック・リカバリー操作は、サイト A にデータを戻す転送を開始します。この処理は、サイト A のボリュームをサイト B のボリュームに再同期させます。
   注: フェイルバック・リカバリー操作は、通常、逆方向 (リモート・サイトからローカル・サイトへ) または元の方向 (ローカル・サイトからリモート・サイトへ) のいずれかにミラーリングを再始動するためにフェイルオーバー・リカバリーを実行した後で、使用します。

   表 1 は、フェイルオーバー操作とフェイルバック操作のインプリメンテーション例です。