tsuki****@gmail*****
tsuki****@gmail*****
2016年 11月 29日 (火) 09:31:38 JST
nakaさん お世話になっております。 池田です。 Pacemaker 1.0.12の場合、ping RAはこちらを使用されているかと思います。 https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping 監視処理実行時に、ping RAがなにをやっているかというと https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping#L170 pidfileの存在を判定しています。 - pidfileが存在していれば、ping_update関数を実行 - pidfileが存在していなければ、監視失敗 → フェイルカウントを更新 pidfileは起動処理実行時に作成しています。 https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping#L157 さらに、ping_update関数がなにをやっているかというと https://github.com/ClusterLabs/pacemaker-1.0/blob/Pacemaker-1.0.12/extra/resources/ping#L261 ping_check関数の実行結果をattrd_updaterコマンドに渡しています。 pingコマンドを実行して、ネットワークの疎通確認をしてるのがping_check関数ですね。 paramで指定したhost_listやmultiplierも絡んでくるところですが nakaさんの設定では、10.1.0.1に対してpingコマンドを10回実行して 成功したら、200がattrd_updaterコマンドに渡されます。 失敗したら、0がattrd_updaterコマンドに渡されます。 attrd_updaterコマンドが失敗した場合は、フェイルカウントが更新されます。 attrd_updaterコマンドがなにをやっているかというと Pacemakerが管理しているクラスタ情報の「属性値」とよばれるものを更新しています。 「フェイルカウント」と「属性値」は別のものです。 だんだんややこしくなってきましたが ping RAが監視処理実行時にフェイルカウントを更新する条件は - pidfileが存在していない - attrd_updaterコマンドが失敗した です。 pingコマンドの失敗を契機にフェイルカウントは更新されません。 pingコマンドが失敗した、つまり、ネットワークに異常が発生したという条件で なにが行われているかというと、attrd_updaterコマンドによる属性値の更新です。 属性値は、crm_monコマンドに「-A」オプションを追加すると表示されます。 nakaさんの設定では、「eth0_ping_set 200」が見えてくるのではないでしょうか。 crm_mon -A コマンドを実行した状態で pingコマンドが成功した場合、属性値は200と表示されます。 pingコマンドが失敗した場合、属性値は0と表示されます。 また、ping RAを使用する場合、location制約も設定します。 http://linux-ha.osdn.jp/wp/archives/3868#location 設定例) 1.1系の設定例ですが、locationは1.0系も同じです。 http://linux-ha.osdn.jp/wp/archives/4377#pingLAN location <location ID> <リソース名> \ rule -INFINITY: not_defined eth0_ping_set or eth0_ping_set lt 200 \ 上記のlocation設定では (1) 「eth0_ping_set」という属性値が設定されていない(not_defined) または (2) 「eth0_ping_set」という属性値が200より小さい(lt 200) いう条件において、「リソース」は起動できません。 ややこしい。。。 ざっくりいうと、「eth0_ping_set」という属性値が200だった場合に、リソースは起動できるってことですね。 で、ネットワークが故障すると、この属性値が0になるので (2)の条件にあてはまり、リソースはフェイルオーバします。 ネットワークが復旧すると、属性値が200に戻り、リソースがフェイルバック可能な状態となります。 ネットワークが連続的に故障すると、リソースのフェイルオーバ/フェイルバックが連続して発生するのはこのためです。 nakaさんの環境では ノード1のpingが失敗 → リソースはノード1にフェイルオーバ ノード1のpingが復旧 → リソースはノード2に居残る(resource-stickiness="INFINITY") ノード2のpingが失敗 → リソースはノード2にフェイルバック を繰り返したのではないでしょうか。 ping RAは、このような仕様なので > pingリソースでF/Oの上限回数の設定はできるものでしょうか？ > （例えば3回F/O繰り返したら停止するとか） 残念ながら、ネットワーク故障でこの動作を実現することはできないと思います。 なお、厳密にいうと、他のリソースでも「F/O繰り返したら停止」という設定は微妙なところで migration-thresholdに設定された「故障上限値」まで同一ノードで「再起動」する、という動作になるので ファイルオーバの上限回数を設定することはできないはずです。 フェイルオーバの上限回数とはまたちょっと違いますが フェイルカウントが上限まで達したノードではリソースが起動できない動作を実現するために ネットワーク故障を契機にフェイルカウントを更新する、という設定案としては 例えば、anything RAを使ってみる、などもありますが https://github.com/ClusterLabs/resource-agents/blob/v3.9.7/heartbeat/anything nakaさんの環境はバージョンをみた感じ、積極的に新規リソースを追加してまで ネットワーク故障に対応したい！というのもなかなか難しそうですし 現実的な解としては、デフォルトゲートウェイのヒトに あんまり壊れないでね、とお願いする感じなのかな、という気もしますが。。。 デフォルトゲートウェイがどのネットワーク機器にくっついているのかにもよりますが L3とかだと、それ自体も冗長化されていて数秒単位で切り替わってくれるはずなので 瞬断を繰り返しても、ping RAのリトライ処理で再検出できます。 以前、ファイアウォール機器をping対象にしたことがありますが ネットワーク担当の人によく話を聞くと「このファイアウォールは切り替えに 10分くらいかかります」と言われ、慌てて同じセグメント内でL3を探したことはあります。 # 気づいたきっかけはそのファイアウォールがたまーにICMPを # ドロップするという謎動作をしていたからですが。 あと、あまりにもよく壊れる(というか疎通がぶっちぎれる)経路をping先にしてしまった環境では 潔くネットワーク監視は諦めて(仮想環境だったていうのもありますが)、 127.0.0.1をping先に変更したという話も聞きました。 以上よろしくお願いいたします。 池田淳子 差出人: Keisuke Nakamura 送信日時: 2016年11月25日 14:03 宛先: linux****@lists***** 件名: [Linux-ha-jp] pingリソースのfail-countについて 関係者各位 お世話になっております。nakaと申します。 環境： CentOS 6.2(x86_64) pacemaker-1.0.12-1.el6.x86_64 heartbeat-3.0.5-1.1.el6.x86_64 (質問) pingリソースのfail-countについて質問です。 pingリソースを利用しデフォルトゲートウェイへの疎通監視 を設定している2ノードクラスタ構成を組んでおります。 先日弊社環境のネットワーク障害の影響で数分間、両ノードとも デフォゲへの疎通が不安定な状態となり、上記のpingリソースでの 異常を契機にクラスタグループリソースのF/Oが繰り返し行われました。 その後ネットワークが復旧後は、繰り返し行われていたF/Oも止まり、 サービスも正常に起動している状態となりました。 障害直後crm_monで状態をみても、fail-countが加算されてなく failed actionも表示されなかったのですが、pingリソースで F/Oの上限回数の設定はできるものでしょうか？（例えば3回F/O 繰り返したら停止するとか） fail-countについての情報を探し出せず、当メールにてご相談 させて頂きました。お手隙の時にご教授頂けますと幸いです。 (現状設定値の一部↓) primitive res_ping ocf:pacemaker:ping \ params name="eth0_ping_set" host_list="10.1.0.1" multiplier="200" dampen="1" debug="true" attempts="10" \ op monitor interval="10s" timeout="60" \ op start interval="0" timeout="60" …中略… property $id="cib-bootstrap-options" \ dc-version="1.0.12-066152e" \ cluster-infrastructure="Heartbeat" \ stonith-enabled="false" \ no-quorum-policy="ignore" \ default-action-timeout="120s" \ last-lrm-refresh="1463626573" rsc_defaults $id="rsc-options" \ resource-stickiness="INFINITY" 以上、宜しくお願い致します。 _______________________________________________ Linux-ha-japan mailing list Linux****@lists***** http://lists.osdn.me/mailman/listinfo/linux-ha-japan -------------- next part -------------- HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...下載
Fork