PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Conference 2014

Linux-HA Japan Project 1
2014年 3月1日 OSC2014 Tokyo
Linux-HA Japan
渡邉達也 <tatsuya.w@gmail.com>
Pacemakerの
Master/Slave構成の
基本と事例紹介
(DRBD、PostgreSQLレプリケーション)

自己紹介
 名前
 渡邉達也 (@infrajp)
 前職
 ネットワークエンジニア
 Global-ASの運用
 MVNEネットワークシステム開発など
 現職
 Linux OSSテクニカルサポート
 Linux-HA Japanプロジェクト
 Pacemaker・DRBD検証・開発、コミュニティーのML対応など
2

3
本日の流れ
 各アプリケーションの概要
 pacemaker
 DRBD、PostgreSQLレプリケーション
 Master Slave リソースと従来のリソースとの違い
 Masterに昇格するノードの選定方法
 promotionスコア
 Pacemaker + DRBDのMasterスコア
 Pacemaker + PostgreSQLレプリケーションのMasterスコア
 障害事例
 レプリケーションLAN障害
 レプリケーションLAN＋インターコネクトLAN障害

4
Pacemakerとは
サーバ#1 サーバ#2
サービスの監視・制御
 サーバ・アプリケーションの故障監視
サーバ間の監視・制御

5
STONITH
(強制電源断)
Pacemakerとは
 サーバ・アプリケーションの故障監視
 故障検知時、自動的にフェイルオーバ
 ダウンタイムの最小化
フェイルオーバ

6
PostgreSQL
RA
共有ディスク
RA
リソース
エージェント
 Pacemakerが起動/停止/監視を制御する対象をリソースと呼ぶ
 例)Apache, PostgreSQL, ファイルシステム, 仮想IPアドレス etc...
 リソースの制御はリソースエージェント(RA)を介して行う
 RAが各リソースの操作方法の違いをラップし、Pacemakerで制御
できるようにしている
リソース
制御
制御制御
Apache
RA
Pacemakerのアーキテクチャ

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

8
 pacemaker
 DRBD、 PostgreSQLレプリケーション
 障害事例

9
共有ディスクを使用した構成について
 メリット
 データが一箇所のため運用しやすい
 デメリット
 複数ノードが同時にアクセスできないように制御が必要
 共有ディスクが高額
 共有ディスクがSPOFになる
共有ディスク
DB、ファイル
サーバ等
DB、ファイル
サーバ等(未稼働)
稼動系（Active）待機系（Standby）

DRBD、PostgreSQLレプリケーションを使用した構成
 メリット
 安価なローカルディスクを使用してデータを2重化できる
 ディスクがSPOFにならない
 デメリット
 レプリケーションが性能に影響を与える
 複数ノードに分散したデータを同一に保つ必要があり運用が複雑
DRBD or
PostgreSQL
DRBD or
PostgreSQL
ローカルディスクローカルディスク
レプリケーション
データレプリケーションLAN
Master Slave
10

11
 Linuxカーネルのブロックデバイスドライバのレイヤで動作
 様々なデータが複製可能(PostgreSQL, MySQL, Oracle, LDAP ・・・)
 Primary、Secondaryの2台構成が基本。
 Primaryノードは読み書き可能。Secondaryノードは不可。
 3種類の同期モードプロトコルA(非同期)、B(メモリ同期)、C(同期)
DRBD概要
DRBD(Primary) DRBD(Secondary)
Filesystem
①書き込み
②ブロック送信
②書き込み ③書き込み④完了
⑤完了
プロトコルC 設定時の動作例

12
PostgreSQL レプリケーション概要
 PostgreSQL9.0から実装された本体組み込みの機能
 9.0：非同期 9.1：同期 9.2：カスケードレプリケーション
 Master側は更新/参照可、Slave側は参照可。スケールアウトも可
 切替に必要な処理(下記)が少ないためフェイルオーバが早い
 ファイルシステムのマウント、PostgreSQL起動、リカバリ処理
PostgreSQL（Master）
①更新
③WAL送信
②WAL
書き込み
⑤完了
⑥完了
PostgreSQL（Slave）
④WAL
書き込み
同期：正常時動作
参照
WAL反映の
タイミングは
非同期
Filesystem Filesystem

Pacemaker＋DRBD / PostgreSQLレプリケーション構成
 DRBD、PostgreSQLレプリケーション機能はデータの複製のみ
 Pacemakerと組み合わせることで可用性を高めることが可能
13
DRBD or
PostgreSQL
DRBD or
PostgreSQL
インターコネクトLAN
ローカルディスクローカルディスク
データレプリケーションLAN
Master→Slave Slave→Master
フェイルオーバ
障害検知

14
 pacemaker
 障害事例

Primitive
Clone Clone
Master Slave
全てのリソース定義の基礎。どこか一つ
のノードで動作させ、故障時にフェイル
オーバさせたいリソースに使用。
(例) PostgreSQL, Filesystem, IPアドレス
複数のノードで動作させたいリソースに
使用。
(例) NW監視, ディスク監視，apache
複数のノードで動作させる点はcloneと同
じだが、Master Slaveという主従関係の
あるリソースに使用。
(例) DRBD 、PostgreSQL、MySQL
Clone
Primitive
Master Slave(以降、MS)
Primitive
リソースの種類
15

16
Primitiveリソースとcloneリソース(共有ディスク構成での例)
node01
共有ディスク
node02
Pacemaker Pacemaker
pgsql RA
PostgreSQL
 PrimitiveはActiveノードのみ起動、cloneは両ノードで起動
 start/stop/monitorアクションを実行し、RAがリソースを実際に制御
pingd RA
pingd
pingd RA
pingdPostgreSQL
各リソースに対する
制御用コマンド
start/stop/monitor
待機系の
Primitive
リソースは
未稼働
Clone Primitive Clone Primitiveread/write

17
MSリソース(Pacemaker＋DRBDの例)
start/stop/monitor
promote/demote
DRBD RADRBD RA
Pacemaker Pacemaker
DRBD制御用コマンド
 両ノードのDRBDをstartアクションで起動。この時点でSlave状態。
 その後、一方のノードをpromoteアクションでMaster状態に昇格。
 DRBDの停止時にはdemoteによりSlave状態に降格してから停止。
read/write
DRBD
(Master)
DRBD
(Slave)
MS MS
node01 node02

18
MSリソース(Pacemaker＋ PostgreSQLレプリケーション)
start/stop/monitor
promote/demote
PostgreSQL
(Slave)
pgsql RApgsql RA
Pacemaker Pacemaker
PostgreSQL
制御用コマンド
 DRBDとロジックは同じため説明は割愛
PostgreSQL
(Master)
readread/writeMS MS
node01 node02

19
 pacemaker
 障害事例

promotionスコアについて①
 MSリソースは各ノードに対するpromotionスコアを持つ
 promotionスコアが最も高いノードでMSリソースをMasterに昇格
 MSリソースは両系をSlaveとして起動
 その後、promotionスコアが高いノードで昇格
