Successfully reported this slideshow.

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

19,486 views

Published on

http://linux-ha.sourceforge.jp/wp/archives/3930
https://www.ospn.jp/osc2014-spring/modules/eguide/event.php?eid=27

Published in: Technology

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

  1. 1. Linux-HA Japan Project 1 2014年 3月1日 OSC2014 Tokyo Linux-HA Japan 渡邉 達也 <tatsuya.w@gmail.com> Pacemakerの Master/Slave構成の 基本と事例紹介 (DRBD、PostgreSQLレプリケーション)
  2. 2. 自己紹介  名前  渡邉 達也 (@infrajp)  前職  ネットワークエンジニア  Global-ASの運用  MVNEネットワークシステム開発など  現職  Linux OSSテクニカルサポート  Linux-HA Japanプロジェクト  Pacemaker・DRBD検証・開発、コミュニティーのML対応など 2
  3. 3. 3 本日の流れ  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  4. 4. 4 Pacemakerとは サーバ#1 サーバ#2 サービスの監視・制御  サーバ・アプリケーションの故障監視 サーバ間の監視・制御
  5. 5. 5 サーバ#1 サーバ#2 STONITH (強制電源断) Pacemakerとは  サーバ・アプリケーションの故障監視  故障検知時、自動的にフェイルオーバ  ダウンタイムの最小化 フェイルオーバ
  6. 6. 6 PostgreSQL RA 共有ディスク RA リソース エージェント  Pacemakerが起動/停止/監視を制御する対象をリソースと呼ぶ  例)Apache, PostgreSQL, ファイルシステム, 仮想IPアドレス etc...  リソースの制御はリソースエージェント(RA)を介して行う  RAが各リソースの操作方法の違いをラップし、Pacemakerで制御 できるようにしている リソース 制御 制御 制御 Apache RA Pacemakerのアーキテクチャ
  7. 7. 7 Pacemakerで監視できること サーバ#1 サーバ#2 仮想IP 自己監視 ノード監視 ディスク監視・制御 ネットワーク監視・制御 ・プロセス監視 ・watchdog ・ファイルシステム監視 ・共有ディスク排他制御 ・ハートビート通信 ・STONITH(強制電源断) ・ping疎通確認 ・仮想IP制御・起動 ・停止 ・稼働監視 アプリケーション監視・制御
  8. 8. 8  各アプリケーションの概要  pacemaker  DRBD、 PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  9. 9. 9 共有ディスクを使用した構成について  メリット  データが一箇所のため運用しやすい  デメリット  複数ノードが同時にアクセスできないように制御が必要  共有ディスクが高額  共有ディスクがSPOFになる 共有ディスク DB、ファイル サーバ等 DB、ファイル サーバ等(未稼働) 稼動系(Active) 待機系(Standby)
  10. 10. DRBD、PostgreSQLレプリケーションを使用した構成  メリット  安価なローカルディスクを使用してデータを2重化できる  ディスクがSPOFにならない  デメリット  レプリケーションが性能に影響を与える  複数ノードに分散したデータを同一に保つ必要があり運用が複雑 DRBD or PostgreSQL DRBD or PostgreSQL ローカルディスク ローカルディスク レプリケーション データレプリケーションLAN Master Slave 10
  11. 11. 11  Linuxカーネルのブロックデバイスドライバのレイヤで動作  様々なデータが複製可能(PostgreSQL, MySQL, Oracle, LDAP ・・・)  Primary、Secondaryの2台構成が基本。  Primaryノードは読み書き可能。Secondaryノードは不可。  3種類の同期モード プロトコルA(非同期)、B(メモリ同期)、C(同期) DRBD概要 DRBD(Primary) DRBD(Secondary) Filesystem ①書き込み ②ブロック送信 ②書き込み ③書き込み④完了 ⑤完了 プロトコルC 設定時の動作例
  12. 12. 12 PostgreSQL レプリケーション概要  PostgreSQL9.0から実装された本体組み込みの機能  9.0: 非同期 9.1:同期 9.2:カスケードレプリケーション  Master側は更新/参照可、Slave側は参照可。スケールアウトも可  切替に必要な処理(下記)が少ないためフェイルオーバが早い  ファイルシステムのマウント、PostgreSQL起動、リカバリ処理 PostgreSQL(Master) ①更新 ③WAL送信 ②WAL 書き込み ⑤完了 ⑥完了 PostgreSQL(Slave) ④WAL 書き込み 同期:正常時動作 参照 WAL反映の タイミングは 非同期 Filesystem Filesystem
  13. 13. Pacemaker+DRBD / PostgreSQLレプリケーション構成  DRBD、PostgreSQLレプリケーション機能はデータの複製のみ  Pacemakerと組み合わせることで可用性を高めることが可能 13 DRBD or PostgreSQL DRBD or PostgreSQL インターコネクトLAN ローカルディスク ローカルディスク データレプリケーションLAN Master→Slave Slave→Master フェイルオーバ 障害検知
  14. 14. 14  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  15. 15. Primitive Clone Clone Master Slave 全てのリソース定義の基礎。どこか一つ のノードで動作させ、故障時にフェイル オーバさせたいリソースに使用。 (例) PostgreSQL, Filesystem, IPアドレス 複数のノードで動作させたいリソースに 使用。 (例) NW監視, ディスク監視,apache 複数のノードで動作させる点はcloneと同 じだが、Master Slaveという主従関係の あるリソースに使用。 (例) DRBD 、PostgreSQL、MySQL Clone Primitive Master Slave(以降、MS) Primitive リソースの種類 15
  16. 16. 16 Primitiveリソースとcloneリソース(共有ディスク構成での例) node01 共有ディスク node02 Pacemaker Pacemaker pgsql RA PostgreSQL  PrimitiveはActiveノードのみ起動、cloneは両ノードで起動  start/stop/monitorアクションを実行し、RAがリソースを実際に制御 pingd RA pingd pingd RA pingdPostgreSQL 各リソースに対する 制御用コマンド start/stop/monitor 待機系の Primitive リソースは 未稼働 Clone Primitive Clone Primitiveread/write
  17. 17. 17 MSリソース(Pacemaker+DRBDの例) start/stop/monitor promote/demote レプリケーション DRBD RADRBD RA Pacemaker Pacemaker DRBD制御用コマンド  両ノードのDRBDをstartアクションで起動。この時点でSlave状態。  その後、一方のノードをpromoteアクションでMaster状態に昇格。  DRBDの停止時にはdemoteによりSlave状態に降格してから停止。 read/write DRBD (Master) DRBD (Slave) MS MS node01 node02
  18. 18. 18 MSリソース(Pacemaker+ PostgreSQLレプリケーション) start/stop/monitor promote/demote PostgreSQL (Slave) pgsql RApgsql RA Pacemaker Pacemaker PostgreSQL 制御用コマンド  DRBDとロジックは同じため説明は割愛 PostgreSQL (Master) レプリケーション readread/writeMS MS node01 node02
  19. 19. 19  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  20. 20. promotionスコアについて①  MSリソースは各ノードに対するpromotionスコアを持つ  promotionスコアが最も高いノードでMSリソースをMasterに昇格  MSリソースは両系をSlaveとして起動  その後、promotionスコアが高いノードで昇格 MS(Master) node01 昇格 node02 MS(Slave) promotionスコアは 上記の記号で表す。 数値 MS(Slave) node01 node02 MS(Slave) 起動 起動 200 100 20 200 100
  21. 21. 21 promotionスコアについて②  promotionスコアはフェイルオーバの判断にも使用される  promotionスコアの大小が入れ替わったらフェイルオーバ  promotionスコアがマイナスならSlaveに留まる  片系起動時はそのノードが昇格するはずだが昇格抑止されている  -INFINITYは-1,000,000を意味するスコアの最小値 MS Master→Slave MS Slave→Master 200→100 MS Slave MS 停止中 100→200 node01 node02 node01 node02 -INFINITY
  22. 22. 22 promotionスコアの求め方  promotionスコア = location設定値+Masterスコア (※)  ①location設定値  PacemakerのCRM設定で指定  ②Masterスコア  DRBDやpgsql RAがデータ状態や接続状態(後述)に応じて設定  データ状態の良いノードで優先的にMSリソースを昇格可能 location rsc_loc-1 MSリソース名 rule $id="loc-1" $role="master“ 200: #uname eq node01 rule $id="loc-2" $role="master" 100: #uname eq node02 ① ② ※参考の下記資料も参照して下さい。 「MSリソースのスコアにresource-stickinessが加算される場合」
  23. 23. 23  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  24. 24. Pacemaker+DRBDのMasterスコア設定までの流れ データ状態(ローカル/対向) Masterスコア UpToDate/UpToDate 10000 次のスライドで説明 UpToDate/DUnknown 10000(Masterの場合) 1000(Slaveの場合) 障害事例で詳しく説明 PacemakerはMasterスコアに基づいてDRBDを Master化するノードを決定 DRBDは自ノードと対向ノードのデータの状態を管理 DRBD RA DRBD pacemaker ② 状態 確認 ③ データ 状態 取得 ④ Master スコア の設定 DRBD RAは、DRBDの管理するデータ状態に基づ いてMasterスコアを設定。以下は一例(※) 24 ① 監視 ※詳細は参考資料の下記ページも参照して下さい 「DRBD RAのデータ状態とMasterスコアの詳細」
  25. 25. 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
  26. 26. Masterスコアとpromotionスコアの確認方法(DRBDの例)  Masterスコアの確認方法  ここでは両ノードが最新データを持つため10000が設定された例  promotionスコアの確認方法  node01のlocation=200、node02のlocation=100とした場合 [root@node01 ~]# ptest -sL | grep promotion prmDrbd:0 promotion score on node01: 10200 prmDrbd:1 promotion score on node02: 10100 [root@node01 ~]# crm_mon -fAr * Node node01: + master-prmDrbd:0 : 10000 * Node node02: + master-prmDrbd:1 : 10000 26 Pacemaker1.1系ではptestではなくcrm_simulateを使用
  27. 27. 27  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  28. 28. 役割 接続状態 Masterスコア Master - 1000(次のスライドで説明) Slave 同期接続 100(次のスライドで説明) Slave 切断 -INFINITY(障害事例で説明) Pacemaker+PostgreSQLのMasterスコア設定までの流れ Master側のPostgreSQLはSlaveとの接続状態 (同期・非同期・切断中)を管理 PacemakerはMasterスコアに基づいて PostgreSQLをMaster化するノードを決定 Master側のpgsql RAは自ノードのMasterスコアを 1000に設定するとともに、接続状態を元にSlave側 のMasterスコアについても設定(※) pgsql RA PostgreSQL pacemaker 28 ② 状態 確認 ③ 接続 状態 取得 ④ Master スコア の設定 ① 監視 ※詳細は参考資料の下記ページも参照して下さい。 「pgsql RAのデータ状態とMasterスコアの詳細」
  29. 29. Masterスコア設定例  両系の起動が完了して正常に同期された状態(※)  locationにはnode01に200、node02に100が設定されているとする  MasterノードのRAが両ノードのMasterスコアを設定 Pacemaker Pacemaker pgsql RA PostgreSQL(Master) 同期接続中 pgsql RA PostgreSQL(Slave) ① monitor ②接続の 状態確認 ③接続状態取得 ④ Masterスコア=1000 ※起動時にどちらをMasterに昇格するかについては参考の下記ページを参照 「Pacemaker+PostgreSQLレプリケーション Pacemaker起動から昇格までの流れ」 ④ Masterスコア=100 同期接続 1200 200 node01 node02
  30. 30. Masterスコアの例(PostgreSQLレプリケーション)  Masterスコアの確認方法  ここではMaster側:1000、 Slave側は同期接続中のため100  promotionスコアの確認方法  node01のlocation=200、node02のlocation=100とした場合 [root@node01 ~]# crm_mon-fAr1 * Node node01: + master-pgsql:1 : 1000 * Node node02: + master-pgsql:0 : 100 [root@node01 ~]# ptest -sL | grep promotion pgsql:0 promotion score on node01: 1200 pgsql:1 promotion score on node02: 200 30 Pacemaker1.1系ではptestではなくcrm_simulateを使用
  31. 31. 31  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  32. 32. レプリケーションLAN障害(DRBD)  両ノードのDRBDはデータ状態をUpToDate/Dunknownに変更  node01と同期できないためnode02のDRBDは古い可能性有り  DRBD RAは自ノードがSlaveでデータ状態がUpToDate/DUnknownの 場合はデータが古い可能性があるためMasterスコアを1000に下げる  フェイルオーバが発生すると古いデータを持つnode02のDRBDが昇格 Pacemaker Pacemaker DRBD RA DRBD(Master) UpToDate/DUnknown DRBD RA DRBD(Slave) UpToDate/DUnknown ①monitor ②データ 状態確認 ③データ 状態取得 ④Masterスコア =10000 ②データ 状態確認 ③データ 状態取得 ①monitor ④Masterスコア =10000→1000 10200 10100→1100 切断 node01 node02
  33. 33. 33 レプリケーションLAN障害 対策(DRBD)  DRBD側に以下のfence-peerスクリプトを設定(※)  レプリケーションLAN切断時にMaster側のDRBDがcrm-fence- peer.shを実行し、node02が古いデータで昇格するのを抑止。  レプリケーションLANが復旧して同期が完了すると昇格抑止は解除 fence-peer "/usr/lib/drbd/crm-fence-peer.sh"; Pacemaker Pacemaker DRBD RA DRBD(Master) UpToDate/DUnknown DRBD RA DRBD(Slave) UpToDate/DUnknown 10200 1100 → ④ -INFINITY crm-fence-peer.sh ②切断を検知して実行 ①切断 ③対向ノードのlocationに –INFINITYを設定 ※参考の下記ページの赤字部分も要設定 「Pacemakerと組み合わせる場合のDRBD設定例」 node01 node02
  34. 34. レプリケーションLAN障害(PostgreSQLレプリケーション)  Master側のpgsql RAはレプリケーション接続が切れた場合、Slave側 のMasterスコアを-INFINITYに更新  DRBDのように外部スクリプトを指定しなくても、 node02が古いデータ で昇格するのを抑止する仕様 Pacemaker Pacemaker pgsql RA PostgreSQL(Master) 切断中 pgsql RA PostgreSQL(Slave) ① monitor ②接続の 状態確認 ③接続状態取得 ④ Masterスコア=1000 ④Masterスコア =100→ -INFINITY 1200 200 → ④ -INFINITY 切断 node01 node02
  35. 35. 35  各アプリケーションの概要  pacemaker  DRBD、PostgreSQLレプリケーション  Master Slave リソースと従来のリソースとの違い  Masterに昇格するノードの選定方法  promotionスコア  Pacemaker + DRBDのMasterスコア  Pacemaker + PostgreSQLレプリケーションのMasterスコア  障害事例  レプリケーションLAN障害  レプリケーションLAN+インターコネクトLAN障害
  36. 36. インターコネクトLANとレプリケーションLAN障害(DRBD)  インターコネクトLANも切断されていることから、 DRBDから実行された crm-fence-peer.shはnode02を昇格抑止状態にすることができない  node02のPacemakerはサービス継続するためpromote実行  node02は昇格し、両系がMasterの状態になってしまう。 36 Pacemaker Pacemaker DRBD RA DRBD(Master) UpToDate/DUnknown DRBD RA DRBD(Slave→⑥Master) UpToDate/DUnknown 10200 1100 crm-fence-peer.sh ②切断を検知して実行 ①切断 ③location設定不可 ④Promote ⑤昇格コマンド node01 node02
  37. 37. インターコネクトLANとレプリケーションLAN障害(DRBD) 対策  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHを使用すると、インターコネクトLAN切断時、Masterは Slaveが昇格する前に別LANからSlaveの電源をOFF  STONITHは下記URL参照  http://sourceforge.jp/projects/linux- ha/docs/Pacemaker_OSC2013Kyoto_20130803/ja/1/Pacemaker_OSC2013Kyoto_20130803.pdf Pacemaker DRBD (Master) DRBD (Slave) Pacemaker HW制御 ボード HW制御 ボード 電源OFF 両系Master状態は防がれる 37
  38. 38. インターコネクトLANとレプリケーションLAN障害(PostgreSQL)  インターコネクトLANが切断されていることから、 Master側RAは node02のMasterスコアを-INFINITYに更新することができない  Pacemakerはスプリットブレイン状態のためnode02でpromote実行  node02は昇格し、両系がMasterの状態になってしまう。 Pacemaker Pacemaker pgsql RA PostgreSQL(Master) 切断中 pgsql RA PostgreSQL ( Slave→⑦Master ) ① monitor ②接続の 状態確認 ③接続状態取得 ④ Masterスコア=1000 ④Masterスコア 設定不可 1200 200 ⑤Promote ⑥昇格コマンド node01 node02
  39. 39. インターコネクトLANとレプリケーションLAN障害(PostgreSQL) 対策  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHについては説明済みのため割愛 Pacemaker PostgreSQL (Master) PostgreSQL (Slave) Pacemaker HW制御 ボード HW制御 ボード 電源OFF 両系Master状態は防がれる 39
  40. 40. まとめ  MSリソースの特徴  各ノードで起動し、Master Slaveという2つの状態を持つ  昇格(promote)、降格(demote)という2つのアクションを実行  promotionスコア、Masterスコア  MSリソースはpromotionスコアの大きいノードをMasterに昇格する  MSリソースのRAがデータ状態に基づきMasterスコアを更新するこ とで、データ状態の良いノードを優先的にMasterに昇格する  障害事例と対応策  レプリケーションLAN障害  fence-peerスクリプトを使用(DRBDの場合)  レプリケーションLAN+インターコネクトLAN障害  STONITHを使用 40
  41. 41. デモについて  LINUX-HA-JAPANのブースにDRBDとPostgreSQLレプリケーション 構成のデモ環境を用意しています。 pm01 サービス用LAN データレプリケーション DRBD PostgreSQL 9.2 DRBD Apache pm02 PostgreSQL 9.2 仮想IP 41
  42. 42. Linux-HA Japan Project Linux-HA Japanについて 42
  43. 43. 43 Linux-HA Japan URL http://linux-ha.sourceforge.jp/ Pacemaker関連の最新情報を 日本語で発信 Pacemakerのダウンロードもこ ちらからどうぞ。 (インストールが楽なリポジトリパッケージ を公開しています。) http://sourceforge.jp/projects/linux-ha/
  44. 44. Linux-HA Japan Project Linux-HA Japanメーリングリスト • ML登録用URL http://linux-ha.sourceforge.jp/ の「メーリングリスト」をクリック • MLアドレス linux-ha-japan@lists.sourceforge.jp 日本におけるHAクラスタについての活発な意見交換の場として 「Linux-HA Japan日本語メーリングリスト」 も開設しています。 Linux-HA-Japan MLでは、Pacemaker、Heartbeat3、Corosync DRBDなど、HAクラスタに関連する話題は歓迎! ※スパム防止のために、登録者以外の投稿は許可制です 44
  45. 45. 参考文献 Linux-HA Japan Project  Pacemaker 1.0 Configuration Explained  http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html-single/Pacemaker_Explained/  Colocation Explained  http://clusterlabs.org/doc/Colocation_Explained.pdf  リソースエージェント開発者ガイド  http://linux- ha.sourceforge.jp/wp/manual/ocf%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%A8%E3%83%B C%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E9%96%8B%E7%99%BA%E8%80%85%E3%82%AC% E3%82%A4%E3%83%89  DRBDユーザーズガイド  http://www.drbd.jp/users-guide/users-guide.html  DRBDアドバンスド・チュートリアル  http://linux-ha.sourceforge.jp/wp/wp-content/uploads/297249828379edfdf8963d9e8ef4c1c3.pdf  HAクラスタでPostgreSQLを高可用化(後編) ~ レプリケーション編 ~  http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf 45
  46. 46. 46Linux-HA Japan Project ご清聴ありがとうございました。 Linux-HA Japan 検索 http://linux-ha.sourceforge.jp/
  47. 47. 47 参考資料
  48. 48. 48 参考資料の目次  基本編  構成例とCRM設定例  中級編  Pacemaker起動から昇格までの流れ  Pacemaker+DRBD  Pacemaker+PostgreSQLレプリケーション  障害事例と復旧時の動作  Slave故障・復旧  Master故障・復旧  Master側で起動するprimitiveリソース故障  インターコネクトLAN故障  ネットワーク故障  Disk故障  上級編  Masterノードで起動するprimitiveリソースを考慮したスコア計算
  49. 49. 49 構成例とCRM設定例
  50. 50. 50 前提  Pacemaker+DRBDの構成例の設定についてのみ解説  Master Slaveに関する設定のみ解説  Pacemaker+PostgreSQLレプリケーションの設定については 下記URLに詳解有り  http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf  STONITHは未使用。STONITHについては下記URLに詳解有り。  http://sourceforge.jp/projects/linux- ha/docs/Pacemaker_OSC2013Kyoto_20130803/ja/1/Pacemaker_OSC2013Kyoto_20130803.pdf  http://linux-ha.sourceforge.jp/wp/wp-content/uploads/521492b28866dce52ea21dc3732ca9cf.swf  STONITHを使用しない・できない場合のスプリットブレイン防止策 についても割愛  スプリットブレイン防止策としてはVIPCHECKやoutdate-peer.sh(DRBDの場 合のみ)などが使用可能。ただしSTONITHほど信頼性は無い。
  51. 51. 51 Pacemaker+DRBDの構成例 node01 node02 ②DRBD (Slave) ①pingd ①diskd ④Filesystem ⑤VIP ⑥PostgreSQL ②DRBD (③Master化) Pacemaker NW監視 disk監視 Filesystem VIP PostgreSQL ①pingd ①diskd Pacemaker disk監視 NW監視  ①pingdとdiskdを起動後、②両系でDRBDを起動し、③node01で DRBDが昇格に成功したら、④~⑥Masterノード(node01)でprimitive リソースを起動する。この起動の流れになるようにCRM設定を行う。 grpPgsql grpPgsql ※番号は起動順序
  52. 52. 52 Pacemaker+DRBDのCRM設定例(Master Slave関連以外) primitive prmFilesystem ocf:heartbeat:Filesystem params fstype="ext4" device="/dev/drbd0" options="barrier=0" directory="/dbfp“ op start interval="0s" timeout="60s" on-fail="restart" op monitor interval="10s" timeout="60s" on-fail="restart" op stop interval="0s" timeout="60s" on-fail="fence" primitive prmVip ocf:heartbeat:IPaddr2 params ip="192.168.0.1" nic="eth0" cidr_netmask=“24" op start interval="0s" timeout="60s" on-fail="restart" op monitor interval="10s" timeout="60s" on-fail="restart" op stop interval="0s" timeout="60s" on-fail="block" primitive prmPostgreSQL ocf:pacemaker:Dummy params pgctl="/usr/pgsql-9.2/bin/pg_ctl" start_opt="-p 5432 -h 192.168.0.1" psql="/usr/pgsql-9.2/bin/psql“ pgdata="/dbfp/pgdata/data" pgdba="postgres" pgport="5432" pgdb="template1" op start interval="0s" timeout="60s" on-fail="restart" op monitor interval="10s" timeout="60s" on-fail="restart" op stop interval="0s" timeout="60s" on-fail=“block“ group grpPgsql prmFilesystem prmVip prmPostgreSQL primitive prmPingd ocf:pacemaker:pingd params name="default_ping_set" host_list="192.168.0.254" multiplier="100" op start interval="0s" timeout="60s" on-fail="restart" op monitor interval="10s" timeout="60s" on-fail="restart" op stop interval="0s" timeout="60s" on-fail="ignore" primitive prmDiskd ocf:pacemaker:diskd params name="diskcheck" device="/dev/vda" options="-e" interval="10" op start interval="0s" timeout="60s" on-fail="restart" op monitor interval="10s" timeout="60s" on-fail="restart" op stop interval="0s" timeout="60s" on-fail="ignore" clone clnPingd prmPingd meta clone-max="2" clone-node-max="1" clone clnDiskd prmDiskd meta clone-max="2" clone-node-max="1" Primitiveリソース ・Filesystem ・VIP ・PostgreSQL cloneリソース ・pingd ・diskd Primitiveリソース のグループ化 基本的な内容なので割愛。 groupのみ次のスライドで補足
  53. 53. 53 groupについて  まず3つのprimitiveリソースを定義し、以下を指定  RAの指定、RAに渡すオプション、各アクションの間隔、アクション失 敗時の動作  続いてprimitiveリソースをgrpPgsqlという名前でgroup化  Filesystem→VIP→PostgreSQLの順で起動し、逆順で停止  3つのリソースは同一ノードで起動 Filesystem VIP PostgreSQL ①Filesystem ②VIP ③PostgreSQL 起動時 停止時
  54. 54. 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スコア のところで説明済 ②配置・起動 順序制約 54
  55. 55. 55 ①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 ※
  56. 56.  ms要素には以下を設定  master-max  masterになれるリソース数(デフォルト値は1)  master-node-max  1つのノードでMasterになれるリソースの数(デフォルト値は1)  clone-max  生成するインスタンス数(デフォルト値はクラスタのノード数)  2ノード構成なら2を指定  clone-node-max  一つのノードで同時に起動するインスタンス数(デフォルト値は1)  notify  trueに設定すると、Master/Slaveリソースの各アクションの前後でnotifyアク ションが実行される。DRBD、PostgreSQLレプリケーションのRAともにnotify アクションを使用しているためtrueを選択する。 ms要素のmeta要素について master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify=true 56
  57. 57. 57 ②配置・起動順序制約 colocation rsc_col-1 inf: msDrbd clnPingd colocation rsc_col-2 inf: msDrbd clnDiskd order order-1 0: clnPingd msDrbd order order-2 0: clnDiskd msDrbd colocation col-3 inf: grpPgsql msDrbd:Master order order-3 0: msDrbd:promote grpPgsql:start ④Filesystem ⑤VIP ⑥PostgreSQL DRBD (③Master化) grpPgsql ①pingd ①diskd ②DRBD  pingd, diskdとDRBD間の制約  colocationによりpingd,diskdが起動しているノードでDRBDを起動  orderによりpingd,diskdが起動してからDRBDが起動  DRBDとリソースグループ(grpPgsql)間の制約  colocationによりDRBDがMasterに昇格するノードでgrpPgsql起動  orderによりDRBDがMasterに昇格してからgrpPgsql起動 orderとcolocationについては前回のOSC公演 資料で詳解しているのでそちらも参照下さい。 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/OSC2013TokyoFall.pdf
  58. 58. 58 colocationについて  概要:  リソースAとBを同一ノードまたは異なるノードに配置する設定  score:  リソースAとBを同じノードで起動させる場合はinfを指定  異なるノードで起動させる場合は-infを指定  役割:  Started, Master, Slaveから指定(デフォルトStarted)  例えばcolocation inf: A:Started B:Masterであれば、Master状態のリ ソースBと同じノードでリソースAを起動するという意味になる。 colocation <任意のID名> <score>: <リソースA>:<役割> <リソースB>:<役割>
  59. 59. orderについて order <任意のID名> <score>: <リソースA>:<アクション> <リソースB>:<アクション> [symmetrical=true|false]  概要:  リソースAが起動してからリソースBを起動するための設定  Score:  典型的な設定例は 0 or INF(デフォルトINF)  0の場合、リソースAの故障時にリソースBが影響を受けない。  infの場合、リソースAの故障時にリソースBも影響を受ける。  アクション  start, stop, promote, demoteから指定する。  例えば、A:promote B:startであれば、Aが昇格してからBを起動  Symmetrical設定  trueの場合、A:promote B:start設定時に、停止順序はB:stop → A:demote  falseの場合、起動順序はtrueの場合と同じだが、停止順序は各リソースを平行し て落とすため早く停止できる。停止順序が重要でない場合はフェイルオーバ時間 の短縮化のため、false設定を推奨 59
  60. 60. 60 Pacemakerと組み合わせる場合のDRBD設定例 global { usage-count no; } common { protocol C; startup { wfc-timeout 30; degr-wfc-timeout 15; outdated-wfc-timeout 15; } syncer { rate 40M; verify-alg sha1; csums-alg sha1; } handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger; halt -f"; } net { max-buffers 8192; ko-count 3; unplug-watermark 2048; cram-hmac-alg sha1; shared-secret password; } disk { on-io-error detach; fencing resource-only; no-disk-barrier; } } resource r0 { device minor 0; meta-disk internal; disk /dev/sda1; handlers { fence-peer "/usr/lib/drbd/crm-fence-peer.sh"; after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh"; } on node01 { address 10.0.1.1:7790; } on node02 { address 10.0.1.2:7790; } } crm-fence-peer.sh使用時は赤字の箇所を設定
  61. 61. 61 Pacemaker+PostgreSQLレプリケーションの構成例  Pacemaker+PostgreSQLレプリケーションは下記URL参照  http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf node01 node02 ②PostgreSQL (Slave) ①pingd ①diskd Pacemaker NW 監視 disk監視 ①pingd ①diskd Pacemaker disk監視 NW 監視 ※番号は起動順序 ②PostgreSQL (③Master化) ④vip-master (外部からの接続用IP) ④vip-rep (Slaveからの接続用IP) master-group vip-rep vip-master master-group
  62. 62. 62 Pacemaker+DRBD Pacemaker起動から昇格までの流れ はデータが新しい状態(UpToDate)を表すこととする。 はデータが無効状態(Outdated)を表すこととする。 新 無効
  63. 63. DRBD RAのデータ状態とMasterスコアの詳細  DRBD RAは、自ノードのロール(PrimaryかSecondaryか)と 確認したデータ状態に対応したMasterスコアをPacemakerに設定  対応表  Noの順に確認して最初に合致した条件のMasterスコアを設定 ※DRBD8.3.16のPKGに含まれるRAを使用した場合のデフォルト設定の例(ユーザによる変更も可能) 63 No ローカルノード 対向ノード Master スコア※ロール データ状態 データ状態 1 Secondary UpToDate DUnknown 1000 2 * UpToDate * 10000 3 * * UpToDate 10 4 * Consistent * 5 5 * * * 削除
  64. 64. DRBDのデータ状態の遷移(停止時)  起動時のスコアは前回停止時のデータ状態に依存するため、まずは停 止手順とその時のデータ状態から説明。次のスライドからは、本スライ ドの手順で停止した後に起動した時の動作を説明していく。  Secondary→Primaryの順に計画停止した場合のデータ状態の遷移  正常稼動時は両系がUpToDate/UpToDate の状態  Secondaryは計画停止時に自ノードをOutdatedとして停止  Primaryも対向がOutdatedとして停止したことを検知  Primary側を停止(両系は停止しているがデータ状態は保持) DRBD(Primary) UpToDate/UpToDate DRBD(Secondary) UpToDate/UpToDate DRBD(Primary) UpToDate/Outdated DRBD(停止) Outdated/DUnknown 新 新 新 無効 64 DRBD(停止) Outdated/DUnknown DRBD(停止) UpToDate/Outdated 新 64 無効
  65. 65. 65 起動時のpromotionスコアの計算例  node01は新、node02は無効の状態から両系を同時起動した場合  前スライドの対応表より、node01はUpToDate/UpToDateなので 10000、node02はOutdated/DunknownなのでMasterスコア削除  locationにはnode01に200、node02に100が設定されているとする  promotionスコアはnode01が10200、node02が100となる Pacemaker Pacemaker DRBD RA ②起動と データ新旧 の確認 DRBD(⑧Master化)新 ④Master スコア=10000 ①start ⑤10200 node01 node02 DRBD RA DRBD(Slave) ④Master スコア削除 ①start⑥ promote ⑦昇格 ③データ は新しい ②起動と データ新旧 の確認 ③データは無効 (古い可能性有) ⑤100 無効
  66. 66. 66 Pacemaker+PostgreSQLレプリケーション Pacemaker起動から昇格までの流れ はデータが新しい状態(Master側と同期接続中のSlave側)を表すこととする。 はデータが古い状態(非同期接続中、または切断中のSlave側)を表すこととする。 新 古
  67. 67. pgsql RAのデータ状態とMasterスコアの詳細  前述の通り、pgsql RAはpostgreSQLに対して確認した接続状態に応じて Masterスコアを設定するが、この時、データ状態についても設定している  データ状態は、Pacemaker停止時も保持されることから、次回起動 時に、前回停止直前のデータ状態が分かる仕組みになっている。 役割 接続状態 データ状態 Master スコア Master - LATEST 1000 Slave 同期 STREAMING|SYNC 100 Slave 非同期 STREAMING|ASYNC -INFINITY Slave 切断中 DISCONNECT -INFINITY 新 古 67
  68. 68. 典型的なPostgreSQLのデータ状態の例 PostgreSQL(Master) LATEST PostgreSQL(Slave) STREAMING|SYNC 同期接続 PostgreSQL(Master) LATEST PostgreSQL(停止) DISCONNECT切断 PostgreSQL(停止) LATEST PostgreSQL(停止) DISCONNECT 新 新 新 古 新  起動時のスコアは前回停止時のデータ状態に依存するため、まずは停 止手順とその時のデータ状態から説明。次のスライドからは、本スライド の手順で停止した後に起動した時の動作を説明していく。  Slave→Masterの順に計画停止した場合のデータ状態の遷移  正常稼動時は以下の状態  Master側のPacemaker (pgsql RA)がSlaveの切断を検知  Master側がSlave側のデータ状態をDISCONNECTに更新  Master側を停止 68 古
  69. 69. 69 起動時のpromotionスコアの計算例 その1  node01のデータ状態が新しくnode02が古い状態で同時起動(※)  locationにはnode01に200、node02に100が設定されているとする  start時点では両系のMasterスコアを-INFINITYにして昇格抑止 Pacemaker Pacemaker pgsql RA PostgreSQL node01 node02 pgsql RA ①start①start ②起動 ③状態確認 ④Slaveで 起動 ②起動 ③状態確認 ⑤Masterスコア = -INFINITY ④Slaveで 起動 ⑤Masterスコア = -INFINITY PostgreSQL ⑤-INFINITY ⑤-INFINITY ②非同期 接続 ※ここでは分かりやすいようにDRBDと手順をそろえて両系同時起動を行っているが、少なくともpgsql9.2以前のバージョンで同時起動 するにはrestart_on_promoteという特殊な設定が必要なため、片系ずつ起動することを推奨。具体的には、最新データを持つノードを片 系起動し、昇格したらデータをもう片系にコピーして、もう片系を起動する手順を推奨。詳細は下記URL参照 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf
  70. 70. 70 起動時のpromotionスコアの計算例 その2  monitor処理で前回停止時に保存したデータ状態を確認  node01は新しいデータを持つためMasterスコア=1000に更新  node01のpromotionスコアは1200(1000+200) ←昇格  node02のpromotionスコアはまだ-INFINITY(-INFINITY+100) Pacemaker Pacemaker pgsql RA PostgreSQL(⑪Master) pgsql RA PostgreSQL(Slave) ⑥ monitor ⑦データが 新しいこと を確認 ⑥ monitor ⑧Master スコア= 1000 ⑧1200 -INFINITY node01 node02 ⑦データが 古いことを 確認 ⑨ promote ⑩昇格 非同期 若干簡略化しているため、 厳密な動作は異なります。 ⑦両ノードとも新しいデータを持つ場合等は ここでデータ位置の比較等を実施 古新
  71. 71. 71 起動時のpromotionスコアの計算例 その3  Master昇格後のmonitor処理でPostgreSQLの接続状態確認  非同期接続中なのでMaster側がSlave側の状態を以下に更新  データ状態= STREAMING|ASYNC、Masterスコア= -INFINITY  その後、同期接続への切替処理を実施 Pacemaker Pacemaker pgsql RA PostgreSQL(Master) 1200 node01 node02 pgsql RA PostgreSQL(Slave) ⑫monitor ⑯同期接続に切替 ⑮-INFINITY ⑬接続状態 の確認 ⑭非同期 で接続中 ⑮古新 ⑯同期接続 ⑮Masterスコア=-INFINITY データ状態=STREAMING|ASYNC
  72. 72. 72 起動時のpromotionスコアの計算例 その4  次の周期のmonitor処理で再度、PostgreSQLの接続状態確認  同期接続に切替ったためMaster側がSlave側の状態を以下に更新  データ状態= STREAMING|SYNC、Masterスコア= 100  以降、 monitor毎に接続状態の確認を継続する。 Pacemaker Pacemaker pgsql RA PostgreSQL(Master) 1200 node01 node02 pgsql RA PostgreSQL(Slave) ⑰monitor ⑳200 ⑱接続状態 の確認 ⑲同期接続中 であることを確認 新 ⑳新 同期 ⑳Masterスコア=100 データ状態=STREAMING|SYNC
  73. 73. 73 障害事例と復旧時の動作 はデータが新しい状態、 はデータが古い状態、 は不整合な状態新 不整合古 単純化のため、locationは未設定とする
  74. 74. 74 Slave故障  Pacemaker+DRBD  node01のDRBDはnode02を切り離す  node02のデータ状態は障害発生時点で古くなる。  Pacemaker+PostgreSQLレプリケーション  node01のPostgreSQLはnode02を切り離す(非同期に設定変更)  node02のデータ状態は障害発生時点で古くなる。 DRBD(Master) node01 node02 Pacemaker DRBD(Slave) Pacemaker 10000 PostgreSQL(Master) node01 node02 Pacemaker PostgreSQL(Slave) Pacemaker 1000 新 古 新 古
  75. 75. Slave復旧(Pacemaker+DRBD)  Slave復旧時は自動的にクラスタに組み込む(DISK障害時を除く)  復旧時、世代識別子によりnode01のデータが新しいことを検知して 同期の方向を決定(node01からnode02に対する同期)。  その後、node02障害中にnode01に書き込まれたデータがDRBD のビットマップログにより特定され、差分同期される。  完了すると、node02のスコアは元の状態に戻る。 DRBD(Master) node01 node02 Pacemaker DRBD(Slave) Pacemaker 10000 ②10①差分同期 75 DRBD(Master) node01 node02 Pacemaker DRBD(Slave) Pacemaker 10000 ③10000 新 不整合※ 新 新 ※DRBDは差分同期の際に書き込み順序を保証しないこと から、同期中に同期先ノードにアクセスさせてはならない。
  76. 76. Slave復旧(Pacemaker+PostgreSQL)  Slave復旧時は自動的にクラスタに組み込む(DISK障害時を除く)(※)  障害中にMaster側に書き込まれた分のWALログが転送される。  完了して同期接続に戻ると、node02のpromotionスコアも元に戻る。 PostgreSQL(Master) node01 node02 Pacemaker PostgreSQL(Slave) Pacemaker 1000 -INFINITYWAL転送 新 古 PostgreSQL(Master) node01 node02 Pacemaker PostgreSQL(Slave) Pacemaker 1000 100 新 新 76 同期接続 ※長時間経過すると組み込まれない可能性有り。 その場合はwal-keep-segmentsを大きくする。
  77. 77. Master故障  Pacemaker+DRBD  ①node02のDRBD RAはMasterスコアを1000に更新  ②node02が昇格すると、再度Masterスコアを10000に更新  Pacemaker+PostgreSQLレプリケーション  ①障害時、node02のpromotionスコアは正の値(=100)なので昇格  ②昇格時、promotionスコアは1000となる。 node02 DRBD(Slave→②Master) Pacemaker node02 PostgreSQL(Slave→①Master) Pacemaker node01 DRBD(Master) Pacemaker node01 PostgreSQL(Master) Pacemaker 新古 新 古 10000 →①1000 →③10000 100 →②1000 node02と 不一致※ node02と 不一致※ ※Masterに書き込み中に突然落ちた場合、どちらか一方のノードのみに書き 込まれたデータが存在する可能性があるため、後で一致させる必要がある。
  78. 78. 78 Master復旧(Pacemaker+DRBD)  Master復旧時は自動的にクラスタに組み込む(DISK障害時を除く)  node01の障害中にnode02に書き込まれたデータはDRBDのビット マップログにより自動的に差分同期され、両系で不一致の可能性が あるブロックはDRBDのアクティビティログにより自動的に解消  同期が完了すると、両系のMasterスコアは10000に更新される。 DRBD(Slave) node01 node02 Pacemaker DRBD(Master) Pacemaker 10000 差分同期 不一致解消 10000 DRBD(Slave) node01 node02 Pacemaker DRBD(Master) Pacemaker 1000010 新 新新 古 node02と 不一致
  79. 79. 79 Master復旧(Pacemaker+PostgreSQL)  ①Master復旧前に以下の手順を手動で実施する必要有り  node02からnode01へのデータコピーによる不整合の解消  ロックファイル削除  手動手順の詳細は以下URLを参照  http://linux-ha.sourceforge.jp/wp/wp-content/uploads/b754c737d835c2546415009387407b7b.pdf  ②node01起動後、③同期処理が走る  ④完了後、Pacemakerにより非同期→同期接続に切り替えを行い、 Masterスコアを100に更新 PostgreSQL(Slave) node01 node02 Pacemaker PostgreSQL(Master) Pacemaker 1000④100 ①データコピー ①ロックファイル削除 ③WAL転送 ②起動
  80. 80. Master側で起動するprimitiveリソース故障(Pacemaker+DRBD)  下図は概要のみです。  本故障時のスコア計算の詳細は以下のページを参照して下さい。  resource-stickinessによりフェイルバックが防止される例 DRBD(Slave→⑤Master) Filesystem VIP PostgreSQL DRBD(Master→④Slave) Pacemaker Filesystem VIP PostgreSQL Pacemaker grpPgsql grpPgsql node01 node02 10000→ ③ 1 10000 ①故障 ⑥起動 ②grpPgsql停止 80
  81. 81. Master側で起動するprimitiveリソース故障(Pacemaker+PostgreSQL)  DRBDと同様に以下のページを参照して下さい(スコア計算の観点で はDRBDと同じですので、解説はDRBDのみ行っています。)  resource-stickinessによりフェイルバックが防止される例 PostgreSQL(Slave→⑤Master) vip-rep vip-master PostgreSQL(Master→④Slave※) Pacemaker Pacemaker master-group node01 node02 1000→ ③ 1 100 ①故障 ⑥起動 vip-rep vip-master master-group ②master-group停止 ※正確にはこの後、node01のPostgreSQLは停止する。理由については以下のページを参照。 「PostgreSQLレプリケーションとPacemakerの状態遷移」 81
  82. 82. 82 インターコネクトLAN障害(DRBD)  Pacemakerはスプリットブレイン状態のためnode02でpromote実行  DRBDは両系が昇格することを抑止する仕様  レプリケーションLANが生きているため、DRBDの上記抑止機能に よりnode02のDRBDのpromoteは失敗して、両系がMasterになる 状態は防がれる。 Pacemaker DRBD (Master) DRBD (Slave) Pacemaker 10000 10000 promote NG node01 node02
  83. 83. 83 インターコネクトLAN障害(PostgreSQLレプリケーション)  Pacemakerはスプリットブレイン状態のためnode02でpromote実行  PostgreSQLレプリケーションは両系をMasterに昇格可能  レプリケーションのセッションは切断される  node02は昇格し、両系がMasterの状態になってしまう。 Pacemaker PostgreSQL (Master) PostgreSQL (Slave→Master) Pacemaker 1000 100 Promote node01 node02
  84. 84. インターコネクトLAN障害 対策(PostgreSQLレプリケーション)  両系でMasterになることを防ぐため、STONITHの利用を推奨  STONITHについては説明済みのため割愛 Pacemaker PostgreSQL (Master) PostgreSQL (Slave) Pacemaker HW制御 ボード HW制御 ボード 電源OFF 両系Master状態は防がれる 84
  85. 85. サービス提供用ネットワーク故障  下記設定を前提  ping疎通NGの場合、rule条件を満たすため、promotionスコアを -INFINITYに更新し、フェイルオーバする。  $role=“master” 指定がある場合はpromotionスコアを更新  $role=“master” 指定が無い場合の例はDisk障害のスライドで説明 location rsc_loc-1 msDrbd rule $id=“loc-3” $role=“master” -inf: not_defined default_ping_set or default_ping_set lt 100 DRBD (Master→ ③Slave) DRBD (Slave→④Master)pingd ①ping疎通NG ②Promotionスコア更新 10000→ ②-INFINITY 10000 85
  86. 86. ディスク故障 DRBD (Master)diskd ①disk監視NG ②allocation スコア更新 ③サービス停止 DRBD (Slave→ ④ Master) ②-INFINITY  下記設定を前提  DISK監視NG時にrule条件を満たすため、allocationスコアを-INFINITY に更新し、フェイルオーバする  allocationスコア(後述)が-INFINITYになると、DRBDを停止する location rsc_loc-1 msDrbd rule $id="loc-4" -inf: not_defined diskcheck or diskcheck eq ERROR 10000 86
  87. 87. 87 Masterノードで起動する primitiveリソースを考慮した スコア計算 Pacemakerとの組み合わせが前提のため、図にはpacemakerを記載しないこととする。 MSリソースの解説では前述のPacemaker+DRBDのCRM設定時を前提とする。 また、locationにはnode01に200、node02に100が設定されているとする
  88. 88. 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 88 allocationスコアは 上記の記号で表す。 数値 起動 停止
  89. 89. 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" 89 node02node01 primitive 400 89 primitive primitive 100
  90. 90. resource-stickinessの目的はフェイルバック防止  primitive故障時はallocationスコアが-INFINITYに更新  allocationスコアがマイナスのノードではリソースは起動しない  フェイルオーバしてnode02でprimitive起動(resource-stickiness加算)  node01の故障回復および故障フラグのクリア  node02のallocationスコアが大きいためフェイルバックしない node02node01 100-INFINITY primitive 100(location) + 200(resource-stickiness) 故障 node02node01 300 primitive故障 primitive -INFINITY node02node01 300 primitive primitive 200 90 primitive
  91. 91. MSリソース(resource-stickiness=200設定時)の場合の例  通常時はnode01を優先するためにlocation設定を行っているとする  node01の故障によりフェイルオーバしてnode02のDRBDが昇格  node01の故障回復および故障フラグのクリア(元のスコア値に戻る)  node01のpromotionスコアが大きいためフェイルバック  MSリソースのみの場合、resource-stickinessの効果は無い node02node01 10200 91 DRBD(Master) DRBD(Slave) 10100 node02node01 10200 DRBD DRBD(Slave→Master) 10100-INFINITY 故障 node02node01 10200 DRBD(Slave→Master) DRBD(Master→Slave) 10100
  92. 92. MSリソースのスコアにresource-stickinessが加算される場合①  MSリソースとcolocationを設定しているprimitiveリソースがある場合  promotionスコア=locationで指定した値+Masterスコア +colocation制約を設定しているprimitiveリソースのallocationスコア  下記の設定がある場合、grpPgsqlが起動すると、grpPgsqlのallocationスコアを msDrbdのpromotionスコアに加算  grpPgsqlのallocationスコア=location設定値+resource-stickiness  通常、primitiveをMSリソースと組み合わせる場合にはprimitiveのlocationは設 定しないため、grpPgsqlのallocationスコア=resource-stickinessと考えてよい。 grpPgsql msDrbd(Master) promotionスコア allocationスコア colocation colocation col-3 inf: grpPgsql msDrbd:Master 加算 92
  93. 93. 93 MSリソースのスコアにresource-stickinessが加算される場合②  grpPgsqlが起動すると、resource-stickinessがgrpPgsqlのallocationス コアに加算され、DRBDのpromotionスコアにも加算される  grpPgsqlが3つのリソースの場合の加算例(前述の設定のケース)  resource-stickiness(ここでは200を設定) * 3 = 600  加算時に「:Master」のあるcolocationの行数+1をかける(1行なら2) Filesystem VIP PostgreSQL grpPgsql 200 200 200 ③ 200×3×2 =1200 を加算 DRBD (Master) 10200 11400 colocation col-3 inf: grpPgsql msDrbd:Master DRBD(Master) DRBD(Slave) grpPgsqlスコア加算 grpPgsql
  94. 94. resource-stickinessによりフェイルバックが防止される例  Primitiveリソース障害時、MSリソースのpromotionスコアは1に下がる  フェイルオーバしてnode02のPromotionスコアが11300になる  node01の復旧および故障フラグのクリア後もフェイルバックしない grpPgsql DRBD (Master→④Slave DRBD (Slave→⑤Master)11400 →③ 1 ①-INFINITY①故障 10100→ ⑨11300 ⑥grpPgsql起動 ⑦1200 ⑧加算 node01 node02 ②加算 DRBD(Slave) DRBD(Master)②10200 ①故障フラグクリア grpPgsql node01 node02 11300 -INFINITY grpPgsql 94
  95. 95. 95 resource-stickiness設定指針(DRBDの場合)  DRBD RAが設定するMasterスコアの変動によりフェイルオーバさせる にはresource-stickinessに小さい値を設定(推奨値は200)  resource-stickinessを小さい値にすることで、Master側DRBDが検 知するデータ状態の悪化によりRAがMasterスコアを下げた時、 promotionスコアがSlave側のMasterスコアを下回り、フェイルオー バを発生させることが可能となる。  以下は前述のresource-stickiness値=200、3リソース構成の例 (1200が加算) resource-stickiness=200の場合 正常時 DRBD異常検知時 Master Slave Master Slave location 200 100 200 100 DRBD RAが設定するMasterスコア 10000 10000 10 10000 resource-stickiness 1200 0 1200 0 Promotionスコア 11400 10100 1410 10100
  96. 96. resource-stickinessが有効な事例  DRBDはDisk障害を検知するとDiskless状態(※)になり、対向のDRBD に書き込むことで処理を継続しようとする(下図の例)  このような状態の時はフェイルオーバさせた方が望ましい  PacemakerはDisklessを検出してMasterスコアを10000から10に変更  この時、resource-stickinessが小さければ、node01のpromotionス コアがnode02を下回り、フェイルオーバする  resource-stickinessが大きな値の場合、DRBDのMasterスコアが 下がってもフェイルオーバしない可能性があるため要注意 DRBD(Master) node01 node02 Pacemaker DRBD(Slave) Pacemaker Diskless/UpToDate Masterスコアを 10000→10に減らすgrpPgsql1200 11400 →1410 10100 この後、1410<10100でnode02にフェイルオーバ ※DRBDにon-io-error detachの設定がある場合の動作。 96
  97. 97. 97 resource-stickiness設定指針(PostgreSQLの場合)  Master側は故障でない限り常に1000、Slave側は100~-INFINITY  Master側のMasterスコアは常に1000であり、Slave側はそれ以下 の値に制御される。  Pgsql RAは、DRBD RAのようにMaster側のMasterスコアを下 げることはしない  よって、PostgreSQLレプリケーション構成の場合はresource- stickinessをチューニングしても特に意味は無い resource-stickiness=INFINITYの場合 Master Slave location 200 100 pgsql RAが設定するMasterスコア値 1000 100 resource-stickiness INFINITY 0 promotionスコア INFINITY 200
  98. 98. 98 補足資料
  99. 99. 99 古いデータを持つ 昇格抑止中のノードを 強制的に昇格する方法
  100. 100. レプリケーションLAN切断後のMaster障害からの復旧方法  レプリケーションLAN切断後、Master障害が発生した場合、Slave側は 昇格抑止状態になる (DRBDの場合はfence-peer設定時)ため、サー ビスが停止する。  Master側がディスク故障等により新しいデータで復旧させることができ ない場合、Slave側は古いデータであるが、昇格させる必要がある。こ の時は次のスライドの手順で昇格させる。 MS (Master) PacemakerPacemaker MS (Slave) -INFINITY 100 故障 昇格抑止中
  101. 101. Slave側での制約解除コマンドについて(DRBD) [root@node02 ~]# grep "drbd-fence-by-handler" /var/lib/heartbeat/crm/cib.xml <rsc_location rsc="msDrbd" id="drbd-fence-by-handler-r0-msDrbd">  以下のコマンドで赤字部分を確認  location制約の削除  上で確認した赤字部分を以下の赤字部分に入れて、コマンド実行 [root@node02 ~]# ptest -sL | grep promotion prmDrbd:0 promotion score on none: 0 prmDrbd:1 promotion score on node02: -1000000 ★この時点で昇格抑止状態 [root@node02 ~]# cibadmin -D -X '<rsc_location rsc="msDrbd" id="drbd-fence-by- handler-r0-msDrbd">‘ [root@node02 ~]# ptest -sL | grep promotion prmDrbd:1 promotion score on node02: 1100 ★制約が解除されたのでこの後、昇格 prmDrbd:0 promotion score on none: 0 101
  102. 102. Slave側での制約解除コマンドについて(PostgreSQL)  属性値の修正  pgsql-data-statusをDISCONNECTからLATESTに変更  PacemakerがSlaveのデータ状態を確認後、昇格する [root@node02 ~]# ptest -sL | grep promotion pgsql:1 promotion score on none: 0 pgsql:0 promotion score on node02: -1000000 ★この時点で昇格抑止状態 [root@node02 ~]# crm_attribute -l forever -N ノード名 -n "pgsql-data-status" -v "LATEST" ★ノード名はSlaveのホスト名に応じて変更する 102
  103. 103. 103 状態遷移について
  104. 104. 104 DRBDとPacemakerの状態遷移 STOP Secondary Start Stop Primary drbdadm primary r0 drbdadm secondary r0 STOP Slave Start Stop Master promote demote  PacemakerはSlaveを経由してMasterになる。  Master状態から停止する時は、Slaveを経由する。  DRBDも同じ仕様であり、両者の状態遷移は一致。
  105. 105. 105 PostgreSQLレプリケーションとPacemakerの状態遷移 start promote stop demote Slave MasterSTOP × 停止(Slaveへの降格はできない) recovery.conf なしで起動 停止 pg_ctl promote recovery.conf ありで起動  PostgreSQLはMaster起動するのに直接・Slave経由の両方可能  Pacemaker制御時はSlaveを経由して起動  Masterからの停止時、 PostgreSQLはSlaveに降格できない  demote処理で停止する仕様 STOP Slave Master

×