パート II 技術要件

技術要件分析は、ソリューションライフサイクルのビジネス分析フェーズの間に作成されるビジネス要件ドキュメントから始まります。ビジネス分析を使用して、使用状況分析を実施します。この分析は、予測される負荷条件を特定したり、システムとユーザーの一般的な対話をモデル化するユースケースを作成したりするために役立ちます。この分析は、一連の品質サービス要件を作成するときにも役立ちます。これらの要件は、配備されるソリューションが、応答時間、可用性、セキュリティーなどの領域で満たさなければならない基準を定義します。

この第 2 部では、Directory Server Enterprise Edition の配備に対して定義する必要のある技術要件について説明します。次の章から構成されています。

• 第 3 章「Directory Server Enterprise Edition の使用分析」では、使用状況分析の要件について説明します。

• 第 4 章「データ特性の定義」では、データ要件の定義方法について説明します。

• 第 5 章「サービスレベル契約の定義」では、サービス品質要件について説明します。

• 第 6 章「システム特性のチューニングとハードウェアサイジング」では、Directory Server Enterprise Edition のシステム要件について説明します。

• 第 7 章「セキュリティー要件の特定」では、セキュリティー要件について説明します。

• 第 8 章「管理と監視の要件の特定」では、設計時に行う必要がある管理面の決定について説明します。

第 3 章 Directory Server Enterprise Edition の使用分析

使用分析では、システムのユーザーを特定し、それらのユーザーの使用パターンを決定します。使用分析ではそうすることで、予期されるディレクトリサービスの負荷条件を決定できます。

使用分析の要因

サーバーをどのように配備するかは、なぜ、Sun Java System Directory Server Enterprise Edition をアイデンティティー管理ソリューションとして提供するのかという理由と密接に関連します。

使用分析時には、可能であれば常にユーザーへのインタビューを行います。既存データを調査して使用パターンを決定し、開発者や管理者に以前のシステムについてのインタビューを行います。使用分析では、第 5 章「サービスレベル契約の定義」で説明するサービス要件の決定を可能にするようなデータを提供すべきです。

使用分析から得られるべき情報は、次のとおりです。

• クライアントアプリケーションの数と種類:配備がサポートする必要のあるクライアントアプリケーションの数を特定し、必要であればそれらのアプリケーションを分類します。

• 管理ユーザー:ディレクトリにアクセスしてその配備を監視、更新、サポートするユーザーを特定します。ファイアウォールの外側から配備を管理するなど、技術要件に影響する可能性のあるすべての特定の管理使用パターンを決定します。

• 使用パターン:各種アプリケーションのシステムへのアクセス方法を特定し、予期される使用法に対する目標値を定めます。

  たとえば、次の質問に答えてください。

  • 使用量が最高になる時間帯が存在するか。

  • 通常の業務時間帯。

  • クライアントアプリケーションがグローバルに分散配置されるか。

  • アプリケーション接続の予期される持続時間。

• クライアントアプリケーションの増大:クライアントアプリケーションの数は固定されるか、あるいは増大することが予期されるかを決定します。アプリケーションが追加されることが予期される場合は、どれくらい増大するかを妥当な範囲で見積もってみてください。

• アプリケーショントランザクション:サポートする必要のあるトランザクションの種類を特定します。

  それらのトランザクションはユースケースに分類できます。次に例を示します。

  • アプリケーションによってどのようなタスクが実行されるか。

  • アプリケーションがディレクトリにバインドしたあと、そのバインドがそのまま維持されるか、あるいはいくつかのタスクを実行してから解除されるか。

• 調査書や統計データ:既存の調査書やその他のリソースに基づいてアプリケーションの動作パターンを決定します。企業や業界組織はしばしば研究調査書を所有していますが、そうした調査書からは、ユーザーやクライアントアプリケーションに関する有用な情報を抽出できます。既存のアプリケーションのログファイルには、システムの見積もりに役立つ統計データが含まれている可能性があります。

使用分析の詳細については、『Sun Java Enterprise System 配備計画ガイド』を参照してください。

第 4 章 データ特性の定義

ディレクトリに格納するデータの種類によって、ディレクトリの構造、データにアクセスできるユーザー、およびアクセス権限の付与方法が決定されます。特によく利用されるデータの種類には、ユーザー名、電子メールアドレス、電話番号、ユーザーが所属するグループについての情報などがあります。

この章では、データを検索、分類、構造化、および整理する方法について説明します。また、Directory Server のスキーマにデータをマップする方法についても説明します。この章の内容は次のとおりです。

• 「データソースと所有者の設定」

• 「異なるデータソースからのデータの特定」

• 「ディレクトリ情報ツリーを使用したデータの構造化」

• 「ディレクトリデータのグループ化と属性の管理」

• 「ディレクトリスキーマの設計」

• 「その他のディレクトリデータ関連資料」

データソースと所有者の設定

既存のデータを分類する最初のステップでは、データがもともとどこに存在していたものか、またそのデータの所有者がだれであるかを特定します。

データソースの特定

ディレクトリに含めるデータを特定するには、既存のデータソースの位置を特定して分析します。

• 情報を提供する組織を特定する。

  企業にとって重要な情報を管理している組織をすべて特定します。通常、これらの組織には、情報サービス部、人事部、給与計算部、および経理部が含まれます。

• 情報のソースであるツールとプロセスを特定する。

  情報の一般的なソースには、次のものがあります。

  • Windows、Novell Netware、UNIX® NIS などのネットワークオペレーティングシステム

  • 電子メールシステム

  • セキュリティーシステム

  • PBX (構内交換機) または電話交換システム

  • 人事アプリケーション

• データの集中化が各データに与える影響を判定する。

  集中データ管理では、新しいツールとプロセスが必要になることがあります。集中化によって、ある組織のスタッフを増員してほかの組織のスタッフを減らすことが必要になる場合は、問題が生じる可能性もあります。

データ所有者の決定

「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザーを決めておきます。データの所有者を決めるには、一般に次の規則に従います。

• ディレクトリの内容を管理する少人数のマネージャーグループを除くすべてのユーザーに対して、ディレクトリへの読み取り専用アクセスを許可する。

• 各ユーザーが自分自身に関する重要な情報を管理できるようにする。

  このような情報には、ユーザーのパスワード、ユーザー自身についての説明的情報、組織内でのユーザーのロールなどがあります。

• 人に関する重要な情報 (連絡先情報や役職など) を上司が書き込めるようにする。

• 組織の管理者がその組織に関するエントリを作成および管理できるようにする。

  これにより、実質的に組織の管理者が、ディレクトリ内容の管理者にもなります。

• グループ内のユーザーに読み取りアクセス権または書き込みアクセス権を与えるロールを作成する。

  たとえば、人事、財務、経理などのロールを作成します。これらのロールごとに、そのグループが必要とするデータへの読み取りアクセス権、書き込みアクセス権、またはその両方を許可します。このようなデータには、給与情報、政府指定の ID 番号、自宅の電話番号と住所などがあります。

  ロールとエントリのグループ化の詳細は、「ディレクトリデータのグループ化と属性の管理」、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 10 章「Directory Server のグループ、ロール、および CoS」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」を参照してください。

データに書き込みを許可するユーザーを決定するときに、複数のユーザーに対して同じデータへの書き込み権限が必要になることがあります。たとえば、情報システムまたはディレクトリ管理グループには、従業員のパスワードへの書き込み権限を許可するのが一般的です。同時に、すべての従業員にも自分自身のパスワードへの書き込み権限を許可する場合があります。複数のユーザーに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に特定できるようにします。グループを少人数にすることは、データの完全性の保証に役立ちます。

ディレクトリのアクセス制御の設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 7 章「Directory Server のアクセス制御」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「How Directory Server Provides Access Control」を参照してください。

ユーザーデータと設定データの区別

Directory Server やその他の Java Enterprise System サーバーを設定するために使用するデータと、ディレクトリに格納される実際のユーザーデータを区別するには、次の手順に従います。

• ユーザーデータと設定データのそれぞれに対して、異なるバックアップ方針を用意します。

• ユーザーデータと設定データのそれぞれに対して、異なる高可用性基準を用意します。

• 設定サーバーをすみやかにシャットダウンし、復元し、再起動します。

• ほかの Directory Server インスタンスの保守を実行している間、設定サーバーの稼働を維持します。

異なるデータソースからのデータの特定

データソースを特定するときは、従来のデータソースを含め、ほかのデータソースからのデータを必ず含めるようにしてください。このデータはディレクトリに格納されていない場合もあります。ただし、Directory Server がデータについて何らかの情報を持っている、またはデータを制御できることが必要な場合があります。

Directory Proxy Server には、複数のデータリポジトリからリアルタイムで情報を集約する「仮想ディレクトリ」機能が用意されています。このようなリポジトリには、LDAP ディレクトリ、JDBC 仕様に準拠するデータ、LDIF フラットファイルなどがあります。

仮想ディレクトリは、複数の異なるデータソースからの属性を処理する複合フィルタをサポートします。また、複数の異なるデータソースからの属性を結合する変更もサポートします。

データ分析フェーズの間、複数のアプリケーションが同じデータを異なる形式で必要とすることが判明する場合があります。このような情報 (データ) については、複製するのではなく、アプリケーションの側でそれぞれの要件に合わせて変換させるのが適切な方法です。

ディレクトリ情報ツリーを使用したデータの構造化

ディレクトリ情報ツリー (DIT) は、ディレクトリデータを構造化し、クライアントアプリケーションからデータを参照できるようにするための手段です。DIT は、ディレクトリデータの分散、レプリケート、アクセス制御の方法など、その他の設計判断と緊密に連携します。

DIT の用語

適切に設計された DIT は、次のような利点をもたらします。

• ディレクトリデータの管理を簡単にする

• レプリケーションポリシーとアクセス制御の作成における柔軟性

• ディレクトリを使用するアプリケーションをサポートする

• ユーザーが簡単にディレクトリを操作できるようにする

DIT の構造は、階層型の LDAP モデルに従います。DIT では、たとえば、グループ、ユーザー、あるいは場所ごとにデータを編成できます。また、ディレクトリツリーによって複数のサーバー間でどのようにデータを分散して配置するかが決まります。

DIT の設計は、レプリケーション設定や、Directory Proxy Server を使用してデータを分散させる方法に影響を及ぼします。DIT の特定部分をレプリケートまたは分散する場合は、レプリケーションおよび Directory Proxy Server の要件について設計時点で検討します。また、分岐点にアクセス制御を適用する必要があるかどうかについても設計時に検討します。

DIT はサフィックス、サブサフィックス、および連鎖サフィックスによって定義されます。「サフィックス」とは分岐またはサブツリーであり、サフィックスの内容全体が管理タスクの単位として扱われます。インデックス生成はサフィックス全体に対して定義され、サフィックス全体を 1 回の操作で初期化できます。サフィックスは通常、レプリケーションの単位でもあります。同じ方法でアクセスおよび管理するデータは、同じサフィックスに格納する必要があります。サフィックスは、「ルートサフィックス」と呼ばれるディレクトリツリーのルートに配置することもできます。

データはサフィックスレベルのみで分割できるため、複数のサーバー間でデータを分散するには、適切なディレクトリツリー構造が必要です。

次の図は、2 つのルートサフィックスを持つディレクトリを示しています。各サフィックスは独立した企業エンティティーを表します。

図 4–1 単一 Directory Server 内の 2 種類のルートサフィックス

サフィックスは、他のサフィックスの分岐となることもできます。その場合は「サブサフィックス」と呼ばれます。親サフィックスには、管理操作のためのサブサフィックスの内容は含まれません。サブサフィックスはその親とは別個に管理されます。LDAP 操作の結果にはサフィックスに関する情報は含まれないため、ディレクトリクライアントは、エントリがルートサフィックスの一部であるか、サブサフィックスの一部であるかを認識できません。

次の図に、大規模な企業エンティティーに対して、単一のルートサフィックスと複数のサブサフィックスを配置したディレクトリを示します。

図 4–2 複数のサブサフィックスを持つ単一のルートサフィックス

サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースとそのファイルはサーバーによって内部的に管理され、データベースの用語は使用されません。

連鎖サフィックスは、仮想 DIT を作成して、別のサーバー上にあるサフィックスを参照します。Directory Server は、連鎖サフィックスを使用してリモートサフィックスに対する操作を実行します。ディレクトリはその後、操作がローカルで実行された場合と同じように結果を返します。データの位置は透過的です。クライアントの側では、サフィックスが連鎖されている、またデータがリモートサーバーから取得されているという認識はありません。あるサーバー上のルートサフィックスが、別のサーバーに連鎖されているサブサフィックスを持つ場合があります。この場合、クライアントは単一のツリー構造を認識します。

カスケード型連鎖の場合、連鎖サフィックスはリモートサーバー上などの別の連鎖サフィックスを参照することがあります。各サーバーは操作を転送し、最終的にクライアントの要求を処理するサーバーへ結果を返します。

DIT の設計

DIT の設計では、データを格納するサフィックスの選択、データエントリ間の階層関係の決定、DIT 階層内のエントリのネーミングを行います。次に、設計の各段階について詳しく説明します。

サフィックスの選択

サフィックスは、DIT のルートにあるエントリの名前です。共通のルートを持たない DIT が 2 つ以上ある場合、複数のサフィックスを使用できます。デフォルトの Directory Server のインストールには、複数のサフィックスが含まれています。1 つのサフィックスはユーザーデータの格納に使用されます。その他のサフィックスは、設定情報やディレクトリのスキーマなど、内部的なディレクトリ操作に必要なデータの格納に使用されます。

ディレクトリ内のすべてのエントリは、共通のベースエントリ (サフィックス) の下に格納する必要があります。各サフィックス名は次のように指定する必要があります。

• グローバルに一意の名前にする

• 変更しない、または名前をまれにしか変更しないようにする

• そのサフィックスの下にあるエントリがオンラインで読みやすいように短い名前にする

• ユーザーが容易に入力および記憶できるものにする

一般的には、企業のドメイン名を識別名 (DN) にマップすることがベストプラクティスと考えられています。たとえば、example.com というドメイン名を持つ企業は「dc=example,dc=com」という DN を使用します。

DIT 構造の作成とエントリのネーミング

DIT の構造は、フラットまたは階層型から選択できます。フラットツリーのほうが管理が容易ですが、データのパーティション分割、レプリケーション管理、およびアクセス制御のために、ある程度の階層が必要な場合もあります。

分岐点とネーミングの考慮事項

「分岐点」とは、DIT の内部で新しいサブ区分を定義するポイントのことです。分岐点を決定するときは、問題が生じる可能性のある名前の変更は避けてください。名前を変更する確率は、名前が変更される可能性があるコンポーネントが、ネームスペース内に多く含まれているほど高くなります。DIT の階層が深いほどネームスペース内のコンポーネントは多くなり、名前を変更する確率が高くなります。

分岐点を定義および命名するときは、次のガイドラインを使用します。

• 企業組織内でもっとも大きい部門区分のみを表すようにツリーを分岐させます。

  分岐点を部門 (企業情報サービス、カスタマサポート、販売、プロフェッショナルサービスなど) に限定します。部門が安定していることを確認します。企業で組織変更が頻繁に行われる場合は、この種の分岐を実行しないでください。

• 組織の実際の名前ではなく、機能を表す名前または一般的な名前を使用します。

  組織名は変更される可能性があり、企業で部門の名前を変更するたびに DIT の変更が必要になるのは問題です。代わりに、組織の機能を表す一般的な名前を使用します。たとえば、「Widget 研究開発」ではなく「エンジニアリング」を使用します。

• 似たような機能を持つ組織が複数ある場合は、部門の構成に基づいて分岐点を作成するのではなく、その機能を表す分岐点を 1 つ作成します。

  たとえば、特定の製品ラインを担当する複数のマーケティング部門がある場合でも、1 つのマーケティングサブツリーのみを作成します。すべてのマーケティングエントリは、そのツリーに所属させます。

• 次の表に示した、従来からある分岐点属性のみを使用するようにします。

  従来からある属性を使用すると、サードパーティーの LDAP クライアントアプリケーションとの互換性が保たれる可能性が高くなります。加えて、従来からある属性はデフォルトのディレクトリスキーマにとって既知であるため、分岐識別名 (DN) のエントリの構築が簡略化されます。

• ディレクトリに格納されるデータの種類に応じた分岐を行います。

  たとえば、人、グループ、サービス、およびデバイスのそれぞれに対応する独立した分岐を作成します。

分岐点の属性を選択するときは、整合性を保つようにしてください。DIT 全体で DN の形式が統一されていないと、一部の LDAP クライアントアプリケーションで問題が発生する可能性があります。DIT のある部分で l (localityName) が o (organizationName) の下位にある場合、必ず、ディレクトリのその他すべての部分でも l が o の下位にあるようにしてください。

レプリケーションに関する検討事項

DIT を設計するときは、どのエントリがほかのサーバーにレプリケートされるかを考慮します。エントリの特定グループを同じサーバー集合にレプリケートする場合、それらのエントリを特定のサブツリー下に配置することをお勧めします。レプリケートするエントリの集合を記述するには、サブツリーの頂点で DN を指定します。エントリのレプリケーションの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」を参照してください。

アクセス制御に関する検討事項

DIT 階層では、特定のタイプのアクセス制御を有効にできます。レプリケーションの場合と同様に、類似したエントリをグループ化したり、エントリを 1 つの分岐から管理したりすることがさらに容易になります。

また、DIT 階層で管理を分散させることもできます。たとえば、DIT を使用して、マーケティング部門の管理者にはマーケティング関連エントリへのアクセス権を付与し、セールス部門の管理者にはセールス関連のエントリへのアクセス権を付与することができます。

DIT ではなくディレクトリの内容に基づいてアクセス制御を設定することもできます。ACI でフィルタされたターゲット機構を使用して、単一のアクセス制御規則を定義します。この規則では、1 つのディレクトリエントリが、特定の属性値を含むすべてのエントリにアクセスできることを記述します。たとえば、ou=Sales という属性を含むすべてのエントリへのアクセス権を営業部の管理者に与える ACI フィルタを設定できます。

ただし、ACI フィルタは管理が簡単ではありません。対象のディレクトリにもっとも適したアクセス制御方法を決定する必要があります。DIT 階層で組織に対応した分岐を作成する、ACI フィルタを適用する、あるいはこの両者を組み合わせる、などの方法から選択します。

ディレクトリデータのグループ化と属性の管理

ディレクトリ情報ツリーは、エントリを階層構造で構成します。この階層は、グループ化メカニズムの 1 種です。この階層は、分散しているエントリの関連付け、頻繁に変更される組織、または多数のエントリで繰り返されるデータには適していません。Directory Server のグループとロールは、エントリ間のより柔軟な関連付けを提供します。サービスクラス (CoS) のメカニズムを使用すると、属性がエントリ間で共有されるように各属性を管理できます。この共有は、アプリケーションには見えない方法で実行されます。

これらのエントリのグループ化と属性管理のメカニズムは、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」で詳細に説明されています。

ここでは、管理戦略の設計には十分なグループ化メカニズムの概要について説明します。ただし、このメカニズムの動作の仕組みや、それらの設定方法については説明していません。

この節は、次の項目で構成されています。

• 「スタティックグループ、ダイナミックグループ、および入れ子のグループ」

• 「管理されているロール、フィルタを適用したロール、入れ子のロール」

• 「グループとロールのどちらを使用するかの決定」

• 「サービスクラスによる属性の管理」

スタティックグループ、ダイナミックグループ、および入れ子のグループ

Directory Server は、スタティックグループ、ダイナミックグループ、および入れ子のグループを識別します。

グループが識別するメンバーはディレクトリ内のどこに配置してもかまいませんが、グループ定義自体は ou=Groups のように適切な名前が付けられたノードに配置するようにします。このようにすることで、バインド資格がグループのメンバーである場合にアクセス権を付与または制限するアクセス制御命令 (ACI) を定義するときなどに、グループ定義を簡単に見つけることができます。

スタティックグループ

スタティックグループは、メンバーエントリの名前を明示的に指定します。たとえば、次の図のように、ディレクトリ管理者のグループにはグループを構成する特定のユーザーの名前が指定されます。

次の LDIF の抜粋は、このスタティックグループのメンバーが定義される方法を示しています。

dn: cn=Directory Administrators, ou=Groups, dc=example,dc=com
...
member: uid=kvaughan, ou=People, dc=example,dc=com
member: uid=rdaugherty, ou=People, dc=example,dc=com
member: uid=hmiller, ou=People, dc=example,dc=com

ダイナミックグループ

ダイナミックグループはフィルタを指定し、そのフィルタと一致するすべてのエントリがグループのメンバーとなります。このようなグループは、フィルタが評価されるたびにメンバーが定義されるため、ダイナミックグループと呼ばれます。

たとえば、すべての管理職とそのアシスタントがビルの 3 階におり、各社員の部屋番号がその階の数字で始まるとします。3 階にいる社員のみを含むグループを作成するのであれば、次の図のように、部屋番号を使用してそれらの社員だけを定義することができます。

次の LDIF の抜粋は、このダイナミックグループのメンバーが定義される方法を示しています。

dn: cn=3rd Floor, ou=Groups, dc=example,dc=com
...
memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)

入れ子のグループ

入れ子のグループでは、別のグループの DN をスタティックまたはダイナミックグループの uniqueMember 属性として使用して、他のグループの内部にグループを配置します。Directory Server では、個々のエントリ、スタティックグループ、およびダイナミックグループを参照する混合グループもサポートしています。

たとえば、すべてのディレクトリ管理者、およびすべての管理職とそのアシスタントを含むグループを作成するとします。この場合、先ほど定義した 2 つのグループの組み合わせを使用して、次の図のように 1 つの入れ子のグループを作成することができます。

次の LDIF の抜粋は、この入れ子のグループのメンバーが定義される方法を示しています。

dn: cn=Admins and 3rd Floor, ou=Groups, dc=example,dc=com
...
member: cn=Directory Administrators, ou=Groups, dc=example,dc=com
member: cn=3rd Floor, ou=Groups, dc=example,dc=com

入れ子のグループはグループ化の手法として必ずしも効率的ではありません。ダイナミックな入れ子のグループには、非常に大きなパフォーマンスコストが必要となります。このようなパフォーマンス上の問題を避けるために、グループではなくロールの使用を考慮してください。

管理されているロール、フィルタを適用したロール、入れ子のロール

ロールは、エントリのグループ化メカニズムです。ロールを使用すると、エントリがディレクトリから取得されるとすぐに、ロールのメンバーシップを決定できます。各ロールはメンバー (そのロールを所有するエントリ) を持ちます。グループと同じようにロールのメンバーを明示的またはダイナミックに指定できます。

Directory Server は、次の 3 種類のロールをサポートしています。

• 管理されているロール: 明示的にメンバーエントリにロールを割り当てる。

• フィルタを適用したロール: エントリが指定された LDAP フィルタに一致した場合は、それらのエントリを自動的にメンバーにする。このため、ロールは各エントリに含まれている属性に依存する。

• 入れ子のロール: ほかのロールを含むロールを作成できる。

グループとロールのどちらを使用するかの決定

グループとロールのメカニズムは、一部の機能が重なっています。どちらのメカニズムにも利点と欠点があります。一般に、ロールメカニズムのほうが、頻繁に必要となる機能を効率的に提供できるように設計されています。グループ化メカニズムはサーバーの複雑さに影響を及ぼし、グループ化メカニズムを選択することで、クライアントがどのようにメンバー情報を処理するかが決まるため、グループ化メカニズムは慎重に計画する必要があります。どちらのメカニズムがより適しているかを判断するには、実行する標準的なメンバーシップクエリーと管理操作を理解してください。

グループメカニズムの利点

グループには、次の利点があります。

• スタティックグループは、標準に準拠した唯一のグループ化メカニズムである。そのため、スタティックグループは、ほとんどのクライアントアプリケーションおよび LDAP サーバーと相互運用できます。

