Active Directory Domain Services のキャパシティ プランニング

この記事では、Active Directory Domain Services (AD DS) のキャパシティ プランニングに関するレコメンデーションを示します。

キャパシティ プランニングの目標

キャパシティ プランニングは、パフォーマンス インシデントのトラブルシューティングと同じではありません。 キャパシティ プランニングの目標は次のとおりです。

• 環境を適切に実装して運用する。
• パフォーマンスの問題のトラブルシューティングに費やす時間を最小限に抑える。

組織のキャパシティ プランニングでは、クライアントのパフォーマンス要件を満たし、データセンターのハードウェアをアップグレードするための十分な時間を確保することを目的として、たとえばピーク時のプロセッサ使用率を 40% というベースライン目標に設定することができます。 一方、パフォーマンスの問題に対する監視アラートのしきい値を 5 分間隔で 90% に設定することもできます。

キャパシティ管理のしきい値を継続的に超えている場合は、プロセッサの数を増やすか高速なプロセッサを追加してキャパシティを引き上げること、あるいは複数のサーバーにわたってサービスを拡張することが解決策になります。 パフォーマンス アラートのしきい値を設定すると、パフォーマンスの問題がクライアントのエクスペリエンスにマイナスの影響を及ぼす場合に、直ちに対処する必要があれば通知を受けることができます。 これに対し、トラブルシューティング ソリューションでは、1 回限りのイベントに対処することに重点を置きます。

容量管理はプロアクティブです。環境を設計、サイズ変更、監視することで、使用率の傾向が定義されたしきい値内に留まり、スケーリング アクションがユーザーに影響を与える前に発生する可能性があります。 パフォーマンスのトラブルシューティングはリアクティブです。ユーザー操作が既に低下している深刻な状態を解決します。

スケールアップ システムの容量計画は、ハードウェアとサービスが予想する負荷を処理できることを確認することです。 どちらの場合も、適切なユーザー エクスペリエンスを提供しながら、システムが予想される負荷を処理できるようにすることが目標です。 次のアーキテクチャの選択肢は、その目標を達成するのに役立ちます。

• 仮想化
• ソリッド ステート ドライブ (SSD) や NVMe (不揮発性メモリ エクスプレス) などの高速ストレージ
• クラウド シナリオ

Active Directory Domain Services (AD DS) は、多くの Microsoft およびサード パーティ製品がバックエンドとして使用する成熟した分散サービスです。 これは、他のアプリケーションに必要な容量を確保するための最も重要なコンポーネントの 1 つです。

プランニングを開始する前に考慮を要する重要な情報

この記事を最大限に活用するには、次のことを行う必要があります。

• Windows Server のパフォーマンス チューニング ガイドラインを読んで理解していることを確認します。
• Windows Server プラットフォームは x64 ベースのアーキテクチャであり、x86 システムと比較してメモリ アドレス空間が大きくなります。 この記事のガイドラインは、Windows Server のバージョンに関係なく、Active Directory 環境に適用されます。 現在のリリースでは、拡張された x64 メモリ機能により、より大きなデータベースをメモリにキャッシュできますが、容量計画の原則は変わりません。 このガイドラインは、使用している環境に、使用可能なシステム メモリに完全に収まるディレクトリ情報ツリー (DIT) がある場合にも適用されます。
• キャパシティ プランニングは継続的なプロセスである点を理解し、構築した環境がどの程度要望に対応しているかを定期的に確認すること。
• 最適化は、ハードウェア コストの変化に伴い、複数のハードウェア ライフサイクルで行われるという点を理解すること。 たとえば、メモリが安くなると、コアあたりのコストが減少したり、さまざまなストレージ オプションの価格が変化することがあります。
• 毎日のピーク繁忙期を計画します。 30 分または 1 時間の間隔に基づいて計画を立てることをお勧めします。 間隔を選択するときは、次の情報を考慮してください。
  • サービスが実際にピーク容量に達すると、1 時間を超える間隔が非表示になる場合があります。
  • 30 分未満の間隔では、一時的な増加が実際よりも重要に見える場合があります。
• 企業のハードウェア ライフサイクル全体にわたる成長を計画します。 この成長計画には、さまざまな方法でハードウェアをアップグレードまたは追加するための戦略や、3 年から 5 年ごとに完全な更新を行う戦略を含めることができます。 各拡張計画では、Active Directory の負荷がどれだけ大きくなるかを見積もる必要があります。 より正確な評価を行うには、履歴データが役立つことがあります。
• フォールト トレランスは、一部のコンポーネントで障害が発生したときにシステムが正常に動作し続ける機能です。 必要な容量 ( n) を決定したら、フォールト トレランスを計画する必要があります。 n + 1、n + 2、または n + x シナリオを検討してください。 たとえば、2 つのドメイン コントローラー (DC) が必要な場合は、1 つの DC 障害を処理できるように 3 つ計画します。

  • 1 台以上のサーバーが失われてもシステムが推定の最大ピーク キャパシティを超えないように、成長計画に基づき、組織のニーズに応じてサーバーを追加します。

  • 成長とフォールト トレランスの計画を必ず統合してください。 たとえば、1 つのドメイン コントローラー (DC) が今日の負荷を処理します。 予測では、1 年以内に負荷が 2 倍になり、需要を満たすために 2 つの DC が必要になります。 フォールト トレランスのための予備容量が残っていません。 このキャパシティ不足を防ぐには、3 台の DC から始めることを計画する必要があります。 予算で 3 台の DC が許可されない場合は、2 台の DC から始めて、3 か月または 6 か月後に 3 台目の DC を追加する計画を立てることもできます。

    注

    Active Directory 対応アプリケーションを追加すると、DC の負荷に大きな影響を与える可能性があります。その負荷がアプリケーション サーバーまたはクライアントから発生したかどうかには関係ありません。

3 部構成のキャパシティ プランニング サイクル

プランニング サイクルを開始する前に、組織に必要なサービスの品質を決定する必要があります。 この記事のすべてのレコメンデーションとガイダンスは、最適なパフォーマンス環境を目的としています。 ただし、最適化の必要がない場合は、部分的に緩和することもできます。 たとえば、組織で高いレベルのコンカレンシーと一貫性のあるユーザー エクスペリエンスが必要な場合は、データセンターのセットアップを検討する必要があります。 データセンターを使用すると、冗長性に注意を払い、システムとインフラストラクチャのボトルネックを最小限に抑えることができます。 一方、ユーザー数が少ないサテライト オフィスへの展開を計画している場合は、ハードウェアとインフラストラクチャの最適化についてそれほど心配する必要がないため、低コストのオプションを選択できます。

次に、仮想マシンと物理マシンのどちらを使用するかを決定する必要があります。 キャパシティ プランニングの観点からは、どちらが正解ということはありません。 ただし、シナリオによって扱う可変要素が異なることに留意する必要があります。

仮想化のシナリオには、次の 2 つのオプションがあります。

• ホストとゲストが 1 対 1 である直接マッピング。
• ホストごとに複数のゲストが存在する共有ホスト シナリオ。

直接マッピング シナリオは、物理ホストの場合と同じように扱うことができます。 共有ホスト シナリオを選択した場合は、この後のセクションで説明する、他の可変要素についても考慮する必要があります。 また、共有ホストは Active Directory Domain Services (AD DS) を使用してリソースを競合させ、システムのパフォーマンスとユーザー エクスペリエンスに影響を与える可能性があります。

これらの以前の計画の質問に答えたら、容量計画サイクル自体を見てみましょう。 キャパシティ プランニングの各サイクルは、次の 3 つのプロセスで構成されます。

1. 既存の環境を測定し、システムのボトルネックが現在発生している場所を特定して、展開に必要なキャパシティを計画するために必要となる環境の基本情報を取得する。
2. キャパシティの要件に基づいて、必要なハードウェアを決定する。
3. セットアップしたインフラストラクチャが仕様の範囲内で動作しているかどうかを監視および検証する。 このステップで収集するデータは、キャパシティ プランニングの次のサイクルでのベースラインになります。

プロセスを適用する

パフォーマンスを最適化するには、以下の主要なコンポーネントが正しく選択され、アプリケーションの負荷に合わせて調整されていることを確認します。

• メモリ
• ネットワーク
• Storage
• プロセッサ
• Netlogon

AD DS の基本的なストレージ要件と互換性のあるクライアント ソフトウェアの一般的な動作は、最新のサーバー クラス ハードウェアが、10,000 ~ 20,000 ユーザーの環境の容量計画のニーズを簡単に満たすことを意味します。 容量計画はすべての展開で引き続き重要ですが、最新のサーバー システムでは、特殊な最適化を必要とせずにこれらの負荷を処理できるため、小規模な環境では一般に、ハードウェアの選択の柔軟性が向上します。

データ コレクションの概要テーブルの表では、既存の環境を評価して適切なハードウェアを選択する方法について説明します。 その後のセクションでは、AD DS 管理者がインフラストラクチャを評価するために役立つ、ハードウェアに関するベースラインのレコメンデーションと環境固有の原則について詳しく説明しています。

その他、プランニング時には次のような情報も念頭に置く必要があります。

• 現在のデータに基づくサイズ設定が正しいのは、現在の環境に対してのみです。
• 見積もりを行う際には、ハードウェア ライフサイクルの推移と共に需要が増加することも考慮します。
• 将来的な成長に対応するために、今すぐ環境を大きめに拡張するか、ライフサイクルの推移に伴い徐々にキャパシティを追加するかを決定します。
• 物理的な展開に適用するキャパシティ プランニングの原則と方法論はすべて、仮想化を取り入れた展開にも適用されます。 ただし、仮想化環境を計画する場合は、ドメイン関連の計画や見積もりに仮想化のオーバーヘッドを追加することを忘れないようにする必要があります。
• キャパシティ プランニングは予測であり、完全に正しい値ではないため、完全に正確であるとは考えないでください。 必要に応じてキャパシティを常に調整し、意図したとおりに環境が動作しているかどうかについても繰り返し検証するようにしてください。

データ コレクションの概要テーブル

次の表は、ハードウェアの見積もりを決定するための条件を示しています。

基本環境

高レベルの評価基準

計画

長い間、AD DS のサイズ設定の一般的な推奨事項は、データベース サイズと同じ量の RAM を配置することです。 コンピューティング能力の向上と x86 アーキテクチャから x64 への切り替えにより、物理マシンでホストされている AD DS のパフォーマンスの重要性が低くなるため、サイズ設定の微妙な側面が増えましたが、仮想化ではパフォーマンス チューニングの重要性が強調されました。

これらの懸念に対処するために、以下の各セクションでは、サービスとしての Active Directory の需要を決定して計画する方法について説明します。 これらのガイドラインは、環境が物理環境、仮想化環境、混在環境のいずれであっても、任意の環境に適用できます。 パフォーマンスを最大化するには、AD DS 環境が可能な限りプロセッサ バウンドになることを目標にする必要があります。

RAM

RAM にキャッシュできるストレージ容量が大きくなるほど、ディスクにアクセスする必要が少なくなります。

サーバーのスケーラビリティを最大化するには、次のコンポーネントを合計して最小 RAM 要件を計算します。

• 現在のデータベース サイズ
• オペレーティング システムに推奨される量
• エージェントに対するベンダーの推奨事項。次に例を示します。
  • ウイルス対策プログラム
  • 監視ソフトウェア
  • バックアップ アプリケーション

また、サーバーの有効期間の将来的な拡大に対応するために、追加の RAM も含める必要があります。 この見積もりは、データベースの増加と環境の変化に基づいて変化します。

RAM の最大化がコスト効率や実現性に優れない環境については、「 ストレージ 」セクションを参照してストレージを適切に構成してください。 これらのシナリオは、次のとおりです。

• 予算の制約があるサテライトの場所
• ディレクトリ情報ツリー (DIT) が大きすぎてメモリに収まらないデプロイ

メモリのサイズを変更する際に考慮すべきもう 1 つの重要な点は、ページ ファイルのサイズ設定です。 ディスクのサイズ設定では、メモリに関連するその他のすべての作業と同様、ディスクの使用量を最小限に抑えることが目標です。 特に、ページングを最小限に抑えるには、どれくらいの RAM が必要になるでしょうか。 次のいくつかのセクションでは、この点を明らかにするために必要な情報を確認します。 AD DS のパフォーマンスに必ずしも影響しないページ サイズに関するその他の考慮事項としては、オペレーティング システム (OS) のレコメンデーションと、メモリ ダンプ用のシステムの構成があります。

ドメイン コントローラー (DC) に必要な RAM 容量を判断することは、多くの複雑な要因により容易でない場合があります。

• ローカル セキュリティ機関サブシステム サービス (LSASS) はメモリ負荷の下で RAM をトリミングし、人為的に要件を縮小するため、既存のシステムは常に RAM 要件の信頼できるインジケーターではありません。
• 個々の DC は、クライアントが必要とするデータのみをキャッシュする必要があります。 つまり、さまざまな環境でキャッシュされるデータは、含まれているクライアントの種類によって変わります。 たとえば、Exchange Server を使用する環境の DC は、ユーザーのみを認証する DC とは異なるデータを収集します。
• ケースバイケースで各 DC の RAM を評価するために必要な労力は、多くの場合、過剰であり、環境の変化に応じて変化します。

レコメンデーションの背後にある基準は、より多くの情報に基づいた意思決定を行うために役立ちます。

