実家のサーバが落ちる

実家に設置してるサーバがどうやら一度ドスンと落ちたようで、vSphereClient見てみるとVMが軒並みPowerOff状態になってました。おそらく実家のブレーカーが一度落ちたのでしょう・・・。時々発生することなので、じゃぁとりあえず起動するかとまずはUnityVSAを起動しようとしたのですが、どうも再起動を繰り返してる模様・・

なかなかでかい地雷を踏んだ模様

UnityVSAは仮想ストレージアプライアンスであり、CPU遅延にめちゃくちゃ弱い特性があるのは知っていて、これに加えてイメージは損も非常に発生しやすい代物だったりします。そういう時たいていは起動するにはするけど、メンテナンスモードに移行してしまってストレージサービスが立ち上がらない・・・というのが大体発生するもので、その場合はserviceアカウントでログインし、svc_reimageコマンドを実行することで改善させることができたものですが、今回は以下のようなエラーメッセージを出力してNMIスイッチが押され、リブートが繰り返されてるようでした。

panic+0xd0/0x209
ext4_handle_error+0x9e/0xa1
__ext4_grp_locked_error+0x116/0x18f

これ、どうも見てみるとKernel側の逆鱗に触れたようで、データ書き込みができないというものみたいでした。マウントすべきファイルシステムの一部で破損が生じたのでしょうかね・・・・困ったのがserviceモードで起動することすらできないということで・・・・・

今回とったリカバリー手法は

強制的にserviceモードで起動するようガイドするにはどうしたらいいだろうか・・・と探った結果、

「VSAのハード構成を変更して起動する」

ということで強制的にserviceモードへ移行できることがわかりました。

実はUnityVSAってハードウェアスペックを変更することを許さない製品でもあって、下手にCPUを足したりメモリ増設をしたりすると、ハードウェアチェックによって強制的にServiceモードへ移行させられます。この動作がNMIスイッチが押される処理の前に行われるんで、じつはNMI押される状態を回避できるのではないかと考え、実際そうしてみたらあっさり起動してくれました。ありがたやー。

さて、一度そうして起動したのち、serviceアカウントでログインしまして、svc_reimageコマンドを実行、イメージの再構築を設定したうえで、svc_shutdownにてVSAを停止。。スペックを元に戻して再度起動すると、OS起動時にイメージ再構築処理が開始され、その後無事に起動してきました。

どうも今回出たエラーはベースにしているLinux上の問題のようで、ある意味ファームウェアの地雷を踏んだ可能性が高いので、その後UnityVSA OEのバージョンアップも併せて行いました。よく考えてみれば、それまで入ってたOEバージョンって2年ぐらい前のバージョンだったんすよね・・・ほげーっとしてるうちにそんな長いこと稼働してたのかこいつ・・・とか思いながら、とりあえず無事復旧したことを喜んだのでありました。