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


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)


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」を使用します。

https://osdn.jp/projects/pg-rex/releases/p14586




https://osdn.jp/projects/pg-rex/releases/62997




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について [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:




+ 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について [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 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


Master Slave

PostgreSQL (Slave)

pm01 pm02

1.1 1.1

クライアント

→故障しうる箇所と、故障時のPacemakerの動作・復旧方法を

把握しておくことで故障に迅速に対応でき、可用性を保てる。

※STONITH用LANもありますが表記を省略しています。

NW監視(ping)


STONITH



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故障 ②

ネットワーク故障レプリケーションLAN故障 ① サービスLAN故障 ② ハートビートLAN故障 ③

ノード故障カーネルハング ③ 電源停止 ③

Pacemakerプロセス故障 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

～～ 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(リソースが起動)になる。



39 Linux-HA Japan

リソース故障 vip-master故障後のcrm_mon

PostgreSQLの故障も表示されるのはなぜ？

PostgreSQLは仕様上、MasterをSlaveに降格(demote)という状態遷移ができません。

Masterは直接停止するしかありません。

Master Stop Slave の状態遷移

Master Stop 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の動作故障再現方法(コマンド)※


レプリケーション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 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:



+ master-pgsql : -INFINITY

+ pgsql-data-status : DISCONNECT

+ 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

はーい・・・

あれ？返事がない・・・

ネットワーク監視の属性値を変えなきゃ・・・

）

属性値が変だ！

フェイルオーバしなきゃ！

pingﾘｿｰｽ pingﾘｿｰｽ



了解！

ルータ

50 Linux-HA Japan

サービスLAN故障後のcrm_mon



～～





Masters: [ pm02 ]

Stopped: [ pm01 ]

～～

Node Attributes:

* Node pm01:

+ default_ping_set : 0 : Connectivity is lost


+ master-pgsql : -INFINITY

+ pgsql-data-status : DISCONNECT

+ pgsql-status : STOP

* 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

ノード故障大項目小項目 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 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:



pm02でリソースが起動(F.O完了)


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を初期構築と同様に組み込みます。

「pg-rex_switchover」コマンドなら一発！

63 Linux-HA Japan

Pacemakerプロセス故障

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 Linux-HA Japan

pacemakerdプロセス故障時の動作（擬人化）

Pacemakerプロセス故障



ペーコロ

ここで「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:

Pacemakerプロセス故障 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): ～略～

Pacemakerプロセス故障 pacemakerdプロセス故障時のha-log

→(pacemakerdが停止したので)pacemakerdとの接続に失敗した

→Pacemaker(pacemakerd)が（再）起動した


68 Linux-HA Japan

Pacemakerプロセス故障 pacemakerdプロセス故障時の復旧方法

特に復旧する必要はありません。

プロセス故障が頻発する場合は、真の原因（メモリ不足？、設定ミス？ etc...）を探すとよいです。

難しい場合は、遠慮なくLinux-HA Japan MLへ質問してください！

質問する場合、「crm_mon(の表示。属性値も。)」「ha-log」があると捗ります！

（ってかログなしでは解析できません・・・）

69 Linux-HA Japan

ディスク故障

70 Linux-HA Japan

ディスク故障大項目小項目 Pacemakerの動作故障再現方法(コマンド)

ディスク故障内蔵ディスク故障 ② or ③ ディスクを引っこ抜く！


②通常F.O

③STONITH後F.O

凡例

故障概要

ディスクはディスク監視機能(diskd)で監視します。

OSのコマンドが配置された内蔵ディスクが故障した場合、リソース停止に使うコマンド(RA自体やpsql、umount、ipコマンド etc...)が使用できたり、できなかったりします。

コマンドが使用できる場合②の動作、できない場合は③の動作となります。

②の動作の場合、前述の「サービスLAN故障」の動作とほぼ同じです。（なので擬人化・ログ紹介は割愛します。）

③の動作の場合、後述の「リソース停止失敗」の動作とほぼ同じです。（なので擬人化・ログ紹介は割愛します。）

補足： OSのディスクキャッシュにコマンド（のバイナリファイル）が存在する場合、ディスクが故障してもコマンドが実行できます。が、Linuxの場合キャッシュはメモリ残量に応じて削除されたりもするので、コマンドが使用できたり、できなかったりします。

71 Linux-HA Japan


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 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

～～ 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で停止が失敗した旨が表示される。



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:



pm02でリソースが起動(F.O完了)


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を初期構築と同様に組み込みます。

「pg-rex_switchover」コマンドなら一発！

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アドレス [email protected]

日本におけるHAクラスタについての活発な意見交換の場として「Linux-HA Japan日本語メーリングリスト」も開設しています。

Linux-HA-Japan MLでは、Pacemaker、Corosync、DRBDなど、 HAクラスタに関連する話題を歓迎！PG-REXの話題もどうぞ！

※スパム防止のために、登録者以外の投稿は許可制です

※メアドが「sourceforge.jp」から「osdn.me」に変わりました！

mailto:[email protected]





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 検索

http://linux-ha.sourceforge.jp/





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 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 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 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 stop interval="0s" timeout="60s" on-fail="ignore"


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 ペーコロ

ここで「ルータ停止」

時間

はーいはーい

ルータさんにping ルータさんにping

・・・・・・

）

pingﾘｿｰｽ pingﾘｿｰｽ



いや無理！こっちも属性値が変だし！

（

あれ？返事がない・・あれ？返事がない・・







→というわけで両系でリソースが停止します。

ルータ

pg-rexで学ぶpacemaker運用の実例

Technology