自己紹介名前所属飯田雄介 ( いいだゆうすけ ) 主な活動 Linux-HA Japan プロジェクト Pacemaker 本体の機能改善や外部ツールの開発を行っています Linux-HA Japan から pm_logconv や pm_crmgen といったツールを提供しています 2

Size: px

Start display at page:

Download "自己紹介名前所属飯田雄介 ( いいだゆうすけ ) 主な活動 Linux-HA Japan プロジェクト Pacemaker 本体の機能改善や外部ツールの開発を行っています Linux-HA Japan から pm_logconv や pm_crmgen といったツールを提供しています 2"

えりかたなせ
5 years ago
Views:

1 試して覚える Pacemaker 入門排他制御編オープンソースカンファレンス 2015 Tokyo/Fall LinuxHA-Japan 飯田雄介

2 自己紹介名前所属飯田雄介 ( いいだゆうすけ ) 主な活動 Linux-HA Japan プロジェクト Pacemaker 本体の機能改善や外部ツールの開発を行っています Linux-HA Japan から pm_logconv や pm_crmgen といったツールを提供しています 2

3 本日のおはなし高可用 (HA) クラスタにとって重要な機能の一つである排他制御機能についてその重要性やデモを通して実際どのように動くのかを解説していきます話題 Pacemaker とは? なぜクラスタには排他制御が必要なのか? Pacemaker の排他制御機能を紹介デモを使った STONITH の実演 3

4 そもそも Pacemaker を知らない人のために 4

5 Pacemaker とは? Pacemaker( ぺーすめーかー ) とはオープンソースで開発されている高可用クラスタソフトウェアのことです Pacemaker は障害が発生するとそれを検知し自動的にサービスをフェイルオーバすることでシステムの可用性を高めてくれます 5

6 Pacemaker によるフェイルオーバのイメージ ( 故障発生時 ) server01(active) server02(standby) サービスに障害が発生故障検知監視インターコネクト PostgreSQL mount DB 6

7 Pacemaker によるフェイルオーバのイメージ ( フェイルオーバ後 ) server01(standby) server02(active) ノード切り替え停止インターコネクト起動 PostgreSQL PostgreSQL DB Pacemakerは障害を検知しサービスを自動的に他のノードに切り替えます HAクラスタでは一般的にこの動きをフェイルオーバと呼びます mount 7

8 サービスが継続できなくなる 2 つの障害 HA クラスタには発生するとサービス継続不能に陥ってしまう致命的な 2 つの障害が存在します 1. スプリットブレイン 2. リソースの停止故障これらこれら2 2つの障害からクラスタを救うためにはつの障害からクラスタを救うために排他制御機能が必排他制御機能が必要となります!! 8

9 スプリットブレインとは? どんな障害なのか? クラスタを組んでいるノード間をつなぐインターコネクト通信が全て切断されてお互いの状態が把握できなくなった Pacemaker がそれぞれのノードでリソースを起動し始めてしまう状態のことですクラスタはどうなってしまう? それぞれのノードで起動したリソースが2 重で書き込みを行うことでデータが破壊されてしまいサービスが復旧不可能な状態にこの時例えば2 重書き込みによりデータが破壊されサービスなってしまいますが復旧不可能な状態に陥る危険があります 9

10 スプリットブレインによるサービス停止のイメージ server01(active) server02(standby) 1server02 の応答がなくなった! 1server01 の応答がなくなった! インターコネクトリソース起動! Filesystem pgsql Filesystem pgsql 2 リソースを起動しなきゃ! write write mount DB mount 32 重に書き込みが行われることによりデータが破壊されてしまう! 10

11 リソースの停止故障とは? どんな障害なのか? Pacemaker が管理しているリソースが停止できなくなってしまった状態のことです例えばプロセスの書き込みが継続して行われているため共有ディスクをアンマウントすることができない状態などクラスタはどうなってしまう? 停止に失敗したリソースはどのノードにもフェイルオーバすることができないためサービスが継続不可能な状態となってしまいます 11

12 リソース停止故障によるサービス停止のイメージ server01(active) server02(standby) PostgreSQL プロセスがハングして停止できない! インターコネクト Filesystem pgsql フェイルオーバできない! リソースの停止に失敗すると Standby 側でリソースを起動することができなくなりサービス停止となります mount DB 12