• RAM にキャッシュする容量が大きくなるほど、ディスクにアクセスする必要が少なくなります。
• ストレージは、コンピューターで最も低速なコンポーネントです。 スピンドル ベースおよび SSD ストレージ メディアでのデータ アクセスは、RAM のデータ アクセスよりも 100 万倍遅くなります。

RAM の仮想化に関する考慮事項

RAM を最適化するための目標は、ディスクへの移動に費やされる時間を最小限にすることです。 ホストでメモリの過剰コミットを避けます (物理マシンよりも多くの RAM をゲストに割り当てる)。 過剰コミットだけでは問題ありませんが、ゲストの合計使用量がホスト RAM を超える場合は、ホスト ページが表示されます。 ページングは、DC が NTDS.dit またはページ ファイルに移動するとき、またはホスト が RAM をページするときに、パフォーマンス ディスク バインドを行います。 この動作により、パフォーマンスとユーザー エクスペリエンスが大幅に低下します。

計算の概要の例

推奨: 16 GB

経時的には、データベースにデータが追加されていき、サーバーの平均寿命は約 3 ～ 5 年になります。 33%の増加予測に基づいて、18 GB は物理サーバーに配置する RAM の妥当な量です。

ネットワーク

このセクションでは、クライアント クエリ、グループ ポリシー設定などを含め、展開に必要な合計帯域幅とネットワーク キャパシティの評価について説明します。 見積もりを行うためのデータは、パフォーマンス カウンター Network Interface(*)\Bytes Received/sec および Network Interface(*)\Bytes Sent/sec を使用して収集できます。 ネットワーク インターフェイス カウンターのサンプル間隔は、15 分、30 分、または 60 分に設定する必要があります。 少ないものは、良好な測定には揮発性が高すぎ、より大きなものは毎日のピークを過度に滑らかにします。

帯域幅のニーズ

ネットワークのスケーラビリティの計画には、トラフィックの量と、ネットワーク トラフィックからの CPU 負荷という 2 つの異なるカテゴリがあります。

トラフィック サポート用にキャパシティ プランニングを行う際には、考慮を要する点が 2 つあります。 1 つ目は、DC 間での Active Directory レプリケーション トラフィックの量を把握する必要があるという点です。 2 つ目は、サイト内のクライアントからサーバーへのトラフィックを評価する必要があるという点です。 サイト内トラフィックでは主に、クライアントに返送される大量のデータに比べると、クライアントから受信する要求の量は少なくなります。 通常、サーバーあたり最大 5,000 人のユーザーを持つ環境では、100 MB で十分です。 5,000 人を超えるユーザーの環境では、代わりに 1 GB のネットワーク アダプターと Receive Side Scaling (RSS) のサポートを使用することをお勧めします。

サイト内トラフィックのキャパシティを評価するには、特にサーバー統合シナリオの場合、サイト内のすべての DC の Network Interface(*)\Bytes/sec パフォーマンス カウンターを確認し、それらを合計して、その合計を DC のターゲット数で割る必要があります。 この数値を計算する簡単な方法は、Windows 信頼性およびパフォーマンス モニターを開き、積み上げ面グラフ ビューを確認することです。 すべてのカウンターの尺度が同じであることを確認してください。

この一般的な規則が特定の環境に適用されるかどうかを検証するために、より複雑な方法の例を見てみましょう。 この例では、次のことを前提としています。

• 目標は、サーバーの設置面積をできる限り削減することです。 理想的には、1 つのサーバーが負荷を受け取り、次に冗長性のために別のサーバーをデプロイします (n + 1 シナリオ)。
• このシナリオでは、現在のネットワーク アダプターは 100 MB のみをサポートし、切り替え環境にあります。
• n シナリオ (1 台の DC がない場合) では、ターゲット ネットワーク帯域幅の最大使用率は 60% です。
• 各サーバーには、約 10,000 のクライアントが接続されています。

次に、このシナリオ例の Network Interface(*)\Bytes Sent/sec カウンターのグラフを見てみましょう。

1. 営業日は AM 5 時 30 分頃に始まり、PM 7 時頃に終わります。
2. 最も負荷の高いピーク時間帯は AM 8 時から AM 8 時 15 分までで、最も負荷の高い DC では 1 秒あたり 25 バイトを超えるデータが送信されます。

   注

   すべてのパフォーマンス データは履歴データであり、AM 8:15 のピーク データ ポイントは AM 8 時から AM 8 時 15 分までの負荷を示します。

3. AM 4 時前にスパイクが発生し、最も負荷の高い DC で 1 秒あたり 20 バイト以上が送信されます。これは、異なるタイム ゾーンからの負荷や、バックアップなどバックグラウンド インフラストラクチャのアクティビティを示している可能性があります。 AM 8 時のピークはこのアクティビティを超えているため、関連性はありません。
4. サイト内には 5 台の DC があります。
5. 最大負荷は DC あたり約 5.5 MBps で、100 MB 接続の 44% を表します。 このデータを使用して、午前 8 時から午前 8 時 15 分までの間に必要な帯域幅の合計が 28MBps であると推定できます。

   注

   ネットワーク インターフェイスの送受信カウンターはバイト単位ですが、ネットワーク帯域幅はビット単位で測定されます。 したがって、合計帯域幅を計算するには、100 MB ÷ 8 = 12.5 MB、1 GB ÷ 8 = 128 MB を実行する必要があります。

データを確認した後、ネットワーク使用率の例からどのような結論が得られますか?

• 現在の環境は、60% の目標使用率で n + 1 レベルのフォールト トレランスを満たしています。 1 つのシステムをオフラインにして、サーバーあたりの帯域幅を約 5.5MBps (44%) から約 7MBps (56%) にシフトします。
• 1 台のサーバーに統合するという前述の目標に基づいて、この統合の変更は、100 MB の接続の最大目標使用率と使用可能な使用率を超えています。
• 1 GB の接続では、このサーバーごとの帯域幅の値は、合計容量の 22% を表します。
• n + 1 シナリオの通常の動作条件下では、クライアントの負荷は、サーバーあたり約 14MBps または合計容量の 11% で比較的分散されます。
• DC が使用できない間に十分な容量があることを確認するために、サーバーあたりの通常の動作ターゲットは、ネットワーク使用率が約 30%、サーバーあたり 38MBps になります。 フェールオーバー ターゲットは、ネットワーク使用率が 60%、サーバーあたり 72MBps になります。

最終的なシステム展開には、1 GB のネットワーク アダプターと、必要な負荷をサポートできるネットワーク インフラストラクチャへの接続が必要です。 ネットワーク トラフィックの量が原因で、ネットワーク通信からの CPU 負荷によって AD DS の最大スケーラビリティが制限される可能性があります。 これと同じプロセスを使用して、DC への受信通信を見積もることができます。 ただし、ほとんどのシナリオでは、送信トラフィックよりも小さいため、受信トラフィックを計算する必要はありません。

サーバーあたり 5,000 ユーザー数を超える環境では、ハードウェアで RSS がサポートされていることを確認することが重要です。 ネットワーク トラフィックが多いシナリオでは、割り込み負荷の分散がボトルネックになる可能性があります。 潜在的なボトルネックを検出するには、 Processor(*)\% Interrupt Time カウンターを調べることで、割り込み時間が CPU 間で不均一に分散されているかどうかを確認します。 RSS 対応のネットワーク インターフェイス コントローラー (NIC) を使用すると、これらの制限を軽減し、スケーラビリティを向上させることができます。

ネットワーク帯域幅に関する仮想化に関する考慮事項

物理サーバーの一般的な推奨事項は、5,000 人以上のユーザーをサポートするサーバー用の 1 GB アダプターです。 複数のゲストが基になる仮想スイッチ インフラストラクチャの共有を開始したら、ホストにすべてのゲストをサポートするための十分な集計ネットワーク帯域幅があることを確認します。 両方のシナリオで帯域幅を考慮します。DC が仮想スイッチ経由のネットワーク トラフィックを持つホスト上で VM として実行される場合と、物理スイッチに直接接続する場合です。 仮想スイッチでは、慎重な帯域幅計画が必要です。 アップリンクは、それを通過する集計データをサポートする必要があります。 スイッチにリンクされている物理ホスト ネットワーク アダプターは、DC 負荷と、仮想スイッチを共有し、物理アダプター経由で接続する他のすべてのゲストをサポートする必要があります。

ネットワーク計算の概要例

次の表は、ネットワーク キャパシティの計算に使用できるシナリオ例の値を示します。

この表に基づいて、推奨帯域幅は 72MBps (28.5MBps ÷ 40%) になります。

ここでも、クライアントの負荷は時間の経過とともに増加すると想定する必要があるため、この増加に対してできるだけ早い段階で計画を立てる必要があります。 少なくとも 50% のネットワーク トラフィックの増加を見込んで計画を立てることをお勧めします。

Storage

ストレージのキャパシティ プランニングでは、次の 2 つの点を考慮する必要があります。

• 容量 (ストレージのサイズ)
• パフォーマンス

容量は重要ですが、パフォーマンスを無視しないことが重要です。 現在のハードウェア コストを考えると、ほとんどの環境では、どちらの要素も大きな懸念材料になるほど深刻ではありません。 このため、通常はデータベース サイズと同じ量の RAM を配置することが推奨されます。 ただし、大規模な環境のサテライト拠点では、このレコメンデーションが過剰である可能性もあります。

サイズ設定

ストレージの評価

4 GB と 9 GB のドライブが最も一般的なドライブ サイズだったときに Active Directory が最初に到着したときと比較して、Active Directory のサイズ設定は、最大の環境以外のすべてに対しても考慮されていません。 180GBの範囲で利用可能な最小のハードドライブサイズで、オペレーティングシステム、 SYSVOL、 NTDS.dit 全体が1つのドライブに簡単に収まります。 そのため、ストレージのサイズ設定に多額の投資を行わないようにすることをお勧めします。

ストレージをデフラグできるように、NTDS.dit サイズの 110% が使用可能であることをお勧めします。

この推奨事項を超えて、将来の成長に対応するための通常の考慮事項を考慮する必要があります。

ストレージを評価する場合は、まず、 NTDS.dit と SYSVOL が必要なサイズを評価する必要があります。 これらの測定値は、固定ディスクと RAM 割り当ての両方のサイズを設定するのに役立ちます。 これらのコンポーネントのコストが比較的低いため、計算を行う際にそれほど正確である必要はありません。 ストレージ評価の詳細については、「ストレージの制限」および「Active Directory ユーザーと組織単位の増加予測」を参照してください。

複数のドメインを持つ既存の環境を確認すると、データベース サイズのバリエーションに気付く場合があります。 このようなバリエーションを見つけた場合は、グローバル カタログ (GC) と非 GC の最小サイズを使用します。

データベースのサイズは、OS のバージョンによって異なる場合があります。 以前のバージョンの OS を実行している DC のデータベース サイズは、新しいバージョンを実行する DC よりも小さくなります。 DC で Active Directory REcycle Bin や Credential Roaming などの機能が有効になっている場合は、データベース サイズにも影響する可能性があります。

ストレージの仮想化に関する考慮事項

複数の仮想ハード ディスク (VHD) ファイルを 1 つのボリュームに割り当てるシナリオでは、固定状態ディスクを使用する必要があります。 ディスクは、DIT のサイズの少なくとも 210％である必要があります。これにより、必要に応じて十分な領域が確保されます。 この固定 VHD サイズには、100% の DIT サイズと 110% の空き領域が含まれます。

ストレージ計算の概要例

次の表に、架空のストレージ シナリオの領域要件を見積もるために使用する値を示します。

また、ストレージの見積もりには、データベース以外のストレージ コンポーネントも含める必要があります。 これらのコンポーネントには、次のものが含まれます。

• SYSVOL
• オペレーティング システム ファイル
• ページ ファイル
• 一時ファイル
• インストーラー ファイルなどのローカル キャッシュ データ
• アプリケーション

Storage performance (ストレージのパフォーマンス)

ストレージはどのコンピューターでも最も低速なコンポーネントであるため、クライアント エクスペリエンスに最も大きい悪影響を及ぼす可能性があります。 大規模な環境で、この記事に記載されている RAM サイズ設定に関するレコメンデーションを適用できない場合、ストレージのキャパシティ プランニングを軽視した結果、システム パフォーマンスに壊滅的な影響が及ぶ可能性があります。 利用可能なストレージ テクノロジの複雑さと多様性によってリスクがさらに増大します。OS、ログ、データベースを別々の物理ディスクに配置するという一般的なレコメンデーションは、すべてのシナリオに普遍的に当てはまるわけではないためです。

ディスクに関する以前のレコメンデーションでは、ディスクは I/O の分離を可能にする専用のスピンドルであることが前提になっていました。 この専用スピンドルの想定は、次のストレージの種類が導入されたため、当てはまりません。

• RAID
• 新しいストレージの種類と仮想化および共有ストレージのシナリオ
• 記憶域ネットワーク (SAN) 上の共有スピンドル
• SAN またはネットワークに接続されたストレージ上の VHD ファイル
• ソリッド ステート ドライブ (SSDs)
• 不揮発性メモリ エクスプレス (NVMe) ドライブ
• 階層型ストレージ アーキテクチャ (SSD ストレージ階層キャッシング、より大きなスピンドルベースのストレージなど)

