この章では、Oracle Unified Directoryディレクトリ・サーバーの複数のインスタンスが含まれる、レプリケートされるトポロジのサンプル構成について説明します。
この項の内容は次のとおりです:
Oracle Unified Directoryでのレプリケーションの動作の詳細は、第7章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。
サーバー間でディレクトリ・データをレプリケートすることによって、1つのサーバーのアクセス負荷を減らすことができるので、サーバー・レスポンス時間が向上し、読取り操作が水平方向にスケーリングされます。また、レプリケーションを使用して、システム障害が発生した場合のデータの可用性を保証できます。
注意: レプリケーションを使用して書込み操作をスケーリングすることはできません。これは、1つのディレクトリ・サーバーへの書込み操作は、結果的にトポロジ内の他のすべてのサーバーへの書込み操作になるからです。書込み操作を水平方向にスケーリングする唯一の方法は、ディレクトリ・データを分割して複数のデータベースに格納し、これらのデータベースを複数のサーバーに配置することです。 |
Oracle Unified Directoryの集中レプリケーション・モデルでは、ユーザー・データはレプリケーション・メタデータから分離されます。このモデルでは、ユーザー・データが格納されるサーバーは、ディレクトリ・サーバーと呼ばれます。レプリケーション・メタデータが格納されるサーバーは、レプリケーション・サーバーと呼ばれます。この方法は、レプリケーション・トポロジの管理を簡素化し、パフォーマンスを向上できます。
小規模デプロイメントの場合、レプリケーション・サーバーとディレクトリ・サーバーを同一システム上に配置する方法でレプリケーションを設定できます。1つのプロセスで各システム上のレプリケーション・サーバーとディレクトリ・サーバーを実行することによって、管理をさらに簡素化できます。
次の図は、小規模トポロジで、可用性を保証し、読取りをスケーリングするために、レプリケーションを使用する方法を示します。
ディレクトリ・サーバーには、次のタスクを実行する役割があります:
データの永続化およびクライアント・リクエストの処理
特定のレプリケーション・サーバーへの変更の転送
ディレクトリ・サーバー上で変更が行われると、このサーバーは、選択されているレプリケーション・サーバーに変更を転送します。レプリケーション・サーバーは受信した変更をトポロジ内の他のレプリケーション・サーバーにリプレイし、今度はそれらのサーバーが変更をトポロジ内の他のすべてのディレクトリ・サーバーにリプレイします。
各ディレクトリ・サーバーには、次の項目が格納されます:
同期する接尾辞DNのリスト
各接尾辞DNの接続先レプリケーション・サーバーのリスト
アプリケーションでは通常同じディレクトリ・サーバー・インスタンスで読取りおよび書込みを行います。これにより、それらのアプリケーションで緩い一貫性が原因で一貫性の問題が発生することを防ぎます。
レプリケーション・サーバーには、次のタスクを実行する役割があります:
ディレクトリ・サーバーからの接続の管理
他のレプリケーション・サーバーへの接続
他のレプリケーション・サーバーからの接続のリスニング
ディレクトリ・サーバーからの変更の受信
ディレクトリ・サーバーおよび他のレプリケーション・サーバーへの変更の転送
安定したストレージへの変更の保存(古い操作の切捨てが含まれます)
各レプリケーション・サーバーには、レプリケーション・トポロジ内の他のすべてのレプリケーション・サーバーのリストが存在します。レプリケーション・サーバーには、レプリケーション・トポロジに関する情報を他のサーバーに提供する役割もあります。最小規模のデプロイメントであっても、2つのレプリケーション・サーバー・インスタンスを実行する必要があります。これは、どちらかのレプリケーション・サーバー・インスタンスに障害が発生した場合の可用性を保証するためです。通常、同時に複数の障害が発生してもディレクトリ・サービスを提供できるようにする必要がある場合またはディレクトリ・サーバー・インスタンスの数を非常に多くする必要がある場合を除いて、レプリケーション・サーバー・インスタンスを増やす必要はありません。
注意: レプリケーション・アーキテクチャでは、各レプリケーション・サーバーは、トポロジ内の他のすべてのレプリケーション・サーバーに接続されています。 |
レプリケーション・サーバーは、ディレクトリ・データは格納されませんが、常にLDAPサーバーまたはJMXサーバーのいずれかです。ディレクトリ・サーバー同様、レプリケーション・サーバーを構成、監視、バックアップおよびリストアできます。
レプリケーションを使用して、複数のデータ・センターの複数のサーバー上にディレクトリ・データの同一のコピーを提供することにより、ディレクトリ・サービスを地理的に分散させることができます。小規模トポロジに関する項で説明したレプリケーション・デプロイメントの基本原則は、複数のデータ・センターのデプロイメントにも当てはまります。
Oracle Unified Directoryディレクトリ・サーバーは、広域ネットワーク(WAN)上で効果的なカスタム・レプリケーション・プロトコルを使用します。次のシナリオでは、企業がロンドンとニューヨークの2箇所に大規模データ・センターを配置し、それらがWANで接続されています。
このデプロイメントには、どちらかのレプリケーション・サーバー・インスタンスに障害が発生した場合の各データ・センターの可用性を保証するために、2つのレプリケーション・サーバー・インスタンスが存在します。ディレクトリ・サーバーはまず、ローカル・レプリケーション・サーバーに接続します。ディレクトリ・サーバーがもう一方のデータ・センターにあるレプリケーション・サーバーにアクセスするのは、すべてのローカル・レプリケーション・サーバーに障害が発生した場合のみです。クライアント・アプリケーションは常にローカル・ディレクトリ・サーバー・インスタンスに接続し、同一のディレクトリ・サーバー・インスタンスに対して読取りと書込みを実行します。
Oracle Unified Directoryディレクトリ・サーバーがサポートする、レプリケーション・トポロジ内の読取り/書込みディレクトリ・サーバーの数には制限がありません。ディレクトリ・サーバーの数は、組織の読取り要件に従ってスケーリングできます。
注意: ディレクトリ・サーバーの数を増やしても、処理できる書込みの数はスケーリングされません。これは、最終的にはトポロジ内のすべてのサーバーがすべての書込みを処理する必要があるからです。収束しないトポロジを持つことが許容される場合を除き、トポロジの書込みスループットは、最も遅いサーバーの書込みスループットで制限されます。 |
レプリケーション・グループを使用すると、データ・センターの場所など、特定の条件に従って、レプリケートされるトポロジを編成できます。レプリケーション・グループは、グループ内のレプリケーション・サーバーとディレクトリ・サーバーに割り当てられる一意のIDによって識別されます。グループIDによって、ディレクトリ・サーバー・ドメインが利用可能なレプリケーション・サーバーに接続する方法が決まります。ディレクトリ・サーバーは、構成済のレプリケーション・サーバーのリストを参照して、自身のグループIDと同じグループIDを持つレプリケーション・サーバーに接続を試みます。
次のサンプル・デプロイメントでは、複数のデータ・センターでのレプリケーション・グループの使用方法を示します。このデプロイメントでは、2つのデータ・センターが、広域ネットワーク(WAN)で接続され、次のように構成されていると想定しています:
1つのデータ・センター内のレプリケーション・サーバーとディレクトリ・サーバーにはそれぞれ同じグループIDが割り当てられています。
データ・センター全体で1つの一意なグループIDを持ちます(データ・センターごとに1つのグループID)。
図2-3は、異なるグループIDを持つ2つのデータ・センターで構成されるディザスタ・リカバリ・デプロイメントを示します。
このデプロイメントでは、各ディレクトリ・サーバーは同じデータ・センターにあるレプリケーション・サーバーに接続を試みることによって、WAN経由で接続する場合の待機時間を回避します。データ・センター内のすべてのレプリケーション・サーバーに障害が発生している場合は、ディレクトリ・サーバーはリモート・レプリケーション・サーバーに接続します。これにより、パフォーマンスは低下しますが(データ・センター間が低速接続の場合)、レプリケーション・サービスが引き続き提供されることが保証されます。1つ以上のローカル・レプリケーション・サーバーがオンラインに復帰すると、ディレクトリ・サーバーは自動的にローカル・レプリケーション・サーバーに再接続します。
Oracle Unified Directoryディレクトリ・サーバーは、特定のサーバーが受信側サーバーからの確認を待たずに連続して一定数の更新リクエストを送信することを指定する、ウィンドウ・メカニズムを提供します。
ウィンドウ・サイズは、受信側サーバーからの即時確認がなくても送信可能な更新メッセージの最大数を表します。待機時間の長いネットワークで接続されている複数のデータ・センターにまたがるトポロジの場合、ウィンドウ・サイズをデフォルト値の100から増やす価値がある可能性があります。ウィンドウ・サイズがレプリケーション・スループットを制限する要因になっているかどうかを評価するには、cn=monitor
の下のcurrent-send-window
属性とcurrent-rcv-window
属性をモニターします。
あるサーバーが定常的に 0 または 0 に近い値のcurrent-send-window
を対応するサーバーにパブリッシュし、そのサーバーがそれより大きい値のcurrent-rcv-window
をパブリッシュしている場合、すべてのデータが現在ネットワーク上に送信されていることを意味します。この場合、受信側サーバーのウィンドウ・サイズを増やすと、レプリケーション速度が向上し、レプリケーション遅延が減るはずです。これらの状況が改善されることで、受信側サーバーのリソース消費量は増加します。