PG-REXで学ぶPacemaker運用の実例

PG-REXで学ぶ
Pacemaker運用の実例
2015年10月3日 OSC2015 Fukuoka
Linux-HA Japan
東一彦

2
Linux-HA Japan
本日のメニュー
[前菜]
① Pacemakerって何？
② 前準備
②-１ PG-REXって何？
②-２前提構成と構築手順（ざっくり）
②-２ Pacemaker運用三種の神器
[メインディッシュ]
③ クラスタ故障の種類
④ 故障毎の動作と対処方法
[デザート]
⑤ コミュニティ紹介

3
Linux-HA Japan
①
Pacemakerって何？

4
Linux-HA Japan
Pacemakerはオープンソースの
HAクラスタソフトです。

5
Linux-HA Japan
High Availability = 高可用性
つまり
一台のコンピュータでは得られない高い信頼
性を狙うために、
複数のコンピュータを結合し、
ひとまとまりとしたシステムのこと
サービス継続性

6
Linux-HA Japan
現用系待機系
サービス
HAクラスタを導入すると、
故障で現用系でサービスができなくなったときに、自動で待
機系でサービスを起動させます
→このことを「フェイルオーバー」と言います
(以降、F.Oと表記)
サービス
故障
フェイルオーバー

7
Linux-HA Japan
は
このHAクラスタソフトとして
実績のある「Heartbeat」と
呼ばれていたソフトの後継です。

8
Linux-HA Japan
サーバ#1
サーバ#2
アプリケーション監視・制御
仮想IP
自己監視
ノード監視
ディスク監視・制御
ネットワーク監視・制御
・プロセス監視
・watchdog
・ファイルシステム監視
・共有ディスク排他制御
・ハートビート通信
・STONITH(強制電源断)
・ping疎通確認
・仮想IP制御
・起動・停止・稼働監視
Pacemakerで監視できること

9
Linux-HA Japan
PostgreSQL
RA
Pacemakerが起動/停止/監視を制御する対象をリソースと呼ぶ
 例)Apache, PostgreSQL, 共有ディスク, 仮想IPアドレス etc...
リソースの制御はリソースエージェント(RA)を介して行う
 RAが各リソースの操作方法の違いをラップし、Pacemakerで制御できるようにしている
 リソースの起動(start), 監視(monitor), 停止(stop) を行うメソッドを定義する※。
Apache
RA
共有ディスク
RA
リソース
リソース
エージェント
start/monitor/stop
※Master/Slaveリソースの場合さらに、昇格(promote), 降格(demote) も定義する。

10
Linux-HA Japan
②前準備
PG-REXって何？
前提構成と構築手順（ざっくり）
Pacemaker運用三種の神器

11
Linux-HA Japan
Master Slave
データ
ローカルディスク
データ
ローカルディスク
レプリケーション
監視
仮想IP
PostgreSQLレプリケーション機能＋Pacemakerでの構成を
PG-REXと呼称
PostgreSQLのストリーミングレ
プリケーション機能を用いてデー
タを常に両系にコピー
• 共有ディスクは不要
• 更新はMaster側のみ可能。
Slaveは参照のみ可能。
• "同期レプリケーション"により、
更新データは即座にSlaveに
送信される。
(送信後、ﾄﾗﾝｻﾞｸｼｮﾝ完了)
故障をPacemakerが監視・検知。
SlaveをMasterに昇格させるこ
とで自動的にサービスを継続。
• Pacemakerは両系で動作。
• 故障時は、SlaveをMasterに
昇格後、仮想IPを移動しサー
ビス継続。
• Slave故障時はレプリケーショ
ン切り離しを実行。
(ﾄﾗﾝｻﾞｸｼｮﾝ中断を最小限に)
ぴーじーれっくす

12
Linux-HA Japan
PG-REXの構成例
Pacemaker Pacemaker
サービスLAN
PostgreSQL
(Master)
PostgreSQL
(Slave)
LAN
仮想IP1
(vip-master)
仮想IP2
(vip-rep)
仮想IP3
(vip-slave)
pgsql RA pgsql RA
制御制御
サーバ#1 サーバ#2
ハートビート
LAN
Read/Write Read Only
STONITH LAN
参照負荷分散用
Slaveからの接続用
ＤＢ接続用(更新/参照)

13
Linux-HA Japan
②前準備
PG-REXって何？

14
Linux-HA Japan
サービスLAN
PostgreSQL9.4
(pgsql RA)
Master
レプリケーションLAN
ハートビートLAN
Master Slave
PostgreSQL9.4
(pgsql RA)
Slave
pm01 pm02
1.1 1.1
クライアント
内蔵ディスク
（DBファイル）
内蔵ディスク
（DBファイル）
※STONITH用LANもありますが表記を省略しています。
 本資料では、以下構成を例に運用方法を例示していきます。
 いわゆる典型的なPG-REX構成です。（詳細なcrm設定は参考に添付。）
 CentOS7.1／Pacemaker1.1.13-1.1／PostgreSQL9.4.4 を使用してます。
クライアントは仮想IPへアクセス
NW監視(ping)
ディスク監視(diskd)
STONITH
仮想IPアドレス
(IPaddr2)
(IPaddr2)
NW監視(ping)
STONITH
7.1 7.1

15
Linux-HA Japan
 前述構成の構築手順は以下です。
 「PG-REX利用マニュアル」に従い、以下３ステップで構築します。
 今回は運用にフォーカスするため、構築はざっくり・・・詳しくはWebで！
構築手順
1. インストール
 両系にPacemaker1.1をインストール
 両系にPostgreSQL9.4、PG-REX運用補助ツールをインストール
2. Master構築・起動
 Master側DB初期化
 Master側Pacemakerを起動しリソースを設定（crm流し込み）
 「pg-rex_master_start」コマンドを使えば楽ちん！
 本構成のcrm設定は参考に添付
3. Slave構築・起動
 Slave側にMasterのPostgreSQL最新DBをコピー
 Slave側Pacemakerを起動
 「pg-rex_slave_start」コマンドを使えば楽ちん！

16
Linux-HA Japan
 ざっくりすぎたので補足
 「PG-REX利用マニュアル」ってどこにあるの？
→以下「PG-REXコミュニティ」で公開されています。
→作成、監修には我々Linux-HA Japanのメンバも参加。
→2015.10.3現在最新版はPacemaker1.1系+PostgreSQL9.4系を使用の
「PG-REX9.4利用マニュアル」です。
PG-REX 検索
http://osdn.jp/projects/pg-rex/
 「PG-REX運用補助ツール」や「pg-rex_~~」コマンドってなに？
→PG-REX運用補助ツールは複雑なPG-REX構成の運用を楽ちんにしてくれる
ツールです。「pg-rex_～～」コマンドはこの中に含まれています。
→このツールは上記PG-REXコミュニティで「pg-rex_operation_tools」として公
開しています。
→PG-REX9.4には「pg-rex_operation_tools 1.5.0」を使用します。

17
Linux-HA Japan
②前準備
PG-REXって何？

18
Linux-HA Japan
Pacemakerの運用に欠かせない３つのことについて
ちょっとお勉強
 crm_mon
 ha-log
 Attribute(属性値)
私が勝手に「運用三種の神器」と命名！

19
Linux-HA Japan
基本情報
ノード情報
リソース情報
故障回数
属性値
crm_monとは、Pacemakerに付属の、クラスタ状態をCUIベースの画面でリアルタイムに確認で
きるコマンドです。現在のPacemakerの状態が手に取るようにわかります。
 三種の神器１：crm_monについて [1/3]
 具体的にはcrm_monで以下がわかります。
 quorumを持っているか？
 DCノードは誰か？
 Pacemakerのバージョンは？
 ノードがクラスタに参加している(online)かどうか？
 リソースがどのノードで起動(停止)しているか？
 ネットワーク監視は正常か？
 ディスク監視は正常か？
 なにか故障は発生していないか？
