ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Unified Directoryへの移行
11g リリース2 (11.1.2)
E61962-01
  目次へ移動
目次

前
 
次
 

2 移行ストラテジの選択

この章では、Directory Server Enterprise Editionの既存のインストールをOracle Unified Directoryに移行する、移行ストラテジを選択するための方法を示します。ストラテジの選択は、反復プロセスになる可能性があることに注意してください。

この章の内容は次のとおりです。

2.1 要件の分析

移行プロセスは、アーキテクチャおよび操作上の要件と連携している必要があります。適切な移行ストラテジを選択することは、OUDにスムーズに移行するための重要な要因です。移行ストラテジを選択する際に考慮する重要な要因を次に示します。

2.1.1 本番環境での(O)DSEEとOUDトポロジの共存

共存させる方法を使用することで、差分移行プロセスを実行できます。このプロセスでは、クライアント・アプリケーションが徐々にOUDに変換される間、(O)DSEEとOUDデプロイメントが共存し、本番環境での同期が維持されます。この方法により、サービスを中断しなくてもアプリケーションを(O)DSEEに戻すこともできます。

共存が終了するまでOUDが提供するいくつかの付加価値サービス/機能をデプロイできないため、特定の期間にのみこのストラテジを使用することをお薦めする、という点を認識していることが重要です。同様に、変更を(O)DSEEにレプリケートできなくなるまで、トポロジはOUDによって可能となる書込みパフォーマンスの向上を提供できなくなります。

2つの環境を稼働させておくには、2つのインフラストラクチャを個別に管理する必要があるため、追加のシステム・リソースが必要です。また、2つの環境を同期させておくことでシステムがさらに複雑になるため、移行プロジェクトで共存が重要な要件になるかどうかを評価することをお薦めします。

2.1.2 共存と(O)DSEEとOUDの間のデータの整合性

レプリケーション中は、サーバー間ですべてのデータがコピーおよび同期され、最新の状態が維持されます。ただし、各サーバーには必ずしも同じデータ(特にメタデータ)が含まれるわけではありません。本番環境でのODSEEとOUDトポロジの共存を選択した場合は、次のガイドラインに従います。

  • 2つの環境の間で想定されるデータの整合性のレベルを評価します。

  • すべての変更が一貫して正しい順序で適用されるように、グローバル・レプリケーションの競合管理との厳密な整合性が必要かどうかを決定します。

  • 同期の遅延に対応するか、(O)DSEEとOUDトポロジの間でほぼリアルタイムのデータ整合性を必要とするかを選択することで、一時的なデータの整合性の処理方法を決定します。

  • トポロジ全体で一貫してアカウントがロックされるように、パスワード・ポリシー関連の完全な同期状態を必要とするかどうかを設定します。


注意:

非常に短期間の共存を必要とするプロジェクトでは、十分な機能を持つグローバル・パスワード・ポリシーのサポートを必要としない可能性があります。別々のサーバーで同じエントリを同時に変更すると、競合が発生する可能性があります。このような特定の状況では、完全な競合管理により、両方のサーバーでエントリが同じになります。

2.1.3 (O)DSEEインフラストラクチャでの移行の影響

特別な場合、(O)DSEEインフラストラクチャに限定的な変更を加えることで、移行プロセスを大幅に簡素化し、特定の機能のサポートが可能になる可能性があります。たとえば、(O)DSEEに対するそのような変更には、LDAPスキーマ拡張の追加、パスワード・ポリシー・モードの変更、レトロ変更ログのデプロイメントなどがあります。

移行ストラテジの選択の一部として、(ODSEE)に対する特定の変更が受入可能かどうかを決定します。

2.1.4 書込みサービスの中断を伴う(または伴わない)移行

サービスを中断せずにクライアント・トラフィックを(O)DSEEからOUDにリダイレクトできるかどうかは、重要な検討要素です。管理者は、移行中の書込みサービスを確実にする組込みの自動メカニズムを認識している必要があります。他のプロジェクトの場合、更新の中断は受け入れられません。

このガイドに示す一部の移行ストラテジでは、移行中に完全書込みの高可用性が実現します。他の移行ストラテジでは、トラフィックを複製できるプロキシなど、追加コンポーネントのデプロイメントが必要になります。

2.1.5 ユーザー・データ構造の変更

