本投稿、この投稿は、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 だけを見て性能要件とすると多くのストレージ選定は失敗するのでご注意ください。
ストレージ 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 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% を使い切ってしまうとデータの書き換えなどが行えず性能が大きく低下するので、実際の利用領域の推奨上限は各ストレージメーカーのベストプラクティス指標に従う事。
- ストレージソフトウェア、ファームウェアのバージョンの違い :
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 の応答遅延が大きくなる傾向があるので要確認ポイント。
どんなベンチマークツールを利用していますか?
- HCIbench : VMware Flings で公開されている無償のストレージ負荷テストツール
https://flings.vmware.com/hcibench
vSphere 環境でストレージ性能試験を行う際の準備
- 純粋にストレージ性能のみを計測したい場合
- 一定負荷状況下でのシステムの挙動を確認したい場合
前者の場合、負荷を掛ける対象のストレージ領域と、ワーカーが稼働する環境には余計なその他のサービス、システムが動いていない事が必須です。
例えば負荷を掛け始めた後に、仮想マシンの負荷の状況に DRS で勝手に vMotion されては負荷 IO のバランスが崩れる可能性がありますし、データのリバランス機能などでワークロードとして掛けていた IO 負荷とは別にストレージのリバランス IO 負荷などが発生すると求めていた IO とは異なる IO が混在してデータの適正さが失われてしまいます。
管理サーバーや負荷試験に関係のないサーバーは負荷対象のクラスタ、ストレージには配置しない事。管理サーバーが高負荷環境で動かなくなってログがとれなかったらテストになりませんのでご注意ください...
- 1つのワーカー(1VM)からの性能を知りたい場合
- システム、ストレージ、クラスタ全体でワーカーから負荷を掛け全体の性能を知りたい場合
- 特定の環境下での性能に絞って性能を知りたい場合
特定の高い負荷を捌く DB のための検証などでは意味のある検証ですが、特殊な環境下の IO 性能が独り歩きしないように注意する必要があります。
また、外部ストレージを利用する場合は外部ストレージそのものの IO 性能値の見え方が vSphere がマウントするデータストア、VM 側の IO 値と異なることがよくあります。
これは上の方でも書きましたが、ストレージコントローラにより IO を処理する単位が異なったり、キャッシュヒットや重複排除の効果で 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 の負荷が掛かる事になります。
IOPS を徐々に上げていくというパラメータを組む関係上、2,000 近いテストが走るため、1パターン 60 秒としても 1日以上のテスト時間になります。
パターン数は試験で許される時間を加味しながら、時間がない場合は本当に必要なパターンに絞って検証する事を推奨します。
全ての IO 比率で、IO Size 8KB、スレッド数 8 でのパターンを8VM で 10,000 IOPS から 350,000 IOPS までの IO 制御ありと最後に Max 負荷を掛けたデータをグラフ化すると以下の様になります。
これだと少し分かり難いので、Read Write 比率を 7:3 に絞って表示します。
グラフは以下の様になります。
※ ちなみに私は HCIbench から出力される Excel シートをピボットテーブル・グラフで整理し、スライサーを付ける事で任意の検証パターンのグラフを表示できるようにカスタマイズしています。
※ HCIbench のレポートのカスタマイズ方法については以前にも簡単に紹介しておりますのでご参照ください。
このような試験を同様の環境で条件を変えながら、例えばストレージコントローラの Firmwear バージョンを変えたり重複排除機能の有無、ネットワークの設定を変えながらグラフを揃えて比較をする事でストレージ製品の設計、サイジングのベストを探る事に役に立ちます。
その他の確認しておくべき IO 性能値とシステム負荷
例えば vCenter から取得可能なパフォーマンス情報を vSphere Client の UI で確認したり、PowerCLI でエクスポートする事で HCIbench のレポートには表れない負荷を掛けている間のシステムの傾向を把握できますし、
ストレージコントローラ側のパフォーマンスレポートを取得しておく事で、vCenter で見る性能値とストレージ管理画面で見る性能値の違いを理解し、コントローラの健全な稼働の目安が把握できます。
0 件のコメント:
コメントを投稿