pacemakerのmaster/slave構成の基本と事例紹介(drbd、postgresqlレプリケーション)...

Linux-HA Japan Project 1

2014年 3月1日 OSC2014 Tokyo

Linux-HA Japan

渡辺達也 <tatsuya.w@gmail.com>

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

本日の流れ

各アプリケーションの概要 pacemaker

DRBD、PostgreSQLレプリケーション

Master Slave リソースと従来のリソースとの違い

Masterに昇格するノードの選定方法 promotionスコア

Pacemaker + DRBDのMasterスコア

Pacemaker + PostgreSQLレプリケーションのMasterスコア

障害事例レプリケーションLAN障害

レプリケーションLAN＋インターコネクトLAN障害

Pacemakerとは

サーバ#1 サーバ#2

サービスの監視・制御

サーバ・アプリケーションの故障監視

サーバ間の監視・制御

4サーバ#1 サーバ#2

STONITH(強制電源断)

Pacemakerとは

サーバ・アプリケーションの故障監視

故障検知時、自動的にフェイルオーバ

ダウンタイムの最小化

フェイルオーバ

PostgreSQLRA

共有ディスクRA

リソースエージェント

Pacemakerが起動/停止/監視を制御する対象をリソースと呼ぶ

例)Apache, PostgreSQL, ファイルシステム, 仮想IPアドレス etc...

リソースの制御はリソースエージェント(RA)を介して行う

RAが各リソースの操作方法の違いをラップし、Pacemakerで制御できるようにしている

リソース

制御

制御制御

ApacheRA

Pacemakerのアーキテクチャ

Pacemakerで監視できること

サーバ#1 サーバ#2

仮想IP

自己監視ノード監視

ディスク監視・制御

ネットワーク監視・制御

・プロセス監視・watchdog ・ファイルシステム監視

・共有ディスク排他制御

・ハートビート通信・STONITH(強制電源断)

・ping疎通確認・仮想IP制御・起動

・停止・稼働監視

アプリケーション監視・制御

DRBD、 PostgreSQLレプリケーション

共有ディスクを使用した構成について

メリット

データが一箇所のため運用しやすい

デメリット

複数ノードが同時にアクセスできないように制御が必要

共有ディスクが高額

共有ディスクがSPOFになる

共有ディスク

DB、ファイルサーバ等

DB、ファイルサーバ等(未稼働)

稼動系（Active）待機系（Standby）

DRBD、PostgreSQLレプリケーションを使用した構成

メリット

安価なローカルディスクを使用してデータを2重化できる

ディスクがSPOFにならない

デメリット

レプリケーションが性能に影響を与える

複数ノードに分散したデータを同一に保つ必要があり運用が複雑

DRBD or PostgreSQL

ローカルディスクローカルディスク

レプリケーション

データレプリケーションLAN

Master Slave

Linuxカーネルのブロックデバイスドライバのレイヤで動作

様々なデータが複製可能(PostgreSQL, MySQL, Oracle, LDAP ・・・)

Primary、Secondaryの2台構成が基本。

Primaryノードは読み書き可能。Secondaryノードは不可。

3種類の同期モードプロトコルA(非同期)、B(メモリ同期)、C(同期)

DRBD概要

DRBD(Primary) DRBD(Secondary)

Filesystem

①書き込み

②ブロック送信

②書き込み ③書き込み④完了

⑤完了

プロトコルC 設定時の動作例

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と組み合わせることで可用性を高めることが可能

DRBD or PostgreSQL

インターコネクトLAN

ローカルディスクローカルディスク

データレプリケーションLAN

Master→Slave Slave→Master

フェイルオーバ障害検知

Primitive

Clone Clone

Master Slave

全てのリソース定義の基礎。どこか一つのノードで動作させ、故障時にフェイルオーバさせたいリソースに使用。(例) PostgreSQL, Filesystem, IPアドレス

複数のノードで動作させたいリソースに使用。(例) NW監視, ディスク監視，apache

複数のノードで動作させる点はcloneと同じだが、Master Slaveという主従関係のあるリソースに使用。

(例) DRBD 、PostgreSQL、MySQL

Primitive

Master Slave(以降、MS)

