次の方法で共有


サイトのサイズとパフォーマンスのガイドラインを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 をテストする方法

  1. Diskspd ユーティリティをダウンロードします。

  2. 少なくとも 100 GB の空きディスク領域があることを確認します。 ディレクトリ、SQL、SMSExec のアクティブなウイルス対策スキャンなど、ディスクへの干渉や余分な負荷を引き起こす可能性のあるアプリを無効にします。

  3. 管理者特権のコマンド プロンプトから 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.dat
    
  4. 2 番目のテストからの出力を確認して、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 のディスクの種類を選択する」を参照してください

関連項目