vmware-appmonitorによるアプリ監視

VMware vSphereにVMware HAという機能がある。

HAとは ※判っている人は読み飛ばし推奨

HAというのがHigh Availabilityという英語の略で、高可用性と訳されるように、サーバに何かあってもコンピュータ上のサービスを継続して動かし続けるような仕組みのことを指す。

例えば、1台のパソコンにあんなデータやこんなデータを溜め込んでいたのに、ある日パソコンが壊れてしまい、どうしても見れないということがあったとする。

この場合、データを外付けHDDやNASに溜め込んでいて、もう一台パソコンがあれば、あなたのあんなデータやこんなデータは直ぐに見ることができる。

簡単に言えば、HAというのは外付けのディスクと予備のサーバを準備しておいて、メインのサーバが壊れた場合に、自動的にメインで使っていた外付けのディスクを予備のサーバにつなげて、予備サーバでサービスを継続する仕組みのことである。

貴方が新本格ミステリ好きならば、麻耶雄嵩の「翼ある闇」のアレを思い浮かべると判りやすいかもしれない。

簡単なHAの場合は2台で済むが、予備機の台数が多いほど信頼性が増すので、システムの重要度に応じて台数が増えていく。

外付けディスクと書いたが、家で使うようなUSBのディスクではなく、光ケーブルとかSASケーブルとかで繋がった、ゴッツいディスク装置にHDDを多重化していっぱい載せた、これだけでン百万～ン億円の世界のものを使用することが多い。

(最近(ここ数年)はソフトウェア的にディスク装置と同じ働きを行って安くしようという動きもあるが、まだ歴史が浅いので一般的ではない。
2018/09/19追記:ハイパーコンバージドインフラ等でSDSが一般的になってきた。今ならvSANでいいんじゃないだろうか。)

また、サーバに関してもネットワークが途切れないよう、ポートが複数あるカードを複数載せたり、外付けディスクとの接続にしても経路を複数もたせたり、多少壊れても動くような余剰をもたせる(冗長化)。

どこまで冗長化するかというのは、どれくらい信頼性を求めるかということなので、「このシステムってどれぐらい止まっても大丈夫なんだっけ？」というのを予め決めておく必要がある。

間違っても一週間の停止が許容できるシステムに対して、「99.9％の稼働率」なんて求めちゃいけない。

可用性を上げるにはどうしても機器の冗長化や予備の部品の確保が必要になってくるので、サーバのコストが増えていくし、ちゃんと予備に切り替わるか、復旧はできるかのテストにかかる時間も増えていき、結果、システムのコストが上がるのだ。

(クラウドは機器の冗長化を事業者側でやってくれるので、この辺を気にしなくていいのが利用者としてのメリット。)

VMWare HAは基本ハードしか見てくれない

VMWareに限らず、ハイパーバイザーのHAが面倒を見てくれるのは主にハードウェアとネットワークの部分で、「ネットワークが切れた」「メモリ、CPU、HDDが故障してサーバが停止した」といった場合は待機系のサーバで仮想OSを起動してサービスを継続してくれるのだが、仮想OSの中で動いているアプリケーションが停止した場合にもうまいことやってサービスを継続してほしい場合だってある。

実機と同じように2個仮想OSを用意しておいて、片方でサービスが停止したらもう片方に切り替えるHAクラスタを作る方法もあるが、HAソフトウェアや構築、クラスタのテスト、仮想OSを2つ管理するコストも嵩むし、正直めんどくさい。(←個人的意見。大体この方法を選択するならvmware-appmonitorを使う必要がないので、この後書くことがなくなるのである。)

お高いソフトウェアを使えば簡単に実現してくれるものもあるが、予算が限られている悲しいSEにとっての一筋の光明がvmware-appmonitorである。

vmware-appmonitorで出来ること

vmware-appmonitorが何をするものかといえば、仮想OSが正常であるという信号をおくるためのものである。

