Your SlideShare is downloading. ×
PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @OSC2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

10,253
views

Published on

http://linux-ha.sourceforge.jp/wp/archives/3930

http://linux-ha.sourceforge.jp/wp/archives/3930

Published in: Technology

0 Comments
23 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,253
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
190
Comments
0
Likes
23
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Pacemakerの Master/Slave構成の 基本と事例紹介 (DRBD、PostgreSQLレプリケーション) 2014年 3月1日 OSC2014 Tokyo Linux-HA Japan 渡辺 達也 <tatsuya.w@gmail.com> Linux-HA Japan Project 1
  • 2. 本日の流れ  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 2
  • 3. Pacemakerとは  サーバ・アプリケーションの故障監視 サービスの監視・制御 サーバ#1 サーバ間の監視・制御 サーバ#2 3
  • 4. Pacemakerとは    サーバ・アプリケーションの故障監視 故障検知時、自動的にフェイルオーバ ダウンタイムの最小化 フェイルオーバ STONITH (強制電源断) サーバ#1 サーバ#2 4
  • 5. Pacemakerのアーキテクチャ   Pacemakerが起動/停止/監視を制御する対象をリソースと呼ぶ  例)Apache, PostgreSQL, ファイルシステム, 仮想IPアドレス etc... リソースの制御はリソースエージェント(RA)を介して行う  RAが各リソースの操作方法の違いをラップし、Pacemakerで制御 できるようにしている リソース 制御 制御 PostgreSQL RA リソース エージェント Apache RA 共有ディスク RA 制御 5
  • 6. Pacemakerで監視できること 仮想IP ネットワーク監視・制御 アプリケーション監視・制御 ・起動 ・停止 ・稼働監視 ・ping疎通確認 ・仮想IP制御 ノード監視 自己監視 ・プロセス監視 ・watchdog サーバ#1 ディスク監視・制御 ・ハートビート通信 ・STONITH(強制電源断) ・ファイルシステム監視 ・共有ディスク排他制御 サーバ#2 6
  • 7.  各アプリケーションの概要  pacemaker  DRBD、 PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 7
  • 8. 共有ディスクを使用した構成について   メリット  データが一箇所のため運用しやすい デメリット  複数ノードが同時にアクセスできないように制御が必要  共有ディスクが高額  共有ディスクがSPOFになる 稼動系(Active) 待機系(Standby) DB、ファイル サーバ等 DB、ファイル サーバ等(未稼働) 共有ディスク 8
  • 9. DRBD、PostgreSQLレプリケーションを使用した構成   メリット  安価なローカルディスクを使用してデータを2重化できる  ディスクがSPOFにならない デメリット  レプリケーションが性能に影響を与える  複数ノードに分散したデータを同一に保つ必要があり運用が複雑 Slave Master DRBD or PostgreSQL ローカルディスク データレプリケーションLAN レプリケーション DRBD or PostgreSQL ローカルディスク 9
  • 10. DRBD概要     Linuxカーネルのブロックデバイスドライバのレイヤで動作 様々なデータが複製可能(PostgreSQL, MySQL, Oracle, LDAP ・・・) Primary、Secondaryの2台構成が基本。  Primaryノードは読み書き可能。Secondaryノードは不可。 3種類の同期モード プロトコルA(非同期)、B(メモリ同期)、C(同期) プロトコルC 設定時の動作例 ⑤完了 ①書き込み Filesystem ②ブロック送信 DRBD(Primary) ②書き込み DRBD(Secondary) ④完了 ③書き込み 10
  • 11. PostgreSQL レプリケーション概要    PostgreSQL9.0から実装された本体組み込みの機能  9.0: 非同期 9.1:同期 9.2:カスケードレプリケーション Master側は更新/参照可、Slave側は参照可。スケールアウトも可 切替に必要な処理(下記)が少ないためフェイルオーバが早い  ファイルシステムのマウント、PostgreSQL起動、リカバリ処理 同期:正常時動作 ⑥完了 ①更新 PostgreSQL(Slave) PostgreSQL(Master) ⑤完了 Filesystem ②WAL 書き込み 参照 ③WAL送信 Filesystem ④WAL 書き込み WAL反映の タイミングは 非同期 11
  • 12. Pacemaker+DRBD / PostgreSQLレプリケーション構成  DRBD、PostgreSQLレプリケーション機能はデータの複製のみ  Pacemakerと組み合わせることで可用性を高めることが可能 障害検知 フェイルオーバ Slave→Master Master→Slave DRBD or PostgreSQL データレプリケーションLAN DRBD or PostgreSQL インターコネクトLAN ローカルディスク ローカルディスク 12
  • 13.  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 13
  • 14. リソースの種類 Primitive Primitive Primitive 全てのリソース定義の基礎。どこか一つ のノードで動作させ、故障時にフェイル オーバさせたいリソースに使用。 (例) PostgreSQL, Filesystem, IPアドレス Clone Clone Clone Master Slave(以降、MS) Master Slave 複数のノードで動作させたいリソースに 使用。 (例) NW監視, ディスク監視,apache 複数のノードで動作させる点はcloneと同 じだが、Master Slaveという主従関係の あるリソースに使用。 (例) DRBD 、PostgreSQL、MySQL 14
  • 15. 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
  • 16. 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
  • 17. 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
  • 18.  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 18
  • 19. 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
  • 20. 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
  • 21. ※参考の下記資料も参照して下さい。 「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
  • 22.  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 22
  • 23. 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
  • 24. 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
  • 25. 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
  • 26.  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 26
  • 27. 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
  • 28. 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
  • 29. 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
  • 30.  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 30
  • 31. レプリケーション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
  • 32. レプリケーション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
  • 33. レプリケーション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
  • 34.  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法   promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害 34
  • 35. インターコネクト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
  • 36. インターコネクト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
  • 37. インターコネクト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
  • 38. インターコネクトLANとレプリケーションLAN障害(PostgreSQL) 対策  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHについては説明済みのため割愛 PostgreSQL (Master) PostgreSQL (Slave) Pacemaker Pacemaker HW制御 ボード HW制御 ボード 電源OFF 両系Master状態は防がれる 38
  • 39. まとめ  MSリソースの特徴  各ノードで起動し、Master Slaveという2つの状態を持つ  昇格(promote)、降格(demote)という2つのアクションを実行  promotionスコア、Masterスコア  MSリソースはpromotionスコアの大きいノードをMasterに昇格する  MSリソースのRAがデータ状態に基づきMasterスコアを更新するこ とで、データ状態の良いノードを優先的にMasterに昇格する  障害事例と対応策  レプリケーションLAN障害  fence-peerスクリプトを使用(DRBDの場合)  レプリケーションLAN+インターコネクトLAN障害  STONITHを使用 39
  • 40. デモについて  LINUX-HA-JAPANのブースにDRBDとPostgreSQLレプリケーション 構成のデモ環境を用意しています。 サービス用LAN 仮想IP pm01 pm02 Apache PostgreSQL 9.2 DRBD データレプリケーション PostgreSQL 9.2 DRBD 40
  • 41. Linux-HA Japanについて Linux-HA Japan Project 41
  • 42. Linux-HA Japan URL http://linux-ha.sourceforge.jp/ http://sourceforge.jp/projects/linux-ha/ Pacemaker関連の最新情報を 日本語で発信 Pacemakerのダウンロードもこ ちらからどうぞ。 (インストールが楽なリポジトリパッケージ を公開しています。) 42
  • 43. Linux-HA Japanメーリングリスト 日本におけるHAクラスタについての活発な意見交換の場として 「Linux-HA Japan日本語メーリングリスト」 も開設しています。 Linux-HA-Japan MLでは、Pacemaker、Heartbeat3、Corosync DRBDなど、HAクラスタに関連する話題は歓迎! • ML登録用URL http://linux-ha.sourceforge.jp/ の「メーリングリスト」をクリック • MLアドレス linux-ha-japan@lists.sourceforge.jp ※スパム防止のために、登録者以外の投稿は許可制です Linux-HA Japan Project 43
  • 44. 参考文献  Pacemaker 1.0 Configuration Explained  http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html-single/Pacemaker_Explained/  Colocation Explained  http://clusterlabs.org/doc/Colocation_Explained.pdf  リソースエージェント開発者ガイド  http://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
  • 45. ご清聴ありがとうございました。 Linux-HA Japan 検索 http://linux-ha.sourceforge.jp/ Linux-HA Japan Project 45
  • 46. 参考資料 46
  • 47. 参考資料の目次    基本編  構成例とCRM設定例 中級編  Pacemaker起動から昇格までの流れ  Pacemaker+DRBD  Pacemaker+PostgreSQLレプリケーション  障害事例と復旧時の動作  Slave故障・復旧  Master故障・復旧  Master側で起動するprimitiveリソース故障  インターコネクトLAN故障  ネットワーク故障  Disk故障 上級編  Masterノードで起動するprimitiveリソースを考慮したスコア計算47
  • 48. 構成例とCRM設定例 48
  • 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/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
  • 50. 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
  • 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" 基本的な内容なので割愛。 groupのみ次のスライドで補足 Primitiveリソース ・Filesystem ・VIP ・PostgreSQL Primitiveリソース のグループ化 cloneリソース ・pingd ・diskd 51
  • 52. groupについて  まず3つのprimitiveリソースを定義し、以下を指定  RAの指定、RAに渡すオプション、各アクションの間隔、アクション失 敗時の動作 PostgreSQL VIP Filesystem  続いてprimitiveリソースをgrpPgsqlという名前でgroup化  Filesystem→VIP→PostgreSQLの順で起動し、逆順で停止  3つのリソースは同一ノードで起動 ③PostgreSQL 起動時 ②VIP ①Filesystem 停止時 52
  • 53. 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は別の値を指定 次に、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
  • 55. 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
  • 56. ②配置・起動順序制約  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
  • 57. 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
  • 58. 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設定例 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
  • 60. 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
  • 61. Pacemaker+DRBD Pacemaker起動から昇格までの流れ 新 はデータが新しい状態(UpToDate)を表すこととする。 無効 はデータが無効状態(Outdated)を表すこととする。 61
  • 62. 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
  • 63. 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
  • 64. 起動時の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
  • 65. Pacemaker+PostgreSQLレプリケーション Pacemaker起動から昇格までの流れ 新 はデータが新しい状態(Master側と同期接続中のSlave側)を表すこととする。 古 はデータが古い状態(非同期接続中、または切断中のSlave側)を表すこととする。 65
  • 66. pgsql RAのデータ状態とMasterスコアの詳細  前述の通り、pgsql RAはpostgreSQLに対して確認した接続状態に応じて Masterスコアを設定するが、この時、データ状態についても設定している  データ状態は、Pacemaker停止時も保持されることから、次回起動 時に、前回停止直前のデータ状態が分かる仕組みになっている。 新 古 役割 Master Slave Slave Slave 接続状態 同期 非同期 切断中 データ状態 LATEST STREAMING|SYNC STREAMING|ASYNC DISCONNECT Master スコア 1000 100 -INFINITY -INFINITY 66
  • 67. 典型的な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
  • 68. 起動時のpromotionスコアの計算例 その1  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
  • 69. 起動時のpromotionスコアの計算例 その2  若干簡略化しているため、 厳密な動作は異なります。 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
  • 70. 起動時のpromotionスコアの計算例 その3  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
  • 71. 起動時のpromotionスコアの計算例 その4   次の周期の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
  • 72. 障害事例と復旧時の動作 新 はデータが新しい状態、 古 はデータが古い状態、 不整合 は不整合な状態 単純化のため、locationは未設定とする 72
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. ※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
  • 77. 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
  • 78. 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
  • 79. 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
  • 80. 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
  • 81. インターコネクト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
  • 82. インターコネクトLAN障害(PostgreSQLレプリケーション)  Pacemakerはスプリットブレイン状態のためnode02でpromote実行  PostgreSQLレプリケーションは両系をMasterに昇格可能  レプリケーションのセッションは切断される  node02は昇格し、両系がMasterの状態になってしまう。 node02 node01 PostgreSQL (Master) 1000 100 PostgreSQL (Slave→Master) Promote Pacemaker Pacemaker 82
  • 83. インターコネクトLAN障害 対策(PostgreSQLレプリケーション)  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHについては説明済みのため割愛 PostgreSQL (Master) PostgreSQL (Slave) Pacemaker Pacemaker HW制御 ボード HW制御 ボード 電源OFF 両系Master状態は防がれる 83
  • 84. サービス提供用ネットワーク故障  下記設定を前提 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
  • 85. ディスク故障  下記設定を前提 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
  • 86. Masterノードで起動する primitiveリソースを考慮した スコア計算 Pacemakerとの組み合わせが前提のため、図にはpacemakerを記載しないこととする。 MSリソースの解説では前述のPacemaker+DRBDのCRM設定時を前提とする。 また、locationにはnode01に200、node02に100が設定されているとする 86
  • 87. 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
  • 88. 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
  • 89. 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
  • 90. 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
  • 91. 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
  • 92. 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
  • 93. 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
  • 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 DRBD RAが設定するMasterスコア 10000 10000 10 100 10000 resource-stickiness 0 10100 94 Promotionスコア 1200 0 1200 11400 10100 1410
  • 95. 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
  • 96. 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. 補足資料 97
  • 98. 古いデータを持つ 昇格抑止中のノードを 強制的に昇格する方法 98
  • 99. レプリケーションLAN切断後のMaster障害からの復旧方法   レプリケーションLAN切断後、Master障害が発生した場合、Slave側は 昇格抑止状態になる (DRBDの場合はfence-peer設定時)ため、サー ビスが停止する。 Master側がディスク故障等により新しいデータで復旧させることができ ない場合、Slave側は古いデータであるが、昇格させる必要がある。こ の時は次のスライドの手順で昇格させる。 MS (Master) MS (Slave) 故障 昇格抑止中 Pacemaker -INFINITY Pacemaker 99
  • 100. Slave側での制約解除コマンドについて(DRBD)  以下のコマンドで赤字部分を確認 [root@node02 ~]# grep "drbd-fence-by-handler" /var/lib/heartbeat/crm/cib.xml <rsc_location rsc="msDrbd" id="drbd-fence-by-handler-r0-msDrbd">  location制約の削除  上で確認した赤字部分を以下の赤字部分に入れて、コマンド実行 [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
  • 101. 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. 状態遷移について 102
  • 103. 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
  • 104. 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