MS(Master)
node01 昇格 node02
MS(Slave)
promotionスコアは
上記の記号で表す。
数値
MS(Slave)
node01 node02
MS(Slave)
起動起動
200 100
20
200 100

21
promotionスコアについて②
 promotionスコアはフェイルオーバの判断にも使用される
 promotionスコアの大小が入れ替わったらフェイルオーバ
 promotionスコアがマイナスならSlaveに留まる
 片系起動時はそのノードが昇格するはずだが昇格抑止されている
 -INFINITYは-1,000,000を意味するスコアの最小値
MS
Master→Slave
MS
Slave→Master
200→100
MS
Slave
MS
停止中
100→200
node01 node02
node01 node02
-INFINITY

22
promotionスコアの求め方
 promotionスコア = location設定値＋Masterスコア (※)
 ①location設定値
 PacemakerのCRM設定で指定
 ②Masterスコア
 DRBDやpgsql RAがデータ状態や接続状態(後述)に応じて設定
 データ状態の良いノードで優先的にMSリソースを昇格可能
location rsc_loc-1 MSリソース名
rule $id="loc-1" $role="master“ 200: #uname eq node01
rule $id="loc-2" $role="master" 100: #uname eq node02
① ②
※参考の下記資料も参照して下さい。
「MSリソースのスコアにresource-stickinessが加算される場合」

23
 pacemaker
 障害事例

Pacemaker+DRBDのMasterスコア設定までの流れ
データ状態（ローカル/対向） Masterスコア
UpToDate/UpToDate
10000
次のスライドで説明
UpToDate/DUnknown
10000(Masterの場合)
1000(Slaveの場合)
障害事例で詳しく説明
PacemakerはMasterスコアに基づいてDRBDを
Master化するノードを決定
DRBDは自ノードと対向ノードのデータの状態を管理
DRBD RA
DRBD
pacemaker
②
状態
確認
③
データ
状態
取得
④
Master
スコア
の設定
DRBD RAは、DRBDの管理するデータ状態に基づ
いてMasterスコアを設定。以下は一例(※)
24
①
監視
※詳細は参考資料の下記ページも参照して下さい
「DRBD RAのデータ状態とMasterスコアの詳細」

Masterスコア設定例
 両系の起動が完了して正常に同期された状態(※)
 locationにはnode01に200、node02に100が設定されているとする
 両系のDRBD RAが自ノードのPacemakerにMasterスコアを設定
Pacemaker Pacemaker
DRBD RA
DRBD(Master)
UpToDate/UpToDate
DRBD RA
DRBD（Slave）
UpToDate/UpToDate
①monitor
②データ
状態確認
※起動時にどちらをMasterに昇格するかについては参考の下記ページを参照
「Pacemaker+DRBD Pacemaker起動から昇格までの流れ」
③データ
状態取得
④Masterスコア
=10000
②データ
状態確認
③データ
状態取得
①monitor
④Masterスコア
=10000
10200 10100
node01 node02

Masterスコアとpromotionスコアの確認方法（DRBDの例）
 Masterスコアの確認方法
 ここでは両ノードが最新データを持つため10000が設定された例
 promotionスコアの確認方法
 node01のlocation=200、node02のlocation=100とした場合
[root@node01 ~]# ptest -sL | grep promotion
prmDrbd:0 promotion score on node01: 10200
prmDrbd:1 promotion score on node02: 10100
[root@node01 ~]# crm_mon -fAr
* Node node01:
+ master-prmDrbd:0 : 10000
* Node node02:
+ master-prmDrbd:1 : 10000
26
Pacemaker1.1系ではptestではなくcrm_simulateを使用

27
 pacemaker
 障害事例

役割接続状態 Masterスコア
Master - 1000(次のスライドで説明)
Slave 同期接続 100(次のスライドで説明)
Slave 切断 -INFINITY(障害事例で説明)
Pacemaker+PostgreSQLのMasterスコア設定までの流れ
Master側のPostgreSQLはSlaveとの接続状態
（同期・非同期・切断中）を管理
PacemakerはMasterスコアに基づいて
PostgreSQLをMaster化するノードを決定
Master側のpgsql RAは自ノードのMasterスコアを
1000に設定するとともに、接続状態を元にSlave側
のMasterスコアについても設定(※)
pgsql RA
PostgreSQL
pacemaker 28
②
状態
確認
③
接続
状態
取得
④
Master
スコア
の設定
①
監視
※詳細は参考資料の下記ページも参照して下さい。
「pgsql RAのデータ状態とMasterスコアの詳細」

Masterスコア設定例
 両系の起動が完了して正常に同期された状態(※)
 locationにはnode01に200、node02に100が設定されているとする
 MasterノードのRAが両ノードのMasterスコアを設定
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master)
同期接続中
pgsql RA
①
monitor
②接続の
状態確認
③接続状態取得
④
Masterスコア=1000
※起動時にどちらをMasterに昇格するかについては参考の下記ページを参照
「Pacemaker+PostgreSQLレプリケーション Pacemaker起動から昇格までの流れ」
④
Masterスコア=100
同期接続
1200 200
node01 node02

Masterスコアの例（PostgreSQLレプリケーション）
 Masterスコアの確認方法
 ここではMaster側：1000、 Slave側は同期接続中のため100
 promotionスコアの確認方法
 node01のlocation=200、node02のlocation=100とした場合
[root@node01 ~]# crm_mon-fAr1
* Node node01:
+ master-pgsql:1 : 1000
* Node node02:
+ master-pgsql:0 : 100
pgsql:0 promotion score on node01: 1200
pgsql:1 promotion score on node02: 200
30
Pacemaker1.1系ではptestではなくcrm_simulateを使用

31
 pacemaker
 障害事例

レプリケーションLAN障害（DRBD）
 両ノードのDRBDはデータ状態をUpToDate/Dunknownに変更
 node01と同期できないためnode02のDRBDは古い可能性有り
 DRBD RAは自ノードがSlaveでデータ状態がUpToDate/DUnknownの
場合はデータが古い可能性があるためMasterスコアを1000に下げる
 フェイルオーバが発生すると古いデータを持つnode02のDRBDが昇格
Pacemaker Pacemaker
DRBD RA
DRBD(Master)
UpToDate/DUnknown
DRBD RA
DRBD（Slave）
UpToDate/DUnknown
①monitor
②データ
状態確認
③データ
状態取得
④Masterスコア
=10000
②データ
状態確認
③データ
状態取得
①monitor
④Masterスコア
=10000→1000
10200 10100→1100
切断
node01 node02

33
レプリケーションLAN障害対策(DRBD)
 DRBD側に以下のfence-peerスクリプトを設定(※)
 レプリケーションLAN切断時にMaster側のDRBDがcrm-fence-