大まかに5種類のことがわかります。

20
Linux-HA Japan
表示例：「crm_mon -rfA」で今回の構成を表示してみると
Last updated: Thu Sep 3 16:20:01 2015
Last change: Mon Aug 24 19:27:11 2015 by root via crm_attribute on pm01
Stack: corosync
Current DC: pm01 - partition with quorum
Version: 1.1.13-6052cd1
2 Nodes configured
16 Resources configured
Online: [ pm01 pm02 ]
Full list of resources:
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Resource Group: grpStonith1
prmStonith1-1 (stonith:external/stonith-helper): Started pm02
prmStonith1-2 (stonith:external/ipmi): Started pm02
Resource Group: grpStonith2
prmStonith2-1 (stonith:external/stonith-helper): Started pm01
prmStonith2-2 (stonith:external/ipmi): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
Clone Set: clnPing [prmPing]
Started: [ pm01 pm02 ]
Clone Set: clnDiskd1 [prmDiskd1]
Started: [ pm01 pm02 ]
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-master-baseline : 0000000051000168
+ pgsql-status : PRI
+ ringnumber_0 : 192.168.1.1 is UP
* Node pm02:
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
+ ringnumber_0 : 192.168.1.2 is UP
Migration summary:
* Node pm01:
* Node pm02:
~続き
ノード情報
基本情報
リソース情報
属性値
故障回数
pm01とpm02
がオンライン
master-groupは
pm01で起動。
pgsqlはpm01が
Master。
etc...
ネットワーク／
ディスク監視は
正常 etc...
故障は発生していない。
故障毎の具体的な表示パターンは習うより慣
れろ、ということで、後程、実例を紹介します。~右上に続く

21
Linux-HA Japan
 crm_mon のTips
 どのノードでcrm_monを叩けばいいの？
→クラスタが正常に組めていればcrm_monはどちらのノードで実行しても同じ表示
になります。
→ノード毎に表示が食い違う場合、クラスタは正常に組めていません。
ネットワーク(ハートビート用LAN)が切れているかもしれません。
 表示が長すぎて画面におさまらないんだけど・・・
→「-1」オプションを付けると、バッチモード(1回分のみ表示しすぐ抜ける)になります。
→Pacemaker-1.1では Shift+D 押下でヘッダ部分を表示しなくなります。
 オプションがいろいろあるみたいだけど・・・
→個人的にお勧めは「crm_mon -rfA」です。以下を表示できます。
-r ：停止しているリソースも(stoppedと)表示します。
-f ：故障状態(フェイルカウントと呼ばれる故障状態を示すフラグ)も表示します。
-A：属性値も表示します。 ※属性値については後述。

22
Linux-HA Japan
 三種の神器２：ha-logについて [1/2]
 ha-logとは、Pacemakerが出力するログの名前。
 伝統的にha-logという名前を使うことが多いようです。
 とはいえ、現在デフォルトでは/var/log/messagesに出力されます。
（syslog_facilityのデフォルトが「daemon」のため。)
 当然ながら、クラスタの運用に役に立つ情報がたくさん出力されます。
 Act側とSby側で出力内容が異なるので注意！
 故障解析には両系分のログがあるほうがよいです。
 でも、Pacemakerは結構大量にログを吐きます・・・
 できれば設定を変更し/var/log/ha-log等に切り出した方がいいかもしれません。
 それでもなかなかログを読み解くのは困難・・・
習うより慣れろ！故障パターン毎のログ出力例を後程紹介します。

23
Linux-HA Japan
 三種の神器２：ha-logについて [2/2]
 Pacemakerログのha-logへの切り出し手順
# vi /etc/corosync/corosync.conf
→syslog_facilityを「local1」等、他で使用していないものに変更。
# vi /etc/sysconfig/pacemaker
→「PCMK_logfacility=local1」という設定を追記。
# vi /etc/rsyslog.conf
→赤字部分を追記。
*.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages
local1.info /var/log/ha-log
# vi /etc/logrotate.d/pacemaker
→以下を記載（ローテート設定）。
/var/log/ha-log {
missingok
}
→最後にrsyslog、pacemaker等を再起動し、設定を反映します。

24
Linux-HA Japan
 pgsql-status属性値
 PostgreSQLの稼働状況を示す
 pgsql-data-status属性値
 PostgreSQLのデータの状態を示す
 Attribute(属性値)とは、ノード毎の各リソースの状態を補完するPacemaker内部の値。
 Key-Valueの形式でユーザ（RA）が任意に定義可能。
 現在の値はcrm_mon -Aコマンドで確認できます。
 crm_attributeコマンドで値を設定・変更できます。
 PG-REXの運用で特に重要なのは以下の２つです。
値意味
PRI Masterとして稼働中
HS:sync Slaveとして同期モードで稼働中
HS:async Slaveとして非同期モードで稼働中
HS:alone Slaveとして稼働しているが、Masterに接続できない
値意味
LATEST 他にMasterはおらず、データは最新。
STREAMING|SYNC 同期接続によりデータは最新。
STREAMING|ASYNC 非同期接続によりデータは追いついていない可能性あり。
DISCONNECT Masterとの接続が切断し、データは古い。
※上記属性値名の「pgsql」部分はPostgreSQLのリソース名(Pacemaker上でのPostgreSQL管理名。ユーザが任意に設定可。)
により変化します。通常は同リソース名は「pgsql」とすることを推奨します。
 三種の神器３：Attribute(属性値)について

25
Linux-HA Japan
③
クラスタ故障の種類

26
Linux-HA Japan
 「故障」と一口に言っても、いろんな箇所が故障しますよね・・・
 PG-REX構成は、以下×箇所の故障を想定済み！
サービスLAN
PostgreSQL
(Master)
レプリケーションLAN
ハートビートLAN
Master Slave
PostgreSQL
(Slave)
pm01 pm02
1.1 1.1
クライアント
→故障しうる箇所と、故障時のPacemakerの動作・復旧方法を
把握しておくことで故障に迅速に対応でき、可用性を保てる。
※STONITH用LANもありますが表記を省略しています。
NW監視(ping)
STONITH
(IPaddr2)
(IPaddr2)
NW監視(ping)
STONITH
7.1 7.1

27
Linux-HA Japan
大項目小項目 Pacemakerの挙動
リソース故障
vip-rep 故障 ①
vip-master 故障 ②
PostgreSQL故障 ②
ネットワーク故障
レプリケーションLAN故障 ①
サービスLAN故障 ②
ハートビートLAN故障 ③
ノード故障
カーネルハング ③
電源停止 ③
Pacemakerプロセス故障
pacemakerdプロセス故障 ①
corosyncプロセス故障 ③
cibプロセス故障 ③
ディスク故障内蔵ディスク故障 ② or ③
リソース停止失敗
vip-rep ②
vip-master ③
PostgreSQL(demote失敗) ③
PostgreSQL(stop失敗) ③
 前ページの×を表に書き下してみる（※Master側分のみ）
ノード監視
ネットワーク監視・制御
自己監視
ディスク監視・制御
すべてPacemakerで対処可能！

28
Linux-HA Japan
 「故障」したらPacemakerはどんな動作をするか？
 「故障」と一口に言っても、Pacemakerの動作も様々です。
