2015.10.3 にOSC2015 Fukuoka(＠九州産業大学）で講演した資料です。 PacemakerとPostgreSQLのレプリケーション機能を組み合わせた「PG-REX」(*)は、共有ディスクを使用しない安価な構成で、商用運用にも耐える可用性を実現することができます。 このPG-REXを含むPacemakerによるクラスタ構成は初期構築後、実際の故障が発生した際にその効果を発揮しますが、ログやコマンドが複雑で、フェイルオーバの原因を突き止めたり、 その後に正しい状態に復旧する方法がわからない、といった問い合わせを受けることが多々あります。 そこで、デモでも使用しているPG-REXを例として、故障内容によるPacemakerの挙動の違い、および原因解析方法、復旧方法を、実例を挙げながら網羅的にご説明します。 * PG-REXのコミュニティも立ち上げ、普及に努めています。 　コミュニティURL：http://osdn.jp/projects/pg-rex/

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

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

3. 3
Linux-HA Japan
①
Pacemakerって何？

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

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

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

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

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

9. 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. 10
Linux-HA Japan
②前準備
PG-REXって何？
前提構成と構築手順（ざっくり）
Pacemaker運用三種の神器

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

12. 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. 13
Linux-HA Japan
②前準備
PG-REXって何？
前提構成と構築手順（ざっくり）
Pacemaker運用三種の神器

14. 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)
仮想IPアドレス
(IPaddr2)
NW監視(ping)
ディスク監視(diskd)
STONITH
7.1 7.1

15. 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. 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. 17
Linux-HA Japan
②前準備
PG-REXって何？
前提構成と構築手順（ざっくり）
Pacemaker運用三種の神器

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

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

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

22. 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. 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. 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. 25
Linux-HA Japan
③
クラスタ故障の種類

26. 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)
ディスク監視(diskd)
STONITH
仮想IPアドレス
(IPaddr2)
仮想IPアドレス
(IPaddr2)
NW監視(ping)
ディスク監視(diskd)
STONITH
7.1 7.1

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

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

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

32. 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. 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. 34
Linux-HA Japan
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
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
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
故障前 故障後
pm01のMigration summary
および"Failed actions"にvip-
repで故障が発生した旨が表
示される。
vip-repは再起動されるため、
リソースおよび属性値に変化
はない。
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

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

37. 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. 38
Linux-HA Japan
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm02
vip-rep (ocf::heartbeat:IPaddr2): Started pm02
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
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-
reason='none', last-rc-change='Mon Sep 7 14:38:50 2015', queued=0ms, exec=0ms
pgsql_monitor_10000 on pm01 'not running' (7): call=117, status=complete, exit-
reason='none', last-rc-change='Mon Sep 7 14:38:54 2015', queued=0ms, exec=119ms
 リソース故障
 vip-master故障後のcrm_mon
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
故障前 故障後
pm01のMigration summary
および"Failed actions"にvip-
masterで故障が発生した旨
が表示される。
同時にPostgreSQLの故障も
表示される。
フェイルオーバし、pm02が
Master(リソースが起動)にな
る。
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

39. 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. 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. 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=稼働していない)を検知
Masterのha-log抜粋
→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. 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. 43
Linux-HA Japan
ネットワーク故障

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

45. 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. 46
Linux-HA Japan
 レプリケーションLAN故障後のcrm_mon
 ネットワーク故障
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : HS:alone
Migration summary:
* Node pm01:
* Node pm02:
故障前 故障後
pm02のpgsql-*属性
値が、故障を示す値
(DISCONNECT|HS:a
lone)に
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

47. 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
 ネットワーク故障
Masterのha-log抜粋
Slaveの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. 48
Linux-HA Japan
 レプリケーションLAN故障時の復旧方法
 ネットワーク故障
 Slave側のPacemakerを一旦停止します。
 故障したレプリケーションLANを復旧します。
 疑似故障の場合iptables のDROPルールを削除するのを忘れずに・・
 再度Slaveを初期構築と同様に組み込みます。
 「pg-rex_slave_start」コマンドなら一発！

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

