Pacemaker 資料一覧

Pacemaker + Heartbeatによる2ノードクラスタ設定(Apache, Samba)

2013/12/4更新

対応バージョン: Pacemaker 1.0.13, Heartbeat 3.0.5

Pacemaker + Heartbeatを使って2ノードのクラスタを構築する手順を示す。導入OSはCentOS 6.4。

PacemakerとHeartbeatはそれぞれ以下の役割を担い、協調して動作する。

Pacemaker

仮想IP、ApacheやMySQL等といった各種サービスをリソースとして扱い、起動/停止、動作状態の監視を行う。何らかの異常を検知すると自動的に再起動やフェールオーバなどの制御を行う。

Heartbeat

メンバーノードをクラスタとして動作させる。電源不良やKernel Panicといった低レイヤに関する障害が発生した場合にノードの切り離しや再起動などの制御を行う。

構築環境

ここでは以下の環境を構築する。

提供サービス

Apache
Samba

片系のノードで両サービスを提供し、障害時やメンテナンス時はサービス単位で停止/起動・フェールオーバ可能とする。

ノード

サーバ1: s1 (em1: 192.168.1.121, p4p1: 192.168.9.121)
サーバ2: s2 (em1: 192.168.1.122, p4p1: 192.168.9.122)

・em1: サービス提供用

・p4p1: インターコネクト(ハートビート)用

GWは192.168.1.1とする。

仮想IP

Apache用: 192.168.1.101
Samba用: 192.168.1.100

以降の設定にあたっては、クラスタが構築し終わるまではそれぞれのノードで同じ作業を行う。

インターコネクト用NIC設定

em1用の設定をコピーしてインターコネクト用NICの設定を行う。

# cd /etc/sysconfig/network-scripts
# cp ifcfg-em1 ifcfg-p4p1
# vi ifcfg-p4p1

以下を削除

GATEWAY=192.168.1.1
DNS1=xxx.xxx.xxx.xxx
DEFROUTE=yes

以下を変更

DEVICE=p4p1
HWADDR=xx:xx:xx:xx:xx:xx
IPADDR=192.168.9.xxx

networkサービス再起動

# service network restart

相手のインターコネクト用NICが見えることを確認

# ping 192.168.9.xxx

Pacemaker, Heartbeatインストール

Linux-HA Japanよりパッケージを取得してインストールする。

pacemaker-1.0.13-1.1.el6.x86_64.repo.tar.gz (64bit用)
pacemaker-1.0.13-1.1.el6.i686.repo.tar.gz (32bit用)

ここでは64bit用をインストールする。

# tar xvzf pacemaker-1.0.13-1.1.el6.x86_64.repo.tar.gz
# mv pacemaker-1.0.13-1.1.el6.x86_64.repo /tmp
# cd /tmp/pacemaker-1.0.13-1.1.el6.x86_64.repo
# yum -c pacemaker.repo install pacemaker-1.0.13-1.el6.x86_64 heartbeat-3.0.5-1.1.el6.x86_64 pm_extras-1.3-1.el6.x86_64
# yum list installed | grep pacemaker
cluster-glue.x86_64     1.0.11-1.el6    @pacemaker
                        1.0.11-1.el6    @pacemaker
corosync.x86_64         1.4.5-1.el6     @pacemaker
corosynclib.x86_64      1.4.5-1.el6     @pacemaker
heartbeat.x86_64        3.0.5-1.1.el6   @pacemaker
heartbeat-libs.x86_64   3.0.5-1.1.el6   @pacemaker
libesmtp.x86_64         1.0.4-16.el6    @pacemaker
pacemaker.x86_64        1.0.13-1.el6    @pacemaker
pacemaker-libs.x86_64   1.0.13-1.el6    @pacemaker
pm_extras.x86_64        1.3-1.el6       @pacemaker
resource-agents.x86_64  3.9.5-1.el6     @pacemaker

(*) pm_extrasをインストールするとインターコネクトLAN故障が標準ツールで見えるようになる。

ファイアウォール設定

インターコネクト通信用に694/udpを許可する。

# cd /etc/sysconfig
# vi iptables

以下の行を追加

-A INPUT -p udp -m udp --dport 694 -j ACCEPT

iptables再起動

# service iptables restart

Heartbeat設定

まず低レイヤを制御するHeartbeatを設定する。

# vi /etc/ha.d/ha.cf
pacemaker on

debug 0
udpport 694
keepalive 2
warntime 7
deadtime 10
initdead 10
logfacility local1

ucast p4p1 192.168.9.121
ucast p4p1 192.168.9.122

ping 192.168.1.1

node s1
node s2

watchdog /dev/watchdog
respawn root /usr/lib64/heartbeat/ifcheckd

以下、主なパラメータについて説明する。

pacemaker

リソース制御にPacemakerを使用するかどうか

udpport

インターコネクト通信で使用するudpポート

keepalive

インターコネクト通信の送信間隔(秒)

warntime
deadtime

インターコネクト通信途絶後に警告(warn)あるいは故障(dead)と判断するまでの時間(秒)

