(中上)あまり知られていない気がする、vSphere ESXiのディスクI/O改善方法
こんにちは、IBMの中上です。
入社5年目で、入社以来、現場SEとして、主にVMware、Linux、Windowsを中心にシステム設計・構築・運用などを担当しています。
特に、VMwareとLinuxを触る機会が多い気がします。
(※単に、Windowsに関しては比較的お客様でも触れるからというのが背景です)
今回は、VMware社が提供する中心製品であるvSphere ESXiのちょっとしたTipsを紹介しようと思います。
1.「ディスクI/Oが重い気がする」
入社以来、特に運用フェーズの支援をしていると、よくこんなお問い合わせの電話を受けます。
分かります、もっさりとしていると、それだけですごくストレスですもんね。
こういうパフォーマンス問題は厄介なもので、エラーらしいエラーは出ていないけれども「普段に比べてなんとなく処理が遅い気がする」という事象の表れ方をします。
そのため、発生している事象に対する切り込み方が非常に難しい。
大抵、電話をかけてくださる情報システム部の方も「困っているんです…」と困り顔が目に浮かぶような声音であることが多い気がします。
一般には、こういうパフォーマンス問題の時には、仮想OS、物理ホスト、ストレージそれぞれの観点で、普段とは異なるリソース使用状況が生まれていないか、一つ一つ潰していくことになります。
この切り分け方法を網羅的に書くことはそれ自体がかなり難しいですし、環境や設計にも依存しますので、ここでは割愛します。
さて、ディスクI/Oに関しては、問題が余計に面倒な様相を呈してきます。
その背景としては、主に2点あると思っています。
- 目に見えにくいため、発見が遅れがち
- 発見されても、速攻で対処できるとは限らない
1. に関しては、経験則として、ディスクI/Oを常時監視しているような環境をあまり知りません。レスポンスタイムの監視というのがなかなか難しいというのがあると思います。
2. に関しては、ボトルネックが見つかったとしても、チューニングが難しかったり、原因次第ではより高速なストレージに変更するより他ないなどのケースがあり得えます。
極端な話、仮想OSのCPUやメモリがリソース不足を起こしているのであれば、足してあげれば良いのですが、ディスクに関してはそういうわけにもいかないことがあるのですよね。
予防策としては、性能要件を十分に定めて要件を十分に満たすストレージを使用する、共有ストレージを共有しすぎない、といった根本的な計画の部分に関わることになると思います。
2. ESXiのディスクI/O改善Tips
ESXiから外部ストレージに対するI/Oに話を絞ります。
外部ストレージ側が対応していれば、ESXiの外部ストレージへのパス選択方法として「ラウンドロビン」を選ぶことができます。
(※少なくとも弊社のミッドレンジ以上の製品は大半が対応している印象です)
ラウンドロビンがもたらす効果として、全てのアクティブなストレージパス間での負荷を分散できます。
他のパス選択ポリシーとして「最近の使用」「固定」などがありますが、これらとは異なり、論理的には全てのアクティブパスの帯域を使用できることになります。
ただ、VMwareのラウンドロビンポリシーに関しては、以下の特徴があります。
1 つのパスは、特定の量のデータが送信されるまで選択されたままで使用されます。その量に達すると、PSP ではリスト内の次のパスが選択されます。
で、このパスが切り替わる基準が、デフォルトでは、ディスクI/O 1000回になっています。
これがなかなかの問題で、例えば、特定のパスが8Gbps=1GBだとした場合に、I/O 1000回以内に1GBが送受信されると、一部のI/Oが待機させられることになるのです。
これでは、複数ストレージパスを持たせ、負荷分散を図ったにも関わらず、逆にI/O遅延を引き起こす可能性があります。
この切替基準は、ESXiの再起動等を伴わず変更が可能です。
例えば、Queue Depthのようなパラメータは、ESXiの再起動が必要になりますので、仮想マシンの退避などの調整がどうしても発生してしまいます。
それに比べれば、かなり融通がききやすいチューニングポイントとなります。
個人的には、このデフォルト値については、ちょっとその意図が分からないなあというのが正直なところです。
実際に、以前私が担当していた案件にて、ディスクI/Oが非常に激しい仮想サーバのパフォーマンスチューニングの中でこの設定変更を入れることで、ディスクI/O処理を改善させることができました。
詳細は、以下のKBを参照して下さい。
3. 前提・留意点
まず、そもそもとして、ラウンドロビンが構成可能なストレージであることを確認する必要があります。
確認の際には、VMwareを触っている人であればお馴染みだと思いますが、VMware Compatibility Guideのサイトでご確認下さい。
VMware Compatibility Guide - System Search
また、KBの中にも記載がある通り、ストレージベンダー側がこの構成を推奨するかは確認が必要になります。
既に本番運用中の環境の場合、それまでは待機させられていたI/Oがストレージに集中する可能性があるため、変更した直後から、ストレージ側への負荷が高くなり、逆にレスポンスタイムを悪化させてしまう可能性もあるでしょう。
必ずしも1000→1に変更する必要はなく、少しずつ数値を下げていくような形でリスクヘッジすることも検討したほうが良いと思います。
変更の際には必ずesxtopを確認しましょう。
ディスクデバイス画面またはディスクアダプター画面で、IO数、帯域使用量、レスポンスタイムをリアルタイムに観察した方が良いでしょう。
なお、上で少し言及した案件の際には「KAVG/cmd」の値がチューニングによって改善されました。
4. おまけ(esxtopについて)
esxtopは、ESXiのパフォーマンス状況をリアルタイムに確認できるツールです。
ディスクI/O、特にレスポンスタイムに関しては、以下のような区別がなされています。
- GAVG … ゲストOSから見たレスポンスタイム
- KAVG … VMKernelで消費される時間
- DAVG … ストレージデバイスで消費される時間
つまり、GAVG = KAVG + DAVGという式になります。
今回のチューニングで効果が出るのは、恐らくKAVGだと思います。ストレージパスの帯域が飽和することで、VMKernelの中でI/Oが待機されることになるので、その消費時間はKAVGの値に加算されるものだと思われます。
逆に、DAVG側が高い値を取っている場合は、今回のチューニングはあまり効果を与えないことだと思います。
この場合は、残念ながらストレージ側が性能限界ということになります。
5. 最後に
社内で設計検討する際に「パス選択ポリシーはラウンドロビンで」という点までは話題に上ることは多いのですが、流石に上のチューニングポイントについてはあまり話に聞いたことがありませんでした。
「ラウンドロビン=I/O 1回毎に次のパスを使用する」というようなイメージを持ちかねませんので、ちょっと気をつけたいところですね。
それでは、引き続き、次の投稿をお楽しみに!
この記事の執筆者:中上
2013年にIBMに入社。エンタープライズ系のお客様を主に担当するインフラSE。メインスキルは、VMware、Linux、Windowsなど。入社時の技術研修で勉強したSystem xシリーズは、プロジェクトに配属される頃にLenovo社に売却される。以来、自社製品に殆ど触れることなく気づけば5年目。
初対面の人には「神経質そう」「理系っぽい」と言われがちだが、根っからの文系人間。
趣味は音楽。入社以来、年1本のペースでギターが増殖中。