50. 50
Linux-HA Japan
 サービスLAN故障後のcrm_mon
 ネットワーク故障
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm02
vip-rep (ocf::heartbeat:IPaddr2): Started pm02
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 0 : Connectivity is lost
+ diskcheck_status_internal : normal
+ master-pgsql : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
Migration summary:
* Node pm01:
* Node pm02:
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
故障前 故障後
pm01の
default_ping_set属性
値は0に下がる。
リソースがpm02で起
動／Masterになる。
pm01のPostgreSQL
の属性値は停止を示
す値に。
pm02のPostgreSQL
の属性値はMasterで
あることを示す値に。
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

51. 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)
11:52:33 pm01 crmd[30453]: notice: process_lrm_event: Operation pgsql_demote_0: ok (node=pm01, call=100, rc=0, ～略～)
11:52:34 pm01 crmd[30453]: notice: process_lrm_event: Operation pgsql_stop_0: ok (node=pm01, call=106, rc=0, ～略～)
11:52:36 pm01 crmd[30453]: notice: process_lrm_event: Operation vip-rep_stop_0: ok (node=pm01, call=111, rc=0, ～略～)
11:52:36 pm01 crmd[30453]: notice: process_lrm_event: Operation vip-master_stop_0: ok (node=pm01, call=113, rc=0, ～略～)
→Master(pm01)のdefault_ping_set属性値が0に変更された（＝pingが失敗した）。
→仮想IP(VIP)をpm02へ移動（フェイルオーバ）することに決定。
→pm01のPostgreSQLを停止し、pm02で昇格(promote)することに決定。
Masterのha-log抜粋
→pm01のPostgreSQLのdemote(降格)／stop(停止)が成功。
→pm01の仮想IP(VIP)のstop(停止)が成功。
（重要な箇所を黄色で強調しています）

52. 52
Linux-HA Japan
11:52:35 pm02 crmd[14849]: notice: process_lrm_event: Operation pgsql_promote_0: ok (node=pm02, call=76, rc=0, ～略～)
11:52:37 pm02 crmd[14849]: notice: process_lrm_event: Operation vip-master_start_0: ok (node=pm02, call=86, rc=0, ～略～)
11:52:37 pm02 crmd[14849]: notice: process_lrm_event: Operation vip-rep_start_0: ok (node=pm02, call=89, rc=0, ～略～)
 サービスLAN故障時のha-log
 ネットワーク故障
→pm02のPostgreSQLのpromote(昇格)が成功（＝Masterになった）。
Slaveのha-log抜粋
→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. 53
Linux-HA Japan
 サービスLAN故障時の復旧方法
 ネットワーク故障
 故障した方のPacemakerを一旦停止します。
 故障したサービスLANを復旧します。
 疑似故障の場合iptables のDROPルールを削除するのを忘れずに・・
 故障した方の「/var/lib/pgsql/tmp/PGSQL.lock」ファイルを削除します。
 再度Slaveを初期構築と同様に組み込みます。
 「pg-rex_slave_start」コマンドなら一発！

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

55. 55
Linux-HA Japan
 ハートビートLAN故障後のcrm_mon
 ネットワーク故障
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
故障前 Online: [ pm01 ]
OFFLINE: [ pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Stopped: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
Migration summary:
* Node pm01:
pm02が
OFFLINE（クラス
タに未参加)に
故障後
(pm01で表示)
リソースはpm01
で起動のまま。
pm02の属性値
表示は無くなる。
※故障前と比較しやす
いよう空白としているが、
実際には空白はない。
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

56. 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.
10:29:51 pm02 corosync[51694]: [TOTEM ] A new membership (192.168.1.2:356) was formed. Members left: -1062731519
10:29:52 pm02 pengine[51706]: warning: stage6: Scheduling Node pm01 for STONITH
 ハートビートLAN故障時のha-log
 ネットワーク故障
Masterのha-log抜粋
Slaveのha-log抜粋
→pgsql RAがSlave(pm02)を切り離し（非同期モードにPostgreSQLの設定を変更）
→PostgreSQLの設定を変更したのでreloadを実行し反映
→クラスタのメンバが192.168.1.1のみになった（1台離脱した）。
→(急にクラスタから離脱したので)Slave(pm02)をSTONITH(強制電源断)することに決定。
→Slave(pm02)のSTONITHがprmStonith2-2リソースを使用して成功(リターンコード0)した。
→クラスタのメンバが192.168.1.2のみになった（1台離脱した）。
→(急にクラスタから離脱したので)Slave(pm01)をSTONITH(強制電源断)することに決定。
（重要な箇所を黄色で強調しています）

