renay****@ybb*****
renay****@ybb*****
2015年 3月 6日 (金) 09:46:54 JST
福田さん こんにちは、山内です。 Pacemaker最新を確認してみました。(環境は同様です） * https://github.com/ClusterLabs/pacemaker/tree/5c4a5a9894b4b8f4b357e213f7c480a6c83f6d6b 1)Heartbeat3.0.5+Pacemaker最新 : NG 事象は変わらず 2)Heartbeat3.0.6+Pacemaker最新 : OK どうやら、Heartbeatも最新版3.0.6を組合せる必要があるようです。 * http://hg.linux-ha.org/heartbeat-STABLE_3_0/rev/cceeb47a7d8f [root ＠ rh64-heartbeat1 pacemaker-master]# crm_mon -1 -Af Last updated: Fri Mar 6 09:38:41 2015 Last change: Fri Mar 6 09:38:35 2015 via crmd on rh64-heartbeat1 Stack: heartbeat Current DC: rh64-heartbeat1 (f18fb27f-b124-4058-b442-7a35a2927312) - partition with quorum Version: 1.1.12-460fffe 1 Nodes configured 0 Resources configured Online: [ rh64-heartbeat1 ] Node Attributes: * Node rh64-heartbeat1: Migration summary: * Node rh64-heartbeat1: [root ＠ rh64-heartbeat1 pacemaker-master]# ps -ef | grep heartbeat root 2171 1 0 09:38 ? 00:00:00 heartbeat: master control process root 2175 2171 0 09:38 ? 00:00:00 heartbeat: FIFO reader root 2176 2171 0 09:38 ? 00:00:00 heartbeat: write: bcast eth1 root 2177 2171 0 09:38 ? 00:00:00 heartbeat: read: bcast eth1 root 2178 2171 0 09:38 ? 00:00:00 heartbeat: write: bcast eth2 root 2179 2171 0 09:38 ? 00:00:00 heartbeat: read: bcast eth2 496 2180 2171 0 09:38 ? 00:00:00 /usr/libexec/heartbeat/ccm root 2212 1906 0 09:39 pts/1 00:00:00 grep heartbeat [root ＠ rh64-heartbeat1 pacemaker-master]# ps -ef | grep pace 496 2181 2171 0 09:38 ? 00:00:00 /usr/libexec/pacemaker/cib root 2182 2171 0 09:38 ? 00:00:00 /usr/libexec/pacemaker/stonithd root 2183 2171 0 09:38 ? 00:00:00 /usr/libexec/pacemaker/lrmd 496 2184 2171 0 09:38 ? 00:00:00 /usr/libexec/pacemaker/attrd 496 2185 2171 0 09:38 ? 00:00:00 /usr/libexec/pacemaker/crmd 496 2188 2185 0 09:38 ? 00:00:00 /usr/libexec/pacemaker/pengine root 2214 1906 0 09:39 pts/1 00:00:00 grep pace 単ノードで起動（リソース無）までは確認しましたが、動作を確認していませんので、ご注意ください。 #やはり、動作の確認が多々されているcorosyncとの組み合わせの方が安全だと思います。 以上です。 ----- Original Message ----- > From: "renay****@ybb*****" <renay****@ybb*****> > To: Masamichi Fukuda - elf-systems <masamichi_fukud****@elf-s*****> > Cc: "linux****@lists*****" <linux****@lists*****> > Date: 2015/3/6, Fri 09:27 > Subject: Re: [Linux-ha-jp] スプリットブレイン時のSTONITHエラーについて > > 福田さん > > こんにちは、山内です。 > > 環境は若干違いますが、 > RHEL6.5上で、Heartbeat3.0.5+Pacemaker1.1.10(ソースインストール)を単ノードで動作を確認してみました。 > > > 残念ですが、結果は、福田さんと同じで、 > > heartbeat: [3847]: EMERG: Rebooting system. Reason: /usr/lib64/heartbeat/crmd > > > となり、単ノードが再起動します。 > > コミュニティの最新版(Heartbeat組合せ対応版）で起動するかどうかも確認してご連絡します。 > > ＃今の所、Pacemaker1.1系を利用するのであれば、やはり、corosyncと組み合わることをおすすめしますが。。。 > > 以上です。 > > > > ----- Original Message ----- >> From: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****> >> To: "renay****@ybb*****" > <renay****@ybb*****> >> Cc: Masamichi Fukuda - elf-systems <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >> Date: 2015/3/6, Fri 07:43 >> Subject: Re: スプリットブレイン時のSTONITHエラーについて >> >> >> 山内さん >> >> >> おはようございます、福田です。 >> >> >> お忙しいところ済みませんが、 >> 宜しくお願いします。 >> >> >> 以上 >> >> 2015年3月6日金曜日、<renay****@ybb*****>さんは書きました: >> >> 福田さん >>> >>> おはようございます。山内です。 >>> >>> 一応、私の方でも確認してご連絡しますね。 >>> ＃たぶん、corosyncと組み合わせないと、福田さんと同じ症状（NG）だと思いますが・・・・ >>> >>> 以上です。 >>> >>> >>> ----- Original Message ----- >>>> From: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****> >>>> To: 山内英生 <renay****@ybb*****> >>>> Cc: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >>>> Date: 2015/3/5, Thu 23:14 >>>> Subject: Re: スプリットブレイン時のSTONITHエラーについて >>>> >>>> >>>> 山内さん >>>> >>>> こんばんは、福田です。 >>>> >>>> はい、heartbeatと組み合わせていました。 >>>> >>>> これは、corosyncと組み合わせないといけないということでしょうか。 >>>> >>>> >>>> >>>> >>>> 2015年3月5日 22:30 <renay****@ybb*****>: >>>> >>>> 福田さん >>>>> >>>>> >>>>> こんばんは、山内です。 >>>>> >>>>> >>>>> もしかして、Heartbeatと組み合わせていますか？ >>>>> >>>>> >>>>> 新しいPacemaker(1.1.12以降）あたりでないと、Heartbeatとの組み合わせはNGかも知れません。 >>>>> >>>>> >>>>> ＃最近の修正で、Heartbeatの組み合わせの修正が入ったばかりです。 >>>>> >>>>> >>>>> 以上です。 >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****> >>>>>> To: 山内英生 <renay****@ybb*****>; > "linux****@lists*****" > <linux****@lists*****> >>>>>> Cc: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****> >>>>>> >>>>>> Date: 2015/3/5, Thu 17:46 >>>>>> Subject: Re: スプリットブレイン時のSTONITHエラーについて >>>>>> >>>>>> >>>>>> >>>>>> 山内さん >>>>>> >>>>>> こんにちは、福田です。 >>>>>> まずは、pacemakerをバージョンアップしてみました。 >>>>>> >>>>>> バージョンは、Version: 1.1.10+git20130802-4.1 です。 >>>>>> >>>>>> まずはノード１の一台だけアップグレードして状態をみました。 >>>>>> >>>>>> バージョンアップしていないノード２側のpacemakerを停止した状態で >>>>>> crm_monを見ると下記のようになります。 >>>>>> >>>>>> # crm_mon -rfA -1 >>>>>> Could not establish cib_ro connection: Connection refused > (111) >>>>>> >>>>>> Connection to cluster failed: Transport endpoint is not > connected >>>>>> >>>>>> ノード２のpacemakerを起動してcrm_monで見るとpending状態です。 >>>>>> >>>>>> Node lbv1.beta.com (38b0f200-83ea-8633-6f37-047d36cd39c6): > pending >>>>>> Online: [ lbv2.beta.com ] >>>>>> >>>>>> これで数分すると、バージョンアップしたノード１がリブートを繰り返します。 >>>>>> >>>>>> 一度crmの設定を削除して、まっさらな状態で起動しても同様に落ちます。 >>>>>> >>>>>> リブートの際には次のようなメッセージが出ます。 >>>>>> >>>>>> 2015 Mar 5 17:25:39 lbv1 [1854]: EMERG: Rebooting system. > Reason: /usr/lib/heartbeat/crmd >>>>>> >>>>>> >>>>>> ログは下記のようになっています。 >>>>>> >>>>>> Mar 05 16:45:30 [3019] lbv1.beta.com crmd: info: > crm_timer_popped: Wait Timer (I_NULL) just popped (2000ms) >>>>>> Mar 05 16:45:30 [3019] lbv1.beta.com crmd: info: > lrmd_ipc_connect: Connecting to lrmd >>>>>> Mar 05 16:45:30 [3019] lbv1.beta.com crmd: info: > crm_ipc_connect: Could not establish lrmd connection: Connection refused > (111) >>>>>> Mar 05 16:45:30 [3019] lbv1.beta.com crmd: warning: > do_lrm_control: Failed to sign on to the LRM 29 (30 max) times >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > crm_timer_popped: Wait Timer (I_NULL) just popped (2000ms) >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > lrmd_ipc_connect: Connecting to lrmd >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > crm_ipc_connect: Could not establish lrmd connection: Connection refused > (111) >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: error: > do_lrm_control: Failed to sign on to the LRM 30 (max) times >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > register_fsa_error_adv: Resetting the current action list >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: error: > do_log: FSA: Input I_ERROR from do_lrm_control() received in state > S_STARTING >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: notice: > do_state_transition: State transition S_STARTING -> S_RECOVERY [ > input=I_ERROR cause=C_FSA_INTERNAL origin=do_lrm_control ] >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: warning: > do_recover: Fast-tracking shutdown in response to errors >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_ccm_control: CCM connection established... waiting for first callback >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: error: > do_started: Start cancelled... S_RECOVERY >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: error: > do_log: FSA: Input I_TERMINATE from do_recover() received in state > S_RECOVERY >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_state_transition: State transition S_RECOVERY -> S_TERMINATE [ > input=I_TERMINATE cause=C_FSA_INTERNAL origin=do_recover ] >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_shutdown: All subsystems stopped, continuing >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_lrm_control: Disconnecting from the LRM >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > lrmd_api_disconnect: Disconnecting from lrmd service >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > lrmd_api_disconnect: Disconnecting from lrmd service >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: notice: > do_lrm_control: Disconnected from the LRM >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > crm_cluster_disconnect: Disconnecting from cluster infrastructure: heartbeat >>>>>> Mar 05 16:45:32 lbv1.beta.com ccm: [3014]: info: client > (pid=3019) removed from ccm >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > crm_cluster_disconnect: Disconnected from heartbeat >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_ha_control: Disconnected from the cluster >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_cib_control: Disconnecting CIB >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > crmd_cib_connection_destroy: Connection to the CIB terminated... >>>>>> Mar 05 16:45:32 [3020] lbv1.beta.com pengine: info: > crm_signal_dispatch: Invoking handler for signal 15: Terminated >>>>>> Mar 05 16:45:32 [3020] lbv1.beta.com pengine: info: > qb_ipcs_us_withdraw: withdrawing server sockets >>>>>> Mar 05 16:45:32 [3020] lbv1.beta.com pengine: info: > crm_xml_cleanup: Cleaning up memory from libxml2 >>>>>> Mar 05 16:45:32 [3015] lbv1.beta.com cib: info: > crm_client_destroy: Destroying 0 events >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > stop_subsystem: Sent -TERM to pengine: [3020] >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_exit: Performing A_EXIT_0 - gracefully exiting the CRMd >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > do_exit: [crmd] stopped (0) >>>>>> Mar 05 16:45:32 [3019] lbv1.beta.com crmd: info: > crmd_exit: Dropping I_TERMINATE: [ state=S_TERMINATE cause=C_FSA_INTERNAL > origin=do_stop ] >>>>>> Mar 05 16:45:32 lbv1.beta.com heartbeat: [1862]: WARN: > Managed /usr/lib/heartbeat/crmd process 3019 killed by signal 11 [SIGSEGV - > Segmentation violation]. >>>>>> >>>>>> >>>>>> 原因はどこにあるかわかりましたらご教示下さい。 >>>>>> >>>>>> 宜しくお願いします。 >>>>>> >>>>>> 以上 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015年3月4日 13:26 Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****>: >>>>>> >>>>>> 山内さん >>>>>>> >>>>>>> こんにちは、福田です。 >>>>>>> >>>>>>> 下記urlの情報ありがとうございます。 >>>>>>> 見てみます。 >>>>>>> >>>>>>> corosyncの件もあわせて検討したいと思います。 >>>>>>> >>>>>>> 宜しくお願いします。 >>>>>>> >>>>>>> 以上 >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015年3月4日 13:18 <renay****@ybb*****>: >>>>>>> >>>>>>> >>>>>>> 福田さん >>>>>>>> >>>>>>>> こんにちは、山内です。 >>>>>>>> >>>>>>>> debianにうとくて申し訳ないのですが、以下もあるようです。 >>>>>>>> >>>>>>>> https://packages.qa.debian.org/p/pacemaker.html >>>>>>>> >>>>>>>> >>>>>>>> 公式のpacemakerサイトからもリンクされています。 >>>>>>>> こちらは、1.1.10のようです。 >>>>>>>> >>>>>>>> 1.1系のバージョンアップのお考えであれば、ぜひ、corosyncとの組み合わせもご検討ください。 >>>>>>>> >>>>>>>> 以上です。 >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****> >>>>>>>>> To: "renay****@ybb*****" > <renay****@ybb*****> >>>>>>>>> Cc: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >>>>>>>> >>>>>>>>> Date: 2015/3/4, Wed 12:35 >>>>>>>>> Subject: Re: スプリットブレイン時のSTONITHエラーについて >>>>>>>>> >>>>>>>>> >>>>>>>>> 山内さん >>>>>>>>> >>>>>>>>> >>>>>>>>> こんにちは、福田です。 >>>>>>>>> 早速の検証ありがとうございました。 >>>>>>>>> >>>>>>>>> >>>>>>>>> pacemakerのバージョンアップを行うか、自前プラグインを作るか社内で検討してみます。 >>>>>>>>> >>>>>>>>> >>>>>>>>> もう一つ質問ですみませんが、 >>>>>>>>> 現在の構成ですが、pacemakerはdebianのパッケージで導入しました。 >>>>>>>>> >>>>>>>>> >>>>>>>>> pacemakerのバージョンアップを行う場合、ソースからのインストールになりますでしょうか。 >>>>>>>>> OSはdebian7.8を使うことになっています。 >>>>>>>>> >>>>>>>>> >>>>>>>>> 宜しくお願いします。 >>>>>>>>> >>>>>>>>> 以上 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015年3月4日水曜日、<renay****@ybb*****>さんは書きました: >>>>>>>>> >>>>>>>>> >>>>>>>>>> 福田さん >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> こんにちは、山内です。 >>>>>>>>>> >>>>>>>>>> 環境は異なりますが(corosync+PM1.1.7)で、stonith-helperとsshによる故障時の動作を確認しましたが、 >>>>>>>>>> 同様に先頭のstonith-helperの実行がループします。 >>>>>>>>>> 1.1.7では、このあたりを制御するパラメータが存在しません。 >>>>>>>>>> >>>>>>>>>> この対応は、Pacemaker1.1.9あたりで入っていおり、1.1.7ではこの事象によりループしてしまいます。 >>>>>>>>>> >>>>>>>>>> 1.1.9あたりでは、このループを制御する為に、pcmk_reboot_retriesなどのパラメータにより実行回数をパラメータで >>>>>>>>>> 指定できるようになっています。 >>>>>>>>>> >>>>>>>>>> 正常なＦＯ動作(stonith実行～再起動。。)を行うには、やはり、pacemakerのバージョンアップを行うか、 >>>>>>>>>> ３つのstonithを組合せたような、stonithプラグインを自前で作成する必要（helperとssh(福田さんの場合には、xen0)とmeatware) >>>>>>>>>> があるようです。 >>>>>>>>>> >>>>>>>>>> ＃自前で作成したプラグインで全てのプラグインを実行して結果を返すような形にする。 >>>>>>>>>> >>>>>>>>>> 以上、です。 >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****> >>>>>>>>>>> To: 山内英生 > <renay****@ybb*****> >>>>>>>>>>> Cc: Masamichi Fukuda - elf-systems > <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >>>>>>>>>>> Date: 2015/3/4, Wed 11:09 >>>>>>>>>>> Subject: Re: [Linux-ha-jp] > スプリットブレイン時のSTONITHエラーについて >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 山内さん >>>>>>>>>>> >>>>>>>>>>> お世話になります、福田です。 >>>>>>>>>>> ご確認ありがとうございます。 >>>>>>>>>>> >>>>>>>>>>>> ということでいけば、xen0の単体では動作は問題ないということになります。 >>>>>>>>>>> >>>>>>>>>>> xen0の動作は問題ないとのことでよかったです。 >>>>>>>>>>> >>>>>>>>>>>> こちらは、コマンド実行でない場合のログと思いますが、どうやら、 >>>>>>>>>>>> pacemaker経由のexternal/stonith-helper以降が実行されないのが問題のようです。 >>>>>>>>>>>> >>>>>>>>>>>> 新しめのpacemakerとはパラメータも異なっている為、こちらでも構成は違って >>>>>>>>>>>> しまいますが、stonith-helper、sshなどの組合せでどうなるか確認してみます。 >>>>>>>>>>> >>>>>>>>>>> すみませんが宜しくお願いします。 >>>>>>>>>>> >>>>>>>>>>> 以上 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015年3月4日 10:41 > <renay****@ybb*****>: >>>>>>>>>>> >>>>>>>>>>> 福田さん >>>>>>>>>>>> >>>>>>>>>>>> おはようございます。山内です。 >>>>>>>>>>>> >>>>>>>>>>>>> 早速STONITHコマンドを試してみました。 >>>>>>>>>>>>> active側(lbv1）で下記コマンドを実行したところ、standby側(lbv2)ノードはリブートされました。 >>>>>>>>>>>>> >>>>>>>>>>>>> # stonith -t external/xen0 > hostlist="lbv2.beta.com:/etc/xen/lbv2.cfg" > dom0="dom0.xxxx.com" reset_method="reboot" -T reset > lbv2.beta.com >>>>>>>>>>>> >>>>>>>>>>>> ということでいけば、xen0の単体では動作は問題ないということになります。 >>>>>>>>>>>> >>>>>>>>>>>>> その後の状態ですが、リブートされたlbv2側でメッセージが出続けています。 >>>>>>>>>>>>> >>>>>>>>>>>>> 2015 Mar 4 09:56:56 lbv2 > [3387]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>> 2015 Mar 4 09:57:11 lbv2 > [3508]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>> 2015 Mar 4 09:57:26 lbv2 > [3629]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> こちらは、コマンド実行でない場合のログと思いますが、どうやら、pacemaker経由のexternal/stonith-helper以降が実行されないのが問題のようです。 >>>>>>>>>>>> >>>>>>>>>>>> 新しめのpacemakerとはパラメータも異なっている為、こちらでも構成は違ってしまいますが、stonith-helper、sshなどの組合せでどうなるか確認してみます。 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 以上です。 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: Masamichi Fukuda - > elf-systems <masamichi_fukud****@elf-s*****> >>>>>>>>>>>>> To: 山内英生 > <renay****@ybb*****> >>>>>>>>>>>>> Cc: Masamichi Fukuda - > elf-systems <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >>>>>>>>>>>> >>>>>>>>>>>>> Date: 2015/3/4, Wed 10:16 >>>>>>>>>>>>> Subject: Re: [Linux-ha-jp] > スプリットブレイン時のSTONITHエラーについて >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 山内さん >>>>>>>>>>>>> >>>>>>>>>>>>> おはようございます、福田です。 >>>>>>>>>>>>> ご連絡ありがとうございます。 >>>>>>>>>>>>> >>>>>>>>>>>>> 早速STONITHコマンドを試してみました。 >>>>>>>>>>>>> active側(lbv1）で下記コマンドを実行したところ、standby側(lbv2)ノードはリブートされました。 >>>>>>>>>>>>> >>>>>>>>>>>>> # stonith -t external/xen0 > hostlist="lbv2.beta.com:/etc/xen/lbv2.cfg" > dom0="dom0.xxxx.com" reset_method="reboot" -T reset > lbv2.beta.com >>>>>>>>>>>>> >>>>>>>>>>>>> その後の状態ですが、リブートされたlbv2側でメッセージが出続けています。 >>>>>>>>>>>>> >>>>>>>>>>>>> 2015 Mar 4 09:56:56 lbv2 > [3387]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>> 2015 Mar 4 09:57:11 lbv2 > [3508]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>> 2015 Mar 4 09:57:26 lbv2 > [3629]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> active(lbv1)側のログです。 >>>>>>>>>>>>> Mar 04 09:54:40 lbv1.beta.com > info: Node lbv2.beta.com is member. >>>>>>>>>>>>> Mar 04 09:55:56 lbv1.beta.com > info: Set DC node to lbv1.beta.com. >>>>>>>>>>>>> Mar 04 09:58:15 lbv1.beta.com > info: Start "pengine" process. >>>>>>>>>>>>> Mar 04 09:58:19 lbv1.beta.com > info: Set DC node to lbv1.beta.com. >>>>>>>>>>>>> >>>>>>>>>>>>> standby(lbv2)側のログです。 >>>>>>>>>>>>> Mar 04 09:54:32 lbv2.beta.com > info: Starting Heartbeat 3.0.5. >>>>>>>>>>>>> Mar 04 09:54:32 lbv2.beta.com > info: Link lbv1.beta.com:eth1 is up. >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "crmd" process. (pid=2938) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "cib" process. (pid=2934) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "lrmd" process. (pid=2935) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "attrd" process. (pid=2937) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "ccm" process. (pid=2933) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "stonithd" process. (pid=2936) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > info: Start "ipfail" process. (pid=2932) >>>>>>>>>>>>> Mar 04 09:54:39 lbv2.beta.com > WARN: Managed "ipfail" process exited. (pid=2932, rc=100) >>>>>>>>>>>>> Mar 04 09:56:15 lbv2.beta.com > info: Start "pengine" process. >>>>>>>>>>>>> Mar 04 09:56:19 lbv2.beta.com > info: Set DC node to lbv2.beta.com. >>>>>>>>>>>>> Mar 04 09:56:23 lbv2.beta.com > ERROR: Start to fail-over. >>>>>>>>>>>>> Mar 04 09:56:25 lbv2.beta.com > info: Resource Stonith1-1 started. (rc=0) >>>>>>>>>>>>> Mar 04 09:56:26 lbv2.beta.com > info: Resource Stonith1-2 started. (rc=0) >>>>>>>>>>>>> Mar 04 09:56:26 lbv2.beta.com > info: Resource Stonith1-3 started. (rc=0) >>>>>>>>>>>>> >>>>>>>>>>>>> crm_monではどちらのノードもlbv2がpending状態で表示されています。 >>>>>>>>>>>>> >>>>>>>>>>>>> active(lbv1)側のcrm_monです。（一部） >>>>>>>>>>>>> Node lbv2.beta.com > (82ffc36f-1ad8-8686-7db0-35686465c624): pending >>>>>>>>>>>>> Online: [ lbv1.beta.com ] >>>>>>>>>>>>> >>>>>>>>>>>>> standby(lbv2)側のcrm_monです。（一部） >>>>>>>>>>>>> Node lbv2.beta.com > (82ffc36f-1ad8-8686-7db0-35686465c624): pending >>>>>>>>>>>>> Online: [ lbv1.beta.com ] >>>>>>>>>>>>> >>>>>>>>>>>>> 宜しくお願いします。 >>>>>>>>>>>>> >>>>>>>>>>>>> 以上 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015年3月4日 9:05 > <renay****@ybb*****>: >>>>>>>>>>>>> >>>>>>>>>>>>> 福田さん >>>>>>>>>>>>>> >>>>>>>>>>>>>> おはようございます。山内です。 >>>>>>>>>>>>>> >>>>>>>>>>>>>> １点、先に試して頂きたいstonithコマンドについてご連絡しておきます。 >>>>>>>>>>>>>> >>>>>>>>>>>>>> xen0が動いていないかも知れないとのことですので、以下を参照してxen0を個別で実行してみると良いとおもいます。 >>>>>>>>>>>>>> >>>>>>>>>>>>>> ●stonithコマンドの例(例はlibvirt) >>>>>>>>>>>>>> stonith -t external/libvirt > hostlist="xx01" hypervisor_uri="xxxxx" > reset_method="reboot" -T reset ap01 >>>>>>>>>>>>>> >>>>>>>>>>>>>> PM1.1.7でも動くとは思いますが、コマンドライン的には >>>>>>>>>>>>>> >>>>>>>>>>>>>> stonith -t 実行するstonithプラグイン > パラメータ１・・・パラメータN -T 実行動作 stonithするホスト >>>>>>>>>>>>>> >>>>>>>>>>>>>> です。 >>>>>>>>>>>>>> xen0単体の実行でも、stonithを実行するホストから相手（故障を想定）ホストをこのコマンドで実行できます。 >>>>>>>>>>>>>> >>>>>>>>>>>>>> まずは、xen0の動作を確認してみてください。 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 以上です。 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>> From: Masamichi Fukuda - > elf-systems <masamichi_fukud****@elf-s*****> >>>>>>>>>>>>>>> To: 山内英生 > <renay****@ybb*****> >>>>>>>>>>>>>>> Cc: Masamichi Fukuda - > elf-systems <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Date: 2015/3/3, Tue > 10:43 >>>>>>>>>>>>>>> Subject: Re: > [Linux-ha-jp] スプリットブレイン時のSTONITHエラーについて >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 山内さん >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> お世話になります、福田です。 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> お忙しいところすみませんが、宜しくお願いします。 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015年3月3日 9:27 > <renay****@ybb*****>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 福田さん >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> こんにちは、山内です。 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 詳細は失念していますので、明日にでもまたご連絡しますが。。。。 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> stonithモジュールの単体の実行をstonithコマンドで試せますので、 >>>>>>>>>>>>>>>> xen0の実行をパラメータも指定して実行してみた方がよさそうです。 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> また、明日にでもお送りいただいた設定ファイルの中身も含めて、確認して >>>>>>>>>>>>>>>> ご連絡しますね。 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 以上です。 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ----- Original > Message ----- >>>>>>>>>>>>>>>>> From: Masamichi > Fukuda - elf-systems <masamichi_fukud****@elf-s*****> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To: 山内英生 > <renay****@ybb*****> >>>>>>>>>>>>>>>>> Cc: Masamichi > Fukuda - elf-systems <masamichi_fukud****@elf-s*****>; > "linux****@lists*****" > <linux****@lists*****> >>>>>>>>>>>>>>>>> Date: 2015/3/2, > Mon 12:10 >>>>>>>>>>>>>>>>> Subject: Re: > [Linux-ha-jp] スプリットブレイン時のSTONITHエラーについて >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 山内さん >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> こんにちは、福田です。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 前回と同じようにインターコネクトlanのインタフェースをdownさせてみましたが、 >>>>>>>>>>>>>>>>> やはり次のstonithモジュール(xen0)が実行されないようです。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> サービスlanのインタフェースをdownさせると、ノード２にフィエルオーバします。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> crmの設定ファイルは次のようにしています。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ### Cluster > Option ### >>>>>>>>>>>>>>>>> property \ >>>>>>>>>>>>>>>>> > no-quorum-policy="ignore" \ >>>>>>>>>>>>>>>>> > stonith-enabled="true" \ >>>>>>>>>>>>>>>>> > startup-fencing="false" \ >>>>>>>>>>>>>>>>> > stonith-timeout="710s" \ >>>>>>>>>>>>>>>>> > crmd-transition-delay="2s" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ### Resource > Default ### >>>>>>>>>>>>>>>>> rsc_defaults > \ >>>>>>>>>>>>>>>>> > resource-stickiness="INFINITY" \ >>>>>>>>>>>>>>>>> > migration-threshold="1" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ### Group > Configuration ### >>>>>>>>>>>>>>>>> group HAvarnish > \ >>>>>>>>>>>>>>>>> vip_208 > \ >>>>>>>>>>>>>>>>> varnishd >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> group > grpStonith1 \ >>>>>>>>>>>>>>>>> Stonith1-1 > \ >>>>>>>>>>>>>>>>> Stonith1-2 > \ >>>>>>>>>>>>>>>>> Stonith1-3 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> group > grpStonith2 \ >>>>>>>>>>>>>>>>> Stonith2-1 > \ >>>>>>>>>>>>>>>>> Stonith2-2 > \ >>>>>>>>>>>>>>>>> Stonith2-3 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ### Clone > Configuration ### >>>>>>>>>>>>>>>>> clone clone_ping > \ >>>>>>>>>>>>>>>>> ping >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ### Primitive > Configuration ### >>>>>>>>>>>>>>>>> primitive > vip_208 ocf:heartbeat:IPaddr2 \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > ip="192.168.17.208" \ >>>>>>>>>>>>>>>>> > nic="eth0" \ >>>>>>>>>>>>>>>>> > cidr_netmask="24" \ >>>>>>>>>>>>>>>>> op start > interval="0s" timeout="90s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> op monitor > interval="5s" timeout="60s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> op stop > interval="0s" timeout="100s" on-fail="fence" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> primitive > varnishd lsb:varnish \ >>>>>>>>>>>>>>>>> op start > interval="0s" timeout="90s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> op monitor > interval="10s" timeout="60s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> op stop > interval="0s" timeout="100s" on-fail="fence" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> primitive ping > ocf:pacemaker:ping \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > name="default_ping_set" \ >>>>>>>>>>>>>>>>> > host_list="192.168.17.254" \ >>>>>>>>>>>>>>>>> > multiplier="100" \ >>>>>>>>>>>>>>>>> > dampen="1" \ >>>>>>>>>>>>>>>>> op start > interval="0s" timeout="90s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> op monitor > interval="10s" timeout="60s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> op stop > interval="0s" timeout="100s" on-fail="fence" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> primitive > Stonith1-1 stonith:external/stonith-helper \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > priority="1" \ >>>>>>>>>>>>>>>>> > stonith-timeout="40" \ >>>>>>>>>>>>>>>>> > hostlist="lbv1.beta.com" \ >>>>>>>>>>>>>>>>> > dead_check_target="192.168.17.132 10.0.17.132" \ >>>>>>>>>>>>>>>>> > standby_wait_time="10" \ >>>>>>>>>>>>>>>>> > standby_check_command="/usr/sbin/crm_resource -r varnishd -W | grep -q > `hostname`" \ >>>>>>>>>>>>>>>>> op start > interval="0s" timeout="60s" on-fail="restart" > \ >>>>>>>>>>>>>>>>> > stonith-timeout="300" \ >>>>>>>>>>>>>>>>> > hostlist="lbv1.beta.com:/etc/xen/lbv1.cfg" \ >>>>>>>>>>>>>>>>> > dom0="dom0.xxxx.com" \ >>>>>>>>>>>>>>>>> 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 > Stonith1-3 stonith:meatware \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > priority="3" \ >>>>>>>>>>>>>>>>> > stonith-timeout="600" \ >>>>>>>>>>>>>>>>> > hostlist="lbv1.beta.com" \ >>>>>>>>>>>>>>>>> op start > interval="0s" timeout="60s" \ >>>>>>>>>>>>>>>>> op monitor > interval="3600s" timeout="60s" \ >>>>>>>>>>>>>>>>> op stop > interval="0s" timeout="60s" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> primitive > Stonith2-1 stonith:external/stonith-helper \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > priority="1" \ >>>>>>>>>>>>>>>>> > stonith-timeout="40" \ >>>>>>>>>>>>>>>>> > hostlist="lbv2.beta.com" \ >>>>>>>>>>>>>>>>> > dead_check_target="192.168.17.133 10.0.17.133" \ >>>>>>>>>>>>>>>>> > standby_wait_time="10" \ >>>>>>>>>>>>>>>>> > standby_check_command="/usr/sbin/crm_resource -r varnishd -W | grep -q > `hostname`" \ >>>>>>>>>>>>>>>>> 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 > Stonith2-2 stonith:external/xen0 \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > priority="2" \ >>>>>>>>>>>>>>>>> > stonith-timeout="300" \ >>>>>>>>>>>>>>>>> > hostlist="lbv2.beta.com:/etc/xen/lbv2.cfg" \ >>>>>>>>>>>>>>>>> > dom0="dom0.xxxx.com" \ >>>>>>>>>>>>>>>>> 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 > Stonith2-3 stonith:meatware \ >>>>>>>>>>>>>>>>> params \ >>>>>>>>>>>>>>>>> > priority="3" \ >>>>>>>>>>>>>>>>> > stonith-timeout="600" \ >>>>>>>>>>>>>>>>> > hostlist="lbv2.beta.com" \ >>>>>>>>>>>>>>>>> op start > interval="0s" timeout="60s" \ >>>>>>>>>>>>>>>>> op monitor > interval="3600s" timeout="60s" \ >>>>>>>>>>>>>>>>> op stop > interval="0s" timeout="60s" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ### Resource > Location ### >>>>>>>>>>>>>>>>> location > HA_location-1 HAvarnish \ >>>>>>>>>>>>>>>>> rule 200: > #uname eq lbv1.beta.com \ >>>>>>>>>>>>>>>>> rule 100: > #uname eq lbv2.beta.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> location > HA_location-2 HAvarnish \ >>>>>>>>>>>>>>>>> rule > -INFINITY: not_defined default_ping_set or default_ping_set lt 100 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> location > HA_location-3 grpStonith1 \ >>>>>>>>>>>>>>>>> rule > -INFINITY: #uname eq lbv1.beta.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> location > HA_location-4 grpStonith2 \ >>>>>>>>>>>>>>>>> rule > -INFINITY: #uname eq lbv2.beta.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DomU(lbv1とlbv2）からDom0へはrootでssh、パスワードなしでログインできるようにはなっています。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> xen0のパラメータで不足分ありますでしょうか。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 宜しくお願いします。 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 以上 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015年3月1日 16:54 > <renay****@ybb*****>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 福田さん >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> こんにちは、山内です。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 流れ的には正常です。 >>>>>>>>>>>>>>>>>> ただ、helperの次のstonithモジュール(xen0)が実行されていないようなので、こちらは問題です。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ただ、先にも書きましたが、pacemakerのバージョンでfencing_topologyがどうなっているか？ >>>>>>>>>>>>>>>>>> ＃お使いの1.1.7で使えるかどうか・・・ちょっと定かではありません。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 後はstonithモジュールもパラメータでリトライの回数や、タイムアウトなども設定できたりもしているので、 >>>>>>>>>>>>>>>>>> そのあたりも見直してみた方がよいかも知れません。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #fencing_topologyがないと、1.1.12あたりでは、stonithの実行順番も制御できないはずなので・・・ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> まずは、試していただいて、開示できる範囲で、crmファイルの全体も見せて頂いたほうが良いかも知れませんね。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> また、可能であれば、1.1.12あたりの利用も考えてもらったほうが良いかも知れません。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ＃すいません、個人的な理由で、水曜日あたりまでは、あまりメールの反応がよくないかも知れません。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 以上です。 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ----- > Original Message ----- >>>>>>>>>>>>>>>>>>> From: > Masamichi Fukuda - elf-systems <masamichi_fukud****@elf-s*****> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> To: > renay****@ybb*****; linux****@lists***** >>>>>>>>>>>>>>>>>>> Date: > 2015/3/1, Sun 12:09 >>>>>>>>>>>>>>>>>>> Subject: > Re: [Linux-ha-jp] スプリットブレイン時のSTONITHエラーについて >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 山内さん >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 福田です。 >>>>>>>>>>>>>>>>>>> ご回答ありがとうございます。 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 今の状態は正常なんですね。 >>>>>>>>>>>>>>>>>>> それでは明日、サービスネットワークを切って試してみたいと思います。 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > crm設定ファイルのfencing_topologyの設定を見直してみた方がよいと思います。 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> fencing_topologyという設定はまだ入れていなかったです。 >>>>>>>>>>>>>>>>>>> こちらを入れないと正しく動かないのでしょうか。 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 宜しくお願いします。 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 以上 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2015年2月28日 > 7:41 <renay****@ybb*****>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 福田さん >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> おはようございます。山内です。 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> インターコネクト(10.0.17.X)が切れて、サービスネットワーク(192.168.17.X)が切れていない状態となっている >>>>>>>>>>>>>>>>>>>> と思いますので、stonith-helperは、1を返して失敗しているはずです。（正しい検知） >>>>>>>>>>>>>>>>>>>> その後、stonith-helperが失敗して、xen0,meatwareの順に実行が続くはずですので。。。 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> crm設定ファイルのfencing_topologyの設定を見直してみた方がよいと思います。 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> もしかすると、pacemaker1.1.7あたりでは、fencing_topologyが使えなかったかも？しれません・・・ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> fencing_topologyあたりの処理は、かなり、pacemaker1.1.12まで修正が入って動くようになりましたので、 >>>>>>>>>>>>>>>>>>>> pacemakerのバージョンアップも必要かも知れません。 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 以上です。 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ----- > Original Message ----- >>>>>>>>>>>>>>>>>>>>> From: > Masamichi Fukuda - elf-systems <masamichi_fukud****@elf-s*****> >>>>>>>>>>>>>>>>>>>>> To: > linux****@lists***** >>>>>>>>>>>>>>>>>>>>> Date: > 2015/2/27, Fri 21:04 >>>>>>>>>>>>>>>>>>>>> Subject: > [Linux-ha-jp] スプリットブレイン時のSTONITHエラーについて >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> お世話になります、福田と申します。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> debian > Xen上で２ノードのクラスタシステムを構築して検証をしています。 >>>>>>>>>>>>>>>>>>>>> Xen上でのstonith使用時のエラーについて質問させて頂きます。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 環境： >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Dom0はdebian7.7, > Xen 4.1.4-3+deb7u3 >>>>>>>>>>>>>>>>>>>>> DomUはdebian7.8, > pacemaker 1.1.7-1, heartbeat 1:3.0.5-3 >>>>>>>>>>>>>>>>>>>>> 同一Dom0上にクラスタ2台を構築しています。 >>>>>>>>>>>>>>>>>>>>> pacemaker,heartbeatはdebianパッケージでインストールしています。 >>>>>>>>>>>>>>>>>>>>> stonith-helper,xen0,meatwareプラグインを使用 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ノード１(active)側のインターコネクト用LANインタフェースをダウンさせて、 >>>>>>>>>>>>>>>>>>>>> スプリットブレインを発生させ、STONITHを行わせようとしています。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 両ノードのcrm_monでは下記のようにお互いをuncleanと表示しています。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ノード１側 >>>>>>>>>>>>>>>>>>>>> Node > lbv2.beta.com (82ffc36f-1ad8-8686-7db0-35686465c624): UNCLEAN (offl >>>>>>>>>>>>>>>>>>>>> ine) >>>>>>>>>>>>>>>>>>>>> Online: > [ lbv1.beta.com ] >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ノード２側 >>>>>>>>>>>>>>>>>>>>> Node > lbv1.beta.com (38b0f200-83ea-8633-6f37-047d36cd39c6): UNCLEAN (offl >>>>>>>>>>>>>>>>>>>>> ine) >>>>>>>>>>>>>>>>>>>>> Online: > [ lbv2.beta.com ] >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ところがエラーメッセージが次のようにでてしまいます。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ノード１側 >>>>>>>>>>>>>>>>>>>>> lbv1 > [12657]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv2.beta.com failed with rc 1 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ノード２側 >>>>>>>>>>>>>>>>>>>>> lbv2 > [22225]: CRIT: external_reset_req: 'stonith-helper reset' for host > lbv1.beta.com failed with rc 1 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 質問 >>>>>>>>>>>>>>>>>>>>> この状態はSTONITHが動いておらず、stonith-helperのパラメータがおかしいのでしょうか？ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> パラメータは次のようにしています。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> primitive > Stonith1-1 stonith:external/stonith-helper \ >>>>>>>>>>>>>>>>>>>>> > params \ >>>>>>>>>>>>>>>>>>>>> > priority="1" \ >>>>>>>>>>>>>>>>>>>>> > stonith-timeout="40" \ >>>>>>>>>>>>>>>>>>>>> > hostlist="lbv1.beta.com" \ >>>>>>>>>>>>>>>>>>>>> > dead_check_target="192.168.17.132 10.0.17.132" \ >>>>>>>>>>>>>>>>>>>>> > standby_wait_time="10" \ >>>>>>>>>>>>>>>>>>>>> > standby_check_command="/usr/sbin/crm_resource -r varnishd -W | grep -q > `hostname`" \ >>>>>>>>>>>>>>>>>>>>> > 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 > Stonith2-1 stonith:external/stonith-helper \ >>>>>>>>>>>>>>>>>>>>> > params \ >>>>>>>>>>>>>>>>>>>>> > priority="1" \ >>>>>>>>>>>>>>>>>>>>> > stonith-timeout="40" \ >>>>>>>>>>>>>>>>>>>>> > hostlist="lbv2.beta.com" \ >>>>>>>>>>>>>>>>>>>>> > dead_check_target="192.168.17.133 10.0.17.133" \ >>>>>>>>>>>>>>>>>>>>> > standby_wait_time="10" \ >>>>>>>>>>>>>>>>>>>>> > standby_check_command="/usr/sbin/crm_resource -r varnishd -W | grep -q > `hostname`" \ >>>>>>>>>>>>>>>>>>>>> > 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" >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 192.168.17.0がサービス用、10.0.17.0がインターコネクト用に使用しているサブネットです。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ログは下記の通りです。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:04 lbv1.beta.com stonith: [18566]: CRIT: external_reset_req >>>>>>>>>>>>>>>>>>>>> : > 'stonith-helper reset' for host lbv2.beta.com failed with rc 1 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:04 lbv1.beta.com stonith-ng: [2815]: ERROR: log_operation: >>>>>>>>>>>>>>>>>>>>> Operation > 'reboot' [18565] (call 0 from d2acf6a5-ef8d-4249-aaab-25a8686d6647) fo >>>>>>>>>>>>>>>>>>>>> r > host 'lbv2.beta.com' with device 'Stonith2-1' returned: -2 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:04 lbv1.beta.com stonith-ng: [2815]: ERROR: log_operation: >>>>>>>>>>>>>>>>>>>>> Stonith2-1: > Performing: stonith -t external/stonith-helper -T reset lbv2. >>>>>>>>>>>>>>>>>>>>> -beta.com >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:04 lbv1.beta.com stonith-ng: [2815]: ERROR: log_operation: >>>>>>>>>>>>>>>>>>>>> Stonith2-1: > failed: lbv2.beta.com 5 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:05 lbv1.beta.com stonith-ng: [2815]: info: call_remote_ston >>>>>>>>>>>>>>>>>>>>> ith: > Requesting that lbv1.beta.com perform op reboot lbv2.beta.c >>>>>>>>>>>>>>>>>>>>> om >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:05 lbv1.beta.com stonith-ng: [2815]: info: can_fence_host_w >>>>>>>>>>>>>>>>>>>>> ith_device: > Stonith2-1 can fence lbv2.beta.com: dynamic-list >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:05 lbv1.beta.com stonith-ng: [2815]: info: can_fence_host_w >>>>>>>>>>>>>>>>>>>>> ith_device: > Stonith2-2 can fence lbv2.beta.com: dynamic-list >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:05 lbv1.beta.com stonith-ng: [2815]: info: can_fence_host_w >>>>>>>>>>>>>>>>>>>>> ith_device: > Stonith2-3 can fence lbv2.beta.com: dynamic-list >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:05 lbv1.beta.com stonith-ng: [2815]: info: stonith_fence: F >>>>>>>>>>>>>>>>>>>>> ound > 3 matching devices for 'lbv2.beta.com' >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:05 lbv1.beta.com stonith-ng: [2815]: info: stonith_command: >>>>>>>>>>>>>>>>>>>>> Processed > st_fence from lbv1.beta.com: rc=-1 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:08 lbv1.beta.com crm_resource: [18790]: info: Invoked: /usr >>>>>>>>>>>>>>>>>>>>> /sbin/crm_resource > -r varnishd -W >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:09 lbv1.beta.com stonith: [18706]: CRIT: external_reset_req >>>>>>>>>>>>>>>>>>>>> : > 'stonith-helper reset' for host lbv2.beta.com failed with rc 1 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:09 lbv1.beta.com stonith-ng: [2815]: ERROR: log_operation: >>>>>>>>>>>>>>>>>>>>> Operation > 'reboot' [18705] (call 0 from d2acf6a5-ef8d-4249-aaab-25a8686d6647) fo >>>>>>>>>>>>>>>>>>>>> r > host 'lbv2.beta.com' with device 'Stonith2-1' returned: -2 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:09 lbv1.beta.com stonith-ng: [2815]: ERROR: log_operation: >>>>>>>>>>>>>>>>>>>>> Stonith2-1: > Performing: stonith -t external/stonith-helper -T reset lbv2. >>>>>>>>>>>>>>>>>>>>> -beta.com >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:09 lbv1.beta.com stonith-ng: [2815]: ERROR: log_operation: >>>>>>>>>>>>>>>>>>>>> Stonith2-1: > failed: lbv2.beta.com 5 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:10 lbv1.beta.com stonith-ng: [2815]: info: call_remote_ston >>>>>>>>>>>>>>>>>>>>> ith: > Requesting that lbv1.beta.com perform op reboot lbv2.beta.c >>>>>>>>>>>>>>>>>>>>> om >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:10 lbv1.beta.com stonith-ng: [2815]: info: can_fence_host_w >>>>>>>>>>>>>>>>>>>>> ith_device: > Stonith2-1 can fence lbv2.beta.com: dynamic-list >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:10 lbv1.beta.com stonith-ng: [2815]: info: can_fence_host_w >>>>>>>>>>>>>>>>>>>>> ith_device: > Stonith2-2 can fence lbv2.beta.com: dynamic-list >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:10 lbv1.beta.com stonith-ng: [2815]: info: can_fence_host_w >>>>>>>>>>>>>>>>>>>>> ith_device: > Stonith2-3 can fence lbv2.beta.com: dynamic-list >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:10 lbv1.beta.com stonith-ng: [2815]: info: stonith_fence: F >>>>>>>>>>>>>>>>>>>>> ound > 3 matching devices for 'lbv2.beta.com' >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:10 lbv1.beta.com stonith-ng: [2815]: info: stonith_command: >>>>>>>>>>>>>>>>>>>>> Processed > st_fence from lbv1.beta.com: rc=-1 >>>>>>>>>>>>>>>>>>>>> Feb > 27 19:29:13 lbv1.beta.com crm_resource: [18953]: info: Invoked: /usr >>>>>>>>>>>>>>>>>>>>> /sbin/crm_resource > -r varnishd -W >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 宜しくお願いします。 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ELF > Systems >>>>>>>>>>>>>>>>>>>>> Masamichi > Fukuda >>>>>>>>>>>>>>>>>>>>> mail > to: masamichi_fukud****@elf-s***** >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> Linux-ha-japan > mailing list >>>>>>>>>>>>>>>>>>>>> Linux****@lists***** >>>>>>>>>>>>>>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> Linux-ha-japan > mailing list >>>>>>>>>>>>>>>>>>>> Linux****@lists***** >>>>>>>>>>>>>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ELF > Systems >>>>>>>>>>>>>>>>>>> Masamichi > Fukuda >>>>>>>>>>>>>>>>>>> mail to: > masamichi_fukud****@elf-s***** >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ELF Systems >>>>>>>>>>>>>>>>> Masamichi Fukuda >>>>>>>>>>>>>>>>> mail to: > masamichi_fukud****@elf-s***** >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ELF Systems >>>>>>>>>>>>>>> Masamichi Fukuda >>>>>>>>>>>>>>> mail to: > masamichi_fukud****@elf-s***** >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> ELF Systems >>>>>>>>>>>>> Masamichi Fukuda >>>>>>>>>>>>> mail to: > masamichi_fukud****@elf-s***** >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ELF Systems >>>>>>>>>>> Masamichi Fukuda >>>>>>>>>>> mail to: > masamichi_fukud****@elf-s***** >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> ELF Systems >>>>>>>>> Masamichi Fukuda >>>>>>>>> mail to: masamichi_fukud****@elf-s***** >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ELF Systems >>>>>>> Masamichi Fukuda >>>>>>> mail to: masamichi_fukud****@elf-s***** >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ELF Systems >>>>>> Masamichi Fukuda >>>>>> mail to: masamichi_fukud****@elf-s***** >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> >>>> ELF Systems >>>> Masamichi Fukuda >>>> mail to: masamichi_fukud****@elf-s***** >>>> >>>> >>> >>> >> >> -- >> >> ELF Systems >> Masamichi Fukuda >> mail to: masamichi_fukud****@elf-s***** >> >> >> > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan >
Fork