大きく以下３つに分けられます。
Pacemakerの動作
①リソース/プロセス
再起動
②通常F.O ③STONITH後F.O
概要同じサーバ上でリソース/プ
ロセスをもう一度起動また
は設定変更する。F.Oはし
ない。
サービス継続に直接関係な
いリソース故障時の対処。
故障したサーバの関連リ
ソースを停止後、Standby
サーバでリソースを起動す
る。いわゆる「フェイルオー
バー」。
故障サーバの電源を強制
的に断(STONITH)後、
Standbyサーバでリソース
を起動。
故障サーバの状態が確認
できない場合に2重起動を
防ぐ対処。
故障例・レプリケーション用VIP故障
・レプリケーションLAN切断
・DBプロセス停止
・サービス用VIP故障
・サービスLAN切断
・サーバ電源停止
・Pacemaker停止
・ﾊｰﾄﾋﾞｰﾄLAN切断
・リソース停止失敗
短長サービス中断時間

29
Linux-HA Japan
 各故障をPacemakerの動作で分類してみる ①リソース／プロセス再起動
②通常F.O
③STONITH後F.O
凡例
以降、大項目ごとに、故障内容とPacemakerの動作、
対処方法を具体的にご紹介していきます。
大項目小項目 Pacemakerの挙動
リソース故障
vip-rep 故障 ①
vip-master 故障 ②
PostgreSQL故障 ②
ノード故障
カーネルハング ③
電源停止 ③
pacemakerdプロセス故障 ①
corosyncプロセス故障 ③
cibプロセス故障 ③
ディスク故障内蔵ディスク故障 ② or ③
vip-rep ②
vip-master ③
PostgreSQL(demote失敗) ③
PostgreSQL(stop失敗) ③

30
Linux-HA Japan
④
故障毎の動作と対処方法

31
Linux-HA Japan
リソース故障

32
Linux-HA Japan
 リソース故障
大項目小項目 Pacemakerの動作故障再現方法(コマンド)
リソース故障
vip-rep 故障 ① # ip addr del <vip-repｱﾄﾞﾚｽ> dev ethX
vip-master 故障 ② # ip addr del <vip-masterｱﾄﾞﾚｽ> dev ethX
PostgreSQL故障 ② # pg_ctl -m i stop
①リソース／プロセス再起動
②通常F.O
③STONITH後F.O
凡例
 故障概要