バックエンド ストレージに配置されたその他のワークロードでは、RAID、SAN、NAS、JBOD、記憶域スペース、VHD などの共有記憶域がオーバーロードされる可能性があります。 このような種類のストレージ デバイスでは、追加の考慮事項が発生する可能性があります。 たとえば、物理ディスクと AD アプリケーションの間の SAN、ネットワーク、またはドライバーの問題により、調整や遅延が発生する可能性があります。 明確にするために、これらの種類のストレージ アーキテクチャは悪い選択ではありませんが、より複雑です。つまり、すべてのコンポーネントが意図したとおりに動作していることを確認するために特別な注意を払う必要があります。 詳細な説明については、この記事の付録 C および付録 D を参照してください。

このソリッドステート ストレージ テクノロジ (NVMe と SSD) には、従来のハード ドライブと同じ機械的制限はありません。 ただし、引き続き I/O の制限があります。 これらの制限を超えると、システムが過負荷になる可能性があります。

ストレージ パフォーマンス計画の目的は、必要な数の I/O が常に使用可能であり、許容される期間内に発生することを確認することです。 ローカルに接続されたストレージを使用するシナリオの詳細については、 付録 C を参照してください。付録の原則は、より複雑なストレージ シナリオや、バックエンド ストレージ ソリューションをサポートするベンダーとの会話に適用できます。

現在利用可能なストレージ オプションが多数あるため、AD DS 展開のニーズを満たすソリューションを計画する際には、ハードウェア サポート チームまたはベンダーに相談することをお勧めします。 これらの会話中、特にデータベースが RAM に対して大きすぎる場合は、次のパフォーマンス カウンターが役に立つ場合があります。

• LogicalDisk(*)\Avg Disk sec/Read (たとえば、 NTDS.dit がドライブ D に格納されている場合、完全なパスは LogicalDisk(D:)\Avg Disk sec/Read)。
• LogicalDisk(*)\Avg Disk sec/Write
• LogicalDisk(*)\Avg Disk sec/Transfer
• LogicalDisk(*)\Reads/sec
• LogicalDisk(*)\Writes/sec
• LogicalDisk(*)\Transfers/sec

データを提供するときは、現在の環境を可能な限り正確に把握できるように、サンプル間隔が 15、30、または 60 分であることを確認する必要があります。

結果を評価する

通常、最も要求の厳しいコンポーネントはデータベースであるため、このセクションではデータベースからの読み取りに焦点を当てます。 <NTDS Log>)\Avg Disk sec/Write と LogicalDisk(<NTDS Log>)\Writes/sec) を置き換えることで、ログ ファイルへの書き込みに同じロジックを適用できます。

LogicalDisk(<NTDS>)\Avg Disk sec/Read カウンターは、現在のストレージのサイズが適切かどうかを示します。 その値が、ディスクの種類に対して予想されるディスク アクセス時間とほぼ等しい場合、LogicalDisk(<NTDS>)\Reads/sec カウンターは有効な測定値です。 その結果が、ディスクの種類に対するディスク アクセス時間とほぼ等しい場合、LogicalDisk(<NTDS>)\Reads/sec カウンターは有効な測定値です。 許容される待機時間はストレージ ベンダーによって異なりますが、 LogicalDisk(<NTDS>)\Avg Disk sec/Read に適した範囲は次のとおりです。

• 7,200 rpm: 9 ミリ秒から 12.5 ミリ秒 (ミリ秒)
• 10,000 rpm: 6 ミリ秒から 10 ミリ秒
• 15,000 rpm: 4 ミリ秒から 6 ミリ秒
• SSD – 1 ミリ秒から 3 ミリ秒

他の情報源によると、ストレージのパフォーマンスが 15 ミリ秒から 20 ミリ秒で低下すると言われることがあります。 このような値と上の一覧に示されている値の違いは、一覧の値が通常の動作範囲を示していることです。 他方の値はトラブルシューティングを目的としており、クライアント エクスペリエンスがいつ低下して顕著になったのかを特定するために役立ちます。 詳細については、付録 C を参照してください。

• LogicalDisk(<NTDS>)\Reads/sec は、システムが現在実行している I/O の量です。
  • LogicalDisk(<NTDS>)\Avg Disk sec/Read の値がバックエンド ストレージの最適な範囲内であれば、LogicalDisk(<NTDS>)\Reads/sec を直接使用してストレージのサイズを決定できます。
  • LogicalDisk(<NTDS>)\Avg Disk sec/Readがバックエンド ストレージに最適な範囲内にない場合は、次の式に従って、より多くの I/O が必要になります。物理メディア ディスクのアクセス時間LogicalDisk(<NTDS>)\Avg Disk sec/Read ÷×LogicalDisk(<NTDS>)\Avg Disk sec/Read

これらの計算を行うときは、次の点を考慮する必要があります。

• サーバーに最適でない量の RAM がある場合、結果の値が高すぎて、計画に役立つほど正確ではない可能性があります。 ただし、そのような値を使用して最悪のシナリオを予測することはできます。
• RAM を追加または最適化すると、読み取り I/O の LogicalDisk(<NTDS>)\Reads/Sec も減少します。 この減少により、ストレージ ソリューションの信頼性が、提案された元の計算よりも低くなる可能性があります。 計算は個々の環境、特にクライアントの負荷によって大きく異なるため、この意味を詳細に説明することはできません。 ただし、RAM を最適化した後は、ストレージのサイズ設定をお勧めします。

パフォーマンスに関する仮想化に関する考慮事項

前のセクションと同様に、仮想化のパフォーマンスの目標は、共有インフラストラクチャがすべてのコンシューマーの総負荷をサポートできるようにすることです。 次のシナリオを計画するときは、この目標に留意してください。

• SAN、NAS、または iSCSI インフラストラクチャ上で他のサーバーまたはアプリケーションと同じメディアを共有する物理 CD。
• メディアを共有する SAN、NAS、または iSCSI インフラストラクチャへのパススルー アクセスを使用するユーザー。
• 共有メディア上のローカル VHD ファイル、または SAN、NAS、iSCSI インフラストラクチャを使用しているユーザー。

ゲスト ユーザーの観点から見ると、ホストを経由してストレージにアクセスする必要はパフォーマンスに影響します。ユーザーはアクセスを取得するために、より多くのコード パスを移動する必要があります。 パフォーマンス テストでは、ホスト システムがプロセッサをどの程度使用するかに応じて、仮想化がスループットに影響を与えることが示されています。 プロセッサ使用率は、ゲスト ユーザーがホストに要求するリソースの数に影響します。 仮想化シナリオでの処理ニーズに応じた、処理の仮想化に関する検討では、この要求を考慮する必要があります。 詳細については、付録 A を参照してください。

さらに複雑な問題は、現在使用できるストレージ オプションの数です。それぞれパフォーマンスに大きく異なる影響があります。 これらのオプションには、パススルー ストレージ、SCSI アダプター、IDE が含まれます。 物理環境から仮想環境に移行する場合は、乗数 1.10 を使用して、仮想化されたゲスト ユーザーのさまざまなストレージ オプションを調整する必要があります。 ただし、異なるストレージ シナリオ間で転送する場合は、ストレージがローカル、SAN、NAS、または iSCSI のいずれであるかの方が重要であるため、調整を考慮する必要はありません。

仮想化の計算例

通常の動作状態で正常なシステムに必要な I/O の量を決定する場合:

• LogicalDisk(<NTDS Database Drive>) ÷ ピーク期間中の 15 分間における 1 秒あたりの転送数
• 基盤となるストレージの容量を超えるストレージに必要な I/O の量を決定する場合:

  必要な IOPS = (LogicalDisk(<NTDS Database Drive>)) ÷ Avg Disk Read/sec ÷ <Target Avg Disk Read/sec>) × LogicalDisk(<NTDS Database Drive>)\Read/sec

キャッシュの適切なウォームアップ速度を決定するには:

• キャッシュのウォームアップに使用できる許容可能な最長時間を決定します。 一般的なシナリオで許容される時間は、ディスクからデータベース全体を読み込むのにかかる時間です。 RAM がデータベース全体を読み込めないシナリオでは、RAM 全体を埋めるのにかかる時間を使用します。
• 使用する予定のない領域を除いて、データベースのサイズを決定します。 詳細については、「ストレージの評価」を参照してください。
• データベースのサイズを 8 KB で除算して、データベースを読み込む必要がある I/O の合計数を取得します。
• 合計 I/O 数を、定義された時間枠内の秒数で割ります。

計算する数値は近似値です。 拡張ストレージ エンジン (ESE) のキャッシュ サイズが固定されていないため、正確ではありません。 既定ではキャッシュは拡大および縮小されるため、AD DS は以前に読み込んだページを削除する可能性があります。 キャッシュ サイズを固定すると、見積もりがより正確になります。

処理中

Active Directory のプロセッサ使用率の評価

ほとんどの環境で、最も注意を払う必要がある要素は処理能力の管理です。 展開に必要な CPU キャパシティを評価するときは、次の 2 点を考慮する必要があります。

• 環境内のアプリケーションが共有サービス インフラストラクチャ内で、「コストがかかり非効率的な検索の追跡」に概説されている基準に基づき、意図したとおりに動作するかどうか。 大規模な環境では、アプリケーションのコーディングが適切でないと、CPU 負荷が不安定になり、他のアプリケーションを犠牲にして CPU 時間が過度に消費され、キャパシティ ニーズが高まり、DC に対する負荷が不均等に分散される可能性があります。
• AD DS は分散環境であり、処理ニーズが大きく異なる可能性のあるクライアントが多数あります。 各クライアントの推定コストは、使用パターンと、AD DS を使用しているアプリケーションの数によって異なる場合があります。 「ネットワーク」で説明したように、各クライアントを 1 つずつ確認するのではなく、環境内で必要な総キャパシティを評価するという形で見積もりを行う必要があります。

プロセッサの使用量の見積もりを開始する前に、 ストレージ の見積もりを完了してください。 プロセッサの負荷に関する有効なデータがないと、正確な推測を行うことはできません。 また、プロセッサのトラブルシューティングを行う前に、ストレージでボトルネックが発生していないことを確認することも重要です。 プロセッサの待機状態を削除すると、データを待機する必要がなくなるため、CPU 使用率が増加します。 そのため、最も注意が必要なパフォーマンス カウンターは次のとおりです。

• Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read
• Process(lsass)\ Processor Time

Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read カウンターが 10 ミリ秒または 15 ミリ秒を超える場合、Process(lsass)\ Processor Timeのデータは人為的に低く、問題はストレージのパフォーマンスに関連しています。 可能な限り正確なデータを取得するには、サンプル間隔を 15 分、30 分、または 60 分に設定することをお勧めします。

処理の概要

ドメイン コントローラーのキャパシティ プランニングを計画するたには、処理能力に最も注意を払って理解する必要があります。 最大のパフォーマンスを確保できるようにシステムのサイズを決定する場合、ボトルネックとなるコンポーネントが常に存在します。適切なサイズのドメイン コントローラーでは、このコンポーネントはプロセッサです。

環境の需要がサイトごとに見直されるネットワーク セクションと同様に、要求されるコンピューティング容量についても同じことを行う必要があります。 利用可能なネットワーク テクノロジが通常の需要をはるかに超えるネットワーク セクションとは異なり、CPU 容量のサイズ設定にさらに注意を払ってください。 中規模の環境でも同様です。同時ユーザーが数千人を超えると、CPU に大きな負荷をかける可能性があります。

残念ながら、AD を使用するクライアント アプリケーションの大きな変動により、CPU あたりのユーザーの一般的な見積もりはすべての環境に適用できません。 具体的には、コンピューティング需要は、ユーザーの行動とアプリケーション プロファイルの影響を受けます。 そのため、環境ごとに個別にサイズを設定する必要があります。

ターゲット サイトの動作プロファイル

サイト全体のキャパシティ プランニングを行う場合、N + 1 というキャパシティ設計を目標にする必要があります。 この設計では、ピーク期間中に 1 つのシステムが失敗した場合でも、許容できるレベルの品質でサービスを続行できます。 N のシナリオでは、ピーク期間中にすべてのボックスの負荷が 80% ～ 100% 未満である必要があります。

また、サイトのアプリケーションとクライアントは、DC を検索するために推奨される DsGetDcName 関数 メソッドを使用します。 これらは、わずかな一時的なスパイクのみで既に均等に分散されている必要があります。

ここで、目標どおりの環境と目標どおりでない環境の例を見てみましょう。 まず、意図したとおりに機能し、キャパシティ プランニングの目標枠を超過しない環境の例を見てみましょう。

最初の例では、次のように想定します。

• サイト内の 5 つの DC に、それぞれ 4 つの CPU があるものとします。
• 業務時間内の目標合計 CPU 使用率は、通常の動作条件 (N + 1) では 40%、それ以外の場合 (N) は 60% です。 非稼働時間中は、バックアップ ソフトウェアやその他のメンテナンス プロセスが使用可能なすべてのリソースを消費することが予想されるため、ターゲット CPU 使用率は 80% です。

次に、下の画像で各 DC の (Processor Information(_Total)\% Processor Utility) グラフを見てみましょう。

• 負荷は均等に分散されます。これは、クライアントが DC ロケーターと適切に記述された検索を使用する場合に想定されるものです。