57. 57
Linux-HA Japan
 ハートビートLAN故障時の復旧方法
 ネットワーク故障
 故障したハートビートLANを復旧します。
 疑似故障の場合iptables のDROPルールを削除するのを忘れずに・・
 再度Slaveを初期構築と同様に組み込みます。
 「pg-rex_slave_start」コマンドなら一発！

58. 58
Linux-HA Japan
ノード故障

59. 59
Linux-HA Japan
 ノード故障
大項目 小項目 Pacemakerの動作 故障再現方法(コマンド)
ノード故障
カーネルハング ③ # 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. 60
Linux-HA Japan
 ノード故障
 ノード故障後のcrm_mon
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
故障前 Online: [ pm02 ]
OFFLINE: [ pm01 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm02
vip-rep (ocf::heartbeat:IPaddr2): Started pm02
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
Migration summary:
* Node pm01:
* Node pm02:
pm01が
OFFLINE（クラス
タに未参加)に
故障後
(pm02で表示)
pm02でリソース
が起動(F.O完了)
pm01の属性値
表示は無くなる。
※故障前と比較しやす
いよう空白としているが、
実際には空白はない。
pm02のpgsqlが
Masterに。
（pgsql-status属
性値がPRIに)
（故障前との差分を黄色で強調しています）

61. 61
Linux-HA Japan
 ノード故障
 ノード故障時のha-log
11:31:55 pm02 corosync[35520]: [TOTEM ] A new membership (192.168.1.2:312) was formed. Members left: -1062731519
11:31:56 pm02 pengine[35531]: warning: stage6: Scheduling Node pm01 for STONITH
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)
11:32:15 pm02 crmd[35532]: notice: process_lrm_event: Operation pgsql_promote_0: ok (node=pm02, call=75, rc=0, ～略～)
11:32:17 pm02 crmd[35532]: notice: process_lrm_event: Operation vip-master_start_0: ok (node=pm02, call=84, rc=0, ～略～)
11:32:17 pm02 crmd[35532]: notice: process_lrm_event: Operation vip-rep_start_0: ok (node=pm02, call=86, rc=0, ～略～)
→クラスタのメンバが192.168.1.2のみになった（1台離脱した）。
→(急にクラスタから離脱したので)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. 62
Linux-HA Japan
 ノード故障
 復旧方法
 故障した方の「/var/lib/pgsql/tmp/PGSQL.lock」ファイルを削除します。
 STONITHで停止(再起動)したノードを、Slaveとして初期構築時と同様に組み込
むことで復旧できます。
 「pg-rex_slave_start」コマンドなら一発！
 STONITHされたノードを再度Masterにしたい場合、手動でF.Oを発生させ、再度
Slaveを初期構築と同様に組み込みます。
 「pg-rex_switchover」コマンドなら一発！

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

64. 64
Linux-HA Japan
 Pacemakerプロセス故障
大項目 小項目 Pacemakerの動作 故障再現方法(コマンド)
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. 65
Linux-HA Japan
 pacemakerdプロセス故障時の動作（擬人化）
 Pacemakerプロセス故障
コロちゃん大丈夫かー？
大丈夫。ぺーちゃんは？
ペー コロ
ここで「pacemakerd」停止
時間
あ、ペーちゃん(の一部)が停止した。
再起動してあげなきゃ。
pacemakerdの停止に気づくのは
OS(CentOS6：upstart、CentOS7：
systemd）です。
再起動後、何事もなかったかのよう
に通信を再開します。
うん大丈夫。
pacemakerd再起動！
コロちゃん大丈夫かー？
大丈夫。ぺーちゃんは？
うん大丈夫。

66. 66
Linux-HA Japan
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
 Pacemakerプロセス故障
 pacemakerdプロセス故障後のcrm_mon
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
故障前 故障後
故障前後で違いはありません！
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。

67. 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): ～略～
 Pacemakerプロセス故障
 pacemakerdプロセス故障時のha-log
→(pacemakerdが停止したので)pacemakerdとの接続に失敗した
→Pacemaker(pacemakerd)が（再）起動した
Masterのha-log抜粋

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

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

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

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

72. 72
Linux-HA Japan
 リソース停止失敗