リソースの故障を、各リソースのRAが検知するパターン。
RAには必ずstart(起動), stop(停止), monitor(監視)の３つのメソッドがありますが、稼働中の故
障はそのうちのmonitorで検知します。その場合、基本的には故障発生ノードでリソースを停止し、
もう片方のノードでリソースを起動することでフェイルオーバします（＝②の動作）。
vip-repのみ①の動作となっていますが、これは以下migration-threshold=0の設定によるもので
す。vip-repの故障は直ちにサービスに影響はないため、リソースが再起動するように設定してい
ます。
primitive vip-rep IPaddr2 ¥
params ip=192.168.2.3 nic=ens1f1 cidr_netmask=24 ¥
meta migration-threshold=0 ¥
op start interval=0s timeout=60s on-fail=stop ¥
op monitor interval=10s timeout=60s on-fail=restart ¥
op stop interval=0s timeout=60s on-fail=ignore
migration-thresholdは何回故障
したらF.Oするかを決める設定。
0だと何度故障してもF.Oはせず
リソースを再起動する。
（他リソースは1に設定）
実例紹介
実例紹介
割愛(上と同様↑）

33
Linux-HA Japan
 vip-rep故障時の動作（擬人化）
vip-repさん、大丈夫？ペーコロ
大丈夫っす!
vip-repさん、大丈夫？
vip-repがないっす！故障っす！
じゃあ、また付けて！
了解っす！
時間
vip-repのmigration-thresholdが0の
ため、Pacemakerは故障時、再起動
を命じます。
IPaddr2
(vip-rep)
192.168.2.3
ここで「vip-rep削除」

34
Linux-HA Japan
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
vip-rep: migration-threshold=0 fail-count=1 last-failure='Mon Sep 7 14:14:25 2015'
* Node pm02:
Failed actions:
vip-rep_monitor_10000 on pm01 'not running' (7): call=84, status=complete, exit-
reason='none', last-rc-change='Mon Sep 7 14:14:25 2015', queued=0ms, exec=0ms
 vip-rep故障後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
故障前故障後
pm01のMigration summary
および"Failed actions"にvip-
repで故障が発生した旨が表
示される。
vip-repは再起動されるため、
リソースおよび属性値に変化
はない。
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

35
Linux-HA Japan
14:14:25 pm01 crmd[37787]: notice: process_lrm_event: Operation vip-rep_monitor_10000: not running
(node=pm01, call=84, rc=7, cib-update=112, confirmed=false)
14:14:25 pm01 crmd[37787]: notice: process_lrm_event: Operation vip-rep_stop_0: ok (node=pm01,
call=90, rc=0, cib-update=116, confirmed=true)
14:14:25 pm01 crmd[37787]: notice: process_lrm_event: Operation vip-rep_start_0: ok (node=pm01,
call=91, rc=0, cib-update=117, confirmed=true)
 vip-rep故障時のha-log
→vip-repのmonitor(監視)で故障(not running=稼働していない)を検知
→vip-repを停止（リソース再起動のため）
Masterのha-log抜粋
→vip-repを起動（リソース再起動のため）
（重要な箇所を黄色で強調しています）

36
Linux-HA Japan
 vip-rep故障時の復旧方法
 crm_monに"Failed actions"が表示されたままだと、次回故障時、そのノードには
フェイルオーバできません。
 Pacemakerはそのノードを"異常"と思っている。
 この状態を"フェイルカウント"が立っている、といいます。
 故障の原因を取り除いたら、以下コマンドで"フェイルカウント"を削除します。
＝Pacemakerにもう異常はない、と教えてあげる。
 フェイルカウントが削除され、crm_mon表示が元に戻ります。
# crm_resource -C -r vip-rep -N pm01
故障リソース名↑ ↑ノード名

37
Linux-HA Japan
 vip-master故障時の動作（擬人化）
vip-masterさん、大丈夫？ペーコロ
大丈夫っす!
vip-masterさん、大丈夫？
vip-masterがないっす！故障っす！
じゃあ、フェイルオーバしなきゃ！
時間
vip-masterのmigration-thresholdが
1のため、Pacemakerは故障時、
ファイルオーバを命じます。
IPaddr2
(vip-master)
192.168.0.3
ここで「vip-master削除」
コロちゃん！こっちのリソース止めるから
そっちで起動して！
了解！

38
Linux-HA Japan
～～
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm01:
+ master-pgsql : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
* Node pm02:
Migration summary:
* Node pm01:
vip-master: migration-threshold=1 fail-count=1 last-failure='Mon Sep 7 14:38:50 2015'
pgsql: migration-threshold=1 fail-count=1 last-failure='Mon Sep 7 14:38:54 2015'
* Node pm02:
Failed actions:
vip-master_monitor_10000 on pm01 'not running' (7): call=82, status=complete, exit-
pgsql_monitor_10000 on pm01 'not running' (7): call=117, status=complete, exit-
 vip-master故障後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
故障前故障後
pm01のMigration summary
および"Failed actions"にvip-
masterで故障が発生した旨
が表示される。
同時にPostgreSQLの故障も
表示される。
フェイルオーバし、pm02が
Master(リソースが起動)にな
る。

39
Linux-HA Japan
 vip-master故障後のcrm_mon
 PostgreSQLの故障も表示されるのはなぜ？
PostgreSQLは仕様上、MasterをSlaveに降格(demote)という状態遷移ができません。
Masterは直接停止するしかありません。
MasterStop Slave
の状態遷移
MasterStop Slave
のM/Sリソース
状態遷移
start promote
stop demote
一方、PacemakerはMaster/Slaveリソースを、「start」「promote」「demote」
「stop」の４つの命令で、それぞれの状態に制御しようとします。
そのため、PacemakerがMasterを「demote」すると、(Pacemakerの思惑とは異な
り）PostgreSQLは停止してしまい、それを故障と判断するのです。
なので、残念ながらPG-REXでは、Master故障でのフェイルオーバ後は、
旧Masterは停止し、PostgreSQLが片系で稼働する状態になります。
※Stopから直接Masterになることもできます。
※

40
Linux-HA Japan
 vip-master故障時の動作（擬人化）
ペーコロ
時間
了解！
PostgreSQL降格(demote)！
vip-rep停止！
(pgsql)成功！
(IPaddr2)成功！
vip-master停止！
(IPaddr2)成功！
(pgsql)ぺーちゃん!PostgreSQLが停止してる!
何!?demoteしただけなのに・・・故障だ！
故障したPostgreSQLも含めて、
フェイルオーバ継続！
PostgreSQL停止！
・・・さっきの続き
(pgsql)成功！(既に停止済み)
よし、全リソース停止完了！
コロちゃんあとは頼んだ！
了解！
demoteしたPostgreSQLはSlaveになったかな？
PG-REX構成では、Pacemakerと
PostgreSQLの状態遷移の差により、
フェイルオーバ時、PostgreSQLの
故障も発生します。
その結果、PostgreSQLは片系のみ
の稼働となります。
もう少し詳しくいうと、ぺーちゃんは
自ノードを以下にしようとしています。
・pgsql -> Slave状態
・vip-rep -> 停止状態
・vip-master -> 停止状態

41
Linux-HA Japan
14:38:50 pm01 crmd[37787]: notice: process_lrm_event: Operation vip-master_monitor_10000: not running (node=pm01, call=82,
rc=7, ～略～)
14:38:51 pm01 crmd[37787]: notice: process_lrm_event: Operation pgsql_demote_0: ok (node=pm01, call=104, rc=0, ～略～)
14:38:52 pm01 crmd[37787]: notice: process_lrm_event: Operation vip-rep_stop_0: ok (node=pm01, call=107, rc=0, ～略～)
14:38:52 pm01 crmd[37787]: notice: process_lrm_event: Operation vip-master_stop_0: ok (node=pm01, call=111, rc=0, ～略～)
14:38:54 pm01 crmd[37787]: notice: process_lrm_event: Operation pgsql_monitor_10000: not running (node=pm01, call=117, rc=7,
～略～)
14:38:54 pm01 crmd[37787]: notice: process_lrm_event: Operation pgsql_stop_0: ok (node=pm01, call=124, rc=0, ～略～)
 vip-master故障時のha-log
→vip-masterのmonitor(監視)で故障(not running=稼働していない)を検知
→PostgreSQLのdemote(降格)／stop(停止)が成功。
→仮想IP(VIP)のstop(停止)が成功。
→PostgreSQLをdemoteしたため、PostgreSQLが停止し、故障(not running)と検知される。
（フェイルオーバは継続する）
→PostgreSQLのstop(停止)が成功。
14:38:53 pm02 crmd[56066]: notice: process_lrm_event: Operation pgsql_promote_0: ok (node=pm02, call=74, rc=0, ～略～)
14:38:56 pm02 crmd[56066]: notice: process_lrm_event: Operation vip-master_start_0: ok (node=pm02, call=90, rc=0, ～略～)
14:38:56 pm02 crmd[56066]: notice: process_lrm_event: Operation vip-rep_start_0: ok (node=pm02, call=92, rc=0, ～略～)
Slaveのha-log抜粋
→仮想IPの起動が成功。
→PostgreSQLのpromoteが成功。

42
Linux-HA Japan
 vip-master故障時の復旧方法
 故障した方のPacemakerを一旦停止します。
 "フェイルカウント"はPacemakerを停止すると削除されます。
 故障した原因を確認し、復旧します。
 故障した方の「/var/lib/pgsql/tmp/PGSQL.lock」ファイルを削除します。
 これはデータが古いことをユーザに気づかせるための印で、pgsql RAが
作成・管理しています。
 このファイルが存在するとPostgreSQLが起動しません。
 故障したノードをSlaveとして初期構築と同様に組み込みます。
 「pg-rex_slave_start」コマンドなら一発！
 故障したノードを再度Masterにしたい場合、手動でF.Oを発生させ、再度Slaveを初期
構築と同様に組み込みます。
 「pg-rex_switchover」コマンドなら一発！
（このコマンドもPG-REX運用補助ツールに含まれています。）

43
Linux-HA Japan
ネットワーク故障

44
Linux-HA Japan
 ネットワーク故障
大項目小項目 Pacemakerの動作故障再現方法(コマンド)※
# iptables -A INPUT -i ethX -j DROP
# iptables -A OUTPUT -o ethX -j DROP
# iptables -A INPUT -i ethY -j DROP
# iptables -A OUTPUT -o ethY -j DROP
②の動作
①の動作
③の動作
②通常F.O
③STONITH後F.O
凡例
 故障概要
NIC故障や断線等でネットワークが切れる故障です。切れたネットワークの用途によって
Pacemakerの挙動が大きく異なります。（下図参照）
※INPUTとOUTPUTを連続して遮断します（「;」で区切って1行で実行するとよい）
実例紹介
実例紹介
実例紹介

45
Linux-HA Japan
 レプリケーションLAN故障時の動作（擬人化）
pgsqlさん、大丈夫？ pgsqlさん、大丈夫？ペーコロ
pgsql RA
(Slave)
pgsql RA
(Master)
大丈夫だぁ。大丈夫だぁ。
ここで「レプリケーションLAN断」
pgsqlさん、大丈夫？ pgsqlさん、大丈夫？
大丈夫だぁ。大丈夫だぁ。
pgsqlさん、大丈夫？ pgsqlさん、大丈夫？
Slaveがいない・・・大丈夫だぁ。
時間
Slaveいないとトランザクション
止まっちゃうから切り離すね
なんか、属性値変わった・・
こっちはMasterにはなれないね。
PostgreSQL設定変更！
Slave側属性値変更！
レプリケーションLAN切断に気づくの
はMaster側のpgsql RAです。
pg_stat_replicationビューを監視し
ています。気づくのに
wal_sender_timeoutに設定の時間
がかかります。
PostgreSQLの
synchronous_standby_namesを空
に変更しSlaveを同期モードから切
離します。
Slaveの属性値を変更し、Slaveが
Masterになれないようマークします。
(DBデータが古いため)
属性値がDISCONNECTになった・・・
一人ぼっち(alone)か・・・

46
Linux-HA Japan
 レプリケーションLAN故障後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
+ pgsql-status : HS:alone
Migration summary:
* Node pm01:
* Node pm02:
故障前故障後
pm02のpgsql-*属性
値が、故障を示す値
(DISCONNECT|HS:a
lone)に

47
Linux-HA Japan
10:12:44 pm01 pgsql(pgsql)[7450]: INFO: Changing pgsql-data-status on pm02 : STREAMING|SYNC-
>DISCONNECT.
10:12:44 pm01 pgsql(pgsql)[7450]: INFO: Changing pgsql master score on pm02 : 100->-INFINITY.
10:12:44 pm01 pgsql(pgsql)[7450]: INFO: Setup pm02 into async mode.
10:12:44 pm01 pgsql(pgsql)[7450]: INFO: server signaled
10:12:44 pm01 pgsql(pgsql)[7450]: INFO: Reload configuration file.
10:12:52 pm02 pgsql(pgsql)[16243]: INFO: Changing pgsql-status on pm02 : HS:sync->HS:alone.
 レプリケーションLAN故障時のha-log
→pgsql RAがSlave(pm02)のpgsql-data-status属性値をDISCONNECTに変更
→pgsql RAがSlave(pm02)がMasterになれないようにマーク
→pgsql RAがSlave(pm02)を切り離し（非同期モードにPostgreSQLの設定を変更）
→PostgreSQLの設定を変更したのでreloadを実行し反映
→pgsql-data-status属性値がDISCONNECTに変更されたため、pgsql-status属性値
をHS:aloneに変更。

48
Linux-HA Japan
 レプリケーションLAN故障時の復旧方法
 Slave側のPacemakerを一旦停止します。
 故障したレプリケーションLANを復旧します。
 疑似故障の場合iptables のDROPルールを削除するのを忘れずに・・
 再度Slaveを初期構築と同様に組み込みます。

49
Linux-HA Japan
 サービスLAN故障時の動作（擬人化）
ルータさんにping ルータさんにping
ペーコロ
ここで「サービスLAN断」
時間
はーい
サービスLAN切断に気づくのはNW
監視(pingリソース)です。
1か所へのpingに失敗すると、
default_ping_set属性値から100を
引きます。
はーい
はーい・・・
あれ？返事がない・・・
ネットワーク監視の属性値を
変えなきゃ・・・
）
属性値が変だ！
フェイルオーバしなきゃ！
pingﾘｿｰｽ pingﾘｿｰｽ
了解！
ルータ

50
Linux-HA Japan
 サービスLAN故障後のcrm_mon
～～
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 0 : Connectivity is lost
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
故障前故障後
pm01の
default_ping_set属性
値は0に下がる。
リソースがpm02で起
動／Masterになる。
pm01のPostgreSQL
の属性値は停止を示
す値に。
pm02のPostgreSQL
の属性値はMasterで
あることを示す値に。

51
Linux-HA Japan
 サービスLAN故障時のha-log
11:52:27 pm01 attrd[30451]: info: attrd_peer_update: Setting default_ping_set[pm01]: 100 -> 0 from pm01
11:52:32 pm01 pengine[30452]: notice: LogActions: Move vip-master (Started pm01 -> pm02)
11:52:32 pm01 pengine[30452]: notice: LogActions: Move vip-rep (Started pm01 -> pm02)
11:52:32 pm01 pengine[30452]: notice: LogActions: Demote pgsql:0 (Master -> Stopped pm01)
11:52:32 pm01 pengine[30452]: notice: LogActions: Promote pgsql:1 (Slave -> Master pm02)
→Master(pm01)のdefault_ping_set属性値が0に変更された（＝pingが失敗した）。
→仮想IP(VIP)をpm02へ移動（フェイルオーバ）することに決定。
→pm01のPostgreSQLを停止し、pm02で昇格(promote)することに決定。
→pm01のPostgreSQLのdemote(降格)／stop(停止)が成功。
→pm01の仮想IP(VIP)のstop(停止)が成功。

52
Linux-HA Japan
 サービスLAN故障時のha-log
→pm02のPostgreSQLのpromote(昇格)が成功（＝Masterになった）。
→pm02の仮想IP(VIP)のstart(起動)が成功。
PostgreSQLおよび仮想IP(master-group)の停止、起動順は、CRM設定のorder制約に従って決
定されています。
 本デモ環境の場合、以下2つの設定がしてあります。
 制約について詳細はLinux-HA Japanの以下記事をご覧ください。
http://linux-ha.osdn.jp/wp/archives/3868
order rsc_order-3 INFINITY : msPostgresql:promote master-group:start symmetrical=false
order rsc_order-4 0 : msPostgresql:demote master-group:stop symmetrical=false
INFINITY：必ず守る
0：できれば守る
先に実行する
「リソース名：命令」
後に実行する
「リソース名：命令」
逆順の制約を自動生成
するか？
補足

53
Linux-HA Japan
 サービスLAN故障時の復旧方法
 故障した方のPacemakerを一旦停止します。
 故障したサービスLANを復旧します。

54
Linux-HA Japan
 ハートビートLAN故障時の動作（擬人化）
ペーコロ
時間
危うく相撃ちするところでし
たが、stonith-helperという
Linux-HA Japan独自のリ
ソースで相撃ちを防ぎまし
た。
ハートビート用LAN
ここで「ハートビートLAN断」
コロちゃん大丈夫かー？
大丈夫。ぺーちゃんは？
うん大丈夫。
2秒声かけがない・・2秒返事がない・・
僕がMasterだけど、まさ
かコロちゃん、Masterに
なってないだろうな？
僕がMasterになるぞ！
ペーちゃん、リソース停
止したかな・・？
よし、僕がコロちゃんを
停止してあげよう！
よし、僕がペーちゃんを
停止してあげよう！
でも僕はSlaveだから10秒
待っ・・・・・・
コロちゃんをSTONITH!
STONITH成功！これで安心！
Pacemaker同士はハートビートLAN
経由でやりとりしています。それが切
れると互いの声は届きません。

55
Linux-HA Japan
 ハートビートLAN故障後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
故障前 Online: [ pm01 ]
OFFLINE: [ pm02 ]
～～
Masters: [ pm01 ]
Stopped: [ pm02 ]
～～
Node Attributes:
* Node pm01:
Migration summary:
* Node pm01:
pm02が
OFFLINE（クラス
タに未参加)に
故障後
(pm01で表示)
リソースはpm01
で起動のまま。
pm02の属性値
表示は無くなる。
※故障前と比較しやす
いよう空白としているが、
実際には空白はない。

56
Linux-HA Japan
10:29:51 pm01 corosync[9808]: [TOTEM ] A new membership (192.168.1.1:356) was formed. Members left: -1062731518
10:29:52 pm01 pengine[9819]: warning: stage6: Scheduling Node pm02 for STONITH
10:29:59 pm01 stonith-ng[9816]: notice: log_operation: Operation 'reboot' [20958] (call 2 from crmd.9820) for host 'pm02' with
device 'prmStonith2-2' returned: 0 (OK)
10:30:19 pm01 pgsql(pgsql)[21960]: INFO: Setup pm02 into async mode.
10:30:19 pm01 pgsql(pgsql)[21960]: INFO: server signaled
10:30:19 pm01 pgsql(pgsql)[21960]: INFO: Reload configuration file.
 ハートビートLAN故障時のha-log
→pgsql RAがSlave(pm02)を切り離し（非同期モードにPostgreSQLの設定を変更）
→PostgreSQLの設定を変更したのでreloadを実行し反映
→クラスタのメンバが192.168.1.1のみになった（1台離脱した）。
→(急にクラスタから離脱したので)Slave(pm02)をSTONITH(強制電源断)することに決定。
→Slave(pm02)のSTONITHがprmStonith2-2リソースを使用して成功(リターンコード0)した。
→(急にクラスタから離脱したので)Slave(pm01)をSTONITH(強制電源断)することに決定。

57
Linux-HA Japan
 ハートビートLAN故障時の復旧方法
 故障したハートビートLANを復旧します。

58
Linux-HA Japan
ノード故障

59
Linux-HA Japan
 ノード故障
ノード故障
カーネルハング ③ # echo c > /proc/sysrq-trigger
電源停止 ③ # poweroff -nf
 故障概要
急にノード全体(OS)の動作が停止してしまうパターンです。カーネルの故障やコンセント抜け、電
源ユニット故障等が該当します。相手ノードの状態が急にわからなくなるため、リソースの2重起動
を防ぐためSTONITHが発動します。
 Pacemakerの動作（擬人化）
大丈夫かー？
大丈夫。そっちは？
大丈・・
あれ？返事が無い。。
2秒待っても返事ないな・・
ここで「poweroff -nf」
こっちでリソース起動したいけど
ペーちゃん、リソース停止したか
な・・？よし僕が停止してあげよう
ぺーちゃんノードSTONITH！
(電源停止)
ペーコロ
「2秒」はcorosync.confに設定の
token値+consensus値 [msec]
で決まります。
consensus値は未設定の場合token値
の1.2倍に自動設定されます。
②通常F.O
③STONITH後F.O
凡例
でも僕はSlaveだから10秒待って・・
stonith-helperで相撃ちを防
いでいます。
実例紹介

60
Linux-HA Japan
 ノード故障
 ノード故障後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
OFFLINE: [ pm01 ]
～～
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
pm01が
OFFLINE（クラス
タに未参加)に
故障後
(pm02で表示)
pm02でリソース
が起動(F.O完了)
pm01の属性値
pm02のpgsqlが
Masterに。
（pgsql-status属
性値がPRIに)