• 5 分間隔で数回、10% のスパイクがあり、時には 20% の場合もあります。 ただし、スパイクによって CPU 使用率がキャパシティ プランの目標を超える場合を除き、それらを調査する必要はありません。

• すべてのシステムのピーク期間は、AM 8 時 から AM 9 時 15 分までです。 平均的な営業日は AM 5 時から PM 5 時までです。 したがって、PM 5 時からAM 4 時の間に発生する CPU 使用率のランダムなスパイクは業務時間外であるため、キャパシティ プランニングの考慮事項に含める必要はありません。

  ピーク外の時間帯には、通常、適切に管理されたシステムでの短いスパイクは次のことから発生します。

  • バックアップ ジョブ
  • 完全なウイルス対策スキャン
  • ハードウェア インベントリ スキャン
  • ソフトウェア インベントリ スキャン
  • ソフトウェア配布またはパッチの展開

  これらのタスク以外の急上昇は、異常な負荷を示しており、調査が必要な場合があります。 これらのスパイクは業務時間外に発生するため、キャパシティ プランニングの目標に対して超過の加算対象にはなりません。

• 各システムは約 40% で、すべて同じ数の CPU を持っているため、そのうちの 1 つがオフラインになると、残りのシステムは推定 53% で実行されます。 システム D の 40% 負荷は、残りのシステム間で均等に分割され、既存の 40% 負荷に追加されます。 この線形再頒布の前提条件は完全には正確ではありませんが、推定に十分な精度を提供します。

次に、CPU 使用率が思わしくなく、キャパシティ プランニングの目標を超えている環境の例を見てみましょう。

この例では、2 つの DC が 40%で実行されます。 1 つはオフラインになり、残りの DC は推定 80%にジャンプします。 フェールオーバー中、この負荷は容量プランのしきい値を超え、スパイクに備えた余裕が10%～20%まで縮小されます。 各スパイクで DC を 90% または 100%に駆動できるようになり、応答性が低下します。

CPU 要求の計算

Process\% Processor Time パフォーマンス カウンターは、アプリケーションのすべてのスレッドが CPU に費やした時間を合計し、経過したシステム時間の合計で除算したものです。 マルチ CPU システム上のマルチスレッド アプリケーションは、CPU 時間が 100% を超える可能性があり、そのデータを Processor Information\% Processor Utility カウンターとは異なる方法で解釈します。 実際には、Process(lsass)\% Processor Time カウンターでは、プロセスの要求をサポートするためにシステムが必要とする 100% で実行されている CPU の数を追跡しています。 たとえば、カウンターの値が 200% の場合、AD DS の全負荷をサポートするには、2 つの CPU がそれぞれ 100% で実行される必要があることを意味します。 100% 容量で実行されている CPU は電力とエネルギー消費の面で最もコスト効率が高いですが、マルチスレッド システムは、システムが 100%で実行されていない場合の応答性が高くなります。 この効率の理由については、「 付録 A」を参照してください。

クライアント負荷の一時的なスパイクに対応するには、目標として、ピーク時の CPU をシステム キャパシティの 40% ～ 60% にすることをお勧めします。 たとえば、「ターゲット サイトの動作プロファイル」の最初の例では、AD DS の負荷をサポートするには、3.33 個の CPU (目標の 60%) から 5 個の CPU (目標の 40%) が必要になります。 OS やその他の必要なエージェント (ウイルス対策、バックアップ、監視など) の要求に応じて、キャパシティを追加する必要があります。 インフラストラクチャ エージェント (ウイルス対策、バックアップ、監視) 用に、1 つの CPU の容量の 5 ~ 10% を予約する予定です。 環境内の実際のエージェントの使用状況を測定し、必要に応じて調整します。 この例でピーク時の負荷をサポートするには、3.43 個 (目標の 60%) から 5.1 個 (目標の 40%) の CPU が必要です。

次に、特定のプロセスの計算例を見てみましょう。 ここでは、LSASS プロセスについて説明します。

LSASS プロセスでの CPU 使用率の計算

この例では、システムは N + 1 のシナリオであり、1 台のサーバーが AD DS の負荷を処理し、冗長性のために追加のサーバーが存在します。

次のグラフは、このシナリオ例のすべてのプロセッサにおける LSASS プロセスのプロセッサ時間を示しています。 これらのデータ ポイントは、 Process(lsass)\% Processor Time パフォーマンス カウンターから取得されます。

LSASS プロセッサの時間グラフは、シナリオの環境についての情報を示しています。

• サイトには 3 つのドメイン コントローラーがあります。
• 営業日は AM 7 時頃に始まり、PM 5 時頃に終わります。
• 一日で最も忙しい時間帯は AM 9 時 30 分から AM 11 時までです。

  注

  すべてのパフォーマンス データは履歴です。 Am 9 時 15 分のピーク データ ポイントは、AM 9 時から AM 9 時 15 分までの負荷を示しています。

• AM 7 時より前にスパイクがあります。これは、異なるタイム ゾーンからの負荷や、バックアップなどバックグラウンド インフラストラクチャ アクティビティによる追加の負荷を示している可能性があります。 ただし、このスパイクは AM 9 時 30 分のピーク アクティビティよりも小さいため、問題の原因にはなりません。

最大負荷では、LSASS プロセスは 100%で実行されている約 4.85 CPU を消費します。これは、1 つの CPU で 485% になります。 つまり、シナリオのサイトで AD DS を処理するには、約 12.25 個の CPU が必要であるということです。 バックグラウンド プロセス用に、推奨される 5% ～ 10% のキャパシティを追加した場合、サーバーが同じの負荷をサポートするには 12.30 ～ 12.25 個の CPU が必要になります。 将来的な成長を予ふまえた見積もりでは、この数値がさらに大きくなります。

LDAP の重みをチューニングするタイミング

シナリオによっては、LdapSrvWeight のチューニングを検討する必要があります。 キャパシティ プランニングにおいては、アプリケーションまたはユーザーの負荷や、基盤となるシステムの機能が均等に分散されていない場合に、これを行います。

次のセクションでは、Lightweight Directory Access Protocol (LDAP) の重みを調整する必要がある 2 つのシナリオ例について説明します。

例 1: PDC エミュレータ環境

プライマリ ドメイン コントローラー (PDC) エミュレータを使用している場合、ユーザーまたはアプリケーションの動作が均等に分散されていないと、一度に複数の環境に影響を及ぼす可能性があります。 PDC エミュレーターは、通常、他のドメイン コントローラーよりも高い CPU 負荷を持っています。 多くの操作では、この方法が好まれるか常に利用されます。例には以下が含まれます。

• グループ ポリシー管理ツール (作成、編集、リンク、GPMC 更新)
• パスワード変更の検証/2 回目の認証試行 (フォールバック パスワード チェック)
• 信頼の作成とメンテナンスの操作
• タイム サービス階層 (ドメイン/フォレスト内の権限のあるタイム ソース)
• アカウント ロックアウト処理
• PDC エミュレーターを対象とするレガシ または正しく構成されていないアプリケーション

これらの操作が頻繁に行われる場合は、CPU を個別に監視し、余分なリソースの余裕を計画します。

PDC エミュレータは、CPU 使用率に顕著な違いがある場合にのみ調整する必要があります。 チューニングでは、PDC エミュレータの負荷を軽減し、他の DC の負荷を増やして、より均等な負荷分散を可能にする必要があります。

このような場合は、PDC エミュレータの LDAPSrvWeight の値を 50 ～ 75 の範囲に設定します。

ここでの問題点は、PDC エミュレータ ロールが、(特にサイト内の別のドメイン コントローラーに) 転送または強制移行された場合、新しい PDC エミュレータで CPU 使用率が劇的に増加することです。

この例のシナリオでは、「ターゲット サイトの動作プロファイル」に基づいて、このサイトの 3 台のドメイン コントローラーすべてに 4 個の CPU があることを想定しています。 ドメイン コントローラーの 1 台に 8 個の CPU が搭載されている場合、通常の状況ではどうなるでしょうか。 使用率が 40% のドメイン コントローラーが 2 台と、使用率が 20% のドメイン コントローラーが 1 台あることになります。 この構成は必ずしも悪いわけではありませんが、LDAP の重みをチューニングすると、負荷分散のバランスを改善できます。

例 2: CPU 数が異なる環境

同じサイト内に CPU 数や速度が異なるサーバーがある場合は、それらが均等に分散されていることを確認する必要があります。 たとえば、サイトに 8 コア サーバーが 2 台と 4 コア サーバーが 1 台ある場合、4 コア サーバーの処理能力は他の 2 台のサーバーの半分です。 クライアントの負荷が均等に分散されている場合、CPU 負荷を処理するために、4 コア サーバーでは 2 台の 8 コア サーバーの 2 倍奮闘する必要があります。 さらに、8 コア サーバーのいずれかがオフラインになると、4 コア サーバーでは過負荷になります。

N + 1 シナリオの計画は重要です。 1 つの DC がオフラインになることによる影響は、シナリオごとに計算する必要があります。 前の例では、負荷はすべてのサーバーで均等に共有されています。 N のシナリオ (1 台のサーバーが失われた場合) では、残りの各サーバーは約 60%にとどまります。 比率は一貫しているため、現在の分布は許容されます。 PDC エミュレーターのチューニング シナリオ、またはユーザーまたはアプリケーションの負荷が不均衡な一般的なシナリオを見ると、効果は異なります。

処理のための仮想化に関する考慮事項

仮想化環境のキャパシティ プランニングを行う場合は、ホスト レベルとゲスト レベルの 2 レベルを考慮する必要があります。 ホスト レベルでは、ビジネス サイクルのピーク期間を特定する必要があります。 仮想マシンの CPU 上でゲスト スレッドをスケジュールするには、物理マシンの CPU 上での AD DS スレッドの取得と似た処理が必要になるため、基盤となるホストの 40% ～ 60% を使用することをお勧めします。 ゲスト レベルでも、基礎となるスレッド スケジューリングの原則は変わらないため、CPU 使用率を 40% ～ 60% の範囲内に維持することをお勧めします。

直接マップされたセットアップ (ホストごとに 1 人のゲスト) の場合は、前に収集した容量計画番号を再利用します。 これを直接適用して、このデプロイのサイズを変更します。

共有ホスト シナリオでは、仮想化による CPU 効率のオーバーヘッドが約 10% であると想定します。 物理ハードウェアで 40% ターゲット使用率でサイトに 10 個の CPU が必要な場合は、そのオーバーヘッドに対してもう 1 つの CPU を追加します。 N ゲスト ドメイン コントローラー全体に合計 11 個の仮想 CPU (vCPU) を割り当てます。

物理サーバーと仮想サーバーの分散が混在するサイトでは、この仮想化オーバーヘッドは仮想マシン (VM) にのみ適用されます。 N + 1 の設計では、10 CPU 物理 (または直接マップされた) サーバーは、11 個の vCPU を持つ仮想 DC とほぼ同等です。 ホストには、その VM 用に予約された別の 11 個の CPU も必要です。

AD DS のロードをサポートするのに必要な CPU 数を分析し計算している間。 物理ハードウェアを購入する予定の場合、市場で利用可能なハードウェアの種類が見積もりに正確に対応していない可能性があることに注意してください。 ただし、仮想化を使用すると、その問題は発生しません。 VM を使用すると、必要な仕様の CPU を VM にいくつでも追加できるため、サイトにコンピューティング キャパシティを追加するために必要な労力を削減できます。 ただし、仮想化では、ゲストがより多くの CPU リソースを必要とする場合に、基になるハードウェアが使用可能であることを保証するために必要なコンピューティング能力を正確に評価する責任はなくなります。 常に成長を計画してください。

仮想化の計算の概要例

3 年間で 50% 需要の増加を予測する場合は、その時点で 18.375 CPU (12.25 × 1.5) を計画します。 あるいは、最初の 1 年が経過した後に需要を確認し、その結果に基づいて追加のキャパシティを追加することもできます。

NTLM の相互信頼クライアント認証の負荷

NTLM の相互信頼クライアント認証の負荷を評価する

多くの環境では、1 つ以上のドメインが信頼によって接続されている可能性があります。 Kerberos 認証を使用しない別のドメインの ID に対する認証要求では、セキュリティで保護されたチャネルを 2 つのドメイン コントローラー間で使用して信頼を走査する必要があります。 ユーザーのドメイン コントローラーは、宛先ドメイン内のドメイン コントローラー、またはそのドメインへの信頼パスに沿って次のドメイン コントローラーに接続します。 *MaxConcurrentAPI 設定は、信頼されたドメイン内の他の DC に対して DC が実行できる呼び出しの数を制御します。 DC 間で相互に通信するために必要な負荷量をセキュリティで保護されたチャネルが処理できるようにするには、MaxConcurrentAPI を調整するか、フォレスト内であればショートカット信頼を作成します。 信頼間のトラフィック量を決定する方法の詳細については、MaxConcurrentApi 設定を使用して NTLM 認証のパフォーマンス チューニングを行う方法の記事を参照してください。

これまでのシナリオと同様、データを活用するには、一日のピーク時間帯にデータを収集する必要があります。

仮想化のプランニング

仮想化のキャパシティ プランニングを行うときは、次の点に注意する必要があります。

