Configuration Manager サイトのサイズ設定とパフォーマンスに関する FAQ

Configuration Manager (現在のブランチ) に適用

このドキュメントでは、サイトのサイズ設定に関するガイダンスと一般的なパフォーマンスの問題Configuration Manager関してよく寄せられる質問に対処します。

マシンとディスクの構成に関する FAQ と例

サイト サーバーとSQL Server上のディスクをフォーマットするにはどうすればよいですか?

Configuration Manager受信トレイとSQL Server ファイルを少なくとも 2 つの異なるボリュームに分割します。 この分離により、実行するさまざまな種類の I/O に対してクラスター割り当てサイズを最適化できます。

サイト サーバーの受信トレイをホストするボリュームの場合は、4K または 8K の割り当てユニットで NTFS を使用します。 ReFS では、小さいファイルでも 64k が書き込まれます。 Configuration Managerには小さなファイルが多数含まれているため、ReFS では不要なディスク オーバーヘッドが発生する可能性があります。

SQL Server データベース ファイルを含むディスクの場合は、64K 割り当て単位で NTFS または ReFS の書式を使用します。

SQL Serverデータベース ファイルをレイアウトする方法と場所

ソリッド ステート ドライブ (SSD) と Azure Premium Storageの最新の配列では、ディスク数が少なく、単一ボリュームで高い IOPS を提供できます。 通常、追加のスループットではなく、追加のストレージ用にドライブをアレイに追加します。 物理スピンドル ベースのディスクを使用している場合は、1 つのボリュームで生成できるよりも多くの IOPS が必要になる場合があります。 推奨される IOPS とディスク領域の合計の 60% を .mdf ファイルに割り当て、 .ldf ファイルに 20%、ログおよびデータ一時ファイルに 20% を割り当てる必要があります。 .ldf ファイルと一時ファイルはすべて、割り当てられた IOPS の 40% (20% + 20%) の単一ボリュームに存在できます。

SQL Server 2016 より前のバージョンSQL Server既定で作成された一時データ ファイルは 1 つだけです。 SQL Serverロックを回避し、1 つのファイルへのアクセスを待機しないように、さらに作成する必要があります。 Community意見は、作成する一時データ ファイルの最適な数が 4 から 8 まで異なります。 テストでは、4 から 8 の間にほとんど違いがないため、4 つの等しいサイズの 一時データ ファイルを作成できます。 tempdb データ ファイルのサイズは、データベース全体の最大 20 ~ 25% である必要があります。

ディスクのセットアップに関するその他の推奨事項はありますか?

構成可能な場合は、書き込み操作に対して RAID コントローラー メモリを 70% 割り当て、読み取り操作で 30% に設定します。 一般に、サイト データベースには RAID 10 配列構成を使用します。 RAID 1 は、I/O 要件が低い小規模サイトや高速 SSD を使用する場合にも許容されます。 ディスク アレイが大きい場合は、障害が発生したディスクを自動的に置き換えるスペア ディスクを構成します。

例: 物理ディスクを含む物理マシン

100,000 のクライアントを持つ併置サイト サーバーとSQL Serverの サイズ設定ガイドラインは、サイト サーバーの受信トレイの場合は 1200 IOPS、SQL Server ファイルの場合は 5000 IOPS です。

結果のディスク構成は次のようになります。

Drives1 RAID フォーマット ボリュームの内容 必要な最小 IOPS 提供される IOPS の約 2
2x10k 1 - Windows -
6x15k 10 NTFS 8k ConfigMgr 受信トレイ 1700 1751
12x15k 10 64k ReFS SQL .mdf 60%*5000 = 3000 3476
8x15k 10 64k ReFS SQL .ldf、一時ファイル 40%*5000 = 2000 2322
  1. 推奨されるスペア ディスクは含まれません。
  2. この値は、 ディスク構成の例から取得されます

Windows サーバーで Hyper-V を使用しています。 最適なパフォーマンスを実現するために、Configuration Manager VM のディスクを構成する方法を教えてください。

ハードウェア リソース (CPU コアとパススルー ストレージ) が仮想マシン (VM) 専用の 100% の場合、Hyper-V は物理サーバーと同様のパフォーマンスを実現します。 固定サイズの .vhd または .vhdx ディスク ファイルを使用すると、最小限の 1 ~ 5% の I/O パフォーマンスへの影響が生じます。 .vhd または .vhdx ディスク ファイルを動的に拡張すると、Configuration Manager ワークロードに対して最大 25% の I/O パフォーマンスの影響が生じます。 ディスクを動的に拡張する必要がある場合は、さらに 25% の IOPS パフォーマンスをアレイに追加することで補正します。

