本投稿、この投稿は、vExperts Advent Calendar 2021 の 12/20 分を担当しています。
元々、一昨年辺りからまとめていた仮想化環境におけるストレージ性能設計、検証方法の考慮点の3つ目のコンテンツの予定だったのですが、ずっと放置していたものをようやく投稿しました。
- ストレージ性能設計・検証のすすめ① : vSAN 性能検証時に取得する情報
- ストレージ性能設計・検証のすすめ② : ストレージの性能を考慮した vSAN ハードウェア構成の組み方
- ストレージ性能設計・検証のすすめ③ : 性能試験を実施する際の考慮点 (本投稿)
私なりの vSphere 環境でのストレージ負荷試験時に考慮しているポイントをまとめていますが、ストレージ機器の性能検証をする時の参考にしていただく以外にも、一般的なアプリなどの性能検証時にも共通する部分があるかと思いますのでご一読いただければ幸いです。
ストレージ性能は何を見るべきか？
一般的なストレージ IO 性能を示す値として、IOPS (毎秒あたりの Read / Write の IO 数)、スループット (毎秒あたりの Read / Write のデータ流量)、遅延 ( IO 毎の Read / Write 完了までに要する時間)があげられます。
その性能を提供するために必要となるコントローラやドライブの選定し、組み合わせて検証を行いますが、IO そのものの性能以外にも IO 性能を出す際のストレージコントローラやドライブなどの利用率・負荷、サーバーのシステム利用率など実際の利用下での負荷状況の予測値がまずは見るべきポイントと考えています。
メーカーのストレージの性能情報や、各種 IT インフラの RFP・仕様書を見てみると「IOPS」の数字だけが独り歩きしている事が多々あります。
どんな条件下での IOPS なのか、その IOPS を出している時のシステムは余裕があるのか、限界ギリギリなのかで状況は大きく異なってきますのでそれ以外の指標をしっかりと把握する事が重要です。
私のストレージ性能を計測して、サイジング・設計に落とし込む順序は、
- Max 負荷の IOPS・スループットがどの程度か、様々な IO パターンで限界性能の測定
- Max 負荷を把握したらその値を上限に徐々に IO 負荷を上げていき、IO 遅延の変化とシステム負荷を計測
- 遅延とシステム負荷の傾向が把握出来たら、健全と判断できる数値内でのサイジング
この順序で各種パターン検証と考察を行い、実際に必要なサイジングに反映します。
※ アプリケーション開発などと絡む場合は高負荷な限界状態での稼働確認テストや、長時間負荷や温度などを変えた耐久テストなどもありますが、今回は対象から外しております。
IOPS だけを見て性能要件とすると多くのストレージ選定は失敗するのでご注意ください。
※ 今回ご紹介する検証の考え方は、メーカーが Max 性能を引き出す際のベンチマークの掛け方とは異なります。とにかく高い IO 性能を出すためのベンチマークツールの使い方やチューニング方法はそれぞれのベンチマークツールの使い方の公式ガイドなどに例があるのでそれらをご参照ください。
ストレージ IO 性能のポイントと検証の前提
既にいくつかの用語が出ていますが、改めてストレージ IO 性能を考える上で必須となる用語、指標を整理します。
ストレージの IO 性能そのものを示す指標
- IOPS (Input Output per Second) : 1秒当たりの IO の数
IOPS が高ければ性能が高い一つの指標だが、Throughput や Latency と併せてみる事が重要。 - Throughput (スループット・帯域): 単時間当たりのデータの流量、スループット。
IOPS * IO Block Size = Throughput となる。
サーバーからストレージに達するまでの IO 経路のネットワークの帯域や、ストレージデバイスのインターフェースが持つ帯域をどこまで適切に使い切れるかがポイント。 - Latency (レイテンシー・遅延・応答速度) : IO が発行されてから Read / Write が完了するまでの時間。
遅延が小さい方が IO が素早く完了し、ユーザーから見ても安定した高い性能であると言える。但し、IO Block Size が大きいと当然 IO の開始から完了までの時間が掛かるので遅延は大きくなるため、単純に遅延だけで比較するのは危険。その他の IO 条件を揃えた上で遅延を比較するのが良い。
バックアップやストリーミングなどの処理ではブロックサイズが大きく、Sequential IO である事が殆どなので IOPS や低遅延の数値よりも Throughput の方が重要な場合もある。
その他、ストレージコントローラのリソース負荷（CPU・メモリ負荷）の高まりや、ネットワークの距離、品質でも遅延は増減する。 - システム負荷 : 明確な指標ではありませんが、ストレージに IO 負荷を掛けている間のストレージコントローラの CPU やメモリの負荷、IO 負荷を掛けているワーカーとそれが稼働するサーバーのリソース利用状況は IOPS が健全に捌かれているかを把握するために重要な指標となります。
2コントローラ構成のストレージであれば、1コントローラダウン時の影響を加味するなど、最大負荷をどのような状況下を想定するかの考慮も必要です。どの程度の "余裕" を持たせるかでシステムの安定性や可用性に大きく影響する。
IO のタイプとそれを実現するための IO ベンチマークツールなどで利用される用語
ベンチマークツールの種類にもよりますが、以下の様な IO ワークロードを想定したパラメータを組み合わせる事で様々な負荷を作り出します。
- IO Block Size (ブロックサイズ): 単純に IO サイズと呼ばれることもある、1つの IO の大きさを示す指標。
一般的な OS・アプリケーションを想定した 4KB / 8KB / 16KB / 32KB などの小さめのブロックサイズから、128KB / 256KB / 512KB / 1MB などバックアップやストリーミング系の IO で多い大き目のブロックサイズを用いて（場合によっては組み合わせて）想定するアプリケーションをシミュレートした負荷を計測する事が多い。 - IO パターン : Random IO や Sequential IO など IO のパターン。
沢山の IO 発行元から同時に IO が発行されると一つ一つは Sequential IO であっても全体で見るとストレージ側では Random IO と見える事もあるので注意が必要。
バックアップやストリーミング系の IO 負荷想定は Sequential IO とする事が多い。 - IO 比率 / Read Write 比率 : こちらの事を IO パターンと呼ぶこともあるかもしれませんが、読み込み処理（Read）と書き込み処理（Write）の比率を示す。
通常は Read 70％ : Write 30% といった形で、実際の想定する IO に合わせて比率を変えながら検証する。
より多くのパターンを比較する場合は Read 100% ～ Write 100％ まで 10％ 刻みで IO 比率を変えて検証する。 - Thread （スレッド数）/ Outstanding IO : 一つの負荷対象（ターゲット）に対しての同時処理の並列数（スレッド数）や、未処理 IO 数（Outstanding IO）の指標。負荷の集中度を示す。
私の場合、小 IO Block Size の Random IO の場合はスレッド数は多めで負荷を掛け、Sequential IO の場合はアプリケーションの特性も考慮して少なめのスレッド数で負荷を掛ける事が多い。
結構この指標が重要で、スレッド数・Outstanding IO の値を増やし過ぎても、各ソフトウェア、ハードウェアのそれぞれの Queue に処理が溜まってしまい、最悪処理が追い付かないとキャッシュ溢れ等で性能が激減する事があります。
特に、ハードウェア側で QD の小さい SATA ドライブを利用している場合は注意が必要です。
特に、単一のワーカーノードから負荷をかける場合と、複数のワーカーノードから同時に負荷を掛ける場合とでは、結果的には前者と後者では単一処理の性能を測るのか、全体の処理の性能を測るのかの違いもあり、スレッド数・Outstanding IO の掛け方も変わります。
単一ワーカーで Max 負荷を掛けるパラメータを複数ワーカーから掛けたらストレージの処理が追いつかず検証が意味をなさないこともあるのでこの辺りの加減は何パターンも検証してみて適切な値の感覚を掴む必要があります。
※ Queue Depth についてはこちらを参照 → ストレージ性能設計・検証のすすめ② : ストレージの性能を考慮した vSAN ハードウェア構成の組み方 : IO コントローラやドライブの Queue Depth を知る - Testing Duration / Test Time（テスト時間）: 指定した IO の負荷を連続して掛ける時間。たくさんの IO ワークロードのパターンをテストしたい場合は 60 秒など短い時間で沢山のパターンを実施し、特定のパターンを掛け続ける事による負荷傾向を検証したい場合は 60分 ~ 数日間のテストを実施する事もある。
IO 性能のベンチマークを取得する以外にも、一定の負荷の状況下での障害試験などを行う際や、欠損データの再構築（RAID リビルドなど）時の挙動を見るときなどもある程度の時間で負荷を設定する。 - Warmup Time (暖機時間): IO 負荷を掛け始めてから実際にデータとして取得するまでの待ち時間、暖気運転時間。
ストレージによっては最初の IO は大容量のコントローラキャッシュに全て格納されてしまい、想定より大幅に高い数字を出すことがあるため、一定時間IO 負荷を掛け続けた後の数値を性能データとして記録する。
私の場合、個々のベンチマークパラメータで暖気時間を設定するよりも、本番と同等の負荷を一定時間掛けてストレージ領域の初期書き込みとキャッシュ埋めを行う事が多い。
また、読み込みキャッシュヒット率を含めて結果に期待したい場合は暖気はしっかり行いましょう。特にハイブリッド環境。 - Reporting Interval (記録間隔) : 負荷を掛けている間の IO 性能を記録する間隔。1 秒間隔で取得する事もあれば、同じ負荷を数日掛ける場合などは 60秒間隔などで設定する事もある。
負荷試験を掛けながら障害試験を実施して IO パスやコントローラの切り替わりを見たい場合などは 1 秒間隔で細かくデータを取得しながらダウンタイムを計測する。 - Prepare Disk Before Testing （事前 IO 処理） : ベンチマークツールで IO 負荷を掛けて計測する前処理で、実際のストレージ領域をランダムデータで埋めたり、ゼロ埋めする事で「初回 IO」のオーバーヘッドなどをあらかじめ吸収しておく処理。
Thin Provisioning のストレージ領域に負荷を掛ける際には初回の書き込みペナルティの排除は必須の処理。
重複排除ストレージの場合はゼロ埋め処理しても結果何も書き込まれないので必ずランダムデータで埋める事。 - Working-Set Percentage （負荷対象領域） :
負荷を掛けるワーカーにどの程度のストレージを割り当て、さらにストレージ領域の何％ の領域に負荷を掛けるかの指標。
階層化されたストレージの高速な SSD 領域や、コントローラキャッシュなど高速なデバイスの領域のみに負荷が掛かっても実際の状況に近いデータは取得できないので、必ず負荷対象のデータ領域の 50% ~ 80% に負荷を掛けられるように調整する。
私の場合はここのワーカーの負荷対象領域は 100% で設定し、展開するワーカーのストレージの合計容量が全体の 80% 以下に収まるように設定指定する事が多い。
※ ストレージプールや RAID の 100% を使い切ってしまうとデータの書き換えなどが行えず性能が大きく低下するので、実際の利用領域の推奨上限は各ストレージメーカーのベストプラクティス指標に従う事。
これらの IO ワークロードのパターンを組み合わせ、対象に様々な IO 負荷を実施し、構成・設定を変えながら同一の負荷を掛ける事でベンチマーク結果の比較が可能になります。
一例となるストレージの構成や設定差異では以下の項目が考えられます。
- ストレージソフトウェア、ファームウェアのバージョンの違い :
HCI などの SDS (Software Defined Storage) はバージョンの違いで同じハードウェアでも IO 性能が大幅に上昇する事があるのでバージョン間比較が重要。 - RAID 構成の違いの比較 :
特に書き込み時の Write Penalty (RAID1 = 2、RAID5 = 4、RAID6 = 6) や、障害からの RAID 再構築検証を行う場合の同期容量からの負荷の違いを考慮。 - 物理ドライブ構成の違いの比較 :
HDD は回転数やプラッタ当たりの容量、インターフェースの違いなどが性能に大きく影響。
SSD はインターフェースのタイプ（SATA / SAS / NVMe）の違いによる Queue Depth の違い、SLC / MLC / eMLC / QLC / 3DXPoint など素子の違いによる性能、耐久性が大きく異なるため比較時は必ず物理構成を把握する事。 - ストレージコントローラ側でのキャッシュヒット、IO の正規化・整形されるサイズの考慮
ストレージによっては小さな IO サイズを複数まとめて効率よく書き込んだり、逆に大きな IO サイズを複数に分割して重複排除などの効率を高めて書き込むなど、サーバー側で認識する IO とストレージ側で見える IO が異なる場合が多くあります。
特に重複排除ストレージや大量のコントローラキャッシュを搭載するエンタープライズストレージでは、コントローラ自体が処理する IO と LUN / FileSystem / RAID / 物理ディスクのそれぞれが処理する IO に大きな差があり、性能検証時のボトルネックの把握などでズレが生じることが多々ありますので注意してください。 - 物理ディスク・仮想ディスクのファイルシステムの設定の違い
- ゲスト OS にマウントした仮想ディスクをファイルシステムでフォーマットするか、RAW デバイスのまま IO するか
- ファイルシステムの違い、フォーマット時のブロックサイズの違い
- 仮想環境のデータストアのフォーマットの違い、ブロックサイズの違い
- vSpehre の場合は VMFS / NFS / vSAN / VVOL などデータストア種別によって傾向は変わります
- 昔の VMFS はブロックサイズの指定がありましたが、VMFS5・VMFS6 は 1MB のブロックサイズですので気にする必要はありません
- 参考 : Core Tech Zone VMware vSphere VMFS
- HDD や SSD のセクターサイズの違い
- 最近は 4K Native (4KN) のドライブも増えてきていますが、従来からある 512B Native (512B)、512B Emulation (512e) の物理ドライブのセクターサイズの違いの性能差なども比較対象として挙げられます
- 参考 : FAQ：VMware vSphere および vSAN の 512e および 4K ネイティブ ドライブのサポート表明 (2091600)
- 重複排除、圧縮機能の有効・無効の有無
- データ暗号化機能の有効・無効の有無 :
重複排除や暗号化をストレージレイヤで実装するとその処理のためにストレージコントローラのプロセッサ負荷が高まる場合が多々あります。
逆に、重複排除が効き実際の IO 数が削減される事でプロセッサ負荷が抑えられる場合もあります。これら機能の有効無効を比較する際は IO だけではなく、ストレージコントローラやサーバーの負荷についても確認する事。
IO の正規化・整形の箇所でも書きましたが、ストレージ毎に重複排除の計算・ IO する際のブロックサイズが異なり、サーバー - コントローラ間とコントローラ - ディスク間での IO に違いがあることが多々ありますので要注意です。 - プロトコルの違い :
FC / iSCSI / NFS / NVMe / その他独自プロトコルの HCI 等様々なプロトコルがあり、様々なネットワーク上でサポートされています。プロトコルとネットワーク種別は要比較ポイント。 - ネットワーク帯域の違い、ネットワークインターフェース形状、ケーブルの違い :
1Gbps / 10Gbps / 25Gbps / 40Gbps / 50Gbps / 100Gbps、FC 4Gbps / FC 8Gbps / FC 16Gbps / FC 32Gbps など現在は様々な帯域が実環境で利用されていますが、帯域だけではなく通信に使われるケーブルの種類や SFP モジュールなどの形状の違いで通信の品質（高負荷時のエラー再送、遅延）に影響。 - ネットワークのフレームサイズの設定（ジャンボフレーム利用の有無） :
高速大容量通信を小さなフレームサイズで転送するとその分、サーバー、ストレージ、ネットワーク機器のプロセッサの処理を必要するので、MTU 9000 以上に設定する事で処理負荷を下げ、効率的な通信が実現可能に。 - ホストの電源設定・パワーポリシー
省電力設定やバランス設定のときとハイパフォーマンス設定の時の性能差の考慮 - IO Multi path や IO チーミング機能の設定有無
- IO Controller、HBA のタイムアウト値のチューニング
- データストアのサイズと集約するワーカー VM の数 :
仮想環境では共有ストレージを利用して複数のワーカー VM から IO を書き込みます。
IO の排他制御の関係でワーカー VM が多いほど、書き込みが多いほど IO の応答遅延が大きくなる傾向があるので要確認ポイント。
このような様々異なる環境に対して「同一のベンチマークテストを実施する」事で、環境間の性能差異や、同一環境でも構成やバージョンの違いによる性能差異を把握する事が可能になります。
例えば、Read Write IO 比率を 10％ 刻みで 100:0 / 90:10 / … / 10:90 / 0:100 の 11 パターン、IO Block Size を 4k / 8k / 16k の3パターン、スレッド数を 2 / 4 / 8 / 16 の 4 パターンの Random IO の負荷を計測する場合は、 11 * 3 * 4 = 132 パターンとなります。
これら様々な IO ワークロードのパターンを総舐めするような負荷パターンを試そうと思うと毎回構成毎に 1,000 ~ 2,000 を超えるパターンの検証が必要になり、非常に手間となりレポートをまとめるだけでも一苦労です。
そんなベンチマークテストの手間をシンプル化するツールが次に紹介する HCIbenchです。
どんなベンチマークツールを利用していますか？
世の中には様々な無償・有償で IO ベンチマークツールがあり、様々な用途で利用されています。
負荷の掛け方はパラメータで様々変更、チューニングできるので様々な使い方で活用されます。
私は vSphere / vSAN などのプロダクト担当をしているという事もあり、上で紹介した様なVDbench、fio の実行を自動化してくれる HCIbench というフリーのベンチマークツール（実際に IO ワーカーは VDbench や fio を利用）を使っています。
- HCIbench : VMware Flings で公開されている無償のストレージ負荷テストツール
https://flings.vmware.com/hcibench
HCIbench に関しては以前に以下の記事で効率よくベンチマークテストを行う方法をご紹介していますが、今回の性能試験を実施する際の考慮点はこの中でご紹介している負荷の掛け方の前提となります。
※ 上記記事を書いてから 3年近く経過し、2021年12月20日時点では HCIbench Ver.2.6.1 が最新版となりますが、基本的な IO ワークロードの負荷の掛け方は同じです。
HCIbench のメリットは、名称こそ HCIbench ですが、HCI に限らず vSphere がマウント可能な各種ストレージ（vSAN / vSAN 以外の他社 HCI / FC ストレージ / iSCSI ストレージ / NVMe ストレージ / NFS ストレージ）に対する様々な IO ワークロードによる負荷検証が行え、Excel データや PDF、テキストでのレポーティングが自動でされる事にあります。
vSphere 環境でストレージ性能試験を行う際の準備
ストレージ性能試験を行う際もいくつかの前提（想定）があります。
- 純粋にストレージ性能のみを計測したい場合
- 一定負荷状況下でのシステムの挙動を確認したい場合
前者の場合、負荷を掛ける対象のストレージ領域と、ワーカーが稼働する環境には余計なその他のサービス、システムが動いていない事が必須です。
例えば負荷を掛け始めた後に、仮想マシンの負荷の状況に DRS で勝手に vMotion されては負荷 IO のバランスが崩れる可能性がありますし、データのリバランス機能などでワークロードとして掛けていた IO 負荷とは別にストレージのリバランス IO 負荷などが発生すると求めていた IO とは異なる IO が混在してデータの適正さが失われてしまいます。
純粋にストレージの性能のみを計測したい場合は、
管理サーバーや負荷試験に関係のないサーバーは負荷対象のクラスタ、ストレージには配置しない事。管理サーバーが高負荷環境で動かなくなってログがとれなかったらテストになりませんのでご注意ください...
管理サーバーや負荷試験に関係のないサーバーは負荷対象のクラスタ、ストレージには配置しない事。管理サーバーが高負荷環境で動かなくなってログがとれなかったらテストになりませんのでご注意ください...
DRS や ストレージのリバランス機能など、負荷の状況に応じて仮想マシンやデータの配置を移動する機能は無効化します。
コントローラや IO 負荷を掛けるワーカーのキャッシュをクリアする事や、本負荷を掛ける前にランダム IO で埋めるかゼロ埋めで初回書き込み済ませておきます。
一定負荷状況下でのシステムの挙動を確認したい場合は、
例えば一定のストレージ負荷の状況下で、別のシステムの正常稼働性を確認したり、
負荷を掛けている状況下で意図的に障害を発生させ、システムが正しくフェイルオーバーするかや、冗長化されたデータの片方に障害を発生させデータ再構成（RAID 再構築、データ再配置）を起こしてその際の負荷を計測するなど耐障害試験が代表的です。
その場合は想定する試験環境が再現できるように、DRS やリバランスの機能を有効にします。試験の前提で準備するべき設定、環境は大きく異なるのでご注意ください。
※ 障害試験を想定してワーカー VM が稼働している ESXi を強制シャットダウン掛けて HA を発生させてワーカー VM が再起動されてしまうと HCIBench のレポート生成が止まります。
vSAN 環境などで障害発生時の IO 劣化を継続モニタリングしたい場合は対象 ESXi ホストからワーカー VM を事前に vMotion で退避しておいてください。※ vSAN データが対象 ESXi に格納されていることによる IO 負荷の変化は VM の HA に関わらず HCIBench でモニタリング可能です。
その他の負荷の前提としていくつか考えられます。
- 1つのワーカー（1VM）からの性能を知りたい場合
- システム、ストレージ、クラスタ全体でワーカーから負荷を掛け全体の性能を知りたい場合
- 特定の環境下での性能に絞って性能を知りたい場合
1つ目の 1つのワーカー（1VM）からの性能を知りたい場合、
昔から良く行われる手法として、1VM のゲスト OS に IOmeter や CrystalDiskMark などのベンチマークツールを単体で動かしてその際の性能値を知る方法です。
2つ目のシステム、ストレージ、クラスタ全体でワーカーから負荷を掛け全体の性能を知りたい場合は、この後ご紹介する HCIbench などを利用したシステム全体で負荷を計測する手法が活用できます。
このパターンの検証では実際の利用を想定して全体に均等に負荷を掛ける事が重要です。
多くのストレージは 100% 近く書き込み切ってしまうと性能低下のリスクがあるので実環境で想定する程度の余裕は残して負荷を掛ける方法をお奨めします。
3つ目の特定の環境下での性能に絞って性能を知りたい場合は、
1つ目と2つ目の中間の様な IO 負荷の掛け方で、特定のワーカー、特定のストレージ領域、特定の負荷だけを集中的に掛ける事で取得します。
この負荷のパターンでは、例えばコントローラキャッシュや、階層化ストレージのキャッシュ層に全ての IO データが載る様なワークロードを組めば通常利用よりはるかに高い性能を計測する事が可能になります。
特定の高い負荷を捌く DB のための検証などでは意味のある検証ですが、特殊な環境下の IO 性能が独り歩きしないように注意する必要があります。
また、外部ストレージを利用する場合は外部ストレージそのものの IO 性能値の見え方が vSphere がマウントするデータストア、VM 側の IO 値と異なることがよくあります。
これは上の方でも書きましたが、ストレージコントローラにより IO を処理する単位が異なったり、キャッシュヒットや重複排除の効果で IO その物の数がサーバー側で確認できる負荷と、ストレージ側で確認できる負荷が異なるからです。
性能検証する際はシステム構成全体の各所で取得し、その性能値を比較することで適切な結果を得ることにつながります。
最大 IO 性能値の計測とその時のシステム負荷の計測
前提となる最大負荷の度合いが分からないと、次のステップでの現実的なストレージの性能値が判明しません。
まずは fio や VDbench の IOPS 制御はせず、IO Max で複数パターンを取得する事が必要です。
HCIbench で利用するパラメータなどは以下にまとめてあります。
以下のグラフはとあるシステムで、個々のワーカーでは IO 制御を入れず Max の負荷を掛け、IO Size 8KB、スレッド数を 2 / 4 / 8 の 3パターン、Read Write 比を変えながら負荷を掛けた際の IOPS と遅延をグラフ化したものです。
IOPS のリミット制御入れずに Max で IO を絞り出そうとすると IO 遅延が大きくなる限界まで IO を出そうとワーカーは頑張ってしまいます。
こうした数字にも意味はありますが、現実的ではないので次に紹介する方法で確認できた Max 値まで IO 負荷を高めていきながら対象ストレージのベストな IO 性能を探ります。
最大 IO 性能値まで IO 負荷を徐々に増加させながら遅延を計測
上記の例では、Read 100％ で 8 スレッドの負荷の際に 350,000 IOPS 位が出ているので、Max 350,000 くらいまで刻んでいく形で VDbench のパラメータを作ります。
HCIbench (VDbench と fio)では io rate というパラメータに指定した IOPS をワーカーとなる VM の数だけ負荷を掛けます。
1250 IOPS で設定して、8VM 展開されると 10,000 IOPS の負荷が掛かる事になります。
HCIbench で利用するパラメータなどは以下にまとめてあります。
IOPS を徐々に上げていくというパラメータを組む関係上、2,000 近いテストが走るため、1パターン 60 秒としても 1日以上のテスト時間になります。
パターン数は試験で許される時間を加味しながら、時間がない場合は本当に必要なパターンに絞って検証する事を推奨します。
全ての IO 比率で、IO Size 8KB、スレッド数 8 でのパターンを8VM で 10,000 IOPS から 350,000 IOPS までの IO 制御ありと最後に Max 負荷を掛けたデータをグラフ化すると以下の様になります。
これだと少し分かり難いので、Read Write 比率を 7:3 に絞って表示します。
グラフは以下の様になります。
IO の Read Write 比を絞り込むことで対象の IO 比での IOPS 負荷と遅延の傾向が分かり易くなりました。
上記の構成では 160,000 IOPS を超えたあたりから IO 遅延が 1ms を上回り、徐々に IOPS の伸びが無くなっていくのが分かります。
この場合、IO 遅延を無視して負荷を掛け続ければ R:W = 7:3 で 200,000 IOPS 以上出る構成ですが、1ms 以下の非常に低遅延な IO で安定した IO を提供する観点だと 150,000 IOPS 辺りがスイートスポットになりそうなストレージ構成と判断できます。
【重要】HCIbench での負荷計測時は、 vSAN 環境などであればレポートの一部に vSAN Kernel の CPU 負荷情報などが記録されますが、他社 HCI や外部ストレージの場合は対象のストレージコントローラの負荷は記録されません。必ず IO の傾向を HCIbench で確認しながら、ストレージコントローラの負荷情報をストレージ側で出力して IO 遅延との関連性を確認してください。
※ ちなみに私は HCIbench から出力される Excel シートをピボットテーブル・グラフで整理し、スライサーを付ける事で任意の検証パターンのグラフを表示できるようにカスタマイズしています。
※ HCIbench のレポートのカスタマイズ方法については以前にも簡単に紹介しておりますのでご参照ください。
このような試験を同様の環境で条件を変えながら、例えばストレージコントローラの Firmwear バージョンを変えたり重複排除機能の有無、ネットワークの設定を変えながらグラフを揃えて比較をする事でストレージ製品の設計、サイジングのベストを探る事に役に立ちます。
また、同じサーバーで負荷を掛けても、ストレージのメーカーやプロダクトが異なれば得意不得意の差により全く異なる IO と遅延の傾向がグラフに現れてきますので、同一条件下の比較で違いを楽しめると思います。
以下の例は3つの異なるストレージで R:W=7:3 の Random IO 負荷を徐々に上げていった際の遅延と IOPS の挙動を比べたものですが、それぞれコントローラの性能限界で IO 遅延が上昇し IOPS の伸びが無くなる点は一緒ですが、どこまでその負荷を引っ張れるかにかなりの違いが確認できました。
こうした違いを発見できるだけでも PoC 検証を行う意味はあるかと思いますので、ぜひお試しください。
その他の確認しておくべき IO 性能値とシステム負荷
ここまで、HCIbench での負荷試験を例に出力されたレポートをグラフ化して性能比較をしました。
性能試験を行う際にはこれら以外にも取得するべき情報、サーバーやストレージの管理画面から IO 情報や CPU 利用率などの情報も確認が必要です。
例えば vCenter から取得可能なパフォーマンス情報を vSphere Client の UI で確認したり、PowerCLI でエクスポートする事で HCIbench のレポートには表れない負荷を掛けている間のシステムの傾向を把握できますし、
ストレージコントローラ側のパフォーマンスレポートを取得しておく事で、vCenter で見る性能値とストレージ管理画面で見る性能値の違いを理解し、コントローラの健全な稼働の目安が把握できます。
ネットワーク機器のログも遅延やエラー再送が起きた時には要チェックになります。
特に私が個人的に重視しているのが今回ご紹介した様な「IO 遅延」が上昇し始める負荷レベルの時に、ストレージコントローラや物理的なドライブ、各コンポーネントに何が起きているのかを多角的に分析する事です。
性能検証する上で重要なのは一つの情報だけで判断するのではなく、関連する情報を比較して考察する事が重要だと思いますので参考にしていただければ幸いです。
まとめ
今回は仕事の中でもたまに質問される性能試験の考え方、見るべきポイントについて私なりの考えを書き出してみました。
システム、環境によっていろいろなベンチマークツールがありますので、それぞれに合わせて解釈を変更していただければと思います。
自分なりの検証方法とアウトプットの精度を一定に揃える事が出来れば、検証し蓄積したデータは非常に強い武器になりますので皆様の環境で色々試してみてください。
0 件のコメント:
コメントを投稿