• 多くのアプリケーションでは、既定または特定の構成で NTLM 認証が使用されます。
• アクティブなクライアントの数が増えるにつれて、アプリケーション サーバーのキャパシティも増やす必要があります。
• クライアントは限られた時間セッションを開いたままにし、代わりに電子メールプル同期などのサービスのために定期的に再接続することがあります。
• インターネット アクセスに認証が必要な Web プロキシ サーバーでは、NTLM の負荷が高くなる可能性があります。

そのような用途では、NTLM 認証の負荷が大きくなる可能性があり、特にユーザーとリソースが異なるドメインにある場合は、DC に大きな負担がかかります。

信頼境界を越える負荷を管理するにはさまざまなアプローチがあり、多くの場合、それらを同時に使用できます。

• 信頼境界を越えたクライアント認証を削減するには、ユーザーが使用するサービスをユーザーと同じドメイン内に配置します。
• セキュリティで保護された使用可能なチャネルの数を増やします。 これらのチャネルはショートカット信頼と呼ばれ、フォレスト内およびフォレスト間のトラフィックに関連しています。
• MaxConcurrentAPI の既定の設定をチューニングします。

既存のサーバーで MaxConcurrentAPI を調整するには、次の式を使用します。

average_semaphore_hold_time ÷ time_collection_lengthを×≥ (semaphore_acquires + semaphore_timeアウト) をNew_MaxConcurrentApi_settingする

詳細については、「サポート技術情報の記事 2688798: MaxConcurrentApi の設定を使用して NTLM 認証のパフォーマンスをチューニングする方法」を参照してください。

仮想化に関する考慮事項

仮想化はオペレーティング システムのチューニング設定であるため、特別な考慮事項はありません。

仮想化チューニングの計算例

この期間、このシステムでは既定値が許容されます。

キャパシティ プランニング目標の準拠を監視する

この記事では、計画とスケーリングが使用率の目標にどのように向かうかについて説明しました。 次の表は、システムが意図したとおりに動作しているか確認するために監視する必要がある、推奨のしきい値をまとめたものです。 これらはパフォーマンスのしきい値ではなく、あくまでもキャパシティ プランニングでのしきい値であることに注意してください。 これらのしきい値を超えて動作しているサーバーは引き続き機能しますが、ユーザーの需要が増加するにつれてパフォーマンスの問題が発生する前に、アプリケーションが意図したとおりに動作していることを検証する必要があります。 アプリケーションに問題がなければ、ハードウェアのアップグレードやその他の構成変更の評価を開始する必要があります。

付録 A: CPU のサイズ設定の条件

この付録では、環境の CPU サイズ設定ニーズを見積もるために役立つ用語と概念について説明します。

定義: CPU のサイズ設定

• プロセッサ (マイクロプロセッサ) は、プログラムの命令を読み取って実行するコンポーネントです。

• マルチコア プロセッサでは、同じ集積回路上に複数の CPU コアが搭載されています。

• マルチ CPU システムには、同じ集積回路上にない複数の CPU があります。

• 論理プロセッサとは、オペレーティング システムの観点では、論理コンピューティング エンジンが 1 つだけあるプロセッサを指します。

これらの定義には、ハイパースレッド、マルチコア プロセッサ上の 1 コア、シングル コア プロセッサなどが含まれます。

今日のサーバー システムには複数のプロセッサ、複数のマルチコア プロセッサ、およびハイパースレッディングが搭載されているため、これらの定義は両方のシナリオに対応できるように一般化されています。 論理プロセッサという用語を使用するのは、利用可能なコンピューティング エンジンの OS とアプリケーションの観点を表すためです。

スレッドレベルの並列処理

各スレッドには独自のスタックと命令があるため、各スレッドは独立したタスクです。 AD DS はマルチスレッドであり、使用可能なスレッドの数を調整できるため、複数の論理プロセッサ間で適切にスケーリングできます。 使用可能なスレッドのチューニングの詳細については、「 Ntdsutil.exeを使用して Active Directory で LDAP ポリシーを表示および設定する方法 」の指示に従ってください。

データレベルの並列処理

データ レベルの並列処理とは、サービスが同じプロセスの複数のスレッド間でデータを共有し、複数のプロセス間で多数のスレッドを共有する場合です。 AD DS プロセスのみであっても、単一のプロセスの複数のスレッド間でデータを共有するサービスとしてカウントされます。 データへの変更は、キャッシュのすべてのレベル、すべてのコア、および共有メモリへの更新で実行中のすべてのスレッドに反映されます。 書き込み操作中は、命令処理を続行する前にすべてのメモリ位置が変更に合わせて調整されるため、パフォーマンスが低下する可能性があります。

CPU 速度とマルチコアに関する考慮事項

論理プロセッサの高速化により、1 つのスレッドが作業を完了するために必要な時間が短縮されます。 論理プロセッサを追加すると、並列で実行できるスレッドの数が増えます。 ただし、スケーリングは、メモリ待機時間、共有リソースの競合、同期/ロック、シリアル コード パス、およびスケジュールのオーバーヘッドにより非線形になります。 これらにより、マルチコア システムでのスケーラビリティは線形ではありません。

複数の制約が相互作用するため、使用率は非線形にスケーリングされます。

• 単一の実行可能なスレッドは、より高速なコアでより早く終了します。より多くのアイドル コアを追加しても、実行可能な並列作業がない限り、利点はありません。
• キャッシュ ミスでスレッドがストールした場合、またはメイン メモリからのデータが必要な場合、データが返されるまで進むことはありません。 より高速なコアでもメモリ待機時間を排除することはできません。それらはサイクルレートに対してより長く待つことになる可能性があります。
• コンカレンシー (実行可能なスレッド) が増加すると、同期、キャッシュコヒーレンス トラフィック、ロックの競合、スケジューラのオーバーヘッドによって、合計サイクルの割合が大きくなります。
• より広いシステム (より多くのソケット/コア) は、グローバルな順序付けを必要とする操作 (共有データの変更、TLB の撃ち込み、プロセッサ間の割り込みなど) の待機時間の影響を増幅します。
• 一部のコード パスはシリアル (アムダールの法則) です。 並列領域が飽和状態になると、余分なコアによってリターンが減少します。

そのため、コアまたは頻度を追加すると、ワークロードが十分に実行可能で並列化可能な作業を行い、メモリ、ストレージ、またはロックの競合で主にストールしていない場合にのみ、AD DS のスループットが向上します。

つまり、プロセッサの数を増やすべきか高速なプロセッサを追加すべきかという質問に対する答は非常に主観的なものとなり、ケースバイケースで検討する必要があります。 特に AD DS の場合、処理のニーズは環境要因に依存し、単一環境内のサーバーごとに異なる場合があります。 そのため、この記事の前半では、正確さを追求した計算を行うことに重点を置きませんでした。 予算に基づいて購入を決定する場合は、まずプロセッサの使用率を 40% (または対象の環境で必要な数値) に最適化することをお勧めします。 システムが最適化されていない場合は、プロセッサを追加購入してもそれほどメリットはありません。

システムアクティビティレベルによるパフォーマンスへの影響と応答時間

待ち行列理論は、待ち行列またはキューの数学的研究です。 コンピューティングの待ち行列理論では、利用法則が t 方程式で表されます。

U k = B ÷ T

ここで、U k は使用率、B はビジー状態で費やされた時間、T はシステムの監視に費やされた合計時間です。 Microsoft のコンテキストでは、これは、実行状態にある 100 ナノ秒 (ns) 間隔のスレッドの数を、指定された時間間隔で使用可能だった 100 ns 間隔の数で割った値を意味します。 この式は、「プロセッサ オブジェクト」および「PERF_100NSEC_TIMER_INV」に示されているプロセッサ使用率のパーセンテージを計算する式と同じです。

待ち行列理論では、使用率に基づいて待機中の項目の数を推定するための式 N = U k ÷ (1 - U k) も提供されています (N はキューの長さ)。 この式をすべての使用率間隔にわたってグラフ化すると、特定の CPU 負荷でプロセッサにキューが到達するまでの長さが次のように推定されます。

この推定に基づくと、CPU 負荷が 50% を超えると、平均的な待機では通常、キュー内に別の項目が 1 つ含まれ、CPU 使用率が急速に 70% に増加することがわかります。

待ち行れる理論が AD DS 展開にどのように適用されるかを理解するために、「CPU 速度とマルチコアに関する考慮事項」で使用した高速道路の例えに戻りましょう。

午後中頃の忙しい時間帯は、キャパシティが 40% ～ 70% の範囲になります。 交通量は十分あるため、運転する車線を選択する能力はそれほど制限されません。 別のドライバーがに割り込まれる可能性は高いですが、ラッシュアワーのときのように、車線内で他の車の間に安全な隙間を見つけるために必要なレベルの労力は必要ありません。

ラッシュアワーが近づくと、道路網のキャパシティは 100% に近くなります。 ラッシュアワーに車線を変更するのは非常に困難になります。車同士が接近しすぎていて、車線変更時に使える余地があまりないからです。 キューの動作が、長期的な平均容量目標40%を説明しています。 平均使用率を 40% 近くに維持すると、短いスパイク (低速または不適切なコーディングされたクエリなど) や、より大きなバースト イベント (休日の朝の急増など) の余地が残ります。

前の記述では、プロセッサ時間のパーセンテージの計算は使用率法則の式と同じであるとみなしています。 この簡略化されたバージョンは、新しいユーザーにこの概念を紹介することを目的としています。 ただし、より高度な計算については、次のリファレンスをガイドとして使用できます。

• PERF_100NSEC_TIMER_INV を変換する
  • B = アイドル スレッドが論理プロセッサで費やす 100 ナノ秒間隔の数。 PERF_100NSEC_TIMER_INV 計算における X 変数の変化
  • T = 指定された時間範囲内の 100 ns 間隔の総数。 PERF_100NSEC_TIMER_INV 計算における Y 変数の変化。
  • U k = Idle Thread または % Idle Time による論理プロセッサの使用率。
• 数学の計算:
  • U k = 1 – %Processor 時間
  • %Processor 時間 = 1 – U k
  • %Processor 時間 = 1 – B / T
  • %Processor 時間 = 1 – X1 – X0 / Y1 – Y0

これらの概念をキャパシティ プランニングに適用する

前のセクションの数学では、システムで必要な論理プロセッサの数を決定することはおそらく複雑に見えます。 このため、システムのサイズを設定するアプローチでは、現在の負荷に基づいて最大ターゲット使用率を決定し、そのターゲットに到達するために必要な論理プロセッサの数を計算することに重点を置く必要があります。 これに加え、見積もりは完全に正確に行う必要はありません。 論理プロセッサの速度は同期に大きな影響を与えますが、次のような他の領域もパフォーマンスに影響する可能性があります。

• キャッシュの効率性
• メモリ コヒーレンスの要件
• スレッドのスケジューリングと同期
• 不完全なバランスのクライアント負荷

コンピューティング能力のコストは比較的低いため、必要な CPU の数を正確に計算するために時間をかける価値はありません。

この場合、40% のレコメンデーションは必須要件ではないことにも注意することが重要です。 この数値は、計算を行ううえでの妥当な開始点として使用します。 AD ユーザーの種類によって、必要な応答性のレベルは異なります。 一部の環境では平均で 80%–90% CPU を使用でき、キューの待機時間が著しく増加しない場合でもユーザーの期待を満たすことができます。 これを例外として扱い、待機時間データで検証し、新たな競合を注意深く監視します。

システムの他の部分は CPU よりも低速です。 チューニングもしてみてください。 RAM アクセス、ディスク アクセス、ネットワーク応答時間に重点を置きます。 例えば次が挙げられます。

• ディスクバウンドで 90% の使用率で稼働しているシステムにプロセッサを追加しても、パフォーマンスが大幅に向上することは期待できません。 システムを詳しく調べると、I/O 操作の完了を待っているためにプロセッサにアクセスできないスレッドが多数あります。

• ディスクバウンドの問題を解決すると、待機状態のままになっていたスレッドが停止しなくなり、CPU 時間の競合が増える可能性があります。 その結果、90% 使用率は 100%になります。 使用率を管理可能なレベルに戻すには、両方のコンポーネントを調整する必要があります。

  注

  Processor Information(*)\% Processor Utility カウンターは、ターボ モードのあるシステムでは 100% を超えることがあります。 ターボ モードでは、CPU が短時間、定格プロセッサ速度を超えることがあります。 詳細については、CPU 製造元のドキュメントとカウンターの説明を参照してください。

システム全体の使用率に関する考慮事項を議論する際には、仮想化ゲストとしてのドメイン コントローラーも考慮する必要があります。 応答時間とシステム アクティビティ レベルがパフォーマンスに与える影響は、仮想化シナリオのホストとゲストの両方に適用されます。 ゲストが 1 台だけのホストでは、DC またはシステムのパフォーマンスは物理ハードウェアの場合とほぼ同じです。 ホストにゲストを追加すると、基盤となるホストの使用率が増加し、プロセッサにアクセスするための待機時間も長くなります。 このため、論理プロセッサの使用率は、ホスト レベルとゲスト レベルの両方で管理する必要があります。

これまでのセクションで使用した高速道路の例えについて、もう一度考えてみましょう。ただし、今回はゲスト VM を高速バスとして想像します。 高速バスは、公共交通機関やスクール バスとは異なり、停車せずに乗客の目的地まで直行します。

では、4 つのシナリオを想像してみましょう。

