Mailing List Archive: Linux-HA: Japanese

Active/Passive$B9=@.(B$B$G$N(BSTONITH$B$N@_Dj$K$D$$$F(B

Linux-HA japanese RSS feed

Index | Next | Previous | View Threaded

wada.shinichiro at jp

Feb 27, 2012, 1:58 AM

Post #1 of 13 (719 views)
Permalink

Active/Passive$B9=@.(B$B$G$N(BSTONITH$B$N@_Dj$K$D$$$F(B

$B$3$s$K$A$O!#(B
$BOBED$G$9!#(B

Active/Passive$B9=@.$G$N(BSTONITH$B4XO"$N [at] _D$K$D$$$F$465<($/$@$5$$!#(B

STONITH$B$r [at] _D$7$F$$$k>uBV$G!"(B

-------------------------------------------------------------------------

property no-quorum-policy="freeze" \
stonith-enabled="true" \
startup-fencing="false" \
stonith-timeout="430s"

-------------------------------------------------------------------------

$B$H [at] _D$7$?>l9g!"(B

$B!&JR8N>c>uBV$G!"%7%9%F%`$r5/F0$9$k$H@5>o$K5/F0$7$J$$!#(B
$B!&(BActive$BB&$,%O!<%I8N>cEy$G%@%&%s$9$k$H$&$^$/@Z$jBX$o$i$J$$!#(B

$B$H$$$&F0:n$r$7$^$9!#(B

$B0JA0!";3Fb$5$s$K65$($FD:$$$?MM$K!"(Bquorum$BDj?t$,H>J,0J2<$K$J$k$?$a!"@Z$jBX$o$i$J$$$H(B
$BG'<1$7$F$$$k$N$G$9$,!"G'<1$O$"$C$F$$$k$G$7$g$&$+!)(B

freeze$B$+$i(Bignore$B$K$9$k$3$H$G!"@5>o$K@Z$jBX$o$k$3$H$O3NG'$7$^$7$?!#(B
$B!t$?$@$7!"%9%W%j%C%H%V%l%$%s$J$I$,:$$j$^$9$h$M!#!#!#(B

$B$^$?!"0lHLE*$J [at] _D$H$7$F!"$_$J$5$s$O>e5-$N;v>]$KBP1~$9$k:]$K!"(B
$B$I$N$h$&$J [at] _D$H$7$F$$$k$N$G$7$g$&$+!)(B
NIC$B$r>iD92=$9$k$3$H$G!"(BActive/Passive$B9=@.$G$O(BSTONITH$B$rMxMQ$7$J$$(B
$B$H$$$&$h$&$J9=@.$,0lHLE*$J$N$G$7$g$&$+!)(B

$B$J$*!"9=@.$O0JA0<ALd$5$;$FD:$$$?$H$-$HF1MM$G!"(BCorosync + Pacemaker + DRBD$B$G(B
$B0J2<$N9=@.$H$J$C$F$$$^$9!#(B

-------------------------------------------------------------------------

primitive drbd_db ocf:linbit:drbd \
params drbd_resource="pgsql" \
op start interval="0s" timeout="240s" on-fail="restart" \
op monitor interval="11s" timeout="60s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
op stop interval="0s" timeout="100s" on-fail="fence"

primitive ip_db ocf:heartbeat:IPaddr2 \
params ip="192.168.1.175" \
nic="eth1" \
cidr_netmask="24" \
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 prmPing ocf:pacemaker:ping \
params \
name="ping_set" \
host_list="192.168.1.1 192.168.2.1" \
multiplier="100" \
dampen="0" \
meta \
migration-threshold="3" \
failure-timeout="60s" \
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="ignore"

primitive fs_db ocf:heartbeat:Filesystem \
params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
op start interval="0s" timeout="60s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="60s" on-fail="fence"

primitive prmPg ocf:heartbeat:pgsql \
params pgctl="/usr/bin/pg_ctl" \
start_opt="-p 5432" \
psql="/usr/bin/psql" \
pgdata="/data/" \
pgdba="postgres" \
pgport="5432" \
pgdb="postgres" \
op start interval="0s" timeout="120s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="120s" on-fail="fence"

primitive apache ocf:heartbeat:apache \
params configfile="/etc/httpd/conf/httpd.conf" \
port="80" \
op start interval="0s" timeout="40s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="60s" on-fail="fence"

primitive prmDiskd ocf:pacemaker:diskd \
params name="diskd_set" \
device="/dev/sda1" \
op start interval="0s" timeout="60s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="60s" on-fail="ignore"

primitive prmStonith1-1 stonith:external/stonith-helper \
params \
priority="1" \
stonith-timeout="60s" \
hostlist="it13" \
dead_check_target="192.168.1.173" \
run_standby_wait="no" \
op start interval="0s" timeout="60s" \
op monitor interval="3600s" timeout="60s" \
op stop interval="0s" timeout="60s"

primitive prmStonith1-2 stonith:external/ssh \
params \
priority="2" \
stonith-timeout="60s" \
hostlist="it13" \
op start interval="0s" timeout="60s" \
op monitor interval="3600s" timeout="60s" \
op stop interval="0s" timeout="60s"

primitive prmStonith1-3 stonith:meatware \
params \
priority="3" \
stonith-timeout="600" \
hostlist="it13" \
op start interval="0s" timeout="60s" \
op monitor interval="3600s" timeout="60s" \
op stop interval="0s" timeout="60s"

primitive prmStonith2-1 stonith:external/stonith-helper \
params \
priority="1" \
stonith-timeout="60s" \
hostlist="it14" \
dead_check_target="192.168.1.174" \
run_standby_wait="no" \
op start interval="0s" timeout="60s" \
op monitor interval="3600s" timeout="60s" \
op stop interval="0s" timeout="60s"

primitive prmStonith2-2 stonith:external/ssh \
params \
priority="2" \
stonith-timeout="60s" \
hostlist="it14" \
op start interval="0s" timeout="60s" \
op monitor interval="3600s" timeout="60s" \
op stop interval="0s" timeout="60s"

primitive prmStonith2-3 stonith:meatware \
params \
priority="3" \
stonith-timeout="600" \
hostlist="it14" \
op start interval="0s" timeout="60s" \
op monitor interval="3600s" timeout="60s" \
op stop interval="0s" timeout="60s"

group group_all fs_db ip_db prmPg apache

group grpStonith1 \
prmStonith1-1 \
prmStonith1-2 \
prmStonith1-3

group grpStonith2 \
prmStonith2-1 \
prmStonith2-2 \
prmStonith2-3

ms ms_drbd_db drbd_db \
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"

clone clnPing prmPing \
meta clone-max="2" clone-node-max="1"

clone clnDiskd prmDiskd \
meta clone-max="2" clone-node-max="1"

location group_all-location group_all \
rule 200: #uname eq it13 \
rule 100: #uname eq it14 \
rule -INFINITY: defined ping_set and ping_set lt 200 \
rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS

location master-location_db ms_drbd_db \
rule 200: #uname eq it13 \
rule 100: #uname eq it14 \
rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
rule role=master -INFINITY: defined fail-count-fs_db \
rule role=master -INFINITY: defined fail-count-ip_db \
rule role=master -INFINITY: defined fail-count-prmPg \
rule role=master -INFINITY: defined fail-count-apache

location rsc_location-grpStonith1-1 grpStonith1 \
rule -INFINITY: #uname eq it13

location rsc_location-grpStonith2-1 grpStonith2 \
rule -INFINITY: #uname eq it14

colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
colocation clnPing-colocation INFINITY: group_all clnPing
colocation clnDiskd-colocation INFINITY: group_all clnDiskd
order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
order order_clnPing_after_all 0: clnPing group_all symmetrical=false
order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false

property no-quorum-policy="freeze" \
stonith-enabled="true" \
startup-fencing="false" \
stonith-timeout="430s"

rsc_defaults resource-stickiness="INFINITY" \
migration-threshold="1"

-------------------------------------------------------------------------

$B$h$m$7$/$*4j$$CW$7$^$9!#(B

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 3:51 PM

Post #2 of 13 (731 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

和田さん

こんにちは、山内です。

> こんにちは。
> 和田です。
>
> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
>
> STONITHを設定している状態で、
>
> -------------------------------------------------------------------------
>
> property no-quorum-policy="freeze" \
>     stonith-enabled="true" \
>    startup-fencing="false" \
>    stonith-timeout="430s"
>
> -------------------------------------------------------------------------
>
> と設定した場合、
>
> ・片故障状態で、システムを起動すると正常に起動しない。
> ・Active側がハード故障等でダウンするとうまく切り替わらない。
>
> という動作をします。
>
> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
> 認識しているのですが、認識はあっているでしょうか？

はい。あっています。

> freezeからignoreにすることで、正常に切り替わることは確認しました。
> ＃ただし、スプリットブレインなどが困りますよね。。。
>
> また、一般的な設定として、みなさんは上記の事象に対応する際に、
> どのような設定としているのでしょうか？
> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
> というような構成が一般的なのでしょうか？

私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。

ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。

ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
stonith-helperなどを利用することが望ましいです。

stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
また、場合によっては、vipcheckなども有効でしょう。

以上、宜しくお願いいたします。

>
> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
> 以下の構成となっています。
>
> -------------------------------------------------------------------------
>
> primitive drbd_db ocf:linbit:drbd \
>    params drbd_resource="pgsql" \
>    op start interval="0s" timeout="240s" on-fail="restart" \
>    op monitor interval="11s" timeout="60s" on-fail="restart" \
>    op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
>    op stop interval="0s" timeout="100s" on-fail="fence"
>
> primitive ip_db ocf:heartbeat:IPaddr2 \
>    params ip="192.168.1.175" \
>    nic="eth1" \
>    cidr_netmask="24" \
>    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 prmPing ocf:pacemaker:ping \
>    params \
>    name="ping_set" \
>    host_list="192.168.1.1 192.168.2.1" \
>    multiplier="100" \
>    dampen="0" \
>    meta \
>    migration-threshold="3" \
>    failure-timeout="60s" \
>    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="ignore"
>
> primitive fs_db ocf:heartbeat:Filesystem \
>    params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
>    op start interval="0s" timeout="60s" on-fail="restart" \
>    op monitor interval="10s" timeout="60s" on-fail="restart" \
>    op stop interval="0s" timeout="60s" on-fail="fence"
>
> primitive prmPg ocf:heartbeat:pgsql \
>    params pgctl="/usr/bin/pg_ctl" \
>    start_opt="-p 5432" \
>    psql="/usr/bin/psql" \
>    pgdata="/data/" \
>    pgdba="postgres" \
>    pgport="5432" \
>    pgdb="postgres" \
>    op start interval="0s" timeout="120s" on-fail="restart" \
>    op monitor interval="10s" timeout="60s" on-fail="restart" \
>    op stop interval="0s" timeout="120s" on-fail="fence"
>
> primitive apache ocf:heartbeat:apache \
>    params configfile="/etc/httpd/conf/httpd.conf" \
>    port="80" \
>    op start interval="0s" timeout="40s" on-fail="restart" \
>    op monitor interval="10s" timeout="60s" on-fail="restart" \
>    op stop interval="0s" timeout="60s" on-fail="fence"
>
> primitive prmDiskd ocf:pacemaker:diskd \
>    params name="diskd_set" \
>    device="/dev/sda1" \
>    op start interval="0s" timeout="60s" on-fail="restart" \
>    op monitor interval="10s" timeout="60s" on-fail="restart" \
>    op stop interval="0s" timeout="60s" on-fail="ignore"
>
> primitive prmStonith1-1 stonith:external/stonith-helper \
>     params \
>         priority="1" \
>         stonith-timeout="60s" \
>         hostlist="it13" \
>         dead_check_target="192.168.1.173" \
>         run_standby_wait="no" \
>     op start interval="0s" timeout="60s" \
>     op monitor interval="3600s" timeout="60s" \
>     op stop interval="0s" timeout="60s"
>
> primitive prmStonith1-2 stonith:external/ssh \
>     params \
>         priority="2" \
>         stonith-timeout="60s" \
>         hostlist="it13" \
>     op start interval="0s" timeout="60s" \
>     op monitor interval="3600s" timeout="60s" \
>     op stop interval="0s" timeout="60s"
>
> primitive prmStonith1-3 stonith:meatware \
>     params \
>         priority="3" \
>         stonith-timeout="600" \
>         hostlist="it13" \
>     op start interval="0s" timeout="60s" \
>     op monitor interval="3600s" timeout="60s" \
>     op stop interval="0s" timeout="60s"
>
> primitive prmStonith2-1 stonith:external/stonith-helper \
>     params \
>         priority="1" \
>         stonith-timeout="60s" \
>         hostlist="it14" \
>         dead_check_target="192.168.1.174" \
>         run_standby_wait="no" \
>     op start interval="0s" timeout="60s" \
>     op monitor interval="3600s" timeout="60s" \
>     op stop interval="0s" timeout="60s"
>
> primitive prmStonith2-2 stonith:external/ssh \
>     params \
>         priority="2" \
>         stonith-timeout="60s" \
>         hostlist="it14" \
>     op start interval="0s" timeout="60s" \
>     op monitor interval="3600s" timeout="60s" \
>     op stop interval="0s" timeout="60s"
>
> primitive prmStonith2-3 stonith:meatware \
>     params \
>         priority="3" \
>         stonith-timeout="600" \
>         hostlist="it14" \
>     op start interval="0s" timeout="60s" \
>     op monitor interval="3600s" timeout="60s" \
>     op stop interval="0s" timeout="60s"
>
> group group_all fs_db ip_db prmPg apache
>
> group grpStonith1 \
>     prmStonith1-1 \
>     prmStonith1-2 \
>     prmStonith1-3
>
> group grpStonith2 \
>     prmStonith2-1 \
>     prmStonith2-2 \
>     prmStonith2-3
>
> ms ms_drbd_db drbd_db \
>    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
>
> clone clnPing prmPing \
>    meta clone-max="2" clone-node-max="1"
>
> clone clnDiskd prmDiskd \
>    meta clone-max="2" clone-node-max="1"
>
> location group_all-location group_all \
>    rule 200: #uname eq it13 \
>    rule 100: #uname eq it14 \
>    rule -INFINITY: defined ping_set and ping_set lt 200 \
>    rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
>
> location master-location_db ms_drbd_db \
>    rule 200: #uname eq it13 \
>    rule 100: #uname eq it14 \
>    rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
>    rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
>    rule role=master -INFINITY: defined fail-count-fs_db \
>    rule role=master -INFINITY: defined fail-count-ip_db \
>    rule role=master -INFINITY: defined fail-count-prmPg \
>    rule role=master -INFINITY: defined fail-count-apache
>
> location rsc_location-grpStonith1-1 grpStonith1 \
>     rule -INFINITY: #uname eq it13
>
> location rsc_location-grpStonith2-1 grpStonith2 \
>     rule -INFINITY: #uname eq it14
>
> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
> colocation clnPing-colocation INFINITY: group_all clnPing
> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
>
> property no-quorum-policy="freeze" \
>     stonith-enabled="true" \
>    startup-fencing="false" \
>    stonith-timeout="430s"
>
> rsc_defaults resource-stickiness="INFINITY" \
>    migration-threshold="1"
>
> -------------------------------------------------------------------------
>
> よろしくお願い致します。
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

wada.shinichiro at jp

Feb 27, 2012, 6:00 PM

Post #3 of 13 (680 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

$B;3Fb$5$s(B

$B$3$s$K$A$O!#(B
$BOBED$G$9!#(B

$B$$$D$b$42sEz$"$j$,$H$&$4$6$$$^$9!#(B

> $B;d8D?M$N0U8+$G$9$,!"C1=c$K(BActive/Passive$B9=@.$r9M$($?>l9g!"(Bstonith$B$O [at] _D$9$k$Y$-$@$H;W$C$F$$$^$9!#(B
>
> $B$G$9$N$G!"(Bno-quorum-policy$B$O(BActive/Passive$B$N>l9g(B"ignore"$B$K [at] _D$7$F!"(Bstonith$B$r [at] _D$9$k9=@.$G$9!#(B
>
> $B$?$@$7!"(B2$B%N!<%I$N>l9g!"J,CG;~$KMn$H$7$"$$$,H/@8$9$k$3$H$r2sHr$9$k0Y$K!"(B
> stonith-helper$B$J$I$rMxMQ$9$k$3$H$,K>$^$7$$$G$9!#(B
>
> stonith-helper$B$O!"F|K\%3%_%e%K%F%#$N(Bpm_extras$B%Q%C%1!<%8$K$"$j$^$9!#(B
> $B$^$?!">l9g$K$h$C$F$O!"(Bvipcheck$B$J$I$bM-8z$G$7$g$&!#(B

no-quorum-policy$B$H(Bstonith-helper$B$K$D$$$F==J,$KM}2r$,$G$-$F$$$J$$$h$&$J$N$G(B
$B$465<($/$@$5$$!#(B

$B$^$:!"(Bno-quorum-policy$B$G$9$,!"(Bignore$B$7$FJ,CG$,H/@8$7$?>l9g$G$b(B
STONITH$B$O<B9T$5$l$k$N$G$7$g$&$+!)(B
no-quorum-policy$B$G$O(BSTONITH$B$O<B9T$5$l$J$$$,!"(Bmonitor$B$N4V3V$G<B9T$5$l$k(B
$B$J$I$NF0:n$r$9$k$N$G$7$g$&$+!)(B

$B<!$K(Bstonith-helper$B$G$9$,!"(Brun_standby_wait$B$G$N%A%'%C%/$,I,MW$H$$$&(B
$BM}2r$G$h$m$7$$$G$7$g$&$+!)(B
$B$=$l$H$b!"(Brun_standby_wait$B<+BN$O(Bno$B$N$^$^$G$bLdBj$J$$$N$G$7$g$&$+!)(B
$B0JA0!"(Brun_standby_wait$B$G(Bact$B%A%'%C%/$7!"(BNIC$B>c32H/@8$N3NG'$r$7$?:]$K(B
$BN>7O$H$b(BPassive$B>uBV$H$J$jI|5l$7$J$+$C$?$s$G$9$h$M!#!#!#(B

$B$h$m$7$/$*4j$$CW$7$^$9!#(B

> $BOBED$5$s(B
>
> $B$3$s$K$A$O!";3Fb$G$9!#(B
>
>
>> $B$3$s$K$A$O!#(B
>> $BOBED$G$9!#(B
>>
>> Active/Passive$B9=@.$G$N(BSTONITH$B4XO"$N [at] _D$K$D$$$F$465<($/$@$5$$!#(B
>>
>> STONITH$B$r [at] _D$7$F$$$k>uBV$G!"(B
>>
>> -------------------------------------------------------------------------
>>
>> property no-quorum-policy="freeze" \
>> stonith-enabled="true" \
>> startup-fencing="false" \
>> stonith-timeout="430s"
>>
>> -------------------------------------------------------------------------
>>
>> $B$H [at] _D$7$?>l9g!"(B
>>
>> $B!&JR8N>c>uBV$G!"%7%9%F%`$r5/F0$9$k$H@5>o$K5/F0$7$J$$!#(B
>> $B!&(BActive$BB&$,%O!<%I8N>cEy$G%@%&%s$9$k$H$&$^$/@Z$jBX$o$i$J$$!#(B
>>
>> $B$H$$$&F0:n$r$7$^$9!#(B
>>
>> $B0JA0!";3Fb$5$s$K65$($FD:$$$?MM$K!"(Bquorum$BDj?t$,H>J,0J2<$K$J$k$?$a!"@Z$jBX$o$i$J$$$H(B
>> $BG'<1$7$F$$$k$N$G$9$,!"G'<1$O$"$C$F$$$k$G$7$g$&$+!)(B
>
> $B$O$$!#$"$C$F$$$^$9!#(B
>
>
>> freeze$B$+$i(Bignore$B$K$9$k$3$H$G!"@5>o$K@Z$jBX$o$k$3$H$O3NG'$7$^$7$?!#(B
>> $B!t$?$@$7!"%9%W%j%C%H%V%l%$%s$J$I$,:$$j$^$9$h$M!#!#!#(B
>>
>> $B$^$?!"0lHLE*$J [at] _D$H$7$F!"$_$J$5$s$O>e5-$N;v>]$KBP1~$9$k:]$K!"(B
>> $B$I$N$h$&$J [at] _D$H$7$F$$$k$N$G$7$g$&$+!)(B
>> NIC$B$r>iD92=$9$k$3$H$G!"(BActive/Passive$B9=@.$G$O(BSTONITH$B$rMxMQ$7$J$$(B
>> $B$H$$$&$h$&$J9=@.$,0lHLE*$J$N$G$7$g$&$+!)(B
>
> $B;d8D?M$N0U8+$G$9$,!"C1=c$K(BActive/Passive$B9=@.$r9M$($?>l9g!"(Bstonith$B$O [at] _D$9$k$Y$-$@$H;W$C$F$$$^$9!#(B
>
> $B$G$9$N$G!"(Bno-quorum-policy$B$O(BActive/Passive$B$N>l9g(B"ignore"$B$K [at] _D$7$F!"(Bstonith$B$r [at] _D$9$k9=@.$G$9!#(B
>
> $B$?$@$7!"(B2$B%N!<%I$N>l9g!"J,CG;~$KMn$H$7$"$$$,H/@8$9$k$3$H$r2sHr$9$k0Y$K!"(B
> stonith-helper$B$J$I$rMxMQ$9$k$3$H$,K>$^$7$$$G$9!#(B
>
> stonith-helper$B$O!"F|K\%3%_%e%K%F%#$N(Bpm_extras$B%Q%C%1!<%8$K$"$j$^$9!#(B
> $B$^$?!">l9g$K$h$C$F$O!"(Bvipcheck$B$J$I$bM-8z$G$7$g$&!#(B
>
>
> $B0J>e!"59$7$/$*4j$$$$$?$7$^$9!#(B
>
>
>
>
>>
>> $B$J$*!"9=@.$O0JA0<ALd$5$;$FD:$$$?$H$-$HF1MM$G!"(BCorosync + Pacemaker + DRBD$B$G(B
>> $B0J2<$N9=@.$H$J$C$F$$$^$9!#(B
>>
>> -------------------------------------------------------------------------
>>
>> primitive drbd_db ocf:linbit:drbd \
>> params drbd_resource="pgsql" \
>> op start interval="0s" timeout="240s" on-fail="restart" \
>> op monitor interval="11s" timeout="60s" on-fail="restart" \
>> op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
>> op stop interval="0s" timeout="100s" on-fail="fence"
>>
>> primitive ip_db ocf:heartbeat:IPaddr2 \
>> params ip="192.168.1.175" \
>> nic="eth1" \
>> cidr_netmask="24" \
>> 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 prmPing ocf:pacemaker:ping \
>> params \
>> name="ping_set" \
>> host_list="192.168.1.1 192.168.2.1" \
>> multiplier="100" \
>> dampen="0" \
>> meta \
>> migration-threshold="3" \
>> failure-timeout="60s" \
>> 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="ignore"
>>
>> primitive fs_db ocf:heartbeat:Filesystem \
>> params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
>> op start interval="0s" timeout="60s" on-fail="restart" \
>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>> op stop interval="0s" timeout="60s" on-fail="fence"
>>
>> primitive prmPg ocf:heartbeat:pgsql \
>> params pgctl="/usr/bin/pg_ctl" \
>> start_opt="-p 5432" \
>> psql="/usr/bin/psql" \
>> pgdata="/data/" \
>> pgdba="postgres" \
>> pgport="5432" \
>> pgdb="postgres" \
>> op start interval="0s" timeout="120s" on-fail="restart" \
>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>> op stop interval="0s" timeout="120s" on-fail="fence"
>>
>> primitive apache ocf:heartbeat:apache \
>> params configfile="/etc/httpd/conf/httpd.conf" \
>> port="80" \
>> op start interval="0s" timeout="40s" on-fail="restart" \
>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>> op stop interval="0s" timeout="60s" on-fail="fence"
>>
>> primitive prmDiskd ocf:pacemaker:diskd \
>> params name="diskd_set" \
>> device="/dev/sda1" \
>> op start interval="0s" timeout="60s" on-fail="restart" \
>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>> op stop interval="0s" timeout="60s" on-fail="ignore"
>>
>> primitive prmStonith1-1 stonith:external/stonith-helper \
>> params \
>> priority="1" \
>> stonith-timeout="60s" \
>> hostlist="it13" \
>> dead_check_target="192.168.1.173" \
>> run_standby_wait="no" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="3600s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> primitive prmStonith1-2 stonith:external/ssh \
>> params \
>> priority="2" \
>> stonith-timeout="60s" \
>> hostlist="it13" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="3600s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> primitive prmStonith1-3 stonith:meatware \
>> params \
>> priority="3" \
>> stonith-timeout="600" \
>> hostlist="it13" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="3600s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> primitive prmStonith2-1 stonith:external/stonith-helper \
>> params \
>> priority="1" \
>> stonith-timeout="60s" \
>> hostlist="it14" \
>> dead_check_target="192.168.1.174" \
>> run_standby_wait="no" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="3600s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> primitive prmStonith2-2 stonith:external/ssh \
>> params \
>> priority="2" \
>> stonith-timeout="60s" \
>> hostlist="it14" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="3600s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> primitive prmStonith2-3 stonith:meatware \
>> params \
>> priority="3" \
>> stonith-timeout="600" \
>> hostlist="it14" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="3600s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> group group_all fs_db ip_db prmPg apache
>>
>> group grpStonith1 \
>> prmStonith1-1 \
>> prmStonith1-2 \
>> prmStonith1-3
>>
>> group grpStonith2 \
>> prmStonith2-1 \
>> prmStonith2-2 \
>> prmStonith2-3
>>
>> ms ms_drbd_db drbd_db \
>> meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
>>
>> clone clnPing prmPing \
>> meta clone-max="2" clone-node-max="1"
>>
>> clone clnDiskd prmDiskd \
>> meta clone-max="2" clone-node-max="1"
>>
>> location group_all-location group_all \
>> rule 200: #uname eq it13 \
>> rule 100: #uname eq it14 \
>> rule -INFINITY: defined ping_set and ping_set lt 200 \
>> rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
>>
>> location master-location_db ms_drbd_db \
>> rule 200: #uname eq it13 \
>> rule 100: #uname eq it14 \
>> rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
>> rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
>> rule role=master -INFINITY: defined fail-count-fs_db \
>> rule role=master -INFINITY: defined fail-count-ip_db \
>> rule role=master -INFINITY: defined fail-count-prmPg \
>> rule role=master -INFINITY: defined fail-count-apache
>>
>> location rsc_location-grpStonith1-1 grpStonith1 \
>> rule -INFINITY: #uname eq it13
>>
>> location rsc_location-grpStonith2-1 grpStonith2 \
>> rule -INFINITY: #uname eq it14
>>
>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
>> colocation clnPing-colocation INFINITY: group_all clnPing
>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
>>
>> property no-quorum-policy="freeze" \
>> stonith-enabled="true" \
>> startup-fencing="false" \
>> stonith-timeout="430s"
>>
>> rsc_defaults resource-stickiness="INFINITY" \
>> migration-threshold="1"
>>
>> -------------------------------------------------------------------------
>>
>> $B$h$m$7$/$*4j$$CW$7$^$9!#(B
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan [at] lists
>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 6:31 PM

Post #4 of 13 (753 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

和田さん

こんにちは、山内です。

以下、補足いたしますね。

> 山内さん
>
> こんにちは。
> 和田です。
>
> いつもご回答ありがとうございます。
>
> > 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >
> > ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >
> > ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> > stonith-helperなどを利用することが望ましいです。
> >
> > stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> > また、場合によっては、vipcheckなども有効でしょう。
>
> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
> ご教示ください。
>
> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
> STONITHは実行されるのでしょうか？

はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
stonithは実行されます。

> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
> などの動作をするのでしょうか？

いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
なったことによって実行されるstonithになります。
monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。

no-quorum-policyの設定について、補足すると。。。

ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)

freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。

もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。

あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。

>
> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
> 理解でよろしいでしょうか？
> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
> 両系ともPassive状態となり復旧しなかったんですよね。。。

stonith-helperの設定例を抜粋します。

primitive prmStonith1-1 stonith:external/stonith-helper \
params \
priority="1" \
stonith-timeout="40s" \
hostlist="db1" \
dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
op start interval="0s" timeout="60s" \
op monitor interval="10s" timeout="60s" \
op stop interval="0s" timeout="60s"

設定のポイントは、
１）hostlist　相手ノードを指定。
２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）

stonith-helper自体は、stonithのグループとして先頭に設定してください。
必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）

group grpStonith1 \
prmStonith1-1 \
prmStonith1-2 \
prmStonith1-3

また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。

以上、宜しくお願いいたします。

>
> よろしくお願い致します。
>
> > 和田さん
> >
> > こんにちは、山内です。
> >
> >
> >> こんにちは。
> >> 和田です。
> >>
> >> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
> >>
> >> STONITHを設定している状態で、
> >>
> >> -------------------------------------------------------------------------
> >>
> >> property no-quorum-policy="freeze" \
> >> stonith-enabled="true" \
> >>    startup-fencing="false" \
> >>    stonith-timeout="430s"
> >>
> >> -------------------------------------------------------------------------
> >>
> >> と設定した場合、
> >>
> >> ・片故障状態で、システムを起動すると正常に起動しない。
> >> ・Active側がハード故障等でダウンするとうまく切り替わらない。
> >>
> >> という動作をします。
> >>
> >> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
> >> 認識しているのですが、認識はあっているでしょうか？
> >
> > はい。あっています。
> >
> >
> >> freezeからignoreにすることで、正常に切り替わることは確認しました。
> >> ＃ただし、スプリットブレインなどが困りますよね。。。
> >>
> >> また、一般的な設定として、みなさんは上記の事象に対応する際に、
> >> どのような設定としているのでしょうか？
> >> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
> >> というような構成が一般的なのでしょうか？
> >
> > 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >
> > ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >
> > ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> > stonith-helperなどを利用することが望ましいです。
> >
> > stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> > また、場合によっては、vipcheckなども有効でしょう。
> >
> >
> > 以上、宜しくお願いいたします。
> >
> >
> >
> >
> >>
> >> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
> >> 以下の構成となっています。
> >>
> >> -------------------------------------------------------------------------
> >>
> >> primitive drbd_db ocf:linbit:drbd \
> >>    params drbd_resource="pgsql" \
> >>    op start interval="0s" timeout="240s" on-fail="restart" \
> >>    op monitor interval="11s" timeout="60s" on-fail="restart" \
> >>    op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
> >>    op stop interval="0s" timeout="100s" on-fail="fence"
> >>
> >> primitive ip_db ocf:heartbeat:IPaddr2 \
> >>    params ip="192.168.1.175" \
> >>    nic="eth1" \
> >>    cidr_netmask="24" \
> >>    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 prmPing ocf:pacemaker:ping \
> >>    params \
> >>    name="ping_set" \
> >>    host_list="192.168.1.1 192.168.2.1" \
> >>    multiplier="100" \
> >>    dampen="0" \
> >>    meta \
> >>    migration-threshold="3" \
> >>    failure-timeout="60s" \
> >>    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="ignore"
> >>
> >> primitive fs_db ocf:heartbeat:Filesystem \
> >>    params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
> >>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>
> >> primitive prmPg ocf:heartbeat:pgsql \
> >>    params pgctl="/usr/bin/pg_ctl" \
> >>    start_opt="-p 5432" \
> >>    psql="/usr/bin/psql" \
> >>    pgdata="/data/" \
> >>    pgdba="postgres" \
> >>    pgport="5432" \
> >>    pgdb="postgres" \
> >>    op start interval="0s" timeout="120s" on-fail="restart" \
> >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>    op stop interval="0s" timeout="120s" on-fail="fence"
> >>
> >> primitive apache ocf:heartbeat:apache \
> >>    params configfile="/etc/httpd/conf/httpd.conf" \
> >>    port="80" \
> >>    op start interval="0s" timeout="40s" on-fail="restart" \
> >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>
> >> primitive prmDiskd ocf:pacemaker:diskd \
> >>    params name="diskd_set" \
> >>    device="/dev/sda1" \
> >>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>    op stop interval="0s" timeout="60s" on-fail="ignore"
> >>
> >> primitive prmStonith1-1 stonith:external/stonith-helper \
> >> params \
> >> priority="1" \
> >> stonith-timeout="60s" \
> >> hostlist="it13" \
> >> dead_check_target="192.168.1.173" \
> >> run_standby_wait="no" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="3600s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> primitive prmStonith1-2 stonith:external/ssh \
> >> params \
> >> priority="2" \
> >> stonith-timeout="60s" \
> >> hostlist="it13" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="3600s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> primitive prmStonith1-3 stonith:meatware \
> >> params \
> >> priority="3" \
> >> stonith-timeout="600" \
> >> hostlist="it13" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="3600s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> primitive prmStonith2-1 stonith:external/stonith-helper \
> >> params \
> >> priority="1" \
> >> stonith-timeout="60s" \
> >> hostlist="it14" \
> >> dead_check_target="192.168.1.174" \
> >> run_standby_wait="no" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="3600s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> primitive prmStonith2-2 stonith:external/ssh \
> >> params \
> >> priority="2" \
> >> stonith-timeout="60s" \
> >> hostlist="it14" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="3600s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> primitive prmStonith2-3 stonith:meatware \
> >> params \
> >> priority="3" \
> >> stonith-timeout="600" \
> >> hostlist="it14" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="3600s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> group group_all fs_db ip_db prmPg apache
> >>
> >> group grpStonith1 \
> >> prmStonith1-1 \
> >> prmStonith1-2 \
> >> prmStonith1-3
> >>
> >> group grpStonith2 \
> >> prmStonith2-1 \
> >> prmStonith2-2 \
> >> prmStonith2-3
> >>
> >> ms ms_drbd_db drbd_db \
> >>    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
> >>
> >> clone clnPing prmPing \
> >>    meta clone-max="2" clone-node-max="1"
> >>
> >> clone clnDiskd prmDiskd \
> >>    meta clone-max="2" clone-node-max="1"
> >>
> >> location group_all-location group_all \
> >>    rule 200: #uname eq it13 \
> >>    rule 100: #uname eq it14 \
> >>    rule -INFINITY: defined ping_set and ping_set lt 200 \
> >>    rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
> >>
> >> location master-location_db ms_drbd_db \
> >>    rule 200: #uname eq it13 \
> >>    rule 100: #uname eq it14 \
> >>    rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
> >>    rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
> >>    rule role=master -INFINITY: defined fail-count-fs_db \
> >>    rule role=master -INFINITY: defined fail-count-ip_db \
> >>    rule role=master -INFINITY: defined fail-count-prmPg \
> >>    rule role=master -INFINITY: defined fail-count-apache
> >>
> >> location rsc_location-grpStonith1-1 grpStonith1 \
> >> rule -INFINITY: #uname eq it13
> >>
> >> location rsc_location-grpStonith2-1 grpStonith2 \
> >> rule -INFINITY: #uname eq it14
> >>
> >> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
> >> colocation clnPing-colocation INFINITY: group_all clnPing
> >> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
> >> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
> >> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
> >> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
> >>
> >> property no-quorum-policy="freeze" \
> >> stonith-enabled="true" \
> >>    startup-fencing="false" \
> >>    stonith-timeout="430s"
> >>
> >> rsc_defaults resource-stickiness="INFINITY" \
> >>    migration-threshold="1"
> >>
> >> -------------------------------------------------------------------------
> >>
> >> よろしくお願い致します。
> >>
> >> _______________________________________________
> >> Linux-ha-japan mailing list
> >> Linux-ha-japan [at] lists
> >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan [at] lists
> > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 6:39 PM

Post #5 of 13 (749 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

和田さん

こんにちは、山内です。

さらにstonithの実行契機について補足しておくと。。。。

stonithが実行されるのは、

①リソースのon-fail="fence"の障害が発生した場合
②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
③ちょっと例外的ですが、startup-fencing="true"が設定されている場合

などになります。
ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。

以上、宜しくお願いいたします。
--- On Tue, 2012/2/28, renayama19661014 [at] ybb <renayama19661014 [at] ybb> wrote:

> 和田さん
>
> こんにちは、山内です。
>
> 以下、補足いたしますね。
>
> > 山内さん
> >
> > こんにちは。
> > 和田です。
> >
> > いつもご回答ありがとうございます。
> >
> > > 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> > >
> > > ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> > >
> > > ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> > > stonith-helperなどを利用することが望ましいです。
> > >
> > > stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> > > また、場合によっては、vipcheckなども有効でしょう。
> >
> > no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
> > ご教示ください。
> >
> > まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
> > STONITHは実行されるのでしょうか？
>
> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
> stonithは実行されます。
>
> > no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
> > などの動作をするのでしょうか？
>
> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
> なったことによって実行されるstonithになります。
> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
>
> no-quorum-policyの設定について、補足すると。。。
>
> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
>
> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>
> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
>
> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
>
> >
> > 次にstonith-helperですが、run_standby_waitでのチェックが必要という
> > 理解でよろしいでしょうか？
> > それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
> > 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
> > 両系ともPassive状態となり復旧しなかったんですよね。。。
>
> stonith-helperの設定例を抜粋します。
>
> primitive prmStonith1-1 stonith:external/stonith-helper \
> params \
> priority="1" \
> stonith-timeout="40s" \
> hostlist="db1" \
> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
> op start interval="0s" timeout="60s" \
> op monitor interval="10s" timeout="60s" \
> op stop interval="0s" timeout="60s"
>
> 設定のポイントは、
> １）hostlist　相手ノードを指定。
> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
>
> stonith-helper自体は、stonithのグループとして先頭に設定してください。
> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
>
> group grpStonith1 \
> prmStonith1-1 \
> prmStonith1-2 \
> prmStonith1-3
>
> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
>
> 以上、宜しくお願いいたします。
>
>
> >
> > よろしくお願い致します。
> >
> > > 和田さん
> > >
> > > こんにちは、山内です。
> > >
> > >
> > >> こんにちは。
> > >> 和田です。
> > >>
> > >> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
> > >>
> > >> STONITHを設定している状態で、
> > >>
> > >> -------------------------------------------------------------------------
> > >>
> > >> property no-quorum-policy="freeze" \
> > >> stonith-enabled="true" \
> > >>    startup-fencing="false" \
> > >>    stonith-timeout="430s"
> > >>
> > >> -------------------------------------------------------------------------
> > >>
> > >> と設定した場合、
> > >>
> > >> ・片故障状態で、システムを起動すると正常に起動しない。
> > >> ・Active側がハード故障等でダウンするとうまく切り替わらない。
> > >>
> > >> という動作をします。
> > >>
> > >> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
> > >> 認識しているのですが、認識はあっているでしょうか？
> > >
> > > はい。あっています。
> > >
> > >
> > >> freezeからignoreにすることで、正常に切り替わることは確認しました。
> > >> ＃ただし、スプリットブレインなどが困りますよね。。。
> > >>
> > >> また、一般的な設定として、みなさんは上記の事象に対応する際に、
> > >> どのような設定としているのでしょうか？
> > >> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
> > >> というような構成が一般的なのでしょうか？
> > >
> > > 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> > >
> > > ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> > >
> > > ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> > > stonith-helperなどを利用することが望ましいです。
> > >
> > > stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> > > また、場合によっては、vipcheckなども有効でしょう。
> > >
> > >
> > > 以上、宜しくお願いいたします。
> > >
> > >
> > >
> > >
> > >>
> > >> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
> > >> 以下の構成となっています。
> > >>
> > >> -------------------------------------------------------------------------
> > >>
> > >> primitive drbd_db ocf:linbit:drbd \
> > >>    params drbd_resource="pgsql" \
> > >>    op start interval="0s" timeout="240s" on-fail="restart" \
> > >>    op monitor interval="11s" timeout="60s" on-fail="restart" \
> > >>    op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
> > >>    op stop interval="0s" timeout="100s" on-fail="fence"
> > >>
> > >> primitive ip_db ocf:heartbeat:IPaddr2 \
> > >>    params ip="192.168.1.175" \
> > >>    nic="eth1" \
> > >>    cidr_netmask="24" \
> > >>    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 prmPing ocf:pacemaker:ping \
> > >>    params \
> > >>    name="ping_set" \
> > >>    host_list="192.168.1.1 192.168.2.1" \
> > >>    multiplier="100" \
> > >>    dampen="0" \
> > >>    meta \
> > >>    migration-threshold="3" \
> > >>    failure-timeout="60s" \
> > >>    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="ignore"
> > >>
> > >> primitive fs_db ocf:heartbeat:Filesystem \
> > >>    params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
> > >>    op start interval="0s" timeout="60s" on-fail="restart" \
> > >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> > >>    op stop interval="0s" timeout="60s" on-fail="fence"
> > >>
> > >> primitive prmPg ocf:heartbeat:pgsql \
> > >>    params pgctl="/usr/bin/pg_ctl" \
> > >>    start_opt="-p 5432" \
> > >>    psql="/usr/bin/psql" \
> > >>    pgdata="/data/" \
> > >>    pgdba="postgres" \
> > >>    pgport="5432" \
> > >>    pgdb="postgres" \
> > >>    op start interval="0s" timeout="120s" on-fail="restart" \
> > >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> > >>    op stop interval="0s" timeout="120s" on-fail="fence"
> > >>
> > >> primitive apache ocf:heartbeat:apache \
> > >>    params configfile="/etc/httpd/conf/httpd.conf" \
> > >>    port="80" \
> > >>    op start interval="0s" timeout="40s" on-fail="restart" \
> > >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> > >>    op stop interval="0s" timeout="60s" on-fail="fence"
> > >>
> > >> primitive prmDiskd ocf:pacemaker:diskd \
> > >>    params name="diskd_set" \
> > >>    device="/dev/sda1" \
> > >>    op start interval="0s" timeout="60s" on-fail="restart" \
> > >>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> > >>    op stop interval="0s" timeout="60s" on-fail="ignore"
> > >>
> > >> primitive prmStonith1-1 stonith:external/stonith-helper \
> > >> params \
> > >> priority="1" \
> > >> stonith-timeout="60s" \
> > >> hostlist="it13" \
> > >> dead_check_target="192.168.1.173" \
> > >> run_standby_wait="no" \
> > >> op start interval="0s" timeout="60s" \
> > >> op monitor interval="3600s" timeout="60s" \
> > >> op stop interval="0s" timeout="60s"
> > >>
> > >> primitive prmStonith1-2 stonith:external/ssh \
> > >> params \
> > >> priority="2" \
> > >> stonith-timeout="60s" \
> > >> hostlist="it13" \
> > >> op start interval="0s" timeout="60s" \
> > >> op monitor interval="3600s" timeout="60s" \
> > >> op stop interval="0s" timeout="60s"
> > >>
> > >> primitive prmStonith1-3 stonith:meatware \
> > >> params \
> > >> priority="3" \
> > >> stonith-timeout="600" \
> > >> hostlist="it13" \
> > >> op start interval="0s" timeout="60s" \
> > >> op monitor interval="3600s" timeout="60s" \
> > >> op stop interval="0s" timeout="60s"
> > >>
> > >> primitive prmStonith2-1 stonith:external/stonith-helper \
> > >> params \
> > >> priority="1" \
> > >> stonith-timeout="60s" \
> > >> hostlist="it14" \
> > >> dead_check_target="192.168.1.174" \
> > >> run_standby_wait="no" \
> > >> op start interval="0s" timeout="60s" \
> > >> op monitor interval="3600s" timeout="60s" \
> > >> op stop interval="0s" timeout="60s"
> > >>
> > >> primitive prmStonith2-2 stonith:external/ssh \
> > >> params \
> > >> priority="2" \
> > >> stonith-timeout="60s" \
> > >> hostlist="it14" \
> > >> op start interval="0s" timeout="60s" \
> > >> op monitor interval="3600s" timeout="60s" \
> > >> op stop interval="0s" timeout="60s"
> > >>
> > >> primitive prmStonith2-3 stonith:meatware \
> > >> params \
> > >> priority="3" \
> > >> stonith-timeout="600" \
> > >> hostlist="it14" \
> > >> op start interval="0s" timeout="60s" \
> > >> op monitor interval="3600s" timeout="60s" \
> > >> op stop interval="0s" timeout="60s"
> > >>
> > >> group group_all fs_db ip_db prmPg apache
> > >>
> > >> group grpStonith1 \
> > >> prmStonith1-1 \
> > >> prmStonith1-2 \
> > >> prmStonith1-3
> > >>
> > >> group grpStonith2 \
> > >> prmStonith2-1 \
> > >> prmStonith2-2 \
> > >> prmStonith2-3
> > >>
> > >> ms ms_drbd_db drbd_db \
> > >>    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
> > >>
> > >> clone clnPing prmPing \
> > >>    meta clone-max="2" clone-node-max="1"
> > >>
> > >> clone clnDiskd prmDiskd \
> > >>    meta clone-max="2" clone-node-max="1"
> > >>
> > >> location group_all-location group_all \
> > >>    rule 200: #uname eq it13 \
> > >>    rule 100: #uname eq it14 \
> > >>    rule -INFINITY: defined ping_set and ping_set lt 200 \
> > >>    rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
> > >>
> > >> location master-location_db ms_drbd_db \
> > >>    rule 200: #uname eq it13 \
> > >>    rule 100: #uname eq it14 \
> > >>    rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
> > >>    rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
> > >>    rule role=master -INFINITY: defined fail-count-fs_db \
> > >>    rule role=master -INFINITY: defined fail-count-ip_db \
> > >>    rule role=master -INFINITY: defined fail-count-prmPg \
> > >>    rule role=master -INFINITY: defined fail-count-apache
> > >>
> > >> location rsc_location-grpStonith1-1 grpStonith1 \
> > >> rule -INFINITY: #uname eq it13
> > >>
> > >> location rsc_location-grpStonith2-1 grpStonith2 \
> > >> rule -INFINITY: #uname eq it14
> > >>
> > >> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
> > >> colocation clnPing-colocation INFINITY: group_all clnPing
> > >> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
> > >> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
> > >> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
> > >> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
> > >>
> > >> property no-quorum-policy="freeze" \
> > >> stonith-enabled="true" \
> > >>    startup-fencing="false" \
> > >>    stonith-timeout="430s"
> > >>
> > >> rsc_defaults resource-stickiness="INFINITY" \
> > >>    migration-threshold="1"
> > >>
> > >> -------------------------------------------------------------------------
> > >>
> > >> よろしくお願い致します。
> > >>
> > >> _______________________________________________
> > >> Linux-ha-japan mailing list
> > >> Linux-ha-japan [at] lists
> > >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> > >>
> > >
> > > _______________________________________________
> > > Linux-ha-japan mailing list
> > > Linux-ha-japan [at] lists
> > > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan [at] lists
> > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

wada.shinichiro at jp

Feb 27, 2012, 9:01 PM

Post #6 of 13 (681 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

山内さん

こんにちは。
和田です。

丁寧なご説明ありがとうございます。
申し訳ないのですが、もう少しご教示ください。

> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。

つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、

> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合

のパターンでのSTONITH実行は行われないという理解であっているでしょうか？

> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
>Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。

とありますが、「Activeが優先して残るような構成」とは
具体的にはどのような設定になるのでしょうか？
＃locationに設定するscore値をさしているのでしょうか？

また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、

> stonithが実行されるのは、
>
> ①リソースのon-fail="fence"の障害が発生した場合
> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合

Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
再起動されていたいように記憶しています。

分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？

よろしくお願い致します。

> 和田さん
>
> こんにちは、山内です。
>
> さらにstonithの実行契機について補足しておくと。。。。
>
> stonithが実行されるのは、
>
> ①リソースのon-fail="fence"の障害が発生した場合
> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>
> などになります。
> ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
>
> 以上、宜しくお願いいたします。
> --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb> wrote:
>
>> 和田さん
>>
>> こんにちは、山内です。
>>
>> 以下、補足いたしますね。
>>
>>> 山内さん
>>>
>>> こんにちは。
>>> 和田です。
>>>
>>> いつもご回答ありがとうございます。
>>>
>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>
>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>
>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>> stonith-helperなどを利用することが望ましいです。
>>>>
>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>
>>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
>>> ご教示ください。
>>>
>>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
>>> STONITHは実行されるのでしょうか？
>>
>> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
>> stonithは実行されます。
>>
>>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
>>> などの動作をするのでしょうか？
>>
>> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
>> なったことによって実行されるstonithになります。
>> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
>>
>> no-quorum-policyの設定について、補足すると。。。
>>
>> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
>>
>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>
>> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
>>
>> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
>>
>>>
>>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
>>> 理解でよろしいでしょうか？
>>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
>>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
>>> 両系ともPassive状態となり復旧しなかったんですよね。。。
>>
>> stonith-helperの設定例を抜粋します。
>>
>> primitive prmStonith1-1 stonith:external/stonith-helper \
>> params \
>> priority="1" \
>> stonith-timeout="40s" \
>> hostlist="db1" \
>> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
>> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
>> op start interval="0s" timeout="60s" \
>> op monitor interval="10s" timeout="60s" \
>> op stop interval="0s" timeout="60s"
>>
>> 設定のポイントは、
>> １）hostlist　相手ノードを指定。
>> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
>>
>> stonith-helper自体は、stonithのグループとして先頭に設定してください。
>> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
>>
>> group grpStonith1 \
>> prmStonith1-1 \
>> prmStonith1-2 \
>> prmStonith1-3
>>
>> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
>>
>> 以上、宜しくお願いいたします。
>>
>>
>>>
>>> よろしくお願い致します。
>>>
>>>> 和田さん
>>>>
>>>> こんにちは、山内です。
>>>>
>>>>
>>>>> こんにちは。
>>>>> 和田です。
>>>>>
>>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
>>>>>
>>>>> STONITHを設定している状態で、
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>> property no-quorum-policy="freeze" \
>>>>> stonith-enabled="true" \
>>>>> startup-fencing="false" \
>>>>> stonith-timeout="430s"
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>> と設定した場合、
>>>>>
>>>>> ・片故障状態で、システムを起動すると正常に起動しない。
>>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
>>>>>
>>>>> という動作をします。
>>>>>
>>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
>>>>> 認識しているのですが、認識はあっているでしょうか？
>>>>
>>>> はい。あっています。
>>>>
>>>>
>>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
>>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
>>>>>
>>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
>>>>> どのような設定としているのでしょうか？
>>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
>>>>> というような構成が一般的なのでしょうか？
>>>>
>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>
>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>
>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>> stonith-helperなどを利用することが望ましいです。
>>>>
>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>
>>>>
>>>> 以上、宜しくお願いいたします。
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
>>>>> 以下の構成となっています。
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>> primitive drbd_db ocf:linbit:drbd \
>>>>> params drbd_resource="pgsql" \
>>>>> op start interval="0s" timeout="240s" on-fail="restart" \
>>>>> op monitor interval="11s" timeout="60s" on-fail="restart" \
>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
>>>>> op stop interval="0s" timeout="100s" on-fail="fence"
>>>>>
>>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
>>>>> params ip="192.168.1.175" \
>>>>> nic="eth1" \
>>>>> cidr_netmask="24" \
>>>>> 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 prmPing ocf:pacemaker:ping \
>>>>> params \
>>>>> name="ping_set" \
>>>>> host_list="192.168.1.1 192.168.2.1" \
>>>>> multiplier="100" \
>>>>> dampen="0" \
>>>>> meta \
>>>>> migration-threshold="3" \
>>>>> failure-timeout="60s" \
>>>>> 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="ignore"
>>>>>
>>>>> primitive fs_db ocf:heartbeat:Filesystem \
>>>>> params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>
>>>>> primitive prmPg ocf:heartbeat:pgsql \
>>>>> params pgctl="/usr/bin/pg_ctl" \
>>>>> start_opt="-p 5432" \
>>>>> psql="/usr/bin/psql" \
>>>>> pgdata="/data/" \
>>>>> pgdba="postgres" \
>>>>> pgport="5432" \
>>>>> pgdb="postgres" \
>>>>> op start interval="0s" timeout="120s" on-fail="restart" \
>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>> op stop interval="0s" timeout="120s" on-fail="fence"
>>>>>
>>>>> primitive apache ocf:heartbeat:apache \
>>>>> params configfile="/etc/httpd/conf/httpd.conf" \
>>>>> port="80" \
>>>>> op start interval="0s" timeout="40s" on-fail="restart" \
>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>
>>>>> primitive prmDiskd ocf:pacemaker:diskd \
>>>>> params name="diskd_set" \
>>>>> device="/dev/sda1" \
>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>> op stop interval="0s" timeout="60s" on-fail="ignore"
>>>>>
>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>>> params \
>>>>> priority="1" \
>>>>> stonith-timeout="60s" \
>>>>> hostlist="it13" \
>>>>> dead_check_target="192.168.1.173" \
>>>>> run_standby_wait="no" \
>>>>> op start interval="0s" timeout="60s" \
>>>>> op monitor interval="3600s" timeout="60s" \
>>>>> op stop interval="0s" timeout="60s"
>>>>>
>>>>> primitive prmStonith1-2 stonith:external/ssh \
>>>>> params \
>>>>> priority="2" \
>>>>> stonith-timeout="60s" \
>>>>> hostlist="it13" \
>>>>> op start interval="0s" timeout="60s" \
>>>>> op monitor interval="3600s" timeout="60s" \
>>>>> op stop interval="0s" timeout="60s"
>>>>>
>>>>> primitive prmStonith1-3 stonith:meatware \
>>>>> params \
>>>>> priority="3" \
>>>>> stonith-timeout="600" \
>>>>> hostlist="it13" \
>>>>> op start interval="0s" timeout="60s" \
>>>>> op monitor interval="3600s" timeout="60s" \
>>>>> op stop interval="0s" timeout="60s"
>>>>>
>>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
>>>>> params \
>>>>> priority="1" \
>>>>> stonith-timeout="60s" \
>>>>> hostlist="it14" \
>>>>> dead_check_target="192.168.1.174" \
>>>>> run_standby_wait="no" \
>>>>> op start interval="0s" timeout="60s" \
>>>>> op monitor interval="3600s" timeout="60s" \
>>>>> op stop interval="0s" timeout="60s"
>>>>>
>>>>> primitive prmStonith2-2 stonith:external/ssh \
>>>>> params \
>>>>> priority="2" \
>>>>> stonith-timeout="60s" \
>>>>> hostlist="it14" \
>>>>> op start interval="0s" timeout="60s" \
>>>>> op monitor interval="3600s" timeout="60s" \
>>>>> op stop interval="0s" timeout="60s"
>>>>>
>>>>> primitive prmStonith2-3 stonith:meatware \
>>>>> params \
>>>>> priority="3" \
>>>>> stonith-timeout="600" \
>>>>> hostlist="it14" \
>>>>> op start interval="0s" timeout="60s" \
>>>>> op monitor interval="3600s" timeout="60s" \
>>>>> op stop interval="0s" timeout="60s"
>>>>>
>>>>> group group_all fs_db ip_db prmPg apache
>>>>>
>>>>> group grpStonith1 \
>>>>> prmStonith1-1 \
>>>>> prmStonith1-2 \
>>>>> prmStonith1-3
>>>>>
>>>>> group grpStonith2 \
>>>>> prmStonith2-1 \
>>>>> prmStonith2-2 \
>>>>> prmStonith2-3
>>>>>
>>>>> ms ms_drbd_db drbd_db \
>>>>> meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
>>>>>
>>>>> clone clnPing prmPing \
>>>>> meta clone-max="2" clone-node-max="1"
>>>>>
>>>>> clone clnDiskd prmDiskd \
>>>>> meta clone-max="2" clone-node-max="1"
>>>>>
>>>>> location group_all-location group_all \
>>>>> rule 200: #uname eq it13 \
>>>>> rule 100: #uname eq it14 \
>>>>> rule -INFINITY: defined ping_set and ping_set lt 200 \
>>>>> rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
>>>>>
>>>>> location master-location_db ms_drbd_db \
>>>>> rule 200: #uname eq it13 \
>>>>> rule 100: #uname eq it14 \
>>>>> rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
>>>>> rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
>>>>> rule role=master -INFINITY: defined fail-count-fs_db \
>>>>> rule role=master -INFINITY: defined fail-count-ip_db \
>>>>> rule role=master -INFINITY: defined fail-count-prmPg \
>>>>> rule role=master -INFINITY: defined fail-count-apache
>>>>>
>>>>> location rsc_location-grpStonith1-1 grpStonith1 \
>>>>> rule -INFINITY: #uname eq it13
>>>>>
>>>>> location rsc_location-grpStonith2-1 grpStonith2 \
>>>>> rule -INFINITY: #uname eq it14
>>>>>
>>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
>>>>> colocation clnPing-colocation INFINITY: group_all clnPing
>>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
>>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
>>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
>>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
>>>>>
>>>>> property no-quorum-policy="freeze" \
>>>>> stonith-enabled="true" \
>>>>> startup-fencing="false" \
>>>>> stonith-timeout="430s"
>>>>>
>>>>> rsc_defaults resource-stickiness="INFINITY" \
>>>>> migration-threshold="1"
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>> よろしくお願い致します。
>>>>>
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan [at] lists
>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan [at] lists
>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan [at] lists
>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan [at] lists
>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 9:48 PM

Post #7 of 13 (693 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

和田さん

こんにちは、山内です。

再度、コメントしますね。

> 山内さん
>
> こんにちは。
> 和田です。
>
> 丁寧なご説明ありがとうございます。
> 申し訳ないのですが、もう少しご教示ください。
>
> > freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> > ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>
> つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、
>
> > ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>
> のパターンでのSTONITH実行は行われないという理解であっているでしょうか？

いえ、実行されないのは、QUORUMの制御が入る(freeze,stop)場合のみです。
stonith-enabled="true"で適切にstonithモジュールが設定されていれば、ignoreでは
stonithをクラスタ消失したノードに実行しようとします。
＃ただし、Active/Passiveではお互いに実行しようとしますので、ここでstonith-helperの出番となります。

>
> > ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
> >Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>
> とありますが、「Activeが優先して残るような構成」とは
> 具体的にはどのような設定になるのでしょうか？
> ＃locationに設定するscore値をさしているのでしょうか？

すいません。
ちょっと曖昧で間違っていま
した。
Activeノードか、PassiveノードでPassive側に待ちをかませる為に、Activeで起動するリソースを指定してくださいという意味です。
＃これがないと、お互いに実行しようとするstonithで相打ちが発生します。
ちなみに、これがある場合には、Passiveノードは待たされるので、Activeノードがまだ生きている場合は、Activeからのstonithが成功します。
もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。

>
> また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、
>
> > stonithが実行されるのは、
> >
> > ①リソースのon-fail="fence"の障害が発生した場合
> > ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> > ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>
> Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
> 分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
> 以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
> 再起動されていたいように記憶しています。
>

復旧後にstonithが実行される場合はあります。
stonith-helperなどがない場合、分断が起きてstonithを実行しようとするクラスタ側(例えば、3ノード構成で2ノードに分かれた側からの1ノード側）へのstonithは、通常ssh接続も出来ないで失敗するはずですので、stonithをしようとし続けます。
このstonithが成功しないと、2ノード側では次のアクションを起こせません。

よって、スプリットブレインが復旧された後で、ssh接続が可能になったので1ノード側はstonithされてしまいます。

>
> 分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
> それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？

はい。
sshのstonithがタイムアウトを起こす前に接続するとsshのstonithが実行されるはずです。

提示したstonithリソースグループであれば、もし、sshのstonithもタイムアウトで失敗すれば、meatwareに制御が移りますが、それもタイムアウトを起こせば、また、先頭のstonith-helperからやり直します。
＃要はstonithが完了するまでは、ずっとstonithをします。

以上、宜しくお願いいたします。
>
> よろしくお願い致します。
>
> > 和田さん
> >
> > こんにちは、山内です。
> >
> > さらにstonithの実行契機について補足しておくと。。。。
> >
> > stonithが実行されるのは、
> >
> > ①リソースのon-fail="fence"の障害が発生した場合
> > ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> > ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
> >
> > などになります。
> > ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
> >
> > 以上、宜しくお願いいたします。
> > --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb> wrote:
> >
> >> 和田さん
> >>
> >> こんにちは、山内です。
> >>
> >> 以下、補足いたしますね。
> >>
> >>> 山内さん
> >>>
> >>> こんにちは。
> >>> 和田です。
> >>>
> >>> いつもご回答ありがとうございます。
> >>>
> >>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >>>>
> >>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >>>>
> >>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> >>>> stonith-helperなどを利用することが望ましいです。
> >>>>
> >>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> >>>> また、場合によっては、vipcheckなども有効でしょう。
> >>>
> >>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
> >>> ご教示ください。
> >>>
> >>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
> >>> STONITHは実行されるのでしょうか？
> >>
> >> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
> >> stonithは実行されます。
> >>
> >>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
> >>> などの動作をするのでしょうか？
> >>
> >> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
> >> なったことによって実行されるstonithになります。
> >> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
> >>
> >> no-quorum-policyの設定について、補足すると。。。
> >>
> >> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
> >>
> >> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> >> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
> >>
> >> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
> >>
> >> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
> >>
> >>>
> >>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
> >>> 理解でよろしいでしょうか？
> >>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
> >>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
> >>> 両系ともPassive状態となり復旧しなかったんですよね。。。
> >>
> >> stonith-helperの設定例を抜粋します。
> >>
> >> primitive prmStonith1-1 stonith:external/stonith-helper \
> >> params \
> >> priority="1" \
> >> stonith-timeout="40s" \
> >> hostlist="db1" \
> >> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
> >> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
> >> op start interval="0s" timeout="60s" \
> >> op monitor interval="10s" timeout="60s" \
> >> op stop interval="0s" timeout="60s"
> >>
> >> 設定のポイントは、
> >> １）hostlist　相手ノードを指定。
> >> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
> >> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
> >> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
> >>
> >> stonith-helper自体は、stonithのグループとして先頭に設定してください。
> >> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
> >>
> >> group grpStonith1 \
> >> prmStonith1-1 \
> >> prmStonith1-2 \
> >> prmStonith1-3
> >>
> >> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
> >>
> >> 以上、宜しくお願いいたします。
> >>
> >>
> >>>
> >>> よろしくお願い致します。
> >>>
> >>>> 和田さん
> >>>>
> >>>> こんにちは、山内です。
> >>>>
> >>>>
> >>>>> こんにちは。
> >>>>> 和田です。
> >>>>>
> >>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
> >>>>>
> >>>>> STONITHを設定している状態で、
> >>>>>
> >>>>> -------------------------------------------------------------------------
> >>>>>
> >>>>> property no-quorum-policy="freeze" \
> >>>>> stonith-enabled="true" \
> >>>>>    startup-fencing="false" \
> >>>>>    stonith-timeout="430s"
> >>>>>
> >>>>> -------------------------------------------------------------------------
> >>>>>
> >>>>> と設定した場合、
> >>>>>
> >>>>> ・片故障状態で、システムを起動すると正常に起動しない。
> >>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
> >>>>>
> >>>>> という動作をします。
> >>>>>
> >>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
> >>>>> 認識しているのですが、認識はあっているでしょうか？
> >>>>
> >>>> はい。あっています。
> >>>>
> >>>>
> >>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
> >>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
> >>>>>
> >>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
> >>>>> どのような設定としているのでしょうか？
> >>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
> >>>>> というような構成が一般的なのでしょうか？
> >>>>
> >>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >>>>
> >>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >>>>
> >>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> >>>> stonith-helperなどを利用することが望ましいです。
> >>>>
> >>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> >>>> また、場合によっては、vipcheckなども有効でしょう。
> >>>>
> >>>>
> >>>> 以上、宜しくお願いいたします。
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
> >>>>> 以下の構成となっています。
> >>>>>
> >>>>> -------------------------------------------------------------------------
> >>>>>
> >>>>> primitive drbd_db ocf:linbit:drbd \
> >>>>>    params drbd_resource="pgsql" \
> >>>>>    op start interval="0s" timeout="240s" on-fail="restart" \
> >>>>>    op monitor interval="11s" timeout="60s" on-fail="restart" \
> >>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
> >>>>>    op stop interval="0s" timeout="100s" on-fail="fence"
> >>>>>
> >>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
> >>>>>    params ip="192.168.1.175" \
> >>>>>    nic="eth1" \
> >>>>>    cidr_netmask="24" \
> >>>>>    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 prmPing ocf:pacemaker:ping \
> >>>>>    params \
> >>>>>    name="ping_set" \
> >>>>>    host_list="192.168.1.1 192.168.2.1" \
> >>>>>    multiplier="100" \
> >>>>>    dampen="0" \
> >>>>>    meta \
> >>>>>    migration-threshold="3" \
> >>>>>    failure-timeout="60s" \
> >>>>>    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="ignore"
> >>>>>
> >>>>> primitive fs_db ocf:heartbeat:Filesystem \
> >>>>>    params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
> >>>>>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>>>>
> >>>>> primitive prmPg ocf:heartbeat:pgsql \
> >>>>>    params pgctl="/usr/bin/pg_ctl" \
> >>>>>    start_opt="-p 5432" \
> >>>>>    psql="/usr/bin/psql" \
> >>>>>    pgdata="/data/" \
> >>>>>    pgdba="postgres" \
> >>>>>    pgport="5432" \
> >>>>>    pgdb="postgres" \
> >>>>>    op start interval="0s" timeout="120s" on-fail="restart" \
> >>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>    op stop interval="0s" timeout="120s" on-fail="fence"
> >>>>>
> >>>>> primitive apache ocf:heartbeat:apache \
> >>>>>    params configfile="/etc/httpd/conf/httpd.conf" \
> >>>>>    port="80" \
> >>>>>    op start interval="0s" timeout="40s" on-fail="restart" \
> >>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>>>>
> >>>>> primitive prmDiskd ocf:pacemaker:diskd \
> >>>>>    params name="diskd_set" \
> >>>>>    device="/dev/sda1" \
> >>>>>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>    op stop interval="0s" timeout="60s" on-fail="ignore"
> >>>>>
> >>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
> >>>>> params \
> >>>>> priority="1" \
> >>>>> stonith-timeout="60s" \
> >>>>> hostlist="it13" \
> >>>>> dead_check_target="192.168.1.173" \
> >>>>> run_standby_wait="no" \
> >>>>> op start interval="0s" timeout="60s" \
> >>>>> op monitor interval="3600s" timeout="60s" \
> >>>>> op stop interval="0s" timeout="60s"
> >>>>>
> >>>>> primitive prmStonith1-2 stonith:external/ssh \
> >>>>> params \
> >>>>> priority="2" \
> >>>>> stonith-timeout="60s" \
> >>>>> hostlist="it13" \
> >>>>> op start interval="0s" timeout="60s" \
> >>>>> op monitor interval="3600s" timeout="60s" \
> >>>>> op stop interval="0s" timeout="60s"
> >>>>>
> >>>>> primitive prmStonith1-3 stonith:meatware \
> >>>>> params \
> >>>>> priority="3" \
> >>>>> stonith-timeout="600" \
> >>>>> hostlist="it13" \
> >>>>> op start interval="0s" timeout="60s" \
> >>>>> op monitor interval="3600s" timeout="60s" \
> >>>>> op stop interval="0s" timeout="60s"
> >>>>>
> >>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
> >>>>> params \
> >>>>> priority="1" \
> >>>>> stonith-timeout="60s" \
> >>>>> hostlist="it14" \
> >>>>> dead_check_target="192.168.1.174" \
> >>>>> run_standby_wait="no" \
> >>>>> op start interval="0s" timeout="60s" \
> >>>>> op monitor interval="3600s" timeout="60s" \
> >>>>> op stop interval="0s" timeout="60s"
> >>>>>
> >>>>> primitive prmStonith2-2 stonith:external/ssh \
> >>>>> params \
> >>>>> priority="2" \
> >>>>> stonith-timeout="60s" \
> >>>>> hostlist="it14" \
> >>>>> op start interval="0s" timeout="60s" \
> >>>>> op monitor interval="3600s" timeout="60s" \
> >>>>> op stop interval="0s" timeout="60s"
> >>>>>
> >>>>> primitive prmStonith2-3 stonith:meatware \
> >>>>> params \
> >>>>> priority="3" \
> >>>>> stonith-timeout="600" \
> >>>>> hostlist="it14" \
> >>>>> op start interval="0s" timeout="60s" \
> >>>>> op monitor interval="3600s" timeout="60s" \
> >>>>> op stop interval="0s" timeout="60s"
> >>>>>
> >>>>> group group_all fs_db ip_db prmPg apache
> >>>>>
> >>>>> group grpStonith1 \
> >>>>> prmStonith1-1 \
> >>>>> prmStonith1-2 \
> >>>>> prmStonith1-3
> >>>>>
> >>>>> group grpStonith2 \
> >>>>> prmStonith2-1 \
> >>>>> prmStonith2-2 \
> >>>>> prmStonith2-3
> >>>>>
> >>>>> ms ms_drbd_db drbd_db \
> >>>>>    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
> >>>>>
> >>>>> clone clnPing prmPing \
> >>>>>    meta clone-max="2" clone-node-max="1"
> >>>>>
> >>>>> clone clnDiskd prmDiskd \
> >>>>>    meta clone-max="2" clone-node-max="1"
> >>>>>
> >>>>> location group_all-location group_all \
> >>>>>    rule 200: #uname eq it13 \
> >>>>>    rule 100: #uname eq it14 \
> >>>>>    rule -INFINITY: defined ping_set and ping_set lt 200 \
> >>>>>    rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
> >>>>>
> >>>>> location master-location_db ms_drbd_db \
> >>>>>    rule 200: #uname eq it13 \
> >>>>>    rule 100: #uname eq it14 \
> >>>>>    rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
> >>>>>    rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
> >>>>>    rule role=master -INFINITY: defined fail-count-fs_db \
> >>>>>    rule role=master -INFINITY: defined fail-count-ip_db \
> >>>>>    rule role=master -INFINITY: defined fail-count-prmPg \
> >>>>>    rule role=master -INFINITY: defined fail-count-apache
> >>>>>
> >>>>> location rsc_location-grpStonith1-1 grpStonith1 \
> >>>>> rule -INFINITY: #uname eq it13
> >>>>>
> >>>>> location rsc_location-grpStonith2-1 grpStonith2 \
> >>>>> rule -INFINITY: #uname eq it14
> >>>>>
> >>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
> >>>>> colocation clnPing-colocation INFINITY: group_all clnPing
> >>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
> >>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
> >>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
> >>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
> >>>>>
> >>>>> property no-quorum-policy="freeze" \
> >>>>> stonith-enabled="true" \
> >>>>>    startup-fencing="false" \
> >>>>>    stonith-timeout="430s"
> >>>>>
> >>>>> rsc_defaults resource-stickiness="INFINITY" \
> >>>>>    migration-threshold="1"
> >>>>>
> >>>>> -------------------------------------------------------------------------
> >>>>>
> >>>>> よろしくお願い致します。
> >>>>>
> >>>>> _______________________________________________
> >>>>> Linux-ha-japan mailing list
> >>>>> Linux-ha-japan [at] lists
> >>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Linux-ha-japan mailing list
> >>>> Linux-ha-japan [at] lists
> >>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>
> >>> _______________________________________________
> >>> Linux-ha-japan mailing list
> >>> Linux-ha-japan [at] lists
> >>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>
> >>
> >> _______________________________________________
> >> Linux-ha-japan mailing list
> >> Linux-ha-japan [at] lists
> >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan [at] lists
> > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 10:03 PM

Post #8 of 13 (679 views)
Permalink

Re: Active/Passive$B9=@.(B$B$G$N(BSTONITH$B$N@_Dj$K$D$$$F(B [In reply to]

$BOBED$5$s(B

$B$9$$$^$;$s!#;3Fb$G$9!#(B

$B2sEz$KJ6$i$o$7$$5-:\$,$"$j$^$7$?$N$GD{@5$5$;$F$/$@$5$$!#(B

> $B$h$C$F!"%9%W%j%C%H%V%l%$%s$,I|5l$5$l$?8e$G!"(Bssh$B@\B3$,2DG=$K$J$C$?$N$G(B1$B%N!<%IB&$O(Bstonith$B$5$l$F$7$^$$$^$9!#(B

$B$H=q$$$F$7$^$$$^$7$?$,!"(B

$B-!%9%W%j%C%H%V%l%$%s$,I|5l$5$l$?>l9g!J%$%s%?!<%3%M%/%H$NI|5l!K$O!"%/%i%9%?$r:F9=@.$7$h$&$H$7$^$9$N$G!"FbIt>uBV$K$h$C$F$O!"(Bstonith$B$5$l$J$$$3$H$b$"$k$H;W$$$^$9!#(B
$B-"#1%N!<%IB&$r:F5/F0$J$I$GI|5l$5$;$?>l9g!"(Bstonith$B$5$l$k$O$:$G$9!#(B

Pacemaker$B$G$O!"%9%W%j%C%H%V%l%$%s$+$i$NI|5l$G-!$N%1!<%9$KLdBj$,5/$-$k>l9g$,$"$j$^$9$N$G!"-!$+$i$NI|5l$O8IN)%N!<%I$r:F5/F0$9$k$3$H$r$*4+$a$7$^$9!#(B
$B!t$b$7$/$O!"3N<B$K%9%W%j%C%H%V%l%$%sH/@8;~$K(Bstonith$B$G:F5/F0$,$+$+$k$3$H$r$*4+$a$7$^$9!#(B

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

wada.shinichiro at jp

Feb 27, 2012, 10:32 PM

Post #9 of 13 (679 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

山内さん

こんにちは。
和田です。

たびたびありがとうございます。

インラインで記述(★)します。

> 和田さん
>
> こんにちは、山内です。
>
> 再度、コメントしますね。
>
>
>> 山内さん
>>
>> こんにちは。
>> 和田です。
>>
>> 丁寧なご説明ありがとうございます。
>> 申し訳ないのですが、もう少しご教示ください。
>>
>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>
>> つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、
>>
>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>
>> のパターンでのSTONITH実行は行われないという理解であっているでしょうか？
>
> いえ、実行されないのは、QUORUMの制御が入る(freeze,stop)場合のみです。
> stonith-enabled="true"で適切にstonithモジュールが設定されていれば、ignoreでは
> stonithをクラスタ消失したノードに実行しようとします。
> ＃ただし、Active/Passiveではお互いに実行しようとしますので、ここでstonith-helperの出番となります。

★Active/Passive構成の場合、ignoreにしておかないと、分断時を含めノード消失時にSTONITHが
　実行されないということですね。

>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
>>> Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>>
>> とありますが、「Activeが優先して残るような構成」とは
>> 具体的にはどのような設定になるのでしょうか？
>> ＃locationに設定するscore値をさしているのでしょうか？
>
> すいません。
> ちょっと曖昧で間違っていま
> した。
> Activeノードか、PassiveノードでPassive側に待ちをかませる為に、Activeで起動するリソースを指定してくださいという意味です。
> ＃これがないと、お互いに実行しようとするstonithで相打ちが発生します。
> ちなみに、これがある場合には、Passiveノードは待たされるので、Activeノードがまだ生きている場合は、Activeからのstonithが成功します。
> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。

★freeze,stopの場合はstandby_check_commandを設定しなくても、実行されるサーバが
　限られるので問題ないが、ignoreの場合は無条件時実行されるので、standby_check_commandを
　設定する必要があるということですね。

　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。

>>
>> また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、
>>
>>> stonithが実行されるのは、
>>>
>>> ①リソースのon-fail="fence"の障害が発生した場合
>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>>
>> Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
>> 分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
>> 以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
>> 再起動されていたいように記憶しています。
>>
>
> 復旧後にstonithが実行される場合はあります。
> stonith-helperなどがない場合、分断が起きてstonithを実行しようとするクラスタ側(例えば、3ノード構成で2ノードに分かれた側からの1ノード側）へのstonithは、通常ssh接続も出来ないで失敗するはずですので、stonithをしようとし続けます。
> このstonithが成功しないと、2ノード側では次のアクションを起こせません。
>
> よって、スプリットブレインが復旧された後で、ssh接続が可能になったので1ノード側はstonithされてしまいます。

★追加のフォローについても了解しました。

>>
>> 分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
>> それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？
>
> はい。
> sshのstonithがタイムアウトを起こす前に接続するとsshのstonithが実行されるはずです。
>
> 提示したstonithリソースグループであれば、もし、sshのstonithもタイムアウトで失敗すれば、meatwareに制御が移りますが、それもタイムアウトを起こせば、また、先頭のstonith-helperからやり直します。
> ＃要はstonithが完了するまでは、ずっとstonithをします。

★保守者介在を施す必要はなくて、とにかく自動で復旧させたい場合は、
　meatwareを設定しなければ、繰り返し、sshをチャレンジしてくれると
　いうことですね。

自分の理解が不十分だった点も含め、いろいろと理解することできました。
お忙しいところいろいろとありがとうございました。

>
> 以上、宜しくお願いいたします。
>>
>> よろしくお願い致します。
>>
>>> 和田さん
>>>
>>> こんにちは、山内です。
>>>
>>> さらにstonithの実行契機について補足しておくと。。。。
>>>
>>> stonithが実行されるのは、
>>>
>>> ①リソースのon-fail="fence"の障害が発生した場合
>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>>>
>>> などになります。
>>> ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
>>>
>>> 以上、宜しくお願いいたします。
>>> --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb> wrote:
>>>
>>>> 和田さん
>>>>
>>>> こんにちは、山内です。
>>>>
>>>> 以下、補足いたしますね。
>>>>
>>>>> 山内さん
>>>>>
>>>>> こんにちは。
>>>>> 和田です。
>>>>>
>>>>> いつもご回答ありがとうございます。
>>>>>
>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>>>
>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>>>
>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>>>> stonith-helperなどを利用することが望ましいです。
>>>>>>
>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>>
>>>>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
>>>>> ご教示ください。
>>>>>
>>>>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
>>>>> STONITHは実行されるのでしょうか？
>>>>
>>>> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
>>>> stonithは実行されます。
>>>>
>>>>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
>>>>> などの動作をするのでしょうか？
>>>>
>>>> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
>>>> なったことによって実行されるstonithになります。
>>>> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
>>>>
>>>> no-quorum-policyの設定について、補足すると。。。
>>>>
>>>> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
>>>>
>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>>>
>>>> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
>>>>
>>>> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
>>>>
>>>>>
>>>>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
>>>>> 理解でよろしいでしょうか？
>>>>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
>>>>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
>>>>> 両系ともPassive状態となり復旧しなかったんですよね。。。
>>>>
>>>> stonith-helperの設定例を抜粋します。
>>>>
>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>> params \
>>>> priority="1" \
>>>> stonith-timeout="40s" \
>>>> hostlist="db1" \
>>>> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
>>>> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
>>>> op start interval="0s" timeout="60s" \
>>>> op monitor interval="10s" timeout="60s" \
>>>> op stop interval="0s" timeout="60s"
>>>>
>>>> 設定のポイントは、
>>>> １）hostlist　相手ノードを指定。
>>>> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>>>> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
>>>>
>>>> stonith-helper自体は、stonithのグループとして先頭に設定してください。
>>>> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
>>>>
>>>> group grpStonith1 \
>>>> prmStonith1-1 \
>>>> prmStonith1-2 \
>>>> prmStonith1-3
>>>>
>>>> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
>>>>
>>>> 以上、宜しくお願いいたします。
>>>>
>>>>
>>>>>
>>>>> よろしくお願い致します。
>>>>>
>>>>>> 和田さん
>>>>>>
>>>>>> こんにちは、山内です。
>>>>>>
>>>>>>
>>>>>>> こんにちは。
>>>>>>> 和田です。
>>>>>>>
>>>>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
>>>>>>>
>>>>>>> STONITHを設定している状態で、
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>>
>>>>>>> property no-quorum-policy="freeze" \
>>>>>>> stonith-enabled="true" \
>>>>>>> startup-fencing="false" \
>>>>>>> stonith-timeout="430s"
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>>
>>>>>>> と設定した場合、
>>>>>>>
>>>>>>> ・片故障状態で、システムを起動すると正常に起動しない。
>>>>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
>>>>>>>
>>>>>>> という動作をします。
>>>>>>>
>>>>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
>>>>>>> 認識しているのですが、認識はあっているでしょうか？
>>>>>>
>>>>>> はい。あっています。
>>>>>>
>>>>>>
>>>>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
>>>>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
>>>>>>>
>>>>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
>>>>>>> どのような設定としているのでしょうか？
>>>>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
>>>>>>> というような構成が一般的なのでしょうか？
>>>>>>
>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>>>
>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>>>
>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>>>> stonith-helperなどを利用することが望ましいです。
>>>>>>
>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>>>
>>>>>>
>>>>>> 以上、宜しくお願いいたします。
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
>>>>>>> 以下の構成となっています。
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>>
>>>>>>> primitive drbd_db ocf:linbit:drbd \
>>>>>>> params drbd_resource="pgsql" \
>>>>>>> op start interval="0s" timeout="240s" on-fail="restart" \
>>>>>>> op monitor interval="11s" timeout="60s" on-fail="restart" \
>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
>>>>>>> op stop interval="0s" timeout="100s" on-fail="fence"
>>>>>>>
>>>>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
>>>>>>> params ip="192.168.1.175" \
>>>>>>> nic="eth1" \
>>>>>>> cidr_netmask="24" \
>>>>>>> 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 prmPing ocf:pacemaker:ping \
>>>>>>> params \
>>>>>>> name="ping_set" \
>>>>>>> host_list="192.168.1.1 192.168.2.1" \
>>>>>>> multiplier="100" \
>>>>>>> dampen="0" \
>>>>>>> meta \
>>>>>>> migration-threshold="3" \
>>>>>>> failure-timeout="60s" \
>>>>>>> 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="ignore"
>>>>>>>
>>>>>>> primitive fs_db ocf:heartbeat:Filesystem \
>>>>>>> params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
>>>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>>>
>>>>>>> primitive prmPg ocf:heartbeat:pgsql \
>>>>>>> params pgctl="/usr/bin/pg_ctl" \
>>>>>>> start_opt="-p 5432" \
>>>>>>> psql="/usr/bin/psql" \
>>>>>>> pgdata="/data/" \
>>>>>>> pgdba="postgres" \
>>>>>>> pgport="5432" \
>>>>>>> pgdb="postgres" \
>>>>>>> op start interval="0s" timeout="120s" on-fail="restart" \
>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>> op stop interval="0s" timeout="120s" on-fail="fence"
>>>>>>>
>>>>>>> primitive apache ocf:heartbeat:apache \
>>>>>>> params configfile="/etc/httpd/conf/httpd.conf" \
>>>>>>> port="80" \
>>>>>>> op start interval="0s" timeout="40s" on-fail="restart" \
>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>>>
>>>>>>> primitive prmDiskd ocf:pacemaker:diskd \
>>>>>>> params name="diskd_set" \
>>>>>>> device="/dev/sda1" \
>>>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>> op stop interval="0s" timeout="60s" on-fail="ignore"
>>>>>>>
>>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>>>>> params \
>>>>>>> priority="1" \
>>>>>>> stonith-timeout="60s" \
>>>>>>> hostlist="it13" \
>>>>>>> dead_check_target="192.168.1.173" \
>>>>>>> run_standby_wait="no" \
>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>
>>>>>>> primitive prmStonith1-2 stonith:external/ssh \
>>>>>>> params \
>>>>>>> priority="2" \
>>>>>>> stonith-timeout="60s" \
>>>>>>> hostlist="it13" \
>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>
>>>>>>> primitive prmStonith1-3 stonith:meatware \
>>>>>>> params \
>>>>>>> priority="3" \
>>>>>>> stonith-timeout="600" \
>>>>>>> hostlist="it13" \
>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>
>>>>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
>>>>>>> params \
>>>>>>> priority="1" \
>>>>>>> stonith-timeout="60s" \
>>>>>>> hostlist="it14" \
>>>>>>> dead_check_target="192.168.1.174" \
>>>>>>> run_standby_wait="no" \
>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>
>>>>>>> primitive prmStonith2-2 stonith:external/ssh \
>>>>>>> params \
>>>>>>> priority="2" \
>>>>>>> stonith-timeout="60s" \
>>>>>>> hostlist="it14" \
>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>
>>>>>>> primitive prmStonith2-3 stonith:meatware \
>>>>>>> params \
>>>>>>> priority="3" \
>>>>>>> stonith-timeout="600" \
>>>>>>> hostlist="it14" \
>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>
>>>>>>> group group_all fs_db ip_db prmPg apache
>>>>>>>
>>>>>>> group grpStonith1 \
>>>>>>> prmStonith1-1 \
>>>>>>> prmStonith1-2 \
>>>>>>> prmStonith1-3
>>>>>>>
>>>>>>> group grpStonith2 \
>>>>>>> prmStonith2-1 \
>>>>>>> prmStonith2-2 \
>>>>>>> prmStonith2-3
>>>>>>>
>>>>>>> ms ms_drbd_db drbd_db \
>>>>>>> meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
>>>>>>>
>>>>>>> clone clnPing prmPing \
>>>>>>> meta clone-max="2" clone-node-max="1"
>>>>>>>
>>>>>>> clone clnDiskd prmDiskd \
>>>>>>> meta clone-max="2" clone-node-max="1"
>>>>>>>
>>>>>>> location group_all-location group_all \
>>>>>>> rule 200: #uname eq it13 \
>>>>>>> rule 100: #uname eq it14 \
>>>>>>> rule -INFINITY: defined ping_set and ping_set lt 200 \
>>>>>>> rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
>>>>>>>
>>>>>>> location master-location_db ms_drbd_db \
>>>>>>> rule 200: #uname eq it13 \
>>>>>>> rule 100: #uname eq it14 \
>>>>>>> rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
>>>>>>> rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
>>>>>>> rule role=master -INFINITY: defined fail-count-fs_db \
>>>>>>> rule role=master -INFINITY: defined fail-count-ip_db \
>>>>>>> rule role=master -INFINITY: defined fail-count-prmPg \
>>>>>>> rule role=master -INFINITY: defined fail-count-apache
>>>>>>>
>>>>>>> location rsc_location-grpStonith1-1 grpStonith1 \
>>>>>>> rule -INFINITY: #uname eq it13
>>>>>>>
>>>>>>> location rsc_location-grpStonith2-1 grpStonith2 \
>>>>>>> rule -INFINITY: #uname eq it14
>>>>>>>
>>>>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
>>>>>>> colocation clnPing-colocation INFINITY: group_all clnPing
>>>>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
>>>>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
>>>>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
>>>>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
>>>>>>>
>>>>>>> property no-quorum-policy="freeze" \
>>>>>>> stonith-enabled="true" \
>>>>>>> startup-fencing="false" \
>>>>>>> stonith-timeout="430s"
>>>>>>>
>>>>>>> rsc_defaults resource-stickiness="INFINITY" \
>>>>>>> migration-threshold="1"
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>>
>>>>>>> よろしくお願い致します。
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux-ha-japan [at] lists
>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux-ha-japan [at] lists
>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan [at] lists
>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan [at] lists
>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan [at] lists
>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan [at] lists
>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 10:42 PM

Post #10 of 13 (674 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

和田さん

こんにちは、山内です。

回答しますね。

>
> たびたびありがとうございます。
>
> インラインで記述(★)します。
>
> > 和田さん
> >
> > こんにちは、山内です。
> >
> > 再度、コメントしますね。
> >
> >
> >> 山内さん
> >>
> >> こんにちは。
> >> 和田です。
> >>
> >> 丁寧なご説明ありがとうございます。
> >> 申し訳ないのですが、もう少しご教示ください。
> >>
> >>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> >>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
> >>
> >> つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、
> >>
> >>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> >>
> >> のパターンでのSTONITH実行は行われないという理解であっているでしょうか？
> >
> > いえ、実行されないのは、QUORUMの制御が入る(freeze,stop)場合のみです。
> > stonith-enabled="true"で適切にstonithモジュールが設定されていれば、ignoreでは
> > stonithをクラスタ消失したノードに実行しようとします。
> > ＃ただし、Active/Passiveではお互いに実行しようとしますので、ここでstonith-helperの出番となります。
>
> ★Active/Passive構成の場合、ignoreにしておかないと、分断時を含めノード消失時にSTONITHが
> 　実行されないということですね。

はい。
現象を見られた通り、ignoreにしないと、初期起動時はリソースすら起動しないという現象も発生します。

>
> >>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
> >>> Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
> >>
> >> とありますが、「Activeが優先して残るような構成」とは
> >> 具体的にはどのような設定になるのでしょうか？
> >> ＃locationに設定するscore値をさしているのでしょうか？
> >
> > すいません。
> > ちょっと曖昧で間違っていま
> > した。
> > Activeノードか、PassiveノードでPassive側に待ちをかませる為に、Activeで起動するリソースを指定してくださいという意味です。
> > ＃これがないと、お互いに実行しようとするstonithで相打ちが発生します。
> > ちなみに、これがある場合には、Passiveノードは待たされるので、Activeノードがまだ生きている場合は、Activeからのstonithが成功します。
> > もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。
>
> ★freeze,stopの場合はstandby_check_commandを設定しなくても、実行されるサーバが
> 　限られるので問題ないが、ignoreの場合は無条件時実行されるので、standby_check_commandを
> 　設定する必要があるということですね。

はい。その通りです。

>
> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。

すいません。ちょっとこの意味がわかりませんでした。

>
> >>
> >> また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、
> >>
> >>> stonithが実行されるのは、
> >>>
> >>> ①リソースのon-fail="fence"の障害が発生した場合
> >>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> >>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
> >>
> >> Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
> >> 分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
> >> 以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
> >> 再起動されていたいように記憶しています。
> >>
> >
> > 復旧後にstonithが実行される場合はあります。
> > stonith-helperなどがない場合、分断が起きてstonithを実行しようとするクラスタ側(例えば、3ノード構成で2ノードに分かれた側からの1ノード側）へのstonithは、通常ssh接続も出来ないで失敗するはずですので、stonithをしようとし続けます。
> > このstonithが成功しないと、2ノード側では次のアクションを起こせません。
> >
> > よって、スプリットブレインが復旧された後で、ssh接続が可能になったので1ノード側はstonithされてしまいます。
>
> ★追加のフォローについても了解しました。

宜しくお願いたします。

>
> >>
> >> 分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
> >> それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？
> >
> > はい。
> > sshのstonithがタイムアウトを起こす前に接続するとsshのstonithが実行されるはずです。
> >
> > 提示したstonithリソースグループであれば、もし、sshのstonithもタイムアウトで失敗すれば、meatwareに制御が移りますが、それもタイムアウトを起こせば、また、先頭のstonith-helperからやり直します。
> > ＃要はstonithが完了するまでは、ずっとstonithをします。
>
> ★保守者介在を施す必要はなくて、とにかく自動で復旧させたい場合は、
> 　meatwareを設定しなければ、繰り返し、sshをチャレンジしてくれると
> 　いうことですね。

はい。完了するまでチャレンジします。
＃しかし、ノードが完全故障すると長いサービス停止を招くので、データセンターなどでは保守者介在の道を残してあるというのが正解ですね。
＃また、sshではなく、サーバのiLO,RSAなどが利用できる場合、そちらのstonithを利用するというのも有効です。(sshよりも確実に落とせる）
＃さらに、stonith-helperが相手ノードの完全故障停止を判断できるように設定してあれば、かなり有効です。（stonith-helperが成功するとチャレンジは終了）

>
> 自分の理解が不十分だった点も含め、いろいろと理解することできました。
> お忙しいところいろいろとありがとうございました。

いえいえ、また何かありましたら、お気軽にＭＬに質問してみてください。

以上、宜しくお願いいたします。

>
> >
> > 以上、宜しくお願いいたします。
> >>
> >> よろしくお願い致します。
> >>
> >>> 和田さん
> >>>
> >>> こんにちは、山内です。
> >>>
> >>> さらにstonithの実行契機について補足しておくと。。。。
> >>>
> >>> stonithが実行されるのは、
> >>>
> >>> ①リソースのon-fail="fence"の障害が発生した場合
> >>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> >>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
> >>>
> >>> などになります。
> >>> ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
> >>>
> >>> 以上、宜しくお願いいたします。
> >>> --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb>   wrote:
> >>>
> >>>> 和田さん
> >>>>
> >>>> こんにちは、山内です。
> >>>>
> >>>> 以下、補足いたしますね。
> >>>>
> >>>>> 山内さん
> >>>>>
> >>>>> こんにちは。
> >>>>> 和田です。
> >>>>>
> >>>>> いつもご回答ありがとうございます。
> >>>>>
> >>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >>>>>>
> >>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >>>>>>
> >>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> >>>>>> stonith-helperなどを利用することが望ましいです。
> >>>>>>
> >>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> >>>>>> また、場合によっては、vipcheckなども有効でしょう。
> >>>>>
> >>>>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
> >>>>> ご教示ください。
> >>>>>
> >>>>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
> >>>>> STONITHは実行されるのでしょうか？
> >>>>
> >>>> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
> >>>> stonithは実行されます。
> >>>>
> >>>>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
> >>>>> などの動作をするのでしょうか？
> >>>>
> >>>> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
> >>>> なったことによって実行されるstonithになります。
> >>>> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
> >>>>
> >>>> no-quorum-policyの設定について、補足すると。。。
> >>>>
> >>>> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
> >>>>
> >>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> >>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
> >>>>
> >>>> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
> >>>>
> >>>> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
> >>>>
> >>>>>
> >>>>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
> >>>>> 理解でよろしいでしょうか？
> >>>>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
> >>>>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
> >>>>> 両系ともPassive状態となり復旧しなかったんですよね。。。
> >>>>
> >>>> stonith-helperの設定例を抜粋します。
> >>>>
> >>>> primitive prmStonith1-1 stonith:external/stonith-helper \
> >>>> params \
> >>>> priority="1" \
> >>>> stonith-timeout="40s" \
> >>>> hostlist="db1" \
> >>>> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
> >>>> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
> >>>> op start interval="0s" timeout="60s" \
> >>>> op monitor interval="10s" timeout="60s" \
> >>>> op stop interval="0s" timeout="60s"
> >>>>
> >>>> 設定のポイントは、
> >>>> １）hostlist　相手ノードを指定。
> >>>> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
> >>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
> >>>> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
> >>>>
> >>>> stonith-helper自体は、stonithのグループとして先頭に設定してください。
> >>>> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
> >>>>
> >>>> group grpStonith1 \
> >>>> prmStonith1-1 \
> >>>> prmStonith1-2 \
> >>>> prmStonith1-3
> >>>>
> >>>> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
> >>>>
> >>>> 以上、宜しくお願いいたします。
> >>>>
> >>>>
> >>>>>
> >>>>> よろしくお願い致します。
> >>>>>
> >>>>>> 和田さん
> >>>>>>
> >>>>>> こんにちは、山内です。
> >>>>>>
> >>>>>>
> >>>>>>> こんにちは。
> >>>>>>> 和田です。
> >>>>>>>
> >>>>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
> >>>>>>>
> >>>>>>> STONITHを設定している状態で、
> >>>>>>>
> >>>>>>> -------------------------------------------------------------------------
> >>>>>>>
> >>>>>>> property no-quorum-policy="freeze" \
> >>>>>>> stonith-enabled="true" \
> >>>>>>>    startup-fencing="false" \
> >>>>>>>    stonith-timeout="430s"
> >>>>>>>
> >>>>>>> -------------------------------------------------------------------------
> >>>>>>>
> >>>>>>> と設定した場合、
> >>>>>>>
> >>>>>>> ・片故障状態で、システムを起動すると正常に起動しない。
> >>>>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
> >>>>>>>
> >>>>>>> という動作をします。
> >>>>>>>
> >>>>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
> >>>>>>> 認識しているのですが、認識はあっているでしょうか？
> >>>>>>
> >>>>>> はい。あっています。
> >>>>>>
> >>>>>>
> >>>>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
> >>>>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
> >>>>>>>
> >>>>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
> >>>>>>> どのような設定としているのでしょうか？
> >>>>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
> >>>>>>> というような構成が一般的なのでしょうか？
> >>>>>>
> >>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >>>>>>
> >>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >>>>>>
> >>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> >>>>>> stonith-helperなどを利用することが望ましいです。
> >>>>>>
> >>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> >>>>>> また、場合によっては、vipcheckなども有効でしょう。
> >>>>>>
> >>>>>>
> >>>>>> 以上、宜しくお願いいたします。
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
> >>>>>>> 以下の構成となっています。
> >>>>>>>
> >>>>>>> -------------------------------------------------------------------------
> >>>>>>>
> >>>>>>> primitive drbd_db ocf:linbit:drbd \
> >>>>>>>    params drbd_resource="pgsql" \
> >>>>>>>    op start interval="0s" timeout="240s" on-fail="restart" \
> >>>>>>>    op monitor interval="11s" timeout="60s" on-fail="restart" \
> >>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
> >>>>>>>    op stop interval="0s" timeout="100s" on-fail="fence"
> >>>>>>>
> >>>>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
> >>>>>>>    params ip="192.168.1.175" \
> >>>>>>>    nic="eth1" \
> >>>>>>>    cidr_netmask="24" \
> >>>>>>>    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 prmPing ocf:pacemaker:ping \
> >>>>>>>    params \
> >>>>>>>    name="ping_set" \
> >>>>>>>    host_list="192.168.1.1 192.168.2.1" \
> >>>>>>>    multiplier="100" \
> >>>>>>>    dampen="0" \
> >>>>>>>    meta \
> >>>>>>>    migration-threshold="3" \
> >>>>>>>    failure-timeout="60s" \
> >>>>>>>    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="ignore"
> >>>>>>>
> >>>>>>> primitive fs_db ocf:heartbeat:Filesystem \
> >>>>>>>    params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
> >>>>>>>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>>>>>>
> >>>>>>> primitive prmPg ocf:heartbeat:pgsql \
> >>>>>>>    params pgctl="/usr/bin/pg_ctl" \
> >>>>>>>    start_opt="-p 5432" \
> >>>>>>>    psql="/usr/bin/psql" \
> >>>>>>>    pgdata="/data/" \
> >>>>>>>    pgdba="postgres" \
> >>>>>>>    pgport="5432" \
> >>>>>>>    pgdb="postgres" \
> >>>>>>>    op start interval="0s" timeout="120s" on-fail="restart" \
> >>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>    op stop interval="0s" timeout="120s" on-fail="fence"
> >>>>>>>
> >>>>>>> primitive apache ocf:heartbeat:apache \
> >>>>>>>    params configfile="/etc/httpd/conf/httpd.conf" \
> >>>>>>>    port="80" \
> >>>>>>>    op start interval="0s" timeout="40s" on-fail="restart" \
> >>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>>>>>>
> >>>>>>> primitive prmDiskd ocf:pacemaker:diskd \
> >>>>>>>    params name="diskd_set" \
> >>>>>>>    device="/dev/sda1" \
> >>>>>>>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>    op stop interval="0s" timeout="60s" on-fail="ignore"
> >>>>>>>
> >>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
> >>>>>>> params \
> >>>>>>> priority="1" \
> >>>>>>> stonith-timeout="60s" \
> >>>>>>> hostlist="it13" \
> >>>>>>> dead_check_target="192.168.1.173" \
> >>>>>>> run_standby_wait="no" \
> >>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>
> >>>>>>> primitive prmStonith1-2 stonith:external/ssh \
> >>>>>>> params \
> >>>>>>> priority="2" \
> >>>>>>> stonith-timeout="60s" \
> >>>>>>> hostlist="it13" \
> >>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>
> >>>>>>> primitive prmStonith1-3 stonith:meatware \
> >>>>>>> params \
> >>>>>>> priority="3" \
> >>>>>>> stonith-timeout="600" \
> >>>>>>> hostlist="it13" \
> >>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>
> >>>>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
> >>>>>>> params \
> >>>>>>> priority="1" \
> >>>>>>> stonith-timeout="60s" \
> >>>>>>> hostlist="it14" \
> >>>>>>> dead_check_target="192.168.1.174" \
> >>>>>>> run_standby_wait="no" \
> >>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>
> >>>>>>> primitive prmStonith2-2 stonith:external/ssh \
> >>>>>>> params \
> >>>>>>> priority="2" \
> >>>>>>> stonith-timeout="60s" \
> >>>>>>> hostlist="it14" \
> >>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>
> >>>>>>> primitive prmStonith2-3 stonith:meatware \
> >>>>>>> params \
> >>>>>>> priority="3" \
> >>>>>>> stonith-timeout="600" \
> >>>>>>> hostlist="it14" \
> >>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>
> >>>>>>> group group_all fs_db ip_db prmPg apache
> >>>>>>>
> >>>>>>> group grpStonith1 \
> >>>>>>> prmStonith1-1 \
> >>>>>>> prmStonith1-2 \
> >>>>>>> prmStonith1-3
> >>>>>>>
> >>>>>>> group grpStonith2 \
> >>>>>>> prmStonith2-1 \
> >>>>>>> prmStonith2-2 \
> >>>>>>> prmStonith2-3
> >>>>>>>
> >>>>>>> ms ms_drbd_db drbd_db \
> >>>>>>>    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
> >>>>>>>
> >>>>>>> clone clnPing prmPing \
> >>>>>>>    meta clone-max="2" clone-node-max="1"
> >>>>>>>
> >>>>>>> clone clnDiskd prmDiskd \
> >>>>>>>    meta clone-max="2" clone-node-max="1"
> >>>>>>>
> >>>>>>> location group_all-location group_all \
> >>>>>>>    rule 200: #uname eq it13 \
> >>>>>>>    rule 100: #uname eq it14 \
> >>>>>>>    rule -INFINITY: defined ping_set and ping_set lt 200 \
> >>>>>>>    rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
> >>>>>>>
> >>>>>>> location master-location_db ms_drbd_db \
> >>>>>>>    rule 200: #uname eq it13 \
> >>>>>>>    rule 100: #uname eq it14 \
> >>>>>>>    rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
> >>>>>>>    rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
> >>>>>>>    rule role=master -INFINITY: defined fail-count-fs_db \
> >>>>>>>    rule role=master -INFINITY: defined fail-count-ip_db \
> >>>>>>>    rule role=master -INFINITY: defined fail-count-prmPg \
> >>>>>>>    rule role=master -INFINITY: defined fail-count-apache
> >>>>>>>
> >>>>>>> location rsc_location-grpStonith1-1 grpStonith1 \
> >>>>>>> rule -INFINITY: #uname eq it13
> >>>>>>>
> >>>>>>> location rsc_location-grpStonith2-1 grpStonith2 \
> >>>>>>> rule -INFINITY: #uname eq it14
> >>>>>>>
> >>>>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
> >>>>>>> colocation clnPing-colocation INFINITY: group_all clnPing
> >>>>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
> >>>>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
> >>>>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
> >>>>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
> >>>>>>>
> >>>>>>> property no-quorum-policy="freeze" \
> >>>>>>> stonith-enabled="true" \
> >>>>>>>    startup-fencing="false" \
> >>>>>>>    stonith-timeout="430s"
> >>>>>>>
> >>>>>>> rsc_defaults resource-stickiness="INFINITY" \
> >>>>>>>    migration-threshold="1"
> >>>>>>>
> >>>>>>> -------------------------------------------------------------------------
> >>>>>>>
> >>>>>>> よろしくお願い致します。
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Linux-ha-japan mailing list
> >>>>>>> Linux-ha-japan [at] lists
> >>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Linux-ha-japan mailing list
> >>>>>> Linux-ha-japan [at] lists
> >>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>
> >>>>> _______________________________________________
> >>>>> Linux-ha-japan mailing list
> >>>>> Linux-ha-japan [at] lists
> >>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Linux-ha-japan mailing list
> >>>> Linux-ha-japan [at] lists
> >>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>
> >>>
> >>> _______________________________________________
> >>> Linux-ha-japan mailing list
> >>> Linux-ha-japan [at] lists
> >>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
> >> _______________________________________________
> >> Linux-ha-japan mailing list
> >> Linux-ha-japan [at] lists
> >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan [at] lists
> > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

wada.shinichiro at jp

Feb 27, 2012, 10:52 PM

Post #11 of 13 (673 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

山内さん

こんにちは。
和田です。

私が勘違いしていそうだったので。。。追加で質問させてください。

>> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。
>
> すいません。ちょっとこの意味がわかりませんでした。

ですが、

>>> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。

とコメントを頂いたので、両系がPassiveになっても、一定時間経過後にSTONITHされて、
OS再起動されるので、復旧すると理解したのですが、認識が誤っているでしょうか？

よろしくお願い致します。

> 和田さん
>
> こんにちは、山内です。
>
> 回答しますね。
>
>>
>> たびたびありがとうございます。
>>
>> インラインで記述(★)します。
>>
>>> 和田さん
>>>
>>> こんにちは、山内です。
>>>
>>> 再度、コメントしますね。
>>>
>>>
>>>> 山内さん
>>>>
>>>> こんにちは。
>>>> 和田です。
>>>>
>>>> 丁寧なご説明ありがとうございます。
>>>> 申し訳ないのですが、もう少しご教示ください。
>>>>
>>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>>>
>>>> つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、
>>>>
>>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>>>
>>>> のパターンでのSTONITH実行は行われないという理解であっているでしょうか？
>>>
>>> いえ、実行されないのは、QUORUMの制御が入る(freeze,stop)場合のみです。
>>> stonith-enabled="true"で適切にstonithモジュールが設定されていれば、ignoreでは
>>> stonithをクラスタ消失したノードに実行しようとします。
>>> ＃ただし、Active/Passiveではお互いに実行しようとしますので、ここでstonith-helperの出番となります。
>>
>> ★Active/Passive構成の場合、ignoreにしておかないと、分断時を含めノード消失時にSTONITHが
>> 　実行されないということですね。
>
> はい。
> 現象を見られた通り、ignoreにしないと、初期起動時はリソースすら起動しないという現象も発生します。
>
>
>>
>>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
>>>>> Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>>>>
>>>> とありますが、「Activeが優先して残るような構成」とは
>>>> 具体的にはどのような設定になるのでしょうか？
>>>> ＃locationに設定するscore値をさしているのでしょうか？
>>>
>>> すいません。
>>> ちょっと曖昧で間違っていま
>>> した。
>>> Activeノードか、PassiveノードでPassive側に待ちをかませる為に、Activeで起動するリソースを指定してくださいという意味です。
>>> ＃これがないと、お互いに実行しようとするstonithで相打ちが発生します。
>>> ちなみに、これがある場合には、Passiveノードは待たされるので、Activeノードがまだ生きている場合は、Activeからのstonithが成功します。
>>> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。
>>
>> ★freeze,stopの場合はstandby_check_commandを設定しなくても、実行されるサーバが
>> 　限られるので問題ないが、ignoreの場合は無条件時実行されるので、standby_check_commandを
>> 　設定する必要があるということですね。
>
> はい。その通りです。
>
>>
>> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。
>
> すいません。ちょっとこの意味がわかりませんでした。
>
>
>>
>>>>
>>>> また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、
>>>>
>>>>> stonithが実行されるのは、
>>>>>
>>>>> ①リソースのon-fail="fence"の障害が発生した場合
>>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>>>>
>>>> Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
>>>> 分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
>>>> 以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
>>>> 再起動されていたいように記憶しています。
>>>>
>>>
>>> 復旧後にstonithが実行される場合はあります。
>>> stonith-helperなどがない場合、分断が起きてstonithを実行しようとするクラスタ側(例えば、3ノード構成で2ノードに分かれた側からの1ノード側）へのstonithは、通常ssh接続も出来ないで失敗するはずですので、stonithをしようとし続けます。
>>> このstonithが成功しないと、2ノード側では次のアクションを起こせません。
>>>
>>> よって、スプリットブレインが復旧された後で、ssh接続が可能になったので1ノード側はstonithされてしまいます。
>>
>> ★追加のフォローについても了解しました。
>
> 宜しくお願いたします。
>
>>
>>>>
>>>> 分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
>>>> それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？
>>>
>>> はい。
>>> sshのstonithがタイムアウトを起こす前に接続するとsshのstonithが実行されるはずです。
>>>
>>> 提示したstonithリソースグループであれば、もし、sshのstonithもタイムアウトで失敗すれば、meatwareに制御が移りますが、それもタイムアウトを起こせば、また、先頭のstonith-helperからやり直します。
>>> ＃要はstonithが完了するまでは、ずっとstonithをします。
>>
>> ★保守者介在を施す必要はなくて、とにかく自動で復旧させたい場合は、
>> 　meatwareを設定しなければ、繰り返し、sshをチャレンジしてくれると
>> 　いうことですね。
>
> はい。完了するまでチャレンジします。
> ＃しかし、ノードが完全故障すると長いサービス停止を招くので、データセンターなどでは保守者介在の道を残してあるというのが正解ですね。
> ＃また、sshではなく、サーバのiLO,RSAなどが利用できる場合、そちらのstonithを利用するというのも有効です。(sshよりも確実に落とせる）
> ＃さらに、stonith-helperが相手ノードの完全故障停止を判断できるように設定してあれば、かなり有効です。（stonith-helperが成功するとチャレンジは終了）
>
>
>>
>> 自分の理解が不十分だった点も含め、いろいろと理解することできました。
>> お忙しいところいろいろとありがとうございました。
>
> いえいえ、また何かありましたら、お気軽にＭＬに質問してみてください。
>
> 以上、宜しくお願いいたします。
>
>
>>
>>>
>>> 以上、宜しくお願いいたします。
>>>>
>>>> よろしくお願い致します。
>>>>
>>>>> 和田さん
>>>>>
>>>>> こんにちは、山内です。
>>>>>
>>>>> さらにstonithの実行契機について補足しておくと。。。。
>>>>>
>>>>> stonithが実行されるのは、
>>>>>
>>>>> ①リソースのon-fail="fence"の障害が発生した場合
>>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>>>>>
>>>>> などになります。
>>>>> ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
>>>>>
>>>>> 以上、宜しくお願いいたします。
>>>>> --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb> wrote:
>>>>>
>>>>>> 和田さん
>>>>>>
>>>>>> こんにちは、山内です。
>>>>>>
>>>>>> 以下、補足いたしますね。
>>>>>>
>>>>>>> 山内さん
>>>>>>>
>>>>>>> こんにちは。
>>>>>>> 和田です。
>>>>>>>
>>>>>>> いつもご回答ありがとうございます。
>>>>>>>
>>>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>>>>>
>>>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>>>>>
>>>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>>>>>> stonith-helperなどを利用することが望ましいです。
>>>>>>>>
>>>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>>>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>>>>
>>>>>>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
>>>>>>> ご教示ください。
>>>>>>>
>>>>>>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
>>>>>>> STONITHは実行されるのでしょうか？
>>>>>>
>>>>>> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
>>>>>> stonithは実行されます。
>>>>>>
>>>>>>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
>>>>>>> などの動作をするのでしょうか？
>>>>>>
>>>>>> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
>>>>>> なったことによって実行されるstonithになります。
>>>>>> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
>>>>>>
>>>>>> no-quorum-policyの設定について、補足すると。。。
>>>>>>
>>>>>> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
>>>>>>
>>>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>>>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>>>>>
>>>>>> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
>>>>>>
>>>>>> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
>>>>>>
>>>>>>>
>>>>>>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
>>>>>>> 理解でよろしいでしょうか？
>>>>>>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
>>>>>>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
>>>>>>> 両系ともPassive状態となり復旧しなかったんですよね。。。
>>>>>>
>>>>>> stonith-helperの設定例を抜粋します。
>>>>>>
>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>>>> params \
>>>>>> priority="1" \
>>>>>> stonith-timeout="40s" \
>>>>>> hostlist="db1" \
>>>>>> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
>>>>>> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
>>>>>> op start interval="0s" timeout="60s" \
>>>>>> op monitor interval="10s" timeout="60s" \
>>>>>> op stop interval="0s" timeout="60s"
>>>>>>
>>>>>> 設定のポイントは、
>>>>>> １）hostlist　相手ノードを指定。
>>>>>> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
>>>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>>>>>> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
>>>>>>
>>>>>> stonith-helper自体は、stonithのグループとして先頭に設定してください。
>>>>>> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
>>>>>>
>>>>>> group grpStonith1 \
>>>>>> prmStonith1-1 \
>>>>>> prmStonith1-2 \
>>>>>> prmStonith1-3
>>>>>>
>>>>>> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
>>>>>>
>>>>>> 以上、宜しくお願いいたします。
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> よろしくお願い致します。
>>>>>>>
>>>>>>>> 和田さん
>>>>>>>>
>>>>>>>> こんにちは、山内です。
>>>>>>>>
>>>>>>>>
>>>>>>>>> こんにちは。
>>>>>>>>> 和田です。
>>>>>>>>>
>>>>>>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
>>>>>>>>>
>>>>>>>>> STONITHを設定している状態で、
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> property no-quorum-policy="freeze" \
>>>>>>>>> stonith-enabled="true" \
>>>>>>>>> startup-fencing="false" \
>>>>>>>>> stonith-timeout="430s"
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> と設定した場合、
>>>>>>>>>
>>>>>>>>> ・片故障状態で、システムを起動すると正常に起動しない。
>>>>>>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
>>>>>>>>>
>>>>>>>>> という動作をします。
>>>>>>>>>
>>>>>>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
>>>>>>>>> 認識しているのですが、認識はあっているでしょうか？
>>>>>>>>
>>>>>>>> はい。あっています。
>>>>>>>>
>>>>>>>>
>>>>>>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
>>>>>>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
>>>>>>>>>
>>>>>>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
>>>>>>>>> どのような設定としているのでしょうか？
>>>>>>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
>>>>>>>>> というような構成が一般的なのでしょうか？
>>>>>>>>
>>>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>>>>>
>>>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>>>>>
>>>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>>>>>> stonith-helperなどを利用することが望ましいです。
>>>>>>>>
>>>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>>>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>>>>>
>>>>>>>>
>>>>>>>> 以上、宜しくお願いいたします。
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
>>>>>>>>> 以下の構成となっています。
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> primitive drbd_db ocf:linbit:drbd \
>>>>>>>>> params drbd_resource="pgsql" \
>>>>>>>>> op start interval="0s" timeout="240s" on-fail="restart" \
>>>>>>>>> op monitor interval="11s" timeout="60s" on-fail="restart" \
>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
>>>>>>>>> op stop interval="0s" timeout="100s" on-fail="fence"
>>>>>>>>>
>>>>>>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
>>>>>>>>> params ip="192.168.1.175" \
>>>>>>>>> nic="eth1" \
>>>>>>>>> cidr_netmask="24" \
>>>>>>>>> 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 prmPing ocf:pacemaker:ping \
>>>>>>>>> params \
>>>>>>>>> name="ping_set" \
>>>>>>>>> host_list="192.168.1.1 192.168.2.1" \
>>>>>>>>> multiplier="100" \
>>>>>>>>> dampen="0" \
>>>>>>>>> meta \
>>>>>>>>> migration-threshold="3" \
>>>>>>>>> failure-timeout="60s" \
>>>>>>>>> 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="ignore"
>>>>>>>>>
>>>>>>>>> primitive fs_db ocf:heartbeat:Filesystem \
>>>>>>>>> params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
>>>>>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>>>>>
>>>>>>>>> primitive prmPg ocf:heartbeat:pgsql \
>>>>>>>>> params pgctl="/usr/bin/pg_ctl" \
>>>>>>>>> start_opt="-p 5432" \
>>>>>>>>> psql="/usr/bin/psql" \
>>>>>>>>> pgdata="/data/" \
>>>>>>>>> pgdba="postgres" \
>>>>>>>>> pgport="5432" \
>>>>>>>>> pgdb="postgres" \
>>>>>>>>> op start interval="0s" timeout="120s" on-fail="restart" \
>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>> op stop interval="0s" timeout="120s" on-fail="fence"
>>>>>>>>>
>>>>>>>>> primitive apache ocf:heartbeat:apache \
>>>>>>>>> params configfile="/etc/httpd/conf/httpd.conf" \
>>>>>>>>> port="80" \
>>>>>>>>> op start interval="0s" timeout="40s" on-fail="restart" \
>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>>>>>
>>>>>>>>> primitive prmDiskd ocf:pacemaker:diskd \
>>>>>>>>> params name="diskd_set" \
>>>>>>>>> device="/dev/sda1" \
>>>>>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>> op stop interval="0s" timeout="60s" on-fail="ignore"
>>>>>>>>>
>>>>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>>>>>>> params \
>>>>>>>>> priority="1" \
>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>> hostlist="it13" \
>>>>>>>>> dead_check_target="192.168.1.173" \
>>>>>>>>> run_standby_wait="no" \
>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>
>>>>>>>>> primitive prmStonith1-2 stonith:external/ssh \
>>>>>>>>> params \
>>>>>>>>> priority="2" \
>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>> hostlist="it13" \
>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>
>>>>>>>>> primitive prmStonith1-3 stonith:meatware \
>>>>>>>>> params \
>>>>>>>>> priority="3" \
>>>>>>>>> stonith-timeout="600" \
>>>>>>>>> hostlist="it13" \
>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>
>>>>>>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
>>>>>>>>> params \
>>>>>>>>> priority="1" \
>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>> hostlist="it14" \
>>>>>>>>> dead_check_target="192.168.1.174" \
>>>>>>>>> run_standby_wait="no" \
>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>
>>>>>>>>> primitive prmStonith2-2 stonith:external/ssh \
>>>>>>>>> params \
>>>>>>>>> priority="2" \
>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>> hostlist="it14" \
>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>
>>>>>>>>> primitive prmStonith2-3 stonith:meatware \
>>>>>>>>> params \
>>>>>>>>> priority="3" \
>>>>>>>>> stonith-timeout="600" \
>>>>>>>>> hostlist="it14" \
>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>
>>>>>>>>> group group_all fs_db ip_db prmPg apache
>>>>>>>>>
>>>>>>>>> group grpStonith1 \
>>>>>>>>> prmStonith1-1 \
>>>>>>>>> prmStonith1-2 \
>>>>>>>>> prmStonith1-3
>>>>>>>>>
>>>>>>>>> group grpStonith2 \
>>>>>>>>> prmStonith2-1 \
>>>>>>>>> prmStonith2-2 \
>>>>>>>>> prmStonith2-3
>>>>>>>>>
>>>>>>>>> ms ms_drbd_db drbd_db \
>>>>>>>>> meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
>>>>>>>>>
>>>>>>>>> clone clnPing prmPing \
>>>>>>>>> meta clone-max="2" clone-node-max="1"
>>>>>>>>>
>>>>>>>>> clone clnDiskd prmDiskd \
>>>>>>>>> meta clone-max="2" clone-node-max="1"
>>>>>>>>>
>>>>>>>>> location group_all-location group_all \
>>>>>>>>> rule 200: #uname eq it13 \
>>>>>>>>> rule 100: #uname eq it14 \
>>>>>>>>> rule -INFINITY: defined ping_set and ping_set lt 200 \
>>>>>>>>> rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
>>>>>>>>>
>>>>>>>>> location master-location_db ms_drbd_db \
>>>>>>>>> rule 200: #uname eq it13 \
>>>>>>>>> rule 100: #uname eq it14 \
>>>>>>>>> rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
>>>>>>>>> rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
>>>>>>>>> rule role=master -INFINITY: defined fail-count-fs_db \
>>>>>>>>> rule role=master -INFINITY: defined fail-count-ip_db \
>>>>>>>>> rule role=master -INFINITY: defined fail-count-prmPg \
>>>>>>>>> rule role=master -INFINITY: defined fail-count-apache
>>>>>>>>>
>>>>>>>>> location rsc_location-grpStonith1-1 grpStonith1 \
>>>>>>>>> rule -INFINITY: #uname eq it13
>>>>>>>>>
>>>>>>>>> location rsc_location-grpStonith2-1 grpStonith2 \
>>>>>>>>> rule -INFINITY: #uname eq it14
>>>>>>>>>
>>>>>>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
>>>>>>>>> colocation clnPing-colocation INFINITY: group_all clnPing
>>>>>>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
>>>>>>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
>>>>>>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
>>>>>>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
>>>>>>>>>
>>>>>>>>> property no-quorum-policy="freeze" \
>>>>>>>>> stonith-enabled="true" \
>>>>>>>>> startup-fencing="false" \
>>>>>>>>> stonith-timeout="430s"
>>>>>>>>>
>>>>>>>>> rsc_defaults resource-stickiness="INFINITY" \
>>>>>>>>> migration-threshold="1"
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> よろしくお願い致します。
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-ha-japan mailing list
>>>>>>>>> Linux-ha-japan [at] lists
>>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-ha-japan mailing list
>>>>>>>> Linux-ha-japan [at] lists
>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux-ha-japan [at] lists
>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux-ha-japan [at] lists
>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan [at] lists
>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan [at] lists
>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan [at] lists
>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan [at] lists
>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

renayama19661014 at ybb

Feb 27, 2012, 11:01 PM

Post #12 of 13 (674 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

和田さん

こんにちは、山内です。

コメントしますね。

>
> 私が勘違いしていそうだったので。。。追加で質問させてください。
>
> >> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。
> >
> > すいません。ちょっとこの意味がわかりませんでした。
>
> ですが、
>
> >>> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。
>
> とコメントを頂いたので、両系がPassiveになっても、一定時間経過後にSTONITHされて、
> OS再起動されるので、復旧すると理解したのですが、認識が誤っているでしょうか？
>

すいません。これもわかりずらい書き方ですね。

ここでの例は、両系がPassiveというよりも、Activeがダウンしている場合の話でした。
Passiveのstonith-helperは、standby_check_commandでリソースを起動していないので、
待ちが発生してからActiveにstonithを実行するという意味でした。
#リソースはどこにも起動していないので、この状態を両系がPassiveという事であれば、ご認識の通りです。

以上、宜しく御願いいたします。

> よろしくお願い致します。
>
> > 和田さん
> >
> > こんにちは、山内です。
> >
> > 回答しますね。
> >
> >>
> >> たびたびありがとうございます。
> >>
> >> インラインで記述(★)します。
> >>
> >>> 和田さん
> >>>
> >>> こんにちは、山内です。
> >>>
> >>> 再度、コメントしますね。
> >>>
> >>>
> >>>> 山内さん
> >>>>
> >>>> こんにちは。
> >>>> 和田です。
> >>>>
> >>>> 丁寧なご説明ありがとうございます。
> >>>> 申し訳ないのですが、もう少しご教示ください。
> >>>>
> >>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> >>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
> >>>>
> >>>> つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、
> >>>>
> >>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> >>>>
> >>>> のパターンでのSTONITH実行は行われないという理解であっているでしょうか？
> >>>
> >>> いえ、実行されないのは、QUORUMの制御が入る(freeze,stop)場合のみです。
> >>> stonith-enabled="true"で適切にstonithモジュールが設定されていれば、ignoreでは
> >>> stonithをクラスタ消失したノードに実行しようとします。
> >>> ＃ただし、Active/Passiveではお互いに実行しようとしますので、ここでstonith-helperの出番となります。
> >>
> >> ★Active/Passive構成の場合、ignoreにしておかないと、分断時を含めノード消失時にSTONITHが
> >> 　実行されないということですね。
> >
> > はい。
> > 現象を見られた通り、ignoreにしないと、初期起動時はリソースすら起動しないという現象も発生します。
> >
> >
> >>
> >>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
> >>>>> Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
> >>>>
> >>>> とありますが、「Activeが優先して残るような構成」とは
> >>>> 具体的にはどのような設定になるのでしょうか？
> >>>> ＃locationに設定するscore値をさしているのでしょうか？
> >>>
> >>> すいません。
> >>> ちょっと曖昧で間違っていま
> >>> した。
> >>> Activeノードか、PassiveノードでPassive側に待ちをかませる為に、Activeで起動するリソースを指定してくださいという意味です。
> >>> ＃これがないと、お互いに実行しようとするstonithで相打ちが発生します。
> >>> ちなみに、これがある場合には、Passiveノードは待たされるので、Activeノードがまだ生きている場合は、Activeからのstonithが成功します。
> >>> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。
> >>
> >> ★freeze,stopの場合はstandby_check_commandを設定しなくても、実行されるサーバが
> >> 　限られるので問題ないが、ignoreの場合は無条件時実行されるので、standby_check_commandを
> >> 　設定する必要があるということですね。
> >
> > はい。その通りです。
> >
> >>
> >> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。
> >
> > すいません。ちょっとこの意味がわかりませんでした。
> >
> >
> >>
> >>>>
> >>>> また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、
> >>>>
> >>>>> stonithが実行されるのは、
> >>>>>
> >>>>> ①リソースのon-fail="fence"の障害が発生した場合
> >>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> >>>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
> >>>>
> >>>> Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
> >>>> 分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
> >>>> 以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
> >>>> 再起動されていたいように記憶しています。
> >>>>
> >>>
> >>> 復旧後にstonithが実行される場合はあります。
> >>> stonith-helperなどがない場合、分断が起きてstonithを実行しようとするクラスタ側(例えば、3ノード構成で2ノードに分かれた側からの1ノード側）へのstonithは、通常ssh接続も出来ないで失敗するはずですので、stonithをしようとし続けます。
> >>> このstonithが成功しないと、2ノード側では次のアクションを起こせません。
> >>>
> >>> よって、スプリットブレインが復旧された後で、ssh接続が可能になったので1ノード側はstonithされてしまいます。
> >>
> >> ★追加のフォローについても了解しました。
> >
> > 宜しくお願いたします。
> >
> >>
> >>>>
> >>>> 分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
> >>>> それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？
> >>>
> >>> はい。
> >>> sshのstonithがタイムアウトを起こす前に接続するとsshのstonithが実行されるはずです。
> >>>
> >>> 提示したstonithリソースグループであれば、もし、sshのstonithもタイムアウトで失敗すれば、meatwareに制御が移りますが、それもタイムアウトを起こせば、また、先頭のstonith-helperからやり直します。
> >>> ＃要はstonithが完了するまでは、ずっとstonithをします。
> >>
> >> ★保守者介在を施す必要はなくて、とにかく自動で復旧させたい場合は、
> >> 　meatwareを設定しなければ、繰り返し、sshをチャレンジしてくれると
> >> 　いうことですね。
> >
> > はい。完了するまでチャレンジします。
> > ＃しかし、ノードが完全故障すると長いサービス停止を招くので、データセンターなどでは保守者介在の道を残してあるというのが正解ですね。
> > ＃また、sshではなく、サーバのiLO,RSAなどが利用できる場合、そちらのstonithを利用するというのも有効です。(sshよりも確実に落とせる）
> > ＃さらに、stonith-helperが相手ノードの完全故障停止を判断できるように設定してあれば、かなり有効です。（stonith-helperが成功するとチャレンジは終了）
> >
> >
> >>
> >> 自分の理解が不十分だった点も含め、いろいろと理解することできました。
> >> お忙しいところいろいろとありがとうございました。
> >
> > いえいえ、また何かありましたら、お気軽にＭＬに質問してみてください。
> >
> > 以上、宜しくお願いいたします。
> >
> >
> >>
> >>>
> >>> 以上、宜しくお願いいたします。
> >>>>
> >>>> よろしくお願い致します。
> >>>>
> >>>>> 和田さん
> >>>>>
> >>>>> こんにちは、山内です。
> >>>>>
> >>>>> さらにstonithの実行契機について補足しておくと。。。。
> >>>>>
> >>>>> stonithが実行されるのは、
> >>>>>
> >>>>> ①リソースのon-fail="fence"の障害が発生した場合
> >>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
> >>>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
> >>>>>
> >>>>> などになります。
> >>>>> ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
> >>>>>
> >>>>> 以上、宜しくお願いいたします。
> >>>>> --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb> wrote:
> >>>>>
> >>>>>> 和田さん
> >>>>>>
> >>>>>> こんにちは、山内です。
> >>>>>>
> >>>>>> 以下、補足いたしますね。
> >>>>>>
> >>>>>>> 山内さん
> >>>>>>>
> >>>>>>> こんにちは。
> >>>>>>> 和田です。
> >>>>>>>
> >>>>>>> いつもご回答ありがとうございます。
> >>>>>>>
> >>>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >>>>>>>>
> >>>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >>>>>>>>
> >>>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> >>>>>>>> stonith-helperなどを利用することが望ましいです。
> >>>>>>>>
> >>>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> >>>>>>>> また、場合によっては、vipcheckなども有効でしょう。
> >>>>>>>
> >>>>>>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
> >>>>>>> ご教示ください。
> >>>>>>>
> >>>>>>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
> >>>>>>> STONITHは実行されるのでしょうか？
> >>>>>>
> >>>>>> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
> >>>>>> stonithは実行されます。
> >>>>>>
> >>>>>>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
> >>>>>>> などの動作をするのでしょうか？
> >>>>>>
> >>>>>> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
> >>>>>> なったことによって実行されるstonithになります。
> >>>>>> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
> >>>>>>
> >>>>>> no-quorum-policyの設定について、補足すると。。。
> >>>>>>
> >>>>>> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
> >>>>>>
> >>>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
> >>>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
> >>>>>>
> >>>>>> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
> >>>>>>
> >>>>>> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
> >>>>>>
> >>>>>>>
> >>>>>>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
> >>>>>>> 理解でよろしいでしょうか？
> >>>>>>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
> >>>>>>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
> >>>>>>> 両系ともPassive状態となり復旧しなかったんですよね。。。
> >>>>>>
> >>>>>> stonith-helperの設定例を抜粋します。
> >>>>>>
> >>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
> >>>>>> params \
> >>>>>> priority="1" \
> >>>>>> stonith-timeout="40s" \
> >>>>>> hostlist="db1" \
> >>>>>> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
> >>>>>> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
> >>>>>> op start interval="0s" timeout="60s" \
> >>>>>> op monitor interval="10s" timeout="60s" \
> >>>>>> op stop interval="0s" timeout="60s"
> >>>>>>
> >>>>>> 設定のポイントは、
> >>>>>> １）hostlist　相手ノードを指定。
> >>>>>> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
> >>>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
> >>>>>> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
> >>>>>>
> >>>>>> stonith-helper自体は、stonithのグループとして先頭に設定してください。
> >>>>>> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
> >>>>>>
> >>>>>> group grpStonith1 \
> >>>>>> prmStonith1-1 \
> >>>>>> prmStonith1-2 \
> >>>>>> prmStonith1-3
> >>>>>>
> >>>>>> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
> >>>>>>
> >>>>>> 以上、宜しくお願いいたします。
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> よろしくお願い致します。
> >>>>>>>
> >>>>>>>> 和田さん
> >>>>>>>>
> >>>>>>>> こんにちは、山内です。
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> こんにちは。
> >>>>>>>>> 和田です。
> >>>>>>>>>
> >>>>>>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
> >>>>>>>>>
> >>>>>>>>> STONITHを設定している状態で、
> >>>>>>>>>
> >>>>>>>>> -------------------------------------------------------------------------
> >>>>>>>>>
> >>>>>>>>> property no-quorum-policy="freeze" \
> >>>>>>>>> stonith-enabled="true" \
> >>>>>>>>>    startup-fencing="false" \
> >>>>>>>>>    stonith-timeout="430s"
> >>>>>>>>>
> >>>>>>>>> -------------------------------------------------------------------------
> >>>>>>>>>
> >>>>>>>>> と設定した場合、
> >>>>>>>>>
> >>>>>>>>> ・片故障状態で、システムを起動すると正常に起動しない。
> >>>>>>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
> >>>>>>>>>
> >>>>>>>>> という動作をします。
> >>>>>>>>>
> >>>>>>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
> >>>>>>>>> 認識しているのですが、認識はあっているでしょうか？
> >>>>>>>>
> >>>>>>>> はい。あっています。
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
> >>>>>>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
> >>>>>>>>>
> >>>>>>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
> >>>>>>>>> どのような設定としているのでしょうか？
> >>>>>>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
> >>>>>>>>> というような構成が一般的なのでしょうか？
> >>>>>>>>
> >>>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
> >>>>>>>>
> >>>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
> >>>>>>>>
> >>>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
> >>>>>>>> stonith-helperなどを利用することが望ましいです。
> >>>>>>>>
> >>>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
> >>>>>>>> また、場合によっては、vipcheckなども有効でしょう。
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 以上、宜しくお願いいたします。
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
> >>>>>>>>> 以下の構成となっています。
> >>>>>>>>>
> >>>>>>>>> -------------------------------------------------------------------------
> >>>>>>>>>
> >>>>>>>>> primitive drbd_db ocf:linbit:drbd \
> >>>>>>>>>    params drbd_resource="pgsql" \
> >>>>>>>>>    op start interval="0s" timeout="240s" on-fail="restart" \
> >>>>>>>>>    op monitor interval="11s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
> >>>>>>>>>    op stop interval="0s" timeout="100s" on-fail="fence"
> >>>>>>>>>
> >>>>>>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
> >>>>>>>>>    params ip="192.168.1.175" \
> >>>>>>>>>    nic="eth1" \
> >>>>>>>>>    cidr_netmask="24" \
> >>>>>>>>>    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 prmPing ocf:pacemaker:ping \
> >>>>>>>>>    params \
> >>>>>>>>>    name="ping_set" \
> >>>>>>>>>    host_list="192.168.1.1 192.168.2.1" \
> >>>>>>>>>    multiplier="100" \
> >>>>>>>>>    dampen="0" \
> >>>>>>>>>    meta \
> >>>>>>>>>    migration-threshold="3" \
> >>>>>>>>>    failure-timeout="60s" \
> >>>>>>>>>    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="ignore"
> >>>>>>>>>
> >>>>>>>>> primitive fs_db ocf:heartbeat:Filesystem \
> >>>>>>>>>    params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
> >>>>>>>>>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>>>>>>>>
> >>>>>>>>> primitive prmPg ocf:heartbeat:pgsql \
> >>>>>>>>>    params pgctl="/usr/bin/pg_ctl" \
> >>>>>>>>>    start_opt="-p 5432" \
> >>>>>>>>>    psql="/usr/bin/psql" \
> >>>>>>>>>    pgdata="/data/" \
> >>>>>>>>>    pgdba="postgres" \
> >>>>>>>>>    pgport="5432" \
> >>>>>>>>>    pgdb="postgres" \
> >>>>>>>>>    op start interval="0s" timeout="120s" on-fail="restart" \
> >>>>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op stop interval="0s" timeout="120s" on-fail="fence"
> >>>>>>>>>
> >>>>>>>>> primitive apache ocf:heartbeat:apache \
> >>>>>>>>>    params configfile="/etc/httpd/conf/httpd.conf" \
> >>>>>>>>>    port="80" \
> >>>>>>>>>    op start interval="0s" timeout="40s" on-fail="restart" \
> >>>>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op stop interval="0s" timeout="60s" on-fail="fence"
> >>>>>>>>>
> >>>>>>>>> primitive prmDiskd ocf:pacemaker:diskd \
> >>>>>>>>>    params name="diskd_set" \
> >>>>>>>>>    device="/dev/sda1" \
> >>>>>>>>>    op start interval="0s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op monitor interval="10s" timeout="60s" on-fail="restart" \
> >>>>>>>>>    op stop interval="0s" timeout="60s" on-fail="ignore"
> >>>>>>>>>
> >>>>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
> >>>>>>>>> params \
> >>>>>>>>> priority="1" \
> >>>>>>>>> stonith-timeout="60s" \
> >>>>>>>>> hostlist="it13" \
> >>>>>>>>> dead_check_target="192.168.1.173" \
> >>>>>>>>> run_standby_wait="no" \
> >>>>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>>>
> >>>>>>>>> primitive prmStonith1-2 stonith:external/ssh \
> >>>>>>>>> params \
> >>>>>>>>> priority="2" \
> >>>>>>>>> stonith-timeout="60s" \
> >>>>>>>>> hostlist="it13" \
> >>>>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>>>
> >>>>>>>>> primitive prmStonith1-3 stonith:meatware \
> >>>>>>>>> params \
> >>>>>>>>> priority="3" \
> >>>>>>>>> stonith-timeout="600" \
> >>>>>>>>> hostlist="it13" \
> >>>>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>>>
> >>>>>>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
> >>>>>>>>> params \
> >>>>>>>>> priority="1" \
> >>>>>>>>> stonith-timeout="60s" \
> >>>>>>>>> hostlist="it14" \
> >>>>>>>>> dead_check_target="192.168.1.174" \
> >>>>>>>>> run_standby_wait="no" \
> >>>>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>>>
> >>>>>>>>> primitive prmStonith2-2 stonith:external/ssh \
> >>>>>>>>> params \
> >>>>>>>>> priority="2" \
> >>>>>>>>> stonith-timeout="60s" \
> >>>>>>>>> hostlist="it14" \
> >>>>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>>>
> >>>>>>>>> primitive prmStonith2-3 stonith:meatware \
> >>>>>>>>> params \
> >>>>>>>>> priority="3" \
> >>>>>>>>> stonith-timeout="600" \
> >>>>>>>>> hostlist="it14" \
> >>>>>>>>> op start interval="0s" timeout="60s" \
> >>>>>>>>> op monitor interval="3600s" timeout="60s" \
> >>>>>>>>> op stop interval="0s" timeout="60s"
> >>>>>>>>>
> >>>>>>>>> group group_all fs_db ip_db prmPg apache
> >>>>>>>>>
> >>>>>>>>> group grpStonith1 \
> >>>>>>>>> prmStonith1-1 \
> >>>>>>>>> prmStonith1-2 \
> >>>>>>>>> prmStonith1-3
> >>>>>>>>>
> >>>>>>>>> group grpStonith2 \
> >>>>>>>>> prmStonith2-1 \
> >>>>>>>>> prmStonith2-2 \
> >>>>>>>>> prmStonith2-3
> >>>>>>>>>
> >>>>>>>>> ms ms_drbd_db drbd_db \
> >>>>>>>>>    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
> >>>>>>>>>
> >>>>>>>>> clone clnPing prmPing \
> >>>>>>>>>    meta clone-max="2" clone-node-max="1"
> >>>>>>>>>
> >>>>>>>>> clone clnDiskd prmDiskd \
> >>>>>>>>>    meta clone-max="2" clone-node-max="1"
> >>>>>>>>>
> >>>>>>>>> location group_all-location group_all \
> >>>>>>>>>    rule 200: #uname eq it13 \
> >>>>>>>>>    rule 100: #uname eq it14 \
> >>>>>>>>>    rule -INFINITY: defined ping_set and ping_set lt 200 \
> >>>>>>>>>    rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
> >>>>>>>>>
> >>>>>>>>> location master-location_db ms_drbd_db \
> >>>>>>>>>    rule 200: #uname eq it13 \
> >>>>>>>>>    rule 100: #uname eq it14 \
> >>>>>>>>>    rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
> >>>>>>>>>    rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
> >>>>>>>>>    rule role=master -INFINITY: defined fail-count-fs_db \
> >>>>>>>>>    rule role=master -INFINITY: defined fail-count-ip_db \
> >>>>>>>>>    rule role=master -INFINITY: defined fail-count-prmPg \
> >>>>>>>>>    rule role=master -INFINITY: defined fail-count-apache
> >>>>>>>>>
> >>>>>>>>> location rsc_location-grpStonith1-1 grpStonith1 \
> >>>>>>>>> rule -INFINITY: #uname eq it13
> >>>>>>>>>
> >>>>>>>>> location rsc_location-grpStonith2-1 grpStonith2 \
> >>>>>>>>> rule -INFINITY: #uname eq it14
> >>>>>>>>>
> >>>>>>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
> >>>>>>>>> colocation clnPing-colocation INFINITY: group_all clnPing
> >>>>>>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
> >>>>>>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
> >>>>>>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
> >>>>>>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
> >>>>>>>>>
> >>>>>>>>> property no-quorum-policy="freeze" \
> >>>>>>>>> stonith-enabled="true" \
> >>>>>>>>>    startup-fencing="false" \
> >>>>>>>>>    stonith-timeout="430s"
> >>>>>>>>>
> >>>>>>>>> rsc_defaults resource-stickiness="INFINITY" \
> >>>>>>>>>    migration-threshold="1"
> >>>>>>>>>
> >>>>>>>>> -------------------------------------------------------------------------
> >>>>>>>>>
> >>>>>>>>> よろしくお願い致します。
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Linux-ha-japan mailing list
> >>>>>>>>> Linux-ha-japan [at] lists
> >>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Linux-ha-japan mailing list
> >>>>>>>> Linux-ha-japan [at] lists
> >>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Linux-ha-japan mailing list
> >>>>>>> Linux-ha-japan [at] lists
> >>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Linux-ha-japan mailing list
> >>>>>> Linux-ha-japan [at] lists
> >>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Linux-ha-japan mailing list
> >>>>> Linux-ha-japan [at] lists
> >>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>
> >>>> _______________________________________________
> >>>> Linux-ha-japan mailing list
> >>>> Linux-ha-japan [at] lists
> >>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>>>
> >>>
> >>> _______________________________________________
> >>> Linux-ha-japan mailing list
> >>> Linux-ha-japan [at] lists
> >>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
> >> _______________________________________________
> >> Linux-ha-japan mailing list
> >> Linux-ha-japan [at] lists
> >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan [at] lists
> > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

wada.shinichiro at jp

Feb 27, 2012, 11:21 PM

Post #13 of 13 (673 views)
Permalink

Re: Active/Passive構成でのSTONITHの設定について [In reply to]

山内さん

こんにちは。
和田です。

すみません。
両系Passiveという記述がよろしくなかったですね。
＃私の理解も少しずれていたのですが。。。

standby_check_commandでActiveじゃないと判断されても
Activeが存在しない場合は一定時間経過後に、STONITHが
実行されるということですね。

何度もありがとうございました。

> 和田さん
>
> こんにちは、山内です。
>
> コメントしますね。
>
>>
>> 私が勘違いしていそうだったので。。。追加で質問させてください。
>>
>>>> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。
>>>
>>> すいません。ちょっとこの意味がわかりませんでした。
>>
>> ですが、
>>
>>>>> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。
>>
>> とコメントを頂いたので、両系がPassiveになっても、一定時間経過後にSTONITHされて、
>> OS再起動されるので、復旧すると理解したのですが、認識が誤っているでしょうか？
>>
>
> すいません。これもわかりずらい書き方ですね。
>
> ここでの例は、両系がPassiveというよりも、Activeがダウンしている場合の話でした。
> Passiveのstonith-helperは、standby_check_commandでリソースを起動していないので、
> 待ちが発生してからActiveにstonithを実行するという意味でした。
> #リソースはどこにも起動していないので、この状態を両系がPassiveという事であれば、ご認識の通りです。
>
> 以上、宜しく御願いいたします。
>
>
>
>
>
>> よろしくお願い致します。
>>
>>> 和田さん
>>>
>>> こんにちは、山内です。
>>>
>>> 回答しますね。
>>>
>>>>
>>>> たびたびありがとうございます。
>>>>
>>>> インラインで記述(★)します。
>>>>
>>>>> 和田さん
>>>>>
>>>>> こんにちは、山内です。
>>>>>
>>>>> 再度、コメントしますね。
>>>>>
>>>>>
>>>>>> 山内さん
>>>>>>
>>>>>> こんにちは。
>>>>>> 和田です。
>>>>>>
>>>>>> 丁寧なご説明ありがとうございます。
>>>>>> 申し訳ないのですが、もう少しご教示ください。
>>>>>>
>>>>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>>>>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>>>>>
>>>>>> つまり、今回の構成(Active/Passive構成)ではfreeze,stop,ignoreのいずれを設定しても、
>>>>>>
>>>>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>>>>>
>>>>>> のパターンでのSTONITH実行は行われないという理解であっているでしょうか？
>>>>>
>>>>> いえ、実行されないのは、QUORUMの制御が入る(freeze,stop)場合のみです。
>>>>> stonith-enabled="true"で適切にstonithモジュールが設定されていれば、ignoreでは
>>>>> stonithをクラスタ消失したノードに実行しようとします。
>>>>> ＃ただし、Active/Passiveではお互いに実行しようとしますので、ここでstonith-helperの出番となります。
>>>>
>>>> ★Active/Passive構成の場合、ignoreにしておかないと、分断時を含めノード消失時にSTONITHが
>>>> 　実行されないということですね。
>>>
>>> はい。
>>> 現象を見られた通り、ignoreにしないと、初期起動時はリソースすら起動しないという現象も発生します。
>>>
>>>
>>>>
>>>>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させて
>>>>>>> Activeが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>>>>>>
>>>>>> とありますが、「Activeが優先して残るような構成」とは
>>>>>> 具体的にはどのような設定になるのでしょうか？
>>>>>> ＃locationに設定するscore値をさしているのでしょうか？
>>>>>
>>>>> すいません。
>>>>> ちょっと曖昧で間違っていま
>>>>> した。
>>>>> Activeノードか、PassiveノードでPassive側に待ちをかませる為に、Activeで起動するリソースを指定してくださいという意味です。
>>>>> ＃これがないと、お互いに実行しようとするstonithで相打ちが発生します。
>>>>> ちなみに、これがある場合には、Passiveノードは待たされるので、Activeノードがまだ生きている場合は、Activeからのstonithが成功します。
>>>>> もし、Activeがダウンしている場合は、Passiveの待ち時間後に、Activeが必要があればstonithされます。
>>>>
>>>> ★freeze,stopの場合はstandby_check_commandを設定しなくても、実行されるサーバが
>>>> 　限られるので問題ないが、ignoreの場合は無条件時実行されるので、standby_check_commandを
>>>> 　設定する必要があるということですね。
>>>
>>> はい。その通りです。
>>>
>>>>
>>>> 　また、両系がPassiveになっても、一定時間経過後にSTONITHされるということですね。
>>>
>>> すいません。ちょっとこの意味がわかりませんでした。
>>>
>>>
>>>>
>>>>>>
>>>>>> また、以前質問させて頂いたないようと類似の質問になってしまい申し訳ないのですが、
>>>>>>
>>>>>>> stonithが実行されるのは、
>>>>>>>
>>>>>>> ①リソースのon-fail="fence"の障害が発生した場合
>>>>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>>>>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>>>>>>
>>>>>> Active/Passive以外の構成で、通信できず、スプリットブレインとなった場合、
>>>>>> 分断されてしまいますが、その場合、復旧後にSTONITHは実行されないのでしょうか？
>>>>>> 以前、検証した際には復旧後にSSHが実行され、QUORUMを持っていないサーバが
>>>>>> 再起動されていたいように記憶しています。
>>>>>>
>>>>>
>>>>> 復旧後にstonithが実行される場合はあります。
>>>>> stonith-helperなどがない場合、分断が起きてstonithを実行しようとするクラスタ側(例えば、3ノード構成で2ノードに分かれた側からの1ノード側）へのstonithは、通常ssh接続も出来ないで失敗するはずですので、stonithをしようとし続けます。
>>>>> このstonithが成功しないと、2ノード側では次のアクションを起こせません。
>>>>>
>>>>> よって、スプリットブレインが復旧された後で、ssh接続が可能になったので1ノード側はstonithされてしまいます。
>>>>
>>>> ★追加のフォローについても了解しました。
>>>
>>> 宜しくお願いたします。
>>>
>>>>
>>>>>>
>>>>>> 分断後、復旧までの時間が短ければSSHが実行されるのでしょうか？
>>>>>> それとも、一定期間監視を続け、その後、meatwareに制御が移るのでしょうか？
>>>>>
>>>>> はい。
>>>>> sshのstonithがタイムアウトを起こす前に接続するとsshのstonithが実行されるはずです。
>>>>>
>>>>> 提示したstonithリソースグループであれば、もし、sshのstonithもタイムアウトで失敗すれば、meatwareに制御が移りますが、それもタイムアウトを起こせば、また、先頭のstonith-helperからやり直します。
>>>>> ＃要はstonithが完了するまでは、ずっとstonithをします。
>>>>
>>>> ★保守者介在を施す必要はなくて、とにかく自動で復旧させたい場合は、
>>>> 　meatwareを設定しなければ、繰り返し、sshをチャレンジしてくれると
>>>> 　いうことですね。
>>>
>>> はい。完了するまでチャレンジします。
>>> ＃しかし、ノードが完全故障すると長いサービス停止を招くので、データセンターなどでは保守者介在の道を残してあるというのが正解ですね。
>>> ＃また、sshではなく、サーバのiLO,RSAなどが利用できる場合、そちらのstonithを利用するというのも有効です。(sshよりも確実に落とせる）
>>> ＃さらに、stonith-helperが相手ノードの完全故障停止を判断できるように設定してあれば、かなり有効です。（stonith-helperが成功するとチャレンジは終了）
>>>
>>>
>>>>
>>>> 自分の理解が不十分だった点も含め、いろいろと理解することできました。
>>>> お忙しいところいろいろとありがとうございました。
>>>
>>> いえいえ、また何かありましたら、お気軽にＭＬに質問してみてください。
>>>
>>> 以上、宜しくお願いいたします。
>>>
>>>
>>>>
>>>>>
>>>>> 以上、宜しくお願いいたします。
>>>>>>
>>>>>> よろしくお願い致します。
>>>>>>
>>>>>>> 和田さん
>>>>>>>
>>>>>>> こんにちは、山内です。
>>>>>>>
>>>>>>> さらにstonithの実行契機について補足しておくと。。。。
>>>>>>>
>>>>>>> stonithが実行されるのは、
>>>>>>>
>>>>>>> ①リソースのon-fail="fence"の障害が発生した場合
>>>>>>> ②クラスタを構成していたノードが消失（分断や電源断でクラスタ構成から消えた）場合
>>>>>>> ③ちょっと例外的ですが、startup-fencing="true"が設定されている場合
>>>>>>>
>>>>>>> などになります。
>>>>>>> ただし、クラスタ構成で、stonith-enabled="true"が設定されていて、stonithリソースが設定されてなければ意味はありませんが。。。
>>>>>>>
>>>>>>> 以上、宜しくお願いいたします。
>>>>>>> --- On Tue, 2012/2/28, renayama19661014 [at] ybb<renayama19661014 [at] ybb> wrote:
>>>>>>>
>>>>>>>> 和田さん
>>>>>>>>
>>>>>>>> こんにちは、山内です。
>>>>>>>>
>>>>>>>> 以下、補足いたしますね。
>>>>>>>>
>>>>>>>>> 山内さん
>>>>>>>>>
>>>>>>>>> こんにちは。
>>>>>>>>> 和田です。
>>>>>>>>>
>>>>>>>>> いつもご回答ありがとうございます。
>>>>>>>>>
>>>>>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>>>>>>>
>>>>>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>>>>>>>
>>>>>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>>>>>>>> stonith-helperなどを利用することが望ましいです。
>>>>>>>>>>
>>>>>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>>>>>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>>>>>>
>>>>>>>>> no-quorum-policyとstonith-helperについて十分に理解ができていないようなので
>>>>>>>>> ご教示ください。
>>>>>>>>>
>>>>>>>>> まず、no-quorum-policyですが、ignoreして分断が発生した場合でも
>>>>>>>>> STONITHは実行されるのでしょうか？
>>>>>>>>
>>>>>>>> はい。Active/Passive管理しているリソースのＦＯ動作は開始されるので
>>>>>>>> stonithは実行されます。
>>>>>>>>
>>>>>>>>> no-quorum-policyではSTONITHは実行されないが、monitorの間隔で実行される
>>>>>>>>> などの動作をするのでしょうか？
>>>>>>>>
>>>>>>>> いいえ、ここはActive/Passiveそれぞれのノードから見て、相手ノードの状態が不定に
>>>>>>>> なったことによって実行されるstonithになります。
>>>>>>>> monitorなどは関係ありませんが、しいて言えば、ha.cfのdeadtimeが関係します。
>>>>>>>>
>>>>>>>> no-quorum-policyの設定について、補足すると。。。
>>>>>>>>
>>>>>>>> ignoreの場合は、QUORUM定数の判断はしないので、処理が進みます。（ここでいうとstonithに制御が移ります)
>>>>>>>>
>>>>>>>> freeze,stopの場合には、まず先にQUORUM定数の判断をして、処理が進みます。
>>>>>>>> ※ただし、Active/Passiveの構成ではQUORUMは分断が発生した場合には、stonithには制御は移りません。
>>>>>>>>
>>>>>>>> もし、Active/Active/Passive構成であれば、どこかで１ノードのみが離脱した場合にはQUORUMを持っている方がstonithに進んで、持っていないほうは、そのままか、リソースを停止することになります。
>>>>>>>>
>>>>>>>> あくまでも、no-qourum-policyの設定は、判断が入って制御が行われるか？制御が行われないか（igonoreの場合)だけに影響しています。
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 次にstonith-helperですが、run_standby_waitでのチェックが必要という
>>>>>>>>> 理解でよろしいでしょうか？
>>>>>>>>> それとも、run_standby_wait自体はnoのままでも問題ないのでしょうか？
>>>>>>>>> 以前、run_standby_waitでactチェックし、NIC障害発生の確認をした際に
>>>>>>>>> 両系ともPassive状態となり復旧しなかったんですよね。。。
>>>>>>>>
>>>>>>>> stonith-helperの設定例を抜粋します。
>>>>>>>>
>>>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>>>>>> params \
>>>>>>>> priority="1" \
>>>>>>>> stonith-timeout="40s" \
>>>>>>>> hostlist="db1" \
>>>>>>>> dead_check_target="192.168.40.170 192.168.40.170 192.168.40.170" \
>>>>>>>> standby_check_command="/usr/sbin/crm_resource -r prmExAAAAA -W | grep -q `hostname`" \
>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>> op monitor interval="10s" timeout="60s" \
>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>
>>>>>>>> 設定のポイントは、
>>>>>>>> １）hostlist　相手ノードを指定。
>>>>>>>> ２）dead_check_target 相手ノードの存在がdead(全て切れていればノードはダウン)判定できるアドレスを全て指定(この例では、サービスＬＡＮとHeartbeat用のＬＡＮ２つ）
>>>>>>>> ３）standby_check_command　自ノードがリソースを持っているかどうかを判断させてActiveが優先して残るような構成では、Activeで起動するリソースを判定できるような設定をしてください。
>>>>>>>> ４）その他のパラメータは基本的には設定不要だと思います（デフォルトのままでＯＫ）
>>>>>>>>
>>>>>>>> stonith-helper自体は、stonithのグループとして先頭に設定してください。
>>>>>>>> 必ず、次のstonithのグループには実stonithを実行するようなstonithモジュールを設定してください。（以下では、Stonith1-1がhelperで、Stonith1-2がssh, Stonith1-3がmeatwareになっています。sshのstonithが失敗した場合に、保守者介在が必要になるケースを考慮しています）
>>>>>>>>
>>>>>>>> group grpStonith1 \
>>>>>>>> prmStonith1-1 \
>>>>>>>> prmStonith1-2 \
>>>>>>>> prmStonith1-3
>>>>>>>>
>>>>>>>> また、stonith-helper自体は、お互いのノード用にリソース構成に配置することをお忘れなく。。。。。
>>>>>>>>
>>>>>>>> 以上、宜しくお願いいたします。
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> よろしくお願い致します。
>>>>>>>>>
>>>>>>>>>> 和田さん
>>>>>>>>>>
>>>>>>>>>> こんにちは、山内です。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> こんにちは。
>>>>>>>>>>> 和田です。
>>>>>>>>>>>
>>>>>>>>>>> Active/Passive構成でのSTONITH関連の設定についてご教示ください。
>>>>>>>>>>>
>>>>>>>>>>> STONITHを設定している状態で、
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> property no-quorum-policy="freeze" \
>>>>>>>>>>> stonith-enabled="true" \
>>>>>>>>>>> startup-fencing="false" \
>>>>>>>>>>> stonith-timeout="430s"
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> と設定した場合、
>>>>>>>>>>>
>>>>>>>>>>> ・片故障状態で、システムを起動すると正常に起動しない。
>>>>>>>>>>> ・Active側がハード故障等でダウンするとうまく切り替わらない。
>>>>>>>>>>>
>>>>>>>>>>> という動作をします。
>>>>>>>>>>>
>>>>>>>>>>> 以前、山内さんに教えて頂いた様に、quorum定数が半分以下になるため、切り替わらないと
>>>>>>>>>>> 認識しているのですが、認識はあっているでしょうか？
>>>>>>>>>>
>>>>>>>>>> はい。あっています。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> freezeからignoreにすることで、正常に切り替わることは確認しました。
>>>>>>>>>>> ＃ただし、スプリットブレインなどが困りますよね。。。
>>>>>>>>>>>
>>>>>>>>>>> また、一般的な設定として、みなさんは上記の事象に対応する際に、
>>>>>>>>>>> どのような設定としているのでしょうか？
>>>>>>>>>>> NICを冗長化することで、Active/Passive構成ではSTONITHを利用しない
>>>>>>>>>>> というような構成が一般的なのでしょうか？
>>>>>>>>>>
>>>>>>>>>> 私個人の意見ですが、単純にActive/Passive構成を考えた場合、stonithは設定するべきだと思っています。
>>>>>>>>>>
>>>>>>>>>> ですので、no-quorum-policyはActive/Passiveの場合"ignore"に設定して、stonithを設定する構成です。
>>>>>>>>>>
>>>>>>>>>> ただし、2ノードの場合、分断時に落としあいが発生することを回避する為に、
>>>>>>>>>> stonith-helperなどを利用することが望ましいです。
>>>>>>>>>>
>>>>>>>>>> stonith-helperは、日本コミュニティのpm_extrasパッケージにあります。
>>>>>>>>>> また、場合によっては、vipcheckなども有効でしょう。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 以上、宜しくお願いいたします。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> なお、構成は以前質問させて頂いたときと同様で、Corosync + Pacemaker + DRBDで
>>>>>>>>>>> 以下の構成となっています。
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> primitive drbd_db ocf:linbit:drbd \
>>>>>>>>>>> params drbd_resource="pgsql" \
>>>>>>>>>>> op start interval="0s" timeout="240s" on-fail="restart" \
>>>>>>>>>>> op monitor interval="11s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" role="Master" \
>>>>>>>>>>> op stop interval="0s" timeout="100s" on-fail="fence"
>>>>>>>>>>>
>>>>>>>>>>> primitive ip_db ocf:heartbeat:IPaddr2 \
>>>>>>>>>>> params ip="192.168.1.175" \
>>>>>>>>>>> nic="eth1" \
>>>>>>>>>>> cidr_netmask="24" \
>>>>>>>>>>> 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 prmPing ocf:pacemaker:ping \
>>>>>>>>>>> params \
>>>>>>>>>>> name="ping_set" \
>>>>>>>>>>> host_list="192.168.1.1 192.168.2.1" \
>>>>>>>>>>> multiplier="100" \
>>>>>>>>>>> dampen="0" \
>>>>>>>>>>> meta \
>>>>>>>>>>> migration-threshold="3" \
>>>>>>>>>>> failure-timeout="60s" \
>>>>>>>>>>> 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="ignore"
>>>>>>>>>>>
>>>>>>>>>>> primitive fs_db ocf:heartbeat:Filesystem \
>>>>>>>>>>> params device="/dev/drbd/by-res/pgsql" directory="/data" fstype="ext4" \
>>>>>>>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmPg ocf:heartbeat:pgsql \
>>>>>>>>>>> params pgctl="/usr/bin/pg_ctl" \
>>>>>>>>>>> start_opt="-p 5432" \
>>>>>>>>>>> psql="/usr/bin/psql" \
>>>>>>>>>>> pgdata="/data/" \
>>>>>>>>>>> pgdba="postgres" \
>>>>>>>>>>> pgport="5432" \
>>>>>>>>>>> pgdb="postgres" \
>>>>>>>>>>> op start interval="0s" timeout="120s" on-fail="restart" \
>>>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op stop interval="0s" timeout="120s" on-fail="fence"
>>>>>>>>>>>
>>>>>>>>>>> primitive apache ocf:heartbeat:apache \
>>>>>>>>>>> params configfile="/etc/httpd/conf/httpd.conf" \
>>>>>>>>>>> port="80" \
>>>>>>>>>>> op start interval="0s" timeout="40s" on-fail="restart" \
>>>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op stop interval="0s" timeout="60s" on-fail="fence"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmDiskd ocf:pacemaker:diskd \
>>>>>>>>>>> params name="diskd_set" \
>>>>>>>>>>> device="/dev/sda1" \
>>>>>>>>>>> op start interval="0s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op monitor interval="10s" timeout="60s" on-fail="restart" \
>>>>>>>>>>> op stop interval="0s" timeout="60s" on-fail="ignore"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmStonith1-1 stonith:external/stonith-helper \
>>>>>>>>>>> params \
>>>>>>>>>>> priority="1" \
>>>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>>>> hostlist="it13" \
>>>>>>>>>>> dead_check_target="192.168.1.173" \
>>>>>>>>>>> run_standby_wait="no" \
>>>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmStonith1-2 stonith:external/ssh \
>>>>>>>>>>> params \
>>>>>>>>>>> priority="2" \
>>>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>>>> hostlist="it13" \
>>>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmStonith1-3 stonith:meatware \
>>>>>>>>>>> params \
>>>>>>>>>>> priority="3" \
>>>>>>>>>>> stonith-timeout="600" \
>>>>>>>>>>> hostlist="it13" \
>>>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmStonith2-1 stonith:external/stonith-helper \
>>>>>>>>>>> params \
>>>>>>>>>>> priority="1" \
>>>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>>>> hostlist="it14" \
>>>>>>>>>>> dead_check_target="192.168.1.174" \
>>>>>>>>>>> run_standby_wait="no" \
>>>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmStonith2-2 stonith:external/ssh \
>>>>>>>>>>> params \
>>>>>>>>>>> priority="2" \
>>>>>>>>>>> stonith-timeout="60s" \
>>>>>>>>>>> hostlist="it14" \
>>>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>>>
>>>>>>>>>>> primitive prmStonith2-3 stonith:meatware \
>>>>>>>>>>> params \
>>>>>>>>>>> priority="3" \
>>>>>>>>>>> stonith-timeout="600" \
>>>>>>>>>>> hostlist="it14" \
>>>>>>>>>>> op start interval="0s" timeout="60s" \
>>>>>>>>>>> op monitor interval="3600s" timeout="60s" \
>>>>>>>>>>> op stop interval="0s" timeout="60s"
>>>>>>>>>>>
>>>>>>>>>>> group group_all fs_db ip_db prmPg apache
>>>>>>>>>>>
>>>>>>>>>>> group grpStonith1 \
>>>>>>>>>>> prmStonith1-1 \
>>>>>>>>>>> prmStonith1-2 \
>>>>>>>>>>> prmStonith1-3
>>>>>>>>>>>
>>>>>>>>>>> group grpStonith2 \
>>>>>>>>>>> prmStonith2-1 \
>>>>>>>>>>> prmStonith2-2 \
>>>>>>>>>>> prmStonith2-3
>>>>>>>>>>>
>>>>>>>>>>> ms ms_drbd_db drbd_db \
>>>>>>>>>>> meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
>>>>>>>>>>>
>>>>>>>>>>> clone clnPing prmPing \
>>>>>>>>>>> meta clone-max="2" clone-node-max="1"
>>>>>>>>>>>
>>>>>>>>>>> clone clnDiskd prmDiskd \
>>>>>>>>>>> meta clone-max="2" clone-node-max="1"
>>>>>>>>>>>
>>>>>>>>>>> location group_all-location group_all \
>>>>>>>>>>> rule 200: #uname eq it13 \
>>>>>>>>>>> rule 100: #uname eq it14 \
>>>>>>>>>>> rule -INFINITY: defined ping_set and ping_set lt 200 \
>>>>>>>>>>> rule -INFINITY: defined diskd_set and diskd_set eq SUCCESS
>>>>>>>>>>>
>>>>>>>>>>> location master-location_db ms_drbd_db \
>>>>>>>>>>> rule 200: #uname eq it13 \
>>>>>>>>>>> rule 100: #uname eq it14 \
>>>>>>>>>>> rule role=master -INFINITY: defined ping_set and ping_set lt 200 \
>>>>>>>>>>> rule role=master -INFINITY: defined diskd_set and diskd_set eq SUCCESS \
>>>>>>>>>>> rule role=master -INFINITY: defined fail-count-fs_db \
>>>>>>>>>>> rule role=master -INFINITY: defined fail-count-ip_db \
>>>>>>>>>>> rule role=master -INFINITY: defined fail-count-prmPg \
>>>>>>>>>>> rule role=master -INFINITY: defined fail-count-apache
>>>>>>>>>>>
>>>>>>>>>>> location rsc_location-grpStonith1-1 grpStonith1 \
>>>>>>>>>>> rule -INFINITY: #uname eq it13
>>>>>>>>>>>
>>>>>>>>>>> location rsc_location-grpStonith2-1 grpStonith2 \
>>>>>>>>>>> rule -INFINITY: #uname eq it14
>>>>>>>>>>>
>>>>>>>>>>> colocation db_on_drbd INFINITY: group_all ms_drbd_db:Master
>>>>>>>>>>> colocation clnPing-colocation INFINITY: group_all clnPing
>>>>>>>>>>> colocation clnDiskd-colocation INFINITY: group_all clnDiskd
>>>>>>>>>>> order order_db_after_drbd INFINITY: ms_drbd_db:promote group_all:start
>>>>>>>>>>> order order_clnPing_after_all 0: clnPing group_all symmetrical=false
>>>>>>>>>>> order order_clnDiskd_after_all 0: clnDiskd group_all symmetrical=false
>>>>>>>>>>>
>>>>>>>>>>> property no-quorum-policy="freeze" \
>>>>>>>>>>> stonith-enabled="true" \
>>>>>>>>>>> startup-fencing="false" \
>>>>>>>>>>> stonith-timeout="430s"
>>>>>>>>>>>
>>>>>>>>>>> rsc_defaults resource-stickiness="INFINITY" \
>>>>>>>>>>> migration-threshold="1"
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Linux-ha-japan mailing list
>>>>>>>>>>> Linux-ha-japan [at] lists
>>>>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Linux-ha-japan mailing list
>>>>>>>>>> Linux-ha-japan [at] lists
>>>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-ha-japan mailing list
>>>>>>>>> Linux-ha-japan [at] lists
>>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-ha-japan mailing list
>>>>>>>> Linux-ha-japan [at] lists
>>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux-ha-japan [at] lists
>>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux-ha-japan [at] lists
>>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan [at] lists
>>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan [at] lists
>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>>>
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan [at] lists
>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan [at] lists
>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan [at] lists
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan [at] lists
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

Linux-HA japanese RSS feed

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads

& Powered by Gossamer Threads Inc.