Configuration Manager サイト サーバーまたは VM 内のSQL Serverを実行する場合は、HYPER-V ホスト OS ドライブを VM OS とデータ ドライブから分離します。

VM の最適化の詳細については、「 Hyper-V サーバーのパフォーマンス チューニング」を参照してください

例: Hyper-V VM ベースのサイト サーバー

150,000 のクライアントを持つ併置サイト サーバーとSQL Serverの サイズ設定ガイドラインは、サイト サーバーの受信トレイの場合は 1800 IOPS、SQL Server ファイルの場合は 7400 IOPS です。

結果のディスク構成は次のようになります。

Drives1 RAID Format2 ボリュームの内容 必要な最小 IOPS 提供される IOPS の約 3
2x10k 1 - Hyper-V ホスト OS - -
2x10k 1 - (VM) サイト サーバー OS - -
2xSSD SAS 1 NTFS 8k (VM) ConfigMgr 受信トレイ 1800 7539
4xSSD SAS 10 64k ReFS (VM) ホスト SQL Server (すべてのファイル) 7400 14346
  1. 推奨されるスペア ディスクは含まれません。
  2. 基になるボリューム専用の VM ドライブ用の固定サイズのパススルー .vhdx
  3. この値は、 ディスク構成の例から取得されます

Microsoft AzureのConfiguration Manager環境に関する提案はありますか?

まず、Azure でよく寄せられる質問に関するConfiguration Managerを読んでください。

Premium Storage ベースのディスクを利用する Azure サービスとしてのインフラストラクチャ (IaaS) VM は、高い IOPS を持つことができます。 これらの VM で、追加の IOPS ではなく、予想されるディスク領域のニーズに合わせて追加のディスクを構成します。

Azure Storage は本質的に冗長であり、可用性のために複数のディスクを必要としません。 Disk Manager または記憶域スペースでディスクをストライプして、追加の領域とパフォーマンスを提供できます。

Premium Storageパフォーマンスを最大化し、Azure IaaS VM でSQL サーバーを実行する方法の詳細と推奨事項については、次を参照してください。

例: Azure ベースのサイト サーバー

50,000 のクライアントを持つ併置サイト サーバーとSQL Serverの サイズ設定ガイドラインは、サイト サーバーの受信トレイの場合は 8 コア、32 GB、1200 IOPS、SQL Server ファイルの場合は 2800 IOPS です。

生成される Azure マシンは、次のディスク構成の DS13v2 (8 コア、56 GB) である可能性があります。

ドライブ フォーマット Contains 必要な最小 IOPS 約 IOPS 提供 1
<標準> - サイト サーバー OS - -
1xP20 (512 GB) NTFS 8k ConfigMgr 受信トレイ 1200 2334
1xP30 (1024 GB) 64k ReFS SQL Server (すべてのファイル 2) 2800 3112
  1. この値は、 ディスク構成の例から取得されます
  2. Azure ガイダンス では、TempDB をローカルの SSD ベースの D: ドライブに配置できます。使用可能な領域を超えず、ディスク I/O の追加配布が可能になります。

例: Azure ベースのサイト サーバー (即座にパフォーマンスを向上させる)

Azure ディスクのスループットは、VM のサイズによって制限されます。 前の Azure の例の構成では、今後の拡張や追加のパフォーマンスが制限される可能性があります。 Azure VM の初期デプロイ中にディスクを追加する場合は、今後の処理能力を高めるために Azure VM をアップサイズし、前払い投資を最小限に抑えることができます。 後でより複雑な移行を行う必要があるのではなく、要件の変更に応じてサイトのパフォーマンスを向上させる計画を立てる方がはるかに簡単です。

前の Azure の例のディスクを変更して、IOPS がどのように変化するかを確認します。

DS13v2