• システムのオフピーク時間帯は、深夜に高速バスに乗っているようなものです。 乗車すると、他の乗客はほとんどおらず、道路もほぼ空です。 交通渋滞が無いため、乗客は自分の車で運転しているように、バスの移動が簡単で迅速です。 ただし、ローカルの速度制限により、ライダーの移動時間が制限される可能性があります。
• オフピークの時間帯にシステムの CPU 使用率が高すぎる状況は、高速道路のほとんどの車線が閉鎖されている深夜の乗車に似ています。 バス自体はほとんど空いていますが、通行車線が制限される中、その時間にも走行している車両で道路は依然として混雑しています。 乗客は好きな席所に座ることができますが、実際の移動時間は車外の交通状況によって決まります。
• ピーク時の CPU 使用率が高いシステムは、ラッシュ時に混雑しているバスのようなものです。 移動に時間がかかるだけでなく、車内は乗客でいっぱいなので、乗り降りも難しくなります。 待ち時間を短縮しようとゲスト システムに論理プロセッサを追加することは、バスを追加して渋滞の問題を解決しようとするようなものです。 問題はバスの数ではなく、移動にかかる時間です。
• オフピークの時間帯に CPU 使用率が高いシステムは、夜間にほとんど空の道路を混雑したバスが走っている状況に似ています。 乗客が座席を見つけたり、バスを乗り降りしたりするのに問題があるかもしれませんが、バスがすべての乗客を迎えに行くと、旅行はかなりスムーズです。 このシナリオは、バスを追加することでパフォーマンスが向上する唯一のケースです。

これまでの例から、0% ～ 100% の使用率の間には、パフォーマンスにさまざまな度合いの影響を与えるシナリオが多数あることがわかります。 また、論理プロセッサを追加しても、特定のシナリオ以外のパフォーマンスが必ずしも向上するとは限りません。 これらの原則を、ホストとゲストに推奨される 40% の CPU 使用率目標に適用することは難しくないはずです。

付録 B: プロセッサ速度の違いに関する考慮事項

「処理」では、データの収集中にプロセッサが 100% のクロック速度で実行されていて、交換システムの処理速度も同じであると想定しました。 これらの前提条件は正確ではありませんが (特に Windows Server 2008 R2 以降では既定の電源プランがバランスになっているため)、控えめに見積もる場合はこれらの前提条件を使用できます。 潜在的なエラーが増加する可能性がある一方で、プロセッサの速度が上がるにつれて安全性のマージンが増えるだけです。

• たとえば、11.25 個の CPU を必要とするシナリオで、データ収集時にプロセッサが半分の速度で動作していた場合、その需要のより正確な推定値は 5.125 ÷ 2 になります。
• ただしクロック速度を 2 倍にしても、記録中の期間内に発生する処理量が 2 倍になることを保証することは不可能です。 プロセッサが RAM またはその他のコンポーネントを待機するための時間は、ほぼ変わりません。 したがって、より高速なプロセッサでは、システムがデータを取得するのを待機している間、アイドル状態の時間の割合が大きくなる可能性があります。 最小公分母を使い、見積もりを控えめにしておき、不正確な結果につながるプロセッサ速度間の線形比較は想定しないことをお勧めします。

交換用ハードウェアのプロセッサ速度が現在のハードウェアより低い場合は、必要なプロセッサ数の推定値を比例的に増やす必要があります。 たとえば、サイトの負荷を支えるために 10 個のプロセッサが必要であると計算したシナリオについて考えてみましょう。 現在のプロセッサは 3.3 GHz で動作し、交換予定のプロセッサは 2.6 GHz で動作します。 元のプロセッサを 10 個交換しただけでは、速度が 21% 低下します。 速度を上げるには、10 個ではなく少なくとも 12 個のプロセッサが必要になります。

ただし、このような変更があってもキャパシティ管理プロセッサの使用率目標は変わりません。 プロセッサのクロック速度は負荷需要に基づいて動的に調整されるため、高負荷でシステムを実行すると、CPU が高クロック速度状態になっている時間が長くなります。 最終的な目標は、業務時間中のピーク時に、100% のクロック速度状態で CPU の使用率を 40% にすることです。 ピーク時以外のシナリオでは CPU 速度を調整することで、少なからず節電が発生します。

さまざまなプロセッサの見積もりを調整するには、Standard Performance Evaluation Corporation のSPECint_rate2006 ベンチマークを使用することをお勧めします。 このベンチマークを使用するには:

1. Standard Performance Evaluation Corporation (SPEC) の Web サイトにアクセスします。

2. 結果を選択します。

3. 「CPU2006」と入力し、[Search] を選択します。

4. [Available Configurations] ドロップダウン メニューで、[All SPEC CPU2006] を選択します。

5. [Search Form Request] フィールドで [Simple] を選択し、[Go!] を選択します。

6. [Simple Request]で、対象のプロセッサを検索する条件を入力します。 たとえば、E5-2630 プロセッサを探している場合は、ドロップダウン メニューの [ プロセッサ] を選択し、検索フィールドにプロセッサ名を入力します。 完了したら、[Execute Simple Fetch] を選択します。

7. 検索結果から、サーバーとプロセッサの構成を探します。 検索エンジンから正確に一致する結果が返されない場合は、できるだけ近いものを探します。

