ADDS パフォーマンス のチューニングにおけるハードウェアの考慮事項
重要
以下は、 Active Directory Domain Services のキャパシティ プランニングに関する記事で詳しく説明されている Active Directory ワークロードのために、サーバーハードウェアを最適化するための主な推奨事項と考慮事項の概要を示しています。 Active Directory Domain Services のキャパシティプランニングを検討して、これらの推奨事項に関する技術的な理解と影響を理解されることを強くお勧めします。
ディスクへの移動を避ける
Active Directory は、データベースと同じくらいの量のメモリをキャッシュできます。 メモリからのページのフェッチは、メディアがスピンドルベースか SSD ベースかにかかわらず、物理メディアに移動するよりもはるかに高速です。 ディスク I/O を最小限に抑えるために、メモリを追加します。
Active Directory ベスト プラクティスでは、DIT 全体をメモリに読み込むために十分な RAM を確保し、オペレーティング システムやその他のインストールされているアプリケーション (ウイルス対策、バックアップソフトウェア、監視など) に対応することをお勧めします。
レガシ プラットフォームの制限事項については、「Windows Server 2003 または Windows 2000 Server を実行しているドメイン コントローラーでの Lsass.exe プロセスによるメモリ使用量」を参照してください。
Memory/longterm の平均スタンバイ キャッシュ有効期間 > 30 分のパフォーマンス カウンターを使用します。
オペレーティング システム、ログ、およびデータベースを別のボリュームに配置します。 DIT のすべてまたは大部分がキャッシュされた場合、キャッシュが安定した状態になると、関連性が低くなり、ストレージ レイアウトの柔軟性が多少向上します。 DIT 全体がキャッシュされないシナリオでは、オペレーティング システム、ログ、およびデータベースを別のボリュームに分割することが重要になります。
通常、DIT に対する I/O 比は、読み取りが 約90% で書き込みが10% です。 書き込み I/O ボリュームが 10%-20% を大幅に超えるシナリオは、書き込みが多いと見なされます。 書き込みが多いシナリオでは、Active Directory キャッシュを活用することはできません。 ディレクトリに書き込まれるデータのトランザクションの持続性を保証するために、Active Directory ではディスク書き込みキャッシュは実行されません。 その代わりに、この操作を行わない明示的な要求がない限り、すべての書き込み操作がディスクにコミットされてから、操作の正常完了状態が返されます。 したがって、高速ディスク I/O は、Active Directory への書き込み操作のパフォーマンスにとって重要です。 これらのシナリオのパフォーマンスを向上させる可能性のあるハードウェアの推奨事項を次に示します:
ハードウェア RAID コントローラー
DIT およびログ ファイルをホストする低待機時間/高 RPM ディスクの数を増やします
コントローラーでの書き込みキャッシュ
ディスク サブシステムのパフォーマンスは、ボリュームごとに個別に確認してください。 ほとんどの Active Directory シナリオは主に読み取りに基づいているため、DIT をホストするボリュームの統計情報は検査するのが最も重要です。 ただし、オペレーティング システムやログ ファイルのドライブを含め、残りのドライブの監視を見落とさないようにしてください。 記憶域がパフォーマンスのボトルネックにならないようにドメイン コントローラーが適切に構成されているかどうかを判断するには、「ストレージ のサブシステム」の「標準ストレージの推奨事項」を参照してください。 多くの環境では、負荷の急激な増加や急増に対応できる十分なヘッドルームがあることを保証するという理念があります。 これらのしきい値は警告しきい値であり、負荷の急激な増加や急増に対応するヘッドルームが制限され、クライアントの応答性が低下します。 簡単に言うと、これらのしきい値を超えても、短期間 (5～15 分) では悪くなりません。ただし、これらの統計情報を使用して継続して実行されているシステムはデータベースを完全にキャッシュしておらず、過剰に調査する必要があります。
Database = = > Instances (lsass/ntdsa.dll) \ I/O データベース読み取りの平均待機時間 < 15 ミリ秒
Database ==> Instances(lsass/NTDSA)\I/O データベース読み取り/秒 < 10
Database ==> Instances(lsass/NTDSA)\I/O ログ書き込みの平均待機時間< 10 ミリ秒
Database ==> Instances(lsass/NTDSA)\I/O ログ書き込み/秒 – 参考情報。
データの一貫性を維持するには、すべての変更をログに書き込む必要があります。 ここでは、適切な番号も不適切な数値もありません。これは、ストレージがサポートしている量の尺度にすぎません。
非ピーク時の負荷期間に対して、バックアップやウイルス対策スキャンなど、非コアディスク I/O 負荷を計画します。 また、Windows Server 2008 で導入された低優先度の I/O 機能をサポートするバックアップとウイルス対策ソリューションを使用して、Active Directory の I/O ニーズに対する競合を軽減します。
プロセッサを消費しないようにする
十分な空きサイクルがないプロセッサは、実行のためにスレッドをプロセッサに取得するのに長い待機時間が発生する可能性があります。 多くの環境では、このようなシナリオでのクライアントの応答性への影響を最小限に抑えるために、負荷の急激な増加やスパイクに対応できる十分なヘッドルームがあることを保証することが理念となっています。 簡単に言うと、以下のしきい値を超えても、短期間 (5 ～15 分) では問題ありません。ただし、これらの統計を使用して継続的に実行されるシステムでは、異常な負荷に対応するためのヘッドルームは提供されず、過剰に消費されるシナリオに簡単に組み込むことができます。 しきい値を超えて一定期間使用されているシステムは、プロセッサの負荷を軽減する方法について調査する必要があります。
プロセッサを選択する方法の詳細については、「サーバー ハードウェアのパフォーマンス チューニング」を参照してください。
CPU 負荷を軽減するために、ハードウェアの追加、負荷の最適化、クライアントの他の場所への接続、または環境からの負荷の削除を行います。
プロセッサ情報 (_Total) \% Processor 使用率 < 60% パフォーマンス カウンタを使用してください。
ネットワーク アダプターの過負荷を回避する
プロセッサの場合と同様に、ネットワーク アダプターが過剰に使用されると、送信トラフィックがネットワークに到達するまでの待機時間が長くなります。 Active Directory は、小さな受信要求を行い、クライアント システムに返されるデータ量が比較的大きくなる傾向があります。 送信されたデータは、受信したデータを超えています。 多くの環境では、負荷の急激な増加や急増に対応できる十分なヘッドルームがあることを保証するという理念があります。 これらのしきい値は警告しきい値であり、負荷の急激な増加や急増に対応するヘッドルームが制限され、クライアントの応答性が低下します。 簡単に言うと、これらのしきい値を超えても、短期間 (5～15 分) では悪くなりません。ただし、これらの統計情報を使用して継続して実行されているシステムは過剰に消費されており調査する必要があります。
ネットワーク サブシステムを調整する方法の詳細については、「ネットワーク サブシステムのパフォーマンス チューニング」を参照してください。
Compare NetworkInterface (*) \ Bytes Sent/Sec with NetworkInterface (*) \ Current 帯域幅パフォーマンスカウンタを使用します。 比率は、使用率が 60% 未満である必要があります。