Primitive

リソースの種類

Primitiveリソースとcloneリソース(共有ディスク構成での例)

node01共有ディスク

node02

Pacemaker Pacemaker

pgsql RA

PostgreSQL

PrimitiveはActiveノードのみ起動、cloneは両ノードで起動

start/stop/monitorアクションを実行し、RAがリソースを実際に制御

pingd RA

pingdPostgreSQL

各リソースに対する制御用コマンド

start/stop/monitor

待機系のPrimitive

リソースは未稼働

Clone Primitive Clone Primitiveread/write

MSリソース(Pacemaker＋DRBDの例)

start/stop/monitor

promote/demote

DRBD RADRBD RA

Pacemaker Pacemaker

DRBD制御用コマンド

両ノードのDRBDをstartアクションで起動。この時点でSlave状態。

その後、一方のノードをpromoteアクションでMaster状態に昇格。

DRBDの停止時にはdemoteによりSlave状態に降格してから停止。

read/write

(Master)

(Slave)

node01 node02

MSリソース(Pacemaker＋ PostgreSQLレプリケーション)

start/stop/monitor

promote/demote

PostgreSQL

(Slave)

pgsql RApgsql RA

Pacemaker Pacemaker

PostgreSQL

制御用コマンド

DRBDとロジックは同じため説明は割愛

PostgreSQL

(Master)

readread/writeMS MS

node01 node02

promotionスコアについて①

MSリソースは各ノードに対するpromotionスコアを持つ

promotionスコアが最も高いノードでMSリソースをMasterに昇格

MSリソースは両系をSlaveとして起動

その後、promotionスコアが高いノードで昇格

MS(Master)

node01 昇格 node02

MS(Slave)

promotionスコアは上記の記号で表す。

数値

MS(Slave)

node01 node02

MS(Slave)

起動起動200 100

200 100

promotionスコアについて②

promotionスコアはフェイルオーバの判断にも使用される

promotionスコアの大小が入れ替わったらフェイルオーバ

promotionスコアがマイナスならSlaveに留まる

片系起動時はそのノードが昇格するはずだが昇格抑止されている

-INFINITYは-1,000,000を意味するスコアの最小値

Master→SlaveMS

Slave→Master

200→100

停止中

100→200node01 node02

node01 node02-INFINITY

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が加算される場合」

Pacemaker+DRBDのMasterスコア設定までの流れ

データ状態（ローカル/対向） Masterスコア

UpToDate/UpToDate10000

次のスライドで説明

UpToDate/DUnknown

10000(Masterの場合)1000(Slaveの場合)障害事例で詳しく説明

PacemakerはMasterスコアに基づいてDRBDをMaster化するノードを決定

DRBDは自ノードと対向ノードのデータの状態を管理

DRBD RA

pacemaker

②状態確認

③データ状態取得

④Master

スコアの設定

DRBD RAは、DRBDの管理するデータ状態に基づいてMasterスコアを設定。以下は一例(※)

①監視

※詳細は参考資料の下記ページも参照して下さい「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

Pacemaker1.1系ではptestではなくcrm_simulateを使用

役割接続状態 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スコア設定例

両系の起動が完了して正常に同期された状態(※)

MasterノードのRAが両ノードのMasterスコアを設定

Pacemaker Pacemaker

pgsql RA

PostgreSQL(Master)

同期接続中

pgsql RA

①monitor

②接続の状態確認

※起動時にどちらをMasterに昇格するかについては参考の下記ページを参照「Pacemaker+PostgreSQLレプリケーション Pacemaker起動から昇格までの流れ」

同期接続

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: 20029Pacemaker1.1系ではptestではなくcrm_simulateを使用

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

①monitor④Masterスコア=10000→1000

10200 10100→1100

切断node01 node02

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

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

200 →

④ -INFINITY

切断node01 node02

インターコネクト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

(Master)

（Slave）

Pacemaker

HW制御ボード

電源OFF

両系Master状態は防がれる 36

インターコネクト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制御ボード

電源OFF

まとめ

MSリソースの特徴

各ノードで起動し、Master Slaveという２つの状態を持つ

昇格(promote)、降格(demote)という2つのアクションを実行