13 もう一度念押しこれらの障害が発生した時にリソースの重複起動やサーこれらの障害が発生した時にリソースの重複起動やビス停止を防ぐために排他制御機能が必要です! サービス停止を防ぐために排他制御機能が必要です 13

14 Pacemaker の備える排他制御機能を紹介 14

15 Pacemaker の備える排他制御機能 Pacemaker では次に挙げる 3 つの排他制御機能を使用することができます 1. STONITH( 読み : すとにす ) ノードの電源操作を行う排他制御機能 2. SFEX( 読み : えすえふいーえっくす ) 共有ディスクを使った排他制御機能 3. VIPcheck( 読み : びっぷちぇっく ) 仮想 IP を使った排他制御機能 15

16 排他制御機能の対応範囲下記は各排他制御機能と障害発生時のサービス継続性を表す対応表です : サービス継続可能 : サービス継続不可能 STONITH は障害に対する対応範囲が最も広い! 障害パターン排他制御なし STONITH SFEX VIPcheck スプリットブレインリソースの停止故障 16

17 STONITH について紹介 17

18 STONITH とは? STONITH とは制御が利かなくなったノードの電源を強制的に停止してクラスタから強制的に離脱 (Fencing) させる機能のことです下記の英文の頭文字を取って作られています Shoot-The-Other-Node-In-The-Head 18

19 STONITH プラグイン Pacemaker には環境に合わせて使える様々な STONITH プラグインが標準装備されています目的プラグイン名サーバに搭載されている電源管理デバイスに合わせて使い分けてくださいフェンシング ( 電源断 ) 制御 ipmi (IPMI デバイス用 ) libvirt (KVM,Xen 等仮想マシン制御用 ) ec2(amazonec2 用 ) などなどサーバ生死確認相撃ち防止 stonith-helper 19

20 STONITH による排他制御のイメージ ( スプリットブレイン時 ) server01(active) server02(standby) 1server02 の応答がなくなった! 1server01 の応答がなくなった! Filesystem インターコネクト 2server02 の状態がわからないから再起動して Clean な状態にしよう! pgsql STONITH プラグイン強制停止 ( 再起動 ) STONITH プラグイン電源管理デバイス電源管理デバイス mount DB 20

21 STONITH による排他制御のイメージ ( リソース停止故障 ) server01(active) server02(standby) 1PostgreSQL プロセスがハングして停止できない! Filesystem インターコネクト 2server01 を再起動すればリソースが停止するからフェイルオーバできる! pgsql STONITH プラグイン電源管理デバイス強制停止 ( 再起動 ) 電源管理デバイス STONITH プラグイン mount DB 21

22 STONITH の相撃ち問題 22

23 STONITH の相撃ちという問題ノードの電源を強制的に停止させることでリソースを安全にフェイルオーバさせる STONITH ですが STONITH には一つ弱点がありますそれはスプリットブレインになった時お互いのノードが STONITH を実行し合い相撃ちが起こってしまうということですこの問題は stonith-helper という STONITH の補助プラグインを使うことで対処することができます 23

24 STONITH 相撃ちのイメージ Heartbeat 通信対向ノードの OFFLINE を検知サービス停止 server01 (Active)! STONITH ( 電源操作 ) を実行 server01 再起動インターコネクト通信断 server02 (Standby)! STONITH ( 電源操作 ) を実行 server02 再起動対向ノードの OFFLINE を検知 24

25 stonith-helper による相撃ち阻止のイメージ Heartbeat 通信対向ノードの OFFLINE を検知 PGSQL が動いているので次のプラグインへ停止を免れた! server01 (Active)! STONITH (stonith-helper) を実行 STONITH ( 電源操作 ) を実行インターコネクト通信断 server02 (Standby)! STONITH (stonith-helper) を実行 sleep server02 再起動対向ノードの OFFLINE を検知 PGSQL が動いていないので sleep して待機 stonith-heper は自身が Active ノードであるかをチェックし STONITH の実行タイミングをずらすことで相撃ちを回避します 25

26 STONITH が使えない環境での排他制御方法サーバが電源管理デバイスを備えていないなど STONITH を使うことができない環境の場合リソースの停止故障には対応できませんが環境に合わせて次の排他制御機能を使うことができます機能名機能使用要件 SFEX 共有ディスクを使った排他制御共有ディスクを使っている構成で使用可能 VIPcheck 仮想 IP を使った排他制御仮想 IP を使っている構成で使用可能 26