大項目 小項目 Pacemakerの動作 故障再現方法(コマンド)
リソース停止失敗
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. 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. 74
Linux-HA Japan
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm02
vip-rep (ocf::heartbeat:IPaddr2): Started pm02 (failure ignored)
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
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
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
故障前 故障後
全リソースがpm02にフェイル
オーバ。
vip-repは停止失敗を無視し
たことを示す"failure
ignored"という表示が。
pm01のPostgreSQLは停止
状態。
pm02のPostgreSQLは
Master状態。
pm01の"Failed actions"に
vip-masterで停止が失敗した
旨が表示される。
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
（故障前との差分を黄色で強調しています）

75. 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:35 pm01 crmd[58179]: notice: process_lrm_event: Operation pgsql_demote_0: ok (node=pm01, call=109, rc=0, ～略～)
12:01:36 pm01 crmd[58179]: notice: process_lrm_event: Operation vip-rep_stop_0: unknown error (node=pm01, call=112, rc=1,
～略～)
12:01:36 pm01 crmd[58179]: notice: process_lrm_event: Operation vip-master_stop_0: ok (node=pm01, call=116, rc=0, ～略～)
12:01:36 pm01 crmd[58179]: notice: process_lrm_event: Operation pgsql_stop_0: ok (node=pm01, call=121, rc=0, ～略～)
 リソース停止失敗
 vip-rep停止失敗時のha-log
Masterのha-log抜粋
12:01:38 pm02 crmd[61486]: notice: process_lrm_event: Operation pgsql_promote_0: ok (node=pm02, call=78, rc=0, ～略～)
12:01:40 pm02 crmd[61486]: notice: process_lrm_event: Operation vip-master_start_0: ok (node=pm02, call=91, rc=0, ～略～)
12:01:40 pm02 crmd[61486]: notice: process_lrm_event: Operation vip-rep_start_0: ok (node=pm02, call=93, rc=0, ～略～)
→pm01のPostgreSQLの故障(not running)を検知し、F.O開始（PostgreSQL demote成功）
→F.Oに伴うvip-repの停止に失敗（unknown error, リターンコード1)
→vip-masterとPostgreSQLの停止が成功（vip-repの停止失敗を無視しF.Oを継続）
Slaveのha-log抜粋
→全リソースのpm02での起動成功（F.O完了）
（重要な箇所を黄色で強調しています）

76. 76
Linux-HA Japan
 リソース停止失敗
 vip-rep停止失敗時の復旧方法
 故障した方のPacemakerおよびvip-repを手動で停止します。
 Pacemaker停止の上、OS再起動でも可
 故障した方の「/var/lib/pgsql/tmp/PGSQL.lock」ファイルを削除します。
 再度Slaveを初期構築と同様に組み込みます。
 「pg-rex_slave_start」コマンドなら一発！

77. 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. 78
Linux-HA Japan
 リソース停止失敗
 vip-master停止失敗後のcrm_mon
Online: [ pm01 pm02 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm01
vip-rep (ocf::heartbeat:IPaddr2): Started pm01
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm01 ]
Slaves: [ pm02 ]
～～
Node Attributes:
* Node pm01:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|SYNC
+ pgsql-status : HS:sync
Migration summary:
* Node pm01:
* Node pm02:
※基本情報、ping/diskd/STONITHリソースおよびringnumber属性値の表示を省略しています。
故障前 Online: [ pm02 ]
OFFLINE: [ pm01 ]
～～
Resource Group: master-group
vip-master (ocf::heartbeat:IPaddr2): Started pm02
vip-rep (ocf::heartbeat:IPaddr2): Started pm02
Master/Slave Set: msPostgresql [pgsql]
Masters: [ pm02 ]
Stopped: [ pm01 ]
～～
Node Attributes:
* Node pm02:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-status : PRI
Migration summary:
* Node pm02:
pm01が
OFFLINE（クラス
タに未参加)に
故障後
(pm02で表示)
pm02でリソース
が起動(F.O完了)
pm01の属性値
表示は無くなる。
※故障前と比較しやす
いよう空白としているが、
実際には空白はない。
pm02のpgsqlが
Masterに。
（pgsql-status属
性値がPRIに)
（故障前との差分を黄色で強調しています）

