9 基本的なデプロイメントの設計

最も単純なDirectory Server Enterprise Editionデプロイメントでは、単一のデータ・センター内の1台のマシンに単一のDirectory Serverをインストールすることによって、ディレクトリ・サービス要件を満たすことができます。このようなシナリオは、小規模組織、またはデモや評価の目的でDirectory Serverを実行する場合に発生することがあります。前の章で説明した技術要件は、すべてのデプロイメントに同等に適用されます。

この章では、単一のDirectory Serverが含まれた、基本的なデプロイメントについて説明します。この章の内容は次のとおりです。

• 基本的なデプロイメントのアーキテクチャ

• 基本的なデプロイメントの設定

• 基本的なデプロイメントのパフォーマンスの改善

9.1 基本的なデプロイメントのアーキテクチャ

基本的なDirectory Server Enterprise Editionデプロイメントには、次の要素が含まれます。

• Directory Serverインスタンス・ファイル

• Directory Serverデーモン

• dsadmおよびdsconfコマンドライン・ユーティリティ

• Directory Service Control Center (DSCC) (GUIアクセスが必要な場合)

• DSCCエージェント(DSCCを使用する場合)

これらの要素は、単一のマシンにすべてインストールできます。次の図は、基本的なDirectory Server Enterprise Editionデプロイメントの概略レベルのアーキテクチャを示しています。

図9-1 単一のマシン上の基本的なDirectory Server Enterprise Editionのアーキテクチャ

「図9-1 単一のマシン上の基本的なDirectory Server Enterprise Editionのアーキテクチャ」の説明

このシナリオでは、内部のLDAPおよびDSMLクライアントをDirectory Serverに直接アクセスするように構成できます。外部のHTMLクライアントは、ファイアウォールを介してDSCCにアクセスするように構成できます。

前に説明したコンポーネントは単一のマシンにすべてインストールできますが、実際のデプロイメントでは、通常、このようにはしません。一般的なシナリオでは、DSCCおよびdsconfコマンドライン・ユーティリティは別々のリモート・マシンにインストールされます。これらのマシンからリモートですべてのDirectory Serverホストを構成できます。次の図は、この一般的なシナリオを示しています。

図9-2 リモートのDirectory Service Control Centerを使用した基本的なDirectory Server Enterprise Editionのアーキテクチャ

「図9-2 リモートのDirectory Service Control Centerを使用した基本的なDirectory Server Enterprise Editionのアーキテクチャ」の説明

Directory Serverインスタンスには、サーバーとアプリケーションの構成設定およびユーザー情報が格納されます。通常、サーバーおよびアプリケーションの構成情報はDirectory Serverの1つの接尾辞に格納され、ユーザーおよびグループ・エントリは別の接尾辞に格納されます。接尾辞は、ディレクトリ・ツリー内のエントリの名前を指し、その下にデータが格納されます。

Directory Service Control Center (DSCC)は、すべてのサーバーのための集中管理されたWebベースのユーザー・インタフェースです。DSCCによって、登録されているすべてのサーバーおよびアプリケーションが特定されます。DSCCには、サーバーがグラフィカル・ユーザー・インタフェースに表示され、そこでサーバーを管理および構成できます。小規模のデプロイメントでは、すべての機能がコマンドライン・インタフェースでも提供されるため、Directory Service Control Centerが必要ない場合もあります。

以降の章では、Directory Service Control Centerが別のマシンにインストールされていることを想定しています。トポロジのこの側面については、残りの章で再び記述されることはありません。

9.2 基本的なデプロイメントの設定

インストールの詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』を参照してください。この項の目的は、基本的なデプロイメントを構成する要素を明確にし、これらの要素の連携について説明することです。

この項では、前の項で説明した基本的なデプロイメントを設定するための主なタスクを示します。

• Directory Server、DSCCエージェントおよびコマンドライン・インタフェースをインストールします。

• コマンドライン・ユーティリティを使用してサーバーを管理する場合は、次のことを実行します。

  • dsadmコマンドを使用して、スタンドアロンDirectory Serverインスタンスを作成し、起動します。

  • dsconfコマンドを使用して、新しいインスタンスの接尾辞を作成し、構成します。

• グラフィカル・ユーザー・インタフェースを使用してサーバーを管理する場合は、次のことを実行します。

  • Directory Service Control Centerを初期化します。

  • Directory Service Control Centerを使用して、Directory Serverインスタンスを作成します。

  • Directory Service Control Centerを使用して、新しいインスタンスの接尾辞を作成し、構成します。

9.3 基本的なデプロイメントのパフォーマンスの改善

最も基本的なデプロイメントでも、特定の領域のパフォーマンスを改善するためにDirectory Serverをチューニングすることが必要となる場合があります。次の各項では、単純な単一サーバー・デプロイメントに適用できる基本的なチューニング方針について説明します。より大規模で複雑なデプロイメントの各サーバーにこれらの方針を適用すると、トポロジ全体のパフォーマンスを改善できます。