27 SFEX による排他制御のイメージ起動中の SFEX は定期的にディスク確保用のフラグを更新しますスプリットブレインが発生すると server02 の SFEX が起動されるがディスクを確保できず起動失敗となります sfex インターコネクト sfex 起動順 1 Filesystem Filesystem 起動順 2 pgsql pgsql 起動順 3 server01 が所有 server01(active) sfex パーティション sfexが起動に失敗するため後続のリソースは起動されないよって2 重起動は防止されます server02(standby) 27

28 VIPcheck による排他制御のイメージサービス LAN ping を使って仮想 IP が割り当て済みか確認します仮想 IP VIPcheck は仮想 IP が他のノードに割り当てられていることを確認し起動失敗となります VIPcheck インターコネクト VIPcheck 起動順 1 IPaddr2 IPaddr2 起動順 2 server01(active) VIPcheckが起動に失敗するため後続のリソースは起動されないよって2 重起動は server02(standby) 防止されます 28

29 STONITH の使い方 29

30 リソース定義ファイルの設定 STONITH を使用するためにはリソース定義ファイルに次に挙げる設定を行います STONITH 機能の有効化設定 STONITH プラグインの設定 STONITH プラグインの実行順序設定リソース停止故障時に STONITH を発動させる設定リソース定義ファイルとは Pacemakerに管理させるサービスのリソース定義ファイルとは Pacemakerに管理させるサービスの情報やクラスタ全体の設定を行うファイルのことです情報やクラスタ全体の設定を行うファイルのことです 30

31 STONITH 機能の有効化設定 STONITH 機能を有効化するためリソース定義ファイルに下記の設定を行います property \ no-quorum-policy="ignore" \ stonith-enabled="true" \ startup-fencing="false" STONITH を有効にする場合 true を設定します STONITH 機能はデフォルトで有効になっています無効にしたい場合は "false" を設定します 31

32 STONITH プラグインの設定 STONITH プラグインに関する設定もリソース定義ファイルに設定します下記に物理マシン環境で一般的に使用される ipmi プラグインの設定例を提示します primitive prmipmi stonith:external/ipmi \ params \ hostname=server01 \ ipaddr= \ userid=userid \ passwd=passw0rd \ interface=lanplus \ op start interval="0s" timeout="60s" on-fail=restart \ op monitor interval="3600s" timeout="60s" on-fail=restart \ op stop interval="0s" timeout="60s" on-fail=ignore 使用するプラグインの種類を設定しますプラグインの実体は下記のディレクトリに存在します /usr/lib64/stonith/plugins/external/ プラグインのパラメータを設定しますプラグインのオペレーションを設定します 32

33 プラグインのパラメータ解説 (ipmi) 下記は ipmi プラグインに設定するパラメータの解説ですパラメータ名 hostname ipaddr userid passwd interface 意味このプラグインを使って STONITHする対象のホスト名を指定します STONITH 対象のノードに搭載されている IPMIデバイスのIPを指定します IPMIデバイスにログインするためのユーザ IDを指定します IPMIデバイスにログインするためのパスワードを指定します使用するIPMIインタフェースを指定します 33

34 プラグインのパラメータ解説 (stonith-helper) 今回のデモで使う stonith-helper プラグインのパラメータですパラメータ名 pcmk_reboot_retries hostlist dead_check_target standby_check_command run_online_check 意味プラグインが reboot 処理に失敗した時にやり直す回数を指定しますこのプラグインを使って STONITH する対象のホスト名を指定します対象ノードの電源が完全に落ちている事を確認するための設定ノードに割り当てられている IP を全て指定します相撃ち回避用の設定スプリットブレインになった時自ノードが Active ノードであると判定するためのコマンドを設定しますコマンドのリターンコードが "0" なら自ノードを Active と判定します Standby だと判定されたノードは一定時間 sleep を実行して STONITH されるのを待ちますスプリットブレイン時以外では相撃ち回避処理を実行する必要はありません "yes" を設定することでスプリットブレイン時以外では相撃ち回避用の sleep が実行されなくなります 34

35 プラグインのパラメータ解説 (libvirt) 同じくデモで使用している libvirt プラグインのパラメータですパラメータ名 hostlist hypervisor_uri 意味このプラグインを使って STONITH する対象のホスト名を指定します仮想マシンが起動しているホストマシンのアドレスを指定します 35