promotionスコア、Masterスコア

MSリソースはpromotionスコアの大きいノードをMasterに昇格する

MSリソースのRAがデータ状態に基づきMasterスコアを更新することで、データ状態の良いノードを優先的にMasterに昇格する

障害事例と対応策

レプリケーションLAN障害

fence-peerスクリプトを使用（DRBDの場合）

STONITHを使用 39

デモについて

LINUX-HA-JAPANのブースにDRBDとPostgreSQLレプリケーション構成のデモ環境を用意しています。

サービス用LAN

データレプリケーション

PostgreSQL 9.2

Apache

PostgreSQL 9.2

仮想IP

Linux-HA Japan Project

Linux-HA Japanについて

Linux-HA Japan URL

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

Pacemaker関連の最新情報を日本語で発信

Pacemakerのダウンロードもこちらからどうぞ。(インストールが楽なリポジトリパッケージを公開しています。)

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

Linux-HA Japanメーリングリスト

• ML登録用URLhttp://linux-ha.sourceforge.jp/の「メーリングリスト」をクリック

• MLアドレスlinux-ha-japan@lists.sourceforge.jp

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

Linux-HA-Japan MLでは、Pacemaker、Heartbeat３、CorosyncDRBDなど、HAクラスタに関連する話題は歓迎！

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

参考文献

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/

参考資料

参考資料の目次

基本編

構成例とCRM設定例

中級編

Pacemaker起動から昇格までの流れ

Pacemaker+DRBD

Pacemaker+PostgreSQLレプリケーション

障害事例と復旧時の動作

Slave故障・復旧

Master故障・復旧

Master側で起動するprimitiveリソース故障

インターコネクトLAN故障

ネットワーク故障

Disk故障

上級編

Masterノードで起動するprimitiveリソースを考慮したスコア計算

構成例とCRM設定例

前提

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ほど信頼性は無い。

Pacemaker＋DRBDの構成例

node01 node02

②DRBD

(Slave)

①pingd

①diskd

④Filesystem

⑤VIP

⑥PostgreSQL

②DRBD

(③Master化)

Pacemaker

NW監視

disk監視

Filesystem

PostgreSQL

①pingd

①diskd

Pacemaker

disk監視

NW監視

①pingdとdiskdを起動後、②両系でDRBDを起動し、③node01でDRBDが昇格に成功したら、④～⑥Masterノード(node01)でprimitive

リソースを起動する。この起動の流れになるようにCRM設定を行う。

grpPgsql grpPgsql

※番号は起動順序

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のみ次のスライドで補足

groupについて

まず3つのprimitiveリソースを定義し、以下を指定

RAの指定、RAに渡すオプション、各アクションの間隔、アクション失敗時の動作

続いてprimitiveリソースをgrpPgsqlという名前でgroup化

Filesystem→VIP→PostgreSQLの順で起動し、逆順で停止

3つのリソースは同一ノードで起動

Filesystem

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-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スコアのところで説明済

②配置・起動順序制約

①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

②配置・起動順序制約

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

⑥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

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設定を推奨

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

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使用時は赤字の箇所を設定

Pacemaker＋PostgreSQLレプリケーションの構成例

Pacemaker＋PostgreSQLレプリケーションは下記URL参照 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf

node01 node02

②PostgreSQL

(Slave)

①pingd

①diskd

Pacemaker

監視

disk監視

①pingd

①diskd

Pacemaker

disk監視

監視

※番号は起動順序

②PostgreSQL

(③Master化)

④vip-master

(外部からの接続用IP)

④vip-rep

(Slaveからの接続用IP)

master-group

vip-rep

vip-master

master-group

Pacemaker+DRBD

はデータが新しい状態（UpToDate）を表すこととする。

はデータが無効状態(Outdated)を表すこととする。

無効

DRBD RAのデータ状態とMasterスコアの詳細

DRBD RAは、自ノードのロール(PrimaryかSecondaryか)と確認したデータ状態に対応したMasterスコアをPacemakerに設定

対応表

Noの順に確認して最初に合致した条件のMasterスコアを設定

