HAを見守る「Watchdog」と「STONITH」：Heartbeatでかんたんクラスタリング（3）（2/3 ページ）

[花島タケシ，VA Linux Systems Japan株式会社]

Watchdogを使ってみよう

　第1回の記事で紹介したとおり、Heartbeatでは外部Watchdog機能との連携を提供しています。

　Watchdogとは「番犬」という名称のとおり、ある特定のプロセスを監視し、一定期間の間応答がなかった場合、そのプロセスを終了させる役割を果たします。Watchdogというのは一般的な名称で、Heartbeatと連携できるWatchdogとしては、ソフトウェアのもの、ハードウェアのものなど、複数提供されています。

　この記事では読者の方すべてが検証できるように、Linux Kernelで提供されるソフトウェアWatchdog（Softdog）を利用することにします。

Softdogの設定

　HeartbeatでWatchdog機能を使用するための設定は非常に簡単です。/etc/ha.d/ha.cfに「watchdog /dev/watchdog」を追加し、Heartbeatサービスを起動するだけです。ただし、すべてのノードで同じ設定にすることを忘れないでください。

　上記のようにWatchdogを設定した後でHeartbeatを起動すると、ログに、

heartbeat[5311]: 2007/12/25_11:37:41 notice: Using watchdog device: /dev/watchdog    

のように出力されます。また、cl_statusというコマンドを用いて、

# cl_status hbparameter -p watchdog

とすると、設定値が出力されます。以上でWatchdogの準備は整いました。

Watchdogの稼働テスト

　「tomato」と「surr」がHAクラスタ構成を取っており、Heartbeatが正常に動作している状態とします。リソースが動作しているノード（ここではtomatoとします）の方で、Heartbeat関連のプロセス情報を取得してみましょう。

[root@tomato ~]# ps aux | grep heartbeat
root      5311  0.0  0.6  12124 12124 ?        SLs  11:37   0:00 heartbeat: master control process
root      5314  0.0  0.2   5528  5528 ?        SL   11:37   0:00 heartbeat: FIFO reader 
root      5315  0.0  0.2   5524  5524 ?        SL   11:37   0:00 heartbeat: write: bcast eth1
root      5316  0.0  0.2   5524  5524 ?        SL   11:37   0:00 heartbeat: read: bcast eth1 
90        5321  0.0  0.1   4972  2012 ?        S    11:38   0:00 /usr/lib/heartbeat/ccm
90        5322  0.0  0.1   7472  3108 ?        S    11:38   0:00 /usr/lib/heartbeat/cib
root      5323  0.0  0.1   4952  1988 ?        S    11:38   0:00 /usr/lib/heartbeat/lrmd -r
root      5324  0.0  0.2   4676  4676 ?        SL   11:38   0:00 /usr/lib/heartbeat/stonithd
90        5325  0.0  0.0   4652  1512 ?        S    11:38   0:00 /usr/lib/heartbeat/attrd
90        5326  0.0  0.1   5904  2804 ?        S    11:38   0:00 /usr/lib/heartbeat/crmd
root      5327  0.0  0.1   6488  2904 ?        S    11:38   0:01 /usr/lib/heartbeat/mgmtd -v
90        5332  0.0  0.1   5404  2060 ?        S    11:38   0:00 /usr/lib/heartbeat/tengine
90        5333  0.0  0.1   6076  2528 ?        S    11:38   0:00 /usr/lib/heartbeat/pengine
root      5820  0.0  0.0   3908   688 pts/0    S+   13:26   0:00 grep heartbeat

　Heartbeatは設計が少し複雑なため、このように関連したプロセスがいくつか表示されます。この状態で、heartbeat: master control process（MCP）のプロセス（上記サンプルでは、5311）をkillしてみましょう。

# kill -9 5311

　その後、同様にプロセス情報を取得すると、ほぼすべてのheartbeat関連のプロセスがなくなっていることが確認できると思います。さらに数十秒たつと、何もしなくても自然にサーバがリブートするはずです。

　これは、heartbeatのMCPが死亡したことにより、Watchdogデバイスへの書き込みが行われなくなり、それを検知したkernelのWatchdog機能が働いたためです。なお、Watchdogデバイスへ定期的に書き込みを行うプロセスはMCPだけです。なので、ほかのプロセスをkillしたときはWatchdog機能は働きません。

　あくまでこれはテストですが、実運用においては、例えばメモリリークなどが発生してリソースの枯渇が起きた場合などにこのような現象が発生し、サーバをフレッシュな状態にしてくれることがあります。このようなケースではとても有用です。ただし、一応、リソースのフェイルオーバーが発生していることは確認するようにしてください。

ほかのプロセスをkillしたら？

　コラムでも記しましたが、Heartbeatバージョン2.1.3では「ほかのプロセスをkillしたときの挙動」が変更されています。下記に、各プロセスをkillしたときの挙動を簡単に示します。

プロセス	挙動
heartbeat MCP	Watchdogが設定されていればサーバ自体の再起動が行われる。 そうでない場合は、ほぼすべての子プロセスとともにプロセス自体が消滅
heartbeat FIFO、lrmd、 stonithd、attrd、mgmtd	そのプロセスのみ再起動する
ccm、cib、crmd	サーバ自体の再起動が行われる
heartbeat read、 writeメディアプロセス	ペアになるread、writeメディアプロセスとともに再起動する
tengine、pengine	サーバ自体の再起動が行われる。ほかに稼働しているノードが あればDCノードが選出され、tengine、pengineがそのノードで起動する

　上記のうち、ccmやtengineをkillしたときの挙動については、バージョン2.1.3で変更されています。2.1.2まではサーバ自体の再起動は行われず、プロセスの再起動が行われていました。今回の変更は、Heartbeatサービスを「クリーン」な状態で動作させるというポリシーに沿ったものだと思われます。