initdead

初期起動時に他のサーバの起動を待つ時間(秒)

logfacility

syslogのファシリティ

ucast

インターコネクト通信に使用するデバイスとIPアドレスの指定

ping

ネットワーク監視用に各ノードからpingを送信するIPアドレス。一般的にはルータなどを指定する。

node

クラスタに参加するノード名

watchdog

kernel提供のsoftdogデバイス名

respawn

起動するサブプロセスの指定

(*) respawnで指定しているifcheckdはpm_extrasに含まれるLinux-HA Japanオリジナルパッケージで、これを使うとインターコネクト通信が正常かどうかを見えるようになる。

続いて各ノードがクラスタメンバーとして動作できるように認証ファイルを配置する。

# vi /etc/ha.d/authkeys
auth 1
1 sha1 xxxxxxxx ← 任意のパスフレーズ
# chmod 0600 /etc/ha.d/authkeys

またPacemakerはログ量が多いので、必須ではないが別ファイルに切り出したほうがよい。

# cd /etc
# cp -p rsyslog.conf rsyslog.conf.org
# vi rsyslog.conf
:
local1.*        /var/log/ha-log

(*) syslogのファシリティは前述のha.cfで変更可能

syslog再起動

# service rsyslog restart

Heartbeat起動

これでクラスタ化の準備ができたのでメンバーノード毎にHeartbeatを起動していく。

まずサーバ1(s1)。

# service heartbeat start

# crm_mon -A
============
Last updated: Fri Sep  6 21:26:14 2013
Stack: Heartbeat
Current DC: s1 (655c8a37-f03a-4b07-bece-d32b39adc80a) - partition with quorum
Version: 1.0.13-30bb726
1 Nodes configured, unknown expected votes
0 Resources configured.
============

Online: [ s1 ]


Node Attributes:
* Node s1:

サーバ1がオンラインになるので別ターミナルを開いてサーバ2(s2)でもHeartbeatを起動する。

# service heartbeat start

これによりサーバ1,2ともオンラインになる。

# crm_mon -A
============
Last updated: Tue Sep 10 21:10:29 2013
Stack: Heartbeat
Current DC: s1 (b7cf0247-85a1-472a-8430-fb38728488fd) - partition with quorum
Version: 1.0.13-30bb726
2 Nodes configured, unknown expected votes
0 Resources configured.
============

Online: [ s1 s2 ]


Node Attributes:
* Node s1:
    + s2-p4p1                           : up
* Node s2:
    + s1-p4p1                           : up

STONITH機能無効化

STONITHとは「Shoot The Other Node In The Head」の略で、相手ノードが不安定になった時にそのノードをOSごと再起動/停止する機能である。

この機能はデフォルトで有効になっているが、リソースを何も設定しない現状では以下のエラーになる。

# crm_verify -LV
crm_verify[24723]: 2013/09/09_21:39:21 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
crm_verify[24723]: 2013/09/09_21:39:21 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
crm_verify[24723]: 2013/09/09_21:39:21 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid

そこでひとまず無効にしておく。

既にクラスタが構成されているので設定変更は任意のノードで1回だけ実行すれば自動的にメンバーノードに反映される。

# crm configure show
node $id="b7cf0247-85a1-472a-8430-fb38728488fd" s1
node $id="e959ca5c-76e4-43c4-8641-6c6c71ac8fbc" s2
property $id="cib-bootstrap-options" \
        dc-version="1.0.13-30bb726" \
        cluster-infrastructure="Heartbeat"

# crm configure property stonith-enabled="false"

# crm_verify -LV
(エラーなし)

# crm configure show
node $id="b7cf0247-85a1-472a-8430-fb38728488fd" s1
node $id="e959ca5c-76e4-43c4-8641-6c6c71ac8fbc" s2
property $id="cib-bootstrap-options" \
        dc-version="1.0.13-30bb726" \
        cluster-infrastructure="Heartbeat" \
        stonith-enabled="false"

また、メンバーノードが2台の場合はquorumによる管理が不要になるのでcrm_attribute(*)をあわせて無効にしておく。

(*) クラスタに参加するメンバーノードが過半数に満たない場合の動作ポリシー

# crm configure property no-quorum-policy="ignore"

Pacemaker設定

Heartbeatの設定が終わったら次はPacemakerでリソースの定義を行う。

まずサービス提供用の仮想IPを定義する。

RA(Resource Agent)としてIPaddr2を使用し、以下のパラメータを設定する。

ip

仮想IPアドレス

nic

使用NIC

cidr_netmask

ネットマスク

# crm configure primitive vip_httpd ocf:heartbeat:IPaddr2 params \
ip="192.168.1.101" nic="em1" cidr_netmask="24" op monitor interval="10s"

# crm configure primitive vip_samba ocf:heartbeat:IPaddr2 params \
ip="192.168.1.100" nic="em1" cidr_netmask="24" op monitor interval="10s"

リソースを定義するとすぐ有効になる。

