もっとも単純な Directory Server Enterprise Edition 配備では、1 つのデータセンター内にある、1 台のマシンにインストールされた単一の Directory Server でディレクトリサービスの要件を満たすことができます。組織が小規模な場合や、Directory Server をデモや評価のために実行している場合には、このシナリオが成り立つ可能性があります。前の章で説明されている技術的な要件は、すべての配備に等しく適用されることに注意してください。
この章では、1 台の Directory Server で構成される基本的な配備について説明します。この章で説明する内容は次のとおりです。
基本的な Directory Server Enterprise Edition 配備には、次の要素が含まれます。
Directory Server インスタンスファイル
Directory Server デーモン
dsadm および dsconf コマンド行ユーティリティー
Directory Service Control Center (DSCC) (GUI アクセスが必要な場合)
コンソールエージェント (DSCC が使用されている場合)
これらの要素をすべて、1 台のマシンにインストールできます。次の図は、基本的な Directory Server Enterprise Edition 配備の高レベルのアーキテクチャーを示しています。
このシナリオでは、内部の LDAP および DSML クライアントを、Directory Server に直接アクセスするように設定できます。外部の HTML クライアントは、ファイアウォールを介して DSCC にアクセスするように設定できます。
先に説明したコンポーネントをすべて 1 台のマシンにインストールすることは可能ですが、それは実際の配備では現実的でありません。より標準的なシナリオでは、DSCC と dsconf コマンド行ユーティリティーを別のリモートマシンにインストールします。それによって、すべての Directory Server ホストを、これらのマシンからリモートに設定することも可能になります。次の図は、この、より標準的なシナリオを示しています。
Directory Server インスタンスには、サーバーとアプリケーションの設定や、ユーザー情報が格納されます。一般に、サーバーとアプリケーションの設定情報は Directory Server の 1 つのサフィックスに格納され、ユーザーとグループのエントリは別のサフィックスに格納されます。サフィックスはディレクトリツリー内のエントリの名前で、データはその下に格納されます。
Directory Service Control Center (DSCC) は、すべてのサーバーを集中管理する Web ベースのユーザーインタフェースであり、また Java Web コンソールのディレクトリコンポーネントです。DSCC に登録されているすべてのサーバーとアプリケーションは、グラフィカルユーザーインタフェース上で表示され、そこでサーバーを管理したり設定したりできます。コマンド行インタフェースを通してすべての機能が提供されるため、小規模な配備では Directory Service Control Center が必要ない場合もあります。
以降の章では、Directory Service Control Center が別のマシンにインストールされていることを前提としています。この前提については、各章であらためて言及しません。
完全なインストール情報は、『Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide 』で提供されています。この節の目的は、基本的な配備を構成する各要素を明確に示し、これらの要素が連携して動作するようすを説明することにあります。
この節では、前の節で説明した基本的な配備を設定するためのメインタスクを示します。
必要な共有コンポーネント (セキュリティーパッケージを含む) をインストールします。
Directory Server、コンソールエージェント、およびコマンド行インタフェースをインストールします。
コマンド行ユーティリティーを使用してサーバーを管理する場合は、次の手順を実行します
dsadm コマンドを使用して、スタンドアロンの Directory Server インスタンスを作成して起動します。
dsconf コマンドを使用して、新しいインスタンス内にサフィックスを作成して設定します。
グラフィカルユーザーインタフェースを通してサーバーを管理する場合は、次の手順を実行します
Directory Service Control Center を初期化します。
Directory Service Control Center を使用して、Directory Server インスタンスを作成します。
Directory Service Control Center を使用して、新しいインスタンス内にサフィックスを作成して設定します。
もっとも基本的な配備でも、特定の領域のパフォーマンスを向上させるために Directory Server の調整が必要になる場合があります。以降の節では、単純な単一サーバー配備に適用できる、基本的なチューニング戦略について説明します。これらの戦略は、トポロジ全体のパフォーマンスを向上させるために、より大規模で、より複雑な配備内の各サーバーにも適用できます。
インデックスを使用すると、検索で一致するものを見つけるためにチェックする必要のあるエントリの数が実質的に削減されるため、検索が高速化されます。インデックスには、値のリストが含まれています。各値は、エントリ識別子のリストに関連付けられています。Directory Server は、インデックス内のエントリ識別子のリストを使用して、各エントリをすばやく検索できます。Directory Server が、インデックスのない状態でエントリのリストを管理するには、検索で一致するものを見つけるためにサフィックス内のすべてのエントリをチェックする必要があります。
Directory Server は、各検索要求を次のように処理します。
Directory Server がクライアントから検索要求を受信します。
Directory Server は要求を検査して、その検索を処理できることを確認します。
Directory Server が検索を実行できない場合は、クライアントにエラーを返します。また、その検索を Directory Server の別のインスタンスに任せる場合もあります。
Directory Server は、その検索に対応する 1 つ以上のインデックスを管理しているかどうかを判定します。
Directory Server がその検索に対応するインデックスを管理している場合、サーバーは、対応するすべてのインデックスを検索して候補エントリを見つけます。候補エントリとは、検索要求に一致する可能性のあるエントリです。
Directory Server がその検索に対応するインデックスを管理していない場合、サーバーは、データベース内のすべてのエントリをチェックすることによって候補エントリのセットを生成します。
Directory Server がインデックスを使用できない場合は、この処理で消費される時間とシステムリソースが増えます。
Directory Server は各候補エントリを検査して、そのエントリが検索条件に一致するかどうかを判定します。
Directory Server は、一致するエントリを見つけると、そのエントリをクライアントアプリケーションに返します。
次のことを行うことによって、検索のパフォーマンスを最適化できます。
インデックスが生成されていないエントリに対して Directory Server が検索を実行しないようにします。
キャッシュサイズが適切に調整されていることを確認します。
インデックスの長さを制限します。
インデックスの動作の包括的な概要については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 6 章「Directory Server Indexing」を参照してください。インデックスの定義については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の第 12 章「Directory Server のインデックス」を参照してください。
検索のパフォーマンスを向上させるには、メモリー内にできるだけ多くのディレクトリデータをキャッシュします。ディレクトリサーバーがディスクから情報を読み取る回数を減らすことで、ディスクの I/O ボトルネックが軽減されます。これを実行するための方法は、ディレクトリツリーのサイズ、使用可能なメモリーの量、および使用されているハードウェアによって異なります。配備によっては、検索のパフォーマンスを最適化するために、エントリキャッシュやデータベースキャッシュに割り当てるメモリーを増やしたり減らしたりすることを選択する場合があります。あるいは、異なるサーバー上の Directory Server コンシューマに検索を分散させることを選択する場合もあります。
次のシナリオを検討してみます。
最適な場合は、データベースキャッシュとエントリキャッシュが使用可能な物理メモリーに収まります。エントリキャッシュは、ディレクトリ内のすべてのエントリを保持するための十分な大きさがあります。データベースキャッシュは、すべてのインデックスとエントリを保持するための十分な大きさがあります。この場合、検索対象はすべてキャッシュ内で見つかります。Directory Server は、エントリを取得するために、ファイルシステムキャッシュまたはディスクにアクセスする必要がまったくありません。
更新や拡張のあとも、データベースキャッシュにすべてのデータベースインデックスが含まれている必要があります。データベースキャッシュ内のインデックスの領域が不足すると、検索を行うたびに、Directory Server がディスクからインデックスを読み取らなければならなくなり、スループットが大幅に低下します。ページングやキャッシュのアクティビティーは、DSCC またはコマンド行を使用して監視できます。
適切なキャッシュサイズは、代表的なデータでの実験的なテストを通して決定してください。一般に、データベースキャッシュサイズは、(データベースファイルの合計サイズ) x 1.2 として計算できます。最初は、キャッシュに大量のメモリーを割り当ててください。次に、Directory Server を実行して監視し、その結果を観察します。この処理を、必要に応じて繰り返します。エントリキャッシュは特に、これらのキャッシュに割り当てた分よりはるかに多くのメモリーを使用する可能性があります。
エントリキャッシュとデータベースキャッシュ内のすべてのデータを保持するための十分なメモリーを備えているが、64 ビット Directory Server プロセスをサポートしていないシステムを考えてみます。ハードウェアの制約によって、64 ビットをサポートする Solaris システム上に Directory Server を配備できない場合は、32 ビットプロセスのメモリー制限を考慮してキャッシュサイズを適切に決定してください。次に、残りのメモリーをファイルシステムキャッシュに割り当てます。
パフォーマンスベンチマークの出発点として、エントリキャッシュのサイズを、できるだけ多数のエントリを保持するように決定します。データベースキャッシュのサイズは、完全に最小化せずに 100M バイト程度に比較的小さくしますが、ファイルシステムキャッシュにはデータベースページが保持されるようにします。
ファイルシステムキャッシュは、システム上のほかのプロセス、特にファイルベースの操作と共有されます。そのため、特に Directory Server 専用のシステムでない場合、ファイルシステムキャッシュの制御はほかのキャッシュの制御より困難です。
システムがファイルシステムキャッシュをほかのプロセスに再割り当てする可能性があります。
インポートキャッシュは Directory Server プロセスに関連付けられているため、この状況でのオンラインインポートは避けてください。
エントリキャッシュとデータベースキャッシュ内のすべてのデータを保持するにはメモリーが不足しているシステムを考えてみます。この場合は、エントリキャッシュとデータベースキャッシュの合計サイズが使用可能な物理メモリーを超えることのないようにしてください。もし超えてしまうと、仮想記憶のページングが大量に発生し、システムが事実上停止してしまう可能性があります。
小規模なシステムのベンチマークでは、最初、使用可能なメモリーをすべてエントリキャッシュとデータベースキャッシュに割り当てください (サイズはそれぞれ 100M バイト以上)。mount_ufs コマンドの -o forcedirectio オプションを使用して Solaris UFS ファイルシステムをマウントすることによって、ファイルシステムキャッシュの無効化を試みてください。詳細については、mount_ufs(1M) のマニュアルページを参照してください。ファイルシステムキャッシュを無効にすると、Directory Server に必要なメモリーがファイルシステムキャッシュでは使用されないようにすることができます。
大規模なマシン上で実行されている大規模な Directory Server では、ファイルシステムキャッシュを最大化し、データベースキャッシュを減らします。実験的なテストを通してこの前提を確認し、修正してください。
配備に書き込みのスケーラビリティーを持たせるように最初から計画することに加えて、データベースキャッシュがメモリー内の更新を処理できるだけの十分なメモリーを用意してください。また、ディスクアクティビティーも最小限に抑えてください。データベースキャッシュの有効性は、Directory Service Control Center でヒット率を読み取ることによって監視できます。
Directory Server がしばらく実行されたあとは、キャッシュ内に、それ以上ディスク読み取りが必要ないほど十分なエントリとインデックスが含まれているようにしてください。更新の結果は、メモリー内の大規模なデータベースキャッシュにあるデータに反映され、データベースキャッシュはたまにしかフラッシュされないはずです。
チェックポイント中のディスクへのデータのフラッシュは、ボトルネックになる場合があります。データベースキャッシュサイズが大きければ大きいほど、このボトルネックは大きくなります。Sun StorEdgeTM ディスクアレイなどの別の RAID システムにデータベースを格納すると、更新のパフォーマンス向上に役立つ場合があります。潜在的な I/O ボトルネックを分離するには、Solaris システムにおける iostat などのユーティリティーを使用できます。詳細については、iostat(1M) のマニュアルページを参照してください。
次の表は、2、3、および 4 つのディスクを備えたシステムでのデータベースとログの配置方法に関する推奨事項を示しています。
表 9–1 別のディスクへのデータベースとログの分離