重要
以下は、「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 をホストしているボリュームの統計情報を調べることが最も重要です。 ただし、オペレーティング システムやログ ファイル ドライブなど、残りのドライブの監視を見落とさないでください。 ストレージがパフォーマンスのボトルネックにならないようにドメイン コントローラーが適切に構成されているかどうかを確認するには、記憶域サブシステムに関する標準ストレージの推奨事項に関するセクションを参照してください。 多くの環境では、負荷の急激な増加や急増に対応できる十分なヘッドルームがあることを保証するという理念があります。 これらのしきい値は警告しきい値であり、負荷の急激な増加や急増に対応するヘッドルームが制限され、クライアントの応答性が低下します。 要するに、これらのしきい値を短時間（1日数回、5〜15分）だけ超えるのは悪くありませんが、これらの統計を持続的に出し続けるシステムは、データベースを完全にキャッシュしていない可能性があり、過負荷になっているかもしれませんので、調査が必要です。
Database ==> Instances(lsass/NTDSA)\I/O データベース読み取り平均待機時間 < 15 ミリ秒
Database ==> Instances(lsass/NTDSA)\I/O データベース読み取り/秒 < 10
Database ==> インスタンス(lsass/NTDSA)\I/O ログ書き込み平均レイテンシー < 10 ミリ秒
データベース ==> インスタンス（lsass/NTDSA）\I/Oログ書き込み/秒 – 情報のみ。
データの一貫性を維持するには、すべての変更をログに書き込む必要があります。 ここには良い数値も悪い数値もありません。ストレージがサポートしている量の尺度にすぎません。
非ピーク読み込み期間に対して、バックアップやウイルス対策スキャンなどの非コア ディスク I/O 負荷を計画します。 また、Windows Server 2008 で導入された優先順位の低い I/O 機能をサポートするバックアップおよびウイルス対策ソリューションを使用して、Active Directory の I/O ニーズとの競合を減らします。
プロセッサに税金をかけない
十分な空きサイクルがないプロセッサでは、実行のためにプロセッサにスレッドを取得する際に長い待機時間が発生する可能性があります。 多くの環境で、これらのシナリオでのクライアントの応答性への影響を最小限に抑えるために、負荷の急増や急増に対応できる十分なヘッド スペースを確保することが理念です。 要するに、以下のしきい値を超えることは、1日に数回、5〜15分程度であれば短期的には問題ありません。しかし、このような統計で持続的に稼働しているシステムは、異常な負荷に対応するための余地がなく、容易に過負荷の状態に陥る可能性があります。 しきい値を超える持続期間を費やすシステムは、プロセッサの負荷を軽減する方法について調査する必要があります。
プロセッサを選択する方法の詳細については、「 サーバー ハードウェアのパフォーマンス チューニング」を参照してください。
ハードウェアの追加、負荷の最適化、クライアントの他の場所へのダイレクト、または環境からの負荷の削除を行って、CPU 負荷を軽減します。
プロセッサ情報(_Total)\% プロセッサ使用率 < 60% パフォーマンスカウンターを使用します。
ネットワーク アダプターのオーバーロードを回避する
プロセッサと同様に、過剰なネットワーク アダプター使用率により、送信トラフィックがネットワークに到達するまでの待機時間が長くなります。 Active Directory では、受信要求が少なく、クライアント システムに返されるデータの量が比較的かなり大きくなる傾向があります。 送信されたデータは、受信したデータをはるかに超えています。 多くの環境では、負荷の急激な増加や急増に対応できる十分なヘッドルームがあることを保証するという理念があります。 このしきい値は警告しきい値であり、負荷の急激な増加や急増に対応するヘッドルームが制限され、クライアントの応答性が低下します。 要するに、これらの閾値を超えるのは短期的には悪くはありませんが（1日に数回の、5～15分程度）、このような統計値で持続的に動作しているシステムは過負荷状態であり、調査の必要があります。
ネットワーク サブシステムを調整する方法の詳細については、「ネットワーク サブシステム のパフォーマンス チューニング」を参照してください。
Compare NetworkInterface (*) \ Bytes Sent/Sec with NetworkInterface (*) \ Current 帯域幅パフォーマンス カウンターを使用します。 比率は、使用率が 60% 未満である必要があります。