【Pacemaker+Corosync】Apacheクラスタを組んでフェイルオーバー/フェイルバックテストをおこなう

Pacemaker+CorosyncでApacheクラスタを組み基本的な導入から操作、動きの確認をおこないます。

前提条件

  • Firewalldは停止
  • SELinuxはDisabled
  • Apache導入済み
  • STONITHは無効
  • 3回のリソース障害でフェイルオーバーする
  • 自動フェイルバックしない
  • pcsではなくcrmを利用する

crmを使う理由ですが、業務では未だにcrmを使うことが多いため、あえてcrmを利用しています。

3回のリソース障害でフェイルオーバーさせる理由は、failcountが上がる課程を見るためです。

Pacemakerのインストール

パッケージダウンロード

CentOS 7(RHEL 7)向けのパッケージは以下のサイトからダウンロードします。

参考 Pacemaker-1.1系リポジトリパッケージ News of Linux-HA Japan

インストール前の準備

Linux-HA Japanが提供するPacemakerとOS同梱のPacemakerを分けるためにCentOS-Base.repoのbaseとupdatesにexlude設定を追加します。

修正するファイル

設定ファイル: /etc/yum.repos.d/CentOS-Base.repo

修正内容

[base]に以下の行を追加する

exclude=pacemaker* corosync* resource-agents* crmsh* cluster-glue* libqb* fence-agents* pcs*

[updates]に以下の行を追加する

exclude=pacemaker* corosync* resource-agents* crmsh* cluster-glue* libqb* fence-agents* pcs*

インストール

先ほどダウンロードしたrpmファイルをインストールします。

# yum -y install pacemaker-repo-1.1.21-1.1.el7.x86_64.rpm
# yum -y install pacemaker-all

Pacemaker設定

Corosync設定ファイル作成

設定ファイル: /etc/corosync/corosync.conf

以下のとおり最低限の設定をおこないます。

quorumを設定を空にしていたところ、ノード障害を起こして再起動した後にONLINEにならずCorosyncのCPU使用率が100%に張り付く事象が発生しましたので、ご注意ください。

Corosync認証鍵

Corosync認証鍵設定をおこないます。鍵はnode1で作成し、その他のノードへコピーします。

[root@node1 ~]# corosync-keygen -l
[root@node1 ~]# scp /etc/corosync/authkey node2:/etc/corosync/authkey

Pacemaker設定ファイルの修正

Pacemakerの内部プロセス障害もノード障害として扱うように設定します。

設定ファイル: /etc/sysconfig/pacemaker

設定ファイルに以下の1行を追加します。

PCMK_fail_fast=yes

クラスタ起動スクリプトの設定

  • pacemakerサービス停止時にcorosyncサービスも同時に停止させる
  • corosyncプロセス故障時にwatchdog 機能を有効にする
  • corosyncプロセス故障検知を迅速(6秒以内)におこなう

設定ファイルはパッケージ標準ディレクトリからローカル設定ディレクトリにコピーしてからおこないます。

# cp -p /usr/lib/systemd/system/corosync.service /etc/systemd/system/
# vi /etc/systemd/system/corosync.service

viでcorosync.serviceを編集し、以下の3行をアンコメントアウトします。

#Restart=on-failure
#RestartSec=70
#ExecStartPre=/sbin/modprobe softdog

Pacemaker起動

# systemctl start pacemaker

node1とnode2がオンラインになっていることを確認します。

コマンド: crm_mon -1

2 nodes configured
0 resources configured

Online: [ node1 node2 ]

No active resources

Apacheの設定

server-statusを有効化する

新規に設定ファイルを作成します。

ファイル名: /etc/httpd/conf.d/server-status.conf

server-statusは自分自身(127.0.0.1)のみ接続できるように制限しています。

PIDファイル指定

httpd.confに「PidFile」がなかったので最終行に以下を追加します。

PidFile /var/run/httpd/httpd.pid

Apacheを再起動します。

# systemctl restart httpd

Pacemaker起動

node1とnode2でPacemakerを起動、併せて自動起動を設定しておきます。

# systemctl start pacemaker
# systemctl enable pacemaker

pacemaker起動後、node1とnode2がオンラインであることを確認します。

# crm_mon -1
0 nodes configured
4 resources configured

Online: [ node1 node2 ]

クラスタ設定

赤色の箇所は環境によって変わるので適宜修正が必要です。

青色の箇所「migration-threshold="3"」は何回障害が発生したら切り替わるか設定している箇所なので必要に応じて変更してください。

crm configure property no-quorum-policy="ignore" stonith-enabled="false"
crm configure rsc_defaults resource-stickiness="INFINITY" migration-threshold="3"
crm configure primitive httpd ocf:heartbeat:apache params configfile="/etc/httpd/conf/httpd.conf" statusurl="http://127.0.0.1/server-status" op monitor interval="10s"
crm configure primitive vip ocf:heartbeat:IPaddr2 params ip="192.168.0.203" nic="ens33" cidr_netmask="24" op monitor interval="10s"
crm configure group web vip httpd
crm configure primitive ping ocf:pacemaker:ping params name="default_ping_set" host_list="192.168.0.1" multiplier="1000" dampen="5s" op monitor interval="10s"
crm configure clone clone_ping ping
crm configure location web_location web rule -inf: not_defined default_ping_set or default_ping_set lt 1000

