Sun Java System Directory Server Enterprise Edition 6.1 配備計画ガイド

DIT の下位方向へのデータ分散

多くの場合、DIT の頂点でのデータ分散は必要ありません。ただし、ツリーの上位にあるエントリが、ツリーの分散済み部分にあるエントリによって必要とされる場合があります。この節では、サンプルのシナリオを通して、このようなケースでの分散方針を設計する方法を示します。

分散されるデータの論理ビュー

Example.com には、グループに対応する 1 つのサブツリーと、人に対応する 1 つの独立したサブツリーがあります。グループ定義の数は少なくあまり変化しませんが、人を表すエントリの数は多く、増加し続けます。そのため Example.com では、人のエントリだけを 3 つのサーバーに分散させる必要があります。ただし、people サブツリー下のすべてのエントリにアクセスするには、グループ定義、グループ定義の ACI、およびネーミングコンテキストの最上位に位置する ACI が必要です。

次の図は、データ分散要件の論理ビューを示したものです

図 10–10 分散されるデータの論理ビュー

図では、ou=people 分岐をどのように分散させる必要があるかを示しています。

データ記憶領域の物理ビュー

ou=people サブツリーは、各エントリの sn 属性の先頭文字に従って、3 つのサーバーに分散されます。ネーミングコンテキスト (dc=example,dc=com) および ou=groups コンテナは、各サーバー上の 1 つのデータベースに格納されます。ou=people 下のエントリがこのデータベースにアクセスできます。ou=people コンテナは、このコンテナ専用のデータベースに格納されます。

次の図は、個々の Directory Server 上にデータがどのように格納されるかを示したものです。

図 10–11 データ記憶領域の物理ビュー

図では、分散されるデータの物理記憶領域を示しています。

ou=people コンテナはトップコンテナのサブサフィックスではありません。

サンプル配備シナリオ用の Directory Server 設定

これまでに説明した各サーバーは、分散チャンク (chunk) として理解することができます。ネーミングコンテキストおよび ou=groups 下のエントリを含むサフィックスは、各チャンク上で同じです。したがって、3 つのチャンクのそれぞれにまたがって、このサフィックスに対してマルチマスターレプリケーションアグリーメントを設定します。

また、可用性のために各チャンクはレプリケートされています。したがって、各チャンクに対して少なくとも 2 つのマスターレプリカが定義されています。

次の図は、各チャンクに対して 3 つのレプリカが定義された Directory Server 設定を示しています。簡略化のため、1 つのチャンクに対するレプリケーションアグリーメントのみを示していますが、ほかの 2 つのチャンクに対しても同じアグリーメントが定義されています。

図 10–12 Directory Server 設定

図では、分散されるデータのレプリケーショントポロジを示しています。

サンプル配備シナリオ用の Directory Proxy Server 設定

クライアントによる Directory Proxy Server 経由でのディレクトリデータへのアクセスは「データビュー」を通して提供されます。データビューの詳細は、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 17 章「Directory Proxy Server Distribution」を参照してください。

このシナリオでは、分散される各サフィックスに対して 1 つのデータビューが必要であり、ネーミングコンテキスト (dc=example,dc=com) および ou=groups サブツリーに対して 1 つのデータビューが必要です。

次の図では、分散データへのアクセスを提供するための Directory Proxy Server データビューの設定を示しています。

図 10–13 Directory Proxy Server 設定

図では、分散データ用のデータビュー設定を示しています。

データ増加に関する考慮事項

分散されるデータは、分散アルゴリズムに従って分割されます。使用する分散アルゴリズムを決定するときは、データの分量が変化する可能性があることと、分散方針は拡張性のあるものでなければならないことに留意してください。データの完全な再分散を必要とするようなアルゴリズムを使用しないでください。

たとえば、uid などの数値に基づく分散アルゴリズムは、比較的簡単に拡張できます。uid=0-999 および uid=1000–1999 の 2 つのデータセグメントから開始する場合、uid=2000–2999 という 3 番目のセグメントをあとから追加することは容易です。