36 STONITH プラグインの実行順序設定 STONITH プラグインを複数設定した場合下記の設定を行うことでプラグインを実行する順番を制御することができますプラグインの実行に失敗した場合次に指定したプラグインが実行されるという動きになります fencing_topology \ server01: prmhelper1-1 prmlibvirt1-2 \ server02: prmhelper2-1 prmlibvirt2-2 STONITH 対象のノード名を指定します STONITH プラグインのリソース ID をスペース区切りで指定します指定したプラグインは左から順番に実行されますここでは stonith-helper libvirt の順番で実行されるように設定しています 36

37 リソース停止故障時に STONITH を発動させる設定リソース停止故障時に STONITH を発動させるには下記のようにリソースの op に on-fail の設定を行います primitive prmdb ocf:heartbeat:pgsql \ params \ pgctl="/usr/pgsql-9.4/bin/pg_ctl" \ psql="/usr/pgsql-9.4/bin/psql" \ pgdata="/pgsqldb/data" \ start_opt="-p 5432" \ pgdba="postgres" \ pgport="5432" \ pgdb="template1" \ op start interval="0s" timeout="120s" on-fail="restart" \ op monitor interval="30s" timeout="30s" on-fail="restart" \ op stop interval="0s" timeout="120s" on-fail="fence" オペレーション失敗時に STONITH を実行させるには "fence" を設定します STONITH を無効にしている環境では block を設定しましょう 37

38 デモ環境の説明と準備 38

39 デモ環境についてデモ環境には仮想マシンを 2 台使います OS は CentOS7.1 を使用します Pacemaker がインストールしてあります Trac サービスが Active/Standby で動作する環境を構築してあります 39

40 デモ環境で使うリソースデモ環境では次に挙げるものをリソース化して管理していますサービスリソース apache pgsql IPaddr2 ( 仮想 IPの管理 ) Filesystem ( マウントの管理 ) 監視リソース ping( ネットワークを監視するリソース ) diskd( ディスクを監視するリソース ) STONITH プラグイン stonith-helper(stonithの動作を補助するプラグイン ) libvirt(kvmなどの仮想マシンを再起動させるプラグイン ) STONITH による相撃ちを回避するため stonith-helper を使用します今回のデモは仮想環境で行うため電源操作プラグインに libvirt を使用します 40

41 デモ環境のイメージ WEB アクセスインターネットサービス LAN サービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 eth3 仮想 IP eth1 eth2 mount インターコネクト 1 インターコネクト 2 eth3 eth1 eth2 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt STONITH リソース stonith-helper libvirt server01(active) eth0 PostgreSQL DB eth0 server02(standby) Hypervisor(KVM) 運用 LAN 41

42 ではクラスタを起動していきましょう 42

43 まずサービスが動いていないことを確認下記のアドレスにアクセスしてまだサービスが動いていないことを確認します 43

44 クラスタを起動する以下のコマンドを実行してクラスタを起動します CentOS6 向け # initctl start pacemaker.combined CentOS7 向け # systemctl start pacemaker クラスタを停止するコマンドはこちら CentOS6 向け # initctl stop pacemaker.combined CentOS7 向け # systemctl stop pacemaker 44

45 リソース定義をクラスタに読み込ませる crm コマンドを実行してクラスタにリソース定義ファイルを読み込ませます crm コマンドは Pacemaker クラスタを操作する運用管理コマンドです # crm configure load update osc2015.crm リソース定義ファイル 45

46 クラスタの状態を確認するクラスタの状態は crm_mon コマンドで確認します # ssh server01 "crm_mon -fda1" Online: [ server01 server02 ] Resource Group: grpstonith1 prmhelper1-1 (stonith:external/stonith-helper): Started server02 prmlibvirt1-2 (stonith:external/libvirt): Started server02 Resource Group: grpstonith2 prmhelper2-1 (stonith:external/stonith-helper): Started server01 prmlibvirt2-2 (stonith:external/libvirt): Started server01 Resource Group: grptrac prmfs (ocf::heartbeat:filesystem): Started server01 prmvip (ocf::heartbeat:ipaddr2): Started server01 prmdb (ocf::heartbeat:pgsql): Started server01 prmweb (ocf::heartbeat:apache): Started server01 Clone Set: clndiskd1 [prmdiskd1] Started: [ server01 server02 ] Clone Set: clndiskd2 [prmdiskd2] Started: [ server01 server02 ] Clone Set: clnping [prmping] Started: [ server01 server02 ] サービスが server01 上で Started 状態になっていることを確認します ( 省略 ) 46