Drives1 フォーマット Contains 必要な最小 IOPS 提供される IOPS の約 2
<標準> - サイト サーバー OS - -
2xP20 (1024 GB) NTFS 8k ConfigMgr 受信トレイ 1200 3984
2xP30 (2048 GB) 64k ReFS SQL Server (すべての files3) 2800 3984
  1. ディスクは、記憶域スペースを使用してストライプされます。
  2. この値は、 ディスク構成の例から取得されます。 VM サイズはパフォーマンスを制限します。
  3. Azure ガイダンス では、TempDB をローカルの SSD ベースの D: ドライブに配置できます。使用可能な領域を超えず、ディスク I/O の追加配布が可能になります。

今後さらにパフォーマンスが必要な場合は、VM を DS14v2 にアップサイズできます。これにより、CPU とメモリが 2 倍になります。 その VM サイズで許可される追加のディスク帯域幅により、以前に構成したディスクで使用可能なディスク IOPS もすぐに向上します。

DS14v2

Drives1 RAID フォーマット Contains 必要な最小 IOPS 提供される IOPS の約 2
<標準> - サイト サーバー OS - -
2xP20 (1024 GB) NTFS 8k ConfigMgr 受信トレイ 1200 4639
2xP30 (2048 GB) 64k ReFS SQL Server (すべての files3) 2800 6182
  1. ディスクは、記憶域スペースを使用してストライプされます。
  2. この値は、 ディスク構成の例から取得されます。 VM サイズはパフォーマンスを制限します。
  3. Azure ガイダンス では、TempDB をローカルの SSD ベースの D: ドライブに配置できます。使用可能な領域を超えず、ディスク I/O の追加配布が可能になります。

その他の一般的なSQL Server関連のパフォーマンスに関する質問

サイト サーバーと併置されたSQL Serverで実行するか、リモート サーバーで実行することをお勧めしますか?

1 台のサーバーのサイズが適切であるか、2 台のサーバー間のネットワーク接続で十分であると仮定すると、どちらも適切に実行できます。

リモート SQL Serverには、追加のサーバーの前払いコストと運用コストが必要ですが、大規模な顧客の大半の間では一般的です。 この構成の利点は次のとおりです。

  • SQL Server Always Onなど、サイトの可用性オプションの増加
  • サイト処理に対する聞き取りが少ない重いレポートを実行する機能
  • 状況によっては、ディザスター リカバリーが簡単になります
  • セキュリティ管理の容易化
  • 別の DBA チームなど、SQL Server管理のためのロールの分離

併置SQL Serverには 1 台のサーバーが必要であり、ほとんどの小規模のお客様に一般的です。 この構成の利点は次のとおりです。

  • マシン、ライセンス、メンテナンスのコストを削減する
  • サイト内の障害点数を減らす
  • ダウンタイムを計画するためのより適切な制御

SQLに割り当てる RAM の量を教えてください。

既定では、SQL Serverはサーバーで使用可能なすべてのメモリを使用し、マシン上の OS やその他のプロセスが不足している可能性があります。 潜在的なパフォーマンスの問題を回避するには、明示的にSQL Serverにメモリを割り当てることが重要です。 SQL Serverと併置されているサイト サーバーで、OS にファイル キャッシュやその他の操作に十分な RAM があることを確認します。 SMSExec とその他のConfiguration Manager プロセスに十分な RAM が残っていることを確認します。 リモート サーバーでSQL Serverを実行する場合は、メモリの 大部分 をSQLに割り当てることができますが、すべてではありません。 最初のガイダンスについては、 サイズ設定 ガイドラインを確認してください。

SQL Serverメモリ割り当ては、GB 全体に丸める必要があります。 また、RAM が大量に増加するにつれて、SQL Serverの割合を高くすることができます。 たとえば、256 GB 以上の RAM を使用できる場合は、OS のメモリが十分に保持されるため、最大 95% のSQL Serverを構成できます。 ページ ファイルを監視することは、OS とConfiguration Managerプロセスに十分なメモリがあることを確認するのに適した方法です。

最近はコアが安い。 SQL Serverに大量のファイルを追加する必要がありますか?

SQL Serverに 16 個を超える物理コアと十分な RAM がない場合、メモリ競合の問題が発生する可能性があります。 Configuration Manager ワークロードは、コアあたり少なくとも 3 ~ 4 GB の RAM をSQLに使用できる場合に、パフォーマンスが向上します。 SQL Serverにコアを追加する場合は、必ず比例した量で RAM を増やしてください。

SQL Server Always On可用性グループはパフォーマンスに影響しますか?

