（中上）あまり知られていない気がする、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本のペースでギターが増殖中。
（鈴木）IBMで働く現場SEメンバーがはてぶ（ブログ）始めたよ
IBMの鈴木です。IBMの現場SE部門でインフラSEを10年ほどやっています。
このたび、うちの部門の試みとして、「IBMの現場SEが培ってきた様々な情報」をこのブログに書いていくことにしました！
1. IBMの現場SEがこんなことを書いていく
どんなことを書いていこうか・・・私は同じ部門のメンバーと話し合いました。
その結果・・・
あれこれ出すぎてまとまりませんでした（笑）
例えば以下のような内容です。
- テクニカルな知識の公開
- 何かに対するレビュー
- 成功談・失敗談
- いちSEとして、いちIBMerとして、いち人間として言っておきたいこと
- お勧めのお店紹介
などなど・・・種々様々、雑多に書いていく予定です！おそらく、書く人間によって書くカテゴリも書きっぷりも全然違ってくると思います。
はっきり言って私も誰がどんな記事を書くのか想像もつきません（笑）しかし、「誰かの役に立てれば」という思いは、私たちの唯一の共通認識です。
2. IBM 現場SEがブログを始めた理由
なんでまたIBMのSEが、しかも複数人でこのようなブログ活動をするのか？
それには、私たちの部門にこんな課題があるからです。（部門といっても、10数人くらいの最小単位の集まりですが）
- 現場SEの知識をアウトプットする機会がない（本当はあるんだけど、積極的にアウトプットしないことが少なかれある）
- 誰がどんなスキルや考え方をもっているのか、同じ部門内ですら周知できていない
- ブログって何か面白そうじゃん！やってみようぜ！
まぁ、同じ部門と言っても全員で同じ仕事をするわけではないので、実はプロジェクトメンバーより絡みが少なかったりするわけです。（「SEあるある」ですねｗ）
そこで、ブログという情報媒体を活用することで、楽しみながらこの課題を乗り越えていこうと思っています。
3. このブログの目指すところ
このブログを書くメンバーは私も含め、SEです。なので、同じような仕事をしているSEの方に、少しでも役に立つ情報を提供できたら、こんなに嬉しいことはありません。
これが、このブログの目指すところです。
もしかすると、記事の内容が読み手に正確に伝わらなかったり、難しいと感じさせてしまうかもしれません。 そういうのをブログを通して少しずつ改善していくことで、我々も成長できると思っています。
同時に、我々自身が抱えている課題（アウトプット機会が少ないなど）も、このブログに記事を投稿していくことで改善できたらいいなーと緩めに期待しています。
4. 投稿頻度は月に数件を目標
本当は、毎日投稿できるといいのですが、そこまでの体力がありません（笑）
おそらく、月に数件程度の投稿頻度でゆる～く運営していくことになると思います。
その分、違う個性の人間が、イロイロな記事を書いていく予定なので、ゆる～く見ていただければ幸いです！
ということで、「IBM現場SEのITな日々」の開設にあたり、私、鈴木より簡単なブログの紹介をさせていただきました。
今後とも当ブログをよろしくお願いします！
この記事の執筆者 ：鈴木
２００８年にIBMに入社。長くエンタープライズのお客様を複数担当。最近は金融系。純情派のインフラSE。Unix/Linux系がメインスキル。 最近は、InfinibandやOSS（Zabbix, xCATなど）など社内スキル保有者が少ないレアキャラを目指して活動中。
仕事柄（？）、血液型をA型に見られがちだが、弩級のB型です。 趣味はカメラ。IT知識よりカメラの方が詳しいのでは？という説もあり。
