Azure NetApp Files 用の Azure VMware Solution データストアのパフォーマンスに関する考慮事項
この記事では、Azure NetApp Files で使用する場合の Azure VMware Solution データストアの設計とサイズ設定に関するパフォーマンスの考慮事項について説明します。 このコンテンツは、仮想化管理者、クラウド アーキテクト、またはストレージ アーキテクトに適用されます。
この記事で説明する考慮事項は、コスト効率を最適化してアプリケーションから最高レベルのパフォーマンスを引き出すのに役立ちます。
Azure NetApp Files は、即座に拡張可能で、ハイ パフォーマンスかつ高信頼性のストレージ サービスを Azure VMware Solution 向けに提供します。 テストには、Azure VMware Solution と Azure NetApp Files の間のさまざまな構成が含まれていました。 テストでは、4 台の Azure VMware Solution または ESXi ホストと 1 つの Azure NetApp Files 容量プールのみを使用して、10,500 MiB/秒を超えるスループットと 1 秒あたり 585,000 回を超える入出力操作 (IOPS) を実行できました。
Azure NetApp Files を使用した Azure VMware Solution のストレージ パフォーマンスの向上
規模が大きくなり得る複数のデータストアを 1 つのサービス レベルでプロビジョニングすることで、パフォーマンスを向上させながら、コストを削減できる可能性があります。 それが可能なのは、Azure VMware Solution ホストから複数のデータストアへの複数の TCP ストリーム間で負荷が分散されるからです。 Azure VMware Solution TCO Estimator の Azure NetApp Files データストアを使用して、RVTools レポートをアップロードするか、手動の平均 VM サイズ設定を入力することで、潜在的なコスト削減額を計算できます。
データストアの構成方法を決定する場合、管理の観点から見た最も簡単な解決策は、1 つの Azure NetApp Files データストアを作成してマウントし、すべての VM をそのデータストアに配置することです。 より多くのスループットまたは IOPS が必要になるまで、この戦略は多くの状況でうまく機能します。 さまざまな境界を特定するために、テストでは合成ワークロード ジェネレーター (プログラム fio) を使用して、これらのシナリオごとにさまざまなワークロードを評価しました。 この分析は、パフォーマンスを最大化し、コストを最適化するために、どのように Azure NetApp Files ボリュームをデータストアとしてプロビジョニングすればよいかを決定するのに役立ちます。
開始する前に
Azure NetApp Files のパフォーマンス データについては、次を参照してください。
Azure NetApp Files: クラウド ストレージを最大限に活用する
Azure VMware Solution ホストでは、セクション 6 (チューニング オプション) で参照されている Linux テスト で
nconnect=1を使用する場合と同様に、NFS データストアごとに 1 つのネットワーク接続が確立されます。 この事実は、Azure VMware Solution が複数のデータストア間でパフォーマンスを非常に効果的にスケーリングする方法を理解するための鍵となります。Azure VMware Solution 用の Azure NetApp Files データストアのパフォーマンス ベンチマーク
テスト方法
このセクションでは、テストで使用される手法について説明します。
テスト シナリオと反復処理
このテストは、シーケンシャル入出力 (IO) とランダム入出力 (IO) のそれぞれについて、読み取り操作と書き込み操作の両方が含まれる "4 コーナー" 手法に従います。 テストの変数には、1 対多の Azure VMware Solution ホスト、Azure NetApp Files データストア、VM (ホストごと)、VM ごとの VM ディスク (VMDK) が含まれます。 特定のシナリオでの最大スループットと最大 IOPS を見つけるために、次のスケーリング データポイントが選択されました。
- VMDK のスケーリング。個々の VMDK を 1 つの VM 用の独自のデータストアに配置します。
- 1 つの Azure NetApp Files データストア上のホストあたりの VM 数のスケーリング。
- 1 つの Azure NetApp Files データストアを共有する Azure VMware Solution ホストの数のスケーリング。個々の Azure VMware Solution ホストが 1 つの VM を実行します。
- Azure NetApp Files データストアの数のスケーリング。各データストアに 1 つの VMDK が配置され、Azure VMware Solution ホスト間で VMDK が均等に分散されます。
小規模ブロックと大規模ブロック両方の操作をテストし、シーケンシャル ワークロードとランダム ワークロードを反復処理することで、コンピューティング スタック、ストレージ スタック、ネットワーク スタック内のすべてのコンポーネントを "エッジ" まで確実にテストします。 ブロック サイズとランダム化で 4 つのコーナーをカバーするために、次の一般的な組み合わせが使用されます。
- 64 KB シーケンシャル テスト
- 大きいファイルのストリーミング ワークロードでは、通常、大きいブロック サイズで読み取りと書き込みを行います。このサイズは既定の MSSQL エクステント サイズでもあります。
- 大規模ブロックのテストでは、一般に、最高のスループット (MiB/秒単位) が生成されます。
- 8 KB ランダム テスト
- この設定は、Microsoft、Oracle、PostgreSQL のソフトウェアなどのデータベース ソフトウェアで使用されることが多いブロック サイズです。
- 小規模ブロックのテストでは、一般に、最も多くの IOPS が生成されます。
Note
この記事では、Azure NetApp Files のテストのみを取り上げます。 Azure VMware Solution に含まれる vSAN ストレージは記事の対象外です。
環境の詳細
この記事の結果は、次の環境構成を使って得られました。
- Azure VMware Solution のホスト:
- サイズ: AV36
- ホスト数: 4
- VMware ESXi バージョン 7u3
- Azure VMware Solution のプライベート クラウド接続: FastPath を備えた UltraPerformance ゲートウェイ
- ゲスト VM:
- オペレーティング システム: Ubuntu 20.04
- CPU/メモリ: 16 vCPU / 64 GB メモリ
- Azure VMware Solution vSAN データストア上の 16 GB OS ディスクを備えた仮想 LSI SAS SCSI コントローラー
- テスト VMDK 用の準仮想 SCSI コントローラー
- LVM/ディスクの構成:
- ディスクごとに 1 つの物理ボリューム
- 物理ボリュームごとに 1 つのボリューム グループ
- ボリューム グループごとに 1 つの論理パーティション
- 論理パーティションごとに 1 つの XFS ファイル システム
- Azure VMware Solution から Azure NetApp Files へのプロトコル: NFS バージョン 3
- ワークロード ジェネレーター:
fioバージョン 3.16 - Fio スクリプト:
fio-parser
Test results
このセクションでは、実行されたテストの結果について説明します。
単一 VM のスケーリング
データストアによって提供されるストレージを Azure VMware Solution 仮想マシン上で構成する場合は、ファイル システム レイアウトの影響を考慮する必要があります。 複数のデータストアにまたがって分散されるように複数の VMDK を構成すると、利用可能な帯域幅の量が最大になります。 1 つのデータストアに配置されるように 1 対多の VMDK を構成すると、バックアップ操作とディザスター リカバリー操作が最大限に簡素化されますが、パフォーマンスの上限は低くなります。 この記事で提供される経験的データは、意思決定に役立ちます。
パフォーマンスを最大化するために 1 つの VM を複数の VMDK にまたがって拡張し、それらの VMDK を複数のデータストアにまたがって配置するのが一般的です。 VMDK が 1 個または 2 個しかない単一の VM は、単一の TCP 接続を介して特定の Azure VMware Solution ホストにマウントされるため、1 つの NFS データストアによって調整できます。
たとえば、エンジニアは、データベース ログ用に VMDK をプロビジョニングした後、データベース ファイル用に 1 対多の VMDK をプロビジョニングすることがよくあります。 複数の VMDK を使用する場合は、2 つのオプションがあります。 最初のオプションは、各 VMDK を個別のファイル システムとして使用する方法です。 2 番目のオプションは、LVM、MSSQL ファイル グループ、Oracle ASM などのストレージ管理ユーティリティを使用して、VMDK 間でストライピングすることで入出力のバランスを取る方法です。 VMDK を個別のファイル システムとして使用する場合は、複数のデータストアにワークロードを分散する作業を手動で行うのが面倒になる可能性があります。 ストレージ管理ユーティリティを使用してファイルを VMDK 間で分散させることで、ワークロードのスケーラビリティを実現できます。
複数のディスク間でボリュームをストライピングする場合は、バックアップ ソフトウェアまたはディザスター リカバリー ソフトウェアが複数の仮想ディスクの同時バックアップをサポートしていることを確認します。 個々の書き込みが複数のディスクにストライピングされるため、ファイル システムは、スナップショット操作またはバックアップ操作の最中にディスクが "フリーズ" することを確認する必要があります。 大半の最新のファイル システムには、xfs (xfs_freeze) や NTFS (ボリューム シャドウ コピー) などのフリーズ操作またはスナップショット操作が含まれているので、バックアップ ソフトウェアはそれを利用できます。
仮想ディスクの増加に応じて単一の Azure VMware Solution VM がどの程度スケーリングするかを理解するために、1 個、2 個、4 個、8 個のデータストア (それぞれに 1 つの VMDK が含まれる) を使用してテストを実行しました。 次の図は、1 個のディスクの平均 IOPS が約 73,040 であることを示しています (書き込み 100%/読み取り 0% から 書き込み 0%/読み取り 100% へのスケーリング)。 テストするドライブを 2 個に増やしたところ、パフォーマンスが 75.8% 向上して 128,420 IOPS になりました。 ドライブを 4 個に増やすと、テスト用にサイズ設定された単一の VM がもたらすがパフォーマンスのゲインが減少し始めました。 観察されたピーク IOPS は 100% ランダム読み取りで 147,000 IOPS でした。
シングルホスト スケーリング – 単一のデータストア
単一のホストから単一のデータストアへの IO を駆動する VM の数を増やしても、スケーリングはうまく機能しません。 ネットワーク フローが 1 つしかないことがその原因です。 特定のワークロードでパフォーマンスが最大になるとすれば、それは多くの場合、単一の TCP 接続を介してホストの単一の NFS データストアに向かうフローの途中で単一のキューが使用された結果です。 8 KB のブロック サイズを使用して、1 個の VMDK を備えた 1 つの VM から、合計 16 個の VMDK を備えた 4 つの VM (VM あたり 4 個、すべての VMDK が 1 つのデータストア上にある) にスケーリングしたところ、合計 IOPS が 3% ～ 16% 増加しました。
大規模ブロックのワークロード用にブロック サイズを (64 KB に) 増やしても同等の結果が得られ、ピークは 2148 MiB/秒 (単一 VM、単一 VMDK) および 2138 MiB/秒 (4つの VM、16 個の VMDK) に達しました。
シングルホスト スケーリング – 複数のデータストア
単一の Azure VMware Solution ホストのコンテキストでは、1 つのデータストアで VM が約 76,000 IOPS を処理できました。ワークロードを 2 つのデータストアにまたがって分散させることにより、合計スループットは平均 76% 増加しました。 データストアを 2 つから 4 つに移行したところ、次の図に示すように、1 つのデータストアに比べて 163% の増加が見られました (2 つから 4 つへの移行では 49% の増加)。 引き続きパフォーマンス ゲインは得られましたが、データストアの数が 8 つを超えると、スループットの増加幅が減少することがわかりました。
マルチホスト スケーリング – 単一のデータストア
ホストが 1 台のときは、単一のデータストアで 2,000 MiB/秒を超えるシーケンシャル 64 KB スループットが生成されました。 同じワークロードを 4 つのホストすべてにまたがって分散させると、135% のピーク ゲインが得られ、スループットが 5,000 MiB/秒を超えました。 この結果は、単一の Azure NetApp Files ボリュームのスループット パフォーマンスの上限を示している可能性があります。
ブロック サイズを 64 KB から 8 KB に縮小し、同じ反復処理を再実行すると、次の図に示すように 4 つの VM で 195,000 IOPS が生成されました。 ホストの数とデータストアの数の両方が増加するとネットワーク フローの数が増加するため、パフォーマンスが向上します。 ネットワーク フローの数はホスト数とデータストア数の積の係数であるため、ホストの数とデータストアの数をスケーリングと、それらを掛け合わせた数に比例してパフォーマンスが向上します。
マルチホスト スケーリング – 複数のデータストア
4 つのホストにまたがって分散された 4 つの VM を持つ 単一のデータストアは 5000 MiB/秒を超えるシーケンシャル 64 KB IO を生成しました。 より要求の厳しいワークロードでは、個々の VM が専用のデータストアに移動され、次の図に示すように、合計 10,500 MiB/秒を超えるスループットが生成されました。
小規模ブロックのランダム ワークロードの場合、単一のデータストアは 195,000 のランダム 8 KB IOPS を生成しました。 データストアを 4 つにスケーリングすると、530,000 を超えるランダム 8K IOPS が生成されました。
影響と推奨事項
このセクションでは、VM を複数のデータストアにまたがって分散するとパフォーマンスが大幅に向上する理由について説明します。
テスト結果に示すように、Azure NetApp Files のパフォーマンス機能は優れています。
- テストの結果、4 ホスト構成では、1 つのデータストアが平均約 148,980 8 KB IOPS または 64 KB IOPS で約 4147 MiB/秒 (すべての書き込み % テスト/読み取り % テストの平均値) を処理できることがわかりました。
- 1 つのデータストア上の単一の VM –
- 約 75,000 8KB IOPS または約 1700 MiB/秒を超えるスループットを必要とする可能性がある個別の VM がある場合は、ファイル システムを複数の VMDK にまたがって分散して VM のストレージ パフォーマンスを拡張します。
- 複数のデータストア上の単一の VM – 8 つのデータストアにまたがる単一の VM は、64 KB のブロック サイズで最大約 147,000 8 KB IOPS または約 2786 MiB/秒 を達成しました。
- 1 つのホスト - 少なくとも 4 つの Azure NetApp Files データストアを持つホスト 1 台につき少なくとも 4 つの VM を使用した場合、各ホストは平均約 198,060 8 KB IOPS または約 2351 MiB/秒 をサポートできました。 したがって、バーストの可能性がある最大限のパフォーマンスの達成に十分なデータストアのプロビジョニングと、管理の複雑さとコスト増とのバランスを取る選択肢があります。
推奨事項
1 つのデータストアのパフォーマンス機能では不十分な場合は、複数のデータストアに VM を分散し、さらにスケーリングします。 たいていの場合はシンプルであることが理想ですが、ある程度複雑さが増すことは、パフォーマンスとスケーラビリティによって正当化される場合があります。
4 つの Azure NetApp Files データストアは、大規模なシーケンシャル IO に最大 10 GBps の利用可能な帯域幅をもたらし、最大 500K のランダム 8K IOPS を処理する能力を持っています。 多くのパフォーマンス ニーズには 1 つのデータストアで十分かもしれませんが、最高のパフォーマンスを得るには、最小限 4 つのデータストアから始めてください。
きめ細かなパフォーマンス調整を行う場合は、Windows と Linux 両方のゲスト オペレーティング システムで、複数のディスクにまたがるストライピングが可能です。 したがって、複数のデータストアにまたがる複数の VMDK 間でファイル システムをストライピングする必要があります。 ただし、アプリケーション スナップショットの一貫性が問題になり、LVM やストレージ スペースでは問題を解決できない場合は、ゲスト オペレーティング システムから Azure NetApp Files をマウントする方法を検討するか、Azure が多くの優れたオプションを備えているアプリケーション レベルのスケーリングを調査してください。
複数のディスク間でボリュームをストライピングする場合は、バックアップ ソフトウェアまたはディザスター リカバリー ソフトウェアが複数の仮想ディスクの同時バックアップをサポートしていることを確認します。 個々の書き込みが複数のディスクにストライピングされるため、ファイル システムは、スナップショット操作またはバックアップ操作の最中にディスクが "フリーズ" することを確認する必要があります。 大半の最新のファイル システムには、xfs (xfs_freeze) や NTFS (ボリューム シャドウ コピー) などのフリーズ操作またはスナップショット操作が含まれているので、バックアップ ソフトウェアはそれを利用できます。
Azure NetApp Files では、割り当てられた容量 (データストア) ではなく、容量プールでプロビジョニングされた容量に対して課金されるため、たとえば、4x20TB のデータストアでも 20x4TB のデータストアでも支払う料金は同じです。 必要に応じて、Azure API/コンソールを介して動的にオンデマンドでデータストアの容量とパフォーマンスを調整できます。
たとえば、会計年度の終わりが近づき、Standard データストアのストレージ パフォーマンスをさらに高める必要があることがわかったとします。 その場合は、Standard データストアのサービス レベルを 1 か月だけ上げることで、他のデータストアを低いサービス レベルに維持しながら、Standard データストア上のすべての VM が利用できるパフォーマンスを高めることができます。 各データストアと各 AVS ホスト間の TCP 接続を増やして、それらの TCP 接続にワークロードを分散することで、コストを節約できるだけでなく、パフォーマンスも向上します。
vCenter Server または Azure API やコンソールを通じてデータストア メトリックを監視できます。 データストアでストレージ IO コントロール メトリックの収集が有効になっている限り、vCenter Server から、詳細なパフォーマンス チャートで、データストアの合計平均 IOPS を監視できます。 Azure API と Azure コンソールには、データストア レベルでワークロードを測定するための WriteIops、ReadIops、ReadThroughput、WriteThroughput のメトリックが表示されます。 Azure メトリックを使用すると、Azure 関数、Webhook、その他のアクションを介して自動的にデータストアのサイズを変更するアクションを含むアラート ルールを設定できます。