peer.shを実行し、node02が古いデータで昇格するのを抑止。
 レプリケーションLANが復旧して同期が完了すると昇格抑止は解除
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
Pacemaker Pacemaker
DRBD RA
DRBD(Master)
UpToDate/DUnknown
DRBD RA
DRBD（Slave）
UpToDate/DUnknown
10200
1100 →
④ -INFINITY
crm-fence-peer.sh
②切断を検知して実行
①切断
③対向ノードのlocationに –INFINITYを設定
※参考の下記ページの赤字部分も要設定
「Pacemakerと組み合わせる場合のDRBD設定例」
node01 node02

レプリケーションLAN障害（PostgreSQLレプリケーション）
 Master側のpgsql RAはレプリケーション接続が切れた場合、Slave側
のMasterスコアを-INFINITYに更新
 DRBDのように外部スクリプトを指定しなくても、 node02が古いデータ
で昇格するのを抑止する仕様
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master) 切断中
pgsql RA
①
monitor
②接続の
状態確認
④
④Masterスコア
=100→ -INFINITY
1200
200 →
④ -INFINITY
切断
node01 node02

35
 pacemaker
 障害事例

インターコネクトLANとレプリケーションLAN障害(DRBD)
 インターコネクトLANも切断されていることから、 DRBDから実行された
crm-fence-peer.shはnode02を昇格抑止状態にすることができない
 node02のPacemakerはサービス継続するためpromote実行
 node02は昇格し、両系がMasterの状態になってしまう。
36
Pacemaker Pacemaker
DRBD RA
DRBD(Master)
UpToDate/DUnknown
DRBD RA
DRBD（Slave→⑥Master）
UpToDate/DUnknown
10200 1100
crm-fence-peer.sh
②切断を検知して実行
①切断
③location設定不可 ④Promote
⑤昇格コマンド
node01 node02

インターコネクトLANとレプリケーションLAN障害(DRBD) 対策
 両系でMasterになることを防ぐため、STONITHの利用を推奨
 STONITHを使用すると、インターコネクトLAN切断時、Masterは
Slaveが昇格する前に別LANからSlaveの電源をOFF
 STONITHは下記URL参照
 http://sourceforge.jp/projects/linux-
ha/docs/Pacemaker_OSC2013Kyoto_20130803/ja/1/Pacemaker_OSC2013Kyoto_20130803.pdf
Pacemaker
DRBD
(Master)
DRBD
（Slave）
Pacemaker
HW制御
ボード
HW制御
ボード
電源OFF
両系Master状態は防がれる 37

インターコネクトLANとレプリケーションLAN障害(PostgreSQL)
 インターコネクトLANが切断されていることから、 Master側RAは
node02のMasterスコアを-INFINITYに更新することができない
 Pacemakerはスプリットブレイン状態のためnode02でpromote実行
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master) 切断中
pgsql RA
PostgreSQL
（ Slave→⑦Master ）
①
monitor
②接続の
状態確認
④
④Masterスコア
設定不可
1200 200
⑤Promote
⑥昇格コマンド
node01 node02

インターコネクトLANとレプリケーションLAN障害(PostgreSQL) 対策
 STONITHについては説明済みのため割愛
Pacemaker
PostgreSQL
(Master)
PostgreSQL
（Slave）
Pacemaker
HW制御
ボード
HW制御
ボード
電源OFF

まとめ
 MSリソースの特徴
 各ノードで起動し、Master Slaveという２つの状態を持つ
 昇格(promote)、降格(demote)という2つのアクションを実行
 promotionスコア、Masterスコア
 MSリソースはpromotionスコアの大きいノードをMasterに昇格する
 MSリソースのRAがデータ状態に基づきMasterスコアを更新するこ
とで、データ状態の良いノードを優先的にMasterに昇格する
 障害事例と対応策
 fence-peerスクリプトを使用（DRBDの場合）
 STONITHを使用 40

デモについて
 LINUX-HA-JAPANのブースにDRBDとPostgreSQLレプリケーション
構成のデモ環境を用意しています。
pm01
サービス用LAN
データレプリケーション
DRBD
PostgreSQL 9.2
DRBD
Apache
pm02
PostgreSQL 9.2
仮想IP
41

Linux-HA Japan Project
Linux-HA Japanについて
42

43
Linux-HA Japan URL
http://linux-ha.sourceforge.jp/
Pacemaker関連の最新情報を
日本語で発信
Pacemakerのダウンロードもこ
ちらからどうぞ。
(インストールが楽なリポジトリパッケージ
を公開しています。)
http://sourceforge.jp/projects/linux-ha/

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

参考文献
 Pacemaker 1.0 Configuration Explained
 http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html-single/Pacemaker_Explained/
 Colocation Explained
 http://clusterlabs.org/doc/Colocation_Explained.pdf
 リソースエージェント開発者ガイド
 http://linux-
ha.sourceforge.jp/wp/manual/ocf%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%A8%E3%83%B
C%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E9%96%8B%E7%99%BA%E8%80%85%E3%82%AC%
E3%82%A4%E3%83%89
 DRBDユーザーズガイド
 http://www.drbd.jp/users-guide/users-guide.html
 DRBDアドバンスド・チュートリアル
 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/297249828379edfdf8963d9e8ef4c1c3.pdf
 HAクラスタでPostgreSQLを高可用化(後編)
～レプリケーション編～
 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf 45

46Linux-HA Japan Project
ご清聴ありがとうございました。
Linux-HA Japan 検索

48
参考資料の目次
 基本編
 構成例とCRM設定例
 中級編
 Pacemaker起動から昇格までの流れ
 Pacemaker+DRBD
 Pacemaker+PostgreSQLレプリケーション
 障害事例と復旧時の動作
 Slave故障・復旧
 Master故障・復旧
 Master側で起動するprimitiveリソース故障
 インターコネクトLAN故障
 ネットワーク故障
 Disk故障
 上級編
 Masterノードで起動するprimitiveリソースを考慮したスコア計算

50
前提
 Pacemaker＋DRBDの構成例の設定についてのみ解説
 Master Slaveに関する設定のみ解説
 Pacemaker＋PostgreSQLレプリケーションの設定については
下記URLに詳解有り
 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf
 STONITHは未使用。STONITHについては下記URLに詳解有り。
 http://sourceforge.jp/projects/linux-
ha/docs/Pacemaker_OSC2013Kyoto_20130803/ja/1/Pacemaker_OSC2013Kyoto_20130803.pdf
 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/521492b28866dce52ea21dc3732ca9cf.swf
 STONITHを使用しない・できない場合のスプリットブレイン防止策
についても割愛
 スプリットブレイン防止策としてはVIPCHECKやoutdate-peer.sh(DRBDの場
合のみ)などが使用可能。ただしSTONITHほど信頼性は無い。

51
Pacemaker＋DRBDの構成例
node01 node02
②DRBD
(Slave)
①pingd
①diskd
④Filesystem
⑤VIP
⑥PostgreSQL
②DRBD
(③Master化)
Pacemaker
NW監視
disk監視
Filesystem
VIP
PostgreSQL
①pingd
①diskd
Pacemaker
disk監視
NW監視
 ①pingdとdiskdを起動後、②両系でDRBDを起動し、③node01で
