2020年6月20日土曜日

VMware 技術情報で便利な公式まとめサイト集

一昨年頃からいろいろと VMware 関連の情報ページが再編・新設されており、有益なものは都度記事にまとめてましたが、改めてベストプラクティス系の資料が集まったサイトを整理したいと思います。
※ 昨年から今年にかけてまとめた記事、ダブった内容もありますが結構書いてました。
これらサイトの中身、全部目を通す必要は全くありませんが、どこにどんなコンテンツがあるのか見出しだけでも眺めておくと今後業務で必要になった際に素早く情報にたどり着けますので参考にしていただけると幸いです。

Best Practice / White Paper / Technical Deep Dive 資料まとめサイト

以下、vSAN・Storage 系、vSphere 系、EUC 系、NSX 系、vRealize 系、VMC 系とそれらを横串にしたソリューションのまとめサイトが公開されています。
殆どの動画以外のコンテンツが PDF でエクスポート可能なので、気に入ったコンテンツは ピン止めしたり RSS 登録したりでローカルに落としておくとオフラインでも調べものが捗ります。

意外と Storage Hub は知られているけれども、VMware 内のプロダクト担当でも Tech Zone や vRealize の Product Walkthroughs の存在が知られていなかったりします...

Storage Hub (vSAN, Storage、Cloud Foundation、SRM などインフラ関連)

vSAN やコアストレージ機能、SRM などのストレージが関連するアーキテクチャの他、VMware Cloud Foundation の様な HCI フルスタックな製品の情報が集約されています。
vSAN やコアストレージ系のベストプラクティスは導入前に必読です。
https://storagehub.vmware.com/

vSphere Central (vSphere 全般の様々な技術情報)

vSphere の各主要機能なディープな情報が集まっています。
vSphere 基盤のベストプラクティスは StorageHub の情報と合わせて必読です。VCP などの試験対策にもなります。
https://vspherecentral.vmware.com/

Digital Workspace Tech Zone (Horizon や Workspace One など End User Computing 関連)

End User Computing 関連のベストプラクティス、プレゼン動画などが集約されています。
https://techzone.vmware.com/

VMware Cloud Tech Zone (VMC 関連)

TechZone の VMC サブドメインサイト。VMC on AWS をはじめとしたクラウドサービスのベストプラクティスが集まっています。
https://vmc.techzone.vmware.com/

Networking & Security Tech Zone (NSX など Network Virtualization  関連)

TechZone の NSX サブドメインサイト。こちらもネットワーク仮想化に関するベストプラクティスが集約されています。
https://nsx.techzone.vmware.com/

vRealize Product Walkthroughs (vRealize 関連の自動化・可視化ソリューション関連)

私自身も最近存在を知った vRealize 系のプロダクト情報が集まったサイトです。
https://vrealize.vmware.com/

VMware Product Walkthroughs (プロダクト間でソリューションとして関連付けたサイト)

プロダクト横断ソリューションなどのガイドへのリンクがまとめられています。
https://featurewalkthrough.vmware.com/

従来からある Technical Paper (各プロダクトのまとめサイトが出来る以前からあったページ)

最近はこちらにコンテンツが追加される事は少なくなりましたがまだ現役です。結構 Deep な昔の資料も見つけることが可能です。
https://www.vmware.com/jp/techpapers.html

公式ドキュメント

各バージョン毎の設計、導入、運用時に確認必須な公式ドキュメント。各製品のリリースノートもここから入手します。
資料の中にもパフォーマンスベストプラクティスガイドやトラブルシューティングガイドもあるので必読。
https://docs.vmware.com/jp/

トップページは主要製品カテゴリのリンクなので、個別製品のドキュメントを探すときは「すべての製品」からたどります。
https://docs.vmware.com/allproducts.html

資料を PDF 化したい場合は各ドキュメントの見出し右上の「PDF」マークをクリックします。
英語 UI に切り替えると RSS フィード購読が出来るので気になる記事や、製品リリースノートの RSS フィードを登録しておけば製品に更新があった場合にいち早く気付くことが可能。

日本語表示のままだと RSS フィードの登録ボタンは表示されないので注意。
英語表示は KB もそうですが、必ず日本語表示と合わせてチェックした方が良いです。
日本語表示が更新されていなかったり、日本語表示自体が提供されていない事も多々ありますのでご注意ください。

その他、設計・導入時にチェック必須なツール・サイト