一般に、可用性グループは、レプリカ サーバー間で十分なネットワークを利用できる場合、システムのパフォーマンスにほとんど影響しません。 ビジー状態の可用性グループ環境では、データベース ログ の .ldf ファイルの増加を迅速に行うことができます。 ただし、ログ ファイルの領域は、データベースのバックアップが正常に完了すると自動的に解放されます。 Configuration Manager データベースのSQL Server ジョブを追加して、たとえば 24 時間ごと、.ldf バックアップを 6 時間ごとに実行します。 SQL Serverバックアップ戦略の詳細など、可用性グループとConfiguration Managerの詳細については、「SQL Server Always On可用性グループを使用する準備」を参照してください。

データベースでSQL Server圧縮を有効にする必要がありますか?

Configuration Manager データベースでは、SQL Server圧縮はお勧めしません。 Configuration Manager データベースで圧縮を有効にしても機能上の問題はありませんが、テスト結果では、システムに大きなパフォーマンスへの影響が生じる可能性がある場合と比較して、サイズが大幅に削減されることはありません。

データベースでSQL Server暗号化を有効にする必要がありますか?

Configuration Manager データベース内のシークレットは既に安全に格納されていますが、SQL Server暗号化を追加すると、さらに別のセキュリティ層が追加される可能性があります。 データベースで暗号化を有効にしても機能上の問題はありませんが、最大 25% のパフォーマンス低下が発生する可能性があります。 そのため、特に大規模な環境では、慎重に暗号化してください。 また、バックアップと復旧の計画を更新して、暗号化されたデータを正常に回復できることを確認してください。

どのバージョンのSQL Serverを実行する必要がありますか?

サポートされているバージョンのSQLについては、「SQL Server バージョンのサポート」を参照してください。 パフォーマンスの観点から見ると、サポートされているすべてのバージョンのSQL Serverは、必要なパフォーマンス基準を満たしています。 ただし、SQL Server 2016 以降では、Configuration Manager ワークロードの一部で 2014 SQL Serverを上回る傾向があります。 また、SQL Server 2014 を SQL Server 2012 互換性レベル (110) で実行すると、一般的にパフォーマンスが向上します。 インストール時に、SQL Server 2014 で実行されているConfiguration Manager データベースは互換性レベル 110 に設定されます。 SQL Server 2016 以降は、SQL Server 2016 の場合は 130 など、SQL Server バージョンの既定の互換性レベルに設定されます。 SQL Serverをアップグレードしても、次のメジャー Configuration Manager現在のブランチ バージョンをインストールするまで互換性レベルは更新されません。

管理コンソールで RBAC を使用する場合など、SQL Server 2016 以降の特定のSQL クエリで異常なタイムアウトや速度低下が発生した場合は、Configuration Manager データベースのSQL Server互換性レベルを 110 に変更してみてください。 SQL Server 2014 以降のバージョンのSQL Serverでは、SQL Server互換性レベル 110 での実行が完全にサポートされています。 詳細については、特定のConfiguration Managerデータベース クエリでクエリのタイムアウトまたはコンソールの速度が低下するSQLに関するページを参照してください。

2018 年 1 月の時点では、パフォーマンスに関連するさまざまな問題やその他の潜在的な問題があるため、次のSQL Server バージョンは 避ける 必要があります。

  • SQL Server 2012 SP3 CU1 から CU5
  • SQL Server 2014 SP1 CU6 から SP2 CU2
  • SQL SERVER 2016 RTM から CU3、SP1 CU3 から CU5

追加のSQL Serverインデックス作成タスクを実装する必要がありますか?

はい。1 週間に 1 回の頻度でインデックスを更新し、SQL Serverパフォーマンスを向上させるために 1 日に 1 回の頻度で統計を更新します。 Configuration ManagerおよびSQL Serverコミュニティから入手できるサード パーティのスクリプトと追加情報は、これらのタスクを最適化するのに役立ちます。

大規模なサイトでは、使用パターンによっては、CICurrentComplianceStatusDetails_、HinvChangeLog などの一部のSQL Server テーブルが大きくなる場合があります。 それらのメンテナンス 方法を 1 つずつ減らすか、変更することが必要な場合があります。

セカンダリ サイトでSQL Server Expressではなく、完全なSQL Serverをいつ使用する必要がありますか?