61
Linux-HA Japan
 ノード故障
 ノード故障時のha-log
11:31:57 pm02 stonith-ng[35528]: info: call_remote_stonith: Requesting that pm02 perform op reboot pm01 with prmStonith1-1 for
crmd.35532 (48s)
11:32:00 pm02 external/stonith-helper[49034]: info: standby wait 10sec
11:32:13 pm02 stonith-ng[35528]: notice: log_operation: Operation 'reboot' [49213] (call 2 from crmd.35532) for host 'pm01' with device
'prmStonith1-2' returned: 0 (OK)
→(急にクラスタから離脱したので)Master(pm01)をSTONITH(強制電源断)することに決定。
→Slave(pm02)にMaster(pm01)をSTONITH(reboot処理)するようリクエストを送信。
→(pm02はSlaveなので)STONITH実行前に10秒待つ。
→Master(pm01)のSTONITHがprmStonith1-2リソースを使用して成功(リターンコード0)した。
→Slave(pm02)でPostgreSQLをMasterに昇格成功(リターンコード0)。
Slaveのha-log抜粋（ノード故障の場合、故障した方の故障時のha-logは消失することがほとんどです。）
→pm02で仮想IPを起動成功(リターンコード0)。

62
Linux-HA Japan
 ノード故障
 復旧方法
 STONITHで停止(再起動)したノードを、Slaveとして初期構築時と同様に組み込