• メンバーを列挙するには、ロールよりスタティックグループの方が適している。

  特定のセットのメンバーを列挙するだけでよい場合は、スタティックグループの方がコストが低くなります。member 属性を取得してスタティックグループのメンバーを列挙することは、同じロールを共有するすべてのエントリを調べるより簡単です。Directory Server では、多くの値を持つ複数値属性に対して大幅なパフォーマンス強化が実現されています。特にスタティックグループとの関連では、これらの属性に対する等価照合や変更操作が大幅に機能強化されています。また、グループエントリに対するメンバーシップのテストも機能強化されています。これらの機能強化によって、スタティックグループに対して以前あった制限の一部 (特にグループサイズに対する制限) が解消されています。

  また、Directory Server では isMemberOf オペレーショナル属性をユーザーエントリに直接指定することで、そのユーザーがどのグループのメンバーであるかを明示できます。この機能はスタティックグループのみに適用されますが、入れ子のグループも含まれます。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「グループの管理」を参照してください。

• メンバーの割り当てや削除などの管理操作には、ロールよりスタティックグループが適している。

  スタティックグループは、ユーザーをセットに割り当てたり、ユーザーをセットから削除したりするためのもっとも単純なメカニズムです。ユーザーをグループに追加するために、特殊なアクセス権は必要ありません。

  グループエントリを作成する権限があると、そのグループにメンバーを割り当てる権限が自動的に与えられます。これは、管理されているロールやフィルタを適用したロールには当てはまりません。これらのロールでは、管理者が、ユーザーエントリに nsroledn 属性を書き込むための権限も持っている必要があります。アクセス権に関する同じ制約が、入れ子のロールにも間接的に適用されます。入れ子のロールを作成するには、入れ子の対象となるすでに定義されているほかのロールに対する権限が必要となります。

• フィルタベースの ACI で使用するには、ロールよりダイナミックグループが適している。

  ACI でのバインドルールの指定など、フィルタに基づいてすべてのメンバーを検索するだけの場合は、ダイナミックグループを使用します。フィルタを適用したロールはダイナミックグループと似ていますが、ロールメカニズムを起動して nsRole 仮想属性を生成します。クライアントが nsRole 値を必要としない場合は、ダイナミックグループを使用してこの計算のオーバーヘッドを回避します。

• 既存のセットに対してセットの追加や削除を行うときは、ロールよりグループが適している。

  あるセットを既存のセットに追加したり、あるセットを既存のセットから削除する場合は、グループメカニズムがもっとも単純です。グループメカニズムには、入れ子の制限がありません。ロールメカニズムでは、他のロールを受け入れられるのは入れ子のロールに限られています。

• エントリのグループ化範囲の柔軟性が重要になる場合は、ロールよりグループが適している。

  グループのメンバー範囲は、グループ定義エントリの場所に関係なくディレクトリ全体であるため、範囲の面ではグループには柔軟性があります。ロールでも、特定のサブツリーを超えて範囲を拡張することができますが、入れ子のロールに範囲拡張属性 nsRoleScopeDN を追加することでしか実現できません。

ロールメカニズムの利点

ロールには、次の利点があります。

• セットのメンバーを列挙し、かつ特定のエントリがメンバーになっているすべてのセットを検索する場合は、ダイナミックグループよりロールの方が適している。スタティックグループでも、isMemberOf 属性によってこの機能を提供しています。

  ロールはメンバーシップ情報をユーザーエントリにプッシュします。そこでこの情報をキャッシュできるので、以後のメンバーシップのテストをより効率的に行えます。サーバーがすべての計算を実行し、クライアントは nsRole 属性の値を読み取るだけです。さらに、この属性にすべてのタイプのロールが含まれ、クライアントはすべてのロールを均等に処理できます。ダイナミックグループよりもロールの方が、両方の処理をより効率よく実行でき、クライアント側での処理が簡単になります。

• CoS、パスワードポリシー、アカウントの無効化、ACI など、Directory Server の既存の機能とグループ化メカニズムを統合する場合は、グループよりロールが適している。

  セットのメンバーシップをサーバーで「自然に」使用する場合は、ロールの方が優れたオプションです。ロールを利用するということは、サーバーが自動的に実行するメンバーシップの計算方法を使用することを意味します。ロールは、リソース指向の ACI で、CoS のベースとして、より複雑な検索フィルタの一部として、さらにパスワードポリシーやアカウントの無効化などに使用することができます。グループを使用してこのような統合を行うことはできません。

ロールに対するアクセス権の制限

ロールを使用する場合は、次の問題に注意してください。

• nsRole 属性を割り当てることができるのはロールメカニズムだけです。この属性は、どのディレクトリユーザーも割り当てたり、変更したりできませんが、どのディレクトリユーザーも「読み取れる」可能性があります。この属性が、不正なユーザーから読み取られないようにするには、アクセス制御を定義してください。

• nsRoleDN 属性は、管理されているロールのメンバーシップを定義します。ユーザーがロールに自分自身を追加したり削除したりできるかどうかを決定してください。自分のロールを変更できないようにするには、そのための ACI を定義してください。

• フィルタを適用したロールは、ユーザーエントリ内の属性の存在または値に基づくフィルタを介してメンバーシップを決定します。フィルタを適用したロール内のメンバーシップを定義できるユーザーを制御するには、これらの属性のユーザーアクセス権を慎重に割り当ててください。

サービスクラスによる属性の管理

サービスクラス (CoS) メカニズムを使用すると、エントリ間で属性を共有できます。ロールメカニズムと同様に、エントリが検出されると、CoS がそのエントリに対して仮想属性を生成します。CoS はメンバーを定義しませんが、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。CoS の値は、それらの値が要求されたときに動的に計算されます。CoS 機能や、CoS のさまざまな種類については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference 』で詳細に説明されています。

以降の節では、パフォーマンスの低下を回避しながら、CoS 機能を意図したとおりに使用する方法について詳しく説明します。

• 「多数のエントリが同じ値を共有する場合の CoS の使用」

• 「エントリが自然な関係を持っている場合の CoS の使用」

• 「過剰な CoS 定義の回避」

CoS の生成は、常にパフォーマンスに影響します。実際に必要とするより多くの属性を検索するクライアントアプリケーションによって、この問題がさらに悪化する可能性があります。

クライアントアプリケーションの記述方法を指示できる場合は、実際に必要な属性値のみを検索するようにクライアントアプリケーションを記述することで、パフォーマンスの大幅な向上が期待できることを開発者に伝えてください。

多数のエントリが同じ値を共有する場合の CoS の使用

CoS は、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。

たとえば、ou=People の下のすべてのユーザーエントリに companyName 属性が含まれている、MyCompany, Inc. のディレクトリを考えてみます。請負業者のエントリには companyName 属性に直接値がセットされていますが、すべての正社員の companyName には、CoS で生成された値 MyCompany, Inc. がセットされています。次の図は、この例でポインタ CoS を使用した場合を示しています。CoS によって、すべての正社員の companyName 値が生成されるが、請負業者の従業員用に直接設定されている実際の companyName 値は置き換えられないことに注意してください。会社名は、companyName が許可された属性になっているエントリに対してのみ生成されます。

図 4–3 ポインタ CoS を使用した CompanyName の生成

多数のエントリが同じ値を共有する場合は、ポインタ CoS が特にうまく機能します。正社員に対する companyName の管理が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー (DIT) は、一般的な特性を共有するエントリをまとめる傾向があります。深い DIT でポインタ CoS を使用すると、ツリー内の適切な分岐に CoS 定義を配置することによって、一般的な属性値を生成できます。

エントリが自然な関係を持っている場合の CoS の使用

CoS はまた、ディレクトリデータが自然な関係を持っている場合も、データ管理の大きな利点を提供します。

すべての従業員にマネージャーがいる企業ディレクトリを考えてみます。すべての従業員がメールストップと Fax 番号を、もっとも近い管理アシスタントと共有しています。図 4–4 は、間接 CoS を使用して、マネージャーのエントリから部門番号を取得する様子を示しています。図 4–5 では、メールストップと Fax 番号が管理アシスタントのエントリから取得されています。

図 4–4 間接 CoS を使用した DepartmentNumber の生成

この実装では、マネージャーのエントリに departmentNumber の実際の値が含まれ、生成されているどの値よりもこの実際の値が優先されます。Directory Server は、CoS で生成された属性値からは属性値を生成しません。そのため、図 4–4 の例では、部門番号の属性値をマネージャーのエントリ上でのみ管理する必要があります。同様に、図 4–5 に示されている例では、メールストップと Fax 番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。

図 4–5 間接 CoS を使用したメールストップと Fax 番号の生成

単一の CoS 定義エントリを使用して、このような関係をディレクトリ内のさまざまなエントリに利用できます。

別の自然な関係に、サービスレベルがあります。顧客にスタンダード、シルバー、ゴールド、およびプラチナのパッケージを提供しているインターネットサービスプロバイダを考えてみます。顧客のディスク割り当て、メールボックスの数、前払いのサポートレベルに対する権限などは、購入したサービスレベルによって異なります。次の図は、クラシック CoS スキーマによってこの機能が可能になるようすを示しています。

図 4–6 クラシック CoS を使用したサービスレベルデータの生成

1 つの CoS 定義が複数の CoS テンプレートエントリに関連付けられる場合があります。

過剰な CoS 定義の回避

Directory Server は、1 つのクラシック CoS 定義エントリが複数の CoS テンプレートエントリに関連付けられている場合は CoS を最適化します。Directory Server は、多数の CoS 定義が適用される可能性がある場合は CoS を最適化しません。代わりに、Directory Server は各 CoS 定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千の CoS 定義が存在する場合はパフォーマンスの問題が発生します。

この状況は、図 4–6 で示した例に変更がある場合に発生する可能性があります。顧客に、各顧客のサービスレベルの委任管理を提供しているインターネットサービスプロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールド、およびプラチナのサービスレベルの定義エントリが提供されます。顧客数が 1000 に増えると、1000 個のクラシック CoS 定義が作成されることになります。どの定義が適用されるを判定するために 1000 個の CoS 定義のリストがチェックされるため、Directory Server のパフォーマンスが影響を受ける可能性があります。この種の状況で CoS を使用する必要がある場合は、間接 CoS を検討してください。間接 CoS では、顧客のエントリによって、その顧客のサービスクラス割り当てを定義するエントリが特定されます。

1 つまたは 2 つのターゲットエントリごとに別の CoS スキーマを選択することの限界に近づき始めたら、実際の値を更新することをお勧めします。CoS で生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。

ディレクトリスキーマの設計

ディレクトリスキーマは、ディレクトリに格納できるデータの種類を記述します。スキーマ設計により、個々のデータ要素が LDAP 属性にマップされます。関連する要素は LDAP オブジェクトクラスにまとめられます。適切に設計されたディレクトリスキーマは、データ値のサイズ、範囲、および形式を制限することによって、データの整合性の維持に役立ちます。ディレクトリに含めるエントリの種類と、各エントリで使用できる属性を決定します。

Directory Server に付属の定義済みスキーマには、Internet Engineering Task Force (IETF) 標準の LDAP スキーマが含まれます。このスキーマには、サーバーの機能をサポートするための、アプリケーション固有の追加スキーマが含まれます。また、Directory Server 固有のスキーマ拡張も含まれています。定義済みのスキーマは大半のディレクトリの要件を満たしますが、対象のディレクトリに固有のニーズに対応するために、このスキーマを拡張して新しいオブジェクトクラスと属性を追加することが必要な場合もあります。

スキーマ設計のプロセス

スキーマ設計では、次のことを行う必要があります。

• デフォルトスキーマへのデータのマッピング

  既存のデータをデフォルトスキーマにマップするには、各データ要素が記述するオブジェクトの種類を識別してから、類似のオブジェクトクラスをデフォルトスキーマから選択します。group、people、organization などの共通オブジェクトクラスを使用します。データ要素にもっとも一致するオブジェクトクラスから、類似の属性を選択します。

• 一致しないデータを特定します。

• デフォルトスキーマを拡張して、残りの要件を満たす新しい要素を定義します。

  デフォルトのディレクトリスキーマで定義されているオブジェクトクラスと属性に一致しないデータ要素がある場合は、スキーマをカスタマイズできます。スキーマを拡張して、既存のスキーマに制約を追加することもできます。詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「カスタムスキーマについて」を参照してください。

• スキーマの保守を計画します。

可能であれば、デフォルトの Directory Server スキーマで定義されている既存のスキーマ要素を使用します。標準のスキーマ要素を使用することにより、ディレクトリ対応アプリケーションとの互換性を保ちやすくなります。このスキーマは LDAP 標準に基づいており、多数のディレクトリユーザーによる検討および合意を経ています。

データの整合性の維持

データの整合性を保つことにより、LDAP クライアントアプリケーションがディレクトリエントリを検索しやすくなります。ディレクトリに格納される情報の種類ごとに、その情報をサポートするために必要なオブジェクトクラスと属性を選択します。常に同じオブジェクトクラスと属性を使用します。整合性のないスキーマオブジェクトを使用すると、情報の検索が難しくなります。

次のようにすると、整合性のあるスキーマを維持できます。

• スキーマ検査を使用して、属性とオブジェクトクラスが必ずスキーマ規則にマッチしていることを確認する。

  スキーマ検査の詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 12 章「Directory Server のスキーマ」を参照してください。

• 整合性のあるデータ形式を選択して適用する。

  LDAP スキーマを使用して、必要なデータを任意の属性値に格納できます。ただし、LDAP クライアントアプリケーションとディレクトリユーザーに適切な形式を選択して、DIT 内で整合性を維持するようにデータを格納することをお勧めします。Directory Server で LDAP プロトコルを使用する場合、RFC 4517 仕様で定められたデータ形式を使用してデータを表現する必要があります。

その他のディレクトリデータ関連資料

標準 LDAP スキーマおよび DIT 設計の詳細は、次のサイトを参照してください。

• RFC 4510: Lightweight Directory Access Protocol (LDAP): 技術仕様ロードマップ http://www.ietf.org/rfc/rfc4510.txt

• RFC 4511: Lightweight Directory Access Protocol (LDAP): プロトコル http://www.ietf.org/rfc/rfc4511.txt

• RFC 4512: Lightweight Directory Access Protocol (LDAP): ディレクトリ情報モデル http://www.ietf.org/rfc/rfc4512.txt

• RFC 4513: Lightweight Directory Access Protocol (LDAP): 認証方法とセキュリティー機構 http://www.ietf.org/rfc/rfc4513.txt

• RFC 4514: Lightweight Directory Access Protocol (LDAP): 識別名 (DN) の文字列表現 http://www.ietf.org/rfc/rfc4514.txt

• RFC 4515: Lightweight Directory Access Protocol (LDAP): 検索フィルタの文字列表現 http://www.ietf.org/rfc/rfc4515.txt

• RFC 4516: Lightweight Directory Access Protocol (LDAP): URL http://www.ietf.org/rfc/rfc4516.txt

• RFC 4517: Lightweight Directory Access Protocol (LDAP): 構文とマッチングルール http://www.ietf.org/rfc/rfc4517.txt

• RFC 4518: Lightweight Directory Access Protocol (LDAP): 国際化された文字列の準備 http://www.ietf.org/rfc/rfc4518.txt

• RFC 4519: Lightweight Directory Access Protocol (LDAP): ユーザーアプリケーション用スキーマ http://www.ietf.org/rfc/rfc4519.txt

• 『Understanding and Deploying LDAP Directory Services』T. Howes, M. Smith, G. Good. Macmillan Technical Publishing, 1999

Directory Server Enterprise Edition でサポートされているすべての RFC および標準規格の一覧は、『Sun Java System Directory Server Enterprise Edition 6.3 Evaluation Guide』の付録 A「Standards and RFCs Supported by Directory Server Enterprise Edition」を参照してください。

第 5 章 サービスレベル契約の定義

サービスレベル契約とは、システムが特定の条件下でどのような動作をしなければならないかを決定する技術的仕様のことです。この章では、Directory Server Enterprise Edition に固有のサービス要件について説明します。また、配備がこれらの要件を満たすことを保証するために、計画フェーズの間に確認する必要があるチェックポイントを示します。

この章の内容は次のとおりです。

• 「システム品質の識別」

• 「パフォーマンス要件の定義」

• 「可用性要件の定義」

• 「拡張性要件の定義」

• 「セキュリティー要件の定義」

• 「潜在処理能力要件の定義」

• 「保守容易性要件の定義」

システム品質の識別

システム品質を識別するには、ディレクトリサービスが提供しなければならない最低限の要件を指定します。一般的に、サービス品質要件の基礎を形成するのは次のシステム品質です。

• パフォーマンス: ユーザーの負荷条件に対する、応答時間およびスループットの測定値。

• 可用性: システムのリソースやサービスにエンドユーザーがアクセスできる時間の指標であり、システムの稼働時間と表現されることもよくあります。

• 拡張性: 配備済みのシステムに容量やユーザーをあとから追加できる能力のこと。拡張性は一般的に、配備アーキテクチャーは変更せずに、システムにリソースを追加することを指します。

• セキュリティー: システムとそのユーザーの完全性を担保する各種要因の複合的な組み合わせです。セキュリティーを構成する要素には、ユーザーの認証と承認、データのセキュリティー、配備済みシステムへのセキュリティー保護されたアクセスなどがあります。

• 潜在処理能力: きわめて高いピーク負荷をリソースの追加なしで処理できるシステムの能力。潜在処理能力は可用性、パフォーマンス、および拡張性に関係する要因です。

• 保守容易性: 配備済みシステムを容易に保守できること。ここでいう保守には、システムの監視、発生する問題の修正、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどが含まれます。

パフォーマンス要件の定義

パフォーマンス要件は、ディレクトリ使用状況の一般的なモデルに基づいて定義することをお勧めします。すべてのディレクトリ配備で、Directory Server は 1 つ以上のクライアントアプリケーションをサポートします。これらのアプリケーションの要件を評価する必要があります。ディレクトリに格納される情報の分量とアクセス頻度を見積もるには、これらのアプリケーションを識別し、アプリケーションが Directory Server をどのように利用するかを特定する必要があります。

クライアントアプリケーションの識別

ディレクトリにアクセスするアプリケーションと、データに対するこれらのアプリケーションのニーズは、パフォーマンス要件に大きな影響を及ぼします。クライアントアプリケーションを識別するときは、次のことを考慮します。

• Directory Server にアクセスするクライアントアプリケーションのタイプ

• これらの各アプリケーションにアクセスするユーザー数

• これらのアプリケーションが実行する操作のタイプ

• これらの操作の使用状況パターン

ディレクトリを使用する可能性がある一般的なアプリケーションには、次のものがあります。

• White pages などのブラウザアプリケーション: この種のアプリケーションは一般に、電子メールアドレス、電話番号、従業員名などの情報にアクセスします。

• メッセージングアプリケーション、特に電子メールサーバー: すべての電子メールサーバーは、電子メールアドレス、ユーザー名、およびルーティング情報を必要とします。サーバーの中には、ユーザーのメールボックスが格納されているディスク上の格納場所、休暇通知情報、およびプロトコル情報など、さらに高度な情報を必要とするものもあります。

• ディレクトリ対応の人事管理アプリケーション: これらのアプリケーションは、政府指定の ID 番号、自宅住所、自宅電話番号、給与詳細などのより個人的な情報を必要とします。

• セキュリティー、Web ポータル、個人化用アプリケーション: この種のアプリケーションは、プロファイル情報にアクセスします。

各アプリケーションが使用する情報を特定すると、いくつかのタイプのデータが複数のアプリケーションによって使用されていることが判明する場合があります。計画段階でこのような課題に取り組むことで、ディレクトリ内のデータが重複する問題を避けることができます。

ディレクトリエントリの数とサイズの決定

ディレクトリに格納されるエントリの数とサイズは、第 4 章「データ特性の定義」で説明したようなデータ要件に大きく左右されます。

エントリの数とサイズを計算するときは、次のことを考慮します。

• 配備で一括インポート初期化を繰り返し実行する必要があるか。

• 必要な場合はインポートの実行頻度

• 一度にインポートされるエントリの数

• インポートされるエントリのタイプ

• サーバーが稼働したままの状態で、オンラインで初期化を実行する必要があるか

読み取り数の特定

読み取りトラフィックを見積もるときは、次のことを考慮します。

• 1 秒あたりの検索件数がどれくらいになるか

• どのようなタイプが検索されるか

  例: 一意 ID 検索、ワイルドカード検索、完全一致検索

• ピーク時の検索率はどの程度になるか

• 平均の検索率はどの程度になるか

• インデックスを使用しない検索がどの程度行われるか

  インデックスを使用しない検索とは、インデックスファイルではなくデータベースを直接検索する検索のことです。インデックスを使用しない検索が発生するのは、検索に使用されるインデックスファイルの内部で「すべての ID のしきい値」に達した場合、インデックスファイルが存在しない場合、または検索に必要な形式でインデックスファイルが構成されていない場合です。

  インデックスを使用しない検索は通常、インデックス検索よりも時間がかかります。

• 検索が特定のデータセンターまたは地理的な領域に集中しているか

  あるデータセンターが受信する検索トラフィックがほかのデータセンターに比べて多い場合、サーバーをレプリケートしてこのデータセンターに追加配置し、負荷分散を図ることを検討する余地があります。

• 検索が一日の特定の時間帯に集中しているか

• ファイアウォール内部での検索がどれくらい行われるか

• ファイアウォールの外からの検索がどれくらい行われるか

読み取りパフォーマンスがもっとも重視されるビジネス環境での配備については、第 10 章「拡張配備の設計」を参照してください。ここでは、読み取りトラフィックの増加に対応できる拡張性を確保しながらディレクトリサービスを配備するための提案事項を紹介しています。

書き込み数の特定

書き込みトラフィックを見積もるときは、次のことを考慮します。

• 1 秒あたりの更新件数がどれくらいになるか

• どのようなタイプが更新されるか

• ピーク時の更新率はどの程度になるか

• 平均の更新率はどの程度になるか

• 更新が特定のデータセンターまたは地理的な領域に集中しているか

  あるデータセンターが受信する更新トラフィックがほかのデータセンターと比べて多い場合、書き込み可能なサーバーをこのデータセンターに追加配置し、更新負荷を分散させることを検討する余地があります。

• 更新が一日の特定の時間帯に集中しているか

書き込みパフォーマンスがもっとも重視されるビジネス環境での配備については、第 10 章「拡張配備の設計」を参照してください。ここでは、書き込みトラフィックの増加に対応できる拡張性を確保しながらディレクトリサービスを配備するための提案事項を紹介しています。

許容可能な応答時間の見積もり

それぞれのクライアントアプリケーションについて、許容可能な最大の応答時間を特定します。許容可能な応答時間は、地理的条件や操作の種類によって異なる可能性があります。

許容可能なレプリケーション待ち時間の見積もり

マスターレプリカとコンシューマレプリカの間で必要な同期性のレベルを見積もります。Directory Server のレプリケーションモデルは疎整合です。これは、マスター上で更新が受理される際に、トポロジ内のほかのレプリカとの通信が不要なことを意味します。そのため、各レプリカの内容が一時的に異なっている可能性があります。これらのレプリカは時間の経過とともに収束し、最終的には各レプリカがデータの同じコピーを保持するようになります。パフォーマンス計画の一環として、レプリカが収束しなければならない最長の許容可能時間を決定します。

Directory Server 6.x には、新しい「優先順位付きレプリケーション」機能が含まれています。この機能では、特定の属性の変更をできるだけ早くレプリケートしなければならないことを指定できます。優先順位付きレプリケーションは、許容可能なレプリケーション待ち時間についての決定に影響を及ぼす場合があります。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Prioritized Replication」を参照してください。

可用性要件の定義

