Mailing List Archive

リソースエージェントの再起動動作について
関係者各位

お世話になっております。nakaと申します。

環境:
2ノード構成(pacemaker+heartbeat) ※nodeA,nodeBとします。
OS:CentOS6.2(x86_64)
pacemaker-1.0.12-1.el6.x86_64
heartbeat-3.0.5-1.1.el6.x86_64

nodeAで全てのグループリソースを起動させた状態で、
nodeBでの障害時動作を確認しております。

/etc/init.d/heartbeat stop
/etc/init.d/heartbeat start

nodeBでheartbeatデーモンを上記コマンドでstop/startさせたところ、
startを実行後になぜかnodeA側で動いている[lsb:initスクリプト名]の
RAが停止してしまい、その後すぐにRAはstartしました。

想定動作としては、stopせずにそのまま起動させておきたいのですが、
上記動作の原因と、どのように設定したらよいかをご教授頂けませんでしょうか?


参考までにheartbeatデーモンをstop/startさせた時のシスログを添付しておきます。
以下、crmの設定内容となります。
$ sudo crm configure show

node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" nodeA
node $id="4a851515-443f-6140-b38f-dfb4bb46c010" nodeB
primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
meta migration-threshold="5" \
params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
op monitor interval="3s"
primitive res_ping ocf:pacemaker:ping \
params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200"
dampen="1" debug="true" attempts="10" \
op monitor interval="10s" timeout="60" \
op start interval="0" timeout="60"
primitive service_naka01v lsb:pkg_naka01v \
op start interval="0s" timeout="90s" \
op monitor interval="300s" timeout="20s" \
op stop interval="0s" timeout="100s" \
meta is-managed="true"
primitive service_sfdb01v lsb:pkg_sfdb01v \
op start interval="0s" timeout="90s" \
op monitor interval="300s" timeout="20s" \
op stop interval="0s" timeout="100s" \
meta is-managed="true"
primitive vgsfdb01v ocf:heartbeat:LVM \
params volgrpname="vgsfdb01v"
primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
meta migration-threshold="5" \
params device="/dev/vgsfdb01v/LogVol00" fstype="ext4"
directory="/mysf" \
op monitor interval="20s"
primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
params index="1" device="/dev/vgsfdb01v/lv_quorum"
group pkg_naka01v service_naka01v \
meta is-managed="true" target-role="Started"
group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum
vgsfdb01v_LogVol00 service_sfdb01v \
meta is-managed="true" target-role="Started"
clone clone_ping res_ping \
meta target-role="Started"
location pkg_naka01v-location pkg_naka01v \
rule $id="pkg_naka01v-location-0" 200: #uname eq nodeA \
rule $id="pkg_naka01v-location-1" 100: #uname eq nodeB
location pkg_naka01v-service-location pkg_naka01v \
rule $id="pkg_naka01v-service-location-rule" -inf: defined
eth0_ping_set and eth0_ping_set lt 200
location pkg_sfdb01v-location pkg_sfdb01v \
rule $id="pkg_sfdb01v-location-0" 200: #uname eq nodeA \
rule $id="pkg_sfdb01v-location-1" 100: #uname eq nodeB
location pkg_sfdb01v-service-location pkg_sfdb01v \
rule $id="pkg_sfdb01v-service-location-rule" -inf: defined
eth0_ping_set and eth0_ping_set lt 200
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="1441681923"
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY"

お手数おかけ致しますが、何卒宜しくお願い致します。
以上

--
Naka
Re: リソースエージェントの再起動動作について [ In reply to ]
申し訳ありません。添付漏れです。

2015年11月24日 17:20 Keisuke Nakamura <k.xnakamu@gmail.com>:

