レプリケーションの方向を逆にして、2 システムによる障害回復計画およびディスク間バックアップをサポートできます。
レプリケーションを逆向きにする操作によって、レプリケーションパッケージはローカルプロジェクトに変換されます。この操作は新しいローカルプロジェクト上で、増分レプリケートしてソースアプライアンスに戻すレプリケーションアクションも構成します。最初の更新が試行されると、ソースシステム上の元のプロジェクトがレプリケーションパッケージに変換され、そのシステムからのレプリケーション更新が最後に正常に実行された時点以降の変更がすべてロールバックされます。
次の図で、逆向きレプリケーションの一連のイベントについて説明します。
図 33 障害回復のためのリモートレプリケーションの使用
|
元のソースプロジェクトを (現在はターゲットとして動作している) 元のソースアプライアンス上のレプリケーションパッケージに変換するとき、現在逆向きになっているアクション/パッケージの一部としてレプリケートされたシェアが、新しいレプリケーションパッケージに移動され、アンエクスポートされます。元のプロジェクトはローカルコレクションに残りますが、アクション/パッケージがそのすべてのシェアを含んでいた場合には、空になることがあります。シェアレベルのレプリケーションを逆向きにした場合、元のプロジェクト内のほかのシェアはどれも変更されません。
パッケージのレプリケーションの方向を逆にする前に、ソースアプライアンスからのそのプロジェクトのレプリケーション更新を停止します。レプリケーション更新の進行中に管理者がプロジェクトのレプリケーションの方向を逆にした場合、管理者は、以前のレプリケーションターゲット (現在のソースアプライアンス) に作成されたプロジェクトに、どの整合性のあるレプリケーションスナップショットが使用されたのかわからなくなります。
逆向き操作中または操作後にレプリケーション更新が実行されると、更新に失敗し、適切なアラートが発行されます。その後、レプリケーションアクションが無効になり、今後は、このアクションからレプリケーションターゲットへの更新が行われません。更新を元のプロジェクトから新しいレプリケーションパッケージに送信するには、新しいレプリケーションアクションおよび完全更新が必要です。
ローカルのシェアはすべてエクスポートされるため、パッケージを逆向きにすると、それまでにエクスポートされたかどうかにかかわらずパッケージ内のすべてのシェアがエクスポートされます。レプリケートされたファイルシステムとシステム上のほかのファイルシステムの間でマウントポイントが競合している場合、逆向きにする操作は失敗します。切断する前に、関連するシェアのマウントポイントを再構成して、これらの競合を解決する必要があります。通常、この操作は本番用のサービスの復元におけるクリティカルパスの一部なため、このようなマウントポイントの競合は、障害回復フェイルオーバーの時点ではなく、システムを最初に設定するときに解決することを強くお勧めします。
関連トピック