可用性は、ディレクトリサービスに関して合意された最低限の「稼働時間」およびパフォーマンスレベルを指します。ここでは、ディレクトリサービスがこの最小レベルのサービスを提供できなくなるあらゆる要因を障害と定義します。

可用性要件を評価するときは、次のことを考慮します。

• ディレクトリサービスは一日の特定の時間帯にのみアクセスされるか

• 読み取り操作と書き込み操作のそれぞれに対して異なる可用性要件が存在するか

• 地理的に離れた複数のサイトにまたがってサービスが提供されるか。その場合、アクセス時間に関する要件がこれらのサイト間で異なっているか

• システムの保守のためにシャットダウンできるか

  できる場合、許容可能な最長の停止時間はどのくらいか

• 移行中にシステムをシャットダウンできるか

• 停止時間が組織にもたらすコスト (損失) はどの程度か

高可用性ディレクトリサービスの配備に関する提案事項については、第 12 章「高可用性配備の設計」を参照してください。

拡張性要件の定義

ディレクトリが拡大する過程で、サポートしなければならないサービスレベルが変化する可能性があります。システムの配備後にサービスのレベルを引き上げることは難しい場合があります。したがって、初期設計では将来の要件も考慮に入れる必要があります。

拡張性要件を定義するときは、次のことを考慮します。

• エントリ分量の増加が予測されるか

• 今後数年間で新規ユーザーの数はどれくらいになるか

• 今後数年間で、データ、ユーザー、およびクライアントアプリケーションの増加率はどの程度になるか

• 新しいビジネスプロセスの導入予定の有無

あまり早い時期に配備の拡張が必要にならないように、必要な CPU 数については多めに見積もっておきます。拡張の時期として想定しているマイルストーンと、今後の負荷の増加分を比較検討して、マイルストーンに到達するまでは十分な能力を維持できるようにします。

セキュリティー要件の定義

セキュリティー要件については、独立した解説が必要です。第 7 章「セキュリティー要件の特定」で詳しく説明します。

潜在処理能力要件の定義

潜在処理能力要件を定義するときは、ディレクトリサービスのピーク時の負荷条件を見積もります。次の点を考慮してください。

• すべてのクライアントアプリケーションが動作中と仮定した場合に達する可能性がある、Directory Server への最大同時接続数

• 1 台以上のサーバーが停止したと仮定した場合に、配備内の残りのサーバーにかかると予測される負荷

保守容易性要件の定義

保守容易性要件については、第 8 章「管理と監視の要件の特定」で詳しく説明します。

第 6 章 システム特性のチューニングとハードウェアサイジング

Directory Server Enterprise Edition を配備するには、まず特定のシステム特性が定義されている必要があります。この章では、配備の計画フェーズで解決する必要のあるシステム情報について説明します。

この章の内容は次のとおりです。

• 「ホストシステムの特性」

• 「ポート番号」

• 「Directory Service Control Center のハードウェアサイジング」

• 「Directory Proxy Server のハードウェアサイジング」

• 「Directory Server のハードウェアサイジング」

• 「Directory Server 向けのオペレーティングシステムチューニング」

• 「Directory Server の物理的な機能」

ホストシステムの特性

配備で使用するホストシステムを特定する際には、次の点を考慮してください。

• 1 つのサーバーの専用システムとするか。

• システム上でほかのアプリケーションを実行するか。実行する場合はどのようなアプリケーションを実行するか。

• それらのアプリケーションはシステムのリソースのどのくらいの割合を必要とするか。

ホストシステムの特定が完了したら、トポロジ内のホストごとにホスト名を選択します。必ず各ホストシステムが静的な IP アドレスを持つようにしてください。

ホストシステムへの物理アクセスを制限します。Directory Server Enterprise Edition に多数のセキュリティー機能が組み込まれているとしても、ホストシステムへの物理アクセスが制御されていない場合、ディレクトリのセキュリティーは危険にさらされます。

Directory Server インスタンスがネットワークのネームサービスを提供していない場合、または配備によりリモート管理を可能にするには、ネームサービスと、そのホストのドメイン名が適切に構成されている必要があります。

ポート番号

設計時に、各 Directory Server インスタンスおよび各 Directory Proxy Server インスタンスのポート番号を選択します。可能であれば、本稼働環境へのディレクトリサービスの配備後にポート番号を変更することは避けてください。

さまざまなサービスやコンポーネントに対してそれぞれ異なるポート番号を割り当てる必要があります。

• 「Directory Server および Directory Proxy Server の LDAP および LDAPS ポート番号」

• 「Directory Server の DSML ポート番号」

• 「Directory Service Control Center および共通エージェントコンテナのポート番号」

• 「Identity Synchronization for Windows のポート番号」

Directory Server および Directory Proxy Server の LDAP および LDAPS ポート番号

LDAP 接続を受け入れるためのポート番号を指定します。LDAP 通信の標準ポートは 389 ですが、ほかのポートを使用してもかまいません。たとえば、サーバーを通常のユーザーとして起動できるようにする必要がある場合には、特権のないポートを使用します。デフォルトは 1389 です。1024 より小さいポート番号では特権付きアクセスが必要になります。1024 より小さいポート番号を使用した場合、特定の LDAP コマンドを root として実行する必要があります。

SSL ベースの接続を受け入れるためのポート番号を指定します。SSL ベースの LDAP (LDAPS) 通信の標準ポートは 636 ですが、通常のユーザーとして実行する場合のデフォルトである 1636 など、ほかのポートを使用してもかまいません。たとえば、サーバーを通常のユーザーとして起動できるように特権のないポートが必要になる可能性があります。

特権のないポートを指定し、かつほかのユーザーがアクセスしているシステム上にサーバーインスタンスをインストールした場合、そのポートは別のアプリケーションに乗っ取られる危険にさらされる可能性があります。ほかのアプリケーションが同じアドレスとポートのペアにバインドできることになり、このため、悪意のあるアプリケーションがサーバー宛の要求を処理できる可能性があります。また、そうしたアプリケーションを使えば、認証処理時に使用されたパスワードを捕捉したり、クライアント要求やサーバー応答を変更したり、サービス拒否攻撃を仕掛けたりすることもできます。

Directory Server と Directory Proxy Server のどちらでも、サーバーが待機する IP アドレスのリストを制限できます。Directory Server には、設定属性 nsslapd-listenhost と nsslapd-securelistenhost があります。Directory Proxy Server では、ldap-listener および ldaps-listener 設定オブジェクト上に listen-address プロパティーがあります。待機するインタフェースのリストを指定すると、ほかのプログラムはサーバーと同じポート番号を使用できなくなります。

Directory Server の DSML ポート番号

Directory Server は、LDAP 要求を処理するだけでなく、Directory Service Markup Language v2 (DSML) で送信されてきた要求にも応答します。DSML は、クライアントがディレクトリ操作をエンコードするためのもう 1 つの方法です。Directory Server は、DSML をほかのすべての要求と同様に、同じアクセス制御とセキュリティー機能を使って処理します。

使用するトポロジに DSML アクセスが含まれている場合は、次の情報を特定します。

• DSML 要求を受信するための標準の HTTP ポート。デフォルトポートは 80 です。

• SSL が有効になっている場合は、暗号化された DSML 要求を受信するための暗号化 (HTTPS) ポート。デフォルトポートは 443 です。

• 相対 URL。これをホストとポートの末尾に追加すれば、クライアントが DSML 要求の送信時に使用する必要のある完全な URL が決まります。

DSML の設定方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「DSML-over-HTTP サービスを有効にする」を参照してください。

Directory Service Control Center および共通エージェントコンテナのポート番号

Directory Service Control Center (DSCC) は Sun Java Web コンソール向けの Web アプリケーションであり、Directory Server および Directory Proxy Server のインスタンスをユーザーが Web ブラウザ経由で管理できるようにします。あるサーバーが DSCC によって認識されるには、そのサーバーを DSCC に登録する必要があります。サーバーの登録を解除しても、それらのサーバーは依然としてコマンド行ユーティリティーを使って管理できます。

DSCC は、サーバーがインストールされたシステム上に存在している DSCC エージェントと通信します。DSCC エージェントは共通エージェントコンテナ内で実行されます。共通エージェントコンテナは、ネットワークトラフィックを各エージェントへ転送するとともに、エージェントの実行環境としてのフレームワークを提供します。

DSCC を使ってトポロジ内のサーバーを管理する予定である場合は、次の各ポート番号を特定します。

• DSCC がインストールされたシステム上の、Sun Java Web コンソール経由で DSCC にアクセスするための暗号化 HTTPS ポート。デフォルトポートは 6789 です。

• サーバーインスタンスがインストールされたシステム上の、DSCC がサーバーに対してローカルな場所にあるエージェントに共通エージェントコンテナ経由でアクセスするための管理トラフィックポート。デフォルトは 11162 です。

• 設定情報をレプリケートする予定である場合は、DSCC レジストリのインスタンスのポート番号。詳細については、dsccsetup(1M) のマニュアルページを参照してください。

同一システム上にすべてのコンポーネントがインストールされている場合でも、DSCC はそのエージェントとこれらのネットワークポート経由で通信します。

Identity Synchronization for Windows のポート番号

配備環境で、Microsoft Active Directory とのアイデンティティー同期を行う場合、Message Queue インスタンス用のポートが必要となります。このポートは、Active Directory との同期に関わる各 Directory Server インスタンス上で使用できる必要があります。Message Queue のセキュリティー保護されていないポートのデフォルトは 80、セキュリティー保護されたポートのデフォルトは 443 です。

また、配備計画時には、その他のインストール決定や設定決定も行う必要があります。Identity Synchronization for Windows のインストールや設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』のパート II「Installing Identity Synchronization for Windows」を参照してください。

Directory Service Control Center のハードウェアサイジング

DSCC は、Web アプリケーションコンテナの内部で動作する Sun Java Web コンソールのさらに内部で、Web アプリケーションとして実行されます。また、DSCC は、設定データの格納用として独自のローカル Directory Server インスタンスも実行します。

DSCC を実行するための最小要件は、256M バイトのメモリーと 100M バイトの空きディスク容量です。ただし、最適なパフォーマンスを実現するには、少なくとも 1G バイトの DSCC 専用メモリーと数 G バイトの空きディスク容量を備えたシステム上で DSCC を実行します。

Directory Proxy Server のハードウェアサイジング

Directory Proxy Server はマルチスレッド Java プログラムとして実行され、複数のプロセッサ間で高いスケーラビリティーを実現できるように構築されています。一般に、利用可能な処理能力が大きいほどパフォーマンスも向上しますが、実際には、メモリーを追加したりディスクやネットワーク接続を高速化したりしたほうが、プロセッサを追加するよりもパフォーマンスが改善される可能性が高くなります。

仮想メモリーの設定

Directory Proxy Server は主に、処理中の情報を保持する目的でメモリーを使用します。複数のデータソースに対するいくつかの仮想ディレクトリ要求を処理することで、一時的に余分なメモリーを使用します。データソースの 1 つが LDIF ファイルであった場合、Directory Proxy Server はそのデータソースの内容をメモリー内に構築します。ただし、配備方法として推奨されていない大規模な LDIF データソースを使用するのでもないかぎり、数 G バイトのメモリーを Directory Proxy Server に割り当てれば十分です。十分なメモリーが利用可能である場合には、Directory Proxy Server 起動時の Java 仮想マシンのヒープサイズを増やすことをお勧めします。たとえば、Java 仮想マシンのヒープサイズを 1000M バイトに設定するには、次のコマンドを使用します。

$ dpadm set-flags instance-path jvm-args="-Xmx1000M -Xms1000M -XX:NewRatio=1"

このコマンドでは -XX:NewRatio オプションを使用していますが、これは、Sun の Java 仮想マシンに固有のオプションです。デフォルトのヒープサイズは 250M バイトです。

ワークスレッドとバックエンド接続の設定

Directory Proxy Server では、サーバーが要求を処理するためのスレッドを何個維持するかを設定できます。これを設定するにはサーバープロパティー number-of-worker-threads を使用します。これについては number-of-worker-threads(5dpconf) のマニュアルページを参照してください。経験則として、50 スレッドに、使用するデータソースごとに 20 スレッドを加算した値を設定してみてください。この数値が十分かどうかを判断するには、cn=Work Queue,cn=System Resource,cn=instance-path ,cn=Application System,cn=DPS6.0,cn=Installed Product,cn=monitor で Directory Proxy Server の作業キューの状態を監視します。作業キューの operationalStatus が STRESSED になっていた場合、それは、スレッドの不足している接続ハンドラが新しいクライアント要求を処理できないことを意味している可能性があります。Directory Proxy Server が追加のシステムリソースを利用できる場合には、number-of-worker-threads を増やすことで状況が改善される可能性があります。

また、ワークスレッドの数はバックエンド接続の数と比較しても適切な値であるべきです。バックエンド接続の数に比べて「ワークスレッドの数が多すぎる」場合、受信接続を受け入れても、それをバックエンド接続に送信することができません。そのような状況は一般に、クライアントアプリケーションにとって問題となります。

この状況が発生しているかどうかを判断するには、次のタイプのエラーメッセージがログファイルに含まれていないかチェックします。"Unable to get backend connections"。あるいは、負荷分散の cn=monitor エントリを確認します。そのエントリの totalBindConnectionsRefused 属性が null でなかった場合、バックエンド接続の不足が原因でプロキシが特定の操作を処理できなかったことになります。この問題を解決するには、バックエンド接続の最大数を増やします。各データソースのバックエンド接続の数を設定するには、そのデータソースの num-bind-limit、num-read-limit、および num-write-limit プロパティーを使用します。バックエンド接続の上限にすでに達した場合には、ワークスレッドの数を減らします。

バックエンド接続の数に比べて「ワークスレッドの数が不足している」場合には、サーバーのキュー内に多数の作業がたまり、新しい接続を処理できなくなる可能性があります。このため、クライアント接続が TCP/IP レベルで拒否されてしまい、何の LDAP エラーも返されない可能性があります。この状況が発生しているかどうかを判断するには、作業キューの cn=monitor エントリの統計を確認します。特に、readConnectionsRefused と writeConnectionsRefused は低いままであるべきです。また、maxNormalPriorityPeak 属性の値も低いままであるべきです。

Directory Proxy Server のディスク容量

Directory Proxy Server はデフォルトで、access ログ用として最大 1G バイトのローカルディスク容量を必要とし、errors ログ用としてさらに 1G バイトのローカルディスク容量を必要とします。Directory Proxy Server がクライアントアプリケーションの要求を処理する際に書き込む access ログメッセージの数を考えると、ロギングがパフォーマンス上の障害点になる可能性があります。ただし通常、本稼働環境ではロギングを有効なままにしておく必要があります。したがって、最高のパフォーマンスを実現するには、Directory Proxy Server のログを、高速な専用ディスクサブシステム上に配置します。ログ設定を調整する手順については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Proxy Server のログの設定」を参照してください。

Directory Proxy Server のネットワーク接続

Directory Proxy Server はネットワーク集約型アプリケーションです。Directory Proxy Server は、クライアントアプリケーションから要求を受け取るたびに、複数の操作を異なるデータソースに送信する可能性があります。Directory Proxy Server とデータソース間のネットワーク接続が高速であり、十分な帯域幅があり、待ち時間も短いことを確認してください。また、Directory Proxy Server とクライアントアプリケーション間の接続が予期されるトラフィック量を処理できることも確認してください。

Directory Server のハードウェアサイジング

中規模から大規模の Directory Server 配備に適したハードウェアを決定するには、本番時に提供することが予期されるデータに類似したデータと、予期されるクライアントアプリケーションからのアクセスパターンに類似したアクセスパターンに基づいて、何らかのテストを行う必要があります。特定のシステム用に最適化する場合には、システムバス、周辺バス、入出力デバイス、およびサポートされているファイルシステムがどのように動作するのかを、必ず理解しておく必要があります。この知識があれば、Directory Server をサポートするように入出力サブシステムの機能をチューニングする際に、それらの機能を活用しやすくなります。Sun サービスは、要件に合ったハードウェアサイジングなど、正しい配備決定を行う際に役立つ可能性があります。

この節では、Directory Server のハードウェアサイジングへのアプローチ方法を説明します。ここでは、配備内の Directory Server 専用として使用するプロセッサの個数、メモリーの容量、ディスクの容量、およびネットワーク接続の種類を決定する際の考慮点を示します。

この節の内容は、次のとおりです。

• 「チューニングプロセス」

• 「サンプルディレクトリデータの作成」

• 「設定すべき項目とその理由」

• 「クライアントアプリケーション負荷のシミュレーション」

• 「Directory Server とプロセッサ」

• 「Directory Server とメモリー」

• 「Directory Server とローカルディスク容量」

• 「Directory Server とネットワーク接続」

• 「クライアントが使用可能な Directory Server リソースの制限」

• 「Directory Server が使用するシステムリソースの制限」

• 「Directory Server の基本的なサイジングの例: ディスクとメモリーの要件」

特に明記されていないかぎり、次の各節で説明されている「サーバープロパティー」は dsconf コマンドで設定できます。dsconf の使用方法の詳細については、dsconf(1M) のマニュアルページを参照してください。

チューニングプロセス

パフォーマンスのチューニングは、デフォルト設定を変更して特定の配備要件が反映されるようにすることを意味します。次のプロセスフェーズのリストには、Directory Server のチューニング時に考慮すべき主要項目が記載されています。

目標の定義

配備要件に基づいて、特定の測定可能なチューニング目標を定義します。

次の各質問を検討してください。

• どのアプリケーションが Directory Server を使用しますか。

• システムの全体を Directory Server の専用にすることができますか。

  システム上でほかのアプリケーションも実行されますか。

  そうであれば、システム上で実行されるほかのアプリケーションはどれですか。

• この配備によって何件の「エントリ」が処理されますか。

  エントリ件数はどのくらいになりますか。

• Directory Server は 1 秒あたり何件の「検索」をサポートする必要がありますか。

  どのようなタイプが検索されるか

• Directory Server は 1 秒あたり何件の「更新」をサポートする必要がありますか。

  どのようなタイプが更新されるか

• どのような種類のピークの更新頻度および検索頻度が予期されますか。

  平均の更新頻度はどれくらいになると予期されますか。

• 配備がこのシステム上で一括インポートによる初期化を繰り返し必要としますか。

  そうであれば、データのインポート頻度はどのくらいであると予期されますか。何件のエントリがインポートされますか。

  エントリの種類はわかりますか。

  サーバーが稼働したままの状態で、オンラインで初期化を実行する必要があるか

このリストはすべての要素を網羅しているわけではありません。自身の目標リストがすべての要素を網羅していることを確認してください。

方法の選択

最適化をどのように実施する予定であるかを決定します。また、最適化結果をどのように測定および解析する予定であるかも決定します。

次の各質問を検討してください。

• システムのハードウェア構成を変更できるか。

• すでに存在しているハードウェアを使用したり、サーバーが稼働しているオペレーティングシステムや Directory Server のみをチューニングしたりすること以外に方法がないか。

• ほかのアプリケーションをどのような方法でシミュレートできるか。

• テスト用の典型的なデータサンプルをどのような方法で生成すべきか。

• 結果をどのような方法で測定すべきか。

• 結果をどのような方法で解析すべきか。

テストの実行

計画したテストを実行します。配備が大規模で複雑な場合、このフェーズでかなりの時間がかかる可能性があります。

結果の確認

テストした潜在的な最適化によって、プロセス開始時に定義した目標が達成されたかどうかをチェックします。

最適化によって目標が達成された場合には、その結果を文書化します。

最適化によって目標が達成されなかった場合には、Directory Server のプロファイリングと監視を行います。

プロファイリングおよび監視

潜在的な変更を適用したあとで、Directory Server の動作のプロファイリングと監視を行います。

関係するすべての動作の測定値を収集します。

グラフ化と解析

プロファイリング中や監視中に監視した動作をグラフ化および解析します。証拠を見つけたり、さらなるテストを示唆するパターンを発見したりする努力を行なってください。

「プロファイリングおよび監視」フェーズに戻って別のデータを収集する必要がある可能性もあります。

調整およびチューニング

測定値の解析結果が示唆する、さらなる潜在的な最適化を適用します。

「テストの実行」フェーズに戻ります。

結果の文書化

適用した最適化によってプロセス開始時に定義した目標が達成された場合には、その最適化を適切に文書化し、あとでその最適化を容易に再現できるようにします。

サンプルディレクトリデータの作成

Directory Server に割り当てるディスクやメモリーの容量は、ディレクトリデータに依存します。サンプルデータが LDIF 形式ですでに存在している場合には、配備のハードウェアをサイジングする際にそのデータを使用します。ここで、サンプルデータとは、配備時に使用することが予期されるデータに対応するサンプルデータを意味しており、「配備時の実際のデータ」を意味しているのではありません。実際のデータは、現実的なプライバシーに関する配慮を必要とし、サンプルデータの生成に必要となる仕様に比べて桁違いに大きくなる可能性があるため、テスト対象のすべてのケースを実施することが難しくなる可能性があります。サンプルデータに含まれるエントリの平均サイズは、配備時に予期されるサイズに近く、その属性は、配備時に予期される値に似た値を持ち、その数は、配備時に予期される比率に似た比率で存在しています。

サンプルデータに基づいて何らかの決定を下す際には、予期される増加分を考慮に入れるようにしてください。容量計画時には、現在のデータのオーバーヘッド分を含めることをお勧めします。

サンプルデータをまだ用意していない場合には、makeldif(1) コマンドを使ってサンプル LDIF を生成し、それを Directory Server にインポートします。第 4 章「データ特性の定義」は、配備用のサンプルデータを決定する際に役立つ可能性があります。makeldif コマンドは Directory Server Resource Kit ツールの 1 つです。

本番時に数百万件のエントリを提供することが予期される配備では、数百万件のエントリをテスト用に読み込むのが理想的です。ただし、数百万件のエントリを読み込むことは、最初の評価目的としては現実的でない可能性もあります。まず、10,000 件のエントリ、100,000 件のエントリ、1,000,000 件のエントリなど、サンプルデータのセットをいくつか作成し、それらをインポートし、その監視結果に基づいて推定することで、さらなるテストに必要となるハードウェアを見積もります。ハードウェア要件を見積もる際には、複数のサーバーにレプリケートされるデータを準備してください。

LDIF から Directory Server 内にディレクトリデータをインポートすると、その結果として得られるデータベースファイル (インデックスを含む) は、LDIF 表現よりも大きくなります。データベースファイルはデフォルトで、instance-path/db/ ディレクトリ内に格納されます。

設定すべき項目とその理由

Directory Server のデフォルト設定は典型的な小規模配備向けに定義されたものであり、その目的は、この製品を容易にインストールおよび評価できるようにすることです。この節では、中規模から大規模の配備で調整すべきいくつかの主要設定について調査します。中規模から大規模の配備では、設定をユーザーの特定の配備に適応させることでパフォーマンスを大幅に改善できることがよくあります。

Directory Server のデータベースページサイズ

Directory Server は、データの読み書きを行う際に、ページと呼ばれる固定長のデータブロックを操作します。ページサイズを増やすことにより、1 つのディスク操作で読み書きされるブロックのサイズを増やせます。

ページサイズはエントリのサイズと関係しており、パフォーマンスを考えるうえで不可欠の要素です。エントリの平均サイズが db-page-size/4–24 (24 はページごとのバイナリツリー内部構造) より大きいことがわかっている場合は、データベースページサイズを増やす必要があります。さらに、データベースのページサイズはファイルシステムのディスクブロックサイズと一致すべきです。

Directory Server のキャッシュサイズ

Directory Server は、クライアントアプリケーションの要求にすばやく応答するように設計されています。Directory Server は、ディスクからディレクトリデータが読み取られるまで待たずにすむように、メモリー内にデータを書き込みます。データベースファイル用、ディレクトリエントリ用、および LDIF からのディレクトリデータのインポート用のキャッシュとして、どれだけのメモリーを割り当てるかを設定できます。