DRBDが昇格に成功したら、④～⑥Masterノード(node01)でprimitive
リソースを起動する。この起動の流れになるようにCRM設定を行う。
grpPgsql grpPgsql
※番号は起動順序

52
Pacemaker+DRBDのCRM設定例（Master Slave関連以外）
primitive prmFilesystem ocf:heartbeat:Filesystem
params fstype="ext4" device="/dev/drbd0" options="barrier=0" directory="/dbfp“
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 prmVip ocf:heartbeat:IPaddr2
params ip="192.168.0.1" nic="eth0" cidr_netmask=“24"
op stop interval="0s" timeout="60s" on-fail="block"
primitive prmPostgreSQL ocf:pacemaker:Dummy
params
pgctl="/usr/pgsql-9.2/bin/pg_ctl" start_opt="-p 5432 -h 192.168.0.1"
psql="/usr/pgsql-9.2/bin/psql“ pgdata="/dbfp/pgdata/data"
pgdba="postgres" pgport="5432" pgdb="template1"
op stop interval="0s" timeout="60s" on-fail=“block“
group grpPgsql prmFilesystem prmVip prmPostgreSQL
primitive prmPingd ocf:pacemaker:pingd
params name="default_ping_set" host_list="192.168.0.254" multiplier="100"
op stop interval="0s" timeout="60s" on-fail="ignore"
primitive prmDiskd ocf:pacemaker:diskd
params name="diskcheck" device="/dev/vda" options="-e" interval="10"
op stop interval="0s" timeout="60s" on-fail="ignore"
clone clnPingd prmPingd
meta clone-max="2" clone-node-max="1"
clone clnDiskd prmDiskd
meta clone-max="2" clone-node-max="1"
Primitiveリソース
・Filesystem
・VIP
・PostgreSQL
cloneリソース
・pingd
・diskd
Primitiveリソース
のグループ化
基本的な内容なので割愛。
groupのみ次のスライドで補足

53
groupについて
 まず3つのprimitiveリソースを定義し、以下を指定
 RAの指定、RAに渡すオプション、各アクションの間隔、アクション失
敗時の動作
 続いてprimitiveリソースをgrpPgsqlという名前でgroup化
 Filesystem→VIP→PostgreSQLの順で起動し、逆順で停止
 3つのリソースは同一ノードで起動
Filesystem
VIP
PostgreSQL
①Filesystem
②VIP
③PostgreSQL
起動時停止時

Pacemaker+DRBDのCRM設定例（Master Slave関連）
primitive prmDrbd ocf:linbit:drbd
params drbd_resource="r0"
op monitor interval="10s" role="Master" timeout="20s" on-fail="restart"
op monitor interval="20s" role="Slave" timeout="20s" on-fail="restart"
op promote interval="0s" timeout="90s" on-fail="restart"
op demote interval="0s" timeout="90s" on-fail="fence"
op stop interval="0s" timeout="100s" on-fail="fence"
ms msDrbd prmDrbd
meta
master-max="1" master-node-max="1" clone-max="2"
clone-node-max="1" notify="true"
location rsc_loc-1 msDrbd
rule $id="loc-3" $role="master" -inf: not_defined default_ping_set
or default_ping_set lt 100
rule $id="loc-4" -inf: not_defined diskcheck or diskcheck eq ERROR
colocation col-1 inf: msDrbd clnPingd
colocation col-2 inf: msDrbd clnDiskd
colocation col-3 inf: grpPgsql msDrbd:Master
order order-1 0: clnPingd msDrbd
order order-2 0: clnDiskd msDrbd
order order-3 0: msDrbd:promote grpPgsql:start
property no-quorum-policy="ignore" stonith-enabled="false"
rsc_defaults $id="rsc-options" resource-stickiness="200" migration-threshold="1"
①MSリソースの
定義。
location設定は
promotionスコア
のところで説明済
②配置・起動
順序制約
54

55
①MSリソースの定義
 DRBDをまずPrimitiveリソースとして定義
primitive prmDrbd ocf:linbit:drbd ← primitiveリソース名を指定
params drbd_resource=“r0” ← DRBD RAに渡すパラメータ
op monitor interval="10s" role="Master" timeout="20s" on-fail="restart"
op monitor interval="20s" role="Slave" timeout="20s" on-fail="restart"
op promote interval="0s" timeout="90s" on-fail="restart"
op demote interval="0s" timeout="90s" on-fail=“block"
op stop interval="0s" timeout="100s" on-fail=“block“
※MasterとSlaveのintervalは別の値を指定
「msDrbd」：MSリソース名。制約関連の設定で使用
「prmDrbd」：DRBDのPrimitiveリソース名を指定
meta 以降の部分(meta要素)：次のスライドで説明
次に、ms要素を設定することで、DRBDをMaster Slaveリソース化
ms msDrbd prmDrbd
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1“ notify=true
※

 ms要素には以下を設定
 master-max
 masterになれるリソース数（デフォルト値は1）
 master-node-max
 1つのノードでMasterになれるリソースの数（デフォルト値は1）
 clone-max
 生成するインスタンス数(デフォルト値はクラスタのノード数)
 2ノード構成なら2を指定
 clone-node-max
 一つのノードで同時に起動するインスタンス数（デフォルト値は1）
 notify
 trueに設定すると、Master/Slaveリソースの各アクションの前後でnotifyアク
ションが実行される。DRBD、PostgreSQLレプリケーションのRAともにnotify
アクションを使用しているためtrueを選択する。
ms要素のmeta要素について
master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify=true
56

57
②配置・起動順序制約
colocation rsc_col-1 inf: msDrbd clnPingd
colocation rsc_col-2 inf: msDrbd clnDiskd
order order-1 0: clnPingd msDrbd
order order-2 0: clnDiskd msDrbd
order order-3 0: msDrbd:promote grpPgsql:start
④Filesystem
⑤VIP
⑥PostgreSQL
DRBD
(③Master化)
grpPgsql
①pingd
①diskd
②DRBD
 pingd, diskdとDRBD間の制約
 colocationによりpingd,diskdが起動しているノードでDRBDを起動
 orderによりpingd,diskdが起動してからDRBDが起動
 DRBDとリソースグループ(grpPgsql)間の制約
 colocationによりDRBDがMasterに昇格するノードでgrpPgsql起動
 orderによりDRBDがMasterに昇格してからgrpPgsql起動
orderとcolocationについては前回のOSC公演
資料で詳解しているのでそちらも参照下さい。
http://linux-ha.sourceforge.jp/wp/wp-content/uploads/OSC2013TokyoFall.pdf

58
colocationについて
 概要：
 リソースAとBを同一ノードまたは異なるノードに配置する設定
 score:
 リソースAとBを同じノードで起動させる場合はinfを指定
 異なるノードで起動させる場合は-infを指定
 役割:
 Started, Master, Slaveから指定(デフォルトStarted)
 例えばcolocation inf: A:Started B:Masterであれば、Master状態のリ
