test

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

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

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

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

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

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

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.1 Reference』の第 5 章「Directory Server Data Caching」を参照してください。

Directory Server のインデックス

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

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

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

インデックス作成やインデックス設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 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.1 Reference』の第 7 章「Directory Server Logging」を参照してください。

Directory Server のレプリケーション

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

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

Directory Server のレプリケーションの詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 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.1 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 サーバープロパティーを使用します。