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