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