ベストプラクティス情報とは異なりますが、導入・運用時にチェックするべき情報サイトも少しずつ変化しているので改めて紹介します。

VMware Configuration Maximum tool  (最大構成上限のチェック)

各製品の構成上限は現在は Config Max Tool で各バージョン毎チェックを行い、PDF などにも情報をエクスポート可能です。

VMware Ports and Protocols (製品毎のポート要件、ネットワーク要件のチェック)

各製品のネットワークポート要件も現在はツールで各製品、バージョン毎に絞り込み確認し、ダウンロードが可能です。
https://ports.vmware.com/

Lifecycle Product Matrix

各製品のサポート期間のチェックは従来通り以下のマトリクスでチェックします。

VMware Product Interoperability Matrice

上記サポート期間中の製品は新しいバージョンが出るたびに各製品間の互換性サポートが更新されるのでバージョンアップや新規導入時に必ずチェックします。ただしここのマトリクスの表示が全てではないので必ずリリースノートや関連 KB も確認してください。

VMware Compatibility Guide

VMware Compatibility Guide (VCG) や Hardware Compatibility List (HCL) と呼ばれる周知のツールですが、新規導入時もそうですが、バージョンアップの際には必ず互換性チェックが必要です。また、ハードウェア側での不具合が見つかった際などは導入時にサポートされていたファームウェアバージョンが途中で非サポートとなる場合もあります。

数が多くなると大変かもしれませんが導入したハードウェア、特にサーバー本体、RAIDカード・HBA、NIC など重要なコンポーネントは RSS フィードなどを登録(矢印のところ)して、更新をチェックできる様にする事をお勧めします。

https://www.vmware.com/resources/compatibility/search.php


vSAN VCG Notification Service

vSAN VCG 通知サービス、今年5月から開催されたサービスですが、上記 VCG・HCL のフィード確認と合わせて vSAN で利用する HBA、SSD などのファームウェア・ドライバの更新履歴を分かりやすくチェックする事が可能なツールです。
https://vsansizer.vmware.com/revision-control/audit-detail

利用中のデバイスは VCG・HCL のページから各デバイスで RSS フィードの登録、または メール通知の登録が出来ます。


まとめは特にありませんが、定期的に自分のブックマークを兼ねてこれら記事は更新していこうと思います。

2020年6月15日月曜日

ESXi 6.x 以降でシステムリソースの予約値を変更する方法

vSphere 5.5 (ESXi 5.5) までは vSphere Client で値の変更が出来たシステムリソース(ESXi Kernel のリソース)の予約値ですが、vSphere 6.0 以降では変更が出来なくなってしまいました。
あえて修正しなくてもベストな値が自動で反映されているので通常は修正する必要はありませんが、各 ESXi 毎に予めシステムリソースの予約値を多めに確保しておきたい場合や、ホームラボ用途で予約値を減らしたいという場合もあるので、本記事では PowerCLI を利用して変更する方法を記します。

※ 正式な手順ではないので本番環境に設定する場合は必ず事前検証、各メーカーサポートへの確認を行ってください。
※ あと、だいぶ前に見た KB で今見つからなかったのですが、vSphere のバージョンアップ時などに設定がリセットされる事象があったのでもしかしたら今のバージョンでも元に戻る仕様かもしれません。テスト環境をバージョンアップする機会があれば追って確認して追記します。

本記事は LucD さんの VMTN での助言をベースにしています。

システムリソースの予約値とは?

システムリソースの予約とは、ESXi が動作するために最低限確保している CPU とメモリのリソース予約値で vSphere Client からホストを選択し、設定 > システム > システムリソースの予約 を開く事で確認できます。


このシステムリソースの予約、vSphere 5.5 までは vSphere Client の画面上にて編集する事が可能でしたが、vSphere 6.0 以降では vSphere Client では編集が出来ません(上記画面上で編集ボタンがそもそもない)。
※ これは設定に応じて適切な値が自動で予約されており、意図的にリソースを減らされて ESXi Kernel が不安定になる事を防止するために変更されたものと思われます。

今回はこの値を PowerCLI を利用して変更する方法をご紹介します。

システムリソースの予約値の変更以外で対応可能な制御方法

現バージョンでは標準 UI から変更不可となってしまったシステムリソースの予約値を変更する以外に、予めシステムリソースをある程度確保しておく方法として vSphere HA のアドミッションコントロールで全体の余剰リソースを多めに確保する方法や、VM を格納するリソースプールの制限設定でシステムリソース分を確保しておく方法があり、むしろクラスタ全体で柔軟なリソース管理をする意味でこちらが現在の推奨設定です。