ソースBと同じノードでリソースAを起動するという意味になる。
colocation <任意のID名> <score>: <リソースA>:<役割> <リソースB>:<役割>

orderについて
order <任意のID名> <score>: <リソースA>:<アクション> <リソースB>:<アクション>
[symmetrical=true|false]
 概要：
 リソースAが起動してからリソースBを起動するための設定
 Score：
 典型的な設定例は 0 or INF（デフォルトINF）
 0の場合、リソースAの故障時にリソースBが影響を受けない。
 infの場合、リソースAの故障時にリソースBも影響を受ける。
 アクション
 start, stop, promote, demoteから指定する。
 例えば、A:promote B:startであれば、Aが昇格してからBを起動
 Symmetrical設定
 trueの場合、A:promote B:start設定時に、停止順序はB:stop → A:demote
 falseの場合、起動順序はtrueの場合と同じだが、停止順序は各リソースを平行し
て落とすため早く停止できる。停止順序が重要でない場合はフェイルオーバ時間
の短縮化のため、false設定を推奨
59

60
Pacemakerと組み合わせる場合のDRBD設定例
global {
usage-count no;
}
common {
protocol C;
startup {
wfc-timeout 30;
degr-wfc-timeout 15;
outdated-wfc-timeout 15;
}
syncer {
rate 40M;
verify-alg sha1;
csums-alg sha1;
}
handlers {
pri-on-incon-degr "echo o > /proc/sysrq-trigger; halt -f";
}
net {
max-buffers 8192;
ko-count 3;
unplug-watermark 2048;
cram-hmac-alg sha1;
shared-secret password;
}
disk {
on-io-error detach;
fencing resource-only;
no-disk-barrier;
}
}
resource r0 {
device minor 0;
meta-disk internal;
disk /dev/sda1;
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
on node01 {
address 10.0.1.1:7790;
}
on node02 {
address 10.0.1.2:7790;
}
}
crm-fence-peer.sh使用時は赤字の箇所を設定

61
Pacemaker＋PostgreSQLレプリケーションの構成例
 Pacemaker＋PostgreSQLレプリケーションは下記URL参照
 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf
node01 node02
②PostgreSQL
(Slave)
①pingd
①diskd
Pacemaker
NW
監視
disk監視
①pingd
①diskd
Pacemaker
disk監視
NW
監視
※番号は起動順序
②PostgreSQL
(③Master化)
④vip-master
(外部からの接続用IP)
④vip-rep
(Slaveからの接続用IP)
master-group
vip-rep
vip-master
master-group

62
Pacemaker+DRBD
Pacemaker起動から昇格までの流れ
はデータが新しい状態（UpToDate）を表すこととする。
はデータが無効状態(Outdated)を表すこととする。
新
無効

DRBD RAのデータ状態とMasterスコアの詳細
 DRBD RAは、自ノードのロール(PrimaryかSecondaryか)と
確認したデータ状態に対応したMasterスコアをPacemakerに設定
 対応表
 Noの順に確認して最初に合致した条件のMasterスコアを設定
※DRBD8.3.16のPKGに含まれるRAを使用した場合のデフォルト設定の例(ユーザによる変更も可能)
63
No
ローカルノード対向ノード Master
スコア※ロールデータ状態データ状態
1 Secondary UpToDate DUnknown 1000
2 * UpToDate * 10000
3 * * UpToDate 10
4 * Consistent * 5
5 * * * 削除

DRBDのデータ状態の遷移（停止時）
 起動時のスコアは前回停止時のデータ状態に依存するため、まずは停
止手順とその時のデータ状態から説明。次のスライドからは、本スライ
ドの手順で停止した後に起動した時の動作を説明していく。
 Secondary→Primaryの順に計画停止した場合のデータ状態の遷移
 正常稼動時は両系がUpToDate/UpToDate の状態
 Secondaryは計画停止時に自ノードをOutdatedとして停止
 Primaryも対向がOutdatedとして停止したことを検知
 Primary側を停止（両系は停止しているがデータ状態は保持）
DRBD(Primary)
UpToDate/UpToDate
DRBD(Secondary)
UpToDate/UpToDate
DRBD(Primary)
UpToDate/Outdated
DRBD(停止)
Outdated/DUnknown
新新
新無効
64
DRBD（停止）
Outdated/DUnknown
DRBD(停止)
UpToDate/Outdated
新
64
無効

65
起動時のpromotionスコアの計算例
 node01は新、node02は無効の状態から両系を同時起動した場合
 前スライドの対応表より、node01はUpToDate/UpToDateなので
10000、node02はOutdated/DunknownなのでMasterスコア削除
 locationにはnode01に200、node02に100が設定されているとする
 promotionスコアはnode01が10200、node02が100となる
Pacemaker Pacemaker
DRBD RA
②起動と
データ新旧
の確認
DRBD(⑧Master化)新
④Master
スコア=10000
①start
⑤10200
node01 node02
DRBD RA
DRBD（Slave）
④Master
スコア削除
①start⑥
promote
⑦昇格
③データ
は新しい
②起動と
データ新旧
の確認
③データは無効
(古い可能性有)
⑤100
無効

66
Pacemaker+PostgreSQLレプリケーション
Pacemaker起動から昇格までの流れ
はデータが新しい状態（Master側と同期接続中のSlave側）を表すこととする。
はデータが古い状態(非同期接続中、または切断中のSlave側)を表すこととする。
新
古

pgsql RAのデータ状態とMasterスコアの詳細
 前述の通り、pgsql RAはpostgreSQLに対して確認した接続状態に応じて
Masterスコアを設定するが、この時、データ状態についても設定している
 データ状態は、Pacemaker停止時も保持されることから、次回起動
時に、前回停止直前のデータ状態が分かる仕組みになっている。
役割接続状態データ状態 Master スコア
Master - LATEST 1000
Slave 同期 STREAMING|SYNC 100
Slave 非同期 STREAMING|ASYNC -INFINITY
Slave 切断中 DISCONNECT -INFINITY
新
古
67

典型的なPostgreSQLのデータ状態の例
PostgreSQL（Master)
LATEST
PostgreSQL（Slave)
STREAMING|SYNC
同期接続
PostgreSQL（Master)
LATEST
PostgreSQL（停止)
DISCONNECT切断
LATEST
DISCONNECT
新新
新古
新
 起動時のスコアは前回停止時のデータ状態に依存するため、まずは停
止手順とその時のデータ状態から説明。次のスライドからは、本スライド
の手順で停止した後に起動した時の動作を説明していく。
 Slave→Masterの順に計画停止した場合のデータ状態の遷移
 正常稼動時は以下の状態
 Master側のPacemaker (pgsql RA)がSlaveの切断を検知
 Master側がSlave側のデータ状態をDISCONNECTに更新
 Master側を停止
68
古