※DRBD8.3.16のPKGに含まれるRAを使用した場合のデフォルト設定の例(ユーザによる変更も可能)

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

新新

新無効

DRBD（停止）Outdated/DUnknown

DRBD(停止)

UpToDate/Outdated

無効

起動時のpromotionスコアの計算例

node01は新、node02は無効の状態から両系を同時起動した場合

前スライドの対応表より、node01はUpToDate/UpToDateなので10000、node02はOutdated/DunknownなのでMasterスコア削除

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

無効

はデータが新しい状態（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

典型的な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側を停止

起動時のpromotionスコアの計算例その１

node01のデータ状態が新しくnode02が古い状態で同時起動(※)

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

起動時の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

スコア=

⑧1200-INFINITY

node01 node02

⑦データが古いことを確認

⑨promote

⑩昇格

非同期

若干簡略化しているため、

厳密な動作は異なります。

⑦両ノードとも新しいデータを持つ場合等はここでデータ位置の比較等を実施

古新

起動時のpromotionスコアの計算例その３

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

起動時のpromotionスコアの計算例その４

次の周期の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

障害事例と復旧時の動作

はデータが新しい状態、はデータが古い状態、は不整合な状態新不整合古

単純化のため、locationは未設定とする

Slave故障

Pacemaker+DRBD

node01のDRBDはnode02を切り離す

node02のデータ状態は障害発生時点で古くなる。

node01のPostgreSQLはnode02を切り離す(非同期に設定変更)

node02のデータ状態は障害発生時点で古くなる。

DRBD(Master)

node01 node02

Pacemaker

DRBD(Slave)

Pacemaker

PostgreSQL(Master)

node01 node02

Pacemaker

PostgreSQL(Slave)

Pacemaker

新古

Slave復旧(Pacemaker+DRBD)

Slave復旧時は自動的にクラスタに組み込む(DISK障害時を除く)

復旧時、世代識別子によりnode01のデータが新しいことを検知して同期の方向を決定(node01からnode02に対する同期)。

その後、node02障害中にnode01に書き込まれたデータがDRBD

のビットマップログにより特定され、差分同期される。

完了すると、node02のスコアは元の状態に戻る。

DRBD(Master)

node01 node02

Pacemaker

DRBD(Slave)

Pacemaker

10000 ②10①差分同期

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

新新

同期接続

※長時間経過すると組み込まれない可能性有り。その場合は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

新古

→①1000

→③10000

→②1000node02と不一致※

node02と不一致※

※Masterに書き込み中に突然落ちた場合、どちらか一方のノードのみに書き込まれたデータが存在する可能性があるため、後で一致させる必要がある。

Master復旧(Pacemaker+DRBD)

Master復旧時は自動的にクラスタに組み込む(DISK障害時を除く)

node01の障害中にnode02に書き込まれたデータはDRBDのビット

マップログにより自動的に差分同期され、両系で不一致の可能性があるブロックはDRBDのアクティビティログにより自動的に解消

同期が完了すると、両系のMasterスコアは10000に更新される。

DRBD(Slave)

node01 node02

Pacemaker

DRBD(Master)

Pacemaker

差分同期不一致解消

DRBD(Slave)

node01 node02

Pacemaker

DRBD(Master)

Pacemaker

1000010

新新

古node02と不一致

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

PostgreSQL

DRBD(Master→④Slave)

Pacemaker

Filesystem

PostgreSQL

Pacemaker

grpPgsql grpPgsql

node01 node02

10000→ ③ 1 10000

①故障 ⑥起動

②grpPgsql停止

Master側で起動するprimitiveリソース故障(Pacemaker+PostgreSQL)

DRBDと同様に以下のページを参照して下さい（スコア計算の観点ではDRBDと同じですので、解説はDRBDのみ行っています。）

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の状態遷移」

インターコネクトLAN障害（DRBD）

DRBDは両系が昇格することを抑止する仕様

レプリケーションLANが生きているため、DRBDの上記抑止機能によりnode02のDRBDのpromoteは失敗して、両系がMasterになる状態は防がれる。

Pacemaker

(Master)

（Slave）

Pacemaker

10000 10000

promote NG

node01 node02

インターコネクト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制御ボード

