pacemakerのmaster/slave構成の基本と事例紹介(drbd、postgresqlレプリケーション)...
DESCRIPTION
http://linux-ha.sourceforge.jp/wp/archives/3930TRANSCRIPT
Linux-HA Japan Project 1
2014年 3月1日 OSC2014 Tokyo
Linux-HA Japan
渡辺達也 <[email protected]>
PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション)
2
本日の流れ
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
3
Pacemakerとは
サーバ#1 サーバ#2
サービスの監視・制御
サーバ・アプリケーションの故障監視
サーバ間の監視・制御
4サーバ#1 サーバ#2
STONITH(強制電源断)
Pacemakerとは
サーバ・アプリケーションの故障監視
故障検知時、自動的にフェイルオーバ
ダウンタイムの最小化
フェイルオーバ
5
PostgreSQLRA
共有ディスクRA
リソースエージェント
Pacemakerが起動/停止/監視を制御する対象をリソースと呼ぶ
例)Apache, PostgreSQL, ファイルシステム, 仮想IPアドレス etc...
リソースの制御はリソースエージェント(RA)を介して行う
RAが各リソースの操作方法の違いをラップし、Pacemakerで制御できるようにしている
リソース
制御
制御 制御
ApacheRA
Pacemakerのアーキテクチャ
6
Pacemakerで監視できること
サーバ#1 サーバ#2
仮想IP
自己監視ノード監視
ディスク監視・制御
ネットワーク監視・制御
・プロセス監視・watchdog ・ファイルシステム監視
・共有ディスク排他制御
・ハートビート通信・STONITH(強制電源断)
・ping疎通確認・仮想IP制御・起動
・停止・稼働監視
アプリケーション監視・制御
7
各アプリケーションの概要 pacemaker
DRBD、 PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
8
共有ディスクを使用した構成について
メリット
データが一箇所のため運用しやすい
デメリット
複数ノードが同時にアクセスできないように制御が必要
共有ディスクが高額
共有ディスクがSPOFになる
共有ディスク
DB、ファイルサーバ等
DB、ファイルサーバ等(未稼働)
稼動系(Active) 待機系(Standby)
DRBD、PostgreSQLレプリケーションを使用した構成
メリット
安価なローカルディスクを使用してデータを2重化できる
ディスクがSPOFにならない
デメリット
レプリケーションが性能に影響を与える
複数ノードに分散したデータを同一に保つ必要があり運用が複雑
DRBD or PostgreSQL
DRBD or PostgreSQL
ローカルディスク ローカルディスク
レプリケーション
データレプリケーションLAN
Master Slave
9
10
Linuxカーネルのブロックデバイスドライバのレイヤで動作
様々なデータが複製可能(PostgreSQL, MySQL, Oracle, LDAP ・・・)
Primary、Secondaryの2台構成が基本。
Primaryノードは読み書き可能。Secondaryノードは不可。
3種類の同期モード プロトコルA(非同期)、B(メモリ同期)、C(同期)
DRBD概要
DRBD(Primary) DRBD(Secondary)
Filesystem
①書き込み
②ブロック送信
②書き込み ③書き込み④完了
⑤完了
プロトコルC 設定時の動作例
11
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と組み合わせることで可用性を高めることが可能
12
DRBD or PostgreSQL
DRBD or PostgreSQL
インターコネクトLAN
ローカルディスク ローカルディスク
データレプリケーションLAN
Master→Slave Slave→Master
フェイルオーバ障害検知
13
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
Primitive
Clone Clone
Master Slave
全てのリソース定義の基礎。どこか一つのノードで動作させ、故障時にフェイルオーバさせたいリソースに使用。(例) PostgreSQL, Filesystem, IPアドレス
複数のノードで動作させたいリソースに使用。(例) NW監視, ディスク監視,apache
複数のノードで動作させる点はcloneと同じだが、Master Slaveという主従関係のあるリソースに使用。
(例) DRBD 、PostgreSQL、MySQL
Clone
Primitive
Master Slave(以降、MS)
Primitive
リソースの種類
14
15
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
16
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
17
MSリソース(Pacemaker+ PostgreSQLレプリケーション)
start/stop/monitor
promote/demote
PostgreSQL
(Slave)
pgsql RApgsql RA
Pacemaker Pacemaker
PostgreSQL
制御用コマンド
DRBDとロジックは同じため説明は割愛
PostgreSQL
(Master)
レプリケーション
readread/writeMS MS
node01 node02
18
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
promotionスコアについて①
MSリソースは各ノードに対するpromotionスコアを持つ
promotionスコアが最も高いノードでMSリソースをMasterに昇格
MSリソースは両系をSlaveとして起動
その後、promotionスコアが高いノードで昇格
MS(Master)
node01 昇格 node02
MS(Slave)
promotionスコアは上記の記号で表す。
数値
MS(Slave)
node01 node02
MS(Slave)
起動 起動200 100
19
200 100
20
promotionスコアについて②
promotionスコアはフェイルオーバの判断にも使用される
promotionスコアの大小が入れ替わったらフェイルオーバ
promotionスコアがマイナスならSlaveに留まる
片系起動時はそのノードが昇格するはずだが昇格抑止されている
-INFINITYは-1,000,000を意味するスコアの最小値
MS
Master→SlaveMS
Slave→Master
200→100
MS
Slave
MS
停止中
100→200node01 node02
node01 node02-INFINITY
21
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が加算される場合」
22
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
Pacemaker+DRBDのMasterスコア設定までの流れ
データ状態(ローカル/対向) Masterスコア
UpToDate/UpToDate10000
次のスライドで説明
UpToDate/DUnknown
10000(Masterの場合)1000(Slaveの場合)障害事例で詳しく説明
PacemakerはMasterスコアに基づいてDRBDをMaster化するノードを決定
DRBDは自ノードと対向ノードのデータの状態を管理
DRBD RA
DRBD
pacemaker
②状態確認
③データ状態取得
④Master
スコアの設定
DRBD RAは、DRBDの管理するデータ状態に基づいてMasterスコアを設定。以下は一例(※)
23
①監視
※詳細は参考資料の下記ページも参照して下さい「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
25
Pacemaker1.1系ではptestではなくcrm_simulateを使用
26
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
役割 接続状態 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
pacemaker27
②状態確認
③接続状態取得
④Master
スコアの設定
①監視
※詳細は参考資料の下記ページも参照して下さい。「pgsql RAのデータ状態とMasterスコアの詳細」
Masterスコア設定例
両系の起動が完了して正常に同期された状態(※)
locationにはnode01に200、node02に100が設定されているとする
MasterノードのRAが両ノードのMasterスコアを設定
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master)
同期接続中
pgsql RA
PostgreSQL(Slave)
①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
[root@node01 ~]# ptest -sL | grep promotion
pgsql:0 promotion score on node01: 1200
pgsql:1 promotion score on node02: 20029Pacemaker1.1系ではptestではなくcrm_simulateを使用
30
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
レプリケーション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
32
レプリケーション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
PostgreSQL(Slave)
①monitor
②接続の状態確認
③接続状態取得
④Masterスコア=1000
④Masterスコア=100→ -INFINITY
1200
200 →
④ -INFINITY
切断node01 node02
34
各アプリケーションの概要 pacemaker
DRBD、PostgreSQLレプリケーション
Master Slave リソースと従来のリソースとの違い
Masterに昇格するノードの選定方法 promotionスコア
Pacemaker + DRBDのMasterスコア
Pacemaker + PostgreSQLレプリケーションのMasterスコア
障害事例レプリケーションLAN障害
レプリケーションLAN+インターコネクトLAN障害
インターコネクトLANとレプリケーションLAN障害(DRBD)
インターコネクトLANも切断されていることから、 DRBDから実行されたcrm-fence-peer.shはnode02を昇格抑止状態にすることができない
node02のPacemakerはサービス継続するためpromote実行
node02は昇格し、両系がMasterの状態になってしまう。
35Pacemaker 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状態は防がれる 36
インターコネクトLANとレプリケーションLAN障害(PostgreSQL)
インターコネクトLANが切断されていることから、 Master側RAはnode02のMasterスコアを-INFINITYに更新することができない
Pacemakerはスプリットブレイン状態のためnode02でpromote実行
node02は昇格し、両系がMasterの状態になってしまう。
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master) 切断中
pgsql RA
PostgreSQL
( Slave→⑦Master )
①monitor
②接続の状態確認
③接続状態取得
④Masterスコア=1000
④Masterスコア設定不可
1200 200
⑤Promote
⑥昇格コマンド
node01 node02
インターコネクトLANとレプリケーションLAN障害(PostgreSQL) 対策
両系でMasterになることを防ぐため、STONITHの利用を推奨
STONITHについては説明済みのため割愛
Pacemaker
PostgreSQL
(Master)
PostgreSQL
(Slave)
Pacemaker
HW制御ボード
HW制御ボード
電源OFF
両系Master状態は防がれる 38
まとめ
MSリソースの特徴
各ノードで起動し、Master Slaveという2つの状態を持つ
昇格(promote)、降格(demote)という2つのアクションを実行
promotionスコア、Masterスコア
MSリソースはpromotionスコアの大きいノードをMasterに昇格する
MSリソースのRAがデータ状態に基づきMasterスコアを更新することで、データ状態の良いノードを優先的にMasterに昇格する
障害事例と対応策
レプリケーションLAN障害
fence-peerスクリプトを使用(DRBDの場合)
レプリケーションLAN+インターコネクトLAN障害
STONITHを使用 39
デモについて
LINUX-HA-JAPANのブースにDRBDとPostgreSQLレプリケーション構成のデモ環境を用意しています。
pm01
サービス用LAN
データレプリケーション
DRBD
PostgreSQL 9.2
DRBD
Apache
pm02
PostgreSQL 9.2
仮想IP
40
Linux-HA Japan Project
Linux-HA Japanについて
41
42
Linux-HA Japan URL
http://linux-ha.sourceforge.jp/
Pacemaker関連の最新情報を日本語で発信
Pacemakerのダウンロードもこちらからどうぞ。(インストールが楽なリポジトリパッケージを公開しています。)
http://sourceforge.jp/projects/linux-ha/
Linux-HA Japan Project
Linux-HA Japanメーリングリスト
• ML登録用URLhttp://linux-ha.sourceforge.jp/の「メーリングリスト」をクリック
• MLアドレス[email protected]
日本におけるHAクラスタについての活発な意見交換の場として「Linux-HA Japan日本語メーリングリスト」 も開設しています。
Linux-HA-Japan MLでは、Pacemaker、Heartbeat3、CorosyncDRBDなど、HAクラスタに関連する話題は歓迎!
※スパム防止のために、登録者以外の投稿は許可制です 43
参考文献
Linux-HA Japan Project
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 44
45Linux-HA Japan Project
ご清聴ありがとうございました。
Linux-HA Japan 検索
http://linux-ha.sourceforge.jp/
46
参考資料
47
参考資料の目次
基本編
構成例とCRM設定例
中級編
Pacemaker起動から昇格までの流れ
Pacemaker+DRBD
Pacemaker+PostgreSQLレプリケーション
障害事例と復旧時の動作
Slave故障・復旧
Master故障・復旧
Master側で起動するprimitiveリソース故障
インターコネクトLAN故障
ネットワーク故障
Disk故障
上級編
Masterノードで起動するprimitiveリソースを考慮したスコア計算
48
構成例とCRM設定例
49
前提
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ほど信頼性は無い。
50
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
※番号は起動順序
51
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 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="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 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=“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 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="ignore"
primitive prmDiskd ocf:pacemaker:diskd ¥
params name="diskcheck" device="/dev/vda" options="-e" interval="10" ¥
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="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のみ次のスライドで補足
52
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 start interval="0s" timeout="240s" on-fail="restart" ¥
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-1" $role="master" 200: #uname eq node01 ¥
rule $id="loc-2" $role="master" 100: #uname eq node02 ¥
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スコアのところで説明済
②配置・起動順序制約
53
54
①MSリソースの定義
DRBDをまずPrimitiveリソースとして定義
primitive prmDrbd ocf:linbit:drbd ¥ ← primitiveリソース名を指定params drbd_resource=“r0” ¥ ← DRBD RAに渡すパラメータop start interval="0s" timeout="240s" on-fail="restart" ¥
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
55
56
②配置・起動順序制約
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
colocation col-3 inf: grpPgsql msDrbd:Master
order order-3 0: msDrbd:promote grpPgsql:start
④Filesystem
⑤VIP
⑥PostgreSQLDRBD
(③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
57
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設定を推奨
58
59
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使用時は赤字の箇所を設定
60
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
61
Pacemaker+DRBD
Pacemaker起動から昇格までの流れ
はデータが新しい状態(UpToDate)を表すこととする。
はデータが無効状態(Outdated)を表すこととする。
新
無効
DRBD RAのデータ状態とMasterスコアの詳細
DRBD RAは、自ノードのロール(PrimaryかSecondaryか)と確認したデータ状態に対応したMasterスコアをPacemakerに設定
対応表
Noの順に確認して最初に合致した条件のMasterスコアを設定
※DRBD8.3.16のPKGに含まれるRAを使用した場合のデフォルト設定の例(ユーザによる変更も可能)
62
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
新 新
新 無効
63
DRBD(停止)Outdated/DUnknown
DRBD(停止)
UpToDate/Outdated
新
63
無効
64
起動時の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
無効
65
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
新
古
66
典型的なPostgreSQLのデータ状態の例
PostgreSQL(Master)
LATEST
PostgreSQL(Slave)
STREAMING|SYNC
同期接続
PostgreSQL(Master)
LATEST
PostgreSQL(停止)
DISCONNECT切断
PostgreSQL(停止)
LATEST
PostgreSQL(停止)
DISCONNECT
新 新
新 古
新
起動時のスコアは前回停止時のデータ状態に依存するため、まずは停止手順とその時のデータ状態から説明。次のスライドからは、本スライドの手順で停止した後に起動した時の動作を説明していく。
Slave→Masterの順に計画停止した場合のデータ状態の遷移
正常稼動時は以下の状態
Master側のPacemaker (pgsql RA)がSlaveの切断を検知
Master側がSlave側のデータ状態をDISCONNECTに更新
Master側を停止
67
古
68
起動時のpromotionスコアの計算例 その1
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
69
起動時のpromotionスコアの計算例 その2
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
⑩昇格
非同期
若干簡略化しているため、
厳密な動作は異なります。
⑦両ノードとも新しいデータを持つ場合等はここでデータ位置の比較等を実施
古新
70
起動時のpromotionスコアの計算例 その3
Master昇格後のmonitor処理でPostgreSQLの接続状態確認
非同期接続中なのでMaster側がSlave側の状態を以下に更新
データ状態= STREAMING|ASYNC、Masterスコア= -INFINITY
その後、同期接続への切替処理を実施
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master)
1200node01 node02
pgsql RA
PostgreSQL(Slave)
⑫monitor
⑯同期接続に切替
⑮-INFINITY
⑬接続状態の確認
⑭非同期で接続中
⑮古新
⑯同期接続
⑮Masterスコア=-INFINITY
データ状態=STREAMING|ASYNC
71
起動時のpromotionスコアの計算例 その4
次の周期のmonitor処理で再度、PostgreSQLの接続状態確認
同期接続に切替ったためMaster側がSlave側の状態を以下に更新
データ状態= STREAMING|SYNC、Masterスコア= 100
以降、 monitor毎に接続状態の確認を継続する。
Pacemaker Pacemaker
pgsql RA
PostgreSQL(Master)
1200node01 node02
pgsql RA
PostgreSQL(Slave)
⑰monitor
⑳200
⑱接続状態の確認
⑲同期接続中であることを確認
新 ⑳新
同期
⑳Masterスコア=100
データ状態=STREAMING|SYNC
72
障害事例と復旧時の動作
はデータが新しい状態、 はデータが古い状態、 は不整合な状態新 不整合古
単純化のため、locationは未設定とする
73
Slave故障
Pacemaker+DRBD
node01のDRBDはnode02を切り離す
node02のデータ状態は障害発生時点で古くなる。
Pacemaker+PostgreSQLレプリケーション
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①差分同期
74
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
1000100
新 新
75
同期接続
※長時間経過すると組み込まれない可能性有り。その場合はwal-keep-segmentsを大きくする。
Master故障
Pacemaker+DRBD
①node02のDRBD RAはMasterスコアを1000に更新
②node02が昇格すると、再度Masterスコアを10000に更新
Pacemaker+PostgreSQLレプリケーション
①障害時、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
→②1000node02と不一致※
node02と不一致※
※Masterに書き込み中に突然落ちた場合、どちらか一方のノードのみに書き込まれたデータが存在する可能性があるため、後で一致させる必要がある。
77
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と不一致
78
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停止
79
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の状態遷移」
80
81
インターコネクトLAN障害(DRBD)
Pacemakerはスプリットブレイン状態のためnode02でpromote実行
DRBDは両系が昇格することを抑止する仕様
レプリケーションLANが生きているため、DRBDの上記抑止機能によりnode02のDRBDのpromoteは失敗して、両系がMasterになる状態は防がれる。
Pacemaker
DRBD
(Master)
DRBD
(Slave)
Pacemaker
10000 10000
promote NG
node01 node02
82
インターコネクトLAN障害(PostgreSQLレプリケーション)
Pacemakerはスプリットブレイン状態のためnode02でpromote実行
PostgreSQLレプリケーションは両系をMasterに昇格可能
レプリケーションのセッションは切断される
node02は昇格し、両系がMasterの状態になってしまう。
Pacemaker
PostgreSQL
(Master)
PostgreSQL
(Slave→Master)
Pacemaker
1000 100
Promote
node01 node02
インターコネクトLAN障害 対策(PostgreSQLレプリケーション)
両系でMasterになることを防ぐため、STONITHの利用を推奨
STONITHについては説明済みのため割愛
Pacemaker
PostgreSQL
(Master)
PostgreSQL
(Slave)
Pacemaker
HW制御ボード
HW制御ボード
電源OFF
両系Master状態は防がれる 83
サービス提供用ネットワーク故障
下記設定を前提
ping疎通NGの場合、rule条件を満たすため、promotionスコアを-INFINITYに更新し、フェイルオーバする。
$role=“master”指定がある場合はpromotionスコアを更新
$role=“master”指定が無い場合の例はDisk障害のスライドで説明
location rsc_loc-1 msDrbd ¥
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
84
ディスク故障
DRBD
(Master)diskd
①disk監視NG
②allocation
スコア更新 ③サービス停止DRBD
(Slave→ ④ Master)
②-INFINITY
下記設定を前提
DISK監視NG時にrule条件を満たすため、allocationスコアを-INFINITY
に更新し、フェイルオーバする
allocationスコア(後述)が-INFINITYになると、DRBDを停止する
location rsc_loc-1 msDrbd ¥
rule $id="loc-4" -inf: not_defined diskcheck
or diskcheck eq ERROR
10000
85
86
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 ¥
rule 100: #uname eq node02
100200
primitive primitive
87
allocationスコアは上記の記号で表す。
数値起動 停止
primitiveリソースにおけるresource-stickinessについて
リソース起動後のallocationスコア=
location設定値+resource-stickiness
locationで設定した値はprimitiveリソース起動前に加算
resource-stickinessはprimitiveリソース起動時に加算
primitive
node02node01location loc-1 primitiveリソース名 ¥
rule 200: #uname eq node01 ¥
rule 100: #uname eq node02 100200
node01で起動
primitive
rsc_defaults $id="rsc-options" ¥
resource-stickiness=“200"88
node02node01
primitive400 88
primitive
primitive100
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 89
primitive
MSリソース(resource-stickiness=200設定時)の場合の例
通常時はnode01を優先するためにlocation設定を行っているとする
node01の故障によりフェイルオーバしてnode02のDRBDが昇格
node01の故障回復および故障フラグのクリア(元のスコア値に戻る)
node01のpromotionスコアが大きいためフェイルバック
MSリソースのみの場合、resource-stickinessの効果は無い
node02node01 10200
90
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
colocation col-3 inf: grpPgsql msDrbd:Master
加算
91
92
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
colocation col-3 inf: grpPgsql msDrbd:Master
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
93
94
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の設定がある場合の動作。
95
96
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
97
補足資料
98
古いデータを持つ昇格抑止中のノードを強制的に昇格する方法
レプリケーションLAN切断後のMaster障害からの復旧方法
レプリケーションLAN切断後、Master障害が発生した場合、Slave側は昇格抑止状態になる (DRBDの場合はfence-peer設定時)ため、サービスが停止する。
Master側がディスク故障等により新しいデータで復旧させることができない場合、Slave側は古いデータであるが、昇格させる必要がある。この時は次のスライドの手順で昇格させる。
MS
(Master)
PacemakerPacemaker
MS
(Slave)-INFINITY
99
故障 昇格抑止中
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制約の削除
上で確認した赤字部分を以下の赤字部分に入れて、コマンド実行
[root@node02 ~]# ptest -sL | grep promotion
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">‘
[root@node02 ~]# ptest -sL | grep promotion
prmDrbd:1 promotion score on node02: 1100 ★制約が解除されたのでこの後、昇格prmDrbd:0 promotion score on none: 0
100
Slave側での制約解除コマンドについて(PostgreSQL)
属性値の修正
pgsql-data-statusをDISCONNECTからLATESTに変更
PacemakerがSlaveのデータ状態を確認後、昇格する
[root@node02 ~]# ptest -sL | grep promotion
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のホスト名に応じて変更する
101
102
状態遷移について
103
DRBDとPacemakerの状態遷移
STOP Secondary
Start
StopPrimary
drbdadm primary r0
drbdadm secondary r0
STOP Slave
Start
Stop
Master
promote
demote
PacemakerはSlaveを経由してMasterになる。
Master状態から停止する時は、Slaveを経由する。
DRBDも同じ仕様であり、両者の状態遷移は一致。
104
PostgreSQLレプリケーションとPacemakerの状態遷移
start promote
stop demote
Slave MasterSTOP
×停止(Slaveへの降格はできない)
recovery.conf なしで起動
停止
pg_ctl promoterecovery.conf ありで起動
PostgreSQLはMaster起動するのに直接・Slave経由の両方可能
Pacemaker制御時はSlaveを経由して起動
Masterからの停止時、 PostgreSQLはSlaveに降格できない
demote処理で停止する仕様
STOP Slave Master