- ストレージ性能設計・検証のすすめ① : vSAN 性能検証時に取得する情報
- ストレージ性能設計・検証のすすめ② : ストレージの性能を考慮した vSAN ハードウェア構成の組み方(本投稿)
- ストレージ性能設計・検証のすすめ③ : 性能試験を実施する際の考慮点
本記事で書いている内容は先日の VMware 公式ブログでも紹介があった vSAN を構成するハードウェアに観点を置いた内容となります。
個人的なサイジングの考えが前提だったので、今まではパートナー様やお客様向けの勉強会で紹介していた内容ですが、公式側でも同様の見解でアナウンスが出たので公開する事にしました。
個人的なサイジングの考えが前提だったので、今まではパートナー様やお客様向けの勉強会で紹介していた内容ですが、公式側でも同様の見解でアナウンスが出たので公開する事にしました。
本記事は長文でダラダラと書いていますが、シンプルに本記事で伝えたい事をまとめると、All Flash 構成で大容量の SATA を組み込むときは SATA の特性を理解して欲しい、All Flash vSAN だからって油断して少数の大容量 SATA SSDで組んでしまうと性能が出ない時もあるから注意して欲しい、という内容になります。
「vSAN で思ったような性能が出ないじゃん！」となってしまう前に、本来のハードウェアとしてのサーバー構成の考慮点や、vSAN としてハードウェア性能を最大限に引き出すポイントをご紹介します。
「vSAN で思ったような性能が出ないじゃん！」となってしまう前に、本来のハードウェアとしてのサーバー構成の考慮点や、vSAN としてハードウェア性能を最大限に引き出すポイントをご紹介します。
vSAN Ready Node のハードウェア構成のカスタマイズ
vSAN クラスタのハードウェアを選定する際、多くは各ハードウェアメーカーがリファレンスモデルとしての vSAN Ready Node を公開しているので、vSAN Ready Node をベースにする事が多いと思います。
以下の公式のガイド、リファレンスガイド、コンフィグツールでサーバーのベースモデルを要件・用途に応じて選択します。
- 最新の vSAN Ready Node の 互換性ガイド（いわゆる VCG や HCL と呼ばれるコンパチリスト）
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan - vSAN ReadyNode Configurator (選択方式で推奨モデルを選定)https://vsanreadynode.vmware.com/RN/RN
- 各社のリファレンスモデル全リストhttps://www.vmware.com/resources/compatibility/pdf/vi_vsan_rn_guide.pdf
上記の 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 に関してはある一定の基準を満たす構成をベースとして定義しています。
キャッシュドライブの耐久性の考慮やサイジングについては、昨年記事をまとめておりますので以下のクイックリファレンスと合わせて参照願います。
- vSAN Hardware Quick Reference Guide
https://www.vmware.com/resources/compatibility/vsan_profile.html - vSAN キャッシュ層 SSD の選定・サイジングのおさらい（2019年版）https://kwmtlog.blogspot.com/2019/03/vsan-cache-ssd-selection.html
※ vSAN 7.0 時点でも上記のサイジング基準で問題ありません。
今回お伝えしたいハードウェア構成の組み方のポイントは、上記のキャッシュサイジングよりさらにハードウェアよりの仕様を考慮した考え方となります。
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 CLASS | WRITES PER SECOND |
| B | 5000 - 10000 |
| C | 10000 - 20000 |
| D | 20000 - 30000 |
| E | 30000 - 100000 |
| F | 100000+ |
同じ 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 が詰まったときの性能限界が見落とされがちです。
多数の仮想マシンが集約され、多くの並列 IO が発行される仮想化環境では最終的な SATA キャパシティドライブの QD の浅さがボトルネックになるリスクがあり、サイジングには注意が必要なのですが、IOPS のみに目が行ってしまうと同時処理で並列 IO が集中し IO が詰まったときの性能限界が見落とされがちです。
特に"大容量"で"安価"な傾向がある SATA ではより多くの仮想マシンデータが格納され IO の集中が強くなる事も考えられます。
※ NL-SAS は SAS インターフェース を持つので QD 254 となり、選べるのであれば NL-SAS に変更した方が良いのですが、現在 IA サーバ向けにはほとんど流通していないようです。
※ NVMe は Command Queue そのものも最大 64k 個なので同時並列処理に適している上に、従来の 144個の SCSI (SAS) コマンドに対して、NVMe では IO Controller における必須コマンドは 13 個、最大でも 50 個前後と大幅にシンプル化され PCIe Direct な接続で更なる低遅延 IO を作り出すことが可能です。
→ NVMe 2.0 仕様詳細は nvmexpress.org で確認可能です。NVMe Base Specification / NVMe Command Set Specifications / NVMe Transport Specifications
→ NVMe 2.0 仕様詳細は nvmexpress.org で確認可能です。NVMe Base Specification / NVMe Command Set Specifications / NVMe Transport Specifications
/ NVMe-MI Specification など多岐にわたる仕様書が公開されています。
※ 実際の ESXi での 各 NVMe ドライブの最大 Queue Depth は製品・ドライバにより異なりますが 2048 ~ 4096 などで設定されている事が多く、esxcli コマンドで確認可能です。64k はあくまで規格上の Max です。
※ドライブの Queue Depth の確認は
esxcli storage core device list
で出力される各ドライブの Device Max Queue Depth 値などで確認可能です。
※ドライブの 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 が流れ続ける事が確認できる（最上段 キャッシュドライブのバッファ利用率は安定している）
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 も参照してください。
- vSAN Design Considerations – Fast Storage Devices Versus Fast Networking
https://blogs.vmware.com/virtualblocks/2020/01/28/vsan-design-considerations-fast-storage-devices-vs-fast-networking/
All NVMe vSAN で Intel 3DxP Optane DC などの爆速 SSD が採用される様な場面で SSD の性能をフルに発揮するためには 25GbE 以上は必須、さらに CPU 処理を下げるために Jumbo Frame も必須と考えてください。
まとめ
長々と書いてしまいましたが、従来は SATA HDD ドライブ1本だけで本番環境の重要システムのストレージを組もうなどとは考えもしませんでしたが、SSD の性能進化により SATA SSD でも 数万 IOPS を余裕で出すことが出来る様になったためデバイスそのものの Queue などの考慮が忘れられてしまったか、そもそもサイジングの前提から漏れている事が増えて、多数の並列 IO を処理し高性能・低遅延な環境を提供なければならない仮想化基盤に組み込まれる事が増えてきました。（SATA が悪いわけではなく適材適所で利用するのが重要）
改めて、重要なシステムに安定した性能を提供するためにハードウェアの特性も考慮した設計・設定の参考にしていただければ幸いです。
0 件のコメント:
コメントを投稿