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

はじめに

第3回では、Pacemakerの応用的な構築について紹介してきました。今回は、Pacemakerを運用してみよう！ということで、Pacemakerの保守運用の手順について2回に分けて紹介します。

今回保守運用を行う環境は、第2回で紹介されたリソース構成（apache.crmファイル）に、第3回で紹介されたSTONITHリソースstonith-helper、ipmi、meatwareを設定してみました。（⁠apache+stonith.crmファイル）

まずは、Pacemakerの保守運用で役立つ2つのツールについて説明します。

crm_mon

crm_monはPacemakerが制御しているリソース状態や、インターコネクトLAN、ネットワークの状態を確認できるツールです。crm_monについては、第2回、第3回でも紹介されていましたが、保守運用に必要なモニタの表示の意味を説明します。

Pacemakerが稼動しているサーバでcrm_monコマンドに -f と -A のオプションをつけて実行します。-f オプションは、リソースの故障状態の表示を、-A オプションはインターコネクトLANの状態や、ネットワーク監視の状態を表示します。httpdリソースの監視処理で故障を検知した場合の出力例は以下のようになります。

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:
    httpd: migration-threshold=1 fail-count=1
* Node pm02:#故障回数表示

Failed actions:
    httpd_monitor_10000 (node=pm01, call=78, rc=7, status=complete): not running#故障内容表示

サーバ状態表示: クラスタシステムを構成しているサーバ名と、Pacemakerの稼動状態が表示されます。Pacemakerが稼動しているサーバは"Online"と表示され、停止しているサーバは"OFFLINE"と表示されます。
リソース状態表示: Pacemakerが制御しているリソースの状態が表示されます。Resource Groupとして登録したリソースは、"Started サーバ名"と表示され、リソース稼動状態と稼働中のサーバ名がわかります。Cloneとして登録したリソースは、"Started: [ pm01 pm02 ]"などと表示され、リソース稼動状態と稼働中のサーバ名がわかります。
属性情報表示: インターコネクトLANの状態、ネットワーク監視の状態などが表示されます。Pacemakerでは、インターコネクトLANやネットワークの監視において、表1のように監視対象ごとにそれぞれ属性名と属性値を持っており、Pacemakerはそれぞれの属性値から監視先の正常/異常を判断しています。

表1　属性情報

監視先	属性名（表示形式）	属性値
監視先	属性名（表示形式）	正常値	異常値
インターネットコネクトLAN	サーバ名- インターフェース名	up	dead※
ネットワーク	default_ping_set	100	0

※　スプリットブレインなどで相手のサーバを一切認識できなくなったり、Pacemakerが停止しているサーバの状態については、表示されなくなります。

故障回数表示: リソースの故障状態が表示されます。リソースの故障を検知すると、故障が発生したサーバと故障リソースの情報を表示します。故障回数表示に表示される故障情報は、サーバでリソース故障が起きたというフラグにも使用されており、そのフラグのことをフェイルカウントと呼びます。また、migration-threshold が"1"に設定されているため、1回の故障でフェイルオーバが発生していることがわかります。（⁠migration-thresholdについては第2回を参照）
故障内容表示: 故障回数表示で表示されたリソースの故障内容として、故障オペレーション（start/monitor/stop⁠）⁠、故障サーバ名、リターンコード（rc）が表示されます。ただし、故障内容表示はリソースの故障が発生した場合のみ表示されます。

pm_logconv

Pacemaker標準のログは出力が多く、初めて見る人にとっては、少しわかりにくいログになっています。そこで、Linux-HA Japanのオリジナルパッケージであるpm_logconvを使用すると、運用上必要なログだけを出力することができます。また、pm_logconvを使用するとフェイルオーバが発生した際に、"Start Fail-over"のログが出力されるようになるため、Pacemaker稼動中にリソースのフェイルオーバが発生したかどうかを簡単に知ることができます。

pm_logconvを使用するには、Pacemakerのリポジトリパッケージからyumでpm_logconvのパッケージを追加インストールし、起動設定（/etc/inittab）と動作設定（/etc/pm_logconv.conf）を行います。

追加インストール

# yum -c /tmp/pacemaker-1.0.10-1.4.1.el5.x86_64.repo/pacemaker.repo install pm_logconv-hb

起動設定

# vi /etc/inittab
  ……
 logc:2345:respawn:/usr/share/pacemaker/pm_logconv/pm_logconv.py  ← /etc/inittabに設定追加

inittabに追加した設定を反映させるために、以下のコマンドを実行します。

# telinit q

動作設定