69
起動時のpromotionスコアの計算例その１
 node01のデータ状態が新しくnode02が古い状態で同時起動(※)
 locationにはnode01に200、node02に100が設定されているとする
 start時点では両系のMasterスコアを-INFINITYにして昇格抑止
Pacemaker Pacemaker
pgsql RA
PostgreSQL
node01 node02
pgsql RA
①start①start
②起動
③状態確認
④Slaveで
起動
②起動
③状態確認
⑤Masterスコア
= -INFINITY
④Slaveで
起動
⑤Masterスコア
= -INFINITY
PostgreSQL
⑤-INFINITY ⑤-INFINITY
②非同期
接続
※ここでは分かりやすいようにDRBDと手順をそろえて両系同時起動を行っているが、少なくともpgsql9.2以前のバージョンで同時起動
するにはrestart_on_promoteという特殊な設定が必要なため、片系ずつ起動することを推奨。具体的には、最新データを持つノードを片
系起動し、昇格したらデータをもう片系にコピーして、もう片系を起動する手順を推奨。詳細は下記URL参照
http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf

70
起動時のpromotionスコアの計算例その２
 monitor処理で前回停止時に保存したデータ状態を確認
 node01は新しいデータを持つためMasterスコア=1000に更新
 node01のpromotionスコアは1200(1000+200) ←昇格
 node02のpromotionスコアはまだ-INFINITY(-INFINITY+100)
Pacemaker Pacemaker
pgsql RA
PostgreSQL(⑪Master)
pgsql RA
PostgreSQL(Slave)
⑥
monitor
⑦データが
新しいこと
を確認
⑥
monitor
⑧Master
スコア=
1000
⑧1200
-INFINITY
node01 node02
⑦データが
古いことを
確認
⑨
promote
⑩昇格
非同期
若干簡略化しているため、
厳密な動作は異なります。
⑦両ノードとも新しいデータを持つ場合等は
ここでデータ位置の比較等を実施
古新

71
起動時のpromotionスコアの計算例その３
 Master昇格後のmonitor処理でPostgreSQLの接続状態確認
 非同期接続中なのでMaster側がSlave側の状態を以下に更新
 データ状態= STREAMING|ASYNC、Masterスコア= -INFINITY
 その後、同期接続への切替処理を実施
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master)
1200
node01 node02
pgsql RA
PostgreSQL(Slave)
⑫monitor
⑯同期接続に切替
⑮-INFINITY
⑬接続状態
の確認
⑭非同期
で接続中
⑮古新
⑯同期接続
⑮Masterスコア＝-INFINITY
データ状態＝STREAMING|ASYNC

72
起動時のpromotionスコアの計算例その４
 次の周期のmonitor処理で再度、PostgreSQLの接続状態確認
 同期接続に切替ったためMaster側がSlave側の状態を以下に更新
 データ状態= STREAMING|SYNC、Masterスコア= 100
 以降、 monitor毎に接続状態の確認を継続する。
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master)
1200
node01 node02
pgsql RA
PostgreSQL(Slave)
⑰monitor
⑳200
⑱接続状態
の確認
⑲同期接続中
であることを確認
新 ⑳新
同期
⑳Masterスコア=100
データ状態＝STREAMING|SYNC

73
障害事例と復旧時の動作
はデータが新しい状態、はデータが古い状態、は不整合な状態新不整合古
単純化のため、locationは未設定とする

74
Slave故障
 Pacemaker+DRBD
 node01のDRBDはnode02を切り離す
 node02のデータ状態は障害発生時点で古くなる。
 node01のPostgreSQLはnode02を切り離す(非同期に設定変更)
 node02のデータ状態は障害発生時点で古くなる。
DRBD(Master)
node01 node02
Pacemaker
DRBD(Slave)
Pacemaker
10000
PostgreSQL(Master)
node01 node02
Pacemaker
PostgreSQL(Slave)
Pacemaker
1000
新古
新古

Slave復旧(Pacemaker+DRBD)
 Slave復旧時は自動的にクラスタに組み込む(DISK障害時を除く)
 復旧時、世代識別子によりnode01のデータが新しいことを検知して
同期の方向を決定(node01からnode02に対する同期)。
 その後、node02障害中にnode01に書き込まれたデータがDRBD
のビットマップログにより特定され、差分同期される。
 完了すると、node02のスコアは元の状態に戻る。
DRBD(Master)
node01 node02
Pacemaker
DRBD(Slave)
Pacemaker
10000 ②10①差分同期
75
DRBD(Master)
node01 node02
Pacemaker
DRBD(Slave)
Pacemaker
10000 ③10000
新不整合※
新新
※DRBDは差分同期の際に書き込み順序を保証しないこと
から、同期中に同期先ノードにアクセスさせてはならない。

Slave復旧(Pacemaker+PostgreSQL)
 Slave復旧時は自動的にクラスタに組み込む(DISK障害時を除く)(※)
 障害中にMaster側に書き込まれた分のWALログが転送される。
 完了して同期接続に戻ると、node02のpromotionスコアも元に戻る。
PostgreSQL(Master)
node01 node02
Pacemaker
PostgreSQL(Slave)
Pacemaker
1000
-INFINITYWAL転送
新古
PostgreSQL(Master)
node01 node02
Pacemaker
PostgreSQL(Slave)
Pacemaker
1000
100
新新
76
同期接続
※長時間経過すると組み込まれない可能性有り。
その場合はwal-keep-segmentsを大きくする。

Master故障
 Pacemaker+DRBD
 ①node02のDRBD RAはMasterスコアを1000に更新
 ②node02が昇格すると、再度Masterスコアを10000に更新
 ①障害時、node02のpromotionスコアは正の値(=100)なので昇格
 ②昇格時、promotionスコアは1000となる。
node02
DRBD(Slave→②Master)
Pacemaker
node02
PostgreSQL(Slave→①Master)
Pacemaker
node01
DRBD(Master)
Pacemaker
node01
PostgreSQL(Master)
Pacemaker
新古
新
古
10000
→①1000
→③10000
100
→②1000
node02と
不一致※
node02と
不一致※
※Masterに書き込み中に突然落ちた場合、どちらか一方のノードのみに書き
込まれたデータが存在する可能性があるため、後で一致させる必要がある。

78
Master復旧(Pacemaker+DRBD)
 Master復旧時は自動的にクラスタに組み込む(DISK障害時を除く)
 node01の障害中にnode02に書き込まれたデータはDRBDのビット
マップログにより自動的に差分同期され、両系で不一致の可能性が
あるブロックはDRBDのアクティビティログにより自動的に解消
 同期が完了すると、両系のMasterスコアは10000に更新される。
DRBD(Slave)
node01 node02
Pacemaker
DRBD(Master)
Pacemaker
10000
差分同期
不一致解消
10000
DRBD(Slave)
node01 node02
Pacemaker
DRBD(Master)
Pacemaker
1000010
新
新新
古
node02と
不一致