> 関係者各位
>
> お世話になっております。nakaと申します。
>
> 環境:
> 2ノード構成(pacemaker+heartbeat) ※nodeA,nodeBとします。
> OS:CentOS6.2(x86_64)
> pacemaker-1.0.12-1.el6.x86_64
> heartbeat-3.0.5-1.1.el6.x86_64
>
> nodeAで全てのグループリソースを起動させた状態で、
> nodeBでの障害時動作を確認しております。
>
> /etc/init.d/heartbeat stop
> /etc/init.d/heartbeat start
>
> nodeBでheartbeatデーモンを上記コマンドでstop/startさせたところ、
> startを実行後になぜかnodeA側で動いている[lsb:initスクリプト名]の
> RAが停止してしまい、その後すぐにRAはstartしました。
>
> 想定動作としては、stopせずにそのまま起動させておきたいのですが、
> 上記動作の原因と、どのように設定したらよいかをご教授頂けませんでしょうか?
>
>
> 参考までにheartbeatデーモンをstop/startさせた時のシスログを添付しておきます。
> 以下、crmの設定内容となります。
> $ sudo crm configure show
>
> node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" nodeA
> node $id="4a851515-443f-6140-b38f-dfb4bb46c010" nodeB
> primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
> meta migration-threshold="5" \
> params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
> op monitor interval="3s"
> primitive res_ping ocf:pacemaker:ping \
> params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200"
> dampen="1" debug="true" attempts="10" \
> op monitor interval="10s" timeout="60" \
> op start interval="0" timeout="60"
> primitive service_naka01v lsb:pkg_naka01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive service_sfdb01v lsb:pkg_sfdb01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive vgsfdb01v ocf:heartbeat:LVM \
> params volgrpname="vgsfdb01v"
> primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
> meta migration-threshold="5" \
> params device="/dev/vgsfdb01v/LogVol00" fstype="ext4"
> directory="/mysf" \
> op monitor interval="20s"
> primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
> params index="1" device="/dev/vgsfdb01v/lv_quorum"
> group pkg_naka01v service_naka01v \
> meta is-managed="true" target-role="Started"
> group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum
> vgsfdb01v_LogVol00 service_sfdb01v \
> meta is-managed="true" target-role="Started"
> clone clone_ping res_ping \
> meta target-role="Started"
> location pkg_naka01v-location pkg_naka01v \
> rule $id="pkg_naka01v-location-0" 200: #uname eq nodeA \
> rule $id="pkg_naka01v-location-1" 100: #uname eq nodeB
> location pkg_naka01v-service-location pkg_naka01v \
> rule $id="pkg_naka01v-service-location-rule" -inf: defined
> eth0_ping_set and eth0_ping_set lt 200
> location pkg_sfdb01v-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-location-0" 200: #uname eq nodeA \
> rule $id="pkg_sfdb01v-location-1" 100: #uname eq nodeB
> location pkg_sfdb01v-service-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-service-location-rule" -inf: defined
> eth0_ping_set and eth0_ping_set lt 200
> 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="1441681923"
> rsc_defaults $id="rsc-options" \
> resource-stickiness="INFINITY"
>
> お手数おかけ致しますが、何卒宜しくお願い致します。
> 以上
>
> --
> Naka
>



--
Nakamura
Re: リソースエージェントの再起動動作について [ In reply to ]
passは
j2G49di2sd
となります。

2015年11月24日 17:23 Keisuke Nakamura <k.xnakamu@gmail.com>:

> 申し訳ありません。添付漏れです。
>
> 2015年11月24日 17:20 Keisuke Nakamura <k.xnakamu@gmail.com>:
>
> 関係者各位
>>
>> お世話になっております。nakaと申します。
>>
>> 環境:
>> 2ノード構成(pacemaker+heartbeat) ※nodeA,nodeBとします。
>> OS:CentOS6.2(x86_64)
>> pacemaker-1.0.12-1.el6.x86_64
>> heartbeat-3.0.5-1.1.el6.x86_64
>>
>> nodeAで全てのグループリソースを起動させた状態で、
>> nodeBでの障害時動作を確認しております。
>>
>> /etc/init.d/heartbeat stop
>> /etc/init.d/heartbeat start
>>
>> nodeBでheartbeatデーモンを上記コマンドでstop/startさせたところ、
>> startを実行後になぜかnodeA側で動いている[lsb:initスクリプト名]の
>> RAが停止してしまい、その後すぐにRAはstartしました。
>>
>> 想定動作としては、stopせずにそのまま起動させておきたいのですが、
>> 上記動作の原因と、どのように設定したらよいかをご教授頂けませんでしょうか?
>>
>>
>> 参考までにheartbeatデーモンをstop/startさせた時のシスログを添付しておきます。
>> 以下、crmの設定内容となります。
>> $ sudo crm configure show
>>
>> node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" nodeA
>> node $id="4a851515-443f-6140-b38f-dfb4bb46c010" nodeB
>> primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
>> meta migration-threshold="5" \
>> params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
>> op monitor interval="3s"
>> primitive res_ping ocf:pacemaker:ping \
>> params name="eth0_ping_set" host_list="10.2.28.1"
>> multiplier="200" dampen="1" debug="true" attempts="10" \
>> op monitor interval="10s" timeout="60" \
>> op start interval="0" timeout="60"
>> primitive service_naka01v lsb:pkg_naka01v \
>> op start interval="0s" timeout="90s" \
>> op monitor interval="300s" timeout="20s" \
>> op stop interval="0s" timeout="100s" \
>> meta is-managed="true"
>> primitive service_sfdb01v lsb:pkg_sfdb01v \
>> op start interval="0s" timeout="90s" \
>> op monitor interval="300s" timeout="20s" \
>> op stop interval="0s" timeout="100s" \
>> meta is-managed="true"
>> primitive vgsfdb01v ocf:heartbeat:LVM \
>> params volgrpname="vgsfdb01v"
>> primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
>> meta migration-threshold="5" \
>> params device="/dev/vgsfdb01v/LogVol00" fstype="ext4"
>> directory="/mysf" \
>> op monitor interval="20s"
>> primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
>> params index="1" device="/dev/vgsfdb01v/lv_quorum"
>> group pkg_naka01v service_naka01v \
>> meta is-managed="true" target-role="Started"
>> group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum
>> vgsfdb01v_LogVol00 service_sfdb01v \
>> meta is-managed="true" target-role="Started"
>> clone clone_ping res_ping \
>> meta target-role="Started"
>> location pkg_naka01v-location pkg_naka01v \
>> rule $id="pkg_naka01v-location-0" 200: #uname eq nodeA \
>> rule $id="pkg_naka01v-location-1" 100: #uname eq nodeB
>> location pkg_naka01v-service-location pkg_naka01v \
>> rule $id="pkg_naka01v-service-location-rule" -inf: defined
>> eth0_ping_set and eth0_ping_set lt 200
>> location pkg_sfdb01v-location pkg_sfdb01v \
>> rule $id="pkg_sfdb01v-location-0" 200: #uname eq nodeA \
>> rule $id="pkg_sfdb01v-location-1" 100: #uname eq nodeB
>> location pkg_sfdb01v-service-location pkg_sfdb01v \
>> rule $id="pkg_sfdb01v-service-location-rule" -inf: defined
>> eth0_ping_set and eth0_ping_set lt 200
>> 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="1441681923"
>> rsc_defaults $id="rsc-options" \
>> resource-stickiness="INFINITY"
>>
>> お手数おかけ致しますが、何卒宜しくお願い致します。
>> 以上
>>
>> --
>> Naka
>>
>
>
>
> --
> Nakamura
>



--
Nakamura
Re: リソースエージェントの再起動動作について [ In reply to ]
naka$BMM(B

$B$$$D$b$*@$OC$K$J$C$F$*$j$^$9!#(B
$BB-N)$H?=$7$^$9!#(B

$BF1$8>u67$H$J$C$?7P83$,$"$k$?$a!";29M$K$J$l$P$H$4O"MmCW$7$^$9!#(B