47 サービスが起動できたことを確認してみよう WEB ブラウザを起動して下記アドレスにアクセスします Trac に接続できたら無事起動完了ですこの IP はリソース定義の IPaddr2 リソースに設定した仮想 IP です 47

48 デモ環境が整ったところで STONITH の動きを体験してみましょう! 48

49 今回のデモ内容今回のデモでは次に挙げる障害が発生した時に STONITH によって排他制御が行われてサービスが継続できることを確認します 1. スプリットブレイン 2. リソース停止故障 49

50 スプリットブレイン 50

51 スプリットブレインによる STONITH 実行デモ server01 と server02 をつなぐインターコネクトが切れてスプリットブレインとなる障害のデモを行いますデモ環境は仮想マシンを使用しているためホスト側でインターコネクトを通している Bridge インターフェイスを停止させ擬似的に故障を発生させます ( ホスト )# ifdown br2 ( ホスト )# ifdown br3 51

52 デモの流れと注目ポイントこのデモで注目してもらいたいポイントはココ! スプリットブレイン発生後 STONITH により server02 が再起動されるところデモの流れ 1. ホストマシンのブリッジを停止 ( 擬似故障 ) 2. server01とserver02でお互いのノードの状態がわからなくなる 3. server01とserver02でstonith-helperが実行される 3-1. server01はpgsqlが動いているのですぐ次のlibvirtプラグインを実行 3-2. server02はpgsqlが動いていないので sleepを実行しstonithされるのを待つ 4. server01からlibvirtプラグインが実行されserver02が再起動 5. サービスはserver01で継続される 52

