重要
以下は、「Active Directory Domain Services の容量計画」の記事でより詳しく説明されている、Active Directory ワークロード向けにサーバー ハードウェアを最適化するための主な推奨事項と考慮事項の概要です。 読者は、 Active Directory Domain Services の容量計画 を確認して、これらの推奨事項に対する技術的な理解と影響を大きくすることを強くお勧めします。
LDAP クエリを確認する
LDAP クエリが、効率的なクエリの作成に関する推奨事項に準拠していることを確認します。
MSDN には、Active Directory に対して使用するクエリを適切に記述、構造化、分析する方法に関する広範なドキュメントがあります。 詳細については、「 より効率的な Microsoft Active Directory-Enabled アプリケーションの作成」を参照してください。
LDAP ページ サイズの最適化
クライアント要求に応答して複数のオブジェクトを含む結果を返す場合、ドメイン コントローラーは結果セットをメモリに一時的に格納する必要があります。 ページ サイズを大きくすると、メモリ使用量が増え、不要に項目がキャッシュから除外される可能性があります。 この場合、既定の設定が最適です。 ページ サイズの設定を増やすために推奨事項が行われたシナリオがいくつかあります。 不十分と明確に識別されない限り、既定値を使用することをお勧めします。
クエリの結果が多い場合は、同時に実行される類似のクエリの制限が発生する可能性があります。 これは、LDAP サーバーが Cookie プールと呼ばれるグローバル メモリ領域を使い果たす可能性があるために発生します。 LDAP サーバー Cookie の処理方法に関するページで説明されているように、プールのサイズを増やす必要がある場合があります。
これらの設定を調整するには、 Windows Server 2008 以降のドメイン コントローラーが LDAP 応答で 5,000 個の値のみを返す方法に関するページを参照してください。
インデックスを追加するかどうかを決定する
インデックス属性は、フィルターで属性名を持つオブジェクトを検索する場合に便利です。 インデックスを作成すると、フィルターを評価するときにアクセスする必要があるオブジェクトの数を減らすことができます。 ただし、これにより、対応する属性が変更または追加されたときにインデックスを更新する必要があるため、書き込み操作のパフォーマンスが低下します。 また、ディレクトリ データベースのサイズも大きくなりますが、多くの場合、ストレージのコストを上回る利点があります。 ログ記録を使用して、コストの高い非効率的なクエリを見つけることができます。 特定されたら、検索のパフォーマンスを向上させるために、対応するクエリで使用される属性のインデックスを作成することを検討してください。 Active Directory 検索のしくみの詳細については、「 Active Directory 検索のしくみ」を参照してください。
インデックスの追加に役立つシナリオ
データ要求時のクライアント負荷によって CPU 使用率が大幅に増加しており、クライアント クエリの動作を変更または最適化することはできません。
インデックスのない属性が原因で、クライアントの読み込みによってサーバーで大量のディスク I/O が生成され、クライアント クエリの動作を変更または最適化することはできません。
クエリには長い時間がかかり、インデックスをカバーしていないため、クライアントが許容できる時間枠で完了していません。
継続時間の長い大量のクエリが ATQ LDAP スレッドの消費と枯渇を引き起こしています。 次のパフォーマンス カウンターを監視します。
NTDS\Request Latency – これは、要求の処理にかかる時間に依存します。 Active Directory は 120 秒後に要求をタイムアウトします (既定)、大部分ははるかに高速に実行する必要があり、実行時間が非常に長いクエリは全体的な数値で非表示になります。 絶対しきい値ではなく、このベースラインの変更を探します。
注
ここでの値が高い場合は、他のドメインや CRL チェックへの "プロキシ" 要求の遅延を示す指標にもなることができます。
NTDS\Estimated Queue Delay – 最適なパフォーマンスを得るために、これは理想的には 0 に近い必要があります。これは、要求が処理されるのを待つ時間を費やさないことを意味するためです。
これらのシナリオは、次の 1 つ以上の方法を使用して検出できます。
パフォーマンス モニターの Active Directory 診断データ コレクター セット (SPA の子孫: Win2008 以降の AD データ コレクター セット)
"(objectClass=*)"以外のフィルターを使用する検索は、先祖インデックスを利用します。"
インデックスに関するその他の考慮事項
クエリのチューニングがオプションとして使い果たされた後、インデックスの作成が問題の適切な解決策であることを確認します。 ハードウェアの適切なサイズ設定は非常に重要です。 インデックスは、適切な修正が属性にインデックスを付ける場合にのみ追加する必要があり、ハードウェアの問題を難読化する試みではありません。
インデックスを使用すると、インデックスが作成される属性の合計サイズの最小値でデータベースのサイズが大きくなります。 そのため、属性内のデータの平均サイズを取得し、属性が設定されるオブジェクトの数を乗算することで、データベースの増加の見積もりを評価できます。 通常、これはデータベース サイズが約 1% 増加します。 詳細については、「 データ ストアのしくみ」を参照してください。
検索動作が主に組織単位レベルで行われる場合は、コンテナー化された検索のインデックス作成を検討してください。
タプル インデックスは通常のインデックスよりも大きくなりますが、サイズの見積もりははるかに困難です。 通常のインデックス サイズの見積もりを成長の下限として使用し、最大値は 20%とします。 詳細については、「 データ ストアのしくみ」を参照してください。
検索動作が主に組織単位レベルで行われる場合は、コンテナー化された検索のインデックス作成を検討してください。
タプル インデックスは、メディア検索文字列と最終的な検索文字列をサポートするために必要です。 タプル インデックスは、最初の検索文字列には必要ありません。
初期検索文字列 – (samAccountName=MYPC*)
中間検索文字列 - (samAccountName=*MYPC*)
最終検索文字列 – (samAccountName=*MYPC$)
インデックスを作成すると、インデックスの作成中にディスク I/O が生成されます。 これは、優先度が低いバックグラウンド スレッドで行われ、受信要求はインデックス ビルドよりも優先されます。 環境の容量計画が正しく行われている場合は、透過的にする必要があります。 ただし、書き込み負荷の高いシナリオや、ドメイン コントローラー ストレージの負荷が不明な環境では、クライアント エクスペリエンスが低下する可能性があり、時間外に実行する必要があります。
インデックスの作成はローカルで行われるため、レプリケーション トラフィックへの影響は最小限です。
詳細については、次を参照してください。
インデックス付き属性 の