SQL Server Expressセカンダリ サイトではパフォーマンスに大きな影響はありません。ほとんどのお客様に適しています。 また、デプロイと管理も簡単で、ほぼすべてのお客様に任意のサイズで推奨される構成です。

完全なSQL Serverインストールが必要になる場合があります。 環境内に多数の配布ポイントとパッケージまたはソースがある場合は、SQL Server Expressの 10 GB のサイズ制限を超える可能性があります。 配布ポイントの数が 4,000,000 を超えるパッケージの数 (コンテンツが 2,000 個の 2,000 個のDP など) を超える場合は、セカンダリ サイトで完全なSQL Serverを使用することを検討してください。

データベースの MaxDOP 設定を変更する必要がありますか?

ほとんどの場合、設定を 0 のままにしておく (使用可能なすべてのプロセッサを使用する) の方が、全体的な処理パフォーマンスに最適です。

多くのConfiguration Manager管理者は、SQL Serverの"最大並列処理度" 構成オプションのおすすめとガイドラインのガイダンスに従います。 最新の大規模ハードウェアでは、このガイダンスにより、推奨される最大設定が 8 に設定されます。 ただし、プロセッサの数に比べて小さいクエリを多数実行する場合は、より多くの数に設定するのに役立つ場合があります。 より多くのコアが使用可能な場合、大規模なサイトでは必ずしも 8 に制限することが最適な設定であるとは限りません。

8 コアを超えるSQL サーバーでは、0 の設定から開始し、パフォーマンスの問題や過度のロックが発生した場合にのみ変更を加えます。 パフォーマンスの問題が 0 で発生したために MaxDOP を変更する必要がある場合は、そのサイトのSQL Serverサイズ設定で推奨される最小コア数以上の新しい値から開始します。 この値より小さくなると、パフォーマンスに悪影響を及ぼす可能性がほぼ常に高くなります。 たとえば、100,000 クライアント サイトのリモート SQL Serverには、少なくとも 12 コアが必要です。 SQL Serverに 16 個のコアがある場合は、値 12 の MaxDOP 設定のテストを開始します。

その他の一般的なパフォーマンス関連の質問

サイト サーバー上のどのフォルダー (またはその他の役割) をウイルス対策ソフトウェアに対して除外する必要がありますか?

任意のシステムでウイルス対策保護を無効にする場合は注意してください。 高いボリュームとセキュリティで保護された環境では、最適なパフォーマンスを実現するために アクティブな監視 を無効にすることをお勧めします。

推奨されるウイルス対策の除外の詳細については、「Configuration Manager 2012 および Current Branch サイト サーバー、サイト システム、クライアントの推奨されるウイルス対策の除外」を参照してください。

CONFIGURATION MANAGERで WSUS を使用する場合、WSUS のパフォーマンスを向上させるにはどうすればよいですか?

WsusPool キューの長さや WsusPool プライベート メモリの制限など、いくつかの重要な IIS 設定を変更すると、小規模なインストールでも WSUS のパフォーマンスを向上させることができます。 詳細については、「 推奨されるハードウェア」を参照してください。

また、WSUS を実行しているオペレーティング システムに最新の更新プログラムがインストールされていることを確認します。

  • Windows Server 2012: 2017 年 10 月以降にリリースされた"セキュリティのみ" 以外の累積的な更新プログラム。 (KB4041690)
  • Windows Server 2012 R2: 2017 年 8 月以降にリリースされた"セキュリティのみ" 以外の累積的な更新プログラム。 (KB4039871)
  • Window Server 2016: 2017 年 8 月以降にリリースされた"セキュリティのみ" 以外の累積的な更新プログラム。 (KB4039396)

WSUS サーバーで実行する必要があるメンテナンスの種類は何ですか?

サイトの基本的なパフォーマンス監視を設定する必要があります。 何を見る必要がありますか?

従来のサーバー パフォーマンス監視は、一般的なConfiguration Managerに対して効果的に機能します。 また、Configuration Manager、SQL Server、Windows Server のさまざまなSystem Center Operations Manager 管理パックを利用して、サーバーの基本的な正常性を監視することもできます。 また、Configuration Managerが提供するWindows パフォーマンス モニター (PerfMon) カウンターを直接監視することもできます。 サイトのパフォーマンスの問題やバックログの可能性がある早期警告の兆候がないか、さまざまな受信トレイのバックログを監視します。