本投稿、この投稿は、vExperts Advent Calendar 2024 の 12/21 分を担当しています。
ここ数年の自分の Advent Calendar の投稿を見ていると、vSAN 含めたストレージの性能検証か設計の話、または LiveOptics などアセスメントの話が多かったので、改めて過去投稿を振り返りながら最近の HCIBench を活用した性能検証について紹介しようと思います。
- HCIBench の最新情報
- HCIBench 2.x で進化しているポイント
- HCIBench VM のバージョンアップ方法
- vSAN OSA と vSAN ESA それぞれに対する負荷の掛け方とワーカーの目安
- vSAN ESA で高 IOPS ・高スループットを低遅延で処理するためのポイント
- HCIBench 多数のパターン検証パラメータの生成エクセル
- ストレージ構成の選定や性能検証を行う上での注意点
HCIBench の最新情報
前回 HCIBench の活用方法について投稿してから早5年、当時 HCIBench 2.0 だったものは 2024年12月現在で HCIBench 2.8.4
まで開発が進んでいます。
Broadcom Community に移行した Flings ですが、HCIBench の最新版は GitHub 上で公開されてます。
【注意】 Broadcom Community : Flings 上の HCIBench のリンクは Version 2.8.2 と少し古いので、インストール後にバージョンアップするか、GitHub 側のものを最初から利用してください。
- ストレージ性能設計・検証のすすめ① : vSAN 性能検証時に取得する情報 （Advent Calendar 2019年）
- ストレージ性能設計・検証のすすめ② : ストレージの性能を考慮した vSAN ハードウェア構成の組み方
- ストレージ性能設計・検証のすすめ③ : 性能試験を実施する際の考慮点（Advent Calendar 2021年）
検証の考え方や実施方法については、基本的に変わっていませんが、実際の案件での PoC
相談や、トラブルシューティングの相談でこのあたりの内容が頻繁に利用されるので、改めて整理しておきたいと思います。
HCIBench 2.x で進化しているポイント
HCIBench 2.5.x くらいまでの情報は ストレージ性能設計・検証のすすめ① : vSAN 性能検証時に取得する情報 の中で少し触れていますが、それ以降も継続的に進化しています。
HCIBench 2.5 までの機能（黒字）と、HCIBench 2.8.x で強化された機能（青字）を以下にまとめます。
- vSphereでの共有ストレージのサポート (Support shared-storage in vSphere)
- vSAN (標準および拡張クラスタ) (vSAN (standard and stretched cluster))
- その他の共有ストレージ (other shared storage)
- 非共有ストレージ (Non-shared storage)
- VMCのストレージ (Storage in VMC)
- vSAN 以外の共有ストレージに対する Easy Run (Easy Run support for non-vSAN datastor)
- VM間通信ネットワーク (Inter-VM communication network)
- IPv4 DHCP (IPv4 DHCP)
- 静的IPアドレス割り当て (192.168.0.0/22) (Static IP assignment (192.168.0.0/22))
- カスタマイズされた静的IP (Customized static IP)
- IPv6: DHCPとリンクローカルモード (IPv6: DHCP and link-local mode)
- Worker VM 構成 (Worker VM configuration)
- VM 数 (VM number)
- ディスク数 (Disk number)
- ディスクサイズ (Disk size)
- vCPU 数 (vCPU number)
- RAM サイズ (RAM size)
- マルチライターモード (Multi-Writer Mode)
- 結果レポート (Results reporting)
- テキストファイル結果 (Text file results)
- Excel スプレッドシート ( Excel Spreadsheet)
- 包括的な PDF レポート (Comprehensive PDF report)
- vSAN 向けの機能 (vSAN only features)
- Easy Run (Easy Run) ※ 2.8.4 からその他のストレージもサポート
- キャッシュのクリア (Clear Cache)
- vSANパフォーマンス診断 (vSAN Performance Diagnostic)
- vSAN ESA のサポート (Support vSAN ESA)
- リモート vSAN データストアのサポート (Support Remote vSAN Datastore)
- vSAN デバッグ情報収集 (vSAN Debug Info Collection)
- vSANオブザーバー (vSAN Observer)
- vSAN デバッグモード (vSAN Debug Mode)
- vmkstats の取得 (Support vmkstats)
- サポートバンドルの取得 (Support Bundle)
- ワークロードパラメータ (Workload parameters) のカスタム項目追加
- 重複排除率 (Dedupe Ratio)
- 圧縮率 (Compression Ratio)
- 読み取り/書き込み I/O制限 (Read/write I/O limit)
- レイテンシターゲット ※ FIO でのみ利用可能 (Latency target)
並べるとかなりの機能が追加されています。
※ HCIBench 2.8.4 は 2024年12月時点ではまだ OVA および GitHub からの CLI を利用したバージョンアップでは降ってこないので、正式リリースまでお待ち下さい。
詳細パラメータの UI 組み込み
vSphere 8.0 以降向けには vSAN ESA に最適化した Easy Run の実装や、リモート vSAN データストア（旧称 HCI Mesh / vSAN Disaggregated Storage）向けの機能が拡充されています。
また、vSAN ESA をはじめとした NVMe ストレージが超高 IOPS / 低遅延な性能を提供する様になり、Worker VM のより高い処理能力が必要になりました。
そのため、Worker VM の vCPU数、RAMサイズなどもカスタム可能になり、クラスタやデータストア全体の性能検証用途のほか、個別の VM 構成ごとの IO 性能の上限を探る検証でも活用出来るツールに進化しました。
以前 HCIBench を利用したベンチマークテストのポイントと効率化（2） にて解説した VDBench の重複排除率、圧縮率の設定や R/W それぞれの IO Limit、遅延のターゲット設定なども HCIBench の UI から指定可能になっています。
パラメータの手打ちが面倒なときは、HCIBench の UI でまずはサンプルを作成し、作成したパラメータを SFTP などで取得してカスタムするのが良いかと思います。
以下は VDBench のパラメータ作成の UI に追加された Compression Ratio と Deduplication Ratio のパラメータ画面です。
また、FIO 向けの設定も拡張されていて IO Rate 設定で Write IO の上限設定が可能になり、また Worker VM の CPU 利用率や、負荷実行時のIO 遅延のターゲットを設定が可能になりました。
IO 遅延のターゲット設定は、高い負荷を掛けすぎてシステムを不安定にすることを避ける目的や、想定するワークロードの"健全な状態"の IOPS を探る際に活用できます。
Performance Monitor の強化
HCIBench 2.0 では Grafana ベースの HCIBench Monitoring View (Guest VM Performance Monitoring) が追加され、その後 HCIBench 2.3 からは Flings で公開されていた vSAN Performance Monitor の View も追加されました。
HCIBench 2.8.x では vSphere Client の vSAN Support Performance 画面がより詳細になったのため、負荷実行中のバックエンドの詳細モニタリングは vSAN Support
Performance へのリンクが追加されました。
vSAN Support Performance（vSAN パフォーマンス情報）のグラフについては ストレージ性能設計・検証のすすめ① : vSAN 性能検証時に取得する情報 にて解説しています。
※ 負荷をかける対象が vSAN OSA かつ、vSAN Performance Service が有効化されている場合は、HCIBench 内の vSAN Performance Monitor も利用可能です。
※ HCIBench 自体には vSAN Observer は組み込まれていますが、vSphere 7.0.x から RVC (Ruby vSphere Console) が非推奨
(Deprecated) になり、vSAN Observer も VCSA 本体では利用できなくなっています。
vSAN Observer のグラフを確認する場合は HCIBench 画面の「Results」タブから
Web ブラウザ上で確認してください。
vSAN デバッグモード
より詳細な負荷検証を行う場合に便利なデバッグ関連の機能が追加されました。
vmkstats の取得とサポートバンドルの取得を含め、各 ESXi ホストの詳細情報を含めて取得する vSAN デバッグモードが追加され、トラブルシューティングの再現検証時など、情報収集手段が強化されています。
vSAN デバッグモードで実行した場合は、レポートファイルの下部にハイパーリンクが含まれ、テスト後に収集されたサポートバンドルから解析された vSAN の詳細統計を示す Grafana ダッシュボードに移動します。
vSAN デバッグモードを利用する際の注意点
vSAN デバッグ モードが有効な場合、I/O テストの開始から 30 分後に vmkstats の収集が開始されるため、各テストケースのテスト時間を少なくとも 1 時間に設定することが推奨されます。
HCIBench 2.8.3 以降では、vmkstats を収集するときに、HCIBench 管理 VM は NFS ターゲットを作成し、すべての ESXi ホストをターゲットにマウントして、ターゲットに直接 vmkstats を収集します。そのため、HCIBench と ESXi ホストの間で NFS プロトコルが通信できる必要があります。
HCIBench VM のバージョンアップ方法
既存で利用している HCIBench VM は、GitHub から差分パッケージをダウンロードしてバージョンアップできます。実施前にかならず GitHub 上の最新の記載を参照してください。
zip ファイルを一旦落としてからインストールする方法（HCIBench が非インターネット接続環境の場合は一旦 wget で zip を落として、HCIBench VM の /root に転送して実行）
cd /root/ && wget https://github.com/vmware-labs/hci-benchmark-appliance/archive/refs/heads/main.zip && unzip main && sh hci-benchmark-appliance-main/HCIBench/upgrade.sh
before (2.8.2)
after (2.8.3)
tdnf で GitHub からインストールする方法（HCIBench VM から要インターネット接続）
tdnf install -y git && git clone https://github.com/vmware-labs/hci-benchmark-appliance.git && sh hci-benchmark-applianc/HCIBench/upgrade.sh
2つ目の tdnf を利用する場合、HCIBench のベース OS に使われている Photo OS 3 の GPG key の署名が有効期限切れでエラーが表示される時があると思います。そのため、1つ目の wget で一旦落としてから upgrade.sh を実行するほうが確実です。
vSAN OSA と vSAN ESA それぞれに対する負荷の掛け方とワーカーの目安
vSAN 環境に負荷を掛ける際の目安（Worker VM 数、構成）は Easy Run により展開される Worker VM 構成をまずは使ってみることを推奨します。
vSAN OSA と vSAN ESA の違いを HCIBench 2.8.x は自動で認識し、それぞれに合わせた Worker VM を展開します。
とりあえず Easy Run を流してみることで、vSAN 構成を詳しく把握していなくても、動作確認を兼ねておおよその性能値と、適切な Worker VM の展開サイズが分かります。
※ 最新の HCIBench 2.8.4 から外部の共有データストアに対しても Easy Run が実行出来るようになりましたが、指定できるデータストアは1つのみです。
デフォルトの Worker VM のスペック（初期値 & Easy Run で展開される VM）
- 4 vCPU
- 8GB RAM
- 8 Data Disk
Easy Run で展開される Worker VM 数
- vSAN ESA の場合 : 1 ESXi あたり 4 VMs
- vSAN OSA の場合 : 1 Disk Group あたり 2 VMs
Easy Run で負荷に利用されるデータセット
- vSAN ESA の場合 : キャパシティ合計の 30%
- vSAN ESA 合計容量の 1/3、かつ既存で消費されているデータが有る場合は 80% を超えないように設定される
- vSAN OSA の場合 : キャッシュサイズの合計に対して
- All-Flash vSAN : 75%
- Hybrid vSAN : 25%
Easy Run のワークロードプロファイル
6つのプロファイルが用意されています。
汎用ワークロード
- 汎用ワークロード :
- IO サイズ 4KB、Read 70%、Random 100%
- OLTP ワークロード :
- IO サイズ 8KB、Read 50%、Random 100%
4コーナーワークロード
- 小サイズ IO での Random Read :
- IO サイズ 4KB、Read 100%、Random 100%
- 小サイズ IO で Random Write :
- IO サイズ4KB、Read 0%、Random 100%
- 大サイズ IO での Sequential Read :
- vSAN OSA の場合は IO サイズ 256KB、Read 100%、Sequential 100%
- vSAN ESA または非 vSAN の場合は 512KB、Read 100%、Sequential 100%
- 大きなブロック サイズでのシーケンシャル書き込み
- vSAN OSA の場合は 256KB、Read 0%、Sequential 100%
- vSAN ESA または非 vSAN の場合は 512KB、Read 0%、Sequential 100%
※ その他、詳細なパラメータの解説は GitHub とユーザーガイドを参照してください。
負荷のスレッド数
負荷のスレッド数（Threads）は、未処理 IO（Outstanding IO）と密接に関係しています（ベンチマークツールによっては Outstanding IO = Threads の場合もある）。
一般的に小さい IO サイズの場合は、システムが多数並列で IO を発行する傾向があるため、スレッド数を増やします。逆に大きな IO サイズの場合は1つのファイルを Sequential に専属して処理する傾向が強いため、スレッド数は少なく設定します。
VDBench や FIO を使用して負荷を掛ける際は、以下を目安に環境に応じて調整してください。
- 64 KB 以下 : VMDK あたり 4 スレッド
- 64 KB 以上 : VMDK あたり 2 〜 4 スレッド
- 256 KB 以上 :VMDK あたり 1 スレッド
vSAN ESA で高 IOPS ・高スループットを低遅延で処理するためのポイント
vSAN ESA の場合、構成にもよりますが、3 〜 4台の小規模構成で、IO サイズや R/W 比にもよりますが、4〜８KB サイズの Random IO なら 1ms 以下の低遅延で 100 万 IOPS くらいは軽く出せてしまいます。
参考までに、vSAN ESA 4Node 構成で 100Gb ネットワークで RDMA と TCP のそれぞれでどのくらいの IO 性能差、遅延の違いがあるかをテストした簡易的なグラフで紹介します。
※ 物理 CPU や NVMe SSD のモデル、サーバーモデルなど詳細については非公開とさせていただくので、あくまでも参考値としてみてください。
様々な構成で vSAN ESA 環境を利用した検証で試しましたが、vSAN ESA のストレージとしての IO 性能の限界が非常に高く、限界まで負荷を掛けようとしても Worker VM の CPU リソースやネットワーク帯域が足りなくなり、ストレージとしての限界値を探ることが困難になることが多々ありました。
vSAN ESA の場合、ストレージの限界を試す前に、ネットワーク帯域の枯渇などがボトルネックになるかも知れません。現実的な用途に合わせて、IO を生成する Worker VM の vCPU 数やメモリサイズの構成を変えながら目的にあった検証データを取得することを推奨します。
※ vSAN ESA 自体は CPU 負荷が非常に低く、低遅延な IO を提供しますが、超高負荷を掛ける際、 IO Generator となる VDBench や FIO の処理が CPU を限界まで使っても負荷が掛けきれない、といった事が起きています。vSAN ESA の限界を試したい場合、ハイエンドモデルの CPU + 100G ネットワーク + RDMA などの構成が必要かも知れません。
ESXi ホスト自体のネットワーク転送処理で利用される CPU 負荷を下げるために、Jumbo Frame（MTU 9000）の利用や、RDMA を利用することもポイントになります。
上記グラフで示されているように、通常の TCP に対して、RDMA はより低遅延で、高い IOPS 負荷になってからも TCP より高い IOPS で処理できています。
高品質なデータセンターグレードのロスレススイッチを利用し、想定するワークロードの「スループット」を基準にネットワーク側も十分な帯域を確保することで vSAN ESA の低遅延な IO 性能を十分に活用する事ができます。
HCIBench 多数のパターン検証パラメータの生成エクセル
「HCIBench を利用したベンチマークテストのポイントと効率化（2）」で紹介した VDBench の負荷パラメータのサンプルですが、階段状に IOPS
を上げていく計算がめんどうだったり、細かいパラメータのコピーがめんどうなので私は作成用のエクセルシートでだいたいの目安をつくり、テキストにコピーしてパラメータファイルにしています。
PoC のお手伝いやコミュニティ仲間との検証などで使っているもので、単純なエクセルシートですが、ここで共有しておきます。
IOPS 制限値 × 仮想マシン数でクラスタ全体に掛ける IOPS 値が変わるので、環境ごとにいい感じの IOPS の階段になるように仮想マシン数とベースの IOPS 値を修正してください。
ストレージ構成の選定や性能検証を行う上での注意点
以前 ストレージ性能設計・検証のすすめ③ : 性能試験を実施する際の考慮点 に大量の文字で書いてしまい、ポイントが分かりにくかったので、改めて近年の案件相談などで寄せられる中からストレージの選定と性能検証に関して思う事をまとめます。
ワークロードの IO サイズとR/W比、IOパターン、遅延要件などを、 IOPS とスループットと併せて事前に調査する
ストレージの負荷検証、ベンチマークはただ IO 負荷を掛けても、それが本当に必要な性能情報になるとは限りません。
入札仕様書などによく見られる課題ですが、ストレージ要件が「◯◯万 IOPS 以上提供可能なこと」や「スループットが毎秒〇〇GB以上提供可能なこと」といった仕様文言が書かれている事が多々あります。
IOPS やスループットは結果でしかなく、IO サイズとR/W比、IOパターン、遅延要件で大幅に変わります。
必ず本番環境のワークロードで想定される IO サイズ、R/W比、IOパターン、遅延要件などを確認の上で性能検証を行い、その結果が IOPS でありスループットになります。
IO サイズを考える
「IO サイズ」とは、コンピュータやアプリケーションがストレージデバイス（ハードディスク、SSDなど）やファイルシステム、ネットワークを通してデータを読み書きする際の、一度に処理するデータ量のことを指します。
- 小さい IO サイズ （Small IO Size）
細かいデータの読み書きに適しています。例えば、データベースのトランザクション処理など、ランダムアクセスが多い場合や、OS の汎用的なログ IO などは小さい IO サイズな場合が多いです。
IO サイズが小さければ 1回の入出力あたりの時間（IO 遅延）が短く済む一方、大量のデータを小さな IO サイズで処理すると、入出力の CPU やネットワークのオーバーヘッドが大きくなります。
32KB 〜 64KB くらいまでが小さい IO サイズと言われる事が多いですが、32KB や 64KB は「中サイズ」と区切られることもあります。 - 大きいIOサイズ （Large IO
Size）
大量のデータをまとめて読み書きするのに適しています。例えば、大きなファイルのコピーやバックアップ、メディアサーバーへのアクセスなど、シーケンシャルアクセスが多い場合に有効です。IO回数が減るため、スループット（単位時間あたりのデータ転送量）が向上します。
IO サイズが大きければ 1回の入出力あたりの時間（IO 遅延）が長くなりますが、大量のデータを大きな IO サイズで処理することで、入出力の回数を減らし、時間あたりの転送効率が向上します。
128KB 以上の IO サイズが一般的には大きいサイズの IO と言われます。
IO サイズはアプリケーション → OS → ファイルシステム → （場合によってはネットワーク） → ストレージと、様々な層を経由しながら、場合によってはそれぞれの層ごとのシステムに最適化されたサイズに調整されます。
ストレージの性能検証する際は途中の IO サイズの特性も理解したほうが、結果を考察する際に良いことがありますので、思ったような結果が出ない場合は、それぞれの層の特徴を調べることをおすすめします。
IO サイズがわかると、IOPS とスループットの関係性がつながります。
ストレージネットワークの要件にはスループットが必ず含まれてきますが、ワークロードの IO
サイズがわかれば、このあたりの要件の決定も捗ります。
逆に、IOPS とスループットがわかれば平均的な IO サイズも計算できます。
既存ワークロードの IO サイズがわからない場合も、ESXi ホストで esxtop
コマンドを叩けば、Read / Write のスループットと Read / Write の IOPS が分かるので、そこから IO サイズの平均値を算出できます。
一般的な Linux や Windows、ストレージシステムのパフォーマンスモニタやコマンドからも同様に算出できます。
IO サイズと IO 遅延
単純な話ですが、同じストレージシステムを使っていても、IO 遅延は IO サイズによって変化します。小さい IO サイズなら一瞬で入出力されますが、IO サイズが 10倍、20倍違えば 1回あたりの入出力に時間を要するので IO 遅延は大きくなる傾向があります。
既存環境のアセスメントを実施した際など、「特定のストレージの IO 遅延が非常に高い」という結果が示された場合も、慌てずにその高い IO 遅延がどのようなワークロードが動く時間に観測されたかを確認してください。
システムのバックアップ処理や DB のダンプ取得するときなど、夜間タスクの際の処理がシーケンシャルアクセスで大きな IO サイズで入出力しているはずです。IO サイズが大きければ、IO 遅延も大きくなるのは仕様なので、数値だけではなく、ワークロード傾向も把握する事が重要です。
LiveOptics などのアセスメントツールや、各ストレージシステムのパフォーマンスモニタなどを見ると、時間帯毎の傾向が見えてくるはずなので、遅延・IOサイズ・スループットはそれぞれ関連付けて見るクセをつけると分析が捗ります。
極端なパターンだと以下のように、特定の IO サイズ（400KB 超え）が集中している時間帯のみ IO 遅延が高くなっているようなシステムも観測されます。
このような場合は、処理が時間内に終わっていなければ問題ですが、時間内に適切に処理が終っていればストレージ側の遅延については特に問題は無いと考えてよいかと思います。
IO パターン（Random / Sequential）を考える
ベンチマークのパラメータでは Random / Sequential という設定値があります。
一般的には小さい IO サイズの場合はバラバラと Random IO の傾向が強く、大きい IO サイズの場合はまとめた入出力を連続しておこなう Sequential IO の傾向が強いです。
ただし、仮想マシン単位では Sequential IO の場合でも、似たワークロードの仮想マシンが同時に入出力している場合、ストレージ側からみたら沢山の Sequential IO が Random に降ってくる、という感じに見え、Random IO に近い IO 特性となる場合もあります。
あまり細かく考えるとキリがない部分ではあるので、ストレージのベンチマークテストを行う際は、
- 小さい IO サイズ（4KB 〜 64KB）は Random
- 大きい IO サイズ（64KB 〜）は Sequential
これくらいのざっくりした分け方で傾向を見ていくのが良いです。
既存ワークロードの IO パターンが明確になっている場合はそれに合わせて調整してください。
仮想化環境独特のストレージ負荷の傾向とスレッド数（Outstanding IO）を考える
負荷の掛け方によっては沢山の仮想マシン、沢山の仮想ディスクそれぞれに多くのスレッド数で負荷をかけることがあるかと思います。
それぞれの IO の入出力処理はコンピュータ（ゲストOS → 仮想ハードウェア（vSCSI） → Hypervisor）で処理されたあと物理層へと向かいますが、IO コントローラや、SSD、HDD ごとにそれぞれ同時に処理可能な IO の数が決まっています。
下の図の例では簡略化して vSAN で利用されるストレージコンポーネントの仕様を書いていますが、SAS や SATA はもともと HDD やテープメディアを前提とした SCSI や IDE の技術の延長のインターフェイスのため、IO を処理するための Queue がそれぞれ1つのみで、処理待ちの IO Queue を受け入れる Queue Depth も SAS で 254、SATA で 32 と決まっています。
SAS や SATA デバイスを束ねる IO コントローラもモデルごとに Queue Depth が決まっており、従来の SAS、SATA に大量の IO が多スレッドで降ってきたら基本的に IO が Queue Depth に受け入れられながら、順々に処理される形になり、処理待ちで入り切らない未処理の IO が Outstanding IO として観測されます。
※ Outstanding IO はストレージデバイスの観点で見る値と、仮想マシン（仮想ディスク・仮想ストレージコントローラ）ごとにみる観点がありますが、話がややこしくなるので詳細は割愛します。
一方、より高性能な SSD に合わせて設計された NVMe は規格上の Queue と Queue Depth が 64k と非常に膨大で、大量の並列 IO を高速に処理する事ができます。
ベンチマークツールで負荷を掛けながら、ストレージのパフォーマンスモニタや ESXi の esxtop コマンド、vSAN Performance Monitor で Outstanding IO が溜まり続ける一方だと、負荷が多すぎる、スレッドが多すぎる傾向なので、パフォーマンスモニタを見ながら、適切なパラメータを探ってください。
様々なワークロードが動く負荷をシミュレーションしたい場合はどうする？
HCIBench はパラメータの作り方次第で、何千パターンの IO を順々に流して、レポートを自動で作成できる強力なツールですが、各パターンはそれぞれ決まった IO サイズ、スレッド、R/W 比、Random / Sequential 比で構成されます。
現実のワークロードでは、A システムは小さい IO サイズで Random、B システムは大きい IO サイズで Sequential、など様々なパターンが入り混じって同時に処理されます。様々な仮想マシンごとに異なる負荷を掛けてツールを実行したいという声もあります。
残念ながら HCIBench としてこれらの混合パターンを生成することはできません。
これらのパターンをシミュレーションしたい場合は、VDBench や FIO、IOMeter
などのツールを個別に展開し、別々のパラメータを適用して走らせたり、
ファイルサーバーのシミュレーションなら FSCT を組み合わせたり、デスクトップワークロードのシミュレーションなら LoginVSI
を組み合わせたり、ざまざまなツールを活用する必要があります。
.png)
0 件のコメント:
コメントを投稿