test

Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド

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

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

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

ホストシステムの特性

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

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

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

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

ポート番号

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

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

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 の設定方法については、『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 はそのエージェントとこれらのネットワークポート経由で通信します。

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 専用として使用するプロセッサの個数、メモリーの容量、ディスクの容量、およびネットワーク接続の種類を決定する際の考慮点を示します。

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

注 –

特に明記されていないかぎり、次の各節で説明されている「サーバープロパティー」は 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 の実行に必要なメモリーのサイズを見積もるには、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 経由で使用することをサポートしません。設定、データベース、およびインデックスファイルはすべて、インストールを終えてからも、常にローカルストレージ上に配置する必要があります。ログファイルはネットワークディスク上に格納できます。

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

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

ディレクトリデータに必要なディスクの見積もりは、推定によって行える場合があります。本番時に予期されるのと同量のデータを使って 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 StorEdgeTM 製品で提供されているような大容量で不揮発性 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 ユーザーとして接続することのないようにしてください。

表 6–1 クライアントアプリケーション専用リソースに対する推奨のチューニング方法

チューニングパラメータ 

説明 

サーバープロパティー 

idle-timeout

Directory Server がアイドル状態のクライアント接続を閉じるまでの時間を、秒単位で設定します。ここで、「アイドル状態」とは、接続が開いたままであるにもかかわらず、何の処理も要求されていない状態を意味します。デフォルトでは、何の時間制限も設定されていません。

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

メッセージングサーバーなどの一部のアプリケーションは、トラフィックが少ないときにはアイドル状態のままであるが閉じるべきではないような一連の接続を開く可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインド DN ベースの個別制限を検討してください。 

いずれにしても、この値を十分大きな値に設定して、ほかのアプリケーションが開いていることを期待するような接続を閉じないようにするとともに、この値を十分小さな値に設定して、接続を不必要にアイドル状態のままにできないようにしてください。たとえば、これを 7200 秒つまり 2 時間に設定することを検討してください。 

属性 

dn: cn=config の属性 nsslapd-ioblocktimeout

Directory Server が停止されたクライアント接続を閉じるまでの時間を、ミリ秒単位で設定します。ここで、「停止された」とは、クライアントへの出力送信時、クライアントからの入力読み取り時のいずれかにサーバーがブロックされることを意味します。

この属性を設定するには、ldapmodify コマンドを使用します。

特にサービス拒否攻撃の標的になっているような Directory Server インスタンスの場合、この値をデフォルトの 1,800,000 ミリ秒つまり 30 分より小さい値に設定することを検討してください。 

サーバープロパティー 

look-through-limit

検索時に一致するかどうかをチェックする候補エントリの最大数を設定します。 

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

メッセージングサーバーなどの一部のアプリケーションは、ディレクトリの全体を検索する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインド DN ベースの個別制限を検討してください。 

いずれにしても、この値をデフォルトの 5000 エントリより小さい値に設定することを検討してください。ただし、search-size-limit のしきい値を下回ってはいけません。

属性 

dn: cn=config の属性 nsslapd-maxbersize

BER (Basic Encoding Rules) に従ってエンコードされた ASN.1 受信メッセージの最大サイズを、バイト単位で設定します。Directory Server は、この制限よりもサイズの大きいエントリを追加する要求を拒否します。 

この属性を設定するには、ldapmodify コマンドを使用します。

ディレクトリデータの最大エントリサイズを正確に予測できる場合には、この値をデフォルトの 2097152 つまり 2M バイトから、予測したディレクトリエントリの最大値に変更することを検討してください。 

更新に対する 2 番目に大きなサイズ制限は、トランザクションログファイルのサイズ nsslapd-db-logfile-size です。このサイズはデフォルトで 10M バイトです。

サーバープロパティー 

max-threads-per-connection-count

1 クライアント接続あたりの最大スレッド数を設定します。 

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

メッセージングサーバーなどの一部のアプリケーションは、一連の接続を開き、それらの各接続上で多数の要求を発行する可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインド DN ベースの個別制限を検討してください。 