すべてのディレクトリデータをキャッシュするのに十分な容量の物理メモリーを割り当てることのできるハードウェア上で Directory Server を実行するのが理想的です。データが無理なく収まるようにすることで、システムがその正常動作に必要な物理メモリーを確保でき、かつファイルシステムも自身のキャッシュ処理や正常動作に必要な物理メモリーを確保できるようにすべきです。いったんデータがキャッシュに書き込まれると、ディレクトリエントリが変更されないかぎり、Directory Server はディスクに対してデータの読み書きを行う必要がなくなります。

Directory Server は、64 ビットメモリーアドレス指定をサポートしているため、64 ビットプロセッサがアドレス指定可能なサイズであれば、どのように大きな合計キャッシュサイズでも処理できます。小規模から中規模の配備では、すべてのディレクトリデータをキャッシュ内に保持できるだけのメモリーを確保できることがよくあります。これに対し、大規模配備では、すべてをキャッシュに保持することは、現実的でないか、あるいは費用効果的に問題がある可能性があります。

大規模配備では、すべてをメモリーに保持すると、副作用が生じる可能性があります。プロセスのメモリーマップをトラバースしてデータを収集する、pmap コマンドなどのツールを実行すると、ユーザーが気づく程度の期間、サーバープロセスが動かなくなる可能性があります。コアファイルが非常に大きくなるため、クラッシュ時にそれらをディスクに書き込むのに数分かかる可能性があります。サーバーが突然停止されたあと再起動された場合、起動時間が長くなる可能性があります。さらに、Directory Server がチェックポイントに到達し、ダーティーキャッシュページをディスクにフラッシュしなければならない場合には、サーバーが一時的に停止し、応答しなくなる可能性もあります。キャッシュが非常に大きい場合はこの一時停止も非常に長くなり、Directory Server が停止しているものと監視ソフトウェアによって判断される可能性があります。

オペレーティングシステムレベルの入出力バッファーを使えば、パフォーマンスが向上する可能性があります。非常に大きなバッファーは、比較的小さなデータベースキャッシュの悪影響を打ち消すことができます。

キャッシュやキャッシュ設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 5 章「Directory Server Data Caching」を参照してください。キャッシュサイズの調整方法については、「The Basics of Directory Server Cache Sizing 」を参照してください。

Directory Server のインデックス

Directory Server は、ディレクトリエントリの属性値に対するインデックスを作成することで、それらの属性の検索を高速化します。属性は、さまざまな方法でインデックスが作成されるように設定できます。たとえば、インデックスを使えば、ある属性が値を持っているか、特定の値に等しい値を持っているか、あるいは特定の部分文字列を含む値を持っているかを、Directory Server がよりすばやく決定できるようになります。

インデックスを使えば、検索時のパフォーマンスが向上する可能性がありますが、書き込み時のパフォーマンスに悪影響が及ぶ可能性もあります。ある属性のインデックスが作成されると、Directory Server はその属性の値が変更されるたびにインデックスを更新しなければいけません。

Directory Server はインデックスデータをファイルに保存します。設定するインデックスが多いほど、必要なディスク容量も多くなります。Directory Server のインデックスとデータファイルはデフォルトで、instance-path/db/ ディレクトリ内に格納されます。

インデックス作成やインデックス設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 6 章「Directory Server Indexing」を参照してください。

Directory Server の管理ファイル

Directory Server のいくつかの管理ファイルは、サイズが非常に大きくなる可能性があります。そうしたファイルとしては、ディレクトリデータを含む LDIF ファイル、バックアップ、コアファイル、ログファイルなどが挙げられます。

配備によっては、Directory Server データのインポート、補助バックアップの両方の用途で LDIF を使用することができます。標準テキスト形式の LDIF を使えば、バイナリデータだけでなく文字列もエクスポートできます。大規模配備の場合、LDIF は大量のディスク容量を占有する可能性があります。たとえば、平均サイズが 2K バイトのエントリを 1 千万件含んでいるディレクトリは、LDIF 表現ではディスク上で 20G バイトを占有します。この LDIF 形式を補助バックアップとして使用する場合、このサイズの LDIF ファイルが複数個維持される可能性があります。

バイナリのバックアップファイルも、少なくとも安全を確保するためにどこかほかの場所に移動されるまでは、ディスクの容量を占有します。Directory Server ユーティリティーによって生成されるバックアップファイルは、ディレクトリデータベースファイルのバイナリコピーから構成されます。大規模配備の場合は別の方法として、Directory Server を凍結モードにしたあと、ファイルシステムのスナップショットを取ることもできます。いずれにしても、バックアップに利用可能なディスク容量が存在している必要があります。

Directory Server はデフォルトで、ログメッセージを instance-path/logs/access と instance-path/logs/errors に書き込みます。Directory Server はデフォルトで、access ログ用として 1G バイトのローカルディスク容量を必要とし、errors ログ用としてさらに 200M バイトのローカルディスク容量を必要とします。

Directory Server のロギングの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 7 章「Directory Server Logging」を参照してください。

Directory Server のレプリケーション

Directory Server では、ディレクトリデータをレプリケートすることで、配備内のサーバーの可用性を高め、サーバー間の負荷分散を行えるようになっています。Directory Server では、複数の読み書き (マスター) レプリカを一緒に配備できます。

サーバーはこれを可能にするために、内部的にディレクトリデータへの変更を追跡します。同じデータが複数の読み書きレプリカ上で変更されても、Directory Server はその変更をすべてのレプリカ上で解決できます。これらの変更を追跡するためのデータは、レプリケーション時に必要とされなくなるまで、保持しておく必要があります。変更は、「パージ遅延」によって指定された期間だけ保持されます。デフォルト値は 7 日間です。ディレクトリデータに多数の変更が加えられると、このデータは非常に大きくなる可能性があります。大きな複数値属性に変更が加えられる場合は特にそうです。

データの増大するレベルはさまざまな要素によって決まるので、データの増大量を求めるための決定的な公式はありません。最善のアプローチ方法は、通常の変更をテストして増大量を測定してみることです。エントリの変更によるデータの増大に影響する要素には、次のようなものがあります。

• 変更対象のエントリのタイプと属性のタイプ。

  複数値属性だとデータの増大量が大きくなります。属性値が小さい場合は、増大量が見えやすくなります。

• エントリに適用される作業負荷。

  エントリの追加や削除を行うと、データの増大量が大きくなります。属性値を追加すると、属性値を置き換えた場合よりもデータの増大量が大きくなります。

• 変更対象のエントリ数と、各エントリ内の変更対象の属性の数。

• データベースページのサイズ。

  非常に多くの変更を行なった場合、特定のエントリがデータベースページサイズよりも大きくなる可能性があります。

パージ遅延の期間が過ぎて、エントリがもう一度変更されるまで、レプリケーションのメタデータはエントリ内に保持されたままになっています。

Directory Server のレプリケーションの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」を参照してください。

Directory Server のスレッドとファイル記述子

Directory Server はマルチスレッドプロセスとして実行され、マルチプロセッサシステム上では高いスケーラビリティーを実現できるように設計されています。Directory Server が起動時に作成する処理用スレッドの数を設定することができます。Directory Server はデフォルトで 30 個のスレッドを作成します。この値を設定するには、dsconf(1M) コマンドを使ってサーバープロパティー thread-count を調整します。

大切なのは、多数のスレッドを処理する必要性による undo 処理のオーバーヘッドを発生させることなく、スレッドをできるだけビジー状態に保つことです。すべてのディレクトリデータがキャッシュ内に収まっているかぎり、プロセッサ数の 2 倍に予期される同時更新処理数を加えた値を thread-count に設定すると、しばしば良好なパフォーマンスが得られます。大きなディレクトリデータセットの一部しかキャッシュ内に収まらない場合には、データがディスクから読み取られるのを Directory Server のスレッドが待たなければいけない状況がしばしば発生します。そうした場合には、利用可能なプロセッサ数の最大 16 倍という、格段に大きなスレッド数を使用すれば、パフォーマンスを改善できる可能性があります。

Directory Server はファイル記述子を使って、開いているクライアントアプリケーション接続に関係するデータを保持します。Directory Server はデフォルトで、最大 1024 個のファイル記述子を使用します。この値を設定するには、dsconf コマンドを使ってサーバープロパティー file-descriptor-count を調整します。too many fds open というメッセージが errors ログに含まれている場合には、file-descriptor-count を増やすことでパフォーマンスが向上する可能性があります。ただし、Directory Server が追加のファイル記述子を開くことをシステムが許可するものと仮定しています。

file-descriptor-count プロパティーは、Windows には適用されません。

Directory Server の規模の増大

Directory Server がいったん配備されると、その使用量はおそらく増加していきます。規模増大への備えが、配備を成功させ、一貫して高レベルのサービスを提供し続けるための鍵となります。将来的に予期される規模の増大も考慮に入れた要件定義を行い、現時点で必要なシステムよりも大規模で強力なシステムを計画してください。

ディレクトリサービスは、急激にあるいは突然に規模を増大させる必要に迫られる場合があります。たとえば、ある組織用にサイジングされたディレクトリサービスが別の組織のディレクトリサービスとマージされる場合などが、そのケースに該当します。規模増大への備えを前もって行い、予期される内容を明示的に特定することによって、急激な規模増大や突然の規模増大により適切に対処できるようになります。なぜなら、予期された増大が計画された容量を超えるかどうかを前もって知ることができるからです。

最重要のチューニングヒント

基本的な推奨事項を次に示します。これらの推奨事項はほとんどの状況で適用可能です。ここに示した推奨事項は基本的に有効ですが、実際の配備への影響を理解することなしにこれらの推奨事項を適用することは避けてください。この節の目的はチェックリストを提供することであり、模範解答を提供することではありません。

1. キャッシュサイズを調整します。

   理想的なサーバーでは、利用可能な物理メモリーが十分に存在しており、Directory Server が使用するすべてのキャッシュを保持できます。さらに、ある適切な量の追加物理メモリーが、将来の規模増大を考慮して利用可能になっています。十分な物理メモリーが利用可能な場合には、エントリキャッシュサイズを十分に大きな値に設定し、ディレクトリ内のすべてのエントリを保持できるようにします。entry-cache-size サフィックスプロパティーを使用します。db-cache-size プロパティー経由でデータベースキャッシュサイズを十分に大きな値に設定し、すべてのインデックスを保持できるようにします。dn-cache-size または dn-cache-count プロパティーを使用し、DN キャッシュのサイズを制御します。

2. インデックス作成を最適化します。

   1. 不要なインデックスを削除します。予期される要求をサポートするための追加インデックスを追加します。

      新しいアプリケーションからの要求をサポートする追加インデックスを追加することもあります。インデックスの追加、削除、または変更は、Directory Server の稼働中に行えます。たとえば、dsconf create-index や dsconf delete-index などのコマンドを使用します。

      システムインデックスを削除しないように注意してください。システムインデックスの一覧については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「System Indexes and Default Indexes」を参照してください。

      ユーザーがインデックスに変更を加えると、Directory Server は徐々にデータのインデックスを作成します。dsconf reindex コマンドを使って Directory Server に強制的にインデックスを再生成させることもできます。

   2. インデックスを使用する検索のみを許可します。

      インデックスを使用しない検索は、サーバーのパフォーマンスに多大な悪影響を及ぼす可能性があります。インデックスを使用しない検索は、多くのサーバーリソースを消費する可能性もあります。

      require-index-enabled サフィックスプロパティーを on に設定することで、インデックスを使用しない検索を拒否するようサーバーに強制することを検討してください。

   3. all-ids-threshold プロパティーを使って、1 インデックスキーあたりの値の最大数を調整します。

3. idsktune コマンドからの推奨内容に従って、サーバーを稼働しているマシンのオペレーティングシステムをチューニングします。詳細については、idsktune(1M) のマニュアルページを参照してください。

4. 操作制限を調整します。

   操作制限を調整することで、Directory Server がある単一の操作に過度のリソースを割り当ててしまうのを防ぐことができます。大きな容量を要求するクライアントアプリケーションに一意のバインド DN を割り当て、それらの一意のバインド DN に対して具体的なリソース制限を設けることを検討してください。

5. ディスクのアクティビティーを分散します。

   大量の更新をサポートする配備では特に、Directory Server はきわめてディスク入出力集中型になる可能性があります。可能であれば、独立したコントローラを使ってこの負荷を複数のディスクに分散することを検討してください。

6. 不要なロギングを無効にします。

   ディスクアクセスはメモリーアクセスよりも低速です。したがって、過度のロギングはパフォーマンスに悪影響を及ぼします。読み取り専用のサーバーインスタンス上など、監査ロギングが必要ない場合にそのロギングをオフにしておくことで、ディスクの負荷を減らします。エラーログを使って問題のトラブルシューティングを行わないときには、エラーロギングを最小レベルにしておきます。また、ログファイルを専用のディスク上や、レプリケーション変更ログ用のディスクなど、使用頻度の少ないディスク上に配置することによっても、ロギングの影響を減らせます。

7. 多数の更新をレプリケートする場合には、適切なレプリケーションアグリーメントプロパティーを調整することを検討してください。

   プロパティーは transport-compression、transport-group-size、および transport-window-size です。

8. Solaris システム上では、データベースホームディレクトリを tmpfs ファイルシステムに移動します。

   db-env-path プロパティーで指定されるデータベースホームディレクトリは、Directory Server がデータベースキャッシュバッキングファイルを格納する場所を示します。データファイルはデフォルトでは、instance-path/db 内に存在し続けます。

   データベースキャッシュバッキングファイルを tmpfs ファイルシステム上に格納すれば、システムがデータベースキャッシュバッキングファイルをディスクに繰り返しフラッシュしなくなります。したがって、更新時のパフォーマンス障害の発生を回避できます。場合によっては、検索時のパフォーマンス障害の発生も回避できます。データベースのキャッシュメモリーは Directory Server のプロセス空間にマップされます。システムは基本的に、tmpfs ファイルシステム内のキャッシュメモリーとバッキングファイルの保持に使用されるメモリーを共有します。したがって、必要メモリー容量の点で基本的に何のコストも払うことなしに、パフォーマンスの向上を図れます。

   この最適化に関連する主なコストは、ホストマシンの再起動後にデータベースキャッシュを再構築する必要がある、という点です。ソフトウェアまたはハードウェアでの障害発生時にのみ再起動が発生することが予期される場合、このコストはおそらく避けて通ることはできません。そのような障害が発生すれば、いずれにしてもデータベースキャッシュを再構築する必要があります。

9. ソフトウェアまたはハードウェアでの障害発生時に更新が失われてもかまわない場合には、トランザクションバッチを有効にします。

   トランザクションバッチを有効にするには、サーバープロパティー db-batched-transaction-count を設定します。

   トランザクションログが更新されるたびに、更新データが失われないように同期処理が続いて実行されます。トランザクションバッチを有効にすると、いくつかの更新が一緒にまとめられてから、トランザクションログに書き込まれます。同期処理が実行されるのは、バッチの全体がトランザクションログに書き込まれるときだけです。したがって、トランザクションバッチを使えば、更新時のパフォーマンスを大幅に改善できます。この改善にはトレードオフがあります。そのトレードオフとは、クラッシュした時点でトランザクションログにまだ書き込まれていない更新データは失われてしまう、ということです。

   ---

   注 –

   トランザクションバッチを有効にすると、ソフトウェアまたはハードウェアでの障害発生時に最大 db-batched-transaction-count - 1 件の更新が失われます。この損失が発生するのは、Directory Server が、バッチが満たされるまでの間か 1 秒間、どちらか短いほうだけ待機したあとで、内容をトランザクションログに、したがってディスクに、フラッシュするからです。

   更新が失われると困る場合には、この最適化を使用「しない」でください。

   ---

10. 参照の完全性プラグインを設定して完全性チェックを遅延させます。

    参照の完全性プラグインは、エントリが変更されたりディレクトリから削除された場合に、それらのエントリへのすべての参照が間違いなく更新されるようにします。この処理はデフォルトでは、削除操作に対する応答がクライアントに返される前に、同期的に実行されます。この更新が非同期で実行されるようにプラグインを設定できます。ref-integrity-check-delay サーバープロパティーを使用します。

クライアントアプリケーション負荷のシミュレーション

Directory Server のパフォーマンスを測定するには、サーバーを準備したあと、本番時に予期されるタイプのクライアントアプリケーショントラフィックをそのサーバーに対して与えます。本番時に発生するクライアントアプリケーションのアクセスパターンタイプの再現性が高まるほど、ハードウェアのサイジングと Directory Server の設定の精度も高くなります。

Directory Server Resource Kit には、基本的なテストを行う際に使用可能な authrate(1)、modrate(1)、および searchrate(1) コマンドが含まれています。これらのコマンドを使えば、使用するディレクトリサービスがサポート可能なバインド頻度、変更頻度、および検索頻度を測定できます。

SLAMD を使って複雑で現実的なクライアントアクセスのシミュレーション、測定、およびグラフ化を行うこともできます。SLAMD 分散負荷生成エンジン (SLAMD) は、ネットワークベースのアプリケーションの負荷テストを行なったりそのパフォーマンスを解析したりするために設計された、Java アプリケーションです。これは当初、LDAP Directory Server のベンチマーク測定およびパフォーマンス解析用として、Sun Microsystems, Inc. によって開発されました。SLAMD は、OSI が承認したオープンソースライセンスである Sun Public License のもとでオープンソースアプリケーションとして公開されています。SLAMD についての情報を入手するには、http://www.slamd.com/ を参照してください。SLAMD は java.net プロジェクトとしても公開されています。https://slamd.dev.java.net/ を参照してください。

Directory Server とプロセッサ

Directory Server は複数のプロセッサが搭載されたシステム上で動作するように開発されたマルチスレッドプロセスであり、そのパフォーマンスはほとんどの場合、割り当てるプロセッサの数を増やすにつれて線形的に増加していきます。多数のプロセッサが搭載されたシステム上で Directory Server を実行する場合、Directory Server がサーバー操作を処理するために起動するスレッドの数を表すサーバープロパティー thread-count を、dsconf コマンドを使って調整することを検討してください。

ただし、特定のディレクトリ配備では、プロセッサを追加してもパフォーマンスがあまり改善されない可能性があります。検索、インデックス、およびレプリケーションで要求の厳しいパフォーマンス要件を扱うときは、解決策の一部として、負荷分散やディレクトリプロキシなどの技術を検討します。

Directory Server とメモリー

必要メモリー量に大きな影響を与える要因は、次のとおりです。

• Directory Server のデータベースキャッシュ、エントリキャッシュ、およびインポートキャッシュの設定

• ピーク時のレプリケーション負荷

• ピーク時のクライアントアプリケーション負荷

• file-descriptor-count と thread-count のサーバー設定

• オペレーティングシステム、システム上で実行されるほかのアプリケーション、およびシステム管理アクティビティーのオーバーヘッド

Directory Server の実行に必要なメモリーのサイズを見積もるには、Directory Server Resource Kit コマンドや SLAMD などによって生成されたアプリケーション負荷など、本番時と同様の負荷のかかったシステム上の特定の Directory Server 設定で必要とされるメモリーを見積もります。

Directory Server プロセスのサイズを測定する前に、サーバーを起動してからしばらく放置し、通常処理時またはピーク処理時と同様にエントリキャッシュが満たされるようにします。すべてをキャッシュメモリーに格納するだけの容量が存在する場合、ディレクトリ内のすべてのエントリを読み取ってエントリキャッシュを満たすことで、この Directory Server のウォームアップ期間を短縮することができます。すべてをキャッシュメモリーに格納するだけの容量が存在しない場合には、実際の場合と同様にキャッシュが満たされるまで、通常処理またはピーク処理のパターンを使ってクライアントアクセスのシミュレーションをしばらく実行します。

サーバーが平衡状態に達したら、Solaris や Linux 上の pmap、Windows タスクマネージャーなどのユーティリティーを使って Directory Server プロセスが使用しているメモリーを測定できます。このプロセスは、UNIX システム上では ns-slapd、Windows システム上では slapd.exe になります。詳細については、pmap(1) のマニュアルページを参照してください。通常処理時、ピーク処理時の両方のプロセスサイズを測定したあとで、使用すべきメモリーの量を決定してください。

システム管理に必要なメモリーとシステム自体に必要なメモリーの量を、必ず見積もりに追加してください。オペレーティングシステムのメモリー要件は、システムの構成によって大きく変わる可能性があります。したがって、使用するオペレーティングシステムの実行に必要なメモリーの見積もりは、実験的に行う必要があります。システムのチューニングが完了したら、メモリーの使用量を監視し、その量を見積もりに追加します。Solaris の vmstat および sar コマンド、Windows のタスクマネージャーなどのユーティリティーを使えば、メモリーの使用量を測定できます。

Directory Server の実行時に、パフォーマンスに悪影響を及ぼす継続的なページスワッピングが発生しないだけのメモリーを、最低限提供するようにしてください。サポート対象外ですが Solaris システム用として別途入手可能な MemTool などのユーティリティーは、メモリーが実行中のアプリケーションによってどのように使用され、それらのアプリケーションにどのように割り当てられているかを監視する際に役立つ可能性があります。

システムに追加のメモリーを搭載できない場合に、これまでどおり継続的なページスワップを監視し続けるには、データベースキャッシュやエントリキャッシュのサイズを減らします。heap-high-threshold-size および heap-low-threshold-size サーバー設定を使ってメモリーの使用量を調整することもできますが、ヒープしきい値メカニズムを使うのは最後の手段と考えてください。Directory Server がヒープメモリーを解放するためにほかの処理を遅延させる必要が生じると、パフォーマンスが低下します。

Red Hat Linux システムの場合、/proc/sys/vm/swappiness パラメータを調整して、カーネルがどの程度積極的にメモリーをスワップアウトするかをチューニングできます。swappiness の値が大きいとカーネルがスワップアウトするデータ量が大きいことを意味し、swappiness の値が小さいとカーネルがスワップスペースをできるかぎり使用しないようにすることを意味します。したがって、swappiness 設定値を少なくすることにより、カーネルがメモリーに保持するサーバープロセスが増えてスワップアウトするまでの時間が長くなるので、Directory パフォーマンスが改善される場合があります。システムが単一の Directory Server インスタンス専用である場合は、swappiness をゼロに設定します。システム上で複数の重い処理または複数の Directory Server の並列インスタンスを実行している場合は、swappiness の設定をいろいろ変えて Directory パフォーマンスをテストしてみてください。

Directory Server とローカルディスク容量

ディスクの使用と I/O 能力は、パフォーマンスに強く影響します。多数の変更をサポートする配備では特に、ディスクサブシステムが入出力の障害点になる可能性があります。この節では、Directory Server インスタンスの全体的なディスク容量を見積もるために推奨される方法を示します。

Directory Server やそれがアクセスするデータをネットワークディスク上にインストール「しない」でください。

Directory Server ソフトウェアは、ネットワークに接続されたストレージを NFS、AFS、または SMB 経由で使用することをサポートしません。設定、データベース、およびインデックスファイルはすべて、インストールを終えてからも、常にローカルストレージ上に配置する必要があります。ログファイルはネットワークディスク上に格納できます。

必要なローカルディスク容量に大きな影響を与える要因は、次のとおりです。

• ディレクトリエントリの数

• エントリの平均サイズ

• サーバーデータベースのページサイズの設定 (ディレクトリデータをインポートする場合)

  データベースのページサイズを調整するには、nsslapd-db-page-size 属性を設定します。詳細については、「Directory Server のデータベースページサイズ」を参照してください。

• ディレクトリデータ上で維持されるインデックスの数

• 格納される LDIF、バックアップ、ログ、およびコアファイルのサイズ