むことで復旧できます。
 STONITHされたノードを再度Masterにしたい場合、手動でF.Oを発生させ、再度
Slaveを初期構築と同様に組み込みます。

63
Linux-HA Japan
Pacemakerプロセス故障

64
Linux-HA Japan
 Pacemakerプロセス故障
pacemakerdプロセス故障 ① # pkill -9 pacemakerd
corosyncプロセス故障 ③ # pkill -9 corosync
cibプロセス故障 ③ # pkill -9 cib
②通常F.O
③STONITH後F.O
凡例
 故障概要
Pacemakerは以下に挙げる複数のプロセスが連携して動作しています。「corosync」
「pacemakerd」「cib」は代表的なプロセスです。プロセス毎に故障した際の動作が異なります。
「corosync」や「cib」の場合、発動するメカニズムは前述の「ノード故障」とほぼ同じです。（なので
擬人化・ログ紹介は割愛します。）
「pacemakerd」の場合、特にF.O等は発生せず、プロセスが再起動します。
• corosync
• cib
• stonithd
• lrmd
• attrd
• pengine
• crmd
• pacemakerd
• ifcheckd
• pm_logconv.py
Pacemaker-1.1関連プロセス一覧
故障時③の動作
故障時①の動作
実例紹介
実例紹介

65
Linux-HA Japan
 pacemakerdプロセス故障時の動作（擬人化）
ペーコロ
ここで「pacemakerd」停止
時間
あ、ペーちゃん(の一部)が停止した。
再起動してあげなきゃ。
pacemakerdの停止に気づくのは
OS(CentOS6：upstart、CentOS7：
systemd）です。
再起動後、何事もなかったかのよう
に通信を再開します。
うん大丈夫。
pacemakerd再起動！
うん大丈夫。

66
Linux-HA Japan
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
 pacemakerdプロセス故障後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
故障前故障後
故障前後で違いはありません！

67
Linux-HA Japan
14:15:22 pm01 pacemakerd[23165]: info: crm_ipc_connect: Could not establish pacemakerd connection:
Connection refused (111)
14:15:22 pm01 pacemakerd[23165]: notice: main: Starting Pacemaker 1.1.13 (Build: 6052cd1): ～略～
 pacemakerdプロセス故障時のha-log
→(pacemakerdが停止したので)pacemakerdとの接続に失敗した
→Pacemaker(pacemakerd)が（再）起動した

68
Linux-HA Japan
 pacemakerdプロセス故障時の復旧方法
 特に復旧する必要はありません。
 プロセス故障が頻発する場合は、真の原因（メモリ不足？、設定ミス？ etc...）を探
すとよいです。
 難しい場合は、遠慮なくLinux-HA Japan MLへ質問してください！
 質問する場合、「crm_mon(の表示。属性値も。)」「ha-log」があると捗ります！
（ってかログなしでは解析できません・・・）

69
Linux-HA Japan
ディスク故障

70
Linux-HA Japan
 ディスク故障
ディスク故障内蔵ディスク故障 ② or ③ ディスクを引っこ抜く！
②通常F.O
③STONITH後F.O
凡例
 故障概要
ディスクはディスク監視機能(diskd)で監視します。
OSのコマンドが配置された内蔵ディスクが故障した場合、リソース停止に使うコマンド(RA自体
やpsql、umount、ipコマンド etc...)が使用できたり、できなかったりします。
コマンドが使用できる場合②の動作、できない場合は③の動作となります。
②の動作の場合、前述の「サービスLAN故障」の動作とほぼ同じです。（なので擬人化・ログ紹介
は割愛します。）
③の動作の場合、後述の「リソース停止失敗」の動作とほぼ同じです。（なので擬人化・ログ紹介は
割愛します。）
補足：
OSのディスクキャッシュにコマンド（のバイナリファイル）が存在する場合、ディスクが故障しても
コマンドが実行できます。が、Linuxの場合キャッシュはメモリ残量に応じて削除されたりもする
ので、コマンドが使用できたり、できなかったりします。

71
Linux-HA Japan
リソース停止失敗

72
Linux-HA Japan
 リソース停止失敗
vip-rep ② RAのstopメソッドをexit $OCF_ERR_GENERICに書き換え
vip-master ③ RAのstopメソッドをexit $OCF_ERR_GENERICに書き換え
PostgreSQL(demote失敗) ③ RAのdemoteメソッドをexit $OCF_ERR_GENERICに書き換え
PostgreSQL(stop失敗) ③ RAのstopメソッドをexit $OCF_ERR_GENERICに書き換え
②通常F.O
③STONITH後F.O
凡例
 故障概要
スイッチオーバやフェイルオーバ等、リソースの停止を伴うオペレーション中に、停止処理に失敗
するケース。リソースの停止ができないと、クラスタとしては2重起動が懸念されるため、リソースを
確実に停止する手段としてSTONITHを発動させます（＝③の動作）。
vip-repだけは②の動作になっていますが、これはvip-repはSlave側のPostgreSQLだけがアク
セスするアドレスで、フェイルオーバ後は使用されず停止に失敗しても問題が無いので、停止失敗
しても無視するよう設定してあるためです。
primitive vip-rep IPaddr2 ¥
params ip=192.168.2.3 nic=ens1f1 cidr_netmask=24 ¥
meta migration-threshold=0 ¥
op start interval=0s timeout=60s on-fail=stop ¥
op monitor interval=10s timeout=60s on-fail=restart ¥
op stop interval=0s timeout=60s on-fail=ignore
on-failは当該のオペレーション
(start/stop/monitor)が失敗した
場合にどうするかを決める設定。
ignoreだと失敗は無視し動作を
継続する。
（他リソースはfenceに設定）
実例紹介
実例紹介

73
Linux-HA Japan
 vip-rep停止失敗時の動作（擬人化）
ペーコロ
全リソース停止！
vip-repの停止失敗っす！
だが無視する！
フェイルオーバ継続！
時間
IPaddr2
(vip-rep)
192.168.2.3
ここで「PostgreSQL強制停止」
(リソース停止を発生させるため)
了解！
(vip-rep以外)リソース停止完了！
了解！
こっちでリソース起動！
vip-repのstopのon-failが"ignore"の
ため、「無視する」と判断します。

74
Linux-HA Japan
～～
vip-rep (ocf::heartbeat:IPaddr2): Started pm02 (failure ignored)
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Sep 9 12:01:35 2015'
* Node pm02:
Failed actions:
vip-rep_stop_0 on pm01 'unknown error' (1): call=112, status=complete, exit-
reason='none', last-rc-change='Wed Sep 9 12:01:36 2015', queued=0ms, exec=48ms
pgsql_monitor_9000 on pm01 'not running' (7): call=84, status=complete, exit-
reason='none', last-rc-change='Wed Sep 9 12:01:35 2015', queued=0ms, exec=0ms
 vip-rep停止失敗後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
故障前故障後
全リソースがpm02にフェイル
オーバ。
vip-repは停止失敗を無視し
たことを示す"failure
ignored"という表示が。
pm01のPostgreSQLは停止
状態。
pm02のPostgreSQLは
Master状態。
pm01の"Failed actions"に
vip-masterで停止が失敗した
旨が表示される。

75
Linux-HA Japan
12:01:35 pm01 pgsql(pgsql)[3154]: INFO: PostgreSQL is down
12:01:35 pm01 crmd[58179]: notice: process_lrm_event: Operation pgsql_monitor_9000: not running (node=pm01, call=84, rc=7,
～略～)
12:01:36 pm01 crmd[58179]: notice: process_lrm_event: Operation vip-rep_stop_0: unknown error (node=pm01, call=112, rc=1,
～略～)
 vip-rep停止失敗時のha-log
→pm01のPostgreSQLの故障(not running)を検知し、F.O開始（PostgreSQL demote成功）
→F.Oに伴うvip-repの停止に失敗（unknown error, リターンコード1)
→vip-masterとPostgreSQLの停止が成功（vip-repの停止失敗を無視しF.Oを継続）
→全リソースのpm02での起動成功（F.O完了）