79
Master復旧(Pacemaker+PostgreSQL)
 ①Master復旧前に以下の手順を手動で実施する必要有り
 node02からnode01へのデータコピーによる不整合の解消
 ロックファイル削除
 手動手順の詳細は以下URLを参照
 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf
 ②node01起動後、③同期処理が走る
 ④完了後、Pacemakerにより非同期→同期接続に切り替えを行い、
Masterスコアを100に更新
PostgreSQL(Slave)
node01 node02
Pacemaker
PostgreSQL(Master)
Pacemaker
1000④100
①データコピー
①ロックファイル削除
③WAL転送
②起動

Master側で起動するprimitiveリソース故障(Pacemaker+DRBD)
 下図は概要のみです。
 本故障時のスコア計算の詳細は以下のページを参照して下さい。
 resource-stickinessによりフェイルバックが防止される例
DRBD(Slave→⑤Master)
Filesystem
VIP
PostgreSQL
DRBD(Master→④Slave)
Pacemaker
Filesystem
VIP
PostgreSQL
Pacemaker
grpPgsql grpPgsql
node01 node02
10000→ ③ 1 10000
①故障 ⑥起動
②grpPgsql停止
80

Master側で起動するprimitiveリソース故障(Pacemaker+PostgreSQL)
 DRBDと同様に以下のページを参照して下さい（スコア計算の観点で
はDRBDと同じですので、解説はDRBDのみ行っています。）
 resource-stickinessによりフェイルバックが防止される例
PostgreSQL(Slave→⑤Master)
vip-rep
vip-master
PostgreSQL(Master→④Slave※)
Pacemaker Pacemaker
master-group
node01 node02
1000→ ③ 1 100
①故障 ⑥起動
vip-rep
vip-master
master-group
②master-group停止
※正確にはこの後、node01のPostgreSQLは停止する。理由については以下のページを参照。
「PostgreSQLレプリケーションとPacemakerの状態遷移」
81

82
インターコネクトLAN障害（DRBD）
 DRBDは両系が昇格することを抑止する仕様
 レプリケーションLANが生きているため、DRBDの上記抑止機能に
よりnode02のDRBDのpromoteは失敗して、両系がMasterになる
状態は防がれる。
Pacemaker
DRBD
(Master)
DRBD
（Slave）
Pacemaker
10000 10000
promote NG
node01 node02

83
インターコネクトLAN障害（PostgreSQLレプリケーション）
 PostgreSQLレプリケーションは両系をMasterに昇格可能
 レプリケーションのセッションは切断される
Pacemaker
PostgreSQL
(Master)
PostgreSQL
（Slave→Master）
Pacemaker
1000 100
Promote
node01 node02

インターコネクトLAN障害対策(PostgreSQLレプリケーション)
 STONITHについては説明済みのため割愛
Pacemaker
PostgreSQL
(Master)
PostgreSQL
（Slave）
Pacemaker
HW制御
ボード
HW制御
ボード
電源OFF

サービス提供用ネットワーク故障
 下記設定を前提
 ping疎通NGの場合、rule条件を満たすため、promotionスコアを
-INFINITYに更新し、フェイルオーバする。
 $role=“master” 指定がある場合はpromotionスコアを更新
 $role=“master” 指定が無い場合の例はDisk障害のスライドで説明
rule $id=“loc-3” $role=“master” -inf: not_defined default_ping_set
or default_ping_set lt 100
DRBD
(Master→ ③Slave)
DRBD
(Slave→④Master)pingd
①ping疎通NG
②Promotionスコア更新 10000→
②-INFINITY
10000
85

ディスク故障
DRBD
(Master)diskd
①disk監視NG
②allocation
スコア更新 ③サービス停止
DRBD
(Slave→ ④ Master)
②-INFINITY
 下記設定を前提
 DISK監視NG時にrule条件を満たすため、allocationスコアを-INFINITY
に更新し、フェイルオーバする
 allocationスコア(後述)が-INFINITYになると、DRBDを停止する
rule $id="loc-4" -inf: not_defined diskcheck
or diskcheck eq ERROR
10000
86

87
Masterノードで起動する
primitiveリソースを考慮した
スコア計算
Pacemakerとの組み合わせが前提のため、図にはpacemakerを記載しないこととする。
MSリソースの解説では前述のPacemaker+DRBDのCRM設定時を前提とする。
また、locationにはnode01に200、node02に100が設定されているとする

allocationスコアについて
 primitiveリソースは、各ノードに対するallocationスコアを持つ
 allocationスコアが最も高いノードでprimitiveリソースを起動する
 リソース起動前のallocationスコア=location設定値
 location設定例
 上記location設定時の動作イメージ
node02node01
location loc-1 リソース名
rule 200: #uname eq node01
100200
primitive primitive
88
allocationスコアは
上記の記号で表す。
数値
起動停止

primitiveリソースにおけるresource-stickinessについて
 リソース起動後のallocationスコア=
location設定値＋resource-stickiness
 locationで設定した値はprimitiveリソース起動前に加算
 resource-stickinessはprimitiveリソース起動時に加算
primitive
node02node01location loc-1 primitiveリソース名
rule 100: #uname eq node02 100200
node01で起動
primitive
rsc_defaults $id="rsc-options"
resource-stickiness=“200"
89
node02node01
primitive
400 89
primitive
primitive
100

resource-stickinessの目的はフェイルバック防止
 primitive故障時はallocationスコアが-INFINITYに更新
 allocationスコアがマイナスのノードではリソースは起動しない
 フェイルオーバしてnode02でprimitive起動（resource-stickiness加算）
 node01の故障回復および故障フラグのクリア
 node02のallocationスコアが大きいためフェイルバックしない
node02node01
100-INFINITY
primitive
100(location)
+
200(resource-stickiness)
故障
node02node01
300
primitive故障
primitive
-INFINITY
node02node01
300
primitive primitive
200 90
primitive

MSリソース(resource-stickiness=200設定時)の場合の例
 通常時はnode01を優先するためにlocation設定を行っているとする
 node01の故障によりフェイルオーバしてnode02のDRBDが昇格
 node01の故障回復および故障フラグのクリア(元のスコア値に戻る)
 node01のpromotionスコアが大きいためフェイルバック
 MSリソースのみの場合、resource-stickinessの効果は無い
node02node01 10200
91
DRBD(Master) DRBD(Slave)
10100
node02node01 10200
DRBD DRBD(Slave→Master)
10100-INFINITY
故障
node02node01 10200
DRBD(Slave→Master) DRBD(Master→Slave)
10100

MSリソースのスコアにresource-stickinessが加算される場合①
 MSリソースとcolocationを設定しているprimitiveリソースがある場合
 promotionスコア＝locationで指定した値＋Masterスコア
＋colocation制約を設定しているprimitiveリソースのallocationスコア
 下記の設定がある場合、grpPgsqlが起動すると、grpPgsqlのallocationスコアを
msDrbdのpromotionスコアに加算
 grpPgsqlのallocationスコア=location設定値＋resource-stickiness
 通常、primitiveをMSリソースと組み合わせる場合にはprimitiveのlocationは設