インデックスの設定、データベースのページサイズの調整、およびディレクトリデータのインポートが完了したら、instance-path/ の内容のサイズを読み取り、それに予期される LDIF、バックアップ、ログ、およびコアファイルのサイズを追加することで、インスタンスに必要なディスク容量を見積もることができます。また、特にピーク処理時に、測定したサイズがどのくらい増加することが予期されるかを見積もります。ログレベルやログサイズをデバッグ目的で増やす必要が生じた場合のために、数 G バイトの追加容量を errors ログ用として必ず残すようにしてください。

ディレクトリデータに必要なディスクの見積もりは、推定によって行える場合があります。本番時に予期されるのと同量のデータを使って Directory Server に負荷をかけることが現実的ではない場合には、「サンプルディレクトリデータの作成」で示唆したように、より小さなサンプルデータセットに基づいて推定します。使用するディレクトリデータの量が本番時より少ない場合、ほかの測定値についても推定する必要があります。

ローカルディスクがどのくらい高速でなければいけないかを決定する要因は、次のとおりです。

• レプリケーショントラフィックの量など、維持される更新のレベル

• ディレクトリデータが主にキャッシュ内、ディスク上のどちらに存在するか

• アクセスロギングとエラーロギングで使用するログレベル、および監査ログを有効にするかどうか

• ディレクトリデータ、ログ、およびトランザクションログ (更新用) をそれぞれ専用のディスクサブシステム上に配置できるかどうか

• Directory Server がオンライン、オフラインのいずれの状態のときにバックアップを実行するか

通常の運用環境で、使用されるディスクをいっぱいにしないでください。Solaris iostat コマンドなどのツールを使えば、潜在的な入出力障害を特定できます。

ディスクのスループットを増やすには、ディスクサブシステム間でファイルを分散させます。トランザクションログ (dsconf set-server-prop db-log-path:/transaction/log/path)、データベース (dsconf create-suffix --db-path /suffix/database/path suffix-name)、およびログファイル (dsconf set-log-prop path:/log/file/path) にそれぞれ専用のディスクサブシステムを割り当てることを検討してください。さらに、Solaris tmpfs ファイルシステムなどのメモリーベースのファイルシステム上に、データベースキャッシュファイルを配置することを検討してください。そのようなファイルシステムでは、利用可能なメモリーが使い果たされた場合にのみファイルがディスクにスワップされます (例: dsconf set-server-prop db-env-path:/tmp)。メモリーベースのファイルシステム上にデータベースキャッシュファイルを配置する場合には、システムの容量が不足してそのファイルシステムの全体をメモリー内に保持できなくなることのないよう、注意する必要があります。

スループットをさらに増やすには、複数のディスクを RAID 構成にして使用します。Sun StorEdge^TM 製品で提供されているような大容量で不揮発性 I/O バッファーや高パフォーマンスのディスクサブシステムによって、Directory Server のパフォーマンスや稼動時間は大きく向上します。Solaris 10 システムの場合、ZFS を使用してもパフォーマンスが改善する可能性があります。

Directory Server とネットワーク接続

Directory Server はネットワーク集約型アプリケーションです。次の式を使えば、理論的な最大スループットを見積もることができます。この式ではレプリケーションのトラフィックが考慮されていない点に注意してください。

max. throughput = max. entries returned/second x average entry size

Directory Server はピーク時に毎秒 5000 件の検索に応答する必要があり、またサーバーは検索ごとに 1 つのエントリを返すものとします。エントリの平均サイズは 2000 バイトです。理論的な最大スループットは 10M バイトつまり 80M ビットになります。ただし、レプリケーションは考慮していません。しかし 80M ビットの方が、100M ビット Ethernet アダプタ 1 つで実現するスループットよりも大きくなる傾向があります。Directory Server インスタンスのネットワーク可用性を改善するには、システムにより高速な接続を装備するか、複数のネットワークインタフェースを装備してください。Directory Server は、同一プロセス内で複数のネットワークインタフェース上で待機できます。

先の例では、ディレクトリの読み取り時または検索時にクライアントアプリケーションが「すべての」属性を要求するものと仮定していました。一般に、「必要な」属性のみを要求するようにクライアントアプリケーションを設計すべきです。

負荷分散のために、同じネットワーク上で Directory Server をクラスタにする場合は、レプリケーションで新たに生じる負荷がネットワークインフラストラクチャーで対応できることを確認します。広域ネットワーク上でマルチマスターレプリケーションを計画する場合には、その構成のテストを行い、その接続が最小限の待ち時間とゼロに近いパケット損失で十分なスループットを提供できることを確認してください。長い待ち時間と大量のパケット損失はどちらも、レプリケーションの速度を低下させます。さらに、レプリケーショントラフィックがロードバランサを通過するようなトポロジは避けてください。

クライアントが使用可能な Directory Server リソースの制限

Directory Server のデフォルトの設定では、クライアントアプリケーションが必要以上の Directory Server リソースを使用できるようになっています。

次のようなリソースの使い方をすると、ディレクトリのパフォーマンスに悪影響が及ぶ可能性があります。

• 多数の接続を開いたあと、それらをアイドル状態や未使用状態のまま放置する

• インデックスを使用しない高コストの検索を不必要に起動する

• 予定外の巨大なバイナリ属性値を格納する

配備状況によっては、デフォルトの設定を変更すべきでないことがあります。Directory Server のチューニングが不可能な配備では、Directory Proxy Server を使用することで、リソースの制限とサービス拒否攻撃への防備を行なってください。

配備状況によっては、Directory Server の 1 つのインスタンスが、ユーザーメールアプリケーションなどのディレクトリクライアントやメッセージングサーバーといった、クライアントアプリケーションをサポートしなければならないことがあります。そのような状況では、バインド DN ベースのリソース制限を使用することで、ディレクトリ集約型アプリケーションに対して個別の制限を設けることを検討してください。ある特定のアカウントの制限を調整するには、そのエントリ上の属性 nsSizeLimit、nsTimeLimit、nsLookThroughLimit、および nsIdleTimeout を設定します。個々のアカウントのリソース制限を制御する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「各クライアントアカウントのリソース制限の設定」を参照してください。

表 6–1 では、リソース制限のグローバル値を設定するパラメータについて説明します。 表 6–1 の制限は、Directory Manager ユーザーには適用されません。したがって、クライアントアプリケーションが決して Directory Manager ユーザーとして接続することのないようにしてください。

Directory Server が使用するシステムリソースの制限

表 6–2 では、Directory Server インスタンスによるシステムリソースやネットワークリソースの使用方法をチューニングするために使用可能なパラメータについて説明します。

20 + 
4 * (number of databases) +
 (total number of indexes) + 
(value of nsoperationconnectionslimit) * 
(number of chaining backends) + 
ReplDescriptors + 
PTADescriptors + 
SSLDescriptors

Directory Server の基本的なサイジングの例: ディスクとメモリーの要件

この節では、配備用として Directory Server のディスクおよびメモリー要件のサイジングを行う際の初期手順を示す例を取り上げます。この例で使用するシステムは、何か特別な理由があって選択したわけではなく、サイジングタスクをすばやく完了できるだけの処理能力とメモリーを備えているという理由で選択しただけです。これは必ずしも、業務用の推奨システムを表しているとはかぎりません。ただし、これを参考にすれば、本番システムで必要となるメモリーやディスクの容量に関する洞察が得られます。

システムの特性

次のシステム情報は、Solaris Management Console (smc) を使って監視したものです。

• 2 個の AMD64 CPU (2.2 GHz)

• Solaris 10 オペレーティングシステム

• 4G バイトの物理メモリー

• 40G バイトのスワップ

• Directory Server インストール前の使用済み物理メモリー: 700M バイト

• Directory Server インストール前の空き物理メモリー: 3400M バイト

• CPU 使用率: 1 %

• ローカルディスク: ロギング機能付き UFS としてフォーマットされた 1 つのパーティション

この例では、システムは Directory Server 専用でした。その他のユーザーは一人もログインしておらず、デフォルトのシステムプロセスのみが実行されていました。

Directory Server インスタンスの準備

zip ディストリビューションを展開したあと、Directory Server ソフトウェアをローカルディスク上にインストールします。

$ ./dsee_deploy install -c DS -i /local

便宜上、環境変数を次のように設定します。

$ export PATH=/local/ds6/bin:/local/dsrk6/bin:/local/dsee6/bin:${PATH}
$ export DIRSERV_PORT=1389
$ export LDAP_ADMIN_PWF=~/.pwd

ソフトウェアのインストールと環境変数の設定が完了したら、LDAP、LDAPS のそれぞれのデフォルトポートを使って Directory Server インスタンスを作成します。

$ dsadm create -p 1389 -P 1636 /local/ds
Choose the Directory Manager password:
Confirm the Directory Manager password:
$ du -hs /local/ds
610K   /local/ds

サフィックスを作成するまでは、Directory Server インスタンスの使用ディスク容量は 1M バイトを下回っています。

$ dsadm start /local/ds
Server started: pid=8046
$ dsconf create-suffix dc=example,dc=com
Certificate "CN=hostname, CN=1636, CN=Directory Server,
 O=Sun Microsystems" presented by the server is not trusted.
Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more
 details: Y
$ du -hs /local/ds
53M   /local/ds

この例では、特に明記しないかぎり、Directory Server のデフォルト設定に対する追加変更は行いません。

サフィックスに 10,000 件のサンプルディレクトリエントリを設定する

Directory Server Resource Kit の一部として提供されている makeldif コマンドとサンプルファイルを使用すれば、1K バイトから 1M バイトまでのサイズのサンプル LDIF ファイルを作成できます。makeldif コマンドの使用方法を示す例については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「To Install Directory Server Enterprise Edition 6.3 From Zip Distribution」を参照してください。

次の各ファイル内のエントリは、実際の配備時に使用するエントリ数よりは少なめかもしれません。

