前回の[保守運用編(1)] では、保守運用で役立つ2つのツールと、ネットワーク故障が起こった場合どうなるの?について説明してきました。続編である今回は、リソースが故障した場合どうなるの?と、Pacemakerのプロセス故障が起きた場合どうなるの?を説明していきます。それではさっそく参りましょう!
リソースが故障した場合どうなるの?
Pacemakerで想定されるリソースの故障は、起動処理が失敗したときのstart故障、監視処理で故障を検知したときのmonitor故障、停止処理が失敗したときのstop故障の3つのパターンがあります。それぞれの故障が発生した時、Pacemakerは表1にまとめたon-fail設定に応じて動作します。今回の環境では、startとmonitorにはon-failを設定していないため、デフォルト値である"restart"が適用されます。stopには、第3回 でも紹介されたように停止処理に失敗したときにSTONITHを実行させるため、"fence"を設定しています。
表1 リソース故障時のon-fail動作一覧
on-fail設定値 Pacemakerの動作
block 故障したリソースの管理を停止し、何もせず保守者が介在するまで待機します。
fence リソース故障が発生したサーバをSTONITHによって再起動し、リソースを他のサーバへフェイルオーバさせます。
ignore 何も処理を行いません。
stop 故障したリソースを停止し、他のサーバへフェイルオーバさせません。
restart 故障したリソースを他のサーバへフェイルオーバさせます。
ここでは、リソースのmonitor故障検知時の動作について説明します。Pacemakerはリソースのmonitor故障を検知した場合は、故障が発生したサーバにフェイルカウント(フラグ)を立て、リソースのフェイルオーバ処理を実施します。
図1 リソース故障
故障を発生させてみよう
では、実際にリソース故障を発生させて、Pacemakerの動きを見てみましょう。今回はリソース故障を擬似的に起こすため、Pacemaker稼働中にhttpdを停止します。
# /etc/init.d/httpd stop
httpd停止後crm_monコマンドを実行すると、pm01でhttpdのmonitor故障を検知したため、故障回数と故障内容が表示され、リソースがpm02にフェイルオーバしていることが確認できます。
Online: [ pm01 pm02 ]
Resource Group: web
vip (ocf::heartbeat:IPaddr2): Started pm02
httpd (ocf::heartbeat:apache): Started pm02
省略
Migration summary:
Node pm01:
httpd: migration-threshold=1 fail-count=1
* Node pm02:
Failed actions:
httpd_monitor_10000 (node=pm01, call=76, rc=7, status=complete): not running
このとき、pm01のpm_logconv.outにはhttpdのリソースが故障したログが出力されます。
Mar 30 13:08:51 pm01 ERROR: Resource httpd does not work. (rc=7)
復旧してみよう
復旧では、pm01で発生したリソース故障のフェイルカウント(フラグ)を削除し、再びpm01でもリソースが稼動できるようにします。フェイルカウントの削除には"crm resource cleanup [故障リソース名] [故障発生サーバ名]"を実行します。このコマンドはクラスタ内のどのサーバからでも実行可能です。
# crm resource cleanup httpd pm01
Cleaning up httpd on pm01
Waiting for 2 replies from the CRMd..
コマンド実行後のモニタ表示では、故障回数と故障内容の表示が消えていることが確認できます。この状態になればリソースをpm01に移動させることができます。
Online: [ pm01 pm02 ]
Resource Group: web
vip (ocf::heartbeat:IPaddr2): Started pm02
httpd (ocf::heartbeat:apache): Started pm02
省略
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ default_ping_set : 100
+ pm01-eth1 : up
+ pm01-eth2 : up
省略
Migration summary:
* Node pm01:
* Node pm02:
リソースを稼動していたサーバに戻したい場合は、以下のようにcrm resource moveコマンドを使ってリソースをpm02からpm01に移動します。
# crm resource move web pm01 force
コマンド実行後のモニタ表示では、以下のようにリソースがpm02からpm01に移動していることが確認できます。
Online: [ pm01 pm02 ]
Resource Group: web
vip (ocf::heartbeat:IPaddr2): Started pm01
httpd (ocf::heartbeat:apache): Started pm01
pm01でリソースが稼動していることを確認した上で、以下のコマンドを実行します。
# crm resource unmove web
Pacemakerのプロセス故障が起きた場合はどうなるの?
Pacemakerは複数のプロセスで構成されており、親プロセスは子プロセスの監視を行っていますが、"親プロセスが故障したら何もできないのでは?"という疑問もあるかと思います。しかしそこは、クラスタシステム。クラスタ制御機能にHeartbeat3を使用している場合、親プロセスが故障すると、watchdogとの連携によりサーバを再起動してサービスを継続します。各プロセス故障時の動作を表2にまとめます。
表2 Pacemakerプロセス故障時の挙動(クラスタ制御機能にHeartbeat3使用の場合)
Pacemaker プロセス プロセス故障時の挙動
heartbeat: master control process サーバ再起動
ccm
cib
crmd
lrmd
pengine
heartbeat: FIFO reader プロセス再起動
heartbeat: write: bcast ethX
heartbeat: read: bcast ethX
stonithd
attrd
ifcheckd
ここでは、Pacemakerの親プロセスである、"heartbeat: master control process"が故障した場合を説明します。"heartbeat: master control process"が故障すると、watchdogによりサーバが再起動され、pm02が相手ノードを認識できなくなることでSTONITHが実行されます。プロセス故障が発生したサーバで稼動させていたリソースは、pm02にフェイルオーバします。
図2 Pacemakerプロセス故障
故障を発生させてみよう
では、実際にプロセス故障を発生させて、Pacemakerの動きを見てみましょう。pm01で"heartbeat: master control process"のプロセスを故障させます。
# ps -aef | grep "master control process" | grep -v grep
root 1035 1 0 14:06 ? 00:00:00 heartbeat: master control process
# kill -KILL 1035
プロセス故障後pm02のモニタ表示では、以下のようにpm01のPacemakerは停止し、リソースがpm02にフェイルオーバしていることが確認できます。また、pm01のPacemakerが停止しているので、pm01に関する属性情報がモニタに表示されていないことも確認できます。
Online: [ pm02 ]
OFFLINE: [ pm01 ]
Resource Group: web
vip (ocf::heartbeat:IPaddr2): Started pm02
httpd (ocf::heartbeat:apache): Started pm02
Resource Group: grpStonith1
stonith1-1 (stonith:external/stonith-helper): Started pm02
stonith1-2 (stonith:external/ipmi): Started pm02
stonith1-3 (stonith:meatware): Started pm02
Clone Set: clone_ping
Started: [ pm02 ]
Stopped: [ ping:0 ]
Node Attributes:
* Node pm02:
+ default_ping_set : 100
Migration summary:
* Node pm02:
このとき、pm01のpm_logconv.outにはプロセス故障のERRORが出力されます。
pm01(Pacemakerプロセス故障サーバ)
Mar 30 14:42:59 pm01 ERROR: Emergency Shutdown: Master Control process died.
また、pm02のpm_logconv.outにはSTONITHを実行したログが出力され、pm01はpm02からのSTONITHによって停止したことがわかります。
pm02(STONITH実行サーバ)
Mar 30 14:43:09 pm02 info: Try to STONITH (RESET) the Node pm01 to stonith1-1 (external/stonith-helper) (pid=735)
Mar 30 14:43:54 pm02 ERROR: Failed to STONITH the Node pm01 with one local device (exitcode=5). Will try to use the next local device.
Mar 30 14:43:54 pm02 info: Try to STONITH (RESET) the Node pm01 to stonith1-2 (external/ipmi) (pid=9137)
Mar 30 14:43:57 pm02 info: Succeeded to STONITH (RESET) the Node pm01 by Node pm02.
復旧してみよう
復旧では、pm01起動後にクラスタに組み込まれることを確認します。Pacemakerの自動起動を有効にしていない場合は、pm01でPacemaker起動コマンドを実行します。
# /etc/init.d/heartbeat start
Starting High-Availability services: [ OK ]
Pacemaker起動後、しばらくするとpm01がクラスタに組み込まれます。
Online: [ pm01 pm02 ]
Resource Group: web
vip (ocf::heartbeat:IPaddr2): Started pm02
httpd (ocf::heartbeat:apache): Started pm02
Resource Group: grpStonith1
stonith1-1 (stonith:external/stonith-helper): Started pm02
stonith1-2 (stonith:external/ipmi): Started pm02
stonith1-3 (stonith:meatware): Started pm02
Resource Group: grpStonith2
stonith2-1 (stonith:external/stonith-helper): Started pm01
stonith2-2 (stonith:external/ipmi): Started pm01
stonith2-3 (stonith:meatware): Started pm01
Clone Set: clone_ping
Started: [ pm01 pm02 ]
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ default_ping_set : 100
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
リソースを稼動していたサーバに戻したい場合は、"リソースが故障した場合どうなるの?"を見て、リソースの移動を行ってください。
まとめ
保守運用編では、ネットワーク故障、リソース故障、Pacemakerプロセス故障の運用手順を紹介しました。運用ポイントとしては、モニタ表示の見方です。モニタの表示がわかってしまえば、何の故障が発生したかなど、現在の状況がつかみやすくなりますので、是非覚えてくださいね。
これまで全5回にわたりPacemakerの歴史から構築、保守運用までを紹介してきましたが、いかがでしたでしょうか。まだまだ書き足りないこともたくさんありますが、少しでもPacemakerについての理解を深めていただければ幸いです。興味を持っていただけて、こんなときはどうするの? こんなログが出たんだけど…… そんな悩みが出てきたときには、メーリングリストに聞いてみると解決の糸口が見つかるかもしれませんよ。
お付き合いありがとうございました。
コラム : Pacemaker応援キャラって何? [その2]
前回 紹介したかな、かよ、に加えてもう2匹、応援キャラがいるの知ってます? ぺーちゃんと、ころちゃんです。言うまでもなく、PacemakerとCorosyncから名前を取ってきています。外見はリスのようにも見えますが、第1回 で説明しているように、Pacemakerロゴはうさぎをモチーフにしているので、これもうさぎです。
やはり、魔法少女ものアニメーションとかには、必ずマスコットキャラが必要ですよね? 電脳世界の住人という設定の2匹ですが、この先の展開はどうなるのか、ご期待(?)ください。
ぺーちゃん
ころちゃん