76
Linux-HA Japan
 vip-rep停止失敗時の復旧方法
 故障した方のPacemakerおよびvip-repを手動で停止します。
 Pacemaker停止の上、OS再起動でも可

77
Linux-HA Japan
 vip-master停止失敗時の動作（擬人化）
ペーコロ
全リソース停止！
vip-masterの停止失敗っす！
もはや僕では停止できない・・・
誰か僕を止めて！
時間
IPaddr2
(vip-master)
192.168.0.3
ここで「PostgreSQL強制停止」
(リソース停止を発生させるため)
了解！
ありが・・・・
了解！
ぺーちゃんをSTONITH！
（ぺーちゃんの意思を受け継
いで）リソース起動！
vip-masterのstopのon-failが
"fence"のため、「STONITHが必要」
と判断します。

78
Linux-HA Japan
 vip-master停止失敗後のcrm_mon
～～
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
* Node pm02:
Migration summary:
* Node pm01:
* Node pm02:
OFFLINE: [ pm01 ]
～～
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm02:
Migration summary:
* Node pm02:
pm01が
OFFLINE（クラス
タに未参加)に
故障後
(pm02で表示)
pm02でリソース
が起動(F.O完了)
pm01の属性値
pm02のpgsqlが
Masterに。
（pgsql-status属
性値がPRIに)

79
Linux-HA Japan
13:49:11 pm01 pgsql(pgsql)[16179]: INFO: PostgreSQL is down
13:49:12 pm01 crmd[2998]: notice: process_lrm_event: Operation vip-master_stop_0: unknown error (node=pm01, call=120, rc=1,
～略～)
 vip-master停止失敗時のha-log
13:49:19 pm02 stonith-ng[38061]: notice: log_operation: Operation 'reboot' [41647] (call 2 from crmd.2998) for host 'pm01' with
device 'prmStonith1-2' returned: 0 (OK)
→pm01のPostgreSQLの故障(not running)を検知し、F.O開始（PostgreSQL demote成功）
→F.Oに伴うvip-masterの停止に失敗（unknown error, リターンコード1)
→Master(pm01)をSTONITH(強制電源断)することに決定。
→全リソースのpm02での起動成功（F.O完了）
→Master(pm01)のSTONITHがprmStonith1-2リソースを使用して成功(リターンコード0)した。

80
Linux-HA Japan
 vip-master停止失敗時の復旧方法
 故障した方を、Slaveとして初期構築時と同様に組み込むことで復旧できます。
 STONITHされたノードを再度Masterにしたい場合、手動でF.Oを発生させ、再度
Slaveを初期構築と同様に組み込みます。

81
Linux-HA Japan
⑤
コミュニティ紹介

82
Linux-HA Japan
http://linux-ha.osdn.jp/wp/
http://osdn.jp/projects/linux-ha/
※URLが「sourceforge.jp」か
ら「osdn.jp」に変わりました！
 Pacemakerの日本公式コミュニティとして「Linux-HA Japan」を
運営しています。
 Pacemaker関連の最新情報を日本語で発信しています。
 Pacemakerのrpmパッケージ(*)の配布も行っています。
(*)関連パッケージをまとめ、インストールが楽なリポジトリパッケージを作成・公開しています。
・・・最新情報発信、ML登録はこちらから
・・・rpmパッケージダウンロードはこちらから

83
Linux-HA Japan
Linux-HA Japanメーリングリスト
• ML登録用URL
http://linux-ha.osdn.jp/
の「メーリングリスト」をクリック
• MLアドレス
linux-ha-japan@lists.osdn.me
日本におけるHAクラスタについての活発な意見交換の場として
「Linux-HA Japan日本語メーリングリスト」も開設しています。
Linux-HA-Japan MLでは、Pacemaker、Corosync、DRBDなど、
HAクラスタに関連する話題を歓迎！PG-REXの話題もどうぞ！
※スパム防止のために、登録者以外の投稿は許可制です
※メアドが「sourceforge.jp」から
「osdn.me」に変わりました！

84
Linux-HA Japan
PG-REXコミュニティ
PG-REXに特化し、構築、運用マニュアルや、運用が楽になる補
助ツール等を開発・配布する日本語コミュニティサイトも運営して
います。
http://osdn.jp/projects/pg-rex/

85
Linux-HA Japan
ご清聴ありがとうございました。
Linux-HA Japan 検索
http://linux-ha.osdn.jp/
PG-REX 検索

86
Linux-HA Japan
 参考1：本構成例のcrm設定 [1/5]
