renay****@ybb*****
renay****@ybb*****
2016年 11月 29日 (火) 18:42:05 JST
nakaさん 池田さん こんばんは、山内です。 すいません、全くの私の勘違いです。 fail-countは、ping RAが故障(monitor)を起こした場合にアップするものであって、 pingの疎通が切れた場合には、関係しません。 よって、nakaさんのケースでは、fail-countはアップせずに、フェイルオーバーが発生します。 ＃"eth0_ping_set" をlocationで記載していると思いますが、その制約条件でフェイルオーバーが発生します。 この動作は、Pacemaker1.1系でも同じです。 提案したcrmd-transition-delayはまた、別物です。 以上です。 ----- Original Message ----- > From: Keisuke Nakamura <k.xna****@gmail*****> > To: linux****@lists***** > Cc: > Date: 2016/11/29, Tue 18:22 > Subject: Re: [Linux-ha-jp] pingリソースのfail-countについて > > 山内様、池田様 > > お世話になっております、nakaと申します。 > ご説明有難うございます！とても助かります。 > 頂いた情報をもとに、pingリソースがどんな処理をしてるかを > 理解するところから確認していきます。（heartbeatのログによく > attrd_updaterのメッセージは目にしてたのですが、触れずに > ここまで来てしまいました） > ping RAはfailcountを維持できるか？私の方でも確認してみます。 > > 取り急ぎ御礼まで。 > > > 2016年11月29日 9:57 Junko IKEDA <tsuki****@gmail*****>: >> あれ、山内さんのメールを読み損なっていましたが >> ping RAはフェイルカウントを維持できるんでしたっけ。 >> pingd RAはpingdデーモンの故障回数を維持してた気がしてましたが、勘違いしてました。 >> 失礼しました。 >> >> 池田淳子 >> >> >> 2016/11/29 6:51 <renay****@ybb*****>: >> >>> nakaさん >>> >>> こんにちは、山内です。 >>> >>> 詳細はログを見てみないとわかりませんが、 >>> Pacemaker1.0系のpingリソースで利用しているattrd_updater（attrdプロセスへの属性更新）の仕様上、 >>> 故障検知よりも、故障カウントのアップが遅れることが原因だと思われます。 >>> >>> propertyに「crmd-transition-delay」パラメータがありますので、これを5sなどと設定してみてください。 >>> これにより、全体的に故障発生時のフェイルオーバーが5s程度遅れてしまいますが、故障カウントの制御は >>> うまくいくはずです。 >>> >>> CentOS6.2とOS環境が古いですが、可能であれば、Pacemaker1.1系の利用をご検討されることをお勧めします。 >>> >>> 以上です。 >>> >>> >>> >>> ----- Original Message ----- >>> > From: Keisuke Nakamura <k.xna****@gmail*****> >>> > To: linux****@lists***** >>> > Cc: >>> > Date: 2016/11/25, Fri 14:03 >>> > Subject: [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 >>> > >>> >>> _______________________________________________ >>> Linux-ha-japan mailing list >>> Linux****@lists***** >>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >> >> >> _______________________________________________ >> Linux-ha-japan mailing list >> Linux****@lists***** >> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >> > > > > -- > Nakamura > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.osdn.me/mailman/listinfo/linux-ha-japan >
Fork