永遠のテーマですね、ストレージが遅くなる。よくあるのが、iSCSIやNFSを利用していて帯域が遅いとかレスポンスタイムが遅いとか、そもそもセッション数が凄まじい事になっているとか、色々と原因が考えられます。
その中で、WEB管理画面から「監視」->「イベント」と確認すると、こんなエラーが表示されている事があります。
・ 接続の問題により、ボリューム *** へのアクセスが失われました。回復処理が進行中です。まもなく結果が報告されます。
・ 接続の問題が発生後、ボリューム *** へのアクセスがリストアされました
というやつです。これ自体は稀にあるのですが、これが頻発している場合は注意が必要です。大体は以下のエラーも同時で出てしまっていると思います。
・デバイス *** のパフォーマンスが低下しました。I/O待ち時間は、平均値である **** マイクロ秒から ****** マイクロ秒に増加しました。
・デバイス *** のパフォーマンスが改善しました。I/O待ち時間は、******* マイクロ秒から ****** マイクロ秒に減少しました。
こうなる理由は多々あるようで、こちらのサイトでは ATS Heartbeat の無効化を検討してみるという手順を紹介しています。勿論再起動もいらないので、これを試す価値は十分にあると思います。
ただ、サーバ自体が長時間稼働している場合、かつこのI/O待ち時間が多発する、かつその待ち時間が7桁を超えていたら、経験上ほぼ間違いなくディスク不良が起こり始めています。
ハードウェアステータスで見ても、まだ緑なんですよ。これ。エラー訂正が走りまくってるのか何なのかは判りませんが、だいたいはHDDが故障寸前である事が多いです。当方の環境では、過去同様のエラー後数日でHDDが他界しました。勿論全てがこの類では無いと思いますが、早めにバックアップを取るか VMware vCenter Converter Standalone Client で他のESXiへ移動する事を強くオススメ致します。
当方の環境では定例的に vmdk をオンラインバックアップ取っているので、それを他のESXiサーバへ下記戻すだけで環境が復活します。DB関係は数時間単位でdumpを出力しているので、HDDが死亡しても最悪数時間前に巻き戻るだけで復旧できます。
ハードウェアは基本的に壊れるモノです。壊れた際に、どうやったら最も早い方法でリカバリーができるか、サービスを復帰させられるかが命です。原因とかそういう事は二の次・三の次です。とにかく、クライアントに迷惑がかからないよう、最低限の時間で復帰させる事に重点を起きましょう。
ちなみに今朝、このトラブルが起きたのですが、最初はあるESXiサーバで稼働している仮想OSから iowait が異常な数値を出して死活監視メールが来たからです。
(ちなみに弊社では全ての仮想サーバへ死活監視をしており、ちょっとした変化でもアラートメールが管理者一同及び関連会社へ飛ぶようになっています。)
最初はESXi自体がオンラインバックアップを取っていて、それでI/Oを食っていただけかな？と思ったのですが、しばらくしてもエラーは変わらず。寧ろレスポンスが悪化していました。
この時点でおかしいと思ってイベントを確認。やはりHDDのアクセス不良とI/O待ち時間が異常な数値を出していたので、これは ATS Heartbeat では無く、HDDへの書き込みがリトライしまくりの死亡寸前だと判断しました。vMotionで他のサーバへ移動させて完了です。
こんな事例もあるって事で、覚えておくとトラブルシュートが捗りますよ。