property ¥
no-quorum-policy="ignore" ¥
stonith-enabled="true" ¥
startup-fencing="false"
rsc_defaults ¥
resource-stickiness="INFINITY" ¥
migration-threshold="1"
group master-group ¥
vip-master ¥
vip-rep
ms msPostgresql ¥
pgsql ¥
meta ¥
master-max="1" ¥
master-node-max="1" ¥
clone-max="2" ¥
clone-node-max="1" ¥
notify="true"
clone clnPing ¥
prmPing
clone clnDiskd1 ¥
prmDiskd1
group grpStonith1 ¥
prmStonith1-1 ¥
prmStonith1-2
group grpStonith2 ¥
prmStonith2-1 ¥
prmStonith2-2
fencing_topology ¥
pm01: prmStonith1-1 prmStonith1-2 ¥
pm02: prmStonith2-1 prmStonith2-2
このcrm設定で以下のようなリソース構成を定義しています。
●STONITHは有効です。
●以下リソースを定義しています。
・primitiveリソース
・vip-master(サービス接続用仮想IPアドレス)
・vip-rep(レプリケーション接続用仮想IPアドレス)
・pgsql(PostgreSQL)
・ping(ネットワーク監視)
・diskd(ディスク監視)
・STONITH(stonith-helperおよびipmi×両系分)
・リソースグループ
・master-group(vip-master,vip-rep)
・grpStonith1(pm01用STONITHリソースのグループ)
・grpStonith2(pm02用STONITHリソースのグループ)
・Master/Slaveリソース
・msPostgresql(PostgreSQLのMaster/Slave)
・クローンリソース
・clnPing(ネットワーク監視を両系で実施）
・clnDiskd1(ディスク監視を両系で実施）
●Master側では以下順でリソースを起動
[ping, diskd]→pgsql(Master)→vip-master→vip-rep
※[ ]内は順不同。STONITHは上記と並行して起動。
●Slave側では以下順でリソースを起動
[ping, diskd]→pgsql(Slave)
※[ ]内は順不同。STONITHは上記と並行して起動。

87
Linux-HA Japan
primitive vip-master ocf:heartbeat:IPaddr2 ¥
params ¥
ip="192.168.0.3" ¥
nic="eno2" ¥
cidr_netmask="24" ¥
op start interval="0s" timeout="60s" on-fail="restart" ¥
op monitor interval="10s" timeout="60s" on-fail="restart" ¥
op stop interval="0s" timeout="60s" on-fail="fence"
primitive vip-rep ocf:heartbeat:IPaddr2 ¥
params ¥
ip="192.168.2.3" ¥
nic="ens1f1" ¥
cidr_netmask="24" ¥
meta ¥
migration-threshold="0" ¥
op start interval="0s" timeout="60s" on-fail="stop" ¥
op stop interval="0s" timeout="60s" on-fail="ignore"
primitive pgsql ocf:heartbeat:pgsql ¥
params ¥
pgctl="/usr/pgsql-9.4/bin/pg_ctl" ¥
start_opt="-p 5432" ¥
psql="/usr/pgsql-9.4/bin/psql" ¥
pgdata="/var/lib/pgsql/dbfp/9.4/pgdata/data" ¥
pgdba="postgres" ¥
pgport="5432" ¥
pgdb="template1" ¥
rep_mode="sync" ¥
node_list="pm01 pm02" ¥
master_ip="192.168.2.3" ¥
restore_command="/bin/cp /var/lib/pgsql/dbfp/9.4/pgarch/arc1/%f %p" ¥
repuser="repuser" ¥
primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" ¥
stop_escalate="0" ¥
xlog_check_count="0" ¥
op monitor role="Master" interval="9s" timeout="60s" on-fail="restart" ¥
op promote interval="0s" timeout="300s" on-fail="restart" ¥
op demote interval="0s" timeout="300s" on-fail="fence" ¥
op notify interval="0s" timeout="60s" ¥

88
Linux-HA Japan
primitive prmPing ocf:pacemaker:ping ¥
params ¥
name="default_ping_set" ¥
host_list="192.168.0.101" ¥
multiplier="100" ¥
attempts="2" ¥
timeout="2" ¥
debug="true" ¥
primitive prmDiskd1 ocf:pacemaker:diskd ¥
params ¥
name="diskcheck_status_internal" ¥
device="/dev/sda" ¥
options="-e" ¥
interval="10" ¥
dampen="2" ¥
primitive prmStonith1-1 stonith:external/stonith-helper ¥
params ¥
pcmk_reboot_retries="1" ¥
pcmk_reboot_timeout="40s" ¥
hostlist="pm01" ¥
dead_check_target="192.168.0.1 192.168.1.1 192.168.2.1 192.168.30.61 192.168.30.63" ¥
standby_check_command="/usr/sbin/crm_resource -r master-group -W | grep -qi `hostname`" ¥
standby_wait_time="10" ¥
run_online_check="yes" ¥

89
Linux-HA Japan
primitive prmStonith1-2 stonith:external/ipmi ¥
params ¥
hostname="pm01" ¥
ipaddr="192.168.30.63" ¥
userid="ユーザ名" ¥
passwd="パスワード" ¥
interface="lanplus" ¥
primitive prmStonith2-1 stonith:external/stonith-helper ¥
params ¥
pcmk_reboot_retries="1" ¥
hostlist="pm02" ¥
dead_check_target="192.168.0.2 192.168.1.2 192.168.2.2 192.168.30.62 192.168.30.64" ¥
standby_check_command="/usr/sbin/crm_resource -r master-group -W | grep -qi `hostname`" ¥
standby_wait_time="10" ¥
run_online_check="yes" ¥
primitive prmStonith2-2 stonith:external/ipmi ¥
params ¥
hostname="pm02" ¥
ipaddr="192.168.30.64" ¥
userid="ユーザ名" ¥
passwd="パスワード" ¥
interface="lanplus" ¥

90
Linux-HA Japan
location rsc_location-1 msPostgresql ¥
rule -INFINITY: not_defined default_ping_set or default_ping_set lt 100 ¥
rule -INFINITY: not_defined diskcheck_status_internal or diskcheck_status_internal eq ERROR
location rsc_location-2 grpStonith1 ¥
rule -INFINITY: #uname eq pm01
location rsc_location-3 grpStonith2 ¥
rule -INFINITY: #uname eq pm02
colocation rsc_colocation-1 INFINITY: msPostgresql clnPing
colocation rsc_colocation-2 INFINITY: msPostgresql clnDiskd1
colocation rsc_colocation-3 INFINITY: master-group msPostgresql:Master
order rsc_order-1 0: clnPing msPostgresql symmetrical=false
order rsc_order-2 0: clnDiskd1 msPostgresql symmetrical=false
order rsc_order-3 INFINITY: msPostgresql:promote master-group:start symmetrical=false
order rsc_order-4 0: msPostgresql:demote master-group:stop symmetrical=false

91
Linux-HA Japan
 参考2：サービスLAN側ルータ故障時の動作（擬人化）
ペーコロ
ここで「ルータ停止」
時間
はーいはーい
・・・・・・
）
pingﾘｿｰｽ pingﾘｿｰｽ
いや無理！こっちも属性値が変だし！
（
あれ？返事がない・・あれ？返事がない・・
ネットワーク監視の属性
値を変えなきゃ・・・
ネットワーク監視の属性
値を変えなきゃ・・・
→というわけで両系でリソースが停止します。
ルータ

PG-REXで学ぶPacemaker運用の実例

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PG-REXで学ぶPacemaker運用の実例

Similar to PG-REXで学ぶPacemaker運用の実例 (20)

Recently uploaded

Recently uploaded (7)

PG-REXで学ぶPacemaker運用の実例