一部のアプリケーションが 1 つの接続で多数の要求を実行することが予期される場合には、この値をデフォルトの 5 から増やすことを検討してください。ただし、これを 10 を超える値にまで増やしてはいけません。通常は、1 スレッドあたり 10 個を超えるスレッドを指定しないでください。 

サーバープロパティー 

search-size-limit

検索要求への応答として Directory Server が返すエントリの最大数を設定します。 

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

メッセージングサーバーなどの一部のアプリケーションは、ディレクトリの全体を検索する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインド DN ベースの個別制限を検討してください。 

いずれにしても、この値をデフォルトの 2000 エントリから下げることを検討してください。 

サーバープロパティー 

search-time-limit

Directory Server が 1 つの検索要求を処理する時間の限度を秒単位で設定します。 

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

メッセージングサーバーなどの一部のアプリケーションは、非常に大規模な検索を実行する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインド DN ベースの個別制限を検討してください。 

いずれにしても、この値は、配備要件を満たす範囲内でできるだけ低く設定してください。デフォルト値の 3600 秒つまり 1 時間は、多くの配備では必要以上に大きな値です。600 秒つまり 10 分を最適化テストの出発点として使用することを検討してください。 

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

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

表 6–2 システムリソースに対する推奨のチューニング方法

チューニングパラメータ 

説明 

属性 

dn: cn=config の属性 nsslapd-listenhost

Directory Server が待機する IP インタフェースのホスト名を設定します。この属性は複数の値を持つことができます。 

この属性を設定するには、ldapmodify コマンドを使用します。

デフォルト動作は、すべてのインタフェース上で待機することです。このデフォルト動作は、冗長性のあるネットワークインタフェースを使って可用性やスループットを高めるような、高ボリュームの配備に適しています。 

マルチホームシステム上に配備する場合や、IPv4、IPv6 の各プロトコルをそれぞれ個別のインタフェースを使ってサポートするようなシステム上で IPv4 または IPv6 トラフィックのみを待機する場合に、この値の設定を検討してください。SSL 使用時には、nsslapd-securelistenhost の設定を検討してください。

サーバープロパティー 

file-descriptor-count

Directory Server が使用できるファイル記述子の最大数を設定します。 

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

デフォルト値は、Directory Server インスタンスが作られる時に、システム上の 1 つのプロセスに許可されるファイル記述子の最大数です。その最大値は、システム上の 1 つのプロセスに許可されるファイル記述子の最大数に対応します。詳細については、オペレーティングシステムのマニュアルを参照してください。 

Directory Server はファイル記述子を使用することで、クライアント接続を処理し、ファイルを内部的に維持します。利用可能なファイル記述子の数が十分でないために Directory Server が新しい接続の待機を停止する場合があることがエラーログから判明した場合、この属性の値を増やせば、Directory Server が同時に処理できるクライアント接続の数が増える可能性があります。 

システム上で利用可能なファイル記述子の数を増やした場合には、この属性の値もそれに応じて設定してください。このプロパティーの値は、システム上で利用可能なファイル記述子の最大数と等しいかそれより小さくなるようにしてください。 

属性 

dn: cn=config の属性 nsslapd-nagle

TCP パケットの送信をソケットレベルで遅延させるかどうかを設定します。 

この属性を設定するには、ldapmodify コマンドを使用します。

ネットワークのトラフィックを減らす必要がある場合には、これを on に設定することを検討してください。

属性 

dn: cn=config の属性 nsslapd-reservedescriptors

Directory Server がインデックス作成やレプリケーションなどの内部処理を管理するために維持するファイル記述子の数を設定します。そのようなファイル記述子は、「クライアント接続の処理用として使用することができなくなります」。

この属性を設定するには、ldapmodify コマンドを使用します。

次のすべてに該当する場合には、この属性の値をデフォルトの 64 から増やすことを検討してください。

  • Directory Server が 10 個を超えるコンシューマにレプリケートするか、Directory Server が 30 個を超えるインデックスファイルを維持する。

  • Directory Server が多数のクライアント接続を処理する。

  • Directory Server がクライアント接続に関係「しない」処理を行うためのファイル記述子が不足していることを、エラーログ内のメッセージが示唆している。