# vi /etc/pm_logconv.conf
  ……
 [Settings]
 ha_log_path = /var/log/ha-log    ← 第2回でsyslog.confの最後に追記したPacemakerのログファイルパスを設定
 output_path = /var/log/pm_logconv.out	← pm_logconvのログ出力ファイルパスを設定
 #hostcache_path = /var/lib/heartbeat/hostcache
 #syslogformat = True
 #reset_interval = 60
 attribute_pingd = default_ping_set, lt, 100 ← ネットワーク監視を行う場合コメント(#)をはずす
 #attribute_diskd = diskcheck_status, eq, ERROR
 #attribute_diskd_inner = diskcheck_status_internal, eq, ERROR
 #logconv_logfacility = daemon
 act_rsc = vip httpd ← サービスリソースの最上位と最下位のリソースIDを設定
  ……

設定ファイルの変更を行ったので、再度読み込ませるため以下のコマンドでpm_logconvを再起動します。

# /usr/share/pacemaker/pm_logconv/pm_logconv.py -k

例としてリソース起動時のログを比較してお見せします。

Pacemaker標準ログ

Mar 30 11:51:04 pm01 lrmd: [29104]: info: rsc:httpd:39: start
Mar 30 11:51:05 pm01 crmd: [29107]: info: process_lrm_event: LRM operation httpd_start_0 (call=39, rc=0, cib-update=49, confirmed=true) ok

pm_logconvのログ（pm_logconv.out）

Mar 30 11:51:04 pm01 info: Resource httpd tries to start.
Mar 30 11:51:05 pm01 info: Resource httpd started. (rc=0)

Pacemaker標準ログでは、プロセスIDやデーモンの情報が出力されていますが、pm_logconv.outでは、リソースの起動に関する情報のみが出力されており、見た目にもわかりやすいことがご理解いただけたのではないでしょうか。

それでは、実際にこの2つのツールを使って保守運用を行っていきましょう！！

ネットワーク故障が起こった場合どうなるの?

Pacemakerにおいてネットワークを監視するのは、第2回で紹介された pingd です。pingdはネットワーク故障を検知すると、default_ping_set の値を異常を示す"0"に更新します。その後Pacemakerは default_ping_set の値からネットワーク故障が発生したと判断し、リソースのフェイルオーバ処理を実施します。

故障を発生させてみよう

では、実際にネットワーク故障を発生させて、Pacemakerの動きを見てみましょう。今回はネットワーク故障を起こすため、サービスLAN用のLANケーブルを引き抜きます。

LANケーブルを引き抜いた後crm_monコマンドを実行すると、default_ping_setの属性値が異常を示す"0"となっていて、リソースがpm02にフェイルオーバしていることが確認できます。

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                  : 0    : Connectivity is lost
    + pm02-eth1                         : up
    + pm02-eth2                         : up

このとき、pm01のpm_logconv.outにはネットワークの故障検知のログと、default_ping_setの属性値を"0"に更新したログが出力されます。

Mar 30 11:53:28 pm01 ERROR: Network to 192.168.68.2 is unreachable.
Mar 30 11:53:31 pm01 ERROR: Network to 192.168.68.2 is unreachable.
Mar 30 11:53:33 pm01 info: Attribute "default_ping_set" is updated to "0".

復旧してみよう

復旧では、ネットワークの監視が正常に戻ることを確認します。引き抜いていたサービスLAN用のLANケーブルを再び接続し、ネットワークを復旧します。

ネットワークの状態が回復すると、モニタ表示のdefault_ping_setの属性値が異常を示す"0"から正常を示す"100"に変わります。この状態になればpm01でリソースを稼動させることができます。

 Node Attributes:
 * Node pm01:
     + default_ping_set                  : 100
     + pm02-eth1                         : up
     + pm02-eth2                         : up

リソースを稼動していたサーバに戻したい場合は、"crm resource move [リソースグループ名] [移動先サーバ名] force"を実行して、リソースをpm02からpm01に移動します。このコマンドはクラスタ内のどのサーバからでも実行可能です。また、コマンド実行時にWARNINGが出力されますが、後の手順を説明しているだけなので気にしないでください。

# 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

crm resource moveコマンドでは、そのサーバでリソースを稼動できない状態としているため、元に戻す必要があります。pm01でリソースが稼動していることを確認した上で、"crm resource unmove [リソースグループ名]"を実行します。

# crm resource unmove web

「保守運用編(1)」の今回は、Pacemakerの保守運用で役立つ2つのツールと、ネットワーク故障が起こった場合どうなるの？を紹介しました。次回は、リソースが故障した場合どうなるの？とPacemakerのプロセス故障が起きた場合どうなるの？について紹介します。お楽しみに!