上記の内容をnode1で投入しました。すべて投入すると以下のようになるはずです。

障害の発生と復旧

現在の状態を確認しておきます。

vipとhttpdはnode1で動いていることが分かります。

「Migration Summary:」の欄には何も表示されていないのでエラーが発生していないことが分かります。

node1で障害発生

ではnode1のhttpdを落としてみます。

[root@node1 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)

node1でhttpdを落とすと「Migration Summary:」欄のnode1で「fail-count=1」となったことが分かります。

そして3回障害が発生しないとnode2にフェイルオーバーしない設定を入れていますから、httpdは再起動してnode1で動いています。

それでは更に2回httpdを落としてnode2にフェイルオーバーすることを確認します。

[root@node1 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)
[root@node1 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)

上記のように2回killコマンドを実行したあとのステータス確認結果は以下のとおりです。node1のfailcountは3になり、vipとhttpdがnode2で動いていることがわかります。

node2で障害発生

それではnode2で3回httpdをkillするとどうなるのか?やってみます。

[root@node2 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)
[root@node2 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)
[root@node2 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)

node2のfailcountも3に達しました。そしてhttpdは「Stopped」となってしまいました。

これはnode1とnode2のfailcoutが共に3に達してしまっているためです。この状態を復旧させるにはfailcoutをクリアしてやる必要があります。

復旧テスト

それではnode2のfailcountをクリアします。これはnode1とnode2のどちらで実行しても構いません。

[root@node1 ~]# crm resource cleanup httpd node2
Cleaned up vip on node2
Cleaned up httpd on node2
Waiting for 2 replies from the CRMd.. OK
[root@node1 ~]#

failcountをクリアしたあと、node2でふたたびhttpdが動き出したことが分かります。

この状態でnode2に障害が発生するとnode1のfailcoutは3のままのためフェイルオーバーしません。そのためnode1のfailcountもクリアしましょう。

[root@node1 ~]# crm resource cleanup httpd node1
Cleaned up vip on node1
.Cleaned up httpd on node1
Waiting for 1 reply from the CRMd. OK
[root@node1 ~]#

node1でfailcountをクリアすると「Migration Summary:」の欄がきれいになりました。

フェイルバックさせる

個人的にはnode1とnode2のどちらでvipとhttpdが動いていても良いのでは?と思いますが、業務ではフェイルバックを求められることがあります。

そのためnode1でvipとhttpdが動くようにリソースを移動させましょう。

リソースを移動するには crm resource move コマンドを実行します。このコマンドもnode1とnode2のどちらで実行しても構いません。

今回は「force」オプションを付けています。理由は後述しますが、強制的にリソースを移動させると以下のようにWARNINGが表示されます。

ステータスは以下のようになります。

これでリソース移動はできたのですが、さきほどのWARNINGで表示されたようにnode1で障害が発生した際にnode2へフェイルオーバーしなくなります。やってみましょう。

[root@node1 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)
[root@node1 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)
[root@node1 ~]# kill -9 $(cat /etc/httpd/run/httpd.pid)

以下のようにhttpdがStoppoedとなってしまいます。

この原因はcrm configure showでわかります。

上記の★を付けたところが原因です(「-inf」はここでは動かないという意味)。

これはクラスタ設定で「resource-stickiness=”INFINITY”」としていることが原因です。「resource-stickiness=”INFINITY”」を設定していると「force」オプションを使って強制しないとリソース移動ができないのですが、強制的にリソースを移動するとリソース移動禁止設定が入ってしまいます。

「resource-stickiness=”0″」にすればforceオプションは不要ですしリソース移動禁止設定が入ることもないのですが、そうすると自動フェイルバックしてしまうため「resource-stickiness=”INFINITY”」と設定しています。

そのため crm resource move コマンドでリソースを強制移動した後は以下のようにしてリソース移動禁止設定を削除してやります。

[root@node1 ~]# crm resource unmove web

上記のコマンドを投入するとリソース移動禁止設定が消えてnode2にフェイルオーバーします。

クラスタ操作コマンド

ノード操作

ノードをオフラインにする

crm node standby node2
crm node standby node1

ノードをオンラインにする

crm node standby node1
crm node standby node2

設定関連

設定表示

crm configure show

設定編集

crm configure edit

設定削除

①各ノードをオフラインにする

crm node standby node2
crm node standby node1

②設定削除する

crm configure erase

③各ノードをオンラインに戻す

crm node standby node1
crm node standby node2

リソース操作

リソース移動

crm resource move web node2

Failcountクリア

crm resource cleanup web node1

ステータス確認

「-f」オプションを付けるとfailcountを確認できる。

リアルタイムで更新したい場合

crm_mon -Af

1回だけ表示させておわり

crm_mon -Af1

コメントを残す

メールアドレスが公開されることはありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)