確保済みファイル記述子の数が増えると、クライアント接続の処理に利用可能なファイル記述子の数が減ることに注意してください。この属性の値を増やす場合には、システム上で利用可能なファイル記述子の数を増やし、file-descriptor-count の数を増やすことを検討してください。

確保すべきファイル記述子の数を初めて見積もる目的でこの属性を変更することにした場合、次の式に従って nsslapd-reservedescriptors の値を設定してみてください。

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

ここで、ReplDescriptors は、レプリケーションが使用される場合は、サプライヤレプリカの数に 8 を加えたものになります。PTADescriptors は、PTA (Pass Through Authentication) プラグインが有効になっている場合は 3、それ以外の場合は 0 になります。SSLDescriptors は、SSL が使用される場合は 5、それ以外の場合は 0 になります。
 

インスタンスがサフィックスごとに 2 つ以上のデータベースを使用するように設定されているのでないかぎり、データベースの数はインスタンスのサフィックスの数と同じになります。実験的なテストを通じて見積もり内容を確認してください。 

属性 

dn: cn=config の属性 nsslapd-securelistenhost

Directory Server が SSL 接続を待機する IP インタフェースのホスト名を設定します。この属性は複数の値を持つことができます。 

この属性を設定するには、ldapmodify コマンドを使用します。

デフォルト動作は、すべてのインタフェース上で待機することです。この属性は、nsslapd-listenhost と同様に考えてください。

サーバープロパティー 

max-thread-count

Directory Server が使用するスレッドの数を設定します。 

このサーバープロパティーを設定するには、dsconf set-server-prop コマンドを使用します。

次のいずれかに該当する場合には、このプロパティーの値を調整することを検討してください。

  • クライアントアプリケーションが、更新や複雑な検索などの時間のかかる処理を、同時に数多く実行する。

  • Directory Server が多数の同時クライアント接続をサポートする。

マルチプロセッサシステムは、シングルプロセッサシステムよりも大きなスレッドプールを維持できます。この属性の値を最適化する際の最初の見積もりとしては、プロセッサ数の 2 倍、20 + 同時更新数のいずれかを使用してください。 

また、1 クライアント接続あたりの最大スレッド数 max-threads-per-connection-count を調整することも検討してください。クライアント接続を処理するこれらのスレッドの最大数が、システム上で利用可能なファイル記述子の最大数を超えることはできません。場合によっては、この属性の値を増やすよりも「減らす」ほうが有効である可能性もあります。

実験的なテストを通じて見積もり内容を確認してください。その結果は、特定の配備状況だけでなく、サーバーが稼働しているシステムの状況にも依存します。 

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

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

システムの特性

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

この例では、システムは 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 は、この例での測定内容を記録したものです。ここには、サーバープロセスサイズ、デフォルトデータベースキャッシュファイルサイズのいずれも含まれていません。

注 –

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

表 6–3 サイジングの測定結果

エントリ数 

LDIF ファイルのサイズ 

デフォルトのインデックスを含むディスク 

5 つのインデックスが追加されたディスク 

データベースキャッシュ 

エントリキャッシュ 

0 [サフィックスは作成済みですが空の状態です。]

測定値なし 

測定値なし 

測定値なし 

測定値なし 

測定値なし 

10,000 

5.7M バイト 

19M バイト 

26M バイト 

32M バイト 

55M バイト 

100,000 

57M バイト 

142M バイト 

163M バイト 

200M バイト 

550M バイト 

1,000,000 

573M バイト 

1300M バイト 

1500M バイト 

1700M バイト (デフォルトのインデックス作成) 

測定値なし 

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

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

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

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

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

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

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

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

正確なシステムクロック

システムクロックがほかのシステムとほぼ同期が取れていることを確認してください。クロックの同期がとれていれば、レプリケーションも正常に行えます。また、ログファイル内の日付やタイムスタンプのシステム間での対応関係も把握しやすくなります。時間情報プロトコル (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 の物理的な機能

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