電源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 ¥

(Master→ ③Slave)

(Slave→④Master)pingd

①ping疎通NG

②Promotionスコア更新 10000→

②-INFINITY

ディスク故障

(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

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

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

primitive故障 primitive

-INFINITY

node02node01

primitive primitive

200 89

primitive

MSリソース(resource-stickiness=200設定時)の場合の例

通常時はnode01を優先するためにlocation設定を行っているとする

node01の故障によりフェイルオーバしてnode02のDRBDが昇格

node01の故障回復および故障フラグのクリア(元のスコア値に戻る)

node01のpromotionスコアが大きいためフェイルバック

MSリソースのみの場合、resource-stickinessの効果は無い

node02node01 10200

DRBD(Master) DRBD(Slave)

node02node01 10200

DRBD DRBD(Slave→Master)

10100-INFINITY

故障

node02node01 10200

DRBD(Slave→Master) DRBD(Master→Slave)

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

加算

MSリソースのスコアにresource-stickinessが加算される場合②

grpPgsqlが起動すると、resource-stickinessがgrpPgsqlのallocationスコアに加算され、DRBDのpromotionスコアにも加算される

grpPgsqlが3つのリソースの場合の加算例（前述の設定のケース）

resource-stickiness(ここでは200を設定) * 3 = 600

加算時に「:Master」のあるcolocationの行数+1をかける（1行なら2）

Filesystem

PostgreSQL

grpPgsql

③ 200×3×2 =1200

を加算DRBD

(Master)

10200 11400

DRBD（Master） DRBD(Slave)

grpPgsqlスコア加算 grpPgsql

Primitiveリソース障害時、MSリソースのpromotionスコアは1に下がる

フェイルオーバしてnode02のPromotionスコアが11300になる

node01の復旧および故障フラグのクリア後もフェイルバックしない

grpPgsql

(Master→④Slave

(Slave→⑤Master)11400

→③ 1

①-INFINITY①故障

10100→

⑨11300

⑥grpPgsql起動⑦1200

⑧加算

node01 node02

②加算

DRBD(Slave) DRBD(Master)②10200

①故障フラグクリアgrpPgsql

node01 node02

-INFINITY

grpPgsql

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

→1410

この後、1410<10100でnode02にフェイルオーバ

※DRBDにon-io-error detachの設定がある場合の動作。

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

補足資料

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

レプリケーションLAN切断後のMaster障害からの復旧方法

レプリケーションLAN切断後、Master障害が発生した場合、Slave側は昇格抑止状態になる (DRBDの場合はfence-peer設定時)ため、サービスが停止する。

Master側がディスク故障等により新しいデータで復旧させることができない場合、Slave側は古いデータであるが、昇格させる必要がある。この時は次のスライドの手順で昇格させる。

(Master)

PacemakerPacemaker

（Slave）-INFINITY

故障昇格抑止中

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

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のホスト名に応じて変更する

状態遷移について

DRBDとPacemakerの状態遷移

STOP Secondary

StopPrimary

drbdadm primary r0

drbdadm secondary r0

STOP Slave

Master

promote

demote

PacemakerはSlaveを経由してMasterになる。

Master状態から停止する時は、Slaveを経由する。

DRBDも同じ仕様であり、両者の状態遷移は一致。

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

pacemakerのmaster/slave構成の基本と事例紹介(drbd、postgresqlレプリケーション)...

Technology

osc2014 hamanako report

marketing rules drbd

oracle databaseアドバンスト・レプリケーション...

[solved] zimbra on drbd - zimbra __ forums

drbd + heartbeat + xen: ha...

osc2014　nagoya プレゼンテーション

drbd pasya heartbeat1

osc2014 tokyo/spring hadoop

drbd + openstack (openstack live prague 2016)

drbd users guide

drbd é um amigo!

virtualisierungscluster mit ganeti, kvm und drbd

osc2014 hamanako

osc2014 東京 owncloud性能検証

drbd users guide 1.3.4

high availability with drbd heartbeat

linux-ha-cluster – heartbeat mit drbd

レプリケーション - i-o data...【index】へ 2...

mysql drbd

empressレプリケーション説明資料 2