[lsb:init$B%9%/%j%W%HL>(B] $B$G$9$,!"(BLSB$B$G(Bpacemaker$B%j%=!<%9$r4F;k$9$k>l9g!"(B
/etc/init.d/ $B$KG[CV$9$k5/F0%9%/%j%W%H$,0J2<$N;HMQ$K9gCW$9$kI,MW$,$"$j$^$9!#(B

$B!Z;29M(BURL$B![(B
http://linux-ha.osdn.jp/wp/archives/3855#lsb
$B!V(Bstatus$B!W%a%=%C%I$O%5!<%S%9(B($B%j%=!<%9(B)$B$N>uBV$K1~$80J2<$NF0:n$*$h$SJV$jCM$rJV$9$3$H!#(B
$B!!!&%5!<%S%9$,Dd;_$7$F$$$k>l9g!'(B3$B$rJV$9!#(B
$B!!!&%5!<%S%9$,5/F0$7$F$$$k>l9g!'(B0$B$rJV$9!#(B

$B$*$=$i$/!"(Bpacemaker(heartbeat)$B$,:F5/F0$5$l$?%?%$%_%s%0$G!"(B
$B!!(B# /etc/init.d/<$B%j%=!<%9(B> status
$B$N7k2L$,(B0$B$rJV$9$3$H$K$h$j!"(BActive/Standby$B$NN>J}$G%j%=!<%9$,2TF/$7$F$k$h$&$K8+$(!"(B
$B$3$N>u67$r2r7h$7$h$&$H(Bpacemaker$B$,%j%=!<%9$N:F5/F0$r9T$C$F$$$k2DG=@-$,$"$k$N$G(B
$B$43NG'D:$1$?$i$HB8$8$^$9!#(B

$B"(BT5!7O(Bpacemaker$B:F5/F0;~$K(B
# crm_mon -i 1
$B$J$I$N%3%^%s%I$G%j%=!<%9>u67$r3NG'$9$k$H!"(B
$BN>J}$N%^%7%s$G0l;~E*$K%j%=!<%9$,>e$,$C$F$$$k$h$&$K8+$($F$*$j$^$7$?!#(B

$B0J>e!"59$7$/$*4j$$CW$7$^$9!#(B

2015$BG/(B11$B7n(B24$BF|(B 17:20 Keisuke Nakamura <k.xnakamu@gmail.com>:
> $B4X78<T3F0L(B
>
> $B$*@$OC$K$J$C$F$*$j$^$9!#(Bnaka$B$H?=$7$^$9!#(B
>
> $B4D6-!'(B
> 2$B%N!<%I9=@.(B(pacemaker+heartbeat)$B!!"((BnodeA,nodeB$B$H$7$^$9!#(B
> OS:CentOS6.2(x86_64)
> pacemaker-1.0.12-1.el6.x86_64
> heartbeat-3.0.5-1.1.el6.x86_64
>
> nodeA$B$GA4$F$N%0%k!<%W%j%=!<%9$r5/F0$5$;$?>uBV$G!"(B
> nodeB$B$G$N>c32;~F0:n$r3NG'$7$F$*$j$^$9!#(B
>
> /etc/init.d/heartbeat stop
> /etc/init.d/heartbeat start
>
> nodeB$B$G(Bheartbeat$B%G!<%b%s$r>e5-%3%^%s%I$G(Bstop/start$B$5$;$?$H$3$m!"(B
> start$B$r<B9T8e$K$J$<$+(BnodeA$BB&$GF0$$$F$$$k(B[lsb:init$B%9%/%j%W%HL>(B]$B$N(B
> RA$B$,Dd;_$7$F$7$^$$!"$=$N8e$9$0$K(BRA$B$O(Bstart$B$7$^$7$?!#(B
>
> $BA[DjF0:n$H$7$F$O!"(Bstop$B$;$:$K$=$N$^$^5/F0$5$;$F$*$-$?$$$N$G$9$,!"(B
> $B>e5-F0:n$N860x$H!"$I$N$h$&$K@_Dj$7$?$i$h$$$+$r$465<xD:$1$^$;$s$G$7$g$&$+!)(B
>
>
> $B;29M$^$G$K(Bheartbeat$B%G!<%b%s$r(Bstop/start$B$5$;$?;~$N%7%9%m%0$rE:IU$7$F$*$-$^$9!#(B
> $B0J2<!"(Bcrm$B$N@_DjFbMF$H$J$j$^$9!#(B
> $ sudo crm configure show
>
> node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" nodeA
> node $id="4a851515-443f-6140-b38f-dfb4bb46c010" nodeB
> primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
> meta migration-threshold="5" \
> params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
> op monitor interval="3s"
> primitive res_ping ocf:pacemaker:ping \
> params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200"
> dampen="1" debug="true" attempts="10" \
> op monitor interval="10s" timeout="60" \
> op start interval="0" timeout="60"
> primitive service_naka01v lsb:pkg_naka01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive service_sfdb01v lsb:pkg_sfdb01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive vgsfdb01v ocf:heartbeat:LVM \
> params volgrpname="vgsfdb01v"
> primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
> meta migration-threshold="5" \
> params device="/dev/vgsfdb01v/LogVol00" fstype="ext4"
> directory="/mysf" \
> op monitor interval="20s"
> primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
> params index="1" device="/dev/vgsfdb01v/lv_quorum"
> group pkg_naka01v service_naka01v \
> meta is-managed="true" target-role="Started"
> group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum
> vgsfdb01v_LogVol00 service_sfdb01v \
> meta is-managed="true" target-role="Started"
> clone clone_ping res_ping \
> meta target-role="Started"
> location pkg_naka01v-location pkg_naka01v \
> rule $id="pkg_naka01v-location-0" 200: #uname eq nodeA \
> rule $id="pkg_naka01v-location-1" 100: #uname eq nodeB
> location pkg_naka01v-service-location pkg_naka01v \
> rule $id="pkg_naka01v-service-location-rule" -inf: defined
> eth0_ping_set and eth0_ping_set lt 200
> location pkg_sfdb01v-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-location-0" 200: #uname eq nodeA \
> rule $id="pkg_sfdb01v-location-1" 100: #uname eq nodeB
> location pkg_sfdb01v-service-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-service-location-rule" -inf: defined
> eth0_ping_set and eth0_ping_set lt 200
> 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="1441681923"
> rsc_defaults $id="rsc-options" \
> resource-stickiness="INFINITY"
>
> $B$*<j?t$*$+$1CW$7$^$9$,!"2?B459$7$/$*4j$$CW$7$^$9!#(B
> $B0J>e(B
>
> --
> Naka
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: リソースエージェントの再起動動作について [ In reply to ]
足立様

お世話になっております。nakaと申します。

ご回答頂き有難うございました。
まさにご指摘頂いた通りで、サービス停止中の場合のstatusは0を
返すようになっていました。スクリプトを修正し、LSBに準拠した
形にした後に動作検証してみたところ、想定通りの動作(待機系障害でも
稼働系サービスに影響なし)となりました。# あとは本番環境への反映。。

大変助かりました。有難うございました。


2015年11月24日 18:29 yohei adachi <yope.sankaku@gmail.com>:

> naka様
>
> いつもお世話になっております。
> 足立と申します。
>
> 同じ状況となった経験があるため、参考になればとご連絡致します。
>
> [lsb:initスクリプト名] ですが、LSBでpacemakerリソースを監視する場合、
> /etc/init.d/ に配置する起動スクリプトが以下の使用に合致する必要があります。
>
> 【参考URL】
> http://linux-ha.osdn.jp/wp/archives/3855#lsb
> 「status」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
> ・サービスが停止している場合:3を返す。
> ・サービスが起動している場合:0を返す。
>
> おそらく、pacemaker(heartbeat)が再起動されたタイミングで、
> # /etc/init.d/<リソース> status
> の結果が0を返すことにより、Active/Standbyの両方でリソースが稼働してるように見え、
> この状況を解決しようとpacemakerがリソースの再起動を行っている可能性があるので
> ご確認頂けたらと存じます。
>
> ※待機系pacemaker再起動時に
> # crm_mon -i 1
> などのコマンドでリソース状況を確認すると、
> 両方のマシンで一時的にリソースが上がっているように見えておりました。
>
> 以上、宜しくお願い致します。
>
> 2015年11月24日 17:20 Keisuke Nakamura <k.xnakamu@gmail.com>:
> > 関係者各位
> >
> > お世話になっております。nakaと申します。
> >
> > 環境:
> > 2ノード構成(pacemaker+heartbeat) ※nodeA,nodeBとします。
> > OS:CentOS6.2(x86_64)
> > pacemaker-1.0.12-1.el6.x86_64
> > heartbeat-3.0.5-1.1.el6.x86_64
> >
> > nodeAで全てのグループリソースを起動させた状態で、
> > nodeBでの障害時動作を確認しております。
> >
> > /etc/init.d/heartbeat stop
> > /etc/init.d/heartbeat start
> >
> > nodeBでheartbeatデーモンを上記コマンドでstop/startさせたところ、
> > startを実行後になぜかnodeA側で動いている[lsb:initスクリプト名]の
> > RAが停止してしまい、その後すぐにRAはstartしました。
> >
> > 想定動作としては、stopせずにそのまま起動させておきたいのですが、
> > 上記動作の原因と、どのように設定したらよいかをご教授頂けませんでしょうか?
> >
> >
> > 参考までにheartbeatデーモンをstop/startさせた時のシスログを添付しておきます。
> > 以下、crmの設定内容となります。
> > $ sudo crm configure show
> >
> > node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" nodeA
> > node $id="4a851515-443f-6140-b38f-dfb4bb46c010" nodeB
> > primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
> > meta migration-threshold="5" \
> > params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
> > op monitor interval="3s"
> > primitive res_ping ocf:pacemaker:ping \
> > params name="eth0_ping_set" host_list="10.2.28.1"
> multiplier="200"
> > dampen="1" debug="true" attempts="10" \
> > op monitor interval="10s" timeout="60" \
> > op start interval="0" timeout="60"
> > primitive service_naka01v lsb:pkg_naka01v \
> > op start interval="0s" timeout="90s" \
> > op monitor interval="300s" timeout="20s" \
> > op stop interval="0s" timeout="100s" \
> > meta is-managed="true"
> > primitive service_sfdb01v lsb:pkg_sfdb01v \
> > op start interval="0s" timeout="90s" \
> > op monitor interval="300s" timeout="20s" \
> > op stop interval="0s" timeout="100s" \
> > meta is-managed="true"
> > primitive vgsfdb01v ocf:heartbeat:LVM \
> > params volgrpname="vgsfdb01v"
> > primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
> > meta migration-threshold="5" \
> > params device="/dev/vgsfdb01v/LogVol00" fstype="ext4"
> > directory="/mysf" \
> > op monitor interval="20s"
> > primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
> > params index="1" device="/dev/vgsfdb01v/lv_quorum"
> > group pkg_naka01v service_naka01v \
> > meta is-managed="true" target-role="Started"
> > group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum
> > vgsfdb01v_LogVol00 service_sfdb01v \
> > meta is-managed="true" target-role="Started"
> > clone clone_ping res_ping \
> > meta target-role="Started"
> > location pkg_naka01v-location pkg_naka01v \
> > rule $id="pkg_naka01v-location-0" 200: #uname eq nodeA \
> > rule $id="pkg_naka01v-location-1" 100: #uname eq nodeB
> > location pkg_naka01v-service-location pkg_naka01v \
> > rule $id="pkg_naka01v-service-location-rule" -inf: defined
> > eth0_ping_set and eth0_ping_set lt 200
> > location pkg_sfdb01v-location pkg_sfdb01v \
> > rule $id="pkg_sfdb01v-location-0" 200: #uname eq nodeA \
> > rule $id="pkg_sfdb01v-location-1" 100: #uname eq nodeB
> > location pkg_sfdb01v-service-location pkg_sfdb01v \
> > rule $id="pkg_sfdb01v-service-location-rule" -inf: defined
> > eth0_ping_set and eth0_ping_set lt 200
> > 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="1441681923"
> > rsc_defaults $id="rsc-options" \
> > resource-stickiness="INFINITY"
> >
> > お手数おかけ致しますが、何卒宜しくお願い致します。
> > 以上
> >
> > --
> > Naka
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan@lists.osdn.me
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>



--
Nakamura