8. [Result] 列と [# Cores] 列の値を記録します。

9. 次の数式を使用して係数を決定します。

   (("ターゲット プラットフォームのコアあたりのスコア値") × ("ベースライン プラットフォームのコアあたりの MHz")) ÷ (("ベースラインのコア ごとのスコア値") × ("ターゲット プラットフォームのコアあたりの MHz"))

   たとえば、E5-2630 プロセッサの修飾子を見つける方法を次に示します。

   (35.83 × 2000) ÷ (33.75 × 2300) = 0.92

10. 必要なプロセッサ数と推定される数にこの係数を掛けます。

    E5-2630 プロセッサの例では、0.92 × 10.3 = 10.35 プロセッサです。

付録 C: オペレーティング システムとストレージの対話方法

「システムアクティビティレベルによるパフォーマンスへの影響と応答時間」で説明した待ち行列理論の概念は、ストレージにも適用されます。 これらの概念を効果的に適用するには、OS で I/O がどのように処理されるかを理解している必要があります。 Windows オペレーティング システムでは、システムは各物理ディスクの I/O 要求を保持するキューを作成します。 ただし、物理ディスクは必ずしも単一のディスクであるとは限りません。 OS が、アレイ コントローラーまたは SAN 上のスピンドルの集合を 1 つの物理ディスクとして登録することもあり得ます。 アレイ コントローラーと SAN は、複数のディスクを 1 つのアレイ セットに集約し、それを複数のパーティションに分割して、各パーティションを物理ディスクとして使用することもできます (次の図を参照)。

この図では、2 つのスピンドルがミラーリングされており、データ ストレージ用の論理領域に分割され、データ 1 とデータ 2 というラベルが付いています。 OS は、これらの論理領域をそれぞれ別々の物理ディスクとして登録します。

次に、物理ディスクを定義する内容を明確にしました。 次の用語は、この付録の情報をより深く理解するのに役立ちます。

• A spindle は、サーバーに物理的に取り付けられているデバイスです。 スピンドルは、サーバーに物理的に取り付けられているデバイスです。
• アレイはスピンドルの集合であり、コントローラーによって統合されます。
• アレイ パーティションは、統合されたアレイのパーティションです。
• 論理ユニット番号 (LUN) は、コンピューターに接続された SCSI デバイスのアレイに使用されます。 この記事では、SAN に関する説明で、これらの用語を使用します。
• ディスクには、OS によって単一の物理ディスクとして登録されるスピンドルまたはパーティションが含まれます。
• パーティションは、OS によって物理ディスクとして登録されるディスクの論理パーティションです。

オペレーティング システムのアーキテクチャに関する考慮事項

OS は、登録するディスクごとに先入れ先出し (FIFO: First In, First Out) で I/O キューを作成します。 ディスクには、スピンドル、アレイ、またはアレイ パーティションがあります。 OS が I/O を処理する方法に関しては、アクティブなキューが多いほど良好な状態です。 OS が FIFO キューをシリアル化する際には、ストレージ サブシステムに発行されたすべての FIFO I/O 要求を到着順に処理する必要があります。 OS は、スピンドルまたはアレイごとに個別の I/O キューを保持することで、ディスクが同じ希少な I/O リソースと競合するのを防ぎ、関係するディスクのみに分離されたアクティビティを保持します。 ただし、Windows Server 2008 では、I/O 優先度設定という形の例外が導入されました。 低優先度の I/O を使用するように設計されたアプリケーションは、OS がいつ受け取ったかに関係なく、キューの最後尾に移動されます。 優先順位の低い設定を使用するようにコード化されていないアプリケーションは、代わりに既定で通常の優先度に設定されます。

シンプルなストレージ サブシステムの概要

このセクションでは、単純なストレージ サブシステムについて説明します。 まず、例として、コンピューター内の 1 つのハード ドライブを見てみましょう。 このシステムを主要なストレージ サブシステム コンポーネントに分解すると、次のようになります。

• 10,000 RPM Ultra Fast SCSI HD (Ultra Fast SCSI には 20 MBps 転送レートがあります)
• SCSI バス 1 × 1 (ケーブル)
• Ultra Fast SCSI アダプター × 1
• 1 つの 32 ビット 33MHz PCI バス

コンポーネントを特定したら、システムで転送できるデータ量と処理できる I/O 量がわかってきます。 I/O の量とシステムを通過できるデータの量は互いに関連していますが、同じ値ではありません。 この相関関係は、ブロック サイズと、ディスク I/O がランダムかシーケンシャルかによって異なります。 システムはすべてのデータをブロックとしてディスクに書き込みますが、アプリケーションによってブロック サイズが異なる場合があります。

次に、これらの項目をコンポーネントごとに分析してみましょう。

ハード ドライブのアクセス時間

平均 10,000 RPM ハード ドライブのシーク時間は 7 ミリ秒で、アクセス時間は 3 ミリ秒です。 シーク時間とは、読み取りまたは書き込みヘッドがプラッター上の特定の位置に移動するまでにかかる平均時間です。 アクセス時間とは、ヘッドが正しい位置に移動してから、ディスクにデータを読み書きするためにかかる平均時間です。 したがって、10,000 RPM HD で一意のデータ ブロックを読み取るための平均時間には、データ ブロックあたり合計約 10 ミリ秒 (0.010 秒) のシーク時間とアクセス時間の両方が含まれます。

すべてのディスク アクセスでヘッドをディスク上の新しい位置に移動する必要がある場合、読み取りまたは書き込みの動作はランダムと呼ばれます。 すべての I/O がランダムである場合、10,000 RPM の HD では 1 秒あたり約 100 回の I/O (IOPS) を処理できます。

すべての I/O をハード ドライブ上の隣接セクターで行う場合、これをシーケンシャル I/O と呼びます。 シーケンシャル I/O では、余分なシーク時間は発生しません。 最初の I/O が完了すると、読み取り/書き込みヘッドは既に次のデータ ブロックに配置されます。 たとえば、10,000 RPM の HD では、次の式に基づいて、1 秒あたり約 333 回の I/O を処理できます。

1 秒あたり 1000 ミリ秒÷ I/O あたり 3 ミリ秒

ここまでの説明で、ハード ドライブの転送速度は、この例には関係ありません。 ハード ドライブのサイズに関係なく、10,000 RPM HD で処理できる IOPS の実際の量は、常に約 100 回のランダムまたは 300 シーケンシャル I/O です。 ドライブに書き込みを行うアプリケーションによってブロック サイズが異なるため、I/O ごとに取得されるデータの量も変わります。 たとえば、ブロック サイズが 8 KB の場合、ハード ドライブからの読み取りまたはハード ドライブへの書き込みの I/O 操作は合計 800 KB になります。 ただし、ブロック サイズが 32 KB の場合、100 I/O はハード ドライブに 3,200 KB (3.2 MB) の読み取りまたは書き込みを行います。 転送されるデータの総量を SCSI 転送速度が上回る場合、転送速度を上げても変化はありません。 詳細については、次の表を参照してください。

SCSI バックプレーン

SCSI バックプレーン (この例ではリボン ケーブル) がストレージ サブシステムのスループットに与える影響は、ブロック サイズによって異なります。 I/O が 8 KB ブロック内にある場合、バスはどのくらいの I/O を処理できますか? このシナリオでは、SCSI バスは 20MBps または 20480 KB/秒です。 20480 KB/秒を 8 KB ブロックで除算すると、SCSI バスでサポートされる最大約 2500 IOPS が生成されます。

上の表に示されているように、この例のシナリオでは、スピンドルの最大値が 100 回の I/O であり、一覧に示されているどのしきい値を大幅に下回るため、バスがボトルネックになることはありません。

SCSI アダプター

システムで処理できる I/O の量を判断するには、製造元の仕様を確認する必要があります。 I/O 要求を適切なデバイスに送信するには処理能力が必要であるため、システムで処理できる I/O の量は SCSI アダプタまたはアレイ コントローラ プロセッサによって異なります。

この例のシナリオでは、システムが 1,000 回の I/O を処理できることが前提になっています。

PCI バス

PCI バスは見落とされがちなコンポーネントです。 この例のシナリオでは、PCI バスはボトルネックではありません。 ただし、システムが拡張されると、将来的にボトルネックになる可能性があります。

この例のシナリオで PCI バスが転送できるデータ量は、次の式を使用して確認できます。

32 ビット ÷バイトあたり 8 ビット × 33 MHz = 133 MBps

したがって、33 Mhz で動作する 32 ビット PCI バスが 133 MBps のデータを転送できるものとします。

66MHz 64 ビット PCI バスは、次の式に基づいて理論上最大 528 MBps をサポートできます。

64 ビット ÷ 8 ビット/バイト × 66Mhz = 528MBps

別のデバイス (ネットワーク アダプターや 2 つ目の SCSI コントローラーなど) を追加すると、システムで使用できる帯域幅が減少します。 バス上のすべてのデバイスは、その帯域幅を共有し、各新しいデバイスは限られた処理リソースを競合します。

ストレージ サブシステムを分析してボトルネックを特定する

このシナリオでスピンドルは、要求できる I/O の量を制限する要因になっています。 結果として、システムが送信できるデータ量もこのボトルネックにより制限されます。 この例は AD DS シナリオであるため、送信可能なデータの量は 8 KB 単位で 1 秒あたり 100 ランダム I/O であり、Jet データベースにアクセスすると合計 800 KB/秒になります。 これに対し、ログ ファイル専用のスピンドルでは、1 秒あたり最大 300 の 8 KB の連続 I/O を提供できます。 1 秒あたり 2,400 KB (2.4 MB) です。

構成例のコンポーネントを分析できたところで、ストレージ サブシステムのコンポーネントを追加および変更するときにボトルネックが発生する可能性がある箇所を下の表を見てみましょう。

RAID の概要

アレイ コントローラーをストレージ サブシステムに導入しても、その性質が劇的に変わるわけではありません。 計算の際に SCSI アダプタがアレイ コントローラーに置き換わるのみです。 ただし、使用するアレイ レベルが異なると、ディスクへのデータの読み取りと書き込みのコストが変わります。

RAID 0 では、データを書き込むと、RAID セット内のすべてのディスクにデータがストライプ化されます。 読み取りまたは書き込みの操作中、システムは各ディスクからのデータのプルや、各ディスクへのプッシュを行うため、この期間中にはシステムが送信できるデータ量が増加します。 したがって、この例では 10,000 RPM ドライブを使用しています。RAID 0 を使用すると、100 個の I/O 操作を実行できます。 システムがサポートする I/O の合計量は、スピンドル数 (N) に、スピンドルあたり 1 秒に 100 回の I/O を掛けた値、つまり N 個のスピンドル × 1 秒あたり 100 回の I/O/秒 (スピンドルあたり) です。

RAID 1 では、冗長性を確保するために、システムは 1 組のスピンドル間でデータをミラーリング (複製) します。 システムが読み取り I/O 操作を実行する際には、セット内の両方のスピンドルからデータを読み取ることができます。 このミラーリングにより、読み取り操作中に両方のディスクの I/O キャパシティが使用可能になります。 ただし、書き込まれたデータも 1 組のスピンドルでミラーリングする必要があるため、RAID 1 での書き込み操作にパフォーマンス上の利点はありません。 ミラーリングによって書き込み操作にかかる時間が長くなることはありませんが、システムが同時に複数の読み取り操作を行うことはできなくなります。 このため、個々の書き込み I/O 操作ごとに、2 回の読み取り I/O 操作のコストがかかります。

このシナリオで発生する I/O 操作の数を計算するには、次の式を使用できます。

読み取り I/O + 2 × 書き込み I/O = 消費された使用可能なディスク I/O の合計

読み取りと書き込みの比率と展開内のスピンドル数がわかれば、アレイでサポートされる I/O の量を次の式で計算できます。

スピンドルあたりの最大 IOPS × 2 スピンドル × [(読み取り % + 書き込み %) ÷ (読み取り % + 2 × 書き込み %)] = 合計 IOPS

RAID 1 と RAID 0 の両方を使用するシナリオでは、読み取りおよび書き込み操作のコストは RAID 1 とまったく同じようにかかります。 ただし、I/O はミラー化されたセットごとにストライピングされるようになりました。 これは、数式が次の値に変化することを意味します。

スピンドルあたりの最大 IOPS × 2 スピンドル × [(読み取り % + 書き込み %) ÷ (読み取り % + 2 × 書き込み %)] = 合計 I/O

RAID 1 セットで、N 個の RAID 1 セットをストライプ化すると、アレイが処理できる合計 I/O は N × RAID 1 セットあたりの I/O になります。

N × {スピンドルあたりの最大 IOPS × 2 スピンドル × [(読み取り % + 書き込み %) ÷ (読み取り % + 2 × 書き込み %)]} = 合計 IOPS

RAID 5 は、システムが N 個のスピンドルにデータをストライプ化し、+ 1 個のスピンドルにパリティ情報を書き込むため、N + 1 RAID と呼ばれることもあります。 ただし、RAID 5 では、書き込み I/O の実行時に、RAID 1 や RAID 1 + 0 よりも多くのリソースが使用されます。 RAID 5 では、オペレーティング システムがアレイに書き込み I/O を送信するたびに、以下のプロセスが実行されます。

1. 古いデータの読み取り。
2. 古いパリティの読み取り。
3. 新しいデータの書き込み。
4. 新しいパリティの書き込み。

OS がアレイ コントローラに送信するすべての書き込み I/O 要求に対し、完了するまでに 4 回の I/O 操作が必要になります。 したがって、N + 1 RAID の書き込み要求では、完了するまでに読み取り I/O の 4 倍の時間がかかります。 つまり、OS からの I/O 要求の数を、スピンドルが受け取る要求の数に変換するには、次の式を使用できます。

読み取りI/O + 4 × 書き込み I/O = 合計 I/O

RAID 1 の場合、読み取り/書き込み比率とスピンドルの数がわかったら、次の式を使用して、アレイでサポートされている I/O の合計を見積もることができます。

スピンドルあたりの IOPS × (スピンドル – 1) × [(読み取り % + 書き込み %) ÷ (読み取り % + 4 × 書き込み %)] = 合計 IOPS

SAN の概要

ストレージ エリア ネットワーク (SAN) を環境に導入しても、ここまでのセクションで説明した計画の原則には影響しません。 ただし、SAN によって、接続されているすべてのシステムの I/O 動作が変わる可能性があることを考慮する必要があります。 SAN は、内部ストレージまたは直接接続ストレージと比較して冗長性を追加します。 フォールト トレランスを計画する必要があります。 1 つ以上のパス、コントローラー、またはシェルフが、他の部分のターゲット使用率を超えない範囲で故障する可能性があると仮定します。 また、システムに導入するコンポーネントが増えた場合は、そのような新しい部分も計算に組み込む必要があります。

それでは、SAN をコンポーネントに分解してみましょう。

• SCSI またはファイバー チャネル ハード ドライブ
• ストレージ ユニット チャネル バックプレーン
• ストレージ ユニットの本体
• ストレージ コントローラー モジュール
• 1 つ以上の SAN スイッチ
• 1 つ以上のホスト バス アダプター (HBA)
• 周辺機器相互接続 (PCI) バス

冗長性を考慮してシステムを設計する場合は、元のコンポーネントの 1 つ以上が動作しなくなる危機的な状況においてもシステムが動作し続けるように、追加のコンポーネントを含める必要があります。 ただし、キャパシティ プランニングを行う場合は、システムのベースライン キャパシティを正確に見積もるために、使用可能なリソースから冗長コンポーネントを除外する必要があります。これらのコンポーネントは通常、緊急事態が発生しない限りオンラインにならないためです。 たとえば、SAN に 2 つのコントローラー モジュールがある場合、元のモジュールが動作を停止しない限り、もう 1 つのモジュールが稼働状態にならないため、使用可能な合計 I/O スループットを計算するときは 1 つのモジュールのみを使用する必要があります。 冗長 SAN スイッチ、ストレージ ユニット、またはスピンドルも I/O の計算に含めないでください。

また、キャパシティ プランニングではピーク時の使用量のみが考慮されるため、使用可能なリソースとして冗長コンポーネントをカウントしないでください。 バーストやその他の異常なシステム動作に対応するには、ピーク使用率をシステムの飽和状態の 80% を超えないようにします。

SCSI またはファイバー チャネル ハード ドライブの動作を分析する場合は、これまでのセクションで説明した原則に従って分析する必要があります。 各プロトコルにはそれぞれ長所と短所がありますが、ディスク単位でのパフォーマンスを制限する主な要因は、ハード ドライブの機械的な制限です。

ストレージ ユニットのチャネルを分析する場合は、SCSI バスで使用可能なリソースの数を計算するときに行ったのと同じアプローチを取る必要があります。帯域幅をブロック サイズで除算します。 たとえば、ストレージ ユニットに 6 つのチャネルがあり、それぞれが 20 MBps の最大転送レートをサポートしている場合、使用可能な I/O とデータ転送の総量は 100 MBps です。 20MBps の 6 つのチャネルは、それぞれ理論上 120 MBps を提供します。 計画スループットは 100 MBps (N+1 設計) に制限されています。 1 つのチャネルで障害が発生した場合でも、残りの 5 つ (5 × 20MBps) は必要な 100MBps を提供します。 また、この例では、システムが負荷とフォールト トレランスをすべてのチャネルに均等に分散していることを前提としています。

前の例を I/O プロファイルに変換できるかどうかは、アプリケーションの動作によって異なります。 Active Directory Jet I/O の場合、最大値は 1 秒あたり約 12,500 I/O、または I/O あたり 100 MBps ÷ 8 KB です。

コントローラー モジュールでサポートされるスループットを知るには、製造元の仕様も確認する必要があります。 この例では、SAN にはそれぞれ 7,500 I/O をサポートする 2 つのコントローラー モジュールがあります。 冗長構成を使用していない場合、システム全体のスループットは 15,000 IOPS になります。 ただし、冗長構成が必要なシナリオでは、1 台のみのコントローラーの上限 (7,500 IOPS) に基づいて最大スループットを計算します。 ブロック サイズが 4 KB であると仮定すると、このしきい値は、ストレージ チャネルがサポートできる最大 12,500 IOPS を大幅に下回るため、分析のボトルネックになります。 ただし、プランニングの目的では、計画する必要がある最大 I/O は 10,400 回の I/O です。

データがコントローラ モジュールから離れると、1GBps または 128MBps で評価されたファイバー チャネル接続が送信されます。 この量は、すべてのストレージ ユニット チャネルで 100MBps の合計帯域幅を超えるため、システムのボトルネックにはなりません。 通常の操作中にトラフィックを伝送するのは、2 つのファイバー チャネル パスのいずれか 1 つだけです。もう 1 つのパスは冗長性のために予約されています。 アクティブ パスが失敗した場合、スタンバイ パスが引き継ぎます。 データの完全な読み込みを処理するのに十分な容量があります。

その後、データは SAN スイッチを経由してサーバーに送信されます。 スイッチは、着信要求を処理して適切なポートに転送する必要があるため、処理できる I/O の量を制限します。 ただし、スイッチに関する制限は、製造元の仕様を確認しないとわかりません。 たとえば、システムに 2 つのスイッチがあり、各スイッチが 10,000 IOPS を処理できる場合、合計スループットは 20,000 IOPS です。 フォールト トレランスの規則に基づいて、1 つのスイッチが機能しなくなった場合、システムの合計スループットは 10,000 IOPS になります。 このため、通常の状況では、80% の使用率 (8,000 I/O) を超えて使用しないでください。

最後に、サーバーに設置した HBA によっても、処理できる I/O の量が制限されます。 冗長性のためにさらに HBA をインストールします。 容量を計算するときは、冗長 HBA を除外します。 1 つの HBA がオフライン (N から 1) であり、残りの 1 つ以上のアクティブ HBA で使用可能な I/O の合計サイズを計画します。

キャッシュに関する考慮事項

キャッシュは、ストレージ システム内のあらゆる箇所で全体的なパフォーマンスに大きな影響を与えるコンポーネントの 1 つです。 ただし、この記事では、キャッシュ アルゴリズムの詳細な分析についての説明を控えます。 代わりに、ディスク サブシステムでのキャッシュについて知っておくべきことの簡単な一覧を次に示します。

• キャッシュを使用すると多数の小さな書き込み操作が大きな I/O ブロックにバッファリングされるため、持続的なシーケンシャル書き込み I/O が向上します。 また、多数の小さなブロックではなく、いくつかの大きなブロック内のストレージに対する操作をデステージします。 この最適化により、ランダム I/O 操作とシーケンシャル I/O 操作の合計回数が減り、他の I/O 操作に使用できるリソースが増えます。
• キャッシングでは、スピンドルがデータをコミットできる状態になるまで書き込みをバッファリングしておくだけなので、ストレージ サブシステムで書き込み I/O スループットが継続的に向上することはありません。 スピンドルからのすべての利用可能な I/O がデータによって長時間飽和状態になると、キャッシュは最終的にいっぱいになります。 キャッシュを空にするには、追加のスピンドルを提供するか、遅れを取り戻せるようにバースト間に十分な時間を確保することで、キャッシュが自然にクリアされるように十分な I/O を提供する必要があります。
• キャッシュが大きいほど、バッファリングできるデータ量が増えるため、より長い期間の飽和状態をキャッシュが処理できるようになります。
• 一般的なストレージ サブシステムでは、システムはデータをキャッシュに書き込むだけでよいため、OS の書き込みパフォーマンスはキャッシュによってが向上します。 ただし、基盤となるメディアが I/O 操作で飽和状態になると、キャッシュがいっぱいになり、書き込みパフォーマンスは通常のディスク速度に戻ります。
• 読み取り I/O をキャッシュする場合、キャッシュを最大限に役立てるには、キャッシュで先読みできるように、データをデスク上に順番に保存します。 先読みとは、次に要求されるデータが次のセクターに含まれていると想定し、キャッシュをすぐに次のセクターに移動できることです。
• 読み取り I/O がランダムである場合、ドライブ コントローラーでキャッシングを使用しても、ディスクで読み取り可能なデータ量は増加しません。 OS またはアプリケーション ベースのキャッシュ サイズがハードウェア ベースのキャッシュ サイズよりも大きい場合、ディスクの読み取り速度を向上させようとしても何も変わりません。
• Active Directory では、キャッシュはシステムに搭載されている RAM の量によってのみ制限されます。

SSD に関する考慮事項

ソリッド ステート ドライブ (SSD) は、スピンドル ベースのハード ディスクとは根本的に異なります。 SSD の方が短い待ち時間で大量の I/O を処理できます。 SSD はギガバイトあたりのコストベースでコストがかかる場合もありますが、I/O 単位のコストで安価です。 SSD を使用した容量計画では、スピンドルと同じ主要な質問が引き続き発生します。処理できる IOPS の数と、それらの IOPS の待機時間はどれくらいですか?

SSD を計画する際に考慮すべき点を次に示します。

• IOPS と待機時間はどちらも、製造元の設計に依存します。 場合によっては、特定の SSD 設計の方が、スピンドルベースのテクノロジよりもパフォーマンスが低いこともあります。 各 SSD またはスピンドル モデルのベンダー仕様を検証します。パフォーマンスと待機時間は設計によって異なります。 すべての SSD またはすべてのスピンドルを同等として扱う必要はありません。 モデルごとの IOPS、待機時間、耐久性、キューの深さの動作、ファームウェアの機能を比較します。
• IOPS の種類によって、読み取りか書き込みかで値が異なる場合もあります。 AD DS サービスは主に読み取りベースであるため、他のアプリケーション シナリオと比較して、どの書き込みテクノロジを使用するかによる影響が少なくなります。
• 書き込み耐久性は、SSD セルの寿命が限られており、頻繁に使用すると最終的に摩耗するという前提に基づいています。 データベース ドライブの場合、主に読み取りの I/O プロファイルによってセルの書き込み耐久性が拡張され、書き込み耐久性についてそれほど心配する必要がなくなります。

まとめ

共有ストレージの競合は、複数の独立したワークロードが、同じ基になるメディアまたは相互接続上の 1 秒あたりの制限付き I/O 操作 (IOPS) と帯域幅を競合する場合に発生します。 一般的な競合ソースは次のとおりです。

• 同じ SAN LUN を使用する複数のサーバー
• 同じ NAS ボリューム上に仮想ディスクが存在する複数の VM
• 共有ファブリック経由で一般的な iSCSI ターゲットにアクセスするホスト

1 つのワークロードで、バックアップ、完全なウイルス対策スキャン、大規模なディレクトリ列挙、一括エクスポートまたはインポート タスクなど、持続的な高 I/O が生成される場合、その共有リソースのすべてのコンシューマーに対する読み取り操作と書き込み操作の平均待機時間と末尾待機時間が長くなります。 NTDS.ditまたはログ I/O がデバイス キューで待機する必要がある場合、待機時間を長くすると、AD DS の応答性が直接低下します。

推奨される修復ワークフロー:

1. 測定: ピーク時間帯とメンテナンス時間帯をカバーしつつ、15～60分間隔でLogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read、Avg Disk sec/Write、Reads/sec、Writes/sec、およびストレージアレイの統計（キューの深さ、コントローラー使用率）を収集します。

2. 属性: 待機時間の急増の原因となっているワークロードを特定します (バックアップ ウィンドウ、ウイルス対策スキャン、バッチ ジョブ、または VM 近隣アクティビティと関連付けます)。 使用可能な場合は、LUN ごとまたは VM ごとのメトリックを使用します。

3. 問題の種類を分類する:

   • 容量の飽和 (IOPS またはスループットは、デバイス/コントローラーの仕様に一貫して近く、待機時間が増加します)。
   • バースト干渉 (短い高強度タスクによってテール待機時間が増加しますが、平均使用率は増加しません)。
   • インフラストラクチャ のチョークポイント (オーバーサブスクライブされた HBA、スイッチ、使用可能なレーンを減らすパス フェールオーバー、古いドライバー/ファームウェア、不適切なマルチパス ポリシー)。

4. 行為：

   • LUN、ボリューム、ストレージ層を分離するために、負荷の高いワークロードを再調整または分離します。
   • AD DS のピーク認証/クエリ期間外に、バックアップ、完全なウイルス対策スキャン、デフラグを調整または再スケジュールしてください。
   • 継続的な使用量が高いままの場合は、ストレージ コンポーネントを追加またはアップグレードします。
   • ドライバー/ファームウェアとマルチパス ソフトウェアが最新で正しく構成されていることを確認します。
   • RAM のサイズが適切なため、頻繁にアクセスされるデータがメモリ内に存在するため、ストレージの読み取り負荷が軽減されます。

5. 検証: 変更後の待機時間がターゲット (たとえば、2 ~ 6 ミリ秒の SSD/NVMe、4 ~ 12 ミリ秒のスピンドル) に戻り、キューのピーク深度が許容範囲内にあることを確認します。

記憶域の競合を模倣または悪化させる可能性のあるチョークポイントには、オーバーサブスクライブされたスイッチや、レーンを共有するホスト バス アダプターが含まれます。

ディスクを追加したり、より高速なメディアに移動したりする前に、これらを確認して除外してください。

待ち時間データをキューの長さとデバイス/コントローラーの使用率と常にペアリングして、最適化、再スケジュール、スケールアウトを行うかどうかを判断します。

成功の主な条件:

• AD DS のピーク負荷時に、ターゲットレイテンシ帯域内で持続的な Avg Disk sec/Read と Avg Disk sec/Write 。
• IOPS の値が平坦になることや、レイテンシが上昇する長い期間はありません。 観察された場合、これは飽和を示す可能性があります。
• 負荷の高いメンテナンス タスクは、定義されたメンテナンス期間中に実行され、運用環境の待機時間がしきい値を超える状態にプッシュされません。

スケジュールと構成の調整後にターゲットが満たされない場合は、容量の拡張またはより高パフォーマンスのストレージ層への移行に進みます。

付録 D: RAM を追加できない環境でのストレージのトラブルシューティング

仮想化ストレージ以前には、ストレージのレコメンデーションの多くは、次の 2 つの目的に沿っていました。

• I/O を分離して、OS スピンドルのパフォーマンスの問題がデータベースと I/O プロファイルのパフォーマンスに影響しないようにする。
• AD DS ログ ファイルのシーケンシャル I/O と組み合わせることで、スピンドル ベースのハード ドライブとキャッシュにより、システムのパフォーマンスを向上させる。 シーケンシャル I/O を別の物理ドライブに分離すると、スループットも向上します。

新しいストレージ オプションでは、以前のストレージのレコメンデーションの背後にある多くの基本的な前提が当てはまらなくなりました。 iSCSI、SAN、NAS、仮想ディスク イメージ ファイルなどの仮想化ストレージ シナリオでは、多くの場合、基になる記憶域メディアが複数のホスト間で共有されます。 共有ストレージは、I/O を分離し、順次 I/O を最適化する必要がある前提を否定します。 他のホストが共有メディアにアクセスする場合は、ドメイン コントローラーへの応答性が低下する可能性があります。

ストレージ パフォーマンスの容量計画を行う場合は、次の点を考慮する必要があります。

• コールド キャッシュ状態
• ウォーム キャッシュ状態
• バックアップと復元

コールド キャッシュ状態は、ドメイン コントローラーを最初に再起動するか、Active Directory サービスを再起動したときの状態であり、このとき RAM には Active Directory データが存在しません。 ウォーム キャッシュ状態は、ドメイン コントローラーが安定した状態で動作し、データベースをキャッシュしている状態です。 パフォーマンス設計の観点では、コールド キャッシュのウォーミングは短距離走に似ていますが、完全にウォーミングされたキャッシュでのサーバー稼働はマラソンのようなものです。 これらの状態と、それらがもたらすさまざまなパフォーマンス プロファイルを定義することは重要です。キャパシティを見積もる際には、これらをどちらも考慮する必要があるためです。 たとえば、ウォーム キャッシュ状態中にデータベース全体をキャッシュするために十分な RAM があっても、コールド キャッシュ状態中のパフォーマンスを最適化するのに役立つわけではありません。

どちらのキャッシュ シナリオでも、最も重要なのは、ストレージがディスクからメモリにデータをどれだけ速く移動できるかです。 キャッシュをウォームアップすると、クエリによってデータが再利用され、キャッシュ ヒット率が上がり、ディスクにアクセスしてデータを取得する頻度が減少するため、経時的にはパフォーマンスが向上します。 その結果、ディスクへのアクセスによる、パフォーマンスへのマイナス影響も緩和されます。 パフォーマンスの低下は一時的なもので、キャッシュがウォーム状態になり、システムで許容される最大サイズに達すると通常は解消されます。

Active Directory で使用可能な IOPS を測定すると、システムがディスクからデータを取得できる速度を測定できます。 使用可能な IOPS の値は、基盤となるストレージで使用可能な IOPS の値よっても左右されます。 また、次のような例外的な状態の計画も検討する必要があります。

• 再起動後のキャッシュ ウォームアップ
• バックアップ操作
• 復元操作

これらを例外的な状態として扱います。 ピーク時以外の時間帯に実行します。 その期間と影響は現在のドメイン コントローラーの負荷によって異なります。そのため、ピーク期間外にスケジュールを設定する以外に、ユニバーサル サイズ設定規則は適用されません。

ほとんどのシナリオでは、AD DS では読み取り I/O が主であり、読み取りが 90%、書き込みが 10% の比率になります。 読み取り I/O はユーザー エクスペリエンスの一般的なボトルネックであり、書き込み I/O は書き込みパフォーマンスを低下させるボトルネックです。 NTDS.dit ファイルの I/O 操作は主にランダムであるため、キャッシュは I/O を読み取る利点を最小限に抑える傾向があります。 このため、読み取り I/O プロファイル ストレージを正しく構成することが最優先事項になります。

通常の運用条件下におけるストレージ プランニングの目標は、システムがAD DSからディスクに要求を返すまでの待ち時間を最小限に抑えることです。 未処理および保留中の I/O 操作の数は、ディスク内のパスの数以下にする必要があります。 パフォーマンス監視のシナリオでは通常、LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read カウンターを 20 ミリ秒未満にすることをお勧めします。 ネイティブ ストレージの待機時間に近い動作しきい値を設定します。 ターゲットは 2 ~ 6 ミリ秒で、高速メディア (NVMe/SSD) の場合は下端を選択し、低速レベルの場合はハイエンドを選択します。

下の折れ線グラフは、ストレージ システム内のディスク待機時間の測定を示しています。

この折れ線グラフを分析してみましょう。

• グラフの左側にある緑色の円で囲まれた領域は、負荷が 800 IOPS から 2,400 IOPS に増加しても、待機時間が 10 ミリ秒で一定であることを示しています。 この待機時間のベースラインは、使用するストレージ ソリューションの種類の影響を受けます。
• グラフの右側にある茶色で囲まれた領域は、ベースラインとデータ収集の終了との間のシステム スループットを示しています。 スループット自体は変わりませんが、待機時間が長くなります。 この領域は、要求ボリュームがストレージ システムの物理制限を超えたときの動作を示します。 要求は、ディスクが処理するまで、キューに長く滞留します。

では、このデータから何がわかるか考えてみましょう。

まず、大規模なグループのメンバーシップに対してクエリを実行するユーザーが、システムがディスクから 1 MB のデータを読み取る必要があるとします。 次の値を使用して、必要な I/O の量と操作にかかる時間を評価できます。

• 各 Active Directory データベース ページのサイズは 8 KB です。
• システムが読み取る必要のあるページの最小数は 128 です。
• したがって、図のベースライン領域では、システムがディスクからデータを読み込んでクライアントに返すには、少なくとも 1.28 秒かかります。 スループットが推奨される最大値を大きく上回る 20 ミリ秒のマークでは、プロセスには 2.5 秒かかります。

これらの数値に基づいて、次の式を使用してキャッシュのウォームアップ速度を計算できます。

1つのIOごとに8KB で2,400 IOPS

この計算を実行した後、このシナリオのキャッシュ ウォーム レートは 20MBps であると言うことができます。 つまり、システムは約 1 GB のデータベースを 53 秒ごとに RAM に読み込みます。

ストレージ システムの設計方法により、キャッシュのウォームアップ速度には物理的な制限があります。 基になるストレージが対応できる速度までキャッシュをウォームアップできるのは、受信クライアント要求だけです。 ピーク時にキャッシュの事前ウォーミングを試みるスクリプトを実行すると、実際のクライアント要求と競合し、全体的な負荷が増加し、クライアント要求に関連しないデータが読み込まれます。また、パフォーマンスが低下します。 キャッシュのウォームアップには、人為的な手段を使用しないことをお勧めします。