第5回　Pacemakerを運用してみよう！［保守運用編(2)］

前回の［保守運用編(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故障を検知した場合は、故障が発生したサーバにフェイルカウント（フラグ）を立て、リソースのフェイルオーバ処理を実施します。

故障を発生させてみよう

では、実際にリソース故障を発生させて、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にフェイルオーバします。

故障を発生させてみよう

では、実際にプロセス故障を発生させて、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についての理解を深めていただければ幸いです。興味を持っていただけて、こんなときはどうするの？こんなログが出たんだけど…… そんな悩みが出てきたときには、メーリングリストに聞いてみると解決の糸口が見つかるかもしれませんよ。

お付き合いありがとうございました。