53 スプリットブレイン時の動作 ( 故障発生時 ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt eth3 仮想 IP server02 の応答がなくなった! eth1 eth2 mount インターコネクト 1 断インターコネクト 2 eth3 eth1 eth2 server01 の応答がなくなった! 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt server01(active) eth0 PostgreSQL DB eth0 server02(standby) Hypervisor(KVM) 運用 LAN 53

54 スプリットブレイン時の動作 (stonith-helper プラグインを実行 ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 eth3 仮想 IP eth1 eth2 mount インターコネクト 1 断インターコネクト 2 eth3 eth1 eth2 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt pgsql が動いているかチェック pgsql が動いているかチェック STONITH リソース stonith-helper libvirt server01(active) eth0 PostgreSQL DB eth0 server02(standby) Hypervisor(KVM) 運用 LAN 54

55 スプリットブレイン時の動作 (libivrt プラグインを実行 ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 eth3 仮想 IP eth1 eth2 mount インターコネクト 1 断インターコネクト 2 eth3 eth1 eth2 sleep 中... 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt Hypervisor を介して libvirt プラグインが server02 を再起動させます STONITH リソース stonith-helper libvirt server01(active) eth0 PostgreSQL DB eth0 server02(standby) Hypervisor(KVM) 運用 LAN 55

56 スプリットブレイン時の動作 (STONITH 完了後 ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt eth3 仮想 IP eth1 eth2 サービスはserver01 mount で継続されますインターコネクト 1 インターコネクト 2 eth3 eth1 eth2 server01(active) eth0 PostgreSQL DB eth0 server02(offline) Hypervisor(KVM) 運用 LAN 56

57 スプリットブレインによる STONITH 完了後のクラスタ状態 # ssh server01 "crm_mon -fda1" Online: [ server01 ] OFFLINE: [ server02 ] Resource Group: grpstonith2 prmhelper2-1 (stonith:external/stonith-helper): Started server01 prmlibvirt2-2 (stonith:external/libvirt): Started server01 Resource Group: grptrac prmfs (ocf::heartbeat:filesystem): Started server01 prmvip (ocf::heartbeat:ipaddr2): Started server01 prmdb (ocf::heartbeat:pgsql): Started server01 prmweb (ocf::heartbeat:apache): Started server01 Clone Set: clndiskd1 [prmdiskd1] Started: [ server01 ] Stopped: [ server02 ] Clone Set: clndiskd2 [prmdiskd2] Started: [ server01 ] Stopped: [ server02 ] Clone Set: clnping [prmping] Started: [ server01 ] Stopped: [ server02 ] ( 省略 ) STONITH 完了後 STONITH が実行されたノードは Pacemaker が止まるため OFFLINE となりますサービスは server01 上で動き続けます 57

58 リソース停止故障 58

59 リソース停止故障による STONITH 実行デモ今回のデモでは server01 で PostgreSQL プロセスを擬似的に停止させてリソースの停止故障を発生させます講演時間の関係上デモを円滑にすすめるため pgsql の stop タイムアウト値を短め (20s) に設定しています (server01)# pkill -STOP postgres 59

60 デモの流れと注目ポイントこのデモで注目してもらいたいポイントはココ! リソース停止故障を起こした server01 が STONITH により再起動されるところデモの流れ 1. pgsqlプロセスをsigstop( 擬似故障 ) 2. pgsqlraでmonitorタイムアウト発生 3. pgsqlをstop 開始 4. pgsqlraでstopタイムアウト発生 5. stopオペレーションのon-fail=fence 設定に従い server01をstonith( 再起動 ) 6. server01のstonith 完了後サービスはserver02にフェイルオーバ 60

61 リソース停止故障時の動作 ( 故障発生時 ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 eth3 仮想 IP eth1 eth2 mount インターコネクト 1 インターコネクト 2 eth3 eth1 eth2 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt server01(active) pgsqlのmonitorオペレーションがタイムアウトします eth0 PostgreSQL DB eth0 STONITH リソース stonith-helper libvirt server02(standby) Hypervisor(KVM) 運用 LAN 61

62 リソース停止故障時の動作 (pgsql リソースの停止タイムアウト ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 eth3 仮想 IP eth1 eth2 mount インターコネクト 1 インターコネクト 2 eth3 eth1 eth2 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt server01(active) pgsql リソースを stop しようとするがこのオペレーションもタイムアウトしま eth0 す PostgreSQL DB eth0 STONITH リソース stonith-helper libvirt server02(standby) Hypervisor(KVM) 運用 LAN 62

63 リソース停止故障時の動作 (libivrt プラグインを実行 ) サービス LAN WEB アクセスインターネットサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt eth3 仮想 IP eth1 eth2 mount インターコネクト 1 インターコネクト 2 Hypervisor を介して libvirt プラグインが server01 を再起動させます eth3 eth1 eth2 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt server01(active) eth0 PostgreSQL DB eth0 server02(standby) Hypervisor(KVM) 運用 LAN 63

64 リソース停止故障時の動作 (STONITH 完了後 ) サービス LAN WEB アクセスインターネット eth3 eth1 eth2 インターコネクト 1 インターコネクト 2 eth3 仮想 IP eth1 eth2 サービスはserver02へフェイルオーバされま mount すサービスリソース Filesystem IPaddr2 pgsql apache 監視リソース ping diskd 2 STONITH リソース stonith-helper libvirt server01(offline) eth0 PostgreSQL DB eth0 server02(active) Hypervisor(KVM) 運用 LAN 64

65 リソース停止故障による STONITH 完了後のクラスタ状態 # ssh server02 "crm_mon -fda1" Online: [ server02 ] OFFLINE: [ server01 ] Resource Group: grpstonith1 prmhelper1-1 (stonith:external/stonith-helper): Started server02 prmlibvirt1-2 (stonith:external/libvirt): Started server02 Resource Group: grptrac prmfs (ocf::heartbeat:filesystem): Started server02 prmvip (ocf::heartbeat:ipaddr2): Started server02 prmdb (ocf::heartbeat:pgsql): Started server02 prmweb (ocf::heartbeat:apache): Started server02 Clone Set: clndiskd1 [prmdiskd1] Started: [ server02 ] Stopped: [ server01 ] Clone Set: clndiskd2 [prmdiskd2] Started: [ server02 ] Stopped: [ server01 ] Clone Set: clnping [prmping] Started: [ server02 ] Stopped: [ server01 ] ( 省略 ) STONITH 完了後 STONITH が実行されたノードは Pacemaker が止まるため OFFLINE となりますリソースはフェイルオーバされて server02 上で起動します 65

66 さいごに本セッションのおさらいリソースの停止故障に対応できるのは STONITH だけ! STONITH はスプリットブレインになってもサービスの 2 重起動を完全に防ぐ! Pacemaker は環境に合わせて使える多様な STONITH プラグインを備えている! Pacemaker を使う際にはクラスタをサービス停止から救う STONITH の導入をぜひご検討ください! 66

Linux-HA Japan の紹介 Pacemaker の日本公式コミュニティとして Linux-HA Japan を運営しています下記サイトにて Pacemaker 関連の最新情報を日本語で発信しています http://linux-ha.osdn.

67 Linux-HA Japan の紹介 Pacemaker の日本公式コミュニティとして Linux-HA Japan を運営しています下記サイトにて Pacemaker 関連の最新情報を日本語で発信しています Linux-HA Japan では Pacemaker の rpm パッケージ 1 の配布も行っています 1:Pacemaker 関連パッケージをまとめてインストールを簡単にしたリポジトリパッケージ rpm パッケージダウンロードはこちらから 67

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

68 Linux-HA Japan メーリングリスト日本における HA クラスタについての活発な意見交換の場として Linux- HA Japan 日本語メーリングリストも開設しています Linux-HA Japan ML では Pacemaker Corosync DRBD など HA クラスタに関連する話題を歓迎しています! ML への登録はこちらから! ML アドレスのメーリングリストをクリックスパム防止のために登録者以外の投稿は許可制です 68

69 最新情報 10/16 に Pacemaker-repo をリリースしました! 最新の Pacemaker を使いたい方は以下からダウンロードしてください 69

70 ご清聴ありがとうございました展示情報 206 教室にて Linux-HA Japan Project ブース展示中です! 70

71 付録 : デモ環境のリソース定義ファイル (1) ### Cluster Option ### property \ no-quorum-policy="ignore" \ stonith-enabled="true" \ startup-fencing="false" ### Fencing Topology ### fencing_topology \ server01: prmhelper1-1 prmlibvirt1-2 \ server02: prmhelper2-1 prmlibvirt2-2 #### Group Configuration ### group grpstonith1 \ prmhelper1-1 \ prmlibvirt1-2 group grpstonith2 \ prmhelper2-1 \ prmlibvirt2-2 primitive prmhelper1-1 stonith:external/stonith-helper \ params \ pcmk_reboot_retries=1 \ hostlist="server01" \ dead_check_target=" " \ standby_check_command="/usr/sbin/crm_resource -r prmdb -W grep -qi `hostname`" \ run_online_check="yes" \ op start interval="0s" timeout="20s" on-fail="restart" \ op monitor interval="3600s" timeout="20s" on-fail="restart" \ op stop interval="0s" timeout="15" on-fail="ignore" primitive prmlibvirt1-2 stonith:external/libvirt \ params \ hostlist="server01" \ hypervisor_uri="qemu+ssh:// /system" \ op start interval="0s" timeout="60s" on-fail="restart" \ op monitor interval="3600s" timeout="60s" on-fail="restart" \ op stop interval="0s" timeout="60s" on-fail="ignore" primitive prmhelper2-1 stonith:external/stonith-helper \ params \ pcmk_reboot_retries=1 \ hostlist="server02" \ dead_check_target=" " \ standby_check_command="/usr/sbin/crm_resource -r prmdb -W grep -qi `hostname`" \ run_online_check="yes" \ op start interval="0s" timeout="20s" on-fail="restart" \ op monitor interval="3600s" timeout="20s" on-fail="restart" \ op stop interval="0s" timeout="15" on-fail="ignore" primitive prmlibvirt2-2 stonith:external/libvirt \ params \ hostlist="server02" \ hypervisor_uri="qemu+ssh:// /system" \ op start interval="0s" timeout="60s" on-fail="restart" \ op monitor interval="3600s" timeout="60s" on-fail="restart" \ op stop interval="0s" timeout="60s" on-fail="ignore" ### Group Configuration ### group grptrac \ prmfs \ prmvip \ prmdb \ prmweb ### Clone Configuration ### clone clnping \ prmping clone clndiskd1 \ prmdiskd1 clone clndiskd2 \ prmdiskd2 71

72 付録 : デモ環境のリソース定義ファイル (2) ### Primitive Configuration ### primitive prmfs ocf:heartbeat:filesystem \ params \ fstype="ext4" \ run_fsck="force" \ device="/dev/vdb1" \ directory="/pgsqldb" \ op start interval="0s" timeout="60s" on-fail="restart" \ op monitor interval="20s" timeout="40s" on-fail="restart" \ op stop interval="0s" timeout="60s" on-fail="fence" primitive prmvip ocf:heartbeat:ipaddr2 \ params \ ip=" " \ nic="eth3" \ cidr_netmask="24" \ op start interval="0s" timeout="20s" on-fail="restart" \ op monitor interval="10s" timeout="20s" on-fail="restart" \ op stop interval="0s" timeout="20s" on-fail="fence" primitive prmdb ocf:heartbeat:pgsql \ params \ pgctl="/usr/pgsql-9.4/bin/pg_ctl" \ psql="/usr/pgsql-9.4/bin/psql" \ pgdata="/pgsqldb/data" \ start_opt="-p 5432" \ pgdba="postgres" \ pgport="5432" \ pgdb="template1" \ op start interval="0s" timeout="120s" on-fail="restart" \ op monitor interval="10s" timeout="10s" on-fail="restart" \ op stop interval="0s" timeout="20s" on-fail="fence" primitive prmweb ocf:heartbeat:apache \ op start interval="0s" timeout="40s" on-fail="restart" \ op monitor interval="10s" timeout="20s" on-fail="restart" \ op stop interval="0s" timeout="60s" on-fail="fence" primitive prmping ocf:pacemaker:ping \ params \ name="default_ping_set" \ host_list=" " \ multiplier="100" \ attempts="2" \ timeout="2" \ debug="true" \ 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 prmdiskd1 ocf:pacemaker:diskd \ params \ name="diskcheck_status" \ device="/dev/vdb" \ options="-e -t 70" \ interval="10" \ dampen="2" \ 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 prmdiskd2 ocf:pacemaker:diskd \ params \ name="diskcheck_status_internal" \ device="/dev/vda" \ options="-e" \ interval="10" \ dampen="2" \ 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" 72

73 付録 : デモ環境のリソース定義ファイル (3) ### Resource Location ### location rsc_location-grptrac-1 grptrac \ rule 200: #uname eq server01 \ rule 100: #uname eq server02 \ rule -INFINITY: not_defined default_ping_set or default_ping_set lt 100 \ rule -INFINITY: not_defined diskcheck_status or diskcheck_status eq ERROR \ rule -INFINITY: not_defined diskcheck_status_internal or diskcheck_status_internal eq ERROR ### Resource Colocation ### colocation rsc_colocation-grptrac-clnping-1 INFINITY: grptrac clnping colocation rsc_colocation-grptrac-clndiskd1-2 INFINITY: grptrac clndiskd1 colocation rsc_colocation-grptrac-clndiskd2-3 INFINITY: grptrac clndiskd2 ### Resource Order ### order rsc_order-clnping-grptrac-1 0: clnping grptrac symmetrical=false order rsc_order-clndiskd1-grptrac-2 0: clndiskd1 grptrac symmetrical=false order rsc_order-clndiskd2-grptrac-3 0: clndiskd2 grptrac symmetrical=false ### Resource Defaults ### rsc_defaults resource-stickiness="infinity" \ migration-threshold="1" 73

HAクラスタをフェイルオーバ失敗から救おう！

HAクラスタをフェイルオーバ失敗から救おう！ HA クラスタをフェイルオーバ失敗から救おう! 2013 年 8 月 3 日 OSC2013 Kansai@Kyoto Linux-HA Japan プロジェクト田中崇幸 1 自己紹介名前 : 田中崇幸 (Takayuki Tanaka) Twitter: @tanakacchi21 所属 : Linux-HA Japan プロジェクトコミュニティ旗揚時のメンバー趣味 : マラソンフルマラソン

自己紹介 名前 所属 飯田雄介 ( いいだゆうすけ ) 主な活動 Linux-HA Japan プロジェクト Pacemaker 本体の機能改善や 外部ツールの開発を行っています Linux-HA Japan から pm_logconv や pm_crmgen といったツールを提供しています 2

自己紹介名前所属飯田雄介 ( いいだゆうすけ ) 主な活動 Linux-HA Japan プロジェクト Pacemaker 本体の機能改善や外部ツールの開発を行っています Linux-HA Japan から pm_logconv や pm_crmgen といったツールを提供しています 2