Directory Server の考慮事項

Sun Java System Directory Server は、イントラネット、ネットワーク、およびエクストラネット情報用に、柔軟性のある複数層データストレージを提供します。Directory Server は既存のシステムを統合し、社員、顧客、供給業者、およびパートナー情報を統合する中央リポジトリとして機能します。Directory Server を拡張して、ユーザープロファイルおよび設定とともに、エクストラネットユーザーの認証を管理することができます。

Portal Server、Access Manager、Messaging Server、Calendar Server、Instant Messaging のスキーマなど、すべてのカスタム LDAP スキーマは単一のディレクトリにインストールされます。

ビジネスの目的と予想される使用パターンに応じて、データ環境を設計する数多くの方法と、考慮すべき数多くの要素があります。ディレクトリ設計は次の領域に対処する必要があります。

• ディレクトリスキーマとオブジェクトクラスの定義

• ディレクトリ情報ツリー (DIT)

• グループとメンバーの定義

• 静的および動的ダイナミックグループを含むアクセス制御リスト (ACL) の方針

• フェイルオーバー、レプリケーション、リフェラルを含む高可用性および高パフォーマンス対応のディレクトリアーキテクチャー

• ディレクトリの管理

データ環境を設計する方法に関するこれらの要素や提案の詳細な説明については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

Directory Server と Tier (層) アーキテクチャーの考慮事項

単一層アーキテクチャーから複数層アーキテクチャーへの移行では、まず Directory Server を専用のマシンに「分割」する必要があります。負荷が一定の量を超えると、同じホストの Directory Server と Messaging Server は特有のパフォーマンスの影響を受けます。これは、Messaging Server が Directory Server で動作するように設計されることによります。Directory Server を専用のマシンに分離することが、配備のパフォーマンスを向上させる最初の手順です。

層アーキテクチャーの詳細については、第 5 章「Communications Services 論理アーキテクチャーの開発」を参照してください。

Directory Server は、ディレクトリユーザー管理とソフトウェアアプリケーション設定とを明確に区別してインストールすることが可能です。このアーキテクチャーには 2 つのディレクトリが存在します。1 つはディレクトリホスト上のユーザーおよびグループ用ディレクトリ、もう 1 つは別のホスト上の設定ディレクトリです。ソフトウェアアプリケーション設定の部分を削除する必要がある場合、こうした区別をしておいたほうが、Directory Server から情報を削除する作業が容易になります。

Directory Server のトポロジの考慮事項

単一マシンにインストールした Directory Server のインスタンスに配備を構築することは可能ですが、その他の Communications Services コンポーネントもコアサービスとして機能するディレクトリサーバーに依存します。したがって、通常の配備をするのではなく、冗長性のある可用性の高い構成の Directory Server の配備を計画する必要があります。

Directory Server の可用性を高めるための最初の手順は、マスターディレクトリサーバーのペアを確立することです。次に、マルチマスターレプリケーションを使用して、LDAP の書き込みスループットと可用性を向上させます。Sun Cluster を高可用性配備で使用する場合、2 つの LDAP マスターがクラスタ化されます。詳細については、「Directory Server と高可用性」を参照してください。

Directory Server の容量計画

Directory Server の容量計画には確立された規則はありませんが、パフォーマンス測定基準に適合するかどうかを確認するためにディレクトリサーバーを注意深く監視することは非常に重要です。システムがこれらの測定基準に適合しない場合は、増設ディレクトリコンシューマを追加します。通常、次の点を監視します。

• 負荷のヒット数

• 負荷のキャッシュ数

• 秒あたりの要求数

目標応答時間 (10 ミリ秒) に対する上記測定値を評価します。IOWAIT は 10 ミリ秒を超えてはなりません。また、この層での CPU 利用率の合計が 70% を超えてはなりません。

Directory Server と Calendar Server の相互作用に関する考慮事項

Calendar Server は、Directory Server に格納されるユーザーエントリに対して複数の書き込みを行います。これらの大量の書き込みは、ユーザーが最初に Calendar Server にログインするときとユーザーが特定のアクションを実行するときに発生します。これらのアクションには、カレンダの作成、カレンダへの登録、設定の変更などがあります。これらのアクションを考慮しないと、Directory Master Server に大きな負荷を与える可能性があります。

ディレクトリのレプリケーションを使用する場合、LDAP Master Server は LDAP 複製サーバーにエントリを複製します。Calendar ユーザーがこれらのアクションのいずれかを実行する場合、Calendar Server は Master Directory Server への変更の書き込みだけを行うことができます。これはレプリカが読み取り専用のためです。

2 番目の相互作用に関する考慮事項は、これらの複製されたディレクトリ構造の中にあります。ユーザーが設定を変更する場合、Master Directory Server から Calendar Server が使用する Directory Replica に正しく複製されるまで、これらの変更は正常に表示されません。この応答遅延を防止するために、Calendar Express (cshttpd) がローカルに変更をキャッシュするように設定して、この問題を回避することができます。詳細については、「Calendar Server LDAP データキャッシュの計画」を参照してください。

Directory Server と個人アドレス帳に関する考慮事項

Messenger Express クライアントは、個人アドレス帳 (PAB) の概念をサポートします。これにより、ユーザーは Directory Server に個人用連絡先 (たとえば、業務用連絡先、友人、家族など) を格納することができます。ユーザーの PAB に新しい個人用連絡先が追加されるごとに、Directory Server に書き込みが行われます。これらのアクションを考慮しないと、ディレクトリレプリケーションの方針とは関係なく LDAP Master Server に大きな負荷を与える可能性があります。

User and Group Directory Server 上のパフォーマンスの問題を解決する 1 つの方法は、PAB 情報を別の Directory Server に配置することです。これにより、PAB の相互作用が LDAP Master Server に負荷を配置しなくても済むようになります。

現在の Communications Express クライアントと、非推奨の Messenger Express Web メールインタフェースの両方を実行している場合、これら 2 つのクライアントが使用するアドレス帳は情報を共有しません。2 つのクライアントインタフェースがエンドユーザーによって切り替えられる場合、2 つのアドレス帳には異なるエントリが含まれます。