79. 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 pgsql_demote_0: ok (node=pm01, call=113, rc=0, ～略～)
13:49:12 pm01 crmd[2998]: notice: process_lrm_event: Operation vip-rep_stop_0: ok (node=pm01, call=116, rc=0, ～略～)
13:49:12 pm01 crmd[2998]: notice: process_lrm_event: Operation vip-master_stop_0: unknown error (node=pm01, call=120, rc=1,
～略～)
13:49:12 pm01 pengine[2997]: warning: stage6: Scheduling Node pm01 for STONITH
 リソース停止失敗
 vip-master停止失敗時のha-log
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)
13:49:23 pm02 crmd[38065]: notice: process_lrm_event: Operation pgsql_promote_0: ok (node=pm02, call=79, rc=0, ～略～)
13:49:23 pm02 crmd[38065]: notice: process_lrm_event: Operation vip-master_start_0: ok (node=pm02, call=88, rc=0, ～略～)
13:49:23 pm02 crmd[38065]: notice: process_lrm_event: Operation vip-rep_start_0: ok (node=pm02, call=90, rc=0, ～略～)
→pm01のPostgreSQLの故障(not running)を検知し、F.O開始（PostgreSQL demote成功）
→F.Oに伴うvip-masterの停止に失敗（unknown error, リターンコード1)
→Master(pm01)をSTONITH(強制電源断)することに決定。
Slaveのha-log抜粋
→全リソースのpm02での起動成功（F.O完了）
→Master(pm01)のSTONITHがprmStonith1-2リソースを使用して成功(リターンコード0)した。
（重要な箇所を黄色で強調しています）

80. 80
Linux-HA Japan
 リソース停止失敗
 vip-master停止失敗時の復旧方法
 故障した方の「/var/lib/pgsql/tmp/PGSQL.lock」ファイルを削除します。
 故障した方を、Slaveとして初期構築時と同様に組み込むことで復旧できます。
 「pg-rex_slave_start」コマンドなら一発！
 STONITHされたノードを再度Masterにしたい場合、手動でF.Oを発生させ、再度
Slaveを初期構築と同様に組み込みます。
 「pg-rex_switchover」コマンドなら一発！

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

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

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

86. 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. 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 monitor interval="10s" timeout="60s" on-fail="restart" ¥
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 start interval="0s" timeout="300s" on-fail="restart" ¥
op monitor interval="10s" timeout="60s" on-fail="restart" ¥
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" ¥
op stop interval="0s" timeout="300s" on-fail="fence"
 参考1：本構成例のcrm設定 [2/5]

88. 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" ¥
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 prmDiskd1 ocf:pacemaker:diskd ¥
params ¥
name="diskcheck_status_internal" ¥
device="/dev/sda" ¥
options="-e" ¥
interval="10" ¥
dampen="2" ¥
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 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" ¥
op start interval="0s" timeout="60s" on-fail="restart" ¥
op stop interval="0s" timeout="60s" on-fail="ignore"
 参考1：本構成例のcrm設定 [3/5]

89. 89
Linux-HA Japan
primitive prmStonith1-2 stonith:external/ipmi ¥
params ¥
pcmk_reboot_timeout="60s" ¥
hostname="pm01" ¥
ipaddr="192.168.30.63" ¥
userid="ユーザ名" ¥
passwd="パスワード" ¥
interface="lanplus" ¥
op start interval="0s" timeout="60s" on-fail="restart" ¥
op monitor interval="3600s" timeout="60s" on-fail="restart" ¥
op stop interval="0s" timeout="60s" on-fail="ignore"
primitive prmStonith2-1 stonith:external/stonith-helper ¥
params ¥
pcmk_reboot_retries="1" ¥
pcmk_reboot_timeout="40s" ¥
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" ¥
op start interval="0s" timeout="60s" on-fail="restart" ¥
op stop interval="0s" timeout="60s" on-fail="ignore"
primitive prmStonith2-2 stonith:external/ipmi ¥
params ¥
pcmk_reboot_timeout="60s" ¥
hostname="pm02" ¥
ipaddr="192.168.30.64" ¥
userid="ユーザ名" ¥
passwd="パスワード" ¥
interface="lanplus" ¥
op start interval="0s" timeout="60s" on-fail="restart" ¥
op monitor interval="3600s" timeout="60s" on-fail="restart" ¥
op stop interval="0s" timeout="60s" on-fail="ignore"
 参考1：本構成例のcrm設定 [4/5]

90. 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
 参考1：本構成例のcrm設定 [5/5]

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