デフォルトでは30秒に一回、HAホストに正常の信号が送られてこない場合に、VMWareは仮想OSが異常であると判定して「仮想OSの再起動」を行う。
あくまで信号を送るだけのツールなので、サービスが稼働しているかの判定ロジックは自分で書かないといけないし、30秒に一回vmware-appmonitorを実行するのもタスクなりループなりを自分で設定しないといけない。

例としてOracleでざっくりいえば、PMONが死んでて、Listenerも死んでる場合はvmware-appmonitorの信号を止めるといった処理をループするシェルやvb scriptを作ってやる必要がある。

アプリ障害時、仮想OSは待機系に移動しない

ただし、注意点としてはvmware-appmonitorで障害を検知した場合、仮想OSは待機系には移動しない。
現在動いているサーバ上でOSの再起動を行うだけ！という点は把握しておく必要がある。

既存システムでHAを行っている場合、OSが死んだ場合でも待機系に切り替わるので「サービスレベルが低下している。OSの障害の場合でも待機系に移動してほしい。」という突っ込みをいただくことがある。

「じゃあ仮想OS2つ準備してクラスタソフト入れて、ライセンス費用と構築費払ってくれたらやりますよ(にっこり)」というのが正解だが、どうせそんな予算ないんだから、VMWareHAの仕組みを説明して納得していただこう。
物理的にサーバ壊れてないんだから、待機系に問題が起こった仮想OSだけ移動したってあんまり意味がないのである。
VMware HAの仮想OSの障害発生時の動作も再起動による復旧なので、これはVMWare HAの思想としてそういうもんなのである。それが嫌なら金とスケジュールを見直せ！と言いたい。

具体的にどうするのか

＜2018/09/19 3年間放置してた内容の追記＞

バージョンに応じた「vSphere Guest SDK for vSphere X.X」をダウンロードする。LinuxとWindowsでファイルが分かれているので、ゲストに応じたものをダウンロード。

パスを通したりする必要はあるが、そこらへんはドキュメントを見て設定すればOK。

なんかコンパイルしないとダメな感じでドキュメントに書いてたりするが、すぐに使えるexeやバイナリが入っているので、気にしなくてOK。

下記のようにオプションを付けて実行する。

vmware-appmonitor { enable | disable | markActive | isEnabled | getAppStatus | postAppState }

enable…監視開始。30秒以内にmarkActiveの送信が切れると障害発生とみなされ仮想マシンが再起動する。

disable…監視停止。メンテナンス時などで停止する場合に使用。

markActive…サービスが生きていることを知らせる。30秒に一回打たないと仮想マシンが再起動する。

isEnabled…監視しているかどうか確認する。

getAppStatus …監視状態を確認する。GreenがOK、REDは再起動しそうな状態、Grayは監視していない時。

postAppStateは使ったことないので不明。

監視したいサービスの状態を確認するコマンドと、vmware-appmonitorを組み合わせて、30秒以内に一回、自作シェルやクーロンなりで監視スクリプトを実行してやれば良いのだが、よくdisableにするの忘れて仮想マシンが再起動しがちなので、サービスの起動停止スクリプトにdisableを投げるコマンドを組み込んでおくとミスが防げる。

また、サーバ起動直後にenableにしてしまうと、サービスが起動するまで時間がかかるような物の場合、サービス異常だと思って監視スクリプトでdisableを投げて再起動しがち。

さらに、サービス監視スクリプトが高負荷で一時的に反応が遅くなった場合にも、容赦なく再起動したりしがち。

なので、個人的には監視スクリプトとmarkActiveを送るスクリプトを分離しといて、Linuxならファイルにステータス吐き出して、ファイルのステータスがNGだったらmarkActiveを停止するとかしてた。

楽ではないが有用

監視スクリプトを手作りする必要があり、楽ではないがサービスまで監視して対応しないといけない時には使える。