[Linux-ha-jp] スプリットブレイン時のSTONITHエラーについて

Back to archive index

renay****@ybb***** renay****@ybb*****
2015年 3月 5日 (木) 22:30:40 JST


福田さん

こんばんは、山内です。

もしかして、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 です。
>
>まずはノード1の一台だけアップグレードして状態をみました。
>
>バージョンアップしていないノード2側の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
>
>ノード2のpacemakerを起動してcrm_monで見るとpending状態です。
>
>Node lbv1.beta.com (38b0f200-83ea-8633-6f37-047d36cd39c6): pending
>Online: [ lbv2.beta.com ]
>
>これで数分すると、バージョンアップしたノード1がリブートを繰り返します。
>
>一度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などのパラメータにより実行回数をパラメータで
>>>>>指定できるようになっています。
>>>>>
>>>>>正常なFO動作(stonith実行~再起動。。)を行うには、やはり、pacemakerのバージョンアップを行うか、
>>>>>3つの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*****>:
>>>>>>>>
>>>>>>>>福田さん
>>>>>>>>>
>>>>>>>>>おはようございます。山内です。
>>>>>>>>>
>>>>>>>>>1点、先に試して頂きたい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プラグイン パラメータ1・・・パラメータ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させると、ノード2にフィエルオーバします。
>>>>>>>>>>>>
>>>>>>>>>>>>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上で2ノードのクラスタシステムを構築して検証をしています。
>>>>>>>>>>>>>>>>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プラグインを使用
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>ノード1(active)側のインターコネクト用LANインタフェースをダウンさせて、
>>>>>>>>>>>>>>>>スプリットブレインを発生させ、STONITHを行わせようとしています。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>両ノードのcrm_monでは下記のようにお互いをuncleanと表示しています。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>ノード1側
>>>>>>>>>>>>>>>>Node lbv2.beta.com (82ffc36f-1ad8-8686-7db0-35686465c624): UNCLEAN (offl
>>>>>>>>>>>>>>>>ine)
>>>>>>>>>>>>>>>>Online: [ lbv1.beta.com ]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>ノード2側
>>>>>>>>>>>>>>>>Node lbv1.beta.com (38b0f200-83ea-8633-6f37-047d36cd39c6): UNCLEAN (offl
>>>>>>>>>>>>>>>>ine)
>>>>>>>>>>>>>>>>Online: [ lbv2.beta.com ]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>ところがエラーメッセージが次のようにでてしまいます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>ノード1側
>>>>>>>>>>>>>>>>lbv1 [12657]: CRIT: external_reset_req: 'stonith-helper reset' for host lbv2.beta.com failed with rc 1
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>ノード2側
>>>>>>>>>>>>>>>>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*****
>
>
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
다운로드 



Linux-ha-japan メーリングリストの案内
Back to archive index