はじめまして、テクニカルサポートエンジニアのRyoです。
Marieにかわりまして第3回を担当させていただきます。
第1回、第2回のサポートブログではトラブル発生時に｢まずどうすればよいの？｣をスタートに、サポートリクエスト(SR)を作成するまでのTIPSをご紹介しました。
VMware製品の障害問い合わせに不慣れなお客様でも、これまでの投稿の内容でかなりイメージが掴めたのではないでしょうか。
まだ、お読みで無い方は以下からチェックしてみて下さい。
—————————————————————————–
第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト（SR）と情報採取
—————————————————————————–
これまでの投稿をお読み頂いた方々の中には
｢いやいや、実際トラブル発生した時はそんな一筋縄にスムーズに事は運ばないよ｣ と思いたくなるシーンや、
｢事象を整理しようにも、なかなかまとめづらい内容なんですよね｣ なんて言いたくなることもあるかと思います。
もちろん、トラブルと言っても多種多様なものがありますので、中には一筋縄ではいかない事象も存在します。
第3回では、もう少し実際の事例に即した形で、ハマりやすいポイントなどをお話し、
｢ああ、そうか、そういう視点で対応すれば良んだ｣ など、少しでも今後の対応の参考にして頂ければと思います。
▮ トラブル発生からお問い合わせまで
早速ですが、トラブルが発生してから問い合わせまでの流れをおさらいしますと
一連の流れは以下のような感じになります。
この流れが滞りなく進めば、お客様側で内容の再確認などを行う手間も省けますし、
SRの担当サポートエンジニアが、お問い合わせ内容を把握し調査に取りかかるまでの時間がかなり短縮されます。
* 1,2の詳細については第1回、3,4,5の詳細については第2回にて紹介しています。
しかしながら、トラブルというのは多種多様で、上記の流れに沿って事象を整理しようと思っても
なかなか上手く事象を把握できず、対応に手間取ってしまうケースももちろん存在します。
では、どのようなケースの場合、事象の把握で時間を要してしまうのでしょうか。
いくつか例を挙げてご紹介します。
▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮
まずはじめに、 “1.トラブル発生” の際に手間取ってしまうであろうケースをご紹介したいと思います。
実際のトラブル発生に気づくポイントとしては、大きく以下の3点があります。
———————————————————————
a. 作業中にエラーが発生した
b. 使用者が動作の異常に気づいた
c. 監視サーバからアラートメールが届いた
———————————————————————
上記aの作業中のエラーは、実際に人が目で見て確認することがほとんどなので、特に見落としすることはないかと思います。
エラーに気づいた際は、エラーメッセージ内容と発生時刻を正確に書き留め、スクリーンショットを取得し、
サポートエンジニアに連携する下準備をしておくとSR発行の際に、正確な情報を伝えることが出来ます。
次にbの動作異常についてもユーザもしくはシステム管理者が気づくケースがほとんどかと思います。
動作異常、特にパフォーマンス関連については捉えにくい部分もありますので、case2で少しお話できればと思います。
残るcのアラートメールに関しては、お客様ご使用の監視システムを介して発行していることが大半かと思います。
ほとんどの警告やエラーメッセージはその内容が記載されており、一体何が発生したのかが何となく察することが出来るかと思います。
▮ アラートメールの中身が無い？
しかし中にはアラートメールは届いているものの、内容が全く無く、何のエラーを示しているのかがわからないケースがあります。
これは、vCenterサーバからSNMPトラップを監視サーバ宛に発行したものの、監視サーバはその内容を解釈できず、内容の表示が無いというものです。
このようなケースはESXiなどのアップグレードを行った際に、監視サーバ側でSNMP MIBファイル(管理情報ベース)の更新をし忘れていた時に起こることがあります。
特にESXi4.xから5.xなど、大きなバージョンアップがある際には、MIBファイルを新しいものに更新することを忘れないようにしましょう。
そうすることで、アラートの内容が確認できないといった事態を事前に回避し、すぐに問題に気づくことができます。
最新のMIBファイルは以下からダウンロードすることが可能ですので、チェックしてみてください。
* VMware KB: SNMP MIB module file download (1013445)
http://kb.vmware.com/kb/1013445
SNMPトラップの設定をこれからやってみようという方は、以下の構成手順をチェックしてみてください。
* VMware KB: Configuring SNMP traps in vCenter Server 4.x / 5.x (1006438)
http://kb.vmware.com/kb/1006438
▮ トラブルは発生していないのに、アラートを検知する？
ハードウェアの障害は発生していないはずなのに、ESXiホストのハードウェアステータスが警告と表示されている
というような困った状況がまれに発生することがあります。
このような事象は、実はサーバーチップセット上の過去のハードウェア障害の履歴をを消し忘れていた時に起こることがあります。
よくある事例として、KBでも紹介されていますのでチェックしてみてください。
* Warnings in the Hardware Status tab of the ESXi 5.x host fails to clear (2061093)
http://kb.vmware.com/kb/2061093
▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮
——————————————————————————————————————————————
特にエラーは発生していないが、アプリケーションの動作が遅い。
昨日深夜の日次運用バッチ処理に時間がかかりすぎて途中でキャンセルされてしまった。
——————————————————————————————————————————————
など、結果として影響は見えているのにも関わらず、エラーメッセージと思しきものが見当たらないケースがまれにあります。
この様なパフォーマンスの問題は、アプリケーション、DB、ストレージ、ネットワーク、ハードウェア障害など様々な要因が考えられ、すぐにその要因がわかるような単純なケースもあれば、複合的な要因で発生するケースもあります。
この様な場合、トラブル対応の一連の流れの中の、“4. 事象の整理” で時間を要してしまいがちです。
パフォーマンスの問題に対するアプローチは様々ですが、今回は仮想環境上でなにか異常を見つけた時に、何を確認し、どのような情報を取得し、VMwareサポートに連携すれば対応がスムーズに運ぶかというポイントでお話します。
まずは簡単にチェックできる箇所から確認していきましょう。
▮ 何と何を比較し、”悪い” という判断に至ったか
事象の切り分けや、各種パフォーマンスデータを収集する前に、まずそもそものところで何を問題視しているかをまとめてみましょう。
例えば、｢アプリケーション、仮想マシンの動作が遅くなっている｣ という状況であれば、
その “遅くなっている” というのはどのような判断基準で判断したのかを、確認できる範囲でチェックしてみましょう。
—————————————————————————————————————————————————————————
･ xx日の処理とyy日の処理を比較するとyy日の処理が遅くなった
･ 同じ構成、同じアプリケーションを実行している仮想マシン01と仮想マシン02を比較すると仮想マシン01が遅い
･ ESXi1号機上で実行していた仮想マシンをESXi2号機にvMotionした後から、ESXi2号機上の仮想マシンが遅くなった
—————————————————————————————————————————————————————————
このようにざっくりとで構いませんので、”悪くなった(遅くなった)” という判断に至る比較ポイントをまとめみて下さい。
これらの情報は今後詳細に調査方針を定める上で非常に重要な情報となります。
エラーの無いパフォーマンスの問題のゴールを設定する上で、比較対象 “正常系”、”異常系” を定めることが主な目的となります。
そうすることで、切り分け、調査方針が定めやすくなります。
▮ “正常系”、”異常系” それぞれで情報取得
比較対象を決めた後は、”正常系”、”異常系” それぞれの環境で情報取得を行いましょう。
取得する情報は第2回でご案内した vm-support に、パフォーマンススナップショットデータを加えていただくと、
パフォーマンス問題の対応時に役立つ場合があります。
* VMware KB: Collecting performance snapshots using vm-support in ESX and ESXi (1967)
http://kb.vmware.com/kb/1967
上記KBに記載があるように、ESXi5.xを例にすると、にSSHでログインし以下のコマンドを実行します。
# vm-support -p -d <取得期間(秒)> -i <取得間隔(秒)>
<取得期間(秒)> : 事象確認できる時間を設定してください。わからなければ100秒で指定してみてください。
<取得間隔(秒)> : 推奨時間である10秒を指定してください。
上記実行後は vm-support 取得手順に従い、ログバンドルを取得いただけますと
パフォーマンスデータは自動でログバンドルに取り込まれます。
以上のように、”正常系”、”異常系” を把握し、それぞれの情報取得実施頂くだけで調査の初動の部分で対応スピードが大きく変わってきます。
また、特にパフォーマンスの問題に関しては、現場のお客様が気づいた･確認した情報が非常に重要なポイントとなることが多いです。
｢関係しないかも･･･｣と思ったことが、意外と本質と捉えていたりすることもありますので、情報にフィルタをかけない状態で、実際に確認した生の情報を頂ければと思います。
お客様が確認した情報と取得いただいたログの情報を合わせて送付いただけましたら、あとはサポートエンジニアにお任せください。
参考までに、いくつかパフォーマンス関連のノウハウがKBにまとまっていますのでチェックしてみてください。
* VMware KB: Troubleshooting ESX/ESXi virtual machine performance issues (2001003)
http://kb.vmware.com/kb/2001003
=> 仮想マシンのパフォーマンス問題が発生した際の調査ポイントがまとめられています。
* VMware KB: Troubleshooting network performance issues in a vSphere environment (1004087)
http://kb.vmware.com/kb/1004087
=> ネットワーク遅延が発生した際の調査ポイントがまとめられています。
* VMware KB: Storage device performance deteriorated (2007236)
http://kb.vmware.com/kb/2007236
=> ストレージパフォーマンスが低下した際の調査ポイントがまとめられています。
▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮
最後に “5. ログの取得” に関するTIPSをご紹介したいと思います。
トラブルを解決するためには、トラブルに対する対処策が必要です。
その対処策を見つけ出すためには、事象発生時に “何が起こっていたか” を正確に把握する必要があります。
“何が起こっていたか” を把握するためにログの情報はなくてはならないものです。
▮ ログがローテートされている？
———————————————————————————————————————————-
該当時間のログ出力を確認しましたが、ログがローテートされており確認できませんでした。
——————————————————————————————————————————–
第2回の投稿でも少し触れましたが、お客様に対しサポートエンジニアからこのような回答を提示するケースが時折見受けられます。
ログの内容を確認出来ない場合、具体的に何が起こっていたかを把握できず、明確な調査結果、対処策をお出しできない可能性があります。
もちろん、事象の内容によっては一時的にログの出力が膨大になり、ログのローテートを防ぐことができない場合もあります。
ですが中には、事象が発生してからログ収集までの時間が経過しすぎたが為に、ログが残っていないというケースもあります。
後者については早めのログ収集を意識することで対策が可能ですが、それでもトラブルの度にログの取りこぼしが起こるような場合、
以下のKBを参考にログの保存世代数やサイズを増やすことも検討してみてもよいかもしれません。
* VMware KB: Increasing VMware vCenter Server and VMware ESX/ESXi logging levels (1004795)
http://kb.vmware.com/kb/1004795
もちろんログ管理設計による部分かと思いますが、ストレージ観点で容量に余裕のある範囲内で対応いただくことで、
トラブル対応がスムーズに進むのではないかと思います。
▮ ログを取得したけど、中身がない？
先ほどの話の通りに事象発生後すぐにログバンドルの取得をしたにもかかわらず、中身を見るとログが出力されていない、
というようなケースも実はごくまれに発生したりします。これは、そもそもログの出力(vmsyslogd)が停止している場合に起こるケースです。
では、一体どのような状況で起こり得るのでしょうか。
* VMware KB: ESXi 5.x host stops saving logs to storage (2001442)
http://kb.vmware.com/kb/2001442
上記KBでいくつか紹介していますが、以下のようなケースでログの出力が停止します。
——————————————————————————————————————————————
･ ローカルストレージの容量不足
･ 外部ストレージにログを保存している場合の、ネットワークやストレージ障害
･ ログファイルが破損している
･ ディスク障害が発生している
——————————————————————————————————————————————
ディスク障害やネットワーク障害など、ESXiとは直接関係の無いところで発生し得るケースが多いです。
このような場合は、まずハードウェアのトラブルの解消した上で、以下のコマンドでログの出力を再開させてみましょう。
# esxcli system syslog reload (ESXi5.xの場合)
このようなケースも存在するといことだけでも頭の片隅に入れておいてもらえると、
ログファイル自体は存在するもの、のある期間のログ出力が無い、といった場合の初動の部分でスムーズな判断ができるかもしれません。
以上のように、ログ取得の際に、目当ての時間帯でログ出力が無かったり、そもそもログが無かったり
といった状況に遭遇した時に ｢こんなケースもあるのか｣ ということを少し知っているだけで、
イレギュラーが発生した際に状況把握がしやすくなり、サポートエンジニアとのコミュニケーションがより円滑になるかと思います。
▮ ログの確認以前に、どのログを取得すればよいかわからない
先ほどまでの話とは少し別なところで、そもそもどの製品のログバンドルを取得すればよいのか、
xxx製品のログの取得方法がわからない、といったケースもあるかと思います。
そのような場合は、その旨をSR発行時にサポートエンジニアに連携していただければ調査に必要な情報をご連絡いたします。
ログの確認をすぐにでもはじめて欲しいといった場合には、余分なログがあっても構いませんので、
関連しそうだと思う製品のログをすべて取得するというのも1つの手段かと思います。
たとえ無駄な情報が多くても、サポートエンジニアがその中から必要な情報をピックアップして確認を行いますのでご安心ください。
一方で、ログサイズが大きすぎてアップロードが難しい、運用環境の制限で取得が難しい、といった状況に遭遇することもあるかと思います。
そのような場合も、一度サポートエンジニアに状況をご相談いただければと思います。
参考までに、以下のKBに各種製品のログファイルの場所がまとめられておりますのでチェックしてみてください。
* VMware KB: Location of log files for VMware products (1021806)
http://kb.vmware.com/kb/1021806
—
いかがでしたでしょうか。第3回では第1回、2回でご紹介したサポートリクエスト発行までの流れのなかで、つまずきやすいポイントをいくつかピックアップしてご紹介しました。
もちろん、ここに挙げた例以外にも様々なケースが存在しますが、ご紹介した話が少しでもトラブル対応時の手助けになればと思います。
以上、第3回でした。ではまたSRでお会いしましょう！
こんな感じで日々ご支援しております！
vSphere 問題解決までのヒント!
第１回 トラブル発生時に役立つ 4 つのリソース
第２回 サポートリクエスト（SR）と情報採取
第３回 実践編