これらの方法はクラスタ単位での設定であり、リソースプールの設定は格納された VM にのみ適用される制御方法となるため、単一ホストに負荷が集中して ESXi のシステムリソースが不足しないようにするためには DRS で VM の自動負荷分散配置できるようにします。

アドミッションコントロールについての公式 Docs

リソース プールの管理の公式 Docs

PowerCLI を利用したシステムリソースの予約値変更

まず、手元の環境の vSAN クラスタのうち 1台のシステムリソースの予約値を確認します。

画面を見るとメモリが 25.16GB、CPU が 239 MHz システムリソースとして予約されています。
但し、GUI でみる場合と、CLI での設定では単位の違いや微妙な数値の違いがあるので 正確な設定値を CLI で事前確認する事が必須です。
これを PowerCLI で確認する際には一発で取得するコマンドは用意されていないので、Get-VMHost で取得した ESXi の情報の中から探し出します。
今回求める情報は ExtensionData > SystemResources > "host/system" Key > Config と求めていきます。

# CPU 予約値の確認
PS C:\> $esx1 = (Get-VMHost)[0]   # ホスト1号機を指定
PS C:\> ($esx1.ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.CpuAllocation
Reservation           : 239    ← 239MHz 予約されている事が分かる
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

# メモリ予約値の確認
PS C:\> ($esx1.ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.MemoryAllocation
Reservation           : 24869  ← GUIの数値とは若干異なる事が分かる、ここでは 24869MB で予約されている
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1
 

念のため、全体の CPU のリソースも確認しておきます。
以下から 28,728 MHz という事が分かります。

PS C:\> Get-VMHost

Name                 ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz   MemoryUsageGB   MemoryTotalGB Version
----                 --------------- ---------- ------ ----------- -----------   -------------   ------------- -------
vxesx01.vx.local     Connected       PoweredOn      12       18523       28728         197.555         255.889   6.7.0
vxesx02.vx.local     Connected       PoweredOn      12        9587       28728         217.086         255.889   6.7.0
vxesx04.vx.local     Connected       PoweredOn      12       13355       28728         124.164         255.889   6.7.0
vxesx03.vx.local     Connected       PoweredOn      12       11707       28728         109.574         255.889   6.7.0
 

今回は例として、ミッションクリティカルなシステムなのでシステムリソースの予約値として CPU 全体の MHz 合計値の 10% = 2,872MHz を予約値として LucD さんの VMTN での回答を例に設定してみます。
※ 必ず設定変更する前に ESXi のコンフィグバックアップを取得したり(KB)、現在の設定値をエクスポート(VMTNのサンプル)しておいて元に戻せるようにしてください。

まずは1台目のホストを指定して設定反映させてみます。

PS C:\> $esx1 = (Get-VMHost)[0]                             # ← まずはホスト1号機に設定
PS C:\> $spec = New-Object VMware.Vim.HostSystemResourceInfo
PS C:\> $spec.key = "host/system"
PS C:\> $spec.Config = New-Object VMware.Vim.ResourceConfigSpec
PS C:\> $spec.Config.cpuAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.cpuAllocation.reservation = 2872       # ← 合計 CPU の 10% を指定
PS C:\> $spec.Config.memoryAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.memoryAllocation.reservation = 24869   # ← メモリの予約値は初期値をそのまま反映
PS C:\> $spec.Config.ChangeVersion = $esx1.ExtensionData.SystemResources.Config.ChangeVersion
PS C:\> $esx1.ExtensionData.UpdateSystemResources($spec)    # ← 変更値の反映
 
変更後の値を確認します
# CPU 予約値の変更確認

PS C:\> ($esx1.ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.CpuAllocation
Reservation           : 2872    # ← 2,872MHz に予約値が変更されている事が分かる
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1
 

vSphere Client 上での変更値を確認すると CPU のリソース予約が 2.87GHz (=2,872MHz) に変更された事が確認できます。 


問題なければ、クラスタ内の他のホストにも変更を掛けます。
※ 以下の例では Get-VMHost で取得したすべてのホストが同一構成で同じ CPU 予約値を設定する前提でパイプで渡して一括設定しています。

# 同一構成の4台でクラスタが組まれている前提で一括適用(1台目に設定した際の $spec が生きている状態で)
PS C:\> Get-VMHost | %{$spec.Config.ChangeVersion = $_.ExtensionData.SystemResources.Config.ChangeVersion; $_.ExtensionData.UpdateSystemResources($spec)}

# 4台とも変更されたことを確認
PS C:\> ((Get-VMHost).ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.CpuAllocation


Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1
 

設定を一括で元に戻したい場合は以下で戻すことが可能です。

PS C:\> $spec = New-Object VMware.Vim.HostSystemResourceInfo
PS C:\> $spec.key = "host/system"
PS C:\> $spec.Config = New-Object VMware.Vim.ResourceConfigSpec
PS C:\> $spec.Config.cpuAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.cpuAllocation.reservation = 239       # ← 初期値の CPU リソース予約値を入力
PS C:\> $spec.Config.memoryAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.memoryAllocation.reservation = 24869   # ← メモリの予約値は初期値をそのまま反映
PS C:\> Get-VMHost | %{$spec.Config.ChangeVersion = $_.ExtensionData.SystemResources.Config.ChangeVersion; $_.ExtensionData.UpdateSystemResources($spec)}
 

以上が変更手順、確認手順となります。

本番環境でシステムリソースを多めに確保しておきたい場合や、逆にリソースの限られるホームラボ環境でシステムリソースの予約を減らしたい場合に活用できる手法ですが、システムリソースを減らすことは安定性を失うことになりかねないので十分にご注意ください。

2020年6月12日金曜日

ストレージ性能設計・検証のすすめ② : ストレージの性能を考慮した vSAN ハードウェア構成の組み方

昨年末に書いた vSAN 性能検証の記事の続きで、本当はもっと早めに投稿したかったのですが色々な調整でなかなか纏められずにいた記事です。

本記事で書いている内容は先日の VMware 公式ブログでも紹介があった vSAN を構成するハードウェアに観点を置いた内容となります。
個人的なサイジングの考えが前提だったので、今まではパートナー様やお客様向けの勉強会で紹介していた内容ですが、公式側でも同様の見解でアナウンスが出たので公開する事にしました。


本記事は長文でダラダラと書いていますが、シンプルに本記事で伝えたい事をまとめると、All Flash 構成で大容量の SATA を組み込むときは SATA の特性を理解して欲しい、All Flash vSAN だからって油断して少数の大容量 SATA SSDで組んでしまうと性能が出ない時もあるから注意して欲しい、という内容になります。
「vSAN で思ったような性能が出ないじゃん!」となってしまう前に、本来のハードウェアとしてのサーバー構成の考慮点や、vSAN としてハードウェア性能を最大限に引き出すポイントをご紹介します。

vSAN Ready Node のハードウェア構成のカスタマイズ

vSAN クラスタのハードウェアを選定する際、多くは各ハードウェアメーカーがリファレンスモデルとしての vSAN Ready Node を公開しているので、vSAN Ready Node をベースにする事が多いと思います。
以下の公式のガイド、リファレンスガイド、コンフィグツールでサーバーのベースモデルを要件・用途に応じて選択します。
上記の vSAN Ready Node リファレンスモデルのベースを選択した後に、実際の性能要件や容量要件に応じて、各メーカーの構成ガイドや見積もりツールを利用して CPU / Memory / SSD など各コンポーネントを必要な構成に調整・カスタマイズして見積もりを作成しますが、
ここでよく 「vSAN Ready Node って構成変更できないよね?」と勘違いされる事が多いのです。

vSAN Ready Node は従来の ESXi のカスタムと同じく基本的に vSAN HCL でサポートされている(サーバーメーカーがサポートしている)コンポーネントであればかなり幅広くカスタムする事が可能で、多くのお客様の環境でもそのように導入されています。

この辺りは KB にもまとまっています。
上記 KB にある様に、vSAN Ready Node のベース構成で基本的に変更できないのは「HBA・RAID カードなどの IO コントローラ」と「ドライブのプロトコル(SAS/SATA/NVMe)の入れ替え」です。それ以外は柔軟に調整できます。

高性能・安定性を考慮した vSAN ハードウェア構成の組み方

まず、前述の vSAN Ready Node に関してはある一定の基準を満たす構成をベースとして定義しています。
キャッシュドライブの耐久性の考慮やサイジングについては、昨年記事をまとめておりますので以下のクイックリファレンスと合わせて参照願います。
今回お伝えしたいハードウェア構成の組み方のポイントは、上記のキャッシュサイジングよりさらにハードウェアよりの仕様を考慮した考え方となります。

SSD や HDD の IOPS 性能を知る

以前の HDD の頃は、ドライブ一本当たり
  • SAS(or FC) 15krpm : 180 IOPS
  • SAS (or FC) 10krpm  : 130 ~ 140 IOPS
  • SATA (or NLSAS) 7.2krpm : 80 IOPS
  • SATA(or NLSAS)5.4krpm : 40 IOPS
といった感じに HDD の物理的な回転数やシーク速度で IOPS 性能が大体決まってて、それを RAID の組み方や Write Penalty を考慮して LUN 毎の IOPS 性能をサイジングして要件を満たすように構成していました。

2010 年くらいからエンタープライズストレージやサーバーにも SSD が採用され始め、徐々にその IOPS 性能は進化して、今ではサーバー向けの汎用の SATA SSD ドライブでも 1本で 20,000 IOPS 以上出るようになりました。
ちなみに、上記にリンクした vSAN Hardware Quick Reference  には vSAN HCL で認証取得済みの SSD に設定される性能クラスの指標がありますが、HCL を見る限りどの SSD も CLASS "D" 以上で認証を取っているので、SSD 単体で 20,000 IOPS 以上出るようなモデルばかりです。

Performance Classes for SSDs

SSD PERFORMANCE CLASSWRITES PER SECOND
B5000 - 10000
C10000 - 20000
D20000 - 30000
E30000 - 100000
F100000+
現在も、SATA HDD の限界性能は HDD 単体でせいぜい 80 ~ 100 IOPS 程度ですが、
同じ SATA インターフェースでも SSD になると SSD 単体で 20,000 IOPS 以上を簡単に出せてしまう、そんな時代です。
さらに SSD は大容量化が進んでいて、1本 7.68 TB や 14 TB の大容量 SSD が普通に IA サーバーのドライブとして構成ガイドにも載っています。

IO コントローラやドライブの Queue Depth を知る

前述の様に、SATA SSD も単体で 20,000 IOPS 以上出る時代です。ノート PC のローカルドライブや、IA サーバにベアメタルで Windows や Linux インストールしてBenchmark ツール走らせても数万 IOPS を軽く出す事が出来ます。しかも大容量で SAS に比べて低価格。

ここで油断して、vSAN ディスクグループの構成を、1キャッシュ : 1 大容量 SATA キャパシティ などで組むと思っていた性能が出ない事態に遭遇します。
原因は SATA インターフェースの Queue Depth (キュー深度・IO処理の待ち行列の保持数)の浅さにあります。
SATA、SAS、NVMe の Queue Depth の違いは、
  • SATA の Command Queue 1、Queue Depth は 32
  • SAS の Command Queue 1、Queue Depth は 254
  • NVMe の Command Queue と Queue Depth の規格上の上限はそれぞれ 64k (65,535)
であり、SATA だけ圧倒的に少ないのです。

多数の仮想マシンが集約され、多くの並列 IO が発行される仮想化環境では最終的な SATA キャパシティドライブの QD の浅さがボトルネックになるリスクがあり、サイジングには注意が必要なのですが、IOPS のみに目が行ってしまうと同時処理で並列 IO が集中し IO が詰まったときの性能限界が見落とされがちです。
特に"大容量"で"安価"な傾向がある SATA ではより多くの仮想マシンデータが格納され IO の集中が強くなる事も考えられます。

※ NL-SAS は SAS インターフェース を持つので QD 254 となり、選べるのであれば NL-SAS に変更した方が良いのですが、現在 IA サーバ向けにはほとんど流通していないようです。

※ NVMe は Command Queue そのものも最大 64k 個なので同時並列処理に適している上に、従来の 144個の SCSI (SAS) コマンドに対して、NVMe では必須コマンド 13 個、最大でも 27 個に大幅にシンプル化され PCIe Direct な接続で更なる低遅延 IO を作り出すことが可能です。
※ 実際の ESXi での 各 NVMe ドライブの最大 Queue Depth は製品・ドライバにより異なりますが 2048 ~ 4096 などで設定されている事が多く、esxcli コマンドで確認可能です。64k はあくまで規格上の Max です。

※ドライブの Queue Depth の確認は
esxcli storage core device list
で出力される各ドライブの Device Max Queue Depth 値などで確認可能です。 

IO コントローラの Queue Depth は大丈夫なのか?

ちなみに、SAS や SATA のドライブが接続される IO コントローラ(HBA・RAIDカード)にもデバイスあたりの Queue Depth はあり、vSAN Hardware Quick Reference  で規定される現在の vSAN Ready Node 認定に必要なモデルは最低 256 ~ 512 以上の QD を持つカードとなります。
例として現行の VxRail などの vSAN アプライアンスに標準搭載される HBA330 などのカードの Queue Depth は vSAN HCL 上に記載があり 9,460 と非常に深い値であることが分かります。
※ NVMe ドライブは個々のドライブに IO コントローラの機能を持っている

IO コントローラに  9,460 も QD があれば、その下に 20本の SAS ドライブをつなげても十分 QD は足りる事になります。
仮に 1枚の IO コントローラで QD が足りない場合はディスクグループ毎に IO コントローラを分ける構成が推奨され、初期の vSAN の頃は IO コントローラの QD が浅かったので Duncan Epping も彼自身のブログで言及していました。

Queue Depth が足りないとどうなるか?

どんなストレージでも最終的にはキャパシティドライブにデータが書き込まれて IO の処理は完了しますが、最終着地点の QD が浅いと大量の IO 負荷が掛かったときに書き込みが間に合わなくなるリスクがあります。vSAN も同様です。
vSAN の場合、一般的には高速・高耐久なキャッシュドライブを利用するので IO のトップスピードは非常に高くなります。しかし、キャパシティドライブが SATA SSD 1本だけで組まれているような場合は大量の処理が間に合わなくなる可能性があります。

イメージとしては漏斗の外形の大きさが IO コントローラとキャッシュドライブの QD、深さがキャッシュドライブの容量、出口の太さがキャパシティドライブの QD で表現すると以下の様になります(実際には Read/Write の往復処理や FTT や 重複排除・圧縮などがあるので異なりますが...)。
左が QD の浅い SATA SSD 1本で組んだ構成、右が QD が深めの SAS SSD 複数本で組んだ構成をイメージしています。

仮想マシンの集約度合いや IO の傾向にも因りますが、1ホスト辺り 30 VM が稼働していて、vSAN の冗長性ポリシーをミラーで設定したら、それだけで 30 VM 同時に IO を書き込むと 60 以上の並列 IO が発生する単純計算になります。
その IO の最終着地点が SATA 1本だと QD 32 しかないので IO を受けきれなくなり、キャッシュ層で Write Buffer 溢れが起きて IO 遅延の増大が発生してしまいます。

(参考)vSAN Observer : vSAN Disk (Deep-Dive) での確認
実際にキャパシティドライブの SAS, SATA の違いでどのようなバックエンド IO の違いがあるかはベンチマークツールで負荷を掛けながら障害試験などをする事で、vSphere Web Client や vSAN Observer で簡単に確認できます。
※ 各ツールでの情報収集方法や見方は以前の記事を参照ください 【vSAN 性能検証時に取得するべき情報

SATA キャパシティドライブでバッファ溢れする際の挙動
バッファ溢れする前からキャパシティドライブの遅延や IOPS にかなり不安定な揺らぎがみられる(最上段 キャッシュドライブのバッファ溢れしている事が分かる)

SAS キャパシティドライブ利用時のデステージ IO の挙動
SAS キャパシティドライブではバッファ溢れせずにキャパシティドライブに IO が流れ続ける事が確認できる(最上段 キャッシュドライブのバッファ利用率は安定している)

単体の OS や少数の VM からの IO がある環境、バックアップサイトの様に通常時はレプリケーションデータが流れてくるだけの環境であれば、コスト効率を高めるため少数の大容量 SATA で組む事も問題ないのですが、
高い IO 性能(低遅延・高 IOPS)を引き出したい環境であれば、QD の深い SAS や NVMe ドライブを利用したり、複数本に分散される事が強く推奨されます。

現在の各サーバーメーカーの構成ガイドなどを見ると大容量 SSD は同一モデルの SSD であれば、1/2 ~1/4 の容量モデルでもそれほど TB 辺りの容量単価はそれほど変わらない傾向があります。
サーバーのドライブスロット数は消費してしまいますが、複数本に分割して搭載した方が IO 性能は格段に上がります。

また、キャッシュドライブも大容量のものを1つ(= 1ディスクグループ)で組むならば、1/2の容量の SSD 2本で 2 ディスクグループで構成した方が IO 性能が大幅に向上しますし、キャッシュドライブ障害時のインパクトも軽減するので推奨です。
※ 一般的な IA サーバーの保守費用ではドライブ本数が変わっても保守費用は変わらないのでこの点でもメリットがあると考えます。

ディスクグループの分割のメリットは All SAS や NVMe で構成した場合にも同様となります。

どんな時に並列 IO 負荷が増大するのか?

沢山の仮想マシンが稼働する環境では当然ですが、ベンチマークツール(HCIBench や IOmeter など)で IO 処理のスレッド数や Out Standing IO の値を高める事で並列 IO 負荷は簡単に高められるほか、
vSAN では 6.7u3 で実装された障害時のデータ修復を高速化した Parallel Resync(パラレル再同期・並列再同期)が、6.7u2 以前と比べて Resync 時の並列 IO 数が増大する事が過去にベンチマークテストしている中でも確認できています(当然の事象ですが)。

ドライブ障害、ノード障害からのデータ冗長性の復旧処理は Intelligent Resync の機能も働き、高負荷時にはフロントエンド側の IO を 80% 優先し、バックエンド側の Resync 処理は 20% に抑える機能が働きますが、それでもキャパシティドライブの QD が浅すぎると読み込み → 書き込みの連続処理でバッファが枯渇してしまいます。

最近の SSD は耐久性が高くめったな事では壊れませんが、安定した低遅延の IO を維持するためにも、高負荷が見込まれる環境では SAS キャパシティドライブを選定してください。
また、SATA キャパシティドライブの環境では Resync IO が高い負荷を掛けない様に予め帯域調整を設定する事もできます。同僚の小佐野さんがこの辺り纏め記事を書いてくれています。<https://vmwarekkhci.hatenablog.jp/entry/2019/08/20/094231>

NVMe ドライブではどうなるのか?

NVMe ドライブの場合、前述の様にドライブ1本あたりの QD が 2,000 ~ 4,000 辺りで設定されています(esxcli などで確認可能)。
そして、ドライブそのものに IO コントローラ機能が組み込まれており、PCIe 直結で IO をやり取りするので CPU 負荷も少なく、非常に高速で低遅延な動作が期待できます。

キャパシティドライブにも NVMe ドライブを採用できるならば少数の大容量 NVMe SSD でも高い IO 性能、低遅延、Resync 時の安定した処理性能を発揮する事ができます。
但し、故障リスクの分散とより高い性能・安定性を考慮すると、価格見合いですがやはり分散した構成にした方が良いと私は考えます。

NVMe ドライブの場合、PCIe 直結と記載しましたが、サーバーメーカーの PCIe バスの設計によりどの位置を利用するのが最適か違いがありますので、必ずサーバーメーカーのハードウェアガイドを確認の上、適切なスロットに装填して vSAN ディスクグループを構成してください。

特に、CPU0 と CPU1 で処理に偏りがない様に、ネットワークカードなども含めた PCIe のバックエンド接続の最適な物理設計が重要になります。



また、高い IO 性能を発揮するためには、25GbE などの高速なネットワークと、IO 処理の CPU 負荷を下げるための Jumbo Frame (MTU9000~)の利用など適切な設計・設定も重要となります。
超高速な IO 性能を提供する vSAN のデザインについては以下の公式ブログや Storage Hub の Performance Best Practice も参照してください。
All NVMe vSAN で Intel 3DxP Optane DC などの爆速 SSD が採用される様な場面で SSD の性能をフルに発揮するためには 25GbE 以上は必須、さらに CPU 処理を下げるために Jumbo Frame も必須と考えてください。

まとめ

長々と書いてしまいましたが、従来は SATA HDD ドライブ1本だけで本番環境の重要システムのストレージを組もうなどとは考えもしませんでしたが、SSD の性能進化により SATA SSD でも 数万 IOPS を余裕で出すことが出来る様になったためデバイスそのものの Queue などの考慮が忘れられてしまったか、そもそもサイジングの前提から漏れている事が増えて、多数の並列 IO を処理し高性能・低遅延な環境を提供なければならない仮想化基盤に組み込まれる事が増えてきました。(SATA が悪いわけではなく適材適所で利用するのが重要)

改めて、重要なシステムに安定した性能を提供するためにハードウェアの特性も考慮した設計・設定の参考にしていただければ幸いです。