# crm configure show vip_httpd
primitive vip_httpd ocf:heartbeat:IPaddr2 \
        params ip="192.168.1.101" nic="em1" cidr_netmask="24" \
        op monitor interval="10s" \
        meta target-role="Started"

# crm configure show vip_samba
primitive vip_samba ocf:heartbeat:IPaddr2 \
        params ip="192.168.1.100" nic="em1" cidr_netmask="24" \
        op monitor interval="10s"

# crm_mon -A
============
Last updated: Tue Sep 10 22:19:44 2013
Stack: Heartbeat
Current DC: s1 (b7cf0247-85a1-472a-8430-fb38728488fd) - partition with quorum
Version: 1.0.13-30bb726
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Online: [ s1 s2 ]

vip_httpd     (ocf::heartbeat:IPaddr2):       Started s1
vip_samba     (ocf::heartbeat:IPaddr2):       Started s1

Node Attributes:
* Node s1:
    + s2-p4p1                           : up
* Node s2:
    + s1-p4p1                           : up

仮想IPが使えるようになっていることをpingで確認する。

# ping 192.168.1.101
PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=0.404 ms
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=0.403 ms
64 bytes from 192.168.1.101: icmp_seq=3 ttl=64 time=0.401 ms
^C

# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.324 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.323 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.320 ms
^C

続いて各サービスを定義する。

まずApache。RAはapacheを使用する。

# crm configure primitive httpd ocf:heartbeat:apache params \
configfile="/etc/httpd/conf/httpd.conf" statusurl="http://192.168.1.101:443/" \
op start interval="0" timeout="90" on-fail="restart" \
op monitor interval="10" timeout="60" on-fail="restart" \
op stop interval="0" timeout="300" on-fail="block"

(*) statusurlはRAの仕様上「http://」で始まらなければならない。SSLサイトの場合は「http://xxx.xxx.xxx.xxx:443/」のように指定する。

次にSamba。RAは用意されていないのでSamba付属のinitスクリプト(LSB)を使用する。

# crm configure primitive nmb lsb:nmb \
op start interval="0" timeout="15" on-fail="restart" \
op monitor interval="15" timeout="15" on-fail="restart" \
op stop interval="0" timeout="15" on-fail="block"

# crm configure primitive smb lsb:smb \
op start interval="0" timeout="15" on-fail="restart" \
op monitor interval="15" timeout="15" on-fail="restart" \
op stop interval="0" timeout="15" on-fail="block"

Pacemakerで規定する故障には以下の3種類がある。

start

起動失敗

stop

停止失敗

monitor

監視による検出

故障が発生した際はon-fail="xxx"の設定に応じた動作を行う。指定できる動作には以下のものがある。

block

故障したリソースの管理を停止し待機する。

fence

リソース故障が発生したメンバーノードをSTONITHによって再起動し、フェールオーバする。

ignore

何の処理も行わない。

stop

故障したリソースを停止し、他のメンバーノードへフェールオーバさせない。

restart

故障したリソースを他のメンバーノードへフェールオーバする(デフォルト)。

仮想IPとサービスの定義が終わったのでサービス毎のグルーピングを行う。グループ名には任意の名前が指定できる。

web

Apache用仮想IPとApacheのグルーピング

# crm configure group web vip_httpd httpd
samba

Samba用仮想IPとSambaのグルーピング

# crm configure group samba vip_samba nmb smb

これでグループ単位でフェールオーバやオンライン/オフラインの制御ができるようになる。

# crm_mon -A
============
Last updated: Mon Oct  7 20:46:35 2013
Stack: Heartbeat
Current DC: s1 (b7cf0247-85a1-472a-8430-fb38728488fd) - partition with quorum
Version: 1.0.13-30bb726
2 Nodes configured, unknown expected votes
Online: [ s1 s2 ]

 Resource Group: web
     vip_httpd  (ocf::heartbeat:IPaddr2):       Started s1
     httpd      (ocf::heartbeat:apache):        Started s1
 Resource Group: samba
     vip_samba  (ocf::heartbeat:IPaddr2):       Started s1
     nmb        (lsb:nmb):      Started s1
     smb        (lsb:smb):      Started s1

Node Attributes:
* Node s1:
    + s2-p4p1                           : up
* Node s2:
    + s1-p4p1                           : up

グループやリソース、ノードの制御はcrmコマンドで行う。以下に一例を示す。

フェールオーバ
# crm resource move web s2 force
グループ停止
# crm resource stop web
リソースに故障履歴(Faied actions)が付いた場合のクリーンアップ
# crm resource cleanup httpd s1
フェールオーバ/フェールバック先に移動禁止フラグが付いた場合のクリア
# crm resource unmove httpd
ノードスタンバイ(当該ノード上でリソースが動作している場合フェールオーバする)
# crm node standby s1

(*)ノードをメンテナンスする場合などに使用

ノードオンライン
# crm node online s1

参考資料

今回のようにシンプルな構成であれば比較的簡単に構築ができるが、複雑な構成の場合は構築や障害発生時などに対応に時間がかかることが考えられるので、以下に参考資料を紹介しておく。