Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

25,216 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
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes.........ACCESS WEBSITE Over for All Ebooks ..... (Unlimited) ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • ACCESS that WEBSITE Over for All Ebooks (Unlimited) ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... DOWNLOAD FULL EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M }
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • ..............ACCESS that WEBSITE Over for All Ebooks ................ ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Full EPUB Ebook here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://urlzs.com/UABbn } ......................................................................................................................... Download Full EPUB Ebook here { https://urlzs.com/UABbn } ......................................................................................................................... ...................................ALL FOR EBOOKS................................................. Cookbooks, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

×