複製

同じ情報を複数のディレクトリサービスクライアントが要求した場合、その負荷をいくつかのディレクトリサーバーに分散できます。分散するには、複製（またはスレーブ）サーバーを定義して、ディレクトリサービスへの代替アクセス点をクライアントに提供する必要があります。マスター名前付きコンテキストは、複数の複製名前付きコンテキストを持つことができます。図 1-2 では、1 つのマスターサーバーに 2 つの複製サーバーがあります。「複製」の処理では、マスターデータ格納の変更がすべての複製名前付きコンテキストに反映されます。複製は、名前付きコンテキスト全体、サブツリー、または特定のエントリの単位で実行できます。さらに、エントリの内容全体または属性の一部を複製できます。

図 1-2 マスタサーバーと複製サーバー

複製の機能には、次の利点があります。

• 一部のトラフィックが他のサーバーへ転送されるため、マスタサーバーの負荷が減る。

• データのコピーを最もよく使われる場所に格納できるため、ネットワークトラフィックが減る。

• データのコピーをいくつも格納できるが、データ自体は中央の場所から保守される。

• 複製サーバーのクライアントの要件が十分わかっている場合は、クライアントが必要とするデータだけを複製すればよい。つまり、特定クライアントの必要に合わせて複製を調整できる。複製するエントリ数が少なくなるため、複製の更新によって生ずるネットワークトラフィックが減少する。

• 秘密でない情報を持つ「公共」複製サーバーを維持すれば、通常の他のサーバーより頻繁にこの情報がアクセスされる。たとえば、将来の製品を開発する研究スタッフを除いて、現在の製品を扱う販売スタッフとサポートスタッフの電子メールアドレスを含めたサーバーを作成すれば、このサーバーを取引先企業の販売スタッフに公開できる。

同じディレクトリ情報の一部に、ユーザーごとに異なるアクセス制御を設定することもできます。ただし、専用のマシン上に部分的な複製を作成すれば、ネットワーク全体にアクセスされることはありません。さらにセキュリティを強化するには、複製の更新の間だけ複製サーバーをネットワークに接続することもできます。

複製を使用する場合、次の問題点があります。

• データの複製によってネットワークトラフィックが増える。しかし、全体的なトラフィックは増えても、トラフィックの多くはローカルなので、照会トラフィックのボトルネックがわかっていれば避けることができる。さらに、ネットワークが混んでいないときを選んで複製を更新できる。

• 更新より後に複製が行われていないと、複製から検索したデータが最新ではないことがある。したがって、アプリケーションによっては、常にマスターデータ格納を照会する必要がある。

• 複製を変更できない。すべての更新は、エントリのマスターコピーに対して行わなければならない。