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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

※参考の下記資料も参照して下さい。「MSリソースのスコアにresource-stickinessが加算される場合」 promotionスコアの求め方  promotionスコア = location設定値＋Masterスコア (※) ①  ② ①location設定値  PacemakerのCRM設定で指定 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  ②Masterスコア  DRBDやpgsql RAがデータ状態や接続状態(後述)に応じて設定  データ状態の良いノードで優先的にMSリソースを昇格可能 21

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

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

Masterスコアとpromotionスコアの確認方法（DRBDの例）  Masterスコアの確認方法  ここでは両ノードが最新データを持つため10000が設定された例 [root@node01 ~]# crm_mon -fAr * Node node01: + master-prmDrbd:0 * Node node02: + master-prmDrbd:1  : 10000 : 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 Pacemaker1.1系ではptestではなくcrm_simulateを使用 25

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

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

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

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

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

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

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

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

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

インターコネクトLANとレプリケーションLAN障害(PostgreSQL) 対策  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHについては説明済みのため割愛 PostgreSQL (Master) PostgreSQL （Slave） Pacemaker Pacemaker HW制御ボード HW制御ボード電源OFF 両系Master状態は防がれる 38

まとめ  MSリソースの特徴  各ノードで起動し、Master Slaveという２つの状態を持つ  昇格(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レプリケーション構成のデモ環境を用意しています。サービス用LAN 仮想IP pm01 pm02 Apache PostgreSQL 9.2 DRBD データレプリケーション PostgreSQL 9.2 DRBD 40

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

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

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

ご清聴ありがとうございました。 Linux-HA Japan 検索 http://linux-ha.sourceforge.jp/ Linux-HA Japan Project 45

参考資料 46

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

構成例とCRM設定例 48

前提  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/linuxha/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ほど信頼性は無い。 49

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

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" 基本的な内容なので割愛。 groupのみ次のスライドで補足 Primitiveリソース・Filesystem ・VIP ・PostgreSQL Primitiveリソースのグループ化 cloneリソース・pingd ・diskd 51

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

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

①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は別の値を指定 次に、ms要素を設定することで、DRBDをMaster Slaveリソース化 ms msDrbd prmDrbd ¥ meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1“ notify=true 「msDrbd」：MSリソース名。制約関連の設定で使用「prmDrbd」：DRBDのPrimitiveリソース名を指定 meta 以降の部分(meta要素)：次のスライドで説明 54

ms要素の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を選択する。 55

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

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

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

Pacemakerと組み合わせる場合のDRBD設定例 crm-fence-peer.sh使用時は赤字の箇所を設定 global { usage-count } resource r0 { device minor 0; meta-disk internal; disk /dev/sda1; 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"; } 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; } } 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; } } 59

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

インターコネクトLAN障害（PostgreSQLレプリケーション）  Pacemakerはスプリットブレイン状態のためnode02でpromote実行  PostgreSQLレプリケーションは両系をMasterに昇格可能  レプリケーションのセッションは切断される  node02は昇格し、両系がMasterの状態になってしまう。 node02 node01 PostgreSQL (Master) 1000 100 PostgreSQL （Slave→Master） Promote Pacemaker Pacemaker 82

インターコネクトLAN障害対策(PostgreSQLレプリケーション)  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHについては説明済みのため割愛 PostgreSQL (Master) PostgreSQL （Slave） Pacemaker Pacemaker HW制御ボード HW制御ボード電源OFF 両系Master状態は防がれる 83

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

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

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

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

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

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

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

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

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

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

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 DRBD RAが設定するMasterスコア 10000 10000 10 100 10000 resource-stickiness 0 10100 94 Promotionスコア 1200 0 1200 11400 10100 1410

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

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

補足資料 97

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

レプリケーションLAN切断後のMaster障害からの復旧方法   レプリケーションLAN切断後、Master障害が発生した場合、Slave側は昇格抑止状態になる (DRBDの場合はfence-peer設定時)ため、サービスが停止する。 Master側がディスク故障等により新しいデータで復旧させることができない場合、Slave側は古いデータであるが、昇格させる必要がある。この時は次のスライドの手順で昇格させる。 MS (Master) MS （Slave）故障昇格抑止中 Pacemaker -INFINITY Pacemaker 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-byhandler-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に変更 [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のホスト名に応じて変更する  PacemakerがSlaveのデータ状態を確認後、昇格する 101

状態遷移について 102

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

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

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

by Tatsuya Watanabe

on Mar 04, 2014

Statistics

Views

Actions

2 Embeds 13

Accessibility

Categories

Upload Details

Usage Rights

Report content

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

http://www.slideee.com	12
http://s.deeeki.com	1