$ du -h /var/tmp/*
 57M   /var/tmp/100k.ldif
 5.7M   /var/tmp/10k.ldif
 573M   /var/tmp/1M.ldif

これらのファイル内のエントリの例を、次の LDIF に示します。

dn: uid=Aartjan.Aalders,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: Aartjan
sn: Aalders
cn: Aartjan Aalders
initials: AA
uid: Aartjan.Aalders
mail: Aartjan.Aalders@example.com
userPassword: trj49xeq
telephoneNumber: 935-748-6699
homePhone: 347-586-0252
pager: 906-399-8417
mobile: 452-898-9034
employeeNumber: 1000004
street: 64197 Broadway Street
l: Lawton
st: IN
postalCode: 57924
postalAddress: Aartjan Aalders$64197 Broadway Street$Lawton, IN  57924
description: This is the description for Aartjan Aalders.

まず、ディスク上で 5.7M バイトを占有する 10k.ldif の内容をインポートすることで、サイジングを始めます。

$ dsadm stop /local/ds
Server stopped
$ dsadm import -i /local/ds /var/tmp/10k.ldif dc=example,dc=com
…

デフォルトのインデックス作成では、10k.ldif により、インスタンスファイルのサイズが 72M バイト - 53M バイト、つまり 19M バイトだけ増加します。

$ du -hs /local/ds
 72M   /local/ds

さらに別の 5 つの属性にもインデックスを付けると、サイズが約 7M バイト増加します。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsconf reindex dc=example,dc=com
…
## example: Finished indexing.

Task completed (slapd exit code: 0).
$ du -hs /local/ds
 79M   /local/ds

デフォルトのキャッシュ設定でメモリーサイズを監視すると、サフィックスからエントリキャッシュへまだ何も読み込まれていなければ、サーバープロセスは約 170M バイトのメモリーを占有し、そのヒープサイズは約 56M バイトになります。

$ dsadm start /local/ds
Server started: pid=8482
$ pmap -x 8482
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
0000000000437000      61348      55632      55380          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     178444     172604      76532          -

次に、キャッシュに情報を格納してから pmap コマンドの出力を再度確認すると、ヒープが約 10M バイトだけ増加し、プロセスの合計サイズもそれと同じだけ増加しています。

$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8482
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      70564      65268      65024          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     187692     182272      86224          -

この数値を、デフォルトインデックス作成の場合と比較してみましょう。

$ dsconf delete-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsconf reindex dc=example,dc=com
…
## example: Finished indexing.

Task completed (slapd exit code: 0).
$ dsadm stop /local/ds
 Server stopped
$ dsadm start /local/ds
 Server started: pid=8541
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8541
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      70564      65248      65004          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     187680     182240      86192          -

エントリ数がわずか 10,000 件であれば、デフォルトのキャッシュサイズを変更しないでください。

$ dsconf get-server-prop | grep cache
db-cache-size                      :  32M
import-cache-size                  :  64M
$ dsconf get-suffix-prop dc=example,dc=com | grep entry-cache-size
entry-cache-size                   :  10M

デフォルトのエントリキャッシュはサイズが小さいため、エントリ数がわずか 10,000 件であっても、情報が格納されると間違いなく、キャッシュが完全にいっぱいになります。エントリが完全に収まるキャッシュのサイズを確認するには、エントリキャッシュサイズをある大きな値に設定し、データをインポートし直してから、キャッシュに情報を格納します。

$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G
$ dsadm stop /local/ds
Server stopped
$ dsadm import -i /local/ds /var/tmp/10k.ldif dc=example,dc=com
…
$ dsadm start /local/ds
Server started: pid=8806
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8806
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     116644     109996     109780          - rw---    [ heap ]

ここでは、10,000 件のエントリが、約 55M バイト (110 - 55) のエントリキャッシュメモリーを占有しています。

サフィックスに 100,000 件のサンプルディレクトリエントリを設定する

100,000 件のエントリを追加する場合は、データベースやエントリキャッシュ内に収めるべきディレクトリデータの量が増えます。まず、100,000 件のエントリをインポートし、この分量のディレクトリデータで必要となるディスクのサイズを確認します。

$ dsadm import -i /local/ds /var/tmp/100k.ldif dc=example,dc=com
…
$ du -hs /local/ds
 196M   /local/ds

データベース内に格納されている、サフィックス dc=example,dc=com のディレクトリデータは、この時点で約 142M バイトを占有しています。

$ du -hs /local/ds/db/example/
 142M   /local/ds/db/example

データベースキャッシュのサイズを増やせば、この内容がキャッシュ内に収まるようにすることができます。ディレクトリデータの分量が時間の経過とともに増加することが予期される場合には、データベースキャッシュを現在必要とされるよりも大きな値に設定できます。エントリキャッシュサイズも、必要とされるより大きな値に設定できます。エントリキャッシュは、起動時に割り当てられるデータベースキャッシュとは異なり、サーバーがクライアントの要求に応答するたびに増加します。

$ dsconf set-server-prop db-cache-size:200M
$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G

$ dsadm stop /local/ds
 Server stopped
$ dsadm start /local/ds
 Server started: pid=8640
$ pmap -x 8640
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      61348      55404      55148          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb     491984     485736     174620          -

これから、起動時のサーバーインスタンスのヒープは比較的小さいが、データベースキャッシュのメモリーは割り当て済みであることがわかります。プロセスのサイズは、1G バイトの約半分になっています。

$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8640
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     610212     604064     603840          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    1040880    1034428     723360          -

ヒープサイズはこの時点で、情報が格納されたエントリキャッシュを反映したものとなっています。これは、100,000 件の小規模ディレクトリエントリの場合に約 550M バイト増えています。その LDIF はディスク上で 57M バイトを占有していました。

インデックスを 5 つ追加しても、プロセスのサイズはほぼ同じです。データベースキャッシュのサイズに変わりはありません。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsadm stop /local/ds
 Server stopped
$ dsadm import -i /local/ds /var/tmp/100k.ldif dc=example,dc=com
…
$ dsadm start /local/ds
 Server started: pid=8762
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 8762
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     610212     603832     603612          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    1040876    1034192     723128          -

ただし、データベースのサイズは若干大きくなっています。インデックスを追加したことで、データベースのサイズが 142M バイトから 163M バイトへと増加しました。

$ du -hs /local/ds/db/example/
 163M   /local/ds/db/example

サフィックスに 1,000,000 件のサンプルディレクトリエントリを設定する

100,000 件のエントリから 1,000,000 件のエントリに移行すると、4G バイトの物理メモリーを備えたシステム上ではもはや十分な容量を確保できず、すべてのエントリをエントリキャッシュ内に収めることができなくなります。まず、データをインポートし、そのディスク上での占有サイズを確認します。

$ dsadm import -i /local/ds /var/tmp/1M.ldif dc=example,dc=com
…
$ du -hs /local/ds/db/example/
 1.3G   /local/ds/db/example

このインスタンスの存続期間中にディレクトリデータのサイズが約 25 % 増加することが予期されると仮定して、データベースキャッシュのサイズを 1700M バイトに設定します。

$ dsadm start /local/ds
Server started: pid=9060
$ dsconf set-server-prop db-cache-size:1700M
$ dsadm stop /local/ds
Server stopped
$ dsadm start /local/ds
Server started: pid=9118
$ pmap -x 9118
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      65508      55700      55452          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    1882448    1034180      76616          -

データベースキャッシュがこの大きさで、かつ物理メモリーが 4G バイトしかなければ、このサフィックスのエントリキャッシュに格納できるのは、ほんの一部のエントリだけになります。ここでは、エントリキャッシュサイズを 1G バイトに設定してからキャッシュに情報を格納し、プロセスのヒープサイズがどのように変化するかを確認します。

$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:1G
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
 objectclass=\* > /dev/null
Enter bind password:
$ pmap -x 9118
…
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000    1016868    1009852    1009612          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
        total Kb    2883268    2477064    1080076          -

プロセスの合計サイズは 2.8G バイトを超えています。

$ prstat -p 9118
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
  9118 myuser   2816M 2374M sleep   59    0   0:03:26 0.5% ns-slapd/42

これまでのエントリキャッシュサイズに基づいて推定すると、十分な物理メモリーが存在していれば、エントリキャッシュだけで 5.5G バイトまたは 6G バイトが使用されることが予期できます。

インデックスを 5 つ追加してディレクトリデータベースのサイズを確認すると、そのインデックス追加によって、データベースのサイズが約 200M バイト増加したことがわかります。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
 postalCode description
$ dsadm stop /local/ds
Server stopped
$ dsadm import -i /local/ds /var/tmp/1M.ldif dc=example,dc=com
…
$ du -hs /local/ds/db/example
 1.5G   /local/ds/db/example

測定結果

表 6–3 は、この例での測定内容を記録したものです。ここには、サーバープロセスサイズ、デフォルトデータベースキャッシュファイルサイズのいずれも含まれていません。

実際の配備環境で同様の実験を行なった場合の結果はおそらく、ここで示したものと大幅に異なります。

実際の配備時には、エントリ数やインデックスを作成する属性の数が大幅に増える可能性があります。ハードウェアを注文する前に各自で実験的なテストを行い、調整を施すようにしてください。

Directory Server 向けのオペレーティングシステムチューニング

デフォルトのシステム設定でディレクトリサービスのパフォーマンスが最高になるとはかぎりません。この節では、最高のパフォーマンスを実現するにはオペレーティングシステムをどのようにチューニングすればよいかについて説明します。

• 「オペレーティングシステムのバージョンとパッチのサポート」

• 「基本的なセキュリティーチェック」

• 「正確なシステムクロック」

• 「システムリブート時の再起動」

• 「idsktune コマンドによるシステム固有のチューニング」

オペレーティングシステムのバージョンとパッチのサポート

サポートされるオペレーティングシステムの一覧の最新情報は、『Sun Java System Directory Server Enterprise Edition 6.3 リリースノート』を参照してください。

システムの全体的なセキュリティーを維持する必要があります。また、Directory Server の正常な動作を保証する必要もあります。したがって、推奨される最新のシステムパッチ、サービスパック、またはバグフィックスをインストールします。使用するプラットフォームで適用すべき最新パッチの一覧の最新情報については、『Sun Java System Directory Server Enterprise Edition 6.3 リリースノート』を参照してください。

基本的なセキュリティーチェック

この節の推奨事項を実施しても、すべてのリスクを回避できるわけではありません。これらの推奨事項の目的は、典型的なセキュリティー上の危険に歯止めをかけるための簡易チェックリストを提供することです。

• ファイアウォールを使ってシステムを隔離する:可能であれば、Directory Server が稼働するシステムを、ネットワークファイアウォールを使って公的なインターネットから隔離してください。

• デュアルブートを許可しない:本番用の Directory Server が稼働するシステム上でほかのオペレーティングシステムを実行しないでください。アクセスを許可すべきでないファイルへのアクセスを、ほかのシステムが許可する可能性があります。

• 強いパスワードを使用する:少なくとも 8 文字の長さの root パスワードを使用します。パスワードには、コンマ、ピリオドなど、アルファベット以外の文字も含めるようにしてください。

  「パスワード強度チェック」サーバープラグインを使えば、弱いパスワードを拒否できます。dsconf でサーバープロパティー pwd-strong-check-enabled を使えば、このプラグインを有効にできます。

  より長いオペレーティングシステムパスワードを使用することにした場合、システムによるパスワードの処理方法を設定しなければいけない可能性があります。その手順については、オペレーティングシステムのマニュアルを参照してください。

• 安全なユーザーおよびグループ ID をサーバーに使用する: セキュリティー上の理由により、スーパーユーザー特権を使って Directory Server を実行しないでください。

  たとえば、UNIX コマンド groupadd と useradd を使えば、ログイン特権を持たないユーザーとグループを作成できます。次に、このユーザーとグループとしてサーバーを実行できます。

  たとえば、servers という名前のグループを追加するには、次のようにします。

  # groupadd servers

  server1 という名前のユーザーをグループ servers のメンバーとして追加するには、次のコマンドを使用します。

  # useradd -g servers -s /bin/false -c "server1"

  ある特定の配備で、メッセージングサーバーなどのほかのサーバーと Directory Server ファイルを共有する必要が生じる可能性があります。そのような配備では、同じユーザーおよびグループ ID を使ってそれらのサーバーを実行してください。

• コア機能を使用する:デバッグを支援するために、このユーザーおよびグループ ID で実行されているプロセスにコアダンプを許可できます。Solaris コマンド coreadm などのユーティリティーを使用します。たとえば、Directory Server がコアファイルを生成できるようにするには、setuid プロセスにその処理を許可したあと、coreadm の設定を更新します。

  # coreadm -e proc-setid # coreadm -u

  サーバーを起動するスクリプトを作成するとき、その起動スクリプトに次の行を追加できます。この行を追加すると、core.ns-slapd.pid という形式のコアファイルを Directory Server が生成できるようになります。ここで、pid はプロセス ID です。

  coreadm -p core.%f.%p $$

• 不要なサービスを無効にする:より少ないリスクで最高のパフォーマンスを実現するには、システムを Directory Server 専用にします。このガイドの別のところで説明したように、同じマシン上で Directory Service Control Center を実行しないでください。別のサービス、特にネットワークサービスを実行すると、サーバーのパフォーマンスとスケーラビリティーに悪影響が及びます。また、それにより、セキュリティー上の危険も増大します。

  できるだけ多くのネットワークサービスを無効にしてください。Directory Server はファイル共有やその他のサービスを必要としません。IP Routing、Mail、NetBIOS、NFS、RAS、Web Publishing、Windows Network Client などのサービスを無効にしてください。telnet と ftpを無効にすることを検討してください。

  telnet と ftp はほかの多くのネットワークサービスと同じく、セキュリティー上の危険を増大させます。これら 2 つのサービスは特に危険です。なぜなら、これらのコマンドはネットワーク経由でユーザーのパスワードを平文として送信するからです。telnet や ftp を使用する必要に迫られた場合には、セキュリティー保護されたシェルである ssh やセキュリティー保護された FTP である sftp などのクライアントを代わりに使用してください。ネットワークサービスを無効にする方法の詳細については、オペレーティングシステムのマニュアルを参照してください。

  Directory Server インスタンスがネットワークに対してネームサービスを提供しない場合、システムのネームサービスを有効にすることを検討してください。その場合、Directory Server は、ACI を解決する場合などにそのネームサービスを使用します。

正確なシステムクロック

システムクロックがほかのシステムとほぼ同期が取れていることを確認してください。クロックの同期がとれていれば、レプリケーションも正常に行えます。また、ログファイル内の日付やタイムスタンプのシステム間での対応関係も把握しやすくなります。時間情報プロトコル (NTP、Network Time Protocol) クライアントを使って正しいシステム時刻を設定することを検討してください。

システムリブート時の再起動

dsadm コマンドを使えば、システムブート時にサーバーインスタンスを再起動させることができます。たとえば、Solaris 10 および Windows システムでは dsadm enable-service コマンドを使用します。ほかのシステムでは dsadm autostart コマンドを使用します。ネイティブパッケージからインストールしなかった場合には、オペレーティングシステムのマニュアルを参照して、システムブート時にサーバーを起動させる方法を確認してください。

可能であれば、dsadm コマンド、DSCC のいずれかを使って Directory Server を停止します。システムの停止中に Directory Server が突然停止されると、すべてのデータがディスクに正しく書き込まれたことが保証されなくなります。したがって、Directory Server は再起動時に、データベースの完全性を確認する必要があります。このプロセスにはある程度の時間がかかる可能性があります。

さらに、ファイルシステムのロギングオプションの使用を検討してください。ファイルシステムのロギングは一般に、書き込み時のパフォーマンスを改善すると同時に、ファイルシステムチェックの実行に必要な時間を短縮します。クラッシュ時にファイルシステムが正常にマウント解除されなかった場合には、システムはファイルシステムをチェックする必要があります。また、RAID をストレージとして使用することも検討してください。

idsktune コマンドによるシステム固有のチューニング

製品に付属する idsktune(1M) ユーティリティーを使えば、基本的なシステム設定の問題を診断するのに役立つかもしれません。このユーティリティーは、高いパフォーマンスを示すディレクトリサービスをサポートするようにシステムをチューニングするための推奨事項を提示します。このユーティリティーは、推奨事項を示すだけで、実際には何の操作も行いません。適切な権限を持ったシステム管理者が提示された推奨事項に基づいて必要な操作を行なってください。

ユーティリティーを root として実行すると、idsktune はシステムに関する情報を収集します。ユーティリティーは、注意、警告、およびエラーを推奨の対処法とともに表示します。idsktune コマンドがチェックする内容は、次のとおりです。

• オペレーティングシステムとカーネルのバージョンが、このリリースでサポートされている。

• 利用可能なメモリーと利用可能なディスク容量が、通常用途の最小要件を満たしている。

• システムリソースの限度が通常用途の最小要件を満たしている。

• 必須パッチがインストールされている。

Directory Server ソフトウェアを本番用のシステムにインストールする前に、少なくともすべての ERROR 状態を解決してください。

個々の配備要件が最小要件を上回る可能性があります。idsktune ユーティリティーによって最小システム要件として指摘されたリソースよりも多くのリソースを提供することができます。

特定の推奨事項を実施する前に、ローカルネットワークの状態やその他のアプリケーションを考慮してください。ネットワーク設定のチューニングに関する追加のヒントについては、オペレーティングシステムのマニュアルを参照してください。

ファイル記述子の設定

Directory Server は、同時クライアント接続を処理する際にファイル記述子を使用します。したがって、サーバープロセスから利用可能なファイル記述子の最大数が小さければ、同時接続数が制限される可能性があります。したがって、ファイル記述子の数に関する推奨事項は、Directory Server が処理可能な同時接続数に関係します。

Solaris システムの場合、利用可能なファイル記述子の数を設定するには rlim_fd_max パラメータを使用します。利用可能なファイル記述子の数を変更するための詳細な手順については、オペレーティングシステムのマニュアルを参照してください。

伝送制御プロトコル (TCP) の設定

具体的なネットワーク設定はプラットフォームに依存します。一部のシステムでは、TCP 設定を変更することで Directory Server のパフォーマンスを向上させることができます。

まずディレクトリサービスを配備し、次にそれらのパラメータのチューニングを必要に応じて検討します。

この節では、idsktune による TCP 設定関連の推奨事項の背景にある根拠について説明したあと、Solaris 10 システム上でそれらの設定をチューニングする方法を示します。

アクティブでない接続

一部のシステムでは、keepalive パケットの送信間隔を設定できます。この設定によって、アクティブでない、場合によっては切断されている TCP 接続を、どのくらいの期間維持するかを決めることができます。keepalive 間隔の設定値が大きすぎると、すでに切断されたクライアント接続を維持するためにシステムが不要なリソースを使用してしまう可能性があります。大部分の配備では、このパラメータの値を 600 秒に設定します。この値を 600,000 ミリ秒すなわち 10 分に設定することで、Directory Server への同時接続数を増やすことができます。

一方、keepalive 間隔の設定値が小さすぎると、ネットワークの一時的な停止時にもシステムが接続を切断してしまう可能性があります。

Solaris システムでこの時間間隔を設定するには、tcp_keepalive_interval パラメータを使用します。

送信接続

一部のシステムでは、送信接続が確立されるのをシステムがどのくらいの期間待つかを設定できます。設定値が大きすぎると、すぐに応答しないレプリカなどの送信先サーバーとの送信接続を確立する際に、大きな遅延が生じる可能性があります。高速で信頼性の高いネットワーク上のイントラネット配備の場合、このパラメータの値を 10 秒に設定すれば、パフォーマンスの改善が期待できます。一方、低速、低信頼、または WAN 型の接続を含むネットワーク上では、そうした小さな値を使用しないでください。

Solaris システムでこの時間間隔を設定するには、tcp_ip_abort_cinterval パラメータを使用します。

再送信タイムアウト

一部のシステムでは、パケットの再送信間の初期時間間隔を設定できます。この設定は、確認応答のなかったパケットが再送信されるまでの待機時間に影響を与えます。設定値が大きすぎると、失われたパケットのためにクライアントが待たされる可能性があります。高速で信頼性の高いネットワーク上のイントラネット配備の場合、このパラメータの値を 500 ミリ秒に設定すれば、パフォーマンスの改善が期待できます。一方、往復時間が 250 ミリ秒を超えるようなネットワークでは、そうした小さな値を使用しないでください。

Solaris システムでこの時間間隔を設定するには、tcp_rexmit_interval_initial パラメータを使用します。

シーケンス番号

一部のシステムでは、システムが初期シーケンス番号の生成を処理する方法を設定できます。エクストラネットおよびインターネット配備では、シーケンス番号攻撃を避けるため、初期シーケンス番号の生成が RFC 1948 に基づいて行われるようにこのパラメータを設定してください。そうした環境では、ここで説明したほかの TCP チューニング設定は役に立ちません。

Solaris システムでこの動作を設定するには、tcp_strong_iss パラメータを使用します。

Solaris 10 システムでの TCP 設定のチューニング

Solaris 10 システム上で TCP 設定をチューニングするもっとも単純な方法は、単純な SMF サービスを次のようにして作成することです。

• Directory Server チューニング用の SMF プロファイルを作成します。

• 次の xml ファイルを環境に従って編集し、そのファイルを /var/svc/manifest/site/ndd-nettune.xml として保存します。

  <?xml version="1.0"?>
  <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/ service_bundle.dtd.1">
  <!--
      ident    "@(#)ndd-nettune.xml    1.0    04/09/21 SMI"
  -->
  
  <service_bundle type='manifest' name='SUNWcsr:ndd'>
  
  <service
      name='network/ndd-nettune'
      type='service'
      version='1'>
  
  			<create_default_instance enabled='true' />
  
  			<single_instance />
  
  		<dependency
          name='fs-minimal'
          type='service'
          grouping='require_all'
          restart_on='none'>
  			<service_fmri value='svc:/system/filesystem/minimal' />
  		</dependency>
  
  		<dependency
          name='loopback-network'
          grouping='require_any'
          restart_on='none'
          type='service'>
  			<service_fmri value='svc:/network/loopback' />
  		</dependency>
  
  		<dependency
          name='physical-network'
          grouping='optional_all'
          restart_on='none'
          type='service'>
  			<service_fmri value='svc:/network/physical' />
  		</dependency>
  
  		<exec_method
          type='method'
          name='start'
          exec='/lib/svc/method/ndd-nettune'
          timeout_seconds='3' />
  		</exec_method>
  
  		<exec_method
                 type='method'
                 name='stop'
                 exec=':true'
                 timeout_seconds='3' >
  		</exec_method>
  
  		<property_group name='startd' type='framework'>
  			<propval name='duration' type='astring'  value='transient' />
  		</property_group>
  
  		<stability value='Unstable' />
  
  		<template>
  			<common_name>
  				<loctext xml:lang='C'>
  					ndd network tuning
  				</loctext>
  			</common_name>
  			<documentation>
  				<manpage title='ndd' section='1M'
                  manpath='/usr/share/man' />
  			</documentation>
  		</template>
  
  </service>
  
  </service_bundle>

• ndd-nettune.xml の設定内容をインポートする前に、その構文が正しいことを確認します。それには次のコマンドを実行します。

  $ svccfg validate /var/svc/manifest/site/ndd-nettune.xml

• 次のコマンドを実行して設定をインポートします。

  $ svccfg import /var/svc/manifest/site/ndd-nettune.xml

  詳細については、svccfg(1M) のマニュアルページを参照してください。

• 次のシェルスクリプトを /lib/svc/method/ndd-nettune 内にコピーします。

  #!/sbin/sh
  #
  # ident   "@(#)ndd-nettune.xml    1.0     01/08/06 SMI"
  
  . /lib/svc/share/smf_include.sh
  . /lib/svc/share/net_include.sh
  
  # Make sure that the libraries essential to this stage of booting  can be found.
  LD_LIBRARY_PATH=/lib; export LD_LIBRARY_PATH
  echo "Performing Directory Server Tuning..." >> /tmp/smf.out
  /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024
  /usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval 600000
  /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 10000
  /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 60000
  
  
  # Reset the library path now that we are past the critical stage
  unset LD_LIBRARY_PATH

• svcadm を実行して nettune (詳細は svcadm(1M) のマニュアルページを参照) を有効にします。

• svcs -x (詳細は svcs(1) のマニュアルページを参照) を実行します。

Directory Server の物理的な機能

次に、Directory Server のスケーラビリティーの決定要因となる物理的な機能を示します。

• プロセスサイズ。オペレーティングシステムによって異なりますが、32 ビット Directory Server は 2G バイト〜 4G バイトのプロセスサイズをサポートします。64 ビット Directory Server のプロセスサイズは、マシン上で使用可能な物理メモリーの容量によって決まります。128G バイトのプロセスサイズによるテストが完了しています。

• LDAP エントリの数。1 つのサーバーインスタンス上で作成できる LDAP エントリの総数は 2^32 -1 で、4G のエントリということになります。

• 各エントリのサイズ。LDAP サーバー内の 1 つのレコードのサイズは 4G バイトです。これはデータベースそのものによって決まります。エントリのサイズも、LDAP 要求の最大サイズ (maxbersize) によって決まります。この最大サイズは 2G バイトです。

• LDAP 接続の数。LDAP 接続の数は、プロセスが開くことのできるファイル記述子の数によって決まります。開いた接続の数が多すぎるとパフォーマンスが低下するので注意が必要です。

• LDAP サーバー (Berkery DB) のサイズ。LDAP サーバーのサイズは、使用するファイルシステムのサイズによって決まります。

第 7 章 セキュリティー要件の特定

Directory Server Enterprise Edition のデータを保護する方法は、ほかのすべての設計領域に影響します。この章では、セキュリティー要件の分析方法と、その要件を満たすディレクトリサービスの設計方法について説明します。

この章の内容は次のとおりです。

• 「セキュリティーに対する脅威」

• 「セキュリティー手法の概要」

• 「認証方法の決定」

• 「プロキシ承認」

• 「パスワードポリシーの設計」

• 「Windows とのパスワードの同期」

• 「暗号化手法の決定」

• 「ACI によるアクセス制御の設計」

• 「Directory Proxy Server によるアクセス制御の設計」

• 「エントリの安全なグループ化」

• 「ファイアウォールの使用」

• 「root 以外のユーザーとして実行」

• 「その他のセキュリティー関連資料」

セキュリティーに対する脅威

ディレクトリのセキュリティーを脅かすもっとも典型的な脅威は、次のとおりです。

• 盗聴:情報は元の状態のままですが、その機密性が損なわれます。たとえば、だれかが、ユーザーのクレジットカード番号を知ったり、機密性の高い会話を記録したり、極秘情報を傍受したりする可能性があります。

• 不正なアクセス:この脅威には、データ取得操作による、データへの不正なアクセスが含まれます。不正なユーザーが、他のユーザーのアクセスを監視することにより、再利用可能なクライアント認証情報にアクセスする可能性があります。Directory Server Enterprise Edition の認証方法、パスワードポリシー、およびアクセス制御のメカニズムは、不正アクセスの防止に効果があります。

• 改ざん:転送中の情報が、変更または置換されてから宛先に送信されます。たとえば、だれかが商品の注文を変更したり、他人の履歴書を変更したりできます。

  この脅威には、データまたは設定情報の不正な変更が含まれます。ディレクトリが改ざんを検出できない場合、攻撃者がサーバーへのクライアントの要求を変更する可能性があります。また、攻撃者が要求を取り消したり、クライアントへのサーバーの応答を変更したりする可能性もあります。SSL (Secure Socket Layer) プロトコルや、それと同様の技術を利用して、接続の両端で情報に署名することで、この問題は解決できます。

• 偽装:情報が、意図する受信者のふりをした人に渡されます。

  偽装には、なりすましと不当表示の 2 つの形態があります。

  • なりすまし:人またはコンピュータが、ほかのだれかのふりをします。たとえば、ある人がメールアドレス jdoe@example.com を持っているふりをしたり、あるコンピュータが自身を偽って www.example.com という名前のサイトのふりをしたりする可能性があります。

  • 不当表示:人または組織が自身を不当表示します。たとえば、サイト www.example.com が、あたかも家具販売店であるふりをしているが、実際にはクレジットカードによる支払いを受けても決して商品を送らないサイトだったりします。

• サービス拒否:攻撃者が、システムリソースを使用することで、それらのリソースが正規ユーザーによって使用されるのを妨害します。

  サービス拒否攻撃とは、侵入者がディレクトリによるクライアントへのサービスの提供を妨害することです。Directory Server Enterprise Edition では、特定のバインド DN に割り当てるリソースに制限を設定することで、サービスの拒否攻撃を防ぎます。

セキュリティー手法の概要

セキュリティーポリシーは、不正なユーザーによって機密情報が変更または取得されるのを防げる必要がありますが、同時に十分に管理しやすい必要もあります。

Directory Server Enterprise Edition が提供するセキュリティー手法は、次のとおりです。

• 認証:一方が他方の識別情報を検証する方法を提供します。たとえば、LDAP のバインド操作時に、クライアントは Directory Server にパスワードを提示します。「パスワードポリシー」は認証プロセスの一部として、有効期限、長さ、構文など、パスワードが有効とみなされるために満たす必要のある条件を定義します。「アカウントの無効化」は、ユーザーアカウント、アカウントのグループ、またはドメイン全体を無効にして、すべての認証の試行に対して、自動的に拒否するようにします。

• 暗号化:情報の機密性を保護します。データを暗号化すると、データは受信者だけが復号化できるような方法で符号化されます。「Secure Sockets Layer」(SSL) は、転送中の情報を暗号化することでデータの完全性を維持します。送信する情報に暗号化とメッセージダイジェストを適用した場合、受信者は、その情報が転送中に改ざんされていないことを確認できます。「属性暗号化」は、格納された情報を暗号化することでデータの完全性を維持します。

• アクセス制御:さまざまなディレクトリユーザーに与えるアクセス権限を調整し、必要な証明情報またはバインド属性を指定する方法を提供します。

• 監査:ディレクトリのセキュリティーが危険にさらされていないかを確認できます。たとえば、ディレクトリで保持されるログファイルを監査できます。

これらのセキュリティーツールは、ユーザーのセキュリティー設計で組み合わせて使用できます。セキュリティーの設計をサポートするために、レプリケーションやデータの分散など、ほかのディレクトリの機能を使用することもできます。

認証方法の決定

Directory Server Enterprise Edition は、次の認証方法をサポートしています。

• 「匿名アクセス」

• 「単純パスワード認証」

• 「セキュリティー保護された接続での単純パスワード認証」

• 「証明書に基づくクライアント認証」

• 「SASL ベースのクライアント認証」

ユーザーが人間か LDAP 対応アプリケーションかにかかわらず、すべてのユーザーに対して同じ認証メカニズムが適用されます。

この節には、上記の認証メカニズムのほかに、認証に関する次の情報も含まれています。

• 「アカウントの無効化による認証の防止」

• 「グローバルアカウントロックアウトを使用した認証の防止」

• 「外部認証のマッピングおよびサービス」

匿名アクセス

匿名アクセスは、ディレクトリアクセスのもっとも単純な形態です。匿名アクセスは、ユーザーが認証済みかどうかにかかわらず、すべてのディレクトリユーザーに対してデータを利用可能にします。

匿名アクセスでは、だれが検索を実行しているかや、どのような種類の検索が実行されているかを追跡することができません。追跡できるのは、だれかが検索を実行している、ということだけです。匿名アクセスを許可すると、ディレクトリに接続するユーザーはだれでもデータにアクセスできます。データへの匿名アクセスを許可したまま、あるユーザーやグループをそのデータからブロックしようとしても、そのユーザーは、ディレクトリに匿名でバインドすることでそのデータにアクセスできます。

匿名アクセスの特権は制限できます。通常、ディレクトリ管理者は、匿名アクセスに対して読み取り、検索、および比較の特権だけを許可します。また、ユーザー名、電話番号、電子メールアドレスなど、一般的な情報を含む属性のサブセットにアクセスを限定することもできます。政府識別番号、自宅の電話番号や住所、給与情報など、機密データへの匿名アクセスを許可しないでください。

ルート DSE (ベース DN "") への匿名アクセスは必要です。アプリケーションはルート DSE への匿名アクセスを使用することで、サーバーの機能、サポートされているセキュリティーメカニズム、およびサポートされているサフィックスを確認できます。

単純パスワード認証

匿名アクセスが設定されていない場合、クライアントは、Directory Server への認証を行わないとディレクトリのコンテンツにアクセスできません。単純パスワード認証では、クライアントは再使用可能な簡単なパスワードを提供して、サーバーへの認証を行います。

クライアントはバインド操作を使って Directory Server への認証を行いますが、そのバインド操作でクライアントは識別名と資格情報を提供します。サーバーは、そのクライアント DN に対応するエントリを特定したあと、そのクライアントのパスワードがエントリに格納された値に一致するかどうかをチェックします。パスワードが一致すれば、サーバーはそのクライアントを認証します。パスワードが一致しない場合、認証操作は失敗し、クライアントにエラーメッセージが返されます。

単純パスワード認証の欠点は、パスワードが平文として送信されることです。その場合、セキュリティーが損なわれる可能性があります。悪意のあるユーザーが盗聴している場合、そのユーザーは承認されたユーザーを偽装できます。

単純パスワード認証を使えば、ユーザーの認証を容易に行えます。ただし、単純パスワード認証を使用するのは、組織のイントラネットに限定する必要があります。この種類の認証では、エクストラネットを介した取引先との転送やインターネット上での顧客との転送に求められるレベルのセキュリティーは提供されません。

セキュリティー保護された接続での単純パスワード認証

セキュリティー保護された接続では、暗号化によって第三者がデータを読めないようにした上で、Directory Server とクライアントの間でデータを送信します。クライアントは、次のいずれかの方法でセキュリティー保護された接続を確立できます。

• SSL (Secure Socket Layer) を使用してセキュリティー保護されたポートにバインドする

• 匿名アクセスでセキュリティー保護されていないポートにバインドし、Start TLS 制御を送信して TLS (Transport Layer Security) を使用する

どちらの場合も、サーバーにはセキュリティー証明書が必要で、この証明書を信頼するようにクライアントを設定する必要があります。サーバーは、証明書をクライアントに送信することで、公開鍵暗号化方式を使用して「サーバー認証」を行います。その結果、クライアントは目的のサーバーに接続していること、およびサーバーが改ざんされていないことを認識します。

次に、機密保護のため、クライアントとサーバーは、接続を介して送信されるすべてのデータを暗号化します。クライアントは、暗号化された接続でバインド DN とパスワードを送信してユーザー認証を受けます。それ以降の操作はすべて、そのユーザーの ID を使って実行されます。バインド DN がほかのユーザー ID のプロキシ権限を持っている場合には、プロキシ ID を使って操作が実行される可能性もあります。操作の結果がクライアントに返されるときは、すべてが暗号化されます。

証明書に基づくクライアント認証

SSL または TLS 上で暗号化接続を確立する場合、「クライアント認証」を要求するようにサーバーを設定することもできます。クライアントは、ユーザー ID の確認のためにサーバーに証明書を送信する必要があります。バインド DN の決定には、ユーザーの DN ではなく、証明書が使用されます。クライアント認証は、ユーザーの偽装を防ぐ保護で、もっとも安全な接続です。

証明書に基づくクライアント認証は、SSL 層と TLS 層のみで動作します。証明書に基づく認証 ID を LDAP で使用するには、SSL 接続の確立後に SASL EXTERNAL 認証を使用する必要があります。

証明書に基づくクライアント認証を設定するには、dsconf get-server-prop コマンドを使用します。詳細については、dsconf(1M) のマニュアルページを参照してください。

SASL ベースのクライアント認証

SSL または TLS 接続時のクライアント認証では、汎用セキュリティーインタフェースの Simple Authentication and Security Layer (SASL) を使ってクライアントの ID を確立することもできます。Directory Server Enterprise Edition が SASL を通じてサポートするメカニズムは、次のとおりです。

• DIGEST-MD5:このメカニズムは、クライアントから送信されたハッシュ値とユーザーパスワードのハッシュを比較することでクライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワード (平文形式のパスワード) を持つ必要があります。

• GSSAPI:General Security Services API (GSSAPI) は、Solaris オペレーティングシステム上でしか利用できません。これを使えば、Directory Server は Kerberos V5 セキュリティーシステムと対話してユーザーを特定できます。クライアントアプリケーションは Kerberos システムに証明情報を提示し、このシステムがユーザーの ID を Directory Server に返します。

• EXTERNAL:このメカニズムは、SSL や TLS などの外部セキュリティー層によって指定された資格情報に基づいて、LDAP のユーザーを認証します。

詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「クライアントでの SASL DIGEST-MD5 の使用」および『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「クライアントでの Kerberos SASL GSSAPI の使用」を参照してください。

アカウントの無効化による認証の防止

あるユーザーアカウントまたは一連のアカウントを無効にすることで、認証を一時的に防止することができます。アカウントを無効にすると、ユーザーは Directory Server にバインドできず、認証処理が失敗します。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「アカウントの手動でのロック」を参照してください。

グローバルアカウントロックアウトを使用した認証の防止

このバージョンの Directory Server では、パスワードによる認証失敗が監視およびレプリケートされます。これにより、無効なパスワードによる認証の試みがある指定された回数だけ行われたときに、グローバルアカウントロックアウトを速やかに行えます。グローバルアカウントロックアウトは、次のどの場合でもサポートされています。

• クライアントアプリケーションがトポロジ内の単一のサーバーだけにバインドする

• 読み取り専用のコンシューマがトポロジ内に 1 つも含まれていない

• Directory Proxy Server を使ってすべてのバインドトラフィックが制御される

すべてのバインド試行が同一のサーバーに向けられず、ロックアウトデータがレプリケートされるよりも早く、クライアントアプリケーションが複数のサーバー上でバインド試行を実行するような状況を想像してください。最悪の場合、クライアントがバインドを試みたサーバーごとに、指定された回数の試みをクライアントに許可することになります。クライアントアプリケーションを駆動する入力を与えるユーザーが人間である場合には、こうした状況はあまり起こりそうにありません。しかし、トポロジを攻撃するために構築された自動化クライアントであれば、この配備選択を悪用することができます。

優先順位付きレプリケーションを使えば、侵入者検出の際に、非同期レプリケーションの遅れによる影響を最小限に抑えることができます。ただし、バインド試行が指定された回数だけ失敗した直後にアカウントロックアウトを行いたい場合もあります。その状況では、ある特定のエントリ上でのすべてのバインドの試みを、Directory Proxy Server を使って同一のマスターレプリカに配信する必要があります。そのように配信するための Directory Proxy Server の設定方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Operational Affinity Algorithm for Global Account Lockout」を参照してください。

レプリケーショントポロジ内で厳密にローカルなロックアウトポリシーを維持するには、version 5.2 のパスワードポリシーとの互換性を維持する必要があります。その状況では、有効なポリシーがデフォルトのパスワードポリシーであってはいけません。また、読み取り専用のコンシューマにバインドを制限することによっても、ローカルロックアウトを実現することができます。

グローバルアカウントロックアウトの動作方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Global Account Lockout」を参照してください。

外部認証のマッピングおよびサービス

Directory Server は、ネットワークユーザーアカウントを Directory Server ユーザーアカウントに関連付けるユーザーアカウントホストマッピングを提供します。この機能を使えば、両方のユーザーアカウントの管理が容易になります。ホストマッピングは、外部で認証されたユーザーの場合に必要となります。

プロキシ承認

プロキシ承認は、特殊な形態のアクセス制御です。プロキシ承認またはプロキシ認証では、アプリケーションが、特定のユーザー名/パスワードの組み合わせを使ってサーバーへのアクセスを取得することを強制されます。

プロキシ承認では、管理者は、ある通常ユーザーの ID を引き受けることで Directory Server へのアクセスを要求できます。管理者は、自身の資格情報を使ってディレクトリにバインドし、その通常ユーザーの権利を許可されます。この引き受ける ID は、「プロキシユーザー」と呼ばれます。そのユーザーの DN は、「プロキシ DN」と呼ばれます。プロキシユーザーは通常のユーザーとして評価されます。プロキシユーザーのエントリがロックまたは無効化されているか、そのパスワードの有効期限が切れていると、アクセスが拒否されます。

プロキシメカニズムの利点は、Directory Server にアクセスしようとする複数のユーザーに対して、LDAP アプリケーションが単一のバインドを使ってサービスを提供できるという点にあります。各ユーザーがわざわざバインドおよび認証する代わりに、クライアントアプリケーションが Directory Server にバインドし、プロキシの権限を使用します。

詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 7 章「Directory Server のアクセス制御」を参照してください。

パスワードポリシーの設計

パスワードポリシーは、システム内でパスワードがどのように管理されるかを規定した規則の集合です。Directory Server は、デフォルトのパスワードポリシーはもちろん、複数のパスワードポリシーもサポートします。

パスワードポリシーのいくつかの要素は設定可能であるため、組織のセキュリティー要件に合ったポリシーを設計できます。パスワードポリシーの設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 8 章「Directory Server のパスワードポリシー」を参照してください。パスワードポリシーの設定時に利用可能な個々の属性については、pwpolicy(5dssd) のマニュアルページを参照してください。

この節は、次の項目で構成されています。

• パスワードポリシーのオプション

• レプリケーション環境でのパスワードポリシー

• パスワードポリシーの移行

パスワードポリシーのオプション

次のようなパスワードポリシーのオプションがあります。

• デフォルトパスワードポリシーが適用されます。このデフォルトポリシーのパラメータは、変更可能です。

• 別の特殊なパスワードポリシーを特定のユーザーに適用できます。

• CoS およびロール機能を使用することで、別の特殊なパスワードポリシーを一連のユーザーに適用できます。パスワードポリシーは、スタティックグループには適用できません。

レプリケーション環境でのパスワードポリシー

デフォルトパスワードポリシーの設定情報はレプリケートされません。代わりに、それはサーバーインスタンスの設定の一部になっています。デフォルトパスワードポリシーを変更すると、トポロジ内のすべてのサーバー上でそれと同じ変更が施されます。レプリケート「される」パスワードポリシーが必要な場合は、レプリケートされるディレクトリツリー内に、特殊なパスワードポリシーを定義する必要があります。

ユーザーエントリに格納されているパスワード情報のすべてがレプリケートされます。この情報には、現在のパスワード、パスワード履歴、パスワードの有効期限などが含まれます。

レプリケートされた環境では、パスワードポリシーによる次の影響を考慮してください。

• パスワードの期限切れが近づいたユーザーは、パスワードを変更するまで、バインドするすべてのレプリカから警告を受信します。

• あるユーザーがパスワードを変更しても、その新しいパスワードがすべてのレプリカ上で更新されるまでに、しばらく時間がかかる可能性があります。あるユーザーがパスワードを変更してすぐに、新しいパスワードを使ってコンシューマレプリカの 1 つにバインドし直した、といった状況が発生する可能性があります。この場合、レプリカが更新されたパスワードを受信するまで、バインドがおそらく失敗します。この状況を緩和するには、優先順位付きレプリケーションを使ってパスワード変更が最初にレプリケートされるように強制します。

パスワードポリシーの移行

Directory Server Enterprise Edition のパスワードポリシーの設定は、5.x バージョンの Directory Server で提供されていたパスワードポリシーの設定とは異なります。異なるバージョンの Directory Server が稼働するサーバーがトポロジ内に含まれている場合には、『Sun Java System Directory Server Enterprise Edition 6.3 Migration Guide』の「New Password Policy」を参照し、パスワードポリシーの設定の移行方法について確認してください。

Windows とのパスワードの同期

Identity Synchronization for Windows は、Directory Server と Windows との間で、パスワードを含むユーザーアカウント情報を同期させます。Windows Active Directory と Windows NT の両方がサポートされています。Identity Synchronization for Windows は、スケーラビリティーの高いセキュリティー機能の豊富なパスワード同期ソリューションを、小規模、中規模、および大規模企業向けに構築する際に役立ちます。

このソリューションが提供する機能は次のとおりです。

• Active Directory、Windows NT、および Directory Server 間における同期アカウントの作成、変更、無効化、および削除

• ネイティブパスワード変更を同期させるための、プロプライエタリな異種ディレクトリソースとの統合

配備内での Identity Synchronization for Windows の使用方法の詳細については、『Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide 』を参照してください。

暗号化手法の決定

暗号化は、転送中のデータや格納されたデータを保護する際に役立ちます。この節では、次のデータ暗号化手法について説明します。

• 「SSL による接続のセキュリティー保護」

• 「格納された属性の暗号化」

SSL による接続のセキュリティー保護

セキュリティー設計には、ユーザーを特定するための認証スキーマ方式や、情報を保護するためのアクセス制御方式以外の要素も含まれます。サーバーとクライアントアプリケーションとの間でネットワーク経由で送信される情報の完全性も保護する必要があります。

ネットワーク上で安全な通信を可能にするために、SSL (Secure Sockets Layer) 上で LDAP プロトコルと DSML プロトコルの両方を使用することができます。SSL が設定および有効化されると、クライアントはある専用のセキュアポートに接続します。そして、SSL 接続の確立後にすべての通信が暗号化されます。Directory Server と Directory Proxy Server は、Start Transport Layer Security (Start TLS) 制御もサポートします。Start TLS を使えば、クライアントは標準の LDAP ポート上で暗号化接続を開始できます。

Directory Server の SSL と TLS の概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 2 章「Directory Server Security」を参照してください。

格納された属性の暗号化

属性の暗号化は、格納されたデータの保護に関係します。この節では、属性の暗号化機能について説明し、次のトピックを取り上げます。

• 「属性暗号化とは」

• 「属性暗号化の実装」

• 「属性の暗号化とパフォーマンス」

属性暗号化とは

Directory Server Enterprise Edition は、パスワード認証、証明書に基づく認証、SSL、プロキシ承認など、アクセスレベルでデータを保護するためのさまざまな機能を提供しています。ただし、データベースファイル、バックアップファイル、および LDIF ファイルに格納されたデータも保護する必要があります。属性を暗号化する機能を使用することで、格納されている機密情報にユーザーがアクセスできないように保護できます。

属性の暗号化を使えば、特定の属性を暗号化された形式で格納できます。属性の暗号化はデータベースレベルで設定されます。したがって、ある属性を暗号化すると、その属性がデータベース内のすべてのエントリで暗号化されます。属性の暗号化はエントリレベルではなく属性レベルで行われるため、エントリ全体を暗号化するには、すべての属性を暗号化する必要があります。

属性の暗号化を使えば、データを暗号化された形式で別のデータベースにエクスポートすることもできます。属性の暗号化の目的は、格納またはエクスポートされる機密データを保護することです。したがって、この暗号化は常に可逆です。検索要求の結果として返された場合は、暗号化された属性は復号化されます。

次の図は、データベースに追加されるユーザーエントリを示しています。ここで設定されている属性暗号化は、salary 属性を暗号化します。

図 7–1 属性暗号化のロジック

属性暗号化の実装

属性の暗号化機能は、広範な暗号化アルゴリズムをサポートしています。異なるプラットフォーム間での移植性が保証されています。属性の暗号化は追加のセキュリティー手段として、サーバーの SSL 証明書の非公開鍵を使って自身の鍵を生成します。その後、この鍵は、暗号化および復号化処理を実行するために使用されます。属性を暗号化できるためには、サーバーが SSL 上で稼働している必要があります。SSL 証明書とその非公開鍵はデータベース内に安全に格納され、パスワードで保護されます。この鍵データベースのパスワードはサーバーへの認証時に必要になります。サーバーは、この鍵データベースのパスワードにアクセスできるユーザーであれば、だれもが復号化されたデータのエクスポートを承認されたものとみなします。

属性の暗号化が保護するのは格納された属性だけである点に注意してください。これらの属性をレプリケートする場合には、転送中の属性を保護できるよう、SSL 上でレプリケーションを設定する必要があります。

属性の暗号化を使用する場合、バイナリコピー機能を使ってあるサーバーから別のサーバーを初期化することはできません。

属性の暗号化とパフォーマンス

属性の暗号化を使えばデータのセキュリティーを高められますが、この機能はパフォーマンスに影響を与えます。属性の暗号化は、機密性の特に高い属性を暗号化するためだけに使用してください。

機密データには、インデックスファイル経由で直接アクセスできます。したがって、暗号化する属性に対応するインデックスキーを暗号化することで、それらの属性が完全に保護されるようにする必要があります。インデックスキーを暗号化することによる追加コストがないとしても、インデックスを作成すること自体がすでにパフォーマンスに影響を及ぼします。したがって、データベースにはじめてデータをインポートまたは追加する「前」に、属性の暗号化を設定してください。こうすることで、暗号化された属性には最初からインデックスが付けられます。

ACI によるアクセス制御の設計

アクセス制御では、特定の情報へのアクセス権を一部のクライアントに与え、その他のクライアントには与えないように指定することができます。アクセス制御は、1 つまたは複数のアクセス制御リスト (ACL) を使用して実装します。ACL は、指定されたエントリとその属性へのアクセス権を許可または拒否する一連のアクセス制御命令 (ACI) から構成されます。アクセス権には、読み取り、書き込み、検索、プロキシ、追加、削除、比較、インポート、およびエクスポートを行う機能が含まれます。

ACL を使用すると、次の項目に対する権限を設定できます。

• ディレクトリ全体

• ディレクトリの特定のサブツリー

• ディレクトリ内の特定のエントリ

• 特定のエントリの属性セット

• 特定の LDAP 検索フィルタにマッチするすべてのエントリ

また、特定のユーザー、グループに属するすべてのユーザー、およびディレクトリのすべてのユーザーに対する権限を設定できます。さらに、IP アドレスや DNS 名など、ネットワークの場所に対してアクセス権を定義することもできます。

この節では、Directory Server のアクセス制御メカニズムの概要を説明します。アクセス制御や ACI の設定方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 7 章「Directory Server のアクセス制御」を参照してください。アクセス制御メカニズムのアーキテクチャーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「How Directory Server Provides Access Control」を参照してください。

デフォルト ACI

Directory Server のデフォルト動作は、アクセスを許可する特定の ACI が存在していないかぎりアクセスを拒否する、というものです。したがって、ACI が 1 つも定義されていなければ、サーバーへのすべてのアクセスが拒否されます。

Directory Server をインストールしたり新しいサフィックスを追加したりすると、ルート DSE 内にいくつかのデフォルト ACI が自動的に定義されます。この ACI は、セキュリティー要件に合うように変更できます。

デフォルト ACI やそれらの変更方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「How Directory Server Provides Access Control」を参照してください。

ACI の適用範囲

Directory Server 6.x には、ACI の適用範囲に対する主な変更が 2 つ含まれています。

• ACI の適用範囲を指定する機能:Directory Server 5.x では、ACI の適用範囲を指定できませんでした。ACI は自動的に、その ACI の格納先となるエントリとそのすべてのサブツリーに対して適用されていました。このため、場合によっては「拒否」ACI を使用する必要がありました。拒否 ACI と許可 ACI が単一のエントリに適用される場合は特に、拒否 ACI の管理が困難になる可能性があります。

  Directory Server 6.x では ACI の適用範囲を指定できます。つまり、「許可」ACI を使ってアクセス制御を行えます。拒否ベースのアクセス制御の使用が避けられなかったり、そうしたアクセス制御を使用したほうが設定が容易になったりする場合もありますが、拒否 ACI の使用は基本的にはお勧めできません。ACI の適用範囲の指定方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 7 章「Directory Server のアクセス制御」を参照してください。

• ルート ACI がルートエントリとそのサブツリー全体に適用されるようになった:Directory Server 5.x では、ルート DSE に格納された ACI はルートエントリのみに適用され、その子には適用されませんでした。ほかの任意のエントリ内の ACI は、その ACI の格納先エントリとそのすべてのサブツリーに対して適用されていました。Directory Server Enterprise Edition では、ルートエントリ内に配置された ACI が、ほかの任意の場所に配置された ACI と同様に扱われます。

  新しいルート ACI には、明確なセキュリティー上の利点が 1 つあります。管理者は、特定の操作を実行する際に Directory Manager としてバインドする必要がなくなりました。SSL などの強い認証によるバインドを管理者に強制できるようになりました。ルートエントリ「だけに」適用することを目的とした ACI を設定するには、その ACI の適用範囲を具体的に base に設定する必要があります。

ACI の適用範囲の変更は移行に影響を与えます。5.x バージョンの Directory Server から Directory Server 6.x に移行する場合には、『Sun Java System Directory Server Enterprise Edition 6.3 Migration Guide』の「Changes to ACIs」を参照してください。

実効権限に関する情報の取得

Directory Server 6.x が提供するアクセス制御モデルでは、異なる多くのメカニズムを通じてユーザーにアクセスを許可できます。しかしながら、この柔軟性のために、セキュリティーポリシーがかなり複雑になる可能性があります。IP アドレス、マシン名、時刻、認証方法など、いくつかのパラメータを使用すれば、あるユーザーのセキュリティーコンテキストを定義できます。

セキュリティーポリシーを単純化するために、Directory Server では、指定されたディレクトリエントリおよび属性に対する、ある特定のユーザーの実行アクセス権限を要求および一覧表示できます。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「実行権限の表示」を参照してください。

ACI の使用に関するヒント

次の各ヒントを参考にすれば、ディレクトリのセキュリティーモデルの単純化とパフォーマンスの改善を図れる可能性があります。

• ディレクトリ内の ACI の数を最小化し、可能であればマクロ ACI を使用する。

  Directory Server は 50,000 件を超える ACI を評価可能ですが、多数の ACI 文を管理するのは容易ではありません。また、過剰な ACI はメモリー消費にも悪影響を及ぼす可能性があります。

• 許可権限と拒否権限のバランスを図る。

  デフォルトの規則は、アクセスを具体的に許可されていないすべてのユーザーのアクセスを拒否することです。ただし、ツリーのルートの近くでアクセスを許可する 1 つの ACI を使用し、リーフエントリの近くで少数の拒否 ACI を使用すれば、ACI の数を減らすことができます。このようにすると、最下位のエントリの近くでアクセスを許可する ACI が必要以上に多くなることがなくなります。

• ACI では最小の属性セットを指定する。

  オブジェクトの属性の一部でアクセスを許可または拒否する場合、許可または拒否する属性の最小リストを決めます。次に、最小の属性リストを管理するように ACI を表します。

  たとえば、ユーザーオブジェクトクラスに多くの属性が含まれている場合を考えます。いくつかの属性だけをユーザーが更新できるようにするには、その少数について書き込み権限を許可する ACI を作成します。1 つか 2 つの属性以外のすべてをユーザーが更新できるようにする場合は、それらの 1 つか 2 つの属性について書き込み権限を拒否する ACI を作成します。

• LDAP 検索フィルタは慎重に使用する。

  検索フィルタは、アクセス管理対象のオブジェクトを直接指定しません。したがって、特にディレクトリが複雑になるにつれて、検索フィルタによって予期しない結果が得られる可能性があります。ACI 内で検索フィルタを使用する場合、その同じフィルタを使って ldapsearch 操作を実行してください。このアクションにより、その変更の結果がユーザーのディレクトリにとって何を意味するのかを確認できます。

• ディレクトリツリーの別の部分で ACI を重複させない。

  オーバーラップしている ACI を探します。グループ書き込みアクセス権を commonName および givenName 属性に対して許可する ACI が、ディレクトリのルート位置に存在するとします。さらに、それと同じグループ書き込みアクセス権を commonName 属性に対してだけ許可する別の ACI も存在するとします。この場合、そのグループに対して 1 つの属性のみの書き込みアクセス権を与えるように、ACI を修正することを検討してください。

  ディレクトリが複雑になるほど、ACI のオーバーラップが間違って発生する確率も高くなります。ACI のオーバーラップを回避すれば、セキュリティーの管理が容易になり、ディレクトリ内の ACI の合計数も減少します。

• ACI に名前を付ける。

  ACI に名前を付けることは省略可能ですが、各 ACI に意味のある短い名前を付ければ、セキュリティーモデルの管理が容易になります。

• ユーザーエントリの標準属性を使用して、アクセス権限を決める。

  可能なかぎり、すでに標準ユーザーエントリの一部となっている情報を使用して、アクセス権限を決めてください。特別な属性を作成する必要がある場合は、それらの属性をロールまたはサービスクラス (CoS) の定義の一部として作成することを検討します。ロールと CoS の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」を参照してください。

• ACI を互いにできるだけ近い位置にまとめる。

  ACI の配置をディレクトリのルートポイントとディレクトリの主な分岐点に限定します。ACI を編成してグループにまとめると、ACI リストの全体を管理しやすくなり、ACI の合計数を最小に保つことができます。

• 二重否定は使用しないようにする (バインド DN が cn=Joe と等しくない場合の書き込みの拒否など)。

  サーバーはこの構文を理解できますが、管理者にとっては混乱の元となります。

接続規則によるアクセス制御の設計

接続規則を使えば、選択されたクライアントが Directory Server への接続を確立するのを防ぐことができます。接続規則の目的は、悪意のあるクライアントや不適切に設計されたクライアントによって引き起こされるサービス拒否攻撃を防ぐことです。そうしたクライアントは Directory Server に接続し、そのサーバーを要求で溢れさせます。

接続規則は TCP レベルで確立されますが、それは「TCP ラッパー」を定義することで行われます。TCP ラッパーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「TCP ラップによるクライアントホストのアクセス制御」を参照してください。

Directory Proxy Server によるアクセス制御の設計

Directory Proxy Server の接続ハンドラは、サーバーに接続を試みるクライアントの分類を可能にするアクセス制御の方法を提供します。この方法では、接続がどのように分類されたかに基づいて、実行可能な操作を制限できます。

この機能を使えば、ある指定された IP アドレスから接続するクライアントだけにアクセスを制限したりすることができます。次の図は、Directory Proxy Server の接続ハンドラを使って特定の IP アドレスからの書き込み操作を拒否する方法を示したものです。

図 7–2 Directory Proxy Server の接続ハンドラのロジック

接続ハンドラの動作

接続ハンドラは、一連の条件と一連のポリシーから構成されます。Directory Proxy Server は、ある接続の起点属性をクラスの条件とマッチングさせることで、その接続のクラスメンバーシップを決定します。接続があるクラスに一致すると、Directory Proxy Server はそのクラスに格納されているポリシーをその接続に適用します。

接続ハンドラの条件には、次の情報を含めることができます。

• クライアントの物理アドレス

• ドメイン名またはホスト名

• クライアント DN のパターン

• 認証方法

• SSL

接続ハンドラには次のポリシーを関連付けることができます。

• 管理制限ポリシー:たとえば、ある特定クラスのクライアントからの接続数を制限できるようにします。

• コンテンツ適応ポリシー:属性の名前変更など、接続が実行できる操作の種類を制限できるようにします。

• データ分散ポリシー:ある接続で特定の配布方式を使用できるようにします。

Directory Proxy Server の接続ハンドラやその設定方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 20 章「Connections Between Clients and Directory Proxy Server」を参照してください。

エントリの安全なグループ化

ロールと CoS では、セキュリティーに関する特別な考慮が必要となります。

ロールの安全な使い方

セキュリティーの状況によっては、ロールの使用が適していない場合があります。ロールを作成するときは、エントリへのロールの割り当てやエントリからのロールの削除がどの程度簡単にできるかを考慮します。ユーザーは場合によっては、自身をロールに追加したりロールから削除したりできるべきです。ただし、一部のセキュリティーコンテキストでは、そうしたオープンなロールは不適切です。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Server Roles」を参照してください。

CoS の安全な使い方

読み取り用のアクセス制御は、エントリの実際の属性と仮想属性の両方に適用されます。サービスクラス (CoS) メカニズムによって生成される仮想属性は、通常の属性と同様に読み取られます。したがって、仮想属性には、同じ方法で読み取り保護を付与すべきです。ただし、CoS 値をセキュリティー保護するには、CoS 値が使用する次のすべての情報ソースを保護する必要があります。定義エントリ、テンプレートエントリ、およびターゲットエントリ。更新操作についても同じことが言えます。各情報ソースから生成される値を保護するには、それらのソースへの書き込みアクセスを制御する必要があります。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」を参照してください。

ファイアウォールの使用

ファイアウォールテクノロジは通常、内部ネットワークを出入りするネットワークトラフィックをフィルタリングまたはブロックするために使用されます。LDAP 要求が境界ファイアウォールの外側から送られてくる場合には、ファイアウォールの通過を許可するポートとプロトコルを指定する必要があります。

指定するポートとプロトコルはディレクトリのアーキテクチャーによって異なります。一般的な規則として、ポート 389 および 636 上の TCP および UDP 接続を許可するように、ファイアウォールを設定する必要があります。

Directory Server が稼働しているサーバーに、ホストベースのファイアウォールをインストールできます。ホストベースのファイアウォールの規則は、境界防御ファイアウォールの規則に似ています。

root 以外のユーザーとして実行

サーバーインスタンスを root 以外のユーザーとして作成および実行できます。サーバーインスタンスを root 以外のユーザーとして実行することで、悪用によって生じる可能性のあるあらゆる損害を制限できます。さらに、root 以外のユーザーとして実行されるサーバーは、オペレーティングシステムのアクセス制限メカニズムの処理対象となります。

その他のセキュリティー関連資料

セキュリティー保護されたディレクトリの設計については、以下のリソースを参照してください。

• Sun Developer セキュリティーリソース http://developers.sun.com/techtopics/security/index.html

• 『Understanding and Deploying LDAP Directory Services』。T. Howes, M. Smith, G. Good、Macmillan Technical Publishing 発行、1999 年

• SecurityFocus.com http://www.securityfocus.com/

• Computer Emergency Response Team (CERT) Coordination Center http://www.cert.org/

第 8 章 管理と監視の要件の特定

Directory Server Enterprise Edition の管理は、5.x バージョンの Directory Server から大幅に変更されています。これらの変更は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』で詳細に説明されています。

この章では、これらの変更の概要を示したあと、配備の計画段階で行う必要のある管理上の決定について説明します。

• 「Directory Server Enterprise Edition の管理モデル」

• 「バックアップと復元のポリシーの設計」

• 「ロギング方法の設計」

• 「監視戦略の設計」

• 「Directory Editor を使用したデータ管理」

Directory Server Enterprise Edition の管理モデル

Directory Server Enterprise Edition では、管理者がインスタンスの作成や管理をより細かく制御できるようになりました。この制御は、2 つの新しいコマンド dsadm と dsconf を使用して実現されます。これらのコマンドは、以前の directoryserver コマンドで提供されていたすべての機能に加え、追加の機能を提供します。

dsadm コマンドを使用すると、管理者は Directory Server インスタンスを作成、起動、および停止できます。このコマンドは、Directory Server インスタンスへのファイルシステムアクセスが必要なすべての操作を行います。このコマンドは、インスタンスをホストするマシン上で実行してください。インスタンスへの LDAP アクセスまたはエージェントへのアクセスが必要な操作は実行しません。

新しい管理モデルでは、Directory Server インスタンスの 「ServerRoot」への関連付けはなくなりました。各 Directory Server インスタンスは、通常のスタンドアロンディレクトリと同じ方法で操作できるスタンドアロンディレクトリです。

dsconf は、cn=config への書き込みアクセスが必要な管理操作を行います。dsconf コマンドは、LDAP クライアントです。アクティブな Directory Server インスタンス上でのみ実行できます。このコマンドはリモートから実行することができ、それによって、管理者は複数のインスタンスを単一のリモートマシンから設定できます。

Directory Proxy Server は、dpadm と dpconf という、2 つの類似のコマンドを提供しています。dpadm コマンドを使用すると、管理者は Directory Proxy Server インスタンスを作成、起動、および停止できます。dpconf コマンドを使用すると、管理者は LDAP を使用して Directory Proxy Server を設定し、Directory Proxy Server を介して Directory Server 構成にアクセスできます。

これらのコマンド行ユーティリティーに加えて、Directory Server Enterprise Edition は Java Web コンソールにも統合されています。このコンソールを使用すると、Directory Server Enterprise Edition やその他の Sun 製品を集中管理のユーザーインタフェースから管理できます。Directory Service Control Center (DSCC) は、Directory Server と Directory Proxy Server の管理専用に用意された、Java Web コンソールのサービスです。DSCC は、コマンド行ユーティリティーと同じ機能のほか、複数のサーバーを一度に設定できるウィザードを提供しています。DSCC はまた、レプリケーショントポロジをグラフィカルに監視できる、レプリケーショントポロジの描画ツールも提供します。このツールでは、個々のマスター、ハブ、コンシューマや、それらの間のレプリケーションアグリーメントがリアルタイムに表示されるため、レプリケーションの監視が簡略化されます。

リモート管理

前の節で説明した Directory Server Enterprise Edition の管理モデルでは、トポロジ内の任意の Directory Server または Directory Proxy Server のリモート管理を行うこともできます。サーバーは、コマンド行ユーティリティーと Java Web コンソールの両方を使用して、リモートから管理できます。

dsadm および dpadm ユーティリティーはリモートからは実行できません。これらのユーティリティーは、管理対象のサーバーインスタンスと同じマシンにインストールして実行してください。dsadm と dpadm で提供される機能の詳細については、dsadm(1M) と dpadm(1M) のマニュアルページを参照してください。

dsconf および dpconf ユーティリティーは、リモートから実行できます。dsconf と dpconf で提供される機能の詳細については、dsconf(1M) と dpconf(1M) のマニュアルページを参照してください。

次の図は、新しい管理モデルによるリモート管理の容易性を示しています。この図は、コンソールコマンドや設定コマンドを Directory Server および Directory Proxy Server インスタンスからリモートにインストールして実行できることを示しています。管理コマンドは、これらのインスタンスに対してローカルに実行する必要があります。

図 8–1 Directory Server Enterprise Edition の管理モデル

バックアップと復元のポリシーの設計

データ破壊やデータ損失をともなう障害の状況では、データの最新のバックアップを保有していることが不可欠です。できるだけ、ほかのサーバーからのサーバーの再初期化は避けてください。データのバックアップ方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 9 章「Directory Server のバックアップと復元」を参照してください。

ここでは、バックアップと復元の戦略を計画する上で考慮すべき事項の概要について説明します。

高レベルのバックアップと復旧の原則

バックアップ戦略を設計するときは、次の高レベルの原則を適用します。

• バックアップする必要のあるデータを特定します。

  Directory Server Enterprise Edition の場合、このデータには次のものが含まれます。

  • 共有されているバイナリとプラグイン

  • 証明書データベースのファイル

  • 設定ファイル

  • ログファイルと更新履歴ログデータベース

  • スキーマファイル

  • ユーザーデータ

• バックアップと復元の戦略に、ハードウェア、オペレーティングシステム、およびソフトウェアコンポーネントが含まれている必要があります。

• バイナリバックアップまたは LDIF バックアップを保持するかどうかを決定します。

  一般には、この両方を保持することをお勧めします。詳細については、「バックアップ方法の選択」および 「復元方法の選択」を参照してください。

• バックアップおよび復旧ツール関連の自動化を確立するとともに、自動スクリプトが保守されている必要があります。

  この戦略によって、緊急にバックアップからの復元が必要になった場合の不必要な遅延が回避されます。

• 保持とローテーションの戦略を決定します。

  この戦略には、バックアップを実行する頻度と、バックアップを保持する期間が含まれます。バックアップの保持とローテーションを決定する場合は、パージ遅延と、それによる、レプリケートされるトポロジ内のバックアップへの影響に注意してください。サプライヤで変更が発生すると、それらの変更は更新履歴ログに記録されます。更新履歴ログを空にするための方法がないと、そのサイズは、すべての使用可能なディスク容量が更新履歴ログによって消費されるまで増え続けます。デフォルトでは、これらの変更は 7 日ごとに消去されます。この期間をパージ遅延と呼びます。変更が消去されると、その変更をレプリケートすることはできなくなります。そのため、データベースは、少なくともパージ遅延と同じ頻度でバックアップされる必要があります。

• 単にシステムのバックアップと復旧を実行するのではなく、Directory Server Enterprise Edition で提供されているバックアップおよび復旧ツールを使用します。

バックアップ方法の選択

Directory Server Enterprise Edition では、バイナリバックアップと、LDIF ファイルへのバックアップという 2 つの方法でデータをバックアップできます。どちらの方法にも利点と制限があるため、効果的なバックアップ戦略を計画するには、それぞれの方法について理解することが役立ちます。

バイナリバックアップ

バイナリバックアップは、データベースファイルのコピーを生成するものであり、ファイルシステムレベルで実行されます。バイナリバックアップの出力は、すべてのエントリ、インデックス、更新履歴ログ、トランザクションログを含むバイナリファイルのセットです。バイナリバックアップには、設定データは含まれません。

バイナリバックアップは、次のいずれかのコマンドを使用して実行されます。

• dsadm backup はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf backup は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

バイナリバックアップには、次のような利点があります。

• すべてのサフィックスを一度にバックアップできる。

• LDIF へのバックアップと比較して、バイナリバックアップは格段に高速である。

• レプリケーション更新履歴ログがバックアップされる。

バイナリバックアップには、1 つの制限があります。バイナリバックアップからの復元は、「同一の」設定のサーバーだけでしか実行できません。

この制限は次を意味します。

• 両方のマシンが同じハードウェア、同じオペレーティングシステム (サービスパックやパッチも含まれる) を使用している必要がある。

• 両方のマシンに同じバージョンの Directory Server (32 ビットまたは 64 ビットのバイナリ形式、サービスパック、パッチレベルも含まれる) がインストールされている必要がある。

• 両方のサーバーは、同じサフィックスに分岐する同じディレクトリツリーを持つ必要がある。すべてのサフィックスのデータベースファイルをまとめてコピーする必要があり、サフィックスを個別にコピーすることはできない。

• 両方のサーバーの各サフィックスには同じインデックス (仮想リスト表示 (VLV) インデックスも含まれる) が設定されている必要がある。サフィックスのデータベースファイルの名前は同じである必要がある。

• 各サーバーに、レプリカとして同じサフィックスが設定されている必要があります。部分レプリケーションが設定されている場合、部分レプリケーションはすべてのマスターサーバーで同じように設定されている必要がある。

• どちらのサーバーでも、属性の暗号化は使用できません。

少なくとも、整合性のあるマシンの各セットに対して定期的なバイナリバックアップを実行してください。整合性のあるマシンとは、前述のように同一の設定を持つマシンのことです。

ローカルバックアップからの復元の方が簡単なため、各サーバーでバイナリバックアップを実行してください。

この章の残りの図では、次の略語を使用します。

次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 と M3 でバイナリバックアップが行われます。障害が発生した場合は、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。M1 と M2 を M3 のバイナリバックアップから復元することはできません。M3 と M4 を M1 のバイナリバックアップから復元することはできません。

図 8–2 オフラインのバイナリバックアップ

バイナリバックアップのコマンドの使用方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「バイナリバックアップ」を参照してください。

LDIF へのバックアップ

LDIF へのバックアップはサフィックスレベルで行われます。LDIF へのバックアップの出力は、サフィックスに含まれているデータのコピーである、フォーマットされた LDIF ファイルです。このため、このプロセスはバイナリバックアップと比較して時間がかかります。

LDIF へのバックアップは、次のいずれかのコマンドを使用して実行されます。

• dsadm export はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf export は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

これらのコマンドの実行時に -Q オプションを指定しないかぎり、レプリケーション情報はバックアップされます。

LDIF へのバックアップでは、dse.ldif 設定ファイルはバックアップされません。以前の設定を復元できるようにするには、このファイルを手動でバックアップしてください。

LDIF へのバックアップには、次のような利点があります。

• LDIF へのバックアップは、設定に関係なくどのサーバーからも実行できる。

• LDIF バックアップからの復元は、設定に関係なくどのサーバーからも実行できる。

LDIF へのバックアップには、1 つの制限があります。迅速なバックアップと復元が必要な状況では、LDIF へのバックアップでは時間がかかり過ぎる可能性があります。

トポロジの単一マスターで、レプリケートされた各サフィックスを LDIF に定期的にバックアップする必要があります。

次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadm export が実行されています。

図 8–3 LDIF へのオフラインのバックアップ

LDIF へのバックアップのコマンドの使用方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「LDIF へのバックアップ」を参照してください。

復元方法の選択

Directory Server Enterprise Edition では、バイナリ復元と、LDIF ファイルからの復元という 2 つの方法でデータを復元できます。バックアップ方法と同様に、どちらの方法にも利点と制限があります。

バイナリ復元

バイナリ復元では、データベースレベルでデータがコピーされます。バイナリ復元は、次のいずれかのコマンドを使用して実行されます。

• dsadm restore はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf restore は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

バイナリ復元には、次のような利点があります。

• すべてのサフィックスを一度に復元できる。

• レプリケーション更新履歴ログが復元される。

• LDIF ファイルからの復元と比較して、バイナリ復元は格段に高速である。

バイナリ復元には、次のような制限があります。

• 復元は、同一の設定を持つサーバーでしか実行できない (「バイナリバックアップ」を参照)。バイナリ復元機能を使用したデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「バイナリ復元」を参照してください。

• データベースが破壊されていることに気付かずにバイナリバックアップを実行した場合は、破壊されたデータベースが復元される危険性がある。バイナリバックアップは、データベースの現在の状態をありのままにコピーします。

マシンの設定が同一であり、実行時間を極力減らすことを一番の目的としている場合は、推奨される復元方法はバイナリ復元になります。

次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。

図 8–4 オフラインのバイナリ復元

LDIF からの復元

LDIF ファイルからの復元は、サフィックスレベルで実行されます。このため、このプロセスはバイナリ復元と比較して時間がかかります。LDIF からの復元は、次のいずれかのコマンドを使用して実行できます。

• dsadm import はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf import は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

LDIF ファイルからの復元には、次のような利点があります。

• このコマンドは、設定に関係なくどのサーバーからも実行できる。

• レプリケーショントポロジに関係なく、ディレクトリサービス全体の配備に単一の LDIF ファイルを使用できる。予定されているビジネスニーズに合わせてディレクトリサービスをダイナミックに拡張または縮小する場合に、この機能は特に便利である。

LDIF ファイルからの復元には、1 つの制限があります。迅速な復元が必要な状況では、この方法は時間がかかり過ぎる場合があります。LDIF ファイルからのデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「LDIF ファイルからのデータのインポート」を参照してください。

次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadmin import が実行されています。

図 8–5 LDIF からのオフラインの復元

ロギング方法の設計

ロギングは、個別のサーバーレベルで管理および設定されます。ロギングは、デフォルトで有効になっていますが、配備の要件に従って再設定したり無効にしたりすることができます。ロギング方法の設計は、ハードウェア要件の計画に役立ちます。詳細については、「Directory Server のハードウェアサイジング」を参照してください。

ここでは、Directory Server Enterprise Edition のロギング機能について説明します。

ロギングポリシーの定義

トポロジ内の各 Directory Server は、ロギング情報を次の 3 つのファイルに格納します。

• アクセスログ: サーバーに接続するクライアントと、要求された操作をリストします。

• エラーログ: サーバーエラーに関する情報を提供します。

• 監査ログ: サフィックスの変更と設定の変更に関する詳細情報を提供します。

トポロジ内の各 Directory Proxy Server は、ロギング情報を次の 2 つのファイルに格納します。

• アクセスログ: Directory Proxy Server に接続するクライアントと、要求された操作をリストします。

• エラーログ: サーバーエラーメッセージが含まれています。

Directory Server と Directory Proxy Server の両方のログファイルを次の方法で管理できます。

• ログファイル作成ポリシーの定義

• ログファイル削除ポリシーの定義

• ログファイルの手動での作成と削除

• ログファイルのアクセス権の定義

ログファイル作成ポリシーの定義

ログファイル作成ポリシーを使用すると、現在のログを定期的に保存し、新しいログファイルを開始することができます。ログファイル作成ポリシーは、Directory Control Center からか、またはコマンド行ユーティリティーを使用して Directory Server と Directory Proxy Server に対して定義できます。

ログファイル作成ポリシーを定義する場合は、次の点を考慮してください。

• 保持するログの個数

  このログ数に達すると、新しいログを作成する前に、フォルダ内のもっとも古いログファイルが削除されます。この値が 1 に設定されていると、ログはローテーションされず、かぎりなく増大します。

• 各ログファイルの最大サイズ (M バイト単位)

  ログファイルがこの最大サイズか、または次の項目で定義される最長有効期間に達すると、そのファイルは保存され、新しいログファイルへのロギングが開始されます。

• 現在のログファイルを保存する頻度

  デフォルトは毎日です。

• ログファイルをローテーションする 1 日の中の時間帯

  時間に基づいてローテーションすると、各ログファイルが同じ期間をカバーするようになるため、ログの分析や傾向判断などの処理が容易になります。

ログファイルのローテーションを、条件の組み合わせに基づいて行うこともできます。たとえば、ファイルサイズが 10M バイトより大きい場合に「のみ」、23 時 30 分にログをローテーションするように指定できます。

ログファイル作成ポリシーを設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server のログの設定」を参照してください。

ログファイル削除ポリシーの定義

ログファイル削除ポリシーを使用すると、保存された古いログを自動的に削除できます。ログファイル削除ポリシーは、Directory Service Control Center からか、またはコマンド行ユーティリティーを使用して Directory Server と Directory Proxy Server に対して定義できます。ログファイル削除ポリシーは、ログファイル作成ポリシーが定義されていないかぎり適用されません。ログファイルが 1 つしかない場合、ログファイル削除は機能しません。サーバーは、ログのローテーションの時点でログファイル削除ポリシーを評価および適用します。

ログファイル削除ポリシーを定義する場合は、次の点を考慮してください。

• 保存される合計のログの最大サイズ

  この最大サイズに達すると、保存されているもっとも古いログが自動的に削除されます。

• 使用可能にする最小のディスク空き容量

  ディスク空き容量がこの最小値に達すると、保存されているもっとも古いログが自動的に削除されます。

• ログファイルの最長有効期間

  ログファイルがこの最長有効期間に達すると、そのログファイルは自動的に削除されます。

ログファイル削除ポリシーを設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server のログの設定」を参照してください。

ログファイルの手動での作成と削除

手動のファイルローテーションや強制されたログローテーションは、Directory Proxy Server には適用されません。

Directory Server に対して自動的な作成および削除のポリシーを定義したくない場合は、ログファイルを手動で作成および削除することができます。さらに、Directory Server には、定義されている作成ポリシーには関係なく、任意のログをただちにローテーションできるタスクが用意されています。この機能は、たとえば、さらに詳細に検証する必要があるイベントが発生した場合に有効なことがあります。この即座のローテーション機能では、サーバーに新しいログファイルが作成されます。これにより、元のログファイルには、今後サーバーからログが追加されない状態となり、そのファイルを検証することができます。

ログを手動でローテーションする方法、およびログのローテーションを強制する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server ログの手動でのローテーション」を参照してください。

ログファイルのアクセス権の定義

5.x バージョンの Directory Server では、ログファイルを読み取れるのは ディレクトリマネージャーだけでした。Directory Server Enterprise Edition では、ログファイルの作成時にアクセス権をサーバー管理者が定義できます。ログファイルのアクセス権を定義する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server のログの設定」を参照してください。

監視戦略の設計

配備を成功させるには、効果的な監視とイベント管理の戦略が必要です。この戦略は、監視対象となるイベント、使用するツール、そのイベントが発生した場合に実行するアクションを定義します。発生しがちなイベントに対する計画を立てておけば、サービスの停止やレベル低下の可能性を防止できます。この戦略によって、ディレクトリのサービスの可用性と品質が向上します。

監視戦略を設計するには、次のことを実行します。

• 適切な監視ツールを選択します。「Directory Server Enterprise Edition で提供される監視ツール」を参照してください。

• ディレクトリアーキテクチャー内の、監視対象となる主要な領域を識別します。

  これらの領域は一般に、サイジングやチューニングの属性と同じです。「監視領域の特定」を参照してください。

• パフォーマンス指標を監視する場合に、イベントまたはアラーム状態を始動する条件を定義します。

  この戦略では、パフォーマンスの受容可能レベル、または各パフォーマンス指標に対する処理を定義します。

• アラーム状態が発生したときに実行するアクションを決定します。

Directory Server Enterprise Edition で提供される監視ツール

ここでは、Directory Server Enterprise Edition で使用できる監視ツールや、サーバーアクティビティーの監視に使用できるその他のツールの概要について説明します。

「監視領域の特定」で説明されている監視領域は、これらの 1 つ以上のツールを使用して監視できます。

• コマンド行ツール: ディスク使用量などのパフォーマンスを監視するオペレーティングシステムに固有のツール、ディレクトリに格納されているサーバー統計を収集する ldapsearch などの LDAP ツール、サードパーティー製ツール、カスタムシェル、Perl スクリプトが含まれます。

• Directory Server および Directory Proxy Server ログ: アクセス、監査、およびエラーログが含まれます。これらのログを手動で監視したり、カスタムスクリプトを使用して解析することで、配備に関連する監視情報を抽出できます。Directory Server Resource Kit には、アクセスログを解析できるログ分析ツール、logconv が用意されています。このログ分析ツールは、利用率統計を抽出し、重要なイベントの発生をカウントします。このツールの詳細については、logconv(1) を参照してください。ログファイルの表示と設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 15 章「Directory Server のログ」を参照してください。

• Directory Service Control Center (DSCC): ディレクトリ操作をリアルタイムに監視できるグラフィカルユーザーインタフェースです。DSCC は、リソースの概要、現在のリソース使用状況、接続状態、グローバルデータベースキャッシュ情報など、一般的なサーバー情報を提供します。また、データベースのタイプや状態、エントリキャッシュ統計などの、一般的なデータベース情報も提供します。キャッシュ情報や、データベース内の各インデックスファイルに関連する情報も提供されます。さらに、DSCC には接続と各連鎖サフィックスで実行される操作に関する情報も表示されます。

• レプリケーション監視ツール: コマンド行ツール、repldisc、insync、および entrycmp が含まれます。

  これらのツールを使用すると、次の操作を実行できます。

  • マスターレプリカと 1 つまたは複数のコンシューマレプリカとの間の同期状態を監視する

  • 複数の異なるレプリカの間で同じエントリを比較することで、レプリケーションの状態を確認する

  • 完全なレプリケーショントポロジを描写する (これは複雑なディレクトリ配備で特に有用となる)

  詳細については、repldisc(1)、insync(1)、および entrycmp(1) を参照してください。

  DCC を使用してレプリケーションの状態を監視することもできます。レプリケーションの監視の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「レプリケーションの状態の取得」を参照してください。

• SNMP (Simple Network Management Protocol): グローバルネットワーク制御と監視のための標準メカニズムであり、ネットワーク管理者はネットワーク管理作業を一元的に行えます。

  SNMP エージェントを使用した監視については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 16 章「Directory Server の監視」を参照してください。

• Java ES Monitoring Framework: JMX を介した、パフォーマンスやその他の統計の監視を可能にします。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Server and CMM/JMX」を参照してください。

監視領域の特定

監視する対象や、その対象をどの程度監視するかは、具体的な配備によって異なります。ただし、一般に、監視戦略には次の要素が含まれます。

• リソース使用状況、サーバーの状態、接続情報などの、サーバーアクティビティー

• キャッシュ、トランザクション、ロック、ログなどの情報を含む、データベースアクティビティー

• 使用可能なディスク容量やしきい値情報を含む、ディスクの状態

• レプリケーションが実行されているかどうかの状態や、同期の状態を含む、レプリケーションアクティビティー

• インデックスを使用しない検索、検索フィルタ、よく使用されるインデックスなど、インデックスの効率性に関する情報

• 失敗したバインド試行、開いている接続、実行権限を含む、セキュリティーの状態

Directory Editor を使用したデータ管理

Directory Server Enterprise Edition の Directory Editor コンポーネントは、Web ブラウザを使用してディレクトリデータを管理できる Java Web アプリケーションです。Directory Editor を使用すると、すべてのユーザーが、クライアントソフトウェアをインストールしなくてもディレクトリデータにリモートアクセスできます。

Directory Editor は、次の機能を提供します。

• 管理者やエンドユーザーがディレクトリユーザー、グループ、およびコンテナを作成したり編集したりできるようにする。

• アプリケーションサーバーや配備されているハードウェアに応じて、複数の並行ユーザーをサポートする。

• 大規模な企業ディレクトリのインストールをサポートする。

• インタフェースのカスタマイズ、ブランド化、および埋め込みを可能にする。

  カスタマイズは、Directory Server スキーマに動的に適応します。

• 直接のプログラミングによるのではなく、フォームの設定によるカスタマイズを可能にする。

• クライアントブラウザと Directory Server の間の SSL で暗号化された転送をサポートする。

• ロールに基づいて、メニューや機能へのアクセスを制限する。

  ロールはスキャンされ、グループ名とマッチングされます。ロールには特定の機能へのアクセス権が与えられます。機能とは、参照、設定、デバッグ、編集、作成、検索などの高レベルのアクションです。

• Directory Server 内の既存の ACI に基づいて、データへのアクセスを制限する。Directory Editor に固有の ACI を定義する必要はありません。

• 仮想リスト表示 (VLV) インデックスに基づいて、大量データをページ化して表示する。

Directory Editor のインストール、設定、および使用の詳細については、Directory Editor マニュアル コレクションを参照してください。