| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
前 |
次 |
Directory Server Enterprise Editionのデプロイメントでは、最初に特定のシステム特性を定義する必要があります。この章では、デプロイメントの計画フェーズで対応する必要があるシステム情報について説明します。
この章の内容は、次のとおりです。
デプロイメントで使用されるホスト・システムを決定するときは、次の点を考慮してください。
システムを単一のサーバー専用にするかどうか。
システムでその他のアプリケーションを実行するかどうか、および、実行する場合、そのアプリケーションは何か。
これらのアプリケーションで必要とされるシステムのリソースのパーセンテージはどのくらいか。
ホスト・システムが決定したら、トポロジ内の各ホストについてホスト名を選択します。各ホスト・システムが必ず静的IPアドレスを持つようにします。
ホスト・システムへの物理アクセスを制限します。Directory Server Enterprise Editionには数多くのセキュリティ機能が備えられていますが、ホスト・システムへの物理アクセスが制御されないと、ディレクトリのセキュリティが損なわれます。
Directory Serverインスタンスによってネットワークに対するネーミング・サービスが提供されない場合、またはデプロイメントにリモート管理が関与する場合、ネーミング・サービスおよびホストのドメイン名を適切に構成する必要があります。
設計時に、Directory ServerおよびDirectory Proxy Serverの各インスタンスにポート番号を選択します。可能な場合、本番環境へのディレクトリ・サービスのデプロイ後はポート番号を変更しないでください。
様々なサービスおよびコンポーネントに対し、個別のポート番号を割り当てる必要があります。
LDAP接続を受け入れるためのポート番号を指定します。LDAP通信の標準ポートは389ですが、その他のポートも使用できます。たとえば、サーバーを一般ユーザーとして起動できるようにする必要がある場合には、デフォルトが1389の権限のないポートを使用します。1024より小さいポート番号では権限付きアクセスが必要です。1024より小さいポート番号を使用する場合、特定のLDAPコマンドはrootとして実行する必要があります。
SSLベースの接続を受け入れるためのポート番号を指定します。SSLベースのLDAP (LDAPS)通信の標準ポートは636ですが、一般ユーザーとして実行する場合のデフォルトである1636など、他のポートを使用することもできます。たとえば、サーバーを一般ユーザーとして起動できるように、権限のないポートが必要な場合があります。
権限のないポートを指定し、かつ他のユーザーがアクセスできるシステム上にサーバー・インスタンスをインストールした場合、そのポートは別のアプリケーションにハイジャックされる危険にさらされる可能性があります。つまり、他のアプリケーションで同じアドレスとポートのペアにバインドすることが可能になります。この場合、不法なアプリケーションで、サーバー宛のリクエストを処理できる可能性があります。このようなアプリケーションを使用して、認証処理に使用されるパスワードを取得したり、クライアント・リクエストまたはサーバー・レスポンスを変更したり、DoS攻撃を実行することもできます。
サーバーがリスニングするIPアドレスのリストは、Directory ServerおよびDirectory Proxy Serverの両方で制限できます。Directory Serverには構成属性nsslapd-listenhostおよびnsslapd-securelistenhostがあります。Directory Proxy Serverでは、ldap-listenerおよびldaps-listener構成オブジェクト上にlisten-addressプロパティがあります。リスニングするインタフェースのリストを指定すると、他のプログラムではサーバーと同じポート番号を使用できなくなります。
Directory Serverでは、LDAPのリクエストを処理する以外に、Directory Service Markup Language v2 (DSML)で送信されたリクエストにも応答します。DSMLでも、クライアントでディレクトリ操作をエンコードできます。Directory Serverでは、同じアクセス制御とセキュリティ機能により、DSMLを他のリクエストと同様に処理します。
トポロジにDSMLアクセスが含まれる場合は、次のことを決定します。
DSMLリクエストを受け取るための標準のHTTPポート。デフォルト・ポートは80です。
SSLがアクティブ化されている場合、暗号化されたDSMLリクエストを受け取るための暗号化(HTTPS)ポート。デフォルト・ポートは443です。
ホストおよびポートに付加された場合、クライアントでDSMLリクエストを送信するために使用する必要がある完全なURLを決定する相対URL。
DSMLの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDSML-over-HTTPサービスを有効にする方法に関する説明を参照してください。
Directory Service Control Center (DSCC)は、WebブラウザからDirectory ServerおよびDirectory Proxy Serverインスタンスを管理するために使用できるWebアプリケーションです。サーバーがDSCCによって認識されるようにするには、そのサーバーをDSCCに登録する必要があります。登録されていないサーバーも、コマンドライン・ユーティリティを使用して管理できます。
DSCCは、サーバーがインストールされているシステムにあるDSCCエージェントと通信します。DSCCエージェントはネットワーク・トラフィックをそれらにルーティングして、それらが実行するためのフレームワークを提供します。
DSCCを使用してトポロジ内のサーバーを管理することを計画している場合は、次のポート番号を指定してください。
DSCCがインストールされているシステムでDSCCにアクセスするための、暗号化されたHTTPSポート。デフォルト・ポートは8080です。
サーバー・インスタンスがインストールされているシステムで、サーバーに対してローカルなDSCCエージェントにアクセスするための、DSCC用管理トラフィック・ポート(デフォルトは11162)。
構成情報をレプリケートする場合は、DSCCレジストリ・インスタンスのポート番号。詳細は、dsccsetupを参照してください。
すべてのコンポーネントが同じシステムにインストールされている場合も、DSCCではこれらのネットワーク・ポートを使用してエージェントと通信します。
デプロイメントにMicrosoft Active Directoryとのアイデンティティの同期が含まれる場合は、Message Queueインスタンス用に、使用可能なポートが必要となります。このポートは、同期に関与する各Directory Serverインスタンスで使用可能である必要があります。Message Queue用のデフォルトの保護されていないポートは80で、デフォルトの保護ポートは443です。
また、デプロイメントを計画するときは、追加のインストールに関して、および構成に関して決定することも必要となります。Identity Synchronization for Windowsのインストールおよび構成の詳細は、Identity Synchronization for Windows 6インストール・ガイド、およびOracle Identity Synchronization for Windows 6.0インストレーションおよび構成ガイドを参照してください。
DSCCはWebアプリケーションとして実行され、Directory Serverの独自のローカル・インスタンスを使用して構成データを保管します。
DSCCを実行するための最小要件は、256MBのメモリーおよび100MBの空きディスク領域です。ただし、最適なパフォーマンスを得るには、DSCC専用の1GB以上のメモリーと、数GBの空きディスク領域のあるシステムでDSCCを実行してください。
Directory Proxy ServerはマルチスレッドJavaプログラムとして実行され、複数のプロセッサをまたいで拡張できるように構築されています。一般的に、使用可能な処理能力が大きいほど適切ですが、実際には、メモリーを追加したりディスクやネットワーク接続を高速化した方が、プロセッサを追加するよりもパフォーマンスが向上する場合があります。
Directory Proxy Serverでは主に、処理中の情報を保持するためにメモリーを使用します。複数のデータ・ソースに対する仮想ディレクトリ・リクエストを処理するための複雑な集計では、一時的に余分なメモリーを使用する場合があります。データ・ソースのいずれかがLDIFファイルである場合、Directory Proxy Serverによって、そのデータ・ソースの表現がメモリー内に構築されます。ただし、大量のLDIFデータ・ソースを使用(非推奨のデプロイメント方法です)しないかぎり、数GBのメモリーをDirectory Proxy Server専用にすれば十分です。十分なメモリーが使用可能である場合には、Directory Proxy Server起動時のJava仮想マシンのヒープ・サイズを増やすことをお薦めします。たとえば、Java仮想マシンのヒープ・サイズを3GBに設定するには、次のコマンドを使用します。
$ dpadm set-flags instance-path jvm-args="-Xms3G -Xmx3G -XX:NewSize=2G -XX:MaxNewSize=2G -XX:+UseParNewGC -XX:+UseConcMarkSweepGC"
このコマンドで使用するいくつかのオプションは、Oracle Java仮想マシンに固有のオプションです。NewSizeおよびMaxNewSize値は、ヒープの2/3にすることをお薦めします。デフォルトのヒープ・サイズは1GBです。
Directory Proxy Serverを使用して、リクエストを処理するためにサーバーで保持するスレッドの数を構成できます。これは、number-of-worker-threadsで説明されているサーバー・プロパティnumber-of-worker-threadsを使用して構成します。目安として、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には、accessロギング用の最大1GBのローカル・ディスク領域と、errorsロギング用にさらに1GBのローカル・ディスク領域が必要です。Directory Proxy Serverでクライアント・アプリケーション・リクエストを処理するときに書き込まれるaccessログ・メッセージの数によって、ロギングがパフォーマンスのボトルネックになる可能性があります。ただし、通常、本番環境ではロギングを有効なままにする必要があります。このため、最高のパフォーマンスを実現するには、Directory Proxy Serverのログを、高速な専用ディスク・サブシステム上に配置します。ログ設定の調整手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverのログの構成に関する説明を参照してください。
Directory Proxy Serverはネットワーク集約型アプリケーションです。Directory Proxy Serverでは、クライアント・アプリケーション・リクエストごとに、複数の操作を異なるデータ・ソースに送信する可能性があります。Directory Proxy Serverとデータ・ソース間のネットワーク接続が高速で、十分な帯域幅があり、待機時間も短いことを確認してください。また、Directory Proxy Serverとクライアント・アプリケーション間の接続で予期されるトラフィック量を処理できることも確認してください。
接続が非常に頻繁にオープンおよびクローズされる場合は、TCPスタックの待機状態が継続する時間を1秒に短縮することを検討します。Solarisで、(スーパーユーザーとして)次のコマンドを使用します。
$ ndd -set /dev/tcp tcp_time_wait_interval 1000
その他のオペレーティング・システムについては、そのオペレーティング・システムのドキュメントを参照してください。
中規模から大規模のDirectory Serverデプロイメントに適したハードウェアを決定するには、本番時に提供することが予期されるデータに類似したデータと、予期されるクライアント・アプリケーションからのアクセス・パターンに類似したアクセス・パターンに基づいて、なんらかのテストを行う必要があります。特定のシステム用に最適化する場合には、システム・バス、周辺バス、入出力デバイスおよびサポートされているファイル・システムがどのように動作するかについて、理解しておく必要があります。Directory Serverをサポートするように入出力サブシステムの機能をチューニングするとき、その機能を活用するために、この知識が役立ちます。
この項では、Directory Serverのハードウェアのサイズ設定に対するアプローチ方法について説明します。ここでは、デプロイメントでDirectory Server専用として、いくつのプロセッサ、どれだけのメモリー、どれだけのディスク領域、およびどのようなタイプのネットワーク接続を使用するかを決定する場合の考慮事項を示します。
この項の内容は次のとおりです。
|
注意: 特に明記されていないかぎり、次の各項で説明されているサーバー・プロパティは、 |
パフォーマンスのチューニングは、特定のデプロイメント要件が反映されるように、デフォルト構成を変更することを意味します。次のプロセス・フェーズのリストは、Directory Serverのチューニング時に考慮する主な項目を示しています。
デプロイメント要件に基づいて、特定の測定可能なチューニング目標を定義します。
次の質問事項を検討してください。
どのアプリケーションがDirectory Serverを使用しますか。
システム全体をDirectory Server専用にすることができますか。
システムで他のアプリケーションも実行されますか。
その場合、システムで実行される他のアプリケーションは何ですか。
このデプロイメントによって何件のエントリが処理されますか。
エントリ件数はどのくらいになりますか。
Directory Serverでは、1秒当たり何件の検索をサポートする必要がありますか。
予想される検索のタイプ
Directory Serverでは、1秒当たり何件の更新をサポートする必要がありますか。
予想される更新のタイプ
ピークの更新頻度および検索頻度はどのようになると予期されますか。
平均頻度はどれくらいになると予期されますか。
デプロイメントでは、このシステム上で一括インポートによる初期化が繰り返し必要になりますか。
その場合、データのインポート頻度はどのくらいであると予期されますか。何件のエントリがインポートされますか。
どのようなタイプのエントリですか。
サーバーの実行中に初期化をオンラインで実行する必要があるかどうか
このリストはすべての要素を網羅しているわけではありません。使用する目標リストにすべての要素が網羅されていることを確認してください。
最適化の実装方法に関する計画を決定します。また、最適化の測定および解析方法に関する計画も決定します。
次の質問事項を検討してください。
システムのハードウェア構成を変更できますか。
すでにあるハードウェアを使用したり、サーバーが稼働しているオペレーティング・システムやDirectory Serverのみをチューニングする以外のことはできますか。
他のアプリケーションをどのようにシミュレートできますか。
テスト用の代表的なデータのサンプルは、どのように生成しますか。
結果をどのように測定しますか。
結果をどのように解析しますか。
計画したテストを実行します。デプロイメントが大規模で複雑な場合、このフェーズに長い時間がかかる可能性があります。
テストした潜在的な最適化によって、プロセス開始時に定義した目標が達成されたかどうかをチェックします。
最適化によって目標が達成された場合は、その結果を文書化します。
最適化によって目標が達成されなかった場合は、Directory Serverをプロファイリングおよび監視します。
潜在的な変更を適用した後で、Directory Serverの動作をプロファイリングおよび監視します。
関係するすべての動作の測定値を収集します。
プロファイリング中や監視中に観察した動作をグラフ化および解析します。証拠を見つけたり、追加のテストの必要性を示すパターンを発見するように努めます。
プロファイリングおよび監視フェーズに戻って、追加でデータを収集する必要がある可能性もあります。
測定値の解析結果によって示される、追加的かつ潜在的な最適化を適用します。
テストの実行フェーズに戻ります。
適用した最適化によってプロセス開始時に定義した目標が達成された場合には、その最適化を適切に文書化し、後でその最適化を容易に再現できるようにします。
どれだけのディスクやメモリーをDirectory Server専用にするかは、ディレクトリ・データによって異なります。LDIFに代表的なデータがすでにある場合は、デプロイメントのハードウェアをサイズ設定するとき、そのデータを使用します。ここで代表的なデータとは、デプロイメントで使用することが予期されるデータに対応するサンプル・データを意味し、デプロイメントで使用する実際のデータを意味するものではありません。実際のデータは、現実的なプライバシに関する配慮を必要とし、代表的なデータの生成に必要となる仕様に比べて桁違いに大きくなる場合があるため、テスト対象のすべてのケースを実施することが困難になることがあります。代表的なデータに含まれるエントリの平均サイズは、デプロイメント時に予期されるサイズに近く、その属性は、デプロイメント時に予期される値と同様の値を持ち、その数は、デプロイメント時に予期される比率と同様の比率で存在しています。
代表的なデータに基づいてなんらかの決定を下す場合には、予期される増加分を考慮します。容量計画においては、現在のデータのオーバーヘッド分を含めることをお薦めします。
代表的なデータをまだ用意していない場合は、makeldifコマンドを使用してサンプル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では、データの読み書きを行うとき、ページと呼ばれる固定長のデータ・ブロックを操作します。ページ・サイズを増やすことにより、1つのディスク操作で読み書きされるブロックのサイズが増大します。
ページ・サイズはエントリのサイズと関係し、パフォーマンスにとって不可欠の要素です。エントリの平均サイズがdb-page-size/4-24 (24はページごとのバイナリ・ツリー内部構造)より大きいことがわかっている場合は、データベース・ページ・サイズを増やす必要があります。データベースのページ・サイズは、ファイル・システムのディスク・ブロック・サイズと一致する必要もあります。
Directory Serverは、クライアント・アプリケーションのリクエストにすばやく応答するように設計されています。Directory Serverでは、ディスクからディレクトリ・データが読み取られるまで待つ必要がないように、メモリー内にデータをキャッシュします。データベース・ファイル用、ディレクトリ・エントリ用およびLDIFからのディレクトリ・データのインポート用のキャッシュとして、どれだけのメモリーが使用されるかを構成できます。
物理メモリーにすべてのディレクトリ・データをキャッシュするのに十分な領域を使用できるハードウェア上で、Directory Serverを実行するのが理想的です。データが適切に収まるようにすることで、システムで動作に必要な物理メモリーを確保でき、かつ、ファイル・システムで、そのキャッシュ化や操作に必要な物理メモリーを確保できるようにする必要があります。一度データがキャッシュに書き込まれると、ディレクトリ・エントリが変更されないかぎり、Directory Serverではディスクに対してデータの読み書きを行う必要がなくなります。
デフォルトでは、エントリ・キャッシュは、サーバーによって、負荷に応じて完全に管理されます。エントリ・キャッシュ設定を変更する前に、デフォルト値を使用した場合のサーバーの動作を評価することをお薦めします。
Directory Serverでは64ビット・メモリー・アドレス指定をサポートしているため、64ビット・プロセッサでアドレス指定可能なサイズであるかぎり、どのくらい大きい合計キャッシュ・サイズでも処理できます。小規模から中規模のデプロイメントでは、多くの場合、すべてのディレクトリ・データをキャッシュ内に保持できるだけのメモリーを確保できます。ただし、大規模デプロイメントでは、すべてをキャッシュに保持することは、現実的でないか費用効率が高くない場合があります。
大規模デプロイメントでは、すべてをメモリーにキャッシュすると、副作用が発生する可能性があります。プロセスのメモリー・マップをトラバースしてデータを収集する、pmapコマンドなどのツールを実行すると、長時間にわたり、サーバー・プロセスが動かなくなる可能性があります。コア・ファイルが非常に大きくなるため、クラッシュ時にそれらをディスクに書き込むために数分かかる可能性があります。サーバーが突然停止した後で再起動した場合、起動時間が長くなることがあります。また、Directory Serverがチェックポイントに到達し、ダーティ・キャッシュ・ページをディスクにフラッシュする必要がある場合には、Directory Serverが一時的に停止し、応答しなくなる可能性もあります。キャッシュが非常に大きい場合はこの一時停止も非常に長くなり、Directory Serverが停止しているものと監視ソフトウェアによって判断される可能性があります。
オペレーティング・システム・レベルの入出力バッファにより、パフォーマンスが向上する場合があります。非常に大きいバッファは、少ないデータベース・キャッシュを補うことができます。
キャッシュおよびキャッシュ設定の詳細は、「キャッシュ設定のチューニング」を参照してください。キャッシュ・サイズのチューニングの詳細は、Directory Serverのキャッシュ・サイズ設定の基本(http://blogs.sun.com/DirectoryManager/resource/ds_cache_sizing.pdf)を参照してください。
Directory Serverでは、ディレクトリ・エントリの属性値に対する索引を作成することで、それらの属性値の検索を高速化します。様々な方法で索引が作成されるよう属性を構成できます。たとえば、索引によって、ある属性が値を持っているか、特定の値に等しい値を持っているかまたは特定の部分文字列を含む値を持っているかを、Directory Serverですばやく判別できるようになります。
索引によって検索時のパフォーマンスが向上する可能性がありますが、書込みパフォーマンスに影響する可能性もあります。ある属性の索引が作成されると、Directory Serverではその属性の値が変更されるたびに索引を更新する必要があります。
Directory Serverでは、索引データがファイルに保存されます。構成する索引が多いほど、必要なディスク領域も多くなります。Directory Serverの索引およびデータ・ファイルはデフォルトで、instance-path/db/ディレクトリ下にあります。
索引作成および索引設定の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第9章「Directory Serverの索引作成」を参照してください。
Directory Serverのいくつかの管理ファイルは、サイズが非常に大きくなる可能性があります。これらのファイルには、ディレクトリ・データを含むLDIFファイル、バックアップ、コア・ファイルおよびログ・ファイルなどがあります。
デプロイメントによっては、Directory Serverデータのインポートおよび補助バックアップの両方の用途でLDIFを使用できます。標準テキスト形式のLDIFを使用すると、バイナリ・データだけでなく文字列もエクスポートできます。大規模デプロイメントの場合、LDIFによって多くのディスク領域が使用されることがあります。たとえば、平均サイズが2KBのエントリが1千万件含まれているディレクトリは、LDIF表現ではディスク上で20GBを使用します。この形式を補助バックアップとして使用する場合は、このサイズのLDIFファイルを複数個維持することがあります。
バイナリのバックアップ・ファイルも、少なくとも保管のためにどこか他の場所に移動されるまでは、ディスク領域を使用します。Directory Serverユーティリティによって生成されるバックアップ・ファイルは、ディレクトリ・データベース・ファイルのバイナリ・コピーで構成されます。大規模デプロイメントの場合は別の方法として、Directory Serverを凍結モードにしてから、ファイル・システムのスナップショットを取ることもできます。いずれにしても、バックアップに使用可能なディスク領域が必要です。
Directory Serverではデフォルトで、ログ・メッセージをinstance-path/logs/accessおよびinstance-path/logs/errorsに書き込みます。Directory Serverにはデフォルトで、accessロギング用の1GBのローカル・ディスク領域およびerrorsロギング用にさらに200MBのローカル・ディスク領域が必要です。
Directory Serverロギングの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第10章「Directory Serverのロギング」を参照してください。
Directory Serverでは、ディレクトリ・データをレプリケートすることで、デプロイメント内のサーバーの可用性を高め、サーバー間のロード・バランシングを行うことが可能になります。Directory Serverを使用すると、複数の読み書き(マスター)レプリカを一緒にデプロイできます。
サーバーではこれを可能にするために、内部的にディレクトリ・データへの変更を追跡します。同じデータが複数の読み書きレプリカ上で変更されても、Directory Serverではその変更をすべてのレプリカ上で正しく解決できます。これらの変更を追跡するためのデータは、レプリケーション時に必要とされなくなるまで、保持しておく必要があります。変更は、パージ遅延によって指定された期間のみ保持されます(デフォルト値は7日間です)。ディレクトリ・データ、特に、大きい複数値属性に多数の変更が加えられた場合、このデータは非常に大きくなることがあります。
増大のレベルは様々な要素によって異なるため、可能性のあるデータの増大量を計算するための汎用的な数式はありません。一般的な変更をテストして増大量を測定することが、最適なアプローチとなります。次の要素は、エントリの変更に伴うデータの増大に影響を及ぼします。
変更対象のエントリのタイプと属性のタイプ。
複数値属性では増大量が大きくなります。属性値が小さい場合は、増大量はより顕著になります。
エントリに課されるワークロード。
エントリの追加や削除を行うと、増大量が大きくなります。属性値を追加すると、属性値を置き換えた場合よりも増大量が大きくなります。
変更対象のエントリ数および各エントリ内の変更対象の属性の数。
データベース・ページのサイズ。
非常に多数の変更を加えた場合、特定のエントリがデータベース・ページ・サイズよりも大きくなる可能性があります。
パージ遅延の期間が過ぎ、かつエントリがもう一度変更されるまで、レプリケーションのメタデータはエントリ内に保持されたままになっていることに注意してください。
Directory Serverのレプリケーションの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。
Directory Serverはマルチスレッド・プロセスとして実行され、マルチプロセッサ・システム上で拡張できるように設計されています。Directory Serverで操作を処理するために起動時に作成されるスレッドの数を構成できます。デフォルトでは、Directory Serverにより30個のスレッドが作成されます。値を設定するには、dsconfコマンドを使用してサーバー・プロパティ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により使用されるすべてのキャッシュを保持できます。さらに、ある適切な量の追加物理メモリーが、将来の規模増大を考慮して使用可能になっています。十分な物理メモリーが使用可能な場合には、エントリ・キャッシュ・サイズを十分に大きい値に設定し、ディレクトリ内のすべてのエントリを保持できるようにします。そのような値を構成するための標準的な方法は、テストを実行してから、その結果を使用してnsslapd-cachesizeパラメータを設定することです。
たとえば、サーバーで1秒当たり20000回の操作を処理できる場合、エントリ・キャッシュには30000件から40000件のエントリを保持する必要があります。このような状況下では、エントリ・キャッシュはサーバー上の負荷の1.5から2倍の範囲内にある必要があります。負荷のパターンが変化した場合は、新しい値を設定する必要があります。
entry-cache-size接尾辞プロパティを使用します。db-cache-sizeプロパティを使用して、すべての索引を保持するために十分なデータベース・キャッシュ・サイズを設定します。dn-cache-sizeまたはdn-cache-countプロパティを使用して、DNキャッシュのサイズを制御します。
設定可能なキャッシュ・サイズ・プロパティの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』またはserverのマニュアル・ページを参照してください。エントリ・キャッシュの詳細は、Oracle Directory Server Enterprise Editionリファレンスを参照してください。
索引作成を最適化します。
不要な索引を削除します。予期されるリクエストをサポートするための索引を追加します。
場合によっては、新しいアプリケーションからのリクエストをサポートする索引を追加することもできます。索引の追加、削除または変更は、Directory Serverの稼働中に実行できます。たとえば、dsconf create-indexやdsconf delete-indexなどのコマンドを使用します。
システム索引を削除しないように注意してください。システム索引のリストは、Oracle Directory Server Enterprise Editionリファレンスのシステム索引およびデフォルト索引に関する説明を参照してください。
ユーザーが索引に変更を加えると、Directory Serverにより徐々にデータの索引が作成されます。dsconf reindexコマンドを使用して、Directory Serverで強制的に索引を再生成することもできます。
索引を使用する検索のみを許可します。
索引を使用しない検索によって、サーバーのパフォーマンスに大幅な悪影響が発生する場合があります。索引を使用しない検索では、サーバー・リソースを大量に消費する可能性もあります。
require-index-enabled接尾辞プロパティをonに設定することで、索引を使用しない検索を拒否するようサーバーに強制することを検討します。
all-ids-thresholdプロパティを使用して、索引キー当たりの値の最大数を調整します。
idsktuneコマンドからの推奨事項に従って、基盤となるオペレーティング・システムをチューニングします。詳細は、idsktuneを参照してください。
操作制限を調整します。
操作制限を調整できることで、Directory Serverによって過度のリソースが単一の操作に使用されることが防止されます。より多くの機能を必要とするクライアント・アプリケーションには、一意のバインドDNを割り当て、それらの一意のバインドDNに固有のリソース制限を設定することを検討します。
ディスク・アクティビティを分散します。
大量の更新をサポートするデプロイメントでは特に、Directory Serverに非常に多くのディスク入出力が集中する可能性があります。可能な場合は、個別のコントローラを使用して、この負荷を複数のディスクに分散することを検討します。
不要なロギングを無効にします。
ディスク・アクセスはメモリー・アクセスよりも低速です。したがって、過度のロギングはパフォーマンスに悪影響を及ぼす可能性があります。読取り専用のサーバー・インスタンス上など、監査ロギングが必要ない場合にそのロギングをオフにしておくことで、ディスクの負荷を減らしてください。エラー・ログを使用して問題のトラブルシューティングを行わないときには、エラー・ロギングを最小レベルにしておきます。また、ログ・ファイルを専用のディスク上や、レプリケーション変更ログ用のディスクなどの、使用頻度の低いディスク上に配置することによっても、ロギングの影響を軽減できます。
多数の更新をレプリケートする場合には、適切なレプリケーション承諾プロパティを調整することを検討します。
プロパティは、transport-compression、transport-group-sizeおよびtransport-window-sizeです。
Solarisシステムでは、データベース・ホーム・ディレクトリをtmpfsファイル・システムに移動します。
db-env-pathプロパティで指定されるデータベース・ホーム・ディレクトリは、Directory Serverによりデータベース・キャッシュ・バッキング・ファイルが格納される場所を示します。データ・ファイルはデフォルトで、instance-path/db下に存在し続けます。
データベース・キャッシュ・バッキング・ファイルをtmpfsファイル・システム上に置くことで、システムでデータベース・キャッシュ・バッキング・ファイルがディスクに繰り返しフラッシュされなくなります。これにより、更新時のパフォーマンスのボトルネックが回避されます。場合によっては、検索時のパフォーマンスのボトルネックも回避されます。データベースのキャッシュ・メモリーはDirectory Serverのプロセス空間にマップされます。システムでは基本的に、tmpfsファイル・システム内のキャッシュ・メモリーおよびバッキング・ファイルの保持に使用されるメモリーを共有します。したがって、必要メモリー領域については基本的にコストなしに、パフォーマンスを改善できます。
この最適化に関連する主なコストは、ホスト・マシンを再起動した後にデータベース・キャッシュを再構築する必要があることです。ソフトウェアまたはハードウェアでの障害発生後にのみ再起動が発生することが予期される場合、このコストはおそらく回避できません。そのような障害が発生した場合は、いずれにしてもデータベース・キャッシュを再構築する必要があります。
ソフトウェアまたはハードウェアでの障害が発生したときに、更新が失われても問題がない場合には、トランザクション・バッチを有効にします。
トランザクション・バッチを有効にするには、サーバー・プロパティdb-batched-transaction-countを設定します。
トランザクション・ログが更新されるたびに、更新データが失われないように、同期操作が続いて実行されます。トランザクション・バッチを有効にすると、複数の更新がまとめられた後、トランザクション・ログに書き込まれます。同期操作は、バッチ全体がトランザクション・ログに書き込まれるときにのみ、実行されます。したがって、トランザクション・バッチによって、更新時のパフォーマンスを大幅に改善できます。この改善にはトレード・オフが伴います。そのトレード・オフとは、クラッシュした時点でトランザクション・ログにまだ書き込まれていない更新データが失われることです。
|
注意: トランザクション・バッチを有効にすると、ソフトウェアまたはハードウェアでの障害発生時に最大 更新が失われると問題がある場合は、この最適化を使用しないでください。 |
整合性チェックを遅延させるように、参照整合性プラグインを構成します。
参照整合性プラグインでは、エントリが変更されたりディレクトリから削除された場合に、それらのエントリへのすべての参照が確実に更新されるようにします。この処理はデフォルトでは、削除操作に対するレスポンスがクライアントに返される前に、同期的に実行されます。プラグインを構成して、この更新が非同期で実行されるようにすることができます。ref-integrity-check-delayサーバー・プロパティを使用します。
Directory Serverのパフォーマンスを測定するには、サーバーを準備した後、本番において予期されるタイプのクライアント・アプリケーション・トラフィックをそのサーバーに適用します。本番で発生するクライアント・アプリケーションのアクセス・パターン・タイプの再現性が高いほど、ハードウェアのサイズ設定およびDirectory Serverの構成をより適切に実行できます。
Directory Server Resource Kitには、基本的なテストのために使用可能なauthrate、modrateおよびsearchrateコマンドが含まれています。これらのコマンドにより、使用するディレクトリ・サービスでサポート可能なバインド頻度、変更頻度および検索頻度を測定できます。
SLAMDを使用して、複雑で現実的なクライアント・アクセスのシミュレーション、測定およびグラフ化を行うこともできます。SLAMD分散負荷生成エンジン(SLAMD)は、ネットワーク・ベースのアプリケーションのパフォーマンスについて負荷テストを実行し、解析するために設計されたJavaアプリケーションです。これは、LDAPディレクトリ・サーバーのパフォーマンスについてベンチマークを実行し、分析するために、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によってサーバー操作を処理するために起動されるスレッドの数を表すサーバー・プロパティthread-countを、dsconfコマンドを使用して調整することを検討します。
ただし、特定のディレクトリ・デプロイメントでは、プロセッサを追加してもパフォーマンスに大きく影響しない場合があります。検索、索引作成およびレプリケーションで要求の厳しいパフォーマンス要件を扱うときは、解決策の一部として、ロード・バランシングやディレクトリ・プロキシなどの技術を検討します。
次の要素は、必要なメモリーの量に大きく影響を及ぼします。
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 Serverインスタンス専用である場合は、swappinessをゼロに設定します。システムにおいて、複数の負荷の大きい処理や複数のDirectory Serverの並列インスタンスを実行する場合は、swappinessの様々な設定を使用してディレクトリ・パフォーマンスをテストすることを検討します。
ディスク使用とI/Oの能力は、パフォーマンスに大きく影響します。多数の変更をサポートするデプロイメントでは、特に、ディスク・サブシステムがI/Oのボトルネックになる可能性があります。この項では、Directory Serverインスタンスの全体的なディスク容量を見積もるために推奨される方法について説明します。
|
注意: Directory Serverやそれによりアクセスされるデータをネットワーク・ディスク上にインストールしないでください。 Directory Serverソフトウェアでは、ネットワークに接続されたストレージをNFS、AFSまたはSMB経由で使用することをサポートしません。構成、データベースおよび索引ファイルはすべて、インストール後も、常にローカル・ストレージ上に配置する必要があります。ログ・ファイルはネットワーク・ディスク上に格納できます。 |
次の要素は、必要なローカル・ディスク領域に大きく影響を及ぼします。
ディレクトリ・エントリの数
エントリの平均サイズ
サーバー・データベースのページ・サイズの設定(ディレクトリ・データをインポートする場合)
データベースのページ・サイズを調整するには、nsslapd-db-page-size属性を設定します。詳細は、「Directory Serverのデータベース・ページ・サイズ」を参照してください。
ディレクトリ・データ上で維持される索引の数
格納されるLDIF、バックアップ、ログおよびコア・ファイルのサイズ
索引の設定、データベースのページ・サイズの調整およびディレクトリ・データのインポートが完了したら、instance-path/の内容のサイズを読み取り、それに予期されるLDIF、バックアップ、ログおよびコア・ファイルのサイズを追加することで、インスタンスに必要なディスク容量を見積もることができます。また、特に、ピーク処理中に、測定したサイズがどのくらい増加することが予期されるかを見積もります。デバッグ目的で、ログ・レベルを上げたり、ログ・サイズを増やすことが必要になった場合に備え、必ず、数GBの追加領域をerrorsログ用として残しておきます。
ディレクトリ・データに必要なディスクの見積りは、推定によって取得できる場合があります。本番時に予期されるデータと同量のデータを使用してDirectory Serverに負荷をかけることが現実的ではない場合には、「サンプル・ディレクトリ・データの作成」に示したように、より小さいサンプル・データ・セットに基づいて推定します。使用するディレクトリ・データの量が本番時より少ない場合、他の測定値についても推定する必要があります。
ローカル・ディスクがどのくらい高速である必要があるかは、次の要素によって決定されます。
レプリケーション・トラフィックの量など、維持される更新のレベル
ディレクトリ・データが主にキャッシュ内またはディスク上のどちらに存在するか
アクセス・ロギングとエラー・ロギングで使用するログ・レベルおよび監査ログを有効にするかどうか
ディレクトリ・データ、ログおよびトランザクション・ログ(更新用)を個別のディスク・サブシステムに配置できるかどうか
Directory Serverがオンラインまたはオフラインのいずれの状態のときにバックアップが実行されるか
通常の運用環境では、使用するディスクは飽和しないようにしてください。Solaris iostatコマンドなどのツールを使用すると、潜在的なI/Oのボトルネックを特定できます。
ディスクのスループットを増やすには、複数のディスク・サブシステムにファイルを分散します。トランザクション・ログ(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製品で提供されているような、大容量の不揮発性I/Oバッファや高パフォーマンスのディスク・サブシステムによって、Directory Serverのパフォーマンスおよび稼働時間を大幅に改善できます。Solaris 10システムの場合、ZFSを使用することによっても、パフォーマンスを改善できます。
Directory Serverはネットワーク集約型アプリケーションです。次の式を使用して、理論的な最大スループットを見積もることができます。この式ではレプリケーションのトラフィックが考慮されていないことに注意してください。
max. throughput = max. entries returned/second x average entry size
Directory Serverではピーク時に毎秒5000件の検索に応答する必要があり、またサーバーからは検索ごとに1つのエントリが返される場合を考えます。エントリの平均サイズは2000バイトです。理論的な最大スループットは、レプリケーションを考慮しない場合、10MBつまり80メガビットになります。80メガビットは、多くの場合、単一の100メガビットEthernetアダプタで実現可能なスループットよりも大きくなります。Directory Serverインスタンスのネットワーク可用性を改善するには、システムにより高速な接続を装備するか、複数のネットワーク・インタフェースを装備します。Directory Serverでは、同一プロセス内で複数のネットワーク・インタフェースでのリスニングが可能です。
|
注意: 前述の例では、クライアント・アプリケーションでは、ディレクトリを読み取ったり検索するときに、すべての属性を要求すると想定していました。一般的に、必要な属性のみが要求されるように、クライアント・アプリケーションを設計する必要があります。 |
広域ネットワーク上でマルチマスター・レプリケーションを計画する場合には、その構成をテストし、その接続により最小限の待機時間とゼロに近いパケット損失で十分なスループットが提供されることを確認します。レプリケーションの速度は、長い待機時間および大量のパケット損失の両方によって低下します。さらに、レプリケーション・トラフィックがロード・バランサを通過するようなトポロジは避けてください。
Directory Serverのデフォルト構成では、クライアント・アプリケーションで必要以上のDirectory Serverリソースを使用できるようになっています。
次のようなリソースの使用法により、ディレクトリのパフォーマンスに悪影響が及ぶ可能性があります。
多数の接続をオープンした後に、アイドル状態や未使用状態のままにすること
索引を使用しない高コストの検索の不必要な起動
計画外の巨大なバイナリ属性値の格納
デプロイメント状況によっては、デフォルト構成を変更することが好ましくない場合があります。Directory Serverのチューニングが不可能なデプロイメントでは、Directory Proxy Serverを使用することで、リソースを制限し、DoS攻撃から保護します。
デプロイメント状況によっては、Directory Serverの1つのインスタンスによって、ユーザー・メール・アプリケーションなどのディレクトリ・クライアントやメッセージング・サーバーなどの、クライアント・アプリケーションをサポートすることが必要になります。そのような状況では、バインドDNベースのリソース制限を使用することで、ディレクトリ集約型アプリケーションに対して個別の制限を引き上げることを検討します。個々のアカウントの制限を調整するには、その個別のエントリ上の属性nsSizeLimit、nsTimeLimit、nsLookThroughLimitおよびnsIdleTimeoutを設定します。個々のアカウントに対するリソース制限の制御方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の各クライアント・アカウントのリソース制限の設定に関する説明を参照してください。
表6-1では、リソース制限のグローバル値を設定するパラメータについて説明します。表6-1の制限は、Directory Managerユーザーには適用されないため、クライアント・アプリケーションがDirectory Managerユーザーとして接続することがないようにしてください。
表6-1 クライアント・アプリケーション専用のリソースに関するチューニング推奨事項
| チューニング・パラメータ | 説明 |
|---|---|
|
サーバー・プロパティ
|
クライアント接続のアイドル状態が何秒間続いた場合に、その接続をDirectory Serverによってクローズするかを設定します。ここで、アイドル状態とは、接続がオープンしたまま、操作がリクエストされない状態を意味します。デフォルトでは、時間制限は設定されません。 このサーバー・プロパティを設定するには、 メッセージング・サーバーなどの一部のアプリケーションでは、トラフィックが少ないときにはアイドル状態のままであるもののクローズしない必要がある、一連の接続をオープンする場合があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。 いずれの場合も、オープンしていることを他のアプリケーションが予期している接続をクローズしないように、この値を十分大きく設定するとともに、接続を不必要にアイドル状態のままにできないように、この値を十分小さく設定します。たとえば、これを7200秒、つまり2時間に設定することを検討してください。 |
|
属性
|
クライアント接続の停止が何ミリ秒間続いた場合に、その接続をDirectory Serverによってクローズするかを設定します。ここで、停止されているとは、クライアントに出力を送信するとき、またはクライアントから入力を読み取るときに、サーバーがブロックされることを意味します。 この属性を設定するには、 特に、DoS攻撃にさらされるDirectory Serverインスタンスの場合は、この値をデフォルトの1,800,000ミリ秒つまり30分より小さくすることを検討してください。 |
|
サーバー・プロパティ
|
検索時に一致するかどうかをチェックする候補エントリの最大数を設定します。 このサーバー・プロパティを設定するには、 メッセージング・サーバーなどの一部のアプリケーションでは、ディレクトリ全体を検索する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。 いずれにしても、この値をデフォルトの5000エントリより小さいが、 |
|
属性
|
基本エンコーディング・ルール(BER)に従ってエンコードされたASN.1受信メッセージの最大サイズを、バイト単位で設定します。Directory Serverでは、この制限よりも大きいエントリを追加するリクエストは拒否されます。 この属性を設定するには、 ディレクトリ・データの最大エントリ・サイズを正確に予測できる場合には、この値をデフォルトの2097152つまり2MBから、予期される最大ディレクトリ・エントリのサイズに変更することを検討してください。 更新に対する2番目に大きいサイズ制限は、トランザクション・ログ・ファイルのサイズ |
|
サーバー・プロパティ
|
クライアント接続当たりの最大スレッド数を設定します。 このサーバー・プロパティを設定するには、 メッセージング・サーバーなどの一部のアプリケーションでは、一連の接続をオープンし、それらの各接続上で多数のリクエストを発行する場合があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。 一部のアプリケーションにより1つの接続で多数のリクエストが実行されることが予期される場合には、この値をデフォルトの5より大きく10より小さい値に増やすことを検討してください。通常は、1接続当たり10個を超えるスレッドを指定しないでください。 |
|
サーバー・プロパティ
|
検索リクエストに応答してDirectory Serverから返されるエントリの最大数を設定します。 このサーバー・プロパティを設定するには、 メッセージング・サーバーなどの一部のアプリケーションでは、ディレクトリ全体を検索する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。 いずれにしても、この値をデフォルトの2000エントリより小さい値に設定することを検討してください。 |
|
サーバー・プロパティ
|
Directory Serverにおいて1つの検索リクエストの処理に最大何秒使用できるかを設定します。 このサーバー・プロパティを設定するには、 メッセージング・サーバーなどの一部のアプリケーションでは、非常に大規模な検索を実行する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。 いずれにしても、この値は、デプロイメント要件を満たす範囲内でできるだけ小さく設定してください。デフォルト値の3600秒つまり1時間は、多くのデプロイメントでは必要以上に大きい値です。600秒つまり10分を最適化テストの出発点として使用することを検討してください。 |
表6-2では、Directory Serverインスタンスによるシステム・リソースおよびネットワーク・リソースの使用方法をチューニングするために使用可能なパラメータについて説明します。
表6-2 システム・リソースに関するチューニング推奨事項
| チューニング・パラメータ | 説明 |
|---|---|
|
属性
|
Directory ServerによりリスニングされるIPインタフェースのホスト名を設定します。この属性は複数の値を持つことができます。 この属性を設定するには、 デフォルト動作は、すべてのインタフェース上でリスニングすることです。このデフォルト動作は、冗長性のあるネットワーク・インタフェースを使用して可用性やスループットを高めるような、高ボリュームのデプロイメントに適しています。 マルチホーム・システム上にデプロイする場合や、IPv4またはIPv6の各プロトコルをそれぞれ個別のインタフェースを使用してサポートするようなシステム上でIPv4またはIPv6トラフィックのみをリスニングする場合に、この値の設定を検討してください。SSL使用時には、 |
|
サーバー・プロパティ
|
Directory Serverにより使用されるファイル記述子の最大数を設定します。 このサーバー・プロパティを設定するには、 デフォルト値は、Directory Serverインスタンスが作成されるときに、システム上の1つのプロセスに許可されるファイル記述子の最大数です。その最大値は、システム上の1つのプロセスに許可されるファイル記述子の最大数に対応します。詳細は、オペレーティング・システムのドキュメントを参照してください。 Directory Serverでは、ファイル記述子を使用することで、クライアント接続を処理し、ファイルを内部的に維持します。使用可能なファイル記述子の数が十分でないために、Directory Serverで新しい接続のリスニングが時々停止していることがエラー・ログに示されている場合、この属性の値を増やすことで、Directory Serverで同時に処理できるクライアント接続の数が増加する可能性があります。 システム上で使用可能なファイル記述子の数を増やした場合には、この属性の値もそれに応じて設定してください。このプロパティの値は、システム上で使用可能なファイル記述子の最大数以下である必要があります。 |
|
属性
|
TCPパケットの送信をソケット・レベルで遅延させるかどうかを設定します。 この属性を設定するには、 ネットワークのトラフィックを減らす必要がある場合には、これを |
|
属性
|
Directory Serverにより、索引作成やレプリケーションなどの内部処理を管理するために維持されるファイル記述子の数を設定します。そのようなファイル記述子は、クライアント接続を処理するために使用できなくなります。 この属性を設定するには、 次のすべてに該当する場合には、この属性の値をデフォルトの64から増やすことを検討してください。
確保済ファイル記述子の数が増加すると、クライアント接続の処理に使用可能なファイル記述子の数が減少することに注意してください。この属性の値を増やす場合には、システム上で使用可能なファイル記述子の数を増やし、 確保するファイル記述子の数を初めて見積もる目的でこの属性を変更することにした場合、次の式に従って 20 + 4 * (number of databases) + (total number of indexes) + (value of nsoperationconnectionslimit) * (number of chaining backends) + ReplDescriptors + PTADescriptors + SSLDescriptors ここで、ReplDescriptorsは、レプリケーションが使用される場合は、サプライヤ・レプリカの数に8を加えたものになります。PTADescriptorsは、パススルー認証(PTA)プラグインが有効になっている場合は3、それ以外の場合は0になります。SSLDescriptorsは、SSLが使用される場合は5、それ以外の場合は0になります。 インスタンスが接尾辞ごとに2つ以上のデータベースを使用するように構成されていないかぎり、データベースの数はインスタンスの接尾辞の数と同じになります。見積りは、実験的なテストによって検証します。 |
|
属性
|
Directory ServerでSSL接続をリスニングするIPインタフェースのホスト名を設定します。この属性は複数の値を持つことができます。 この属性を設定するには、 デフォルト動作は、すべてのインタフェース上でリスニングすることです。この属性は |
|
サーバー・プロパティ
|
Directory Serverで使用されるスレッドの数を設定します。 このサーバー・プロパティを設定するには、 次のいずれかに該当する場合は、このプロパティの値を調整することを検討してください。
マルチプロセッサ・システムでは、シングル・プロセッサ・システムよりも大きいスレッド・プールを維持できます。この属性の値を最適化する場合の最初の見積りとしては、プロセッサ数の2倍または20に同時更新数を加えたもののいずれかを使用します。 また、クライアント接続当たりの最大スレッド数 見積りは、実験的なテストによって検証します。結果は、特定のデプロイメント状況だけでなく、基盤となるシステムによっても異なります。 |
デフォルトのシステム設定でディレクトリ・サービスのパフォーマンスが最高になるとはかぎりません。この項では、最高のパフォーマンスを実現するためのオペレーティング・システムのチューニング方法について説明します。
サポートされるオペレーティング・システムの最新リストは、『Oracle Directory Server Enterprise Editionリリース・ノート』を参照してください。
システムの全体的なセキュリティを維持する必要があります。また、Directory Serverの正常な動作を保証する必要もあります。このため、推奨される最新のシステム・パッチ、サービス・パックまたはフィックスをインストールします。プラットフォームに適用される最新パッチの最新のリストは、『Oracle Directory Server Enterprise Editionリリース・ノート』を参照してください。
こ項の推奨事項によって、すべてのリスクが排除されるわけではありません。推奨事項の目的は、一般的なセキュリティ上のリスクを制限するための簡潔なチェックリストを提供することです。
ファイアウォールを使用してシステムを分離します。可能な場合、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ルーティング、メール、NetBIOS、NFS、RAS、WebパブリッシングおよびWindowsネットワーク・クライアントなどのサービスを無効にしてください。telnetおよびftpを無効にすることを検討してください。
telnetおよびftpは、多くのネットワーク・サービスと同様に、セキュリティ上のリスクとなります。これらのコマンドでは、ユーザーのパスワードがネットワーク経由でクリア・テキストとして送信されるため、これらの2つのサービスは特に危険です。telnetおよびftpが必要な場合は、回避策として、セキュア・シェル(ssh)やセキュアFTP (sftp)などのクライアントをかわりに使用してください。ネットワーク・サービスを無効にする方法の詳細は、オペレーティング・システムのドキュメントを参照してください。
Directory Serverインスタンスでネットワークに対してネーミング・サービスが提供されない場合、システムのネーミング・サービスを有効にすることを検討してください。その場合、Directory Serverでは、ACIを解決する場合などにそのネーミング・サービスを使用します。
システム・クロックが他のシステムと適切に同期されていることを確認してください。クロックが適切に同期されていると、レプリケーションが容易になります。また、正確に同期されていることによって、ログ・ファイル内の日付やタイム・スタンプのシステム間での対応付けも容易になります。システム時刻を正しく設定するために、ネットワーク・タイム・プロトコル(NTP)クライアントを使用することを検討してください。
dsadmコマンドを使用して、システム・ブート時にサーバー・インスタンスを再起動できるようにすることができます。たとえば、Solaris 10およびWindowsシステムでは、dsadm enable-serviceコマンドを使用します。その他のシステムでは、dsadm autostartコマンドを使用します。システム・ブート時にサーバーが起動するようにする方法は、オペレーティング・システムのドキュメントを参照してください。
可能な場合は、dsadmコマンドを使用するかDSCCからDirectory Serverを停止します。システムの停止中にDirectory Serverが突然停止した場合、すべてのデータがディスクに正しく書き込まれたことは保証されません。したがって、Directory Serverでは、再起動するときに、データベースの完全性を検証する必要があります。このプロセスは時間がかかる場合があります。
さらに、ファイル・システムのロギング・オプションを使用することを検討します。一般的に、ファイル・システムのロギングによって、書込みパフォーマンスが向上すると同時に、ファイル・システム・チェックの実行に必要な時間が短縮されます。クラッシュ時にファイル・システムが正常にマウント解除されなかった場合、システムではファイル・システムをチェックする必要があります。また、RAIDをストレージとして使用することも検討します。
idsktuneコマンドによるシステム固有のチューニング製品に付属のidsktuneユーティリティを使用すると、基本的なシステム構成の問題の診断に役立ちます。ユーティリティによって、高いパフォーマンスを示すディレクトリ・サービスをサポートするようにシステムをチューニングするための推奨事項が示されます。ユーティリティによって実際に推奨事項が実装されるわけではありません。適切な権限を持ったシステム管理者が、推奨事項を実装する必要があります。
ユーティリティをrootとして実行すると、idsktuneではシステムに関する情報を収集します。ユーティリティには、注意、警告およびエラーが推奨される対処法とともに表示されます。idsktuneコマンドでは、次のことがチェックされます。
オペレーティング・システムとカーネルのバージョンが、このリリースでサポートされてること
使用可能なメモリーおよび使用可能なディスク領域が、通常用途の最小要件を満たしていること
システム・リソースの限度が通常用途の最小要件を満たしていること
必須パッチがインストールされていること
|
ヒント: Directory Serverソフトウェアを本番用のシステムにインストールする前に、少なくともすべての |
個々のデプロイメント要件は、最小要件を上回る可能性があります。idsktuneユーティリティによって最小システム要件として指摘されたリソースよりも多くのリソースを提供できます。
特定の推奨事項を実装する前に、ローカル・ネットワークの状態やその他のアプリケーションについて検討します。ネットワーク設定のチューニングに関する追加のヒントは、オペレーティング・システムのドキュメントを参照してください。
Directory Serverでは、同時クライアント接続を処理する場合にファイル記述子を使用します。そのため、サーバー・プロセスで使用可能なファイル記述子の最大数が小さい場合、同時接続数が制限される可能性があります。したがって、ファイル記述子の数に関する推奨事項は、Directory Serverで処理可能な同時接続数に関係します。
Solarisシステムの場合、使用可能なファイル記述子の数を構成するにはrlim_fd_maxパラメータを使用します。使用可能なファイル記述子の数を変更する手順の詳細は、オペレーティング・システムのドキュメントを参照してください。
具体的なネットワーク設定はプラットフォームよって異なります。システムによっては、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設定をチューニングする場合、最も単純な方法は、単純な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のスケーラビリティを決定する物理的機能を示します。
プロセス・サイズ。オペレーティング・システムによって異なりますが、32ビット・バージョンのDirectory Serverでは2GBから4GBのプロセス・サイズがサポートされます。64ビット・バージョンのDirectory Serverのプロセス・サイズは、マシン上で使用可能な物理メモリーの容量によって決定されます。128GBのプロセス・サイズによるテストが完了しています。
LDAPエントリの数。1つのサーバー・インスタンス上で作成できるLDAPエントリの総数は2^32 -1、つまり4Gのエントリです。
各エントリのサイズ。LDAPサーバー内の1つのレコードのサイズは、DB自体に基づき、4GBとなります。また、エントリのサイズも、LDAPリクエストの最大サイズ(maxbersize)によって異なります。その最大値は2GBです。
LDAP接続の数。LDAP接続の数は、プロセスでオープンできるファイル記述子の数によって異なります。一般的に、オープン接続の数が多すぎると、パフォーマンスが低下することに注意してください。
LDAPサーバー(Berkery DB)のサイズ。LDAPサーバーのサイズは、使用するファイルシステムのサイズにより決定されます。
システムの全体的なパフォーマンスの改善に役立つヒントを次に示します。
JDK 1.5ではなく、JDK 1.6を使用します。
$ export JAVA_HOME=JDK1.6-Installation-Directory
プロキシ・サーバー・インスタンスを再起動します。
JRE 64ビットではなく、32ビットを使用します。
$ dpadm set-flags instance-path jvm-args="-Xmx250M -Xms250M -d32"
ヒープ・サイズのほとんどを新規領域に割り当てます。たとえば、-XX:NewSize=500Mとします。
jvm-argsでCMSガベージ・コレクションを使用します。たとえば、-XX:+UseConcMarkSweepGCとします。
不要な場合はアクセス・ログを無効にします。
$ dpconf set-access-log-prop default-log-level:none
この項では、データベースおよびエントリ・キャッシュ・サイズの設定に関する推奨事項を示します。インポート・キャッシュ・サイズはこの対象外となります。ここに示す推奨事項は、検索速度または変更速度のいずれかを最大化するためのものであり、その両方を一度に最大化するものではありません。
この項の内容は次のとおりです。
ここでは、Directory Serverで実現される検索速度または変更速度を最大化するための基本的な推奨事項を示します。次の推奨事項に従って、キャッシュ・サイズを設定します。
ディレクトリ・データが使用可能な物理メモリー内に収まらないか、ちょうど収まって余分な領域がない場合は、db-cache-sizeをデフォルト値の32Mに設定して、オペレーティング・システムのファイル・システム・キャッシュをサーバーでできるだけ多く使用できるようにします。テストを実行し、スループットに基づいてサイズを正しく測定してください。
ディレクトリ・データが使用可能な物理メモリー内に収まり、物理メモリーに余分がある場合は、エントリ・キャッシュが一杯になるか、32ビット・システムの場合はエントリ・キャッシュが最大サイズに達するまで、エントリ・キャッシュにメモリーを割り当てます。次に、データベース・キャッシュが一杯になるか最大サイズに達するまで、データベース・キャッシュにメモリーを割り当てます。
キャッシュ・サイズの設定手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』のメモリーの構成に関する説明を参照してください。
ディレクトリ・データが使用可能な物理メモリー内に収まらないか、ちょうど収まって余分な領域がない場合は、オペレーティング・システムのファイル・システム・キャッシュをできるだけ多くサーバーで使用できるようにします。使用可能なデータベース・キャッシュをいくらか残しておくことにより、各データベース・チェックポイント間で変更がキャッシュに入れられたままになります。
ディレクトリ・データが使用可能な物理メモリー内に収まり、物理メモリーに余分がある場合は、エントリ・キャッシュが一杯になるか、32ビット・システムの場合はエントリ・キャッシュが最大サイズに達するまで、エントリ・キャッシュにメモリーを割り当てます。次に、データベース・キャッシュが一杯になるか最大サイズに達するまで、データベース・キャッシュにメモリーを割り当てます。
キャッシュ・サイズの設定手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』のメモリーの構成に関する説明を参照してください。
ワーキング・セットとは、サーバーがクライアント・アプリケーションに応答できるようにするために、実際にメモリーに取得されるデータのことです。データ・セットとは、クライアント・トラフィックが原因で使用されているディレクトリ内のエントリです。データ・セットは、ディレクトリ内の全エントリを含む場合や、ユーザーがアクティブであるタイム・ゾーンのユーザーに関連するエントリなど、より少数のエントリで構成される場合があります。
使用可能な物理メモリー内に収まるディレクトリ・データ・セットの量に基づいて、3つのデータ・セット・サイズを定義します。
データ・セットは完全に物理メモリー内に収まり、完全にロードされたデータベースおよびエントリ・キャッシュがあります。
データ・セットは物理メモリー内に収まり、余分の物理メモリーをエントリ・キャッシュに割り当てることができます。
データ・セットが小さく、使用可能な物理メモリー内に完全には収まりません。
理想的なのは、データ・セットが小規模であることです。データ・セットが小規模である場合、すべてのエントリがデータベース・キャッシュおよびエントリ・キャッシュの両方に収まるように、データベース・キャッシュ・サイズおよびエントリ・キャッシュ・サイズを設定してください。
次の項では、サーバーですべての検索またはすべての変更操作のいずれかが実行される、中規模および大規模データ・セットに関する推奨事項を示します。
図6-1に、仮想的なシステムにおける検索パフォーマンスを示します。予期されるとおり、ある特定のシステム構成について、Directory Serverの検索パフォーマンスが最高になるのは、データ・セット全体がメモリー内に収まる場合です。
大規模データ・セットでは、データベース・キャッシュおよびエントリ・キャッシュがそれぞれ最小サイズに設定され、使用可能なメモリーが、オペレーティング・システムで、ファイル・システム・キャッシュの割当てに使用できるようになっている場合に、パフォーマンスが向上しています。示されているとおり、より多くのデータ・セットがファイル・システム・キャッシュ内に収まると、パフォーマンスが向上します。
中規模データ・セットでは、データ・セット全体がファイル・システム・キャッシュに保持され、使用可能な余分の物理メモリーがエントリ・キャッシュに使用される場合にパフォーマンスが向上しています。示されているとおり、より多くの中規模データ・セットがエントリ・キャッシュ内に収まると、パフォーマンスが向上します。
図6-2に、仮想的なシステムにおける変更パフォーマンスを示します。予期されるとおり、ある特定のシステム構成について、Directory Serverの変更パフォーマンスが最高になるのは、データ・セット全体がメモリー内に収まる場合です。
大規模データ・セットでは、データベース・キャッシュおよびエントリ・キャッシュがそれぞれ最小サイズに設定され、使用可能なメモリーが、オペレーティング・システムで、ファイル・システム・キャッシュの割当てに使用できるようになっている場合に、パフォーマンスが向上しています。示されているとおり、より多くのデータ・セットがファイル・システム・キャッシュ内に収まると、パフォーマンスが向上します。
中規模データセットの場合、すべてのエントリがファイル・システム・キャッシュに収まった時点で変更パフォーマンスが最大になります。「基本的なチューニング推奨事項」で説明するとおり、使用可能なデータベース・キャッシュをいくらか残しておくことにより、各データベース・チェックポイント間で変更がキャッシュに入れられたままになります。
索引を使用して検索の実行にかかる時間を短縮することにより、パフォーマンスを向上できます。ただし、索引にはそれに伴うコストもあります。エントリが更新された場合、そのエントリを参照している索引も更新する必要があります。索引付けされたエントリが増えるほど、索引の更新に必要なリソースが増え、索引がディスク領域およびメモリー領域を消費します。
索引を設計する場合は、検索の高速化によるメリットが索引に伴うコストを相殺するようにしてください。有用な索引を維持することはよい方法ですが、クライアントでほとんど検索されず、使用されない属性の索引を維持することは無駄です。
次の方法で検索のパフォーマンスを最適化できます。
Directory Serverで、索引付けされていないエントリを検索できないようにします。
索引リストの長さを制限します。
データベース・キャッシュのサイズが適切にチューニングされていることを確認します。
Directory Serverで索引付けされていないエントリを検索できないようにするには、接尾辞にrequire-index-enabled接尾辞プロパティを設定します。
特定の検索について索引キー当たりの値の数を制限するには、索引リストのしきい値を設定します。1つの検索キーに対するリスト内のエントリ数が索引リストのしきい値を超えた場合、索引を使用しない検索が実行されます。しきい値は、サーバー・インスタンス全体、接尾辞全体および個別の属性タイプに対して設定できます。等価、プレゼンスおよび部分文字列索引に対して個別のしきい値を設定することもできます。
索引リストのしきい値を変更する手順の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の索引リストのしきい値の変更に関する説明を参照してください。この手順により、all-ids-threshold構成プロパティが変更されます。
サーバー・インスタンスのall-ids-thresholdのグローバル値は、ディレクトリ内にあるエントリの合計数のおよそ5%である必要があります。たとえば、80000件以下のエントリを処理するDirectory Serverのインスタンスの場合、デフォルト値の4000が通常は適切です。非常に大規模なデプロイメントの場合にも、しきい値を50000より大きく設定しないでください。ただし、次の場合には、all-ids-thresholdを5%ガイドラインに従わない値に設定できます。
ディレクトリの大幅な増大が見込まれ、しきい値を合計の5%より高く設定することが適切である場合。
多数の検索をサポートするコンシューマおよびほぼ書込みのみをサポートするマスターがあり、コンシューマとマスターに異なるしきい値を設定することが適切である場合。
LDIFファイルから大きいディレクトリを初期化することを計画しており、初期化の直前にしきい値を変更することが適切である場合。
ディレクトリに深い階層を持つディレクトリ情報ツリーがあり、1レベルまたはサブツリー検索を実行している場合。この場合、親および祖先索引のall-ids-thresholdを高く設定して、特定のブランチの下にある全エントリが索引付けされるようにできます。
索引を使用しない検索の実行数を制限する必要があります。Directory Server Resource Kitに付属のlogconvユーティリティを使用してアクセス・ログを確認し、索引を使用しない検索が頻繁に実行されている証拠を探します。詳細は、logconvのマニュアル・ページを参照してください。
この項では、デプロイメント用のDirectory Serverのディスクおよびメモリー要件のサイズを設定する最初の手順を示す例について説明します。この例に使用されるシステムは、サイズ設定タスクを迅速に完了するために十分な処理能力およびメモリーを備えているシステムの中から、無作為に選択されたものです。必ずしも、本番用に推奨されるシステムを表しているわけではありません。ただし、これにより、本番システムでメモリーおよびディスク領域がどれだけ必要となるかについて、見通しを得ることができます。
次のシステム情報は、Solaris管理コンソール(smc)を使用して取得されたものです。
2つのAMD64 CPU (2.2GHz)
Solaris 10オペレーティング・システム
4GBの物理メモリー
40GBのスワップ
Directory Serverのインストール前に使用中だった物理メモリー: 700MB
Directory Serverのインストール前の空き物理メモリー: 3400MB
CPU使用率: 1%
ローカル・ディスク: ロギング付きUFSとしてフォーマットされた1つのパーティション
この例では、システムはDirectory Server専用でした。他のユーザーはログインしておらず、デフォルトのシステム・プロセスのみが実行されていました。
zipディストリビューションを展開して、ローカル・ディスク領域にDirectory Server Enterprise Editionソフトウェアをインストールします。
詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』のZipディストリビューションを使用したDirectory Server Enterprise Editionのインストールに関する説明を参照してください。
便宜上、環境変数を次のように設定します。
$ export PATH=/local/dsee7/bin:${PATH} $ export DIRSERV_PORT=1389 $ export LDAP_ADMIN_PWF=~/.pwd
ソフトウェアのインストールおよび環境変数の設定が完了したら、LDAPおよびLDAPSそれぞれのデフォルト・ポートを使用するDirectory Serverインスタンスを作成します。
$ dsadm create -p 1389 -P 1636 /local/dsInst Choose the Directory Manager password: Confirm the Directory Manager password: $ du -hs /local/dsInst 610K /local/dsInst
接尾辞が作成されるまでは、Directory Serverインスタンスでは1MB未満のディスク領域を使用しています。
$ dsadm start /local/dsInst 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/dsInst 53M /local/dsInst
この例では、明示的に示されているものを除き、Directory Serverのデフォルト構成に対する追加の変更は行いません。
makeldifコマンドとサンプル・ファイルを使用すると、サイズが1KBから1MBのサンプルLDIFファイルを作成できます。makeldifコマンドの使用方法を示す例は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサンプル・データのDirectory Serverインスタンスへのロードに関する説明を参照してください。
これらのファイル内のエントリは、実際のデプロイメントにおいて予期されるエントリより小さくなっています。
$ 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.7MBを使用する10k.ldifの内容をインポートして、サイズ設定を開始します。
$ dsadm stop /local/dsInst Server stopped $ dsadm import -i /local/dsInst /var/tmp/10k.ldif dc=example,dc=com …
デフォルトの索引作成では、10k.ldifの内容によって、インスタンス・ファイルのサイズが72MB - 53MB、つまり19MB増大します。
$ du -hs /local/dsInst
72M /local/dsInst
追加で5つの属性の索引を作成すると、約7MBサイズが増大します。
$ 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/dsInst 79M /local/dsInst
デフォルトのキャッシュ設定を使用し、接尾辞からエントリ・キャッシュにまだ何もロードされていない状態でメモリー・サイズを確認すると、サーバー・プロセスによっておよそ170MBのメモリーが使用され、ヒープ・サイズは約56MBです。
$ dsadm start /local/dsInst 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コマンドの出力を再度確認すると、ヒープが約10MB増加しており、プロセスの合計サイズも同様です。
$ 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/dsInst Server stopped $ dsadm start /local/dsInst 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/dsInst Server stopped $ dsadm import -i /local/dsInst /var/tmp/10k.ldif dc=example,dc=com … $ dsadm start /local/dsInst 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件のエントリによって、およそ55MB (110 - 55)のエントリ・キャッシュ・メモリーが使用されています。
エントリが100,000件になると、データベースおよびエントリ・キャッシュに収めるディレクトリ・データの量が増えます。まず、100,000件のエントリをインポートして、この量のディレクトリ・データに対して必要なディスク上のサイズを確認します。
$ dsadm import -i /local/dsInst /var/tmp/100k.ldif dc=example,dc=com … $ du -hs /local/dsInst 196M /local/dsInst
データベースに格納されている、このサンプル接尾辞dc=example,dc=comのディレクトリ・データによって、現時点で約142MBが使用されています。
$ du -hs /local/dsInst/db/example/
142M /local/dsInst/db/example
データベース・キャッシュのサイズを増やして、この内容を保持できます。ディレクトリ・データの量が時間の経過に伴って増大することが見込まれる場合、データベース・キャッシュを現在必要な量より大きく設定できます。エントリ・キャッシュ・サイズも必要な量より大きく設定できます。エントリ・キャッシュは、起動時に割り当てられるデータベース・キャッシュとは異なり、サーバーがクライアント・リクエストに応答するたびに増加します。
$ dsconf set-suffix-prop entry-cache-mode:manual $ dsconf set-server-prop db-cache-size:200M $ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G $ dsadm stop /local/dsInst Server stopped $ dsadm start /local/dsInst 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 -
これから、起動時のサーバー・インスタンスのヒープは比較的小さいが、データベース・キャッシュのメモリーは割当て済であることがわかります。プロセス・サイズはほぼ0.5GBです。
$ 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件の小規模なディレクトリ・エントリに対して約550MB増大し、そのLDIFによってディスク上の57MBが使用されています。
索引を5つ追加しても、プロセス・サイズはほぼ同じです。データベース・キャッシュ・サイズは変化していません。
$ dsconf create-index dc=example,dc=com employeeNumber street st \ postalCode description $ dsadm stop /local/dsInst Server stopped $ dsadm import -i /local/dsInst /var/tmp/100k.ldif dc=example,dc=com … $ dsadm start /local/dsInst 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 -
ただし、データベースは若干大きくなっています。追加の索引によって、データベースのサイズが142MBから163MBに増大しています。
$ du -hs /local/dsInst/db/example/
163M /local/dsInst/db/example
エントリが100,000件から1,000,000件になると、4GBの物理メモリーを持つシステム上には十分な領域を確保できず、エントリ・キャッシュにすべてのエントリを収めることはできなくなります。まず、データをインポートし、このデータによって使用されるディスク上のサイズを確認します。
$ dsadm import -i /local/dsInst /var/tmp/1M.ldif dc=example,dc=com … $ du -hs /local/dsInst/db/example/ 1.3G /local/dsInst/db/example
インスタンスの存続期間中にディレクトリ・データ・サイズがおよそ25%増大することが予期されると想定して、データベース・キャッシュ・サイズを1700MBに設定します。
$ dsadm start /local/dsInst Server started: pid=9060 $ dsconf set-server-prop db-cache-size:1700M $ dsadm stop /local/dsInst Server stopped $ dsadm start /local/dsInst 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 -
この大きさのデータベース・キャッシュと4GBのみの物理メモリーを使用する場合、接尾辞のエントリ・キャッシュには、エントリの一部分のみを収めることができます。ここで、エントリ・キャッシュ・サイズを1GBに設定し、キャッシュをプライミングして、プロセス・ヒープ・サイズの変化を確認します。
$ 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.8GBを超えています。
$ 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.5から6GBが使用されることが予期できます。
索引を5つ追加してディレクトリ・データベースのサイズを確認すると、索引の追加によってデータベースのサイズが約200MB増大したことがわかります。
$ dsconf create-index dc=example,dc=com employeeNumber street st \ postalCode description $ dsadm stop /local/dsInst Server stopped $ dsadm import -i /local/dsInst /var/tmp/1M.ldif dc=example,dc=com … $ du -hs /local/dsInst/db/example 1.5G /local/dsInst/db/example
表6-3に、この例での結果を記録します。これには、サーバー・プロセス・サイズおよびデフォルトのデータベース・キャッシュ・ファイル・サイズはいずれも含まれていません。
|
注意: 実際のデプロイメントにおける実験的なテストの結果は、通常、ここに示すものとは大きく異なります。 |
表6-3 サイズ設定サマリー
| エントリ数 | LDIFファイル・サイズ | デフォルト索引を持つディスク | 索引が5つ追加されたディスク | データベース・キャッシュ | エントリ・キャッシュ |
|---|---|---|---|---|---|
|
0脚注 1 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
|
10,000 |
8MB |
19MB |
26MB |
32MB |
55MB |
|
100,000 |
83MB |
142MB |
163MB |
200MB |
550MB |
|
1,000,000 |
800MB |
1300MB |
1500MB |
1700MB (デフォルトの索引作成) |
該当なし |
脚注 1 接尾辞は作成されていますが、空です。
実際のデプロイメントでは、エントリおよび索引の数が大幅に増加する可能性があります。ハードウェアを注文する前に、実験的なテストとチューニングを行ってください。
