サイトのサイズとパフォーマンスのガイドラインをConfiguration Managerする
Configuration Manager (現在のブランチ) に適用
Configuration Managerは、業界の規模とパフォーマンスをリードしています。 その他のドキュメントでは、 サポートされている最大スケール制限 と、最大の環境サイズでサイトを実行するための ハードウェア ガイドライン について説明します。 この記事では、すべてのサイズの環境に関する補足的なパフォーマンス ガイダンスを提供します。 このガイダンスは、Configuration Managerのデプロイに必要なハードウェアをより正確に見積もるのに役立ちます。
この記事では、ディスクの入出力サブシステムまたは IOPS というパフォーマンスのボトルネックConfiguration Manager最大の要因について説明します。
- IOPS に焦点を当てた詳細とテスト結果を表示します
- 独自の環境とハードウェアを使用してテストを再現する方法について説明します
- さまざまなサイズ環境のディスク IOPS 要件を提案する
パフォーマンス テスト手法
Configuration Managerはさまざまな方法でデプロイできますが、サイズ設定に関するディスカッションではいくつかの変数を理解しておくことが重要です。 1 つの変数は、在庫サイクルなどの 特徴間隔です。 もう 1 つの変数は、システムが参照または展開するユーザー、ソフトウェア展開、またはその他の オブジェクト の数です。 パフォーマンス テストでは、これらの変数が 負荷の一部として適用されます。 この負荷により、さまざまなサイズの環境で運用環境のデプロイを使用している企業のお客様に対して、一般的な速度でオブジェクトが生成されます。
注:
顧客使用状況データを使用すると、ほとんどの顧客に最も一般的なシナリオ、構成、設定を使用して、現在のブランチ ビルドをテストできます。 この記事の推奨事項は、これらの平均に基づいています。 エクスペリエンスは、環境のサイズと構成によって異なる場合があります。 一般に、Configuration Managerオブジェクトと間隔に関しては常識が必要です。 システム上のすべてのファイルを収集したり、サイクルの間隔を 1 分に設定したりできるからといって、そうする必要はありません。
次のセクションでは、大企業の処理ニーズをテストおよびモデリングするときに使用する主要な設定と構成について説明します。 これらのガイドラインは、推奨されるハードウェア サイズに対する基本的なシステム パフォーマンスの期待を設定するのに役立ちます。
機能間隔の設定
ほとんどのテストでは、システム内のキー サイクルに既定の間隔を使用する必要があります。 たとえば、ハードウェア インベントリ テストは、既定の .mof ファイルよりも大きい週に 1 回行われます。 一部の定期的な機能間隔 (特にハードウェアとソフトウェアのインベントリ サイクル) は、環境のパフォーマンス特性に大きな影響を与える可能性があります。 データ収集に対して積極的な既定の間隔を有効にする環境では、アクティビティの増加に直接比例して、サイズの大きいハードウェアが必要です。 たとえば、25,000 台のデスクトップ クライアントがあり、ハードウェア インベントリを既定の間隔の 2 倍速く収集するとします。 まず、50,000 人のクライアントがあるかのようにサイトのハードウェアのサイズを設定します。
オブジェクト
テストでは、大企業がシステムで使用する傾向があるオブジェクトの 上位平均 を使用する必要があります。 一般的な値は何千ものコレクションとアプリケーションであり、何十万人ものユーザーまたはシステムにデプロイされます。 テストは、これらの制限でシステム 内のすべての オブジェクトで同時に実行する必要があります。 多くのお客様は複数の機能を使用していますが、一般に、これらの上限で製品のすべての機能を使用しているわけではありません。 すべての製品機能を使用したテストは、システム全体のパフォーマンスを最大限に高めるのに役立ち、一部のお客様が平均を超えて使用する可能性がある機能のバッファーを可能にします。
負荷
テストは、システムにピーク時の使用量要求を生成するシミュレーションを実行することで、標準 の平均日 の負荷を超える場合にも実行する必要があります。 たとえば、パッチ火曜日のロールアウトをシミュレートして、ピーク時のこれらの日にシステムが更新プログラムのコンプライアンス データを迅速に返すことができることを確認します。 もう 1 つの例として、広範囲にわたるマルウェアの発生中のサイト アクティビティをシミュレートして、タイムリーな通知と対応を可能にします。 推奨サイズのデプロイされたマシンは、特定の日に使い過ごされる可能性がありますが、より極端な状況では処理バッファーが必要です。
構成
サポートされているオペレーティング システムとSQL Server バージョンを組み合わせて、さまざまな物理ハードウェア、Hyper-V ハードウェア、Azure ハードウェアでテストを実行します。 サポートされている構成の最悪のケースを常に検証します。 一般に、Hyper-V と Azure は、同様に構成されている場合、同等の物理ハードウェアに同等のパフォーマンス結果を返します。 現在のサーバー オペレーティング システムのパフォーマンスは、以前の OS バージョン以上である傾向があります。 サポートされているすべてのプラットフォームが最小要件を満たしていますが、通常、Windows や SQL Server などのサポート製品の最新バージョンでは、パフォーマンスがさらに向上します。
最大のバリエーションは、使用中のSQL Serverバージョンから来ています。 SQL Serverバージョンの詳細については、「実行する必要があるSQL Serverのバージョン」を参照してください。
主要なパフォーマンス決定要因
さまざまな種類の設定、さまざまな方法、および異なるサイト サイズで、Configuration Managerパフォーマンスをテストおよび測定できます。 次の設定とオブジェクトは、パフォーマンスに大きく影響する可能性があります。 環境でのパフォーマンスのテストとモデリングを行うときは、必ず考慮してください。
注意
Configuration Managerのいくつかの側面は、過剰な使用を防ぐ公式の最大値またはユーザー インターフェイスの制限を持ちますが、ガイドラインを超えると、サイトのパフォーマンスに大きな悪影響を与える可能性があります。 推奨レベルを超えたり、サイズ設定ガイダンスを無視したりするには、通常、より大きなハードウェアが必要であり、さまざまなオブジェクトの頻度または数を減らすまで環境を維持できなくなる可能性があります。
ハードウェア インベントリ
ベースライン パフォーマンスをテストするには、ハードウェア インベントリ収集を週に 1 回に設定し、既定の .mof ファイル サイズに約 20% の他のプロパティを追加します。 すべてのプロパティを有効にせず、実際に必要なプロパティのみを収集してください。 使用可能な仮想メモリなど、インベントリ サイクルごとに常に変更されるプロパティを収集する場合は、特に注意してください。 これらのプロパティを収集すると、すべてのクライアントからインベントリ サイクルごとに過剰なチャーンが発生する可能性があります。
ソフトウェア インベントリ
ベースライン パフォーマンスをテストするには、ソフトウェア インベントリ収集を 1 週間に 1 回に設定し、 製品のみの 詳細を使用します。 多数のファイルを収集すると、インベントリ サブシステムに大きな負担が及ぶ可能性があります。 や *.dllなど*.exe、多数のクライアント間で何千ものファイルを収集する可能性があるフィルターを指定しないでください。
コレクション
ベースライン パフォーマンス テストには、スコープ、サイズ、複雑さ、および更新設定の種類が異なる数千のコレクションを含めることができます。 サイトのパフォーマンスは、サイト上の膨大な数のコレクションの直接的な機能ではありません。 パフォーマンスは、コレクションのクエリの複雑さ、完全および増分更新と変更頻度、コレクション間の依存関係、コレクション内のクライアントの数のクロス積でもあります。
可能であれば、高価な動的ルール クエリまたは複雑な動的ルール クエリを含むコレクションを最小限に抑えます。 これらの種類の規則を必要とするコレクションの場合は、適切な更新間隔と更新時間を設定して、システムでのコレクションの再評価の影響を最小限に抑えます。 たとえば、午前 8 時ではなく午前 0 時に更新します。
コレクションで増分更新を有効にすると、コレクション メンバーシップを迅速かつタイムリーに更新できます。 ただし、増分更新は効率的ですが、引き続きシステムに負荷がかけられます。 予想される変更頻度と、メンバーシップに関するほぼリアルタイムの更新の必要性のバランスを取る。 たとえば、コレクション メンバーでは大きなチャーンが予想されますが、ほぼリアルタイムのメンバーシップ更新は必要ないとします。 増分更新を有効にするよりも、より効率的で、スケジュールされた完全更新でコレクションを更新するシステムの負荷が少なくなります。
増分更新を有効にする場合は、同じコレクションでスケジュールされた完全更新を減らします。 増分更新ではコレクション メンバーシップをほぼリアルタイムで更新する必要があるため、これらは評価のバックアップ方法にすぎません。 コレクションのベスト プラクティス では、増分更新のコレクションの合計数を最大数にすることをお勧めしますが、記事で説明しているように、エクスペリエンスはさまざまな要因によって異なる場合があります。
直接メンバーシップ ルールのみを使用し、増分更新を実行していない制限コレクションを持つコレクションでは、スケジュールされた完全な更新は必要ありません。 これらの種類のコレクションの更新スケジュールを無効にして、システムへの不必要な負荷を防ぎます。 制限コレクションで増分更新が使用されている場合、直接メンバーシップ 規則のみを持つコレクションには、最大 24 時間、またはスケジュールされた更新が行われるまでメンバーシップの更新が反映されない可能性があります。
ベスト プラクティスではありませんが、一部の組織では、さまざまなビジネス プロセスの一部として数百または数千のコレクションを作成します。 オートメーションを使用してコレクションを作成する場合は、必要な増分更新を正しく有効にすることが重要です。 コレクション評価のホット スポットを 1 つの期間に回避するために、更新スケジュール全体を最小限に抑え、分散します。 未使用のコレクションを削除する通常のグルーミング プロセスを確立します。特に、しばらくしてから不要になったコレクションを自動的に作成する場合。
Configuration Managerは、展開などのタスクを対象にするときに、コレクション内のすべてのオブジェクトのポリシーを作成します。 メンバーシップの変更は、スケジュールされた更新または増分更新によって、システム全体に対してはるかに多くの作業を作成できます。 最新の現在のブランチ ビルドでは、すべてのシステムとすべてのユーザー コレクションに対して特別なポリシーの最適化が行われます。 エンタープライズ全体を対象とする場合は、これらの組み込みコレクションの複製ではなく、組み込みのコレクションを使用します。
コレクションのパフォーマンスをさらに深く調査するには、コンソールでコレクションの評価を表示します。 詳細については、「 コレクションの評価を表示する方法」を参照してください。
検出方法
ベースライン パフォーマンス テストの場合は、サーバー ベースの検出方法を週に 1 回実行し、必要に応じて差分検出を有効にして、1 週間にデータを最新の状態に保ちます。 テストでは、シミュレートされたエンタープライズ サイズに比例するオブジェクト数量を検出する必要があります。 ハートビート検出のパフォーマンス ベースライン テストも週に 1 回実行する必要があります。
検出データはグローバル データです。 パフォーマンスに関連する一般的な問題は、階層内のサーバー ベースの検出方法を誤って構成し、複数のプライマリ サイトから同じリソースが重複して検出される問題です。 複数のプライマリ サイトで同じ検出スコープが重複しないようにしながら、Active Directory ドメイン コントローラーなどのターゲット サービスとの通信を最適化するために、探索方法を慎重に構成します。
一般的なサイズ設定ガイドライン
前の パフォーマンス テスト手法に基づいて、次の表に、特定の数のマネージド クライアントに関する一般的な 最小 ハードウェア要件ガイドラインを示します。 これらの値を使用すると、指定した数のクライアントを持つほとんどのお客様が、指定したサイトを管理するのに十分な速さでオブジェクトを処理できます。 コンピューティング能力は毎年価格が下がり続け、最新のサーバー ハードウェア構成では以下の要件の一部が小さくなります。 次のガイドラインを超えるハードウェアは、処理能力が必要なサイトや特別な製品の使用パターンを持つサイトのパフォーマンスを比例的に向上させます。
| デスクトップ クライアント | サイトの種類/ロール | コア 注 1 | メモリ (GB) | SQL Serverメモリ割り当て注 2 | IOPS: 受信トレイ 注 3 | IOPS: SQL Server注 3 | 必要な記憶域 (GB) 注 4 |
|---|---|---|---|---|---|---|---|
| 25k | 同じサーバー上のデータベース サイト ロールを持つプライマリまたは CAS | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25k | プライマリまたは CAS | 4 | 8 | 600 | 100 | ||
| リモート SQL Server | 4 | 16 | 70% | 1700 | 250 | ||
| 50k | 同じサーバー上のデータベース サイト ロールを持つプライマリまたは CAS | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50k | プライマリまたは CAS | 4 | 8 | 1200 | 200 | ||
| リモート SQL Server | 8 | 24 | 70% | 2800 | 400 | ||
| 100k | 同じサーバー上のデータベース サイト ロールを持つプライマリまたは CAS | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100k | プライマリまたは CAS | 6 | 12 | 1200 | 300 | ||
| リモート SQL Server | 12 | 48 | 80% | 5000 | 800 | ||
| 150k | 同じサーバー上のデータベース サイト ロールを持つプライマリまたは CAS | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150k | プライマリまたは CAS | 8 | 16 | 1800 | 400 | ||
| リモート SQL Server | 16 | 72 | 90% | 7400 | 1200 | ||
| 700k | 同じサーバー上のデータベース サイトロールを持つ CAS | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700k | Ca | 8+ | 16+ | 1800+ | 500+ | ||
| リモート SQL Server | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5k | セカンダリ サイト | 4 | 8 | 500 | - | 200 | |
| 15k | セカンダリ サイト | 8 | 16 | 500 | - | 300 |
一般的なサイズ設定ガイドラインに関する注意事項
注 1: コア
Configuration Managerは多数の同時プロセスを実行するため、さまざまなサイト サイズに対して一定の最小数の CPU コアが必要です。 コアの速度は毎年速くなりますが、一定の最小コア数が並列に動作することを確認することが重要です。 一般に、2015 以降に生成されたサーバー レベルの CPU は、テーブルで指定されたコアの基本的なパフォーマンス ニーズを満たします。 Configuration Managerは、推奨事項を超えて他のコアを利用します。 推奨される最小コア数を取得したら、CPU リソースの投資に優先順位を付けて、既存のコアの速度を向上させます。 より遅いコアを追加しないでください。 たとえば、Configuration Managerは、24 個の低速コアを使用する場合よりも、16 個の高速コアを持つキー処理タスクのパフォーマンスが向上します。 このパフォーマンスは、ディスク IOPS などの他の十分なシステム リソースがあることを前提としています。
コアとメモリの関係も重要です。 一般に、コアあたり 3 GB から 4 GB 未満の RAM を使用すると、SQL Server の合計処理能力が低下します。 SQL Serverがサイト サーバー コンポーネントと併置されている場合は、コアごとにさらに RAM が必要です。
注:
すべてのテストでは、CPU の最大消費電力とパフォーマンスを可能にするマシンの電源プランが設定されます。
注 2: SQL Serverメモリ割り当て
この値を使用して、SQL Serverのプロパティで最大サーバー メモリ (MB) を構成します。 これは、サーバーで使用可能なメモリの合計量に対する割合です。
最小値と最大値は同じに構成しないでください。 このガイダンスは、SQL Serverの割り当てを許可する必要がある最大メモリに対するものです。
注 3: IOPS: 受信トレイと IOPS: SQL
これらの値は、Configuration ManagerとSQL Server論理ドライブの IOPS ニーズを参照します。 [IOPS: 受信トレイ] 列には、Configuration Manager受信トレイ ディレクトリを含む論理ドライブの IOPS 要件が表示されます。 [IOPS: SQL] 列には、さまざまなSQL Server ファイルで使用される論理ドライブに必要な合計 IOPS が表示されます。 これらの列は、2 つのドライブの書式設定が異なる必要があるため、異なります。 複数のボリューム間でファイルを分割する方法の詳細など、推奨されるSQL Serverディスク構成とファイルのベスト プラクティスの詳細と例については、「サイトのサイズ設定とパフォーマンスに関する FAQ」を参照してください。
どちらの IOPS 列でも、業界標準ツール Diskspd のデータが使用されます。 これらの測定値を複製する手順については、「 ディスクのパフォーマンスを測定する方法 」を参照してください。 一般に、基本的な CPU とメモリの要件を満たすと、ストレージ サブシステムはサイトのパフォーマンスに最も大きな影響を与え、ここでの改善により、投資に対する最も多くの見返りが得られます。
注 4: ストレージ領域が必要
これらの実際の値は、他の文書化された推奨事項とは異なる場合があります。 これらの数値は、一般的なガイドラインとしてのみ提供されます。個々の要件は大きく異なる可能性があります。 サイトのインストール前にディスク領域のニーズを慎重に計画してください。 このストレージの一部の容量は、ほとんどの場合、空きディスク領域として残っているとします。 このバッファー領域は、回復シナリオで使用することも、セットアップ パッケージの拡張に空きディスク領域が必要なアップグレード シナリオにも使用できます。 大量のデータ収集、データ保持期間の長い期間、大量のソフトウェア配布コンテンツに対して、サイトに必要なストレージが増える場合があります。 これらの項目は、スループットの低い別のボリュームに格納することもできます。
ディスクのパフォーマンスを測定する方法
業界標準ツール Diskspd を使用して、さまざまなサイズのConfiguration Manager環境で必要な IOPS に関する標準化された提案を提供できます。 網羅的ではありませんが、次のテスト手順とコマンド ラインは、サーバーのディスク サブシステムのスループットを簡単かつ再現可能な方法で見積もります。 一般的なサイズ設定ガイドラインの表で、結果を最小推奨 IOPS と比較できます。
ラボ環境のさまざまな種類のハードウェア構成のテスト結果については、「 ディスク構成の例」を参照してください。 新しい環境用のストレージ サブシステムをゼロから設計する場合は、大まかな出発点としてデータを使用できます。
ディスク IOPS をテストする方法
Diskspd ユーティリティをダウンロードします。
少なくとも 100 GB の空きディスク領域があることを確認します。 ディレクトリ、SQL、SMSExec のアクティブなウイルス対策スキャンなど、ディスクへの干渉や余分な負荷を引き起こす可能性のあるアプリを無効にします。
管理者特権のコマンド プロンプトから Diskspd を実行します。
テストするボリュームに対してツールを 2 回順番に実行します。 ランダムな書き込み操作を 1 分間行った 64k サイズの最初のテスト。 このテストでは、ボリュームが動的に拡張されている場合に備え、コントローラー キャッシュの読み込みとディスク領域の割り当てを検証します。 最初のテストの結果を破棄します。 2 番目のテストは 、最初のテストに直ちに 従い、同じ負荷を 5 分間実行する必要があります。
たとえば、次の特定のコマンド ラインを使用してボリュームを
G:テストします。DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat2 番目のテストからの出力を確認して、1 秒あたりの I/O 列の合計 IOPS を見つけます。 次の例では、合計 IOPS は 3929.18 です。
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
ディスク構成の例
次の表は、「さまざまなテスト ラボ構成で ディスク パフォーマンスを測定する方法 」のテスト手順を実行した結果を示しています。 このデータは、新しい環境のストレージ サブシステムをゼロから設計する際の 大まかな 出発点として使用します。
物理マシンと Hyper-V
ハードウェアは常に改善しています。 SSD や SAN など、新しい世代のハードウェアとさまざまなハードウェアの組み合わせが、以下に示すパフォーマンスを超えると予想されます。 これらの結果は、サーバーを設計するとき、またはハードウェア ベンダーと話し合うときに考慮すべき基本的な出発点です。
次の表は、さまざまなテスト ラボ構成のスピンドルおよび SSD ベースのハード ドライブを含む、さまざまなディスク サブシステムにわたるテスト結果を示しています。 すべての構成では、64k クラスターを使用してディスクをフォーマットし、エンタープライズ クラスのディスク コントローラーに接続します。 RAID アレイ ディスク数に加えて、それぞれに少なくとも 1 つの予備ディスクがあります。
| ディスクの種類 | +1 予備ディスクを含まないディスク数 | RAID | 測定された IOPS |
|---|---|---|---|
| 15k SAS | 2 | 1 | 620 |
| 15k SAS | 4 | 10 | 1206 |
| 15k SAS | 6 | 10 | 1751 |
| 15k SAS | 8 | 10 | 2322 |
| 15k SAS | 10 | 10 | 2882 |
| 15k SAS | 12 | 10 | 3476 |
| 15k SAS | 16 | 10 | 4236 |
| 15k SAS | 20 | 10 | 5148 |
| 15k SAS | 30 | 10 | 7398 |
| 15k SAS | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| SSD SAS | 2 | 1 | 7539 |
| SSD SAS | 4 | 10 | 14346 |
| SSD SAS | 6 | 10 | 15607 |
次の表に、この例で使用される特定のデバイスを示します。 この情報は、特定のハードウェア モデルまたは製造元に対する推奨事項ではありません。
| ディスクの種類 | モデル | RAID コントローラー | キャッシュ メモリと構成 |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | スマート配列 P822 | 2 GB、20% 読み取り/80% 書き込み |
| SSD SATA | ATA MK0200GCTYV | Smart Array P420i | 1 GB、20% 読み取り/80% 書き込み |
| SSD SAS | HP MO0800 JEFPB | Smart Array P420i | 1 GB、20% 読み取り/80% 書き込み |
Azure マシンとディスクのパフォーマンス
Azure ディスクのパフォーマンスは、Azure VM のサイズ、使用するディスクの数と種類など、いくつかの要因によって異なります。 Azure では、次のグラフとは異なる新しいマシンの種類とディスク速度も常に追加されています。 Azure で実行Configuration Managerの詳細と、Azure でのディスク I/O について詳しくは、「Azure でよく寄せられる質問に関するConfiguration Manager」をご覧ください。
すべてのディスクは NTFS 64k クラスター サイズでフォーマットされ、複数のディスクを持つ行は、Windows ディスク管理ユーティリティを使用してストライプ ボリュームとして構成されます。
| Azure VM | Azure ディスク | ディスク数 | 使用可能な領域 | 測定された IOPS | 制限係数 |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 GB | 965 | Azure VM のサイズ |
| DS2/DS11 | P20 | 2 | 1024 GB | 996 | Azure VM のサイズ |
| DS2/DS11 | P30 | 1 | 1024 GB | 996 | Azure VM のサイズ |
| DS2/DS11 | P30 | 2 | 2048 GB | 996 | Azure VM のサイズ |
| DS3/DS12/F4S | P20 | 1 | 512 GB | 1994 | Azure VM のサイズ |
| DS3/DS12/F4S | P20 | 2 | 1024 GB | 1992 | Azure VM のサイズ |
| DS3/DS12/F4S | P30 | 1 | 1024 GB | 1993 | Azure VM のサイズ |
| DS3/DS12/F4S | P30 | 2 | 2048 GB | 1992 | Azure VM のサイズ |
| DS4/DS13/F8S | P20 | 1 | 512 GB | 2334 | P20 ディスク |
| DS4/DS13/F8S | P20 | 2 | 1024 GB | 3984 | Azure VM のサイズ |
| DS4/DS13/F8S | P20 | 3 | 1536 GB | 3984 | Azure VM のサイズ |
| DS4/DS13/F8S | P30 | 1 | 1024 GB | 3112 | P30 ディスク |
| DS4/DS13/F8S | P30 | 2 | 2048 GB | 3984 | Azure VM のサイズ |
| DS4/DS13/F8S | P30 | 3 | 3072 GB | 3996 | Azure VM のサイズ |
| DS5/DS14/F16S | P20 | 1 | 512 GB | 2335 | P20 ディスク |
| DS5/DS14/F16S | P20 | 2 | 1024 GB | 4639 | P20 ディスク |
| DS5/DS14/F16S | P20 | 3 | 1536 GB | 6913 | P20 ディスク |
| DS5/DS14/F16S | P20 | 4 | 2048 GB | 7966 | Azure VM のサイズ |
| DS5/DS14/F16S | P30 | 1 | 1024 GB | 3112 | P30 ディスク |
| DS5/DS14/F16S | P30 | 2 | 2048 GB | 6182 | P30 ディスク |
| DS5/DS14/F16S | P30 | 3 | 3072 GB | 7963 | Azure VM のサイズ |
| DS5/DS14/F16S | P30 | 4 | 4096 GB | 7968 | Azure VM のサイズ |
| DS15 | P30 | 1 | 1024 GB | 3113 | P30 ディスク |
| DS15 | P30 | 2 | 2048 GB | 6184 | P30 ディスク |
| DS15 | P30 | 3 | 3072 GB | 9225 | P30 ディスク |
| DS15 | P30 | 4 | 4096 GB | 10200 | Azure VM のサイズ |
現在使用可能なディスクの詳細については、「 Azure IaaS VM のディスクの種類を選択する」を参照してください。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示