ディレクトリ・サービスを移行する前に、既存のディレクトリ・サービス・アーキテクチャおよびユーザー・データ構造を評価することもできます。既存のアーキテクチャに満足している場合は、ユーザー・データのサブセットのみを再度表示することもできます。

このガイドでは、ユーザー・データ構造の再設計を含む移行は取り上げません。移行の際にユーザー・データ構造の変更が必要な場合は、Oracle Support担当に問い合せてください。

2.2 サポートされている移行ストラテジ

この項では、Oracleが移行でサポートしているストラテジ、および技術的なニーズに最も適した移行ストラテジを選択する際に役立つ決定マトリックスについて説明します。次のいずれかのストラテジを選択します。

2.2.1 レプリケーション・ゲートウェイを使用した共存

このストラテジでは、(O)DSEEおよびOUDトポロジは、レプリケーション・ゲートウェイを使用することでネイティブ・レプリケーション・プロトコル・レベルで同期が維持されます。ゲートウェイ経由のレプリケーションでは、ポーリング・メカニズムが含まれないため、非常に低遅延になります。

レプリケーション・ゲートウェイは他のOUDコンポーネントのようにインストールおよび管理され、(O)DSEEとOUDの間で必要なレプリケーション・プロトコルが調整されます。レプリケーション・ゲートウェイでは、2つのタイプのディレクトリ間で厳密なデータ整合性が提供され、競合管理が十分に活用されます。完全なディレクトリ・メタデータがレプリケートされると、適切なアカウント・ロックが維持されるように、レプリケーション・ゲートウェイは内部パスワード・ポリシー状態も同期します。

レプリケーション・ゲートウェイは、(O)DSEEとOUDの間で双方向の完全なレプリケーションを提供します。それは、ゲートウェイ・レベルで格納されることなく、異機種環境のレプリケートされたトポロジ間で更新を伝播する高パフォーマンスのルートです。レプリケーションの単位は、(O)DSEE側で定義されているサフィックスです。OUDからの変更が(O)DSEEに反映されない間にディレクトリ・サーバーからの変更がOUDにレプリケートされるように、レプリケーション・ゲートウェイを一方向モードで実行することもできます。

高可用性を実現するために、すべてのシナリオで2つの(O)DSEEマスターと2つのOUDレプリケーション・サーバーの間に少なくとも2つのレプリケーション・ゲートウェイ・サーバーがデプロイされます。これにより、シングル・ポイント障害のリスクが排除されます。

2.2.2 Oracle Directory Integration Platform (DIP)を使用した共存

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)ライブラリにあります。

2.2.3 直接移行ストラテジ

このストラテジでは、標準のディレクトリ管理コマンドとともにエクスポートおよびインポート・メソッドを使用します。ユーザー・データおよび構成は(O)DSEEからエクスポートされ、このガイドで説明するツールおよび手順を使用して必要に応じて調整されます。その後、ユーザー・データおよび構成がOUDにインポートされます。

直接移行ストラテジは特異な移行であり、簡単かつ迅速に実行できます。書込み機能の中断が受入れ可能な場合に使用できます。通常、ディレクトリ管理者はロード・バランサまたはLDAPプロキシを使用して、インフラストラクチャを読取り専用モードに設定し、データを(O)DSEEからエクスポートし、データをOUDにインポートした後、トラフィックをOUDにリダイレクトします。

2.2.4 決定マトリックス

次の決定マトリックスは、移行ストラテジを選択する際の主要な決定要因をまとめたものです。

表2-1 移行ストラテジの決定要因

決定要因 レプリケーション・ゲートウェイを使用した共存 DIPを使用した共存 直接移行

共存

はい

はい

いいえ

データ整合性レベル

厳密

低遅延

ルーズ

遅延はDIP構成に依存します

N/A

パフォーマンス

N/A

(O)DSEEへの影響

(O)DSEEリリースおよび設定に依存します(第3章「移行ストラテジの検証」)

レトロ変更ログの有効化

いいえ

書込みサービスの可用性

組込みサポート

組込みサポート

追加コンポーネント(*)が必要です

データ調整/構造の変更

いいえ

可(制限を適用)

可(任意で実行可能)

高可用性

組込みサポート

デプロイメント固有

N/A


(*)このガイドでは取り上げません