定しないため、grpPgsqlのallocationスコア=resource-stickinessと考えてよい。
grpPgsql
msDrbd(Master) promotionスコア
allocationスコア
colocation
加算
92

93
MSリソースのスコアにresource-stickinessが加算される場合②
 grpPgsqlが起動すると、resource-stickinessがgrpPgsqlのallocationス
コアに加算され、DRBDのpromotionスコアにも加算される
 grpPgsqlが3つのリソースの場合の加算例（前述の設定のケース）
 resource-stickiness(ここでは200を設定) * 3 = 600
 加算時に「:Master」のあるcolocationの行数+1をかける（1行なら2）
Filesystem
VIP
PostgreSQL
grpPgsql
200
200
200
③ 200×3×2 =1200
を加算
DRBD
(Master)
10200 11400
DRBD（Master） DRBD(Slave)
grpPgsqlスコア加算 grpPgsql

resource-stickinessによりフェイルバックが防止される例
 Primitiveリソース障害時、MSリソースのpromotionスコアは1に下がる
 フェイルオーバしてnode02のPromotionスコアが11300になる
 node01の復旧および故障フラグのクリア後もフェイルバックしない
grpPgsql
DRBD
(Master→④Slave
DRBD
(Slave→⑤Master)11400
→③ 1
①-INFINITY①故障
10100→
⑨11300
⑥grpPgsql起動
⑦1200
⑧加算
node01 node02
②加算
DRBD(Slave) DRBD(Master)②10200
①故障フラグクリア
grpPgsql
node01 node02
11300
-INFINITY
grpPgsql
94

95
resource-stickiness設定指針（DRBDの場合）
 DRBD RAが設定するMasterスコアの変動によりフェイルオーバさせる
にはresource-stickinessに小さい値を設定（推奨値は200）
 resource-stickinessを小さい値にすることで、Master側DRBDが検
知するデータ状態の悪化によりRAがMasterスコアを下げた時、
promotionスコアがSlave側のMasterスコアを下回り、フェイルオー
バを発生させることが可能となる。
 以下は前述のresource-stickiness値=200、3リソース構成の例
(1200が加算)
resource-stickiness=200の場合
正常時 DRBD異常検知時
Master Slave Master Slave
location 200 100 200 100
DRBD RAが設定するMasterスコア 10000 10000 10 10000
resource-stickiness 1200 0 1200 0
Promotionスコア 11400 10100 1410 10100

resource-stickinessが有効な事例
 DRBDはDisk障害を検知するとDiskless状態（※）になり、対向のDRBD
に書き込むことで処理を継続しようとする（下図の例）
 このような状態の時はフェイルオーバさせた方が望ましい
 PacemakerはDisklessを検出してMasterスコアを10000から10に変更
 この時、resource-stickinessが小さければ、node01のpromotionス
コアがnode02を下回り、フェイルオーバする
 resource-stickinessが大きな値の場合、DRBDのMasterスコアが
下がってもフェイルオーバしない可能性があるため要注意
DRBD(Master)
node01 node02
Pacemaker
DRBD(Slave)
Pacemaker
Diskless/UpToDate
Masterスコアを
10000→10に減らすgrpPgsql1200
11400
→1410
10100
この後、1410<10100でnode02にフェイルオーバ
※DRBDにon-io-error detachの設定がある場合の動作。
96

97
resource-stickiness設定指針（PostgreSQLの場合）
 Master側は故障でない限り常に1000、Slave側は100～-INFINITY
 Master側のMasterスコアは常に1000であり、Slave側はそれ以下
の値に制御される。
 Pgsql RAは、DRBD RAのようにMaster側のMasterスコアを下
げることはしない
 よって、PostgreSQLレプリケーション構成の場合はresource-
stickinessをチューニングしても特に意味は無い
resource-stickiness=INFINITYの場合 Master Slave
location 200 100
pgsql RAが設定するMasterスコア値 1000 100
resource-stickiness INFINITY 0
promotionスコア INFINITY 200

99
古いデータを持つ
昇格抑止中のノードを
強制的に昇格する方法

レプリケーションLAN切断後のMaster障害からの復旧方法
 レプリケーションLAN切断後、Master障害が発生した場合、Slave側は
昇格抑止状態になる (DRBDの場合はfence-peer設定時)ため、サー
ビスが停止する。
 Master側がディスク故障等により新しいデータで復旧させることができ
ない場合、Slave側は古いデータであるが、昇格させる必要がある。こ
の時は次のスライドの手順で昇格させる。
MS
(Master)
PacemakerPacemaker
MS
（Slave）
-INFINITY
100
故障昇格抑止中

Slave側での制約解除コマンドについて(DRBD)
[root@node02 ~]# grep "drbd-fence-by-handler" /var/lib/heartbeat/crm/cib.xml
<rsc_location rsc="msDrbd" id="drbd-fence-by-handler-r0-msDrbd">
 以下のコマンドで赤字部分を確認
 location制約の削除
 上で確認した赤字部分を以下の赤字部分に入れて、コマンド実行
prmDrbd:0 promotion score on none: 0
prmDrbd:1 promotion score on node02: -1000000 ★この時点で昇格抑止状態
[root@node02 ~]# cibadmin -D -X '<rsc_location rsc="msDrbd" id="drbd-fence-by-
handler-r0-msDrbd">‘
prmDrbd:1 promotion score on node02: 1100 ★制約が解除されたのでこの後、昇格
prmDrbd:0 promotion score on none: 0
101

Slave側での制約解除コマンドについて(PostgreSQL)
 属性値の修正
 pgsql-data-statusをDISCONNECTからLATESTに変更
 PacemakerがSlaveのデータ状態を確認後、昇格する
pgsql:1 promotion score on none: 0
pgsql:0 promotion score on node02: -1000000 ★この時点で昇格抑止状態
[root@node02 ~]# crm_attribute -l forever -N ノード名 -n "pgsql-data-status" -v
"LATEST"
★ノード名はSlaveのホスト名に応じて変更する
102

104
DRBDとPacemakerの状態遷移
STOP Secondary
Start
Stop
Primary
drbdadm primary r0
drbdadm secondary r0
STOP Slave
Start
Stop
Master
promote
demote
 PacemakerはSlaveを経由してMasterになる。
 Master状態から停止する時は、Slaveを経由する。
 DRBDも同じ仕様であり、両者の状態遷移は一致。

105
PostgreSQLレプリケーションとPacemakerの状態遷移
start promote
stop demote
Slave MasterSTOP
×
停止（Slaveへの降格はできない）
recovery.conf なしで起動
停止
pg_ctl promote
recovery.conf ありで起動
 PostgreSQLはMaster起動するのに直接・Slave経由の両方可能
 Pacemaker制御時はSlaveを経由して起動
 Masterからの停止時、 PostgreSQLはSlaveに降格できない
 demote処理で停止する仕様
STOP Slave Master

PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Conference 2014

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Conference 2014

Ähnlich wie PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Conference 2014 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Conference 2014