この章では、Directory Server Enterprise Editionの既存のインストールをOracle Unified Directoryに移行する、移行ストラテジを選択するための方法を示します。ストラテジの選択は、反復プロセスになる可能性があることに注意してください。
この章の内容は次のとおりです。
移行プロセスは、アーキテクチャおよび操作上の要件と連携している必要があります。適切な移行ストラテジを選択することは、OUDにスムーズに移行するための重要な要因です。移行ストラテジを選択する際に考慮する重要な要因を次に示します。
共存させる方法を使用することで、差分移行プロセスを実行できます。このプロセスでは、クライアント・アプリケーションが徐々にOUDに変換される間、(O)DSEEとOUDデプロイメントが共存し、本番環境での同期が維持されます。この方法により、サービスを中断しなくてもアプリケーションを(O)DSEEに戻すこともできます。
共存が終了するまでOUDが提供するいくつかの付加価値サービス/機能をデプロイできないため、特定の期間にのみこのストラテジを使用することをお薦めする、という点を認識していることが重要です。同様に、変更を(O)DSEEにレプリケートできなくなるまで、トポロジはOUDによって可能となる書込みパフォーマンスの向上を提供できなくなります。
2つの環境を稼働させておくには、2つのインフラストラクチャを個別に管理する必要があるため、追加のシステム・リソースが必要です。また、2つの環境を同期させておくことでシステムがさらに複雑になるため、移行プロジェクトで共存が重要な要件になるかどうかを評価することをお薦めします。
レプリケーション中は、サーバー間ですべてのデータがコピーおよび同期され、最新の状態が維持されます。ただし、各サーバーには必ずしも同じデータ(特にメタデータ)が含まれるわけではありません。本番環境でのODSEEとOUDトポロジの共存を選択した場合は、次のガイドラインに従います。
2つの環境の間で想定されるデータの整合性のレベルを評価します。
すべての変更が一貫して正しい順序で適用されるように、グローバル・レプリケーションの競合管理との厳密な整合性が必要かどうかを決定します。
同期の遅延に対応するか、(O)DSEEとOUDトポロジの間でほぼリアルタイムのデータ整合性を必要とするかを選択することで、一時的なデータの整合性の処理方法を決定します。
トポロジ全体で一貫してアカウントがロックされるように、パスワード・ポリシー関連の完全な同期状態を必要とするかどうかを設定します。
注意: 非常に短期間の共存を必要とするプロジェクトでは、十分な機能を持つグローバル・パスワード・ポリシーのサポートを必要としない可能性があります。別々のサーバーで同じエントリを同時に変更すると、競合が発生する可能性があります。このような特定の状況では、完全な競合管理により、両方のサーバーでエントリが同じになります。 |
特別な場合、(O)DSEEインフラストラクチャに限定的な変更を加えることで、移行プロセスを大幅に簡素化し、特定の機能のサポートが可能になる可能性があります。たとえば、(O)DSEEに対するそのような変更には、LDAPスキーマ拡張の追加、パスワード・ポリシー・モードの変更、レトロ変更ログのデプロイメントなどがあります。
移行ストラテジの選択の一部として、(ODSEE)に対する特定の変更が受入可能かどうかを決定します。
この項では、Oracleが移行でサポートしているストラテジ、および技術的なニーズに最も適した移行ストラテジを選択する際に役立つ決定マトリックスについて説明します。次のいずれかのストラテジを選択します。
このストラテジでは、(O)DSEEおよびOUDトポロジは、レプリケーション・ゲートウェイを使用することでネイティブ・レプリケーション・プロトコル・レベルで同期が維持されます。ゲートウェイ経由のレプリケーションでは、ポーリング・メカニズムが含まれないため、非常に低遅延になります。
レプリケーション・ゲートウェイは他のOUDコンポーネントのようにインストールおよび管理され、(O)DSEEとOUDの間で必要なレプリケーション・プロトコルが調整されます。レプリケーション・ゲートウェイでは、2つのタイプのディレクトリ間で厳密なデータ整合性が提供され、競合管理が十分に活用されます。完全なディレクトリ・メタデータがレプリケートされると、適切なアカウント・ロックが維持されるように、レプリケーション・ゲートウェイは内部パスワード・ポリシー状態も同期します。
レプリケーション・ゲートウェイは、(O)DSEEとOUDの間で双方向の完全なレプリケーションを提供します。それは、ゲートウェイ・レベルで格納されることなく、異機種環境のレプリケートされたトポロジ間で更新を伝播する高パフォーマンスのルートです。レプリケーションの単位は、(O)DSEE側で定義されているサフィックスです。OUDからの変更が(O)DSEEに反映されない間にディレクトリ・サーバーからの変更がOUDにレプリケートされるように、レプリケーション・ゲートウェイを一方向モードで実行することもできます。
高可用性を実現するために、すべてのシナリオで2つの(O)DSEEマスターと2つのOUDレプリケーション・サーバーの間に少なくとも2つのレプリケーション・ゲートウェイ・サーバーがデプロイされます。これにより、シングル・ポイント障害のリスクが排除されます。
Oracle Directory Integration Platform (DIP)は、様々なリポジトリで使用される多目的の同期ツールで、次の処理を実行できます。
(O)DSEEとOUDトポロジを同期します。
停止時間なしで徐々に移行する際にOUDを使用してディレクトリ・サーバーを実行します。
(O)DSEEおよびOUDで構成された変更ログを使用して、変更を検出し、繰り返します。
同期は定期的に行われ、実行のたびに構成可能な最大数の変更が処理されます。DIPはユーザー・データのみを同期します。
DIPの詳細は、『Oracle Directory Integration Platform (DIP)管理者ガイド』を参照してください。ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g
リリース1 (11.1.1.7)ライブラリにあります。
このストラテジでは、標準のディレクトリ管理コマンドとともにエクスポートおよびインポート・メソッドを使用します。ユーザー・データおよび構成は(O)DSEEからエクスポートされ、このガイドで説明するツールおよび手順を使用して必要に応じて調整されます。その後、ユーザー・データおよび構成がOUDにインポートされます。
直接移行ストラテジは特異な移行であり、簡単かつ迅速に実行できます。書込み機能の中断が受入れ可能な場合に使用できます。通常、ディレクトリ管理者はロード・バランサまたはLDAPプロキシを使用して、インフラストラクチャを読取り専用モードに設定し、データを(O)DSEEからエクスポートし、データをOUDにインポートした後、トラフィックをOUDにリダイレクトします。
次の決定マトリックスは、移行ストラテジを選択する際の主要な決定要因をまとめたものです。
表2-1 移行ストラテジの決定要因
決定要因 | レプリケーション・ゲートウェイを使用した共存 | DIPを使用した共存 | 直接移行 |
---|---|---|---|
共存 |
はい |
はい |
いいえ |
データ整合性レベル |
厳密 低遅延 |
ルーズ 遅延はDIP構成に依存します |
N/A |
パフォーマンス |
高 |
中 |
N/A |
(O)DSEEへの影響 |
(O)DSEEリリースおよび設定に依存します(第3章「移行ストラテジの検証」) |
レトロ変更ログの有効化 |
いいえ |
書込みサービスの可用性 |
組込みサポート |
組込みサポート |
追加コンポーネント(*)が必要です |
データ調整/構造の変更 |
いいえ |
可(制限を適用) |
可(任意で実行可能) |
高可用性 |
組込みサポート |
デプロイメント固有 |
N/A |
(*)このガイドでは取り上げません