9.3.1 索引作成による検索の高速化

索引を使用すると、検索で一致を見つけるために確認する必要があるエントリの数が効果的に削減されるため、検索が高速化されます。索引には、値のリストが含まれます。各値は、エントリ識別子のリストに関連付けられます。Directory Serverでは、索引のエントリ識別子のリストを使用して、迅速にエントリを検索できます。エントリのリストを管理するための索引がない場合、Directory Serverでは、接尾辞のすべてのエントリを確認して検索の一致を見つける必要があります。

Directory Serverは、各検索リクエストを次のように処理します。

1. Directory Serverは、クライアントから検索リクエストを受信します。

2. Directory Serverはリクエストを調べ、検索を処理できることを確認します。

   検索を実行できない場合は、クライアントにエラーを返し、Directory Serverの別のインスタンスに検索を委ねることがあります。

3. Directory Serverは、検索に適した1つ以上の索引を管理するかどうかを決定します。

   • Directory Serverで検索に適した索引を管理する場合、サーバーは適切なすべての索引を調べて候補エントリを検索します。候補エントリは、検索リクエストに一致する可能性があるエントリです。

   • Directory Serverで検索に適した索引を管理しない場合、サーバーはデータベース内のエントリをすべて確認して一連の候補エントリを生成します。

     Directory Serverで索引を使用できない場合は、このプロセスで消費される時間およびシステム・リソースが増大します。

4. Directory Serverでは、エントリが検索基準に一致するかどうかを判断するために、それぞれの候補エントリを調べます。

5. 一致するエントリが見つかると、Directory Serverによってクライアント・アプリケーションに返されます。

検索パフォーマンスは、次の方法で最適化できます。

• Directory Serverで索引付けされていないエントリに対して検索を実行しないようにします。

• キャッシュ・サイズが適切にチューニングされていることを確認します。

• 索引の長さを制限します。

索引の動作の包括的な概要は、Oracle Directory Server Enterprise Editionリファレンスの第9章「Directory Serverの索引作成」を参照してください。索引の定義の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第12章「Directory Serverの索引作成」を参照してください。

9.3.2 検索パフォーマンスのためのキャッシュの最適化

検索パフォーマンスを改善するには、できるだけ多くのディレクトリ・データをメモリーにキャッシュします。ディレクトリによってディスクから情報が読み取られないようにすることによって、ディスクI/Oのボトルネックを制限します。このことを行う場合、ディレクトリ・ツリーのサイズ、使用可能なメモリーの量および使用されるハードウェアによって、様々な方法があります。デプロイメントに応じて、検索パフォーマンスを最適化するために、エントリおよびデータベース・キャッシュに割り当てるメモリーを増減することを選択できます。または、異なるサーバー上の複数のDirectory Serverコンシューマに検索を分散することもできます。

詳細は、「キャッシュ設定のチューニング」を参照してください。

次のシナリオを検討してください。

• すべてのエントリと索引がメモリーに収まる場合

• 32ビットDirectory Serverのため十分なメモリーがある場合

• メモリー不足

9.3.2.1 すべてのエントリと索引がメモリーに収まる場合

最適なケースでは、データベース・キャッシュおよびエントリ・キャッシュは使用可能な物理メモリーに収まります。エントリ・キャッシュは、ディレクトリ内のすべてのエントリを格納できる大きさです。データベース・キャッシュは、すべての索引およびエントリを格納できる大きさです。このケースでは、すべての検索対象がキャッシュにあります。Directory Serverがファイル・システム・キャッシュまたはディスクにアクセスしてエントリを取得する必要はありません。

更新および拡張の後も、データベース・キャッシュにすべてのデータベース索引を格納できることを確認してください。データベース・キャッシュに索引のための領域がなくなると、Directory Serverは検索リクエストのたびにディスクから索引を読み取る必要があり、スループットに大きな影響を及ぼします。DSCCまたはコマンドラインを使用して、ページングおよびキャッシュ・アクティビティを監視できます。

適切なキャッシュ・サイズは、代表的なデータを使用して実験的にテストして決定する必要があります。通常、データベース・キャッシュのサイズは、(total size of database files) x 1.2で計算できます。まず、キャッシュに大量のメモリーを割り当てます。次に、Directory Serverを実行および監視して結果を確認し、必要に応じて処理を繰り返します。特に、エントリ・キャッシュでは、これらのキャッシュに割り当てた量よりはるかに多いメモリーが使用されることがあります。

エントリ・キャッシュは、サーバーの負荷によって1分間にアクセスされたエントリの数がすぐにわかるような方法で、測定する必要があります。エントリ・キャッシュの内容が1秒間に何度も置き換えられる状況は回避するようにしてください。

9.3.2.2 32ビットDirectory Serverのため十分なメモリーがある場合

エントリ・キャッシュおよびデータベース・キャッシュ内のすべてのデータを格納するための十分なメモリーが搭載され、64ビットDirectory Serverプロセスがサポートされていないシステムの場合を考えます。ハードウェアの制約により、64ビットをサポートするSolarisシステムにDirectory Serverをデプロイできない場合は、32ビット・プロセスのメモリー制限に合わせてキャッシュのサイズを適切に調整します。次に、残りのメモリーをファイル・システム・キャッシュに残します。

パフォーマンスのベンチマークを実行する場合は、最初に、できるだけ多くのエントリが格納されるようにエントリ・キャッシュのサイズを調整します。データベース・キャッシュのサイズは、完全に最小にするのではなく、ファイル・システムがデータベース・ページを格納できるように、100MBなどの比較的小さいサイズにします。

注意: ファイル・システム・キャッシュは、システム上の他のプロセス(特にファイルベースの操作)で共有されます。このため、特に、Directory Server専用でないシステムでは、ファイル・システム・キャッシュの制御は、他のキャッシュの制御よりも困難になります。 ファイル・システム・キャッシュは、システムによって他のプロセスに再割当てされることがあります。

Directory Serverプロセスにはインポート・キャッシュが関連付けられているため、この状況ではオンライン・インポートを実行しないでください。

9.3.2.3 メモリー不足

エントリ・キャッシュおよびデータベース・キャッシュ内のすべてのデータを格納するためのメモリーが不足しているシステムを考えます。この場合は、エントリ・キャッシュ・サイズとデータベース・キャッシュ・サイズの合計が使用可能な物理メモリーのサイズを超えることがないようにしてください。これにより、仮想メモリーのページングが大量に発生し、システムが仮想停止する可能性があります。

小規模システムの場合は、使用可能なメモリーをエントリ・キャッシュおよびデータベース・キャッシュ(それぞれ100MB未満のサイズ)に使用してベンチマークを開始します。mount_ufsコマンドの-o forcedirectioオプションを使用してSolaris UFSファイル・システムをマウントすることで、ファイル・システム・キャッシュを無効にします。詳細は、mount_ufs(1M)のマニュアル・ページを参照してください。ファイル・システム・キャッシュを無効にすると、Directory Serverで必要になるメモリーがファイル・システム・キャッシュによって使用されることを防止できます。

大規模なマシンでDirectory Serverが実行されている場合は、ファイル・システム・キャッシュを最小にし、データベース・キャッシュを減らします。実験的にテストして想定を検証し、修正します。

9.3.3 書込みパフォーマンスのためのキャッシュの最適化

デプロイメントを計画するとき、最初から書込みスケーラビリティが確保されるようにする以外に、データベース・キャッシュにメモリー内の更新を処理するための十分なメモリーを割り当てます。また、ディスク・アクティビティを最小化します。データベース・キャッシュの効果は、Directory Service Control Centerでヒット率を読むことによって監視できます。

Directory Serverをしばらくの間実行すると、キャッシュに十分なエントリと索引が格納されて、ディスク読取りが必要なくなります。更新はメモリー内のデータベース・キャッシュに影響を及ぼし、メモリー内の大規模なデータベース・キャッシュのデータはまれにしかフラッシュされません。

チェックポイント中のディスクへのデータ・フラッシュは、ボトルネックになることがあります。データベース・キャッシュ・サイズが大きくなるほど、ボトルネックは大きくなります。データベースをSun StorEdgeディスク・アレイなどの別のRAIDシステムに格納すると、更新パフォーマンスの改善に役立つ場合があります。Solarisシステムでiostatなどのユーティリティを使用して、可能性のあるI/Oボトルネックを特定できます。詳細は、iostat(1M)のマニュアル・ページを参照してください。

次の表に、2、3および4つのディスクのあるシステムにおけるデータベースおよびログの配置の推奨事項を示します。

表9-1 様々なディスクにおけるデータベースとログの分離

使用可能なディスク	推奨事項
2	Directory Serverデータベースを一方のディスクに配置します。 トランザクション・ログ、アクセス・ログ、監査ログ、エラー・ログおよびレトロ変更ログをもう一方のディスクに配置します。
3	Directory Serverデータベースを一方のディスクに配置します。 トランザクション・ログを2つ目のディスクに配置します。 アクセス・ログ、監査ログ、エラー・ログおよびレトロ変更ログを3つ目のディスクに配置します。
4	Directory Serverデータベースを一方のディスクに配置します。 トランザクション・ログを2つ目のディスクに配置します。 アクセス・ログ、監査ログおよびエラー・ログを3つ目のディスクに配置します。 レトロ変更ログを4つ目のディスクに配置します。