Keisuke Nakamura
k.xna****@gmail*****
2016年 11月 29日 (火) 19:12:41 JST
山内さん ご連絡有難うございます！ こちらこそすみません、お手数おかけ致しました。 池田さんの情報も参考にしつつ、改めて確認していきます。 有難うございました。 以上、宜しくお願い致します。 2016年11月29日 18:51 <renay****@ybb*****>: > nakaさん > 池田さん > > こんばんは、山内です。 > > 最初のnakaさんのご質問の回答という意味では、池田さんが回答した。 > >>残念ながら、ネットワーク故障でこの動作を実現することはできないと思います。 >>なお、厳密にいうと、他のリソースでも「F/O繰り返したら停止」という設定は微妙なところで >>migration-thresholdに設定された「故障上限値」まで同一ノードで「再起動」する、という動作になるので >>ファイルオーバの上限回数を設定することはできないはずです。 > > 上記の回答が正しいです。 > > 勘違いで混乱させてしまったかも知れません、申し訳ありませんでした。 > > 以上です。 > > > > ----- Original Message ----- >> From: "renay****@ybb*****" <renay****@ybb*****> >> To: "linux****@lists*****" <linux****@lists*****> >> Cc: >> Date: 2016/11/29, Tue 18:42 >> Subject: Re: [Linux-ha-jp] pingリソースのfail-countについて >> >> 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 >>> >> >> _______________________________________________ >> 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
Fork