Mailing List Archive

$B2>A[(BIP$B$@$1$,(B$B%j%=!<%9$N>l9g$NF15o!&=g=x@)Ls(B$B$OI,MW$+!)(B
$B9-@%$H?=$7$^$9(B


Pacemaker$B!\(BHeartbeat$B$G$N<h$j07$$$K$J$j$^$9$,!"7GBj$NDL$j$K(B
$B%j%=!<%9$O=c?h$K2>A[(BIP$B$@$1$,<gLr$H$J$k%N!<%I$,$"$C$?$H$7$^$9(B


$B"#MWLs$7$?%j%=!<%9Dj5A$O0J2<(B($B:Y$+$$%Q%i%a!<%?$O>J$-$^$7$?(B)
=============================================================
primitive res_pingd ocf:pacemaker:ping
primitive res_vip ocf:heartbeat:IPaddr2
primitive res_vipchk ocf:heartbeat:VIPcheck
primitive res_diskd ocf:pacemaker:diskd
group rg_test res_vipchk res_vip
clone cl_diskd res_diskd
clone cl_pingd res_pingd
location l_test rg_test \
rule 200: #uname eq A-host.local \
rule 100: #uname eq B-host.local \
rule -inf: not_defined ping_chk or ping_chk lt 100 \
rule -inf: not_defined disk_chk or disk_chk eq ERROR
=============================================================


$B4pK\E*$K$O$3$l$@$1$G$bF0:n$O$9$k$H;W$$$^$9!#0LCV@)Ls$G@_Dj$7$?(B
$BCM$K=>$$!"0J2<$G5/F0$7$F$/$l$^$9(B

$B!!-!M%@h(BAct$B$O(BA-host.local$B$G5/F0(B
$B!!-"(BF/O$B$7$?>l9g!"(BFailback$B$O4pK\E*$K$O$7$J$$(B
$B!!-#(BAct$BB&$N(BPing$B!"$^$?$O(BDisk$B4F;k$,0[>o$H$J$C$?>l9g!"(BF/O$B$9$k(B
$B!!-$N>7O$H$b(BPing$B!"$^$?$O(BDisk$B4F;k$,0[>o$J$i$P0l@Z%j%=!<%9$O(B
$B!!!!5/F0$7$J$$(B

$B;v<B>e3F(BPrimitive$B$K;XDj$5$l$?>r7o$K=>$$@5>o$K(BF/O$B$7$^$9$7!"N>7O(B
$B$,0[>o$J$i%j%=!<%9$ON>7O$H$b$K%j%=!<%9$O5/F0$7$^$;$s$N$G!"$3$l(B
$B$@$1$G$b>r7o$OK~$?$7$F$$$k$N$+$J$H;W$$$^$9!#(B
$B$3$N>u672<$K$*$$$F!"F15o@)Ls!"JB$S$K=g=x@)Ls$OI,MW$H$9$kM}M3$O(B
$B$"$k$N$+5?Ld$,Ib$+$s$G$-$^$7$?(B
$B=g=x@)Ls$K4X$7$F$O!"(BClone$B%j%=!<%9$,5/F0$7$J$$Fb$K(BGroup$B%j%=!<%9(B
$B$,5/F0$9$k7|G0$,$"$j$^$9$,!"5/F0B.EY$+$i$7$F$b$5$7$FLdBj$K$O$J(B
$B$i$J$$$+$J$H$b;W$$$^$9(B

$B!!"($=$b$=$bO@!"(BPing/Disk$B0[>o$,$"$k>uBV$G5/F0$5$;$k;v<+BN$,$"$j(B
$B!!!!F@$J$$$N$G!"@5>o$J9=@.>uBV$G$"$C$F=i$a$F5/F0$9$k$N$G!&!&!&(B


$B>e5-$N;vNc$K$*$$$F$O(Bcolocation/order$B$,I,MW$H$J$j$&$kM}M3$,$"$j(B
$B$^$7$?$i!"$4;XE&$$$?$@$1$k$H9,$$$G$9!#(B


$B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
Re: 仮想IPだけがリソースの場合の同居・順序制約は必要か? [ In reply to ]
広瀬さん

こんばんは、山内です。

例えば、

 2ノードACT/STB構成で、primitiveリソースA(Dummy)とcloneリソース(diskd)

をcolocation無(通常、colcation リソースA with cloneリソースを省略)で配置した場合、

diskdのプロセスが落ちた場合にprimiverリソースAは、STBノードへファイルオーバーしなくなります。
#diskdの故障自体は、検知しますが。。。

これは、colocationがない為に、故障後のSTBノードへの配置計算にdiskdの故障が反映出来ない為です。

当然、diskdなどリソースの作りにもよる話ですが、colocationを組んでおいた方が良いと思います。

以上です。




----- Original Message -----
> From: "momoko@mail.t-momoko.org" <momoko@mail.t-momoko.org>
> To: Linux-ha-japan@lists.osdn.me
> Cc:
> Date: 2015/11/10, Tue 13:17
> Subject: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>
> 広瀬と申します
>
>
> Pacemaker+Heartbeatでの取り扱いになりますが、掲題の通りに
> リソースは純粋に仮想IPだけが主役となるノードがあったとします
>
>
> ■要約したリソース定義は以下(細かいパラメータは省きました)
> =============================================================
> primitive res_pingd ocf:pacemaker:ping
> primitive res_vip ocf:heartbeat:IPaddr2
> primitive res_vipchk ocf:heartbeat:VIPcheck
> primitive res_diskd ocf:pacemaker:diskd
> group rg_test res_vipchk res_vip
> clone cl_diskd res_diskd
> clone cl_pingd res_pingd
> location l_test rg_test \
>     rule 200: #uname eq A-host.local \
>     rule 100: #uname eq B-host.local \
>     rule -inf: not_defined ping_chk or ping_chk lt 100 \
>     rule -inf: not_defined disk_chk or disk_chk eq ERROR
> =============================================================
>
>
> 基本的にはこれだけでも動作はすると思います。位置制約で設定した
> 値に従い、以下で起動してくれます
>
>  ①優先ActはA-host.localで起動
>  ②F/Oした場合、Failbackは基本的にはしない
>  ③Act側のPing、またはDisk監視が異常となった場合、F/Oする
>  ④両系ともPing、またはDisk監視が異常ならば一切リソースは
>   起動しない
>
> 事実上各Primitiveに指定された条件に従い正常にF/Oしますし、両系
> が異常ならリソースは両系ともにリソースは起動しませんので、これ
> だけでも条件は満たしているのかなと思います。
> この状況下において、同居制約、並びに順序制約は必要とする理由は
> あるのか疑問が浮かんできました
> 順序制約に関しては、Cloneリソースが起動しない内にGroupリソース
> が起動する懸念がありますが、起動速度からしてもさして問題にはな
> らないかなとも思います
>
>  ※そもそも論、Ping/Disk異常がある状態で起動させる事自体があり
>   得ないので、正常な構成状態であって初めて起動するので・・・
>
>
> 上記の事例においてはcolocation/orderが必要となりうる理由があり
> ましたら、ご指摘いただけると幸いです。
>
>
> 以上、よろしくお願いいたします。
>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: 仮想IPだけがリソースの場合の同居・順序制約は必要か? [ In reply to ]
広瀬です。


山内さま、ご回答ありがとうございます。

Ping/Disk監視プロセスが落ちた場合という事を頭に入れておらず、
Ping/Disk監視で、”異常”を検知した場合のみに固執していました。
ご指摘ありがとうございます。

primitive res_diskd ocf:pacemaker:diskd \
params name="disk_chk" write_dir="/tmp" interval="10" \
op start interval="0" timeout="60" on-fail="restart" \
op stop interval="0" timeout="60" on-fail="block" \
op monitor interval="10" timeout="60" on-fail="restart" \
meta migration-threshold="1"

primitive res_pingd ocf:pacemaker:ping \
params name="ping_chk" host_list="<IPアドレス>" multiplier="100" dampen="10" \
op start interval="0" timeout="60" on-fail="restart" \
op stop interval="0" timeout="20" on-fail="block" \
op monitor interval="10" timeout="60" on-fail="restart" \
meta migration-threshold="1"

全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
にF/O発動はいたしました<改めて試験いたしました。
また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
を停止した場合、またICMPを遮断してもF/Oする事も確認しました。


 ※本設定ではシステム領域のDisk異常発生時を見ていますが、実はこれで
  はI/Oエラー発動させると正常には動作しません。別HDDのデータドライ
  ブや、共有ディスクであれば問題なく発動しますが・・・


このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも
ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように
解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス
コア計算の概念にどう当てはまって行くのかが悩みどころです。


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

renayama19661014@ybb.ne.jpさん:
> 広瀬さん
>
> こんばんは、山内です。
>
> 例えば、
>
>  2ノードACT/STB構成で、primitiveリソースA(Dummy)とcloneリソース(diskd)
>
> をcolocation無(通常、colcation リソースA with cloneリソースを省略)で配置した場合、
>
> diskdのプロセスが落ちた場合にprimiverリソースAは、STBノードへファイルオーバーしなくなります。
> #diskdの故障自体は、検知しますが。。。
>
> これは、colocationがない為に、故障後のSTBノードへの配置計算にdiskdの故障が反映出来ない為です。
>
> 当然、diskdなどリソースの作りにもよる話ですが、colocationを組んでおいた方が良いと思います。
>
> 以上です。
>
>
>
>
> ----- Original Message -----
> > From: "momoko@mail.t-momoko.org" <momoko@mail.t-momoko.org>
> > To: Linux-ha-japan@lists.osdn.me
> > Cc:
> > Date: 2015/11/10, Tue 13:17
> > Subject: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
> >
> > 広瀬と申します
> >
> >
> > Pacemaker+Heartbeatでの取り扱いになりますが、掲題の通りに
> > リソースは純粋に仮想IPだけが主役となるノードがあったとします
> >
> >
> > ■要約したリソース定義は以下(細かいパラメータは省きました)
> > =============================================================
> > primitive res_pingd ocf:pacemaker:ping
> > primitive res_vip ocf:heartbeat:IPaddr2
> > primitive res_vipchk ocf:heartbeat:VIPcheck
> > primitive res_diskd ocf:pacemaker:diskd
> > group rg_test res_vipchk res_vip
> > clone cl_diskd res_diskd
> > clone cl_pingd res_pingd
> > location l_test rg_test \
> >     rule 200: #uname eq A-host.local \
> >     rule 100: #uname eq B-host.local \
> >     rule -inf: not_defined ping_chk or ping_chk lt 100 \
> >     rule -inf: not_defined disk_chk or disk_chk eq ERROR
> > =============================================================
> >
> >
> > 基本的にはこれだけでも動作はすると思います。位置制約で設定した
> > 値に従い、以下で起動してくれます
> >
> >  ①優先ActはA-host.localで起動
> >  ②F/Oした場合、Failbackは基本的にはしない
> >  ③Act側のPing、またはDisk監視が異常となった場合、F/Oする
> >  ④両系ともPing、またはDisk監視が異常ならば一切リソースは
> >   起動しない
> >
> > 事実上各Primitiveに指定された条件に従い正常にF/Oしますし、両系
> > が異常ならリソースは両系ともにリソースは起動しませんので、これ
> > だけでも条件は満たしているのかなと思います。
> > この状況下において、同居制約、並びに順序制約は必要とする理由は
> > あるのか疑問が浮かんできました
> > 順序制約に関しては、Cloneリソースが起動しない内にGroupリソース
> > が起動する懸念がありますが、起動速度からしてもさして問題にはな
> > らないかなとも思います
> >
> >  ※そもそも論、Ping/Disk異常がある状態で起動させる事自体があり
> >   得ないので、正常な構成状態であって初めて起動するので・・・
> >
> >
> > 上記の事例においてはcolocation/orderが必要となりうる理由があり
> > ましたら、ご指摘いただけると幸いです。
> >
> >
> > 以上、よろしくお願いいたします。
> >
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan@lists.osdn.me
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: 仮想IPだけがリソースの場合の同居・順序制約は必要か? [ In reply to ]
広瀬さん

こんばんは、山内です。

> 全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
> 内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
> にF/O発動はいたしました<改めて試験いたしました。
> また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
> を停止した場合、またICMPを遮断してもF/Oする事も確認しました。


すいません。
先ほどの回答ですが、私の方では、PM1.1系で確認していました。

再度、PM1.0系(PM+Heartbeat)でも明日、確認してみます。
#記憶違いがなければ、同じ動作だと思うのですが。。。。

diskdは、primitiveの他にdiskdプロセスが上がっているのでそちらをkillして、先ほどの回答は記載していました。
広瀬さんの方でも、同様の手順であれば、PM1.1の相違だと思います。

また、明日にでも回答いたします。

以上です。



----- Original Message -----
> From: "momoko@mail.t-momoko.org" <momoko@mail.t-momoko.org>
> To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
> Cc:
> Date: 2015/11/10, Tue 22:53
> Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>
> 広瀬です。
>
>
> 山内さま、ご回答ありがとうございます。
>
> Ping/Disk監視プロセスが落ちた場合という事を頭に入れておらず、
> Ping/Disk監視で、”異常”を検知した場合のみに固執していました。
> ご指摘ありがとうございます。
>
> primitive res_diskd ocf:pacemaker:diskd \
>         params name="disk_chk" write_dir="/tmp"
> interval="10" \
>         op start interval="0" timeout="60"
> on-fail="restart" \
>         op stop interval="0" timeout="60"
> on-fail="block" \
>         op monitor interval="10" timeout="60"
> on-fail="restart" \
>         meta migration-threshold="1"
>
> primitive res_pingd ocf:pacemaker:ping \
>         params name="ping_chk" host_list="<IPアドレス>"
> multiplier="100" dampen="10" \
>         op start interval="0" timeout="60"
> on-fail="restart" \
>         op stop interval="0" timeout="20"
> on-fail="block" \
>         op monitor interval="10" timeout="60"
> on-fail="restart" \
>         meta migration-threshold="1"
>
> 全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
> 内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
> にF/O発動はいたしました<改めて試験いたしました。
> また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
> を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
>
>
>  ※本設定ではシステム領域のDisk異常発生時を見ていますが、実はこれで
>   はI/Oエラー発動させると正常には動作しません。別HDDのデータドライ
>   ブや、共有ディスクであれば問題なく発動しますが・・・
>
>
> このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも
> ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように
> 解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス
> コア計算の概念にどう当てはまって行くのかが悩みどころです。
>
>
> よろしくお願いいたします。
>
> renayama19661014@ybb.ne.jpさん:
>> 広瀬さん
>>
>> こんばんは、山内です。
>>
>> 例えば、
>>
>>  2ノードACT/STB構成で、primitiveリソースA(Dummy)とcloneリソース(diskd)
>>
>> をcolocation無(通常、colcation リソースA with cloneリソースを省略)で配置した場合、
>>
>> diskdのプロセスが落ちた場合にprimiverリソースAは、STBノードへファイルオーバーしなくなります。
>> #diskdの故障自体は、検知しますが。。。
>>
>> これは、colocationがない為に、故障後のSTBノードへの配置計算にdiskdの故障が反映出来ない為です。
>>
>> 当然、diskdなどリソースの作りにもよる話ですが、colocationを組んでおいた方が良いと思います。
>>
>> 以上です。
>>
>>
>>
>>
>> ----- Original Message -----
>> > From: "momoko@mail.t-momoko.org"
> <momoko@mail.t-momoko.org>
>> > To: Linux-ha-japan@lists.osdn.me
>> > Cc:
>> > Date: 2015/11/10, Tue 13:17
>> > Subject: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>> >
>> > 広瀬と申します
>> >
>> >
>> > Pacemaker+Heartbeatでの取り扱いになりますが、掲題の通りに
>> > リソースは純粋に仮想IPだけが主役となるノードがあったとします
>> >
>> >
>> > ■要約したリソース定義は以下(細かいパラメータは省きました)
>> > =============================================================
>> > primitive res_pingd ocf:pacemaker:ping
>> > primitive res_vip ocf:heartbeat:IPaddr2
>> > primitive res_vipchk ocf:heartbeat:VIPcheck
>> > primitive res_diskd ocf:pacemaker:diskd
>> > group rg_test res_vipchk res_vip
>> > clone cl_diskd res_diskd
>> > clone cl_pingd res_pingd
>> > location l_test rg_test \
>> >     rule 200: #uname eq A-host.local \
>> >     rule 100: #uname eq B-host.local \
>> >     rule -inf: not_defined ping_chk or ping_chk lt 100 \
>> >     rule -inf: not_defined disk_chk or disk_chk eq ERROR
>> > =============================================================
>> >
>> >
>> > 基本的にはこれだけでも動作はすると思います。位置制約で設定した
>> > 値に従い、以下で起動してくれます
>> >
>> >  ①優先ActはA-host.localで起動
>> >  ②F/Oした場合、Failbackは基本的にはしない
>> >  ③Act側のPing、またはDisk監視が異常となった場合、F/Oする
>> >  ④両系ともPing、またはDisk監視が異常ならば一切リソースは
>> >   起動しない
>> >
>> > 事実上各Primitiveに指定された条件に従い正常にF/Oしますし、両系
>> > が異常ならリソースは両系ともにリソースは起動しませんので、これ
>> > だけでも条件は満たしているのかなと思います。
>> > この状況下において、同居制約、並びに順序制約は必要とする理由は
>> > あるのか疑問が浮かんできました
>> > 順序制約に関しては、Cloneリソースが起動しない内にGroupリソース
>> > が起動する懸念がありますが、起動速度からしてもさして問題にはな
>> > らないかなとも思います
>> >
>> >  ※そもそも論、Ping/Disk異常がある状態で起動させる事自体があり
>> >   得ないので、正常な構成状態であって初めて起動するので・・・
>> >
>> >
>> > 上記の事例においてはcolocation/orderが必要となりうる理由があり
>> > ましたら、ご指摘いただけると幸いです。
>> >
>> >
>> > 以上、よろしくお願いいたします。
>> >
>> >
>> > _______________________________________________
>> > Linux-ha-japan mailing list
>> > Linux-ha-japan@lists.osdn.me
>> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> >
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: 仮想IPだけがリソースの場合の同居・順序制約は必要か? [ In reply to ]
広瀬さん

こんばんは、山内です。

手元の環境ですが、早速、確認してみました。

失礼しました。
私の方のPM1.1確認時の、CLIファイルの設定ミスですね。

### Resource Location ###
location rsc_location-prmDummy-1 prmDummy \
        rule 200: #uname eq xxxx-01 \
        rule 100: #uname eq xxxx-02 \
        rule -inf: not_defined disk_chk or disk_chk eq ERROR

(↑-infが抜けていました。すいません。)


PM1.1、PM1.0共にdiskdのプロセス故障でもFOしますね。

pingd/diskdと単純なリソースの組み合わせであれば、locationルールでpingd/diskd故障検知のFOが実現出来るので、
colocationは不要だと思います。

orderルールは設定によっては、orderを組んだリソース故障によってrestartが実現出来ますが、これらの動作が不要であれば
起動が完了してからの監視という観点から言えば、不要かと思います。

以上です。



----- Original Message -----
> From: "renayama19661014@ybb.ne.jp" <renayama19661014@ybb.ne.jp>
> To: "linux-ha-japan@lists.osdn.me" <linux-ha-japan@lists.osdn.me>
> Cc:
> Date: 2015/11/10, Tue 23:05
> Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>
> 広瀬さん
>
> こんばんは、山内です。
>
>> 全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
>> 内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
>> にF/O発動はいたしました<改めて試験いたしました。
>> また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
>> を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
>
>
> すいません。
> 先ほどの回答ですが、私の方では、PM1.1系で確認していました。
>
> 再度、PM1.0系(PM+Heartbeat)でも明日、確認してみます。
> #記憶違いがなければ、同じ動作だと思うのですが。。。。
>
> diskdは、primitiveの他にdiskdプロセスが上がっているのでそちらをkillして、先ほどの回答は記載していました。
> 広瀬さんの方でも、同様の手順であれば、PM1.1の相違だと思います。
>
> また、明日にでも回答いたします。
>
> 以上です。
>
>
>
> ----- Original Message -----
>> From: "momoko@mail.t-momoko.org" <momoko@mail.t-momoko.org>
>> To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
>> Cc:
>> Date: 2015/11/10, Tue 22:53
>> Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>>
>> 広瀬です。
>>
>>
>> 山内さま、ご回答ありがとうございます。
>>
>> Ping/Disk監視プロセスが落ちた場合という事を頭に入れておらず、
>> Ping/Disk監視で、”異常”を検知した場合のみに固執していました。
>> ご指摘ありがとうございます。
>>
>> primitive res_diskd ocf:pacemaker:diskd \
>>         params name="disk_chk" write_dir="/tmp"
>> interval="10" \
>>         op start interval="0" timeout="60"
>> on-fail="restart" \
>>         op stop interval="0" timeout="60"
>> on-fail="block" \
>>         op monitor interval="10" timeout="60"
>> on-fail="restart" \
>>         meta migration-threshold="1"
>>
>> primitive res_pingd ocf:pacemaker:ping \
>>         params name="ping_chk" host_list="<IPアドレス>"
>> multiplier="100" dampen="10" \
>>         op start interval="0" timeout="60"
>> on-fail="restart" \
>>         op stop interval="0" timeout="20"
>> on-fail="block" \
>>         op monitor interval="10" timeout="60"
>> on-fail="restart" \
>>         meta migration-threshold="1"
>>
>> 全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
>> 内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
>> にF/O発動はいたしました<改めて試験いたしました。
>> また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
>> を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
>>
>>
>>  ※本設定ではシステム領域のDisk異常発生時を見ていますが、実はこれで
>>   はI/Oエラー発動させると正常には動作しません。別HDDのデータドライ
>>   ブや、共有ディスクであれば問題なく発動しますが・・・
>>
>>
>> このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも
>> ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように
>> 解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス
>> コア計算の概念にどう当てはまって行くのかが悩みどころです。
>>
>>
>> よろしくお願いいたします。
>>
>> renayama19661014@ybb.ne.jpさん:
>>>   広瀬さん
>>>
>>>   こんばんは、山内です。
>>>
>>>   例えば、
>>>
>>>    2ノードACT/STB構成で、primitiveリソースA(Dummy)とcloneリソース(diskd)
>>>
>>>   をcolocation無(通常、colcation リソースA with cloneリソースを省略)で配置した場合、
>>>
>>>   diskdのプロセスが落ちた場合にprimiverリソースAは、STBノードへファイルオーバーしなくなります。
>>>   #diskdの故障自体は、検知しますが。。。
>>>
>>>   これは、colocationがない為に、故障後のSTBノードへの配置計算にdiskdの故障が反映出来ない為です。
>>>
>>>   当然、diskdなどリソースの作りにもよる話ですが、colocationを組んでおいた方が良いと思います。
>>>
>>>   以上です。
>>>
>>>
>>>
>>>
>>>   ----- Original Message -----
>>>   > From: "momoko@mail.t-momoko.org"
>> <momoko@mail.t-momoko.org>
>>>   > To: Linux-ha-japan@lists.osdn.me
>>>   > Cc:
>>>   > Date: 2015/11/10, Tue 13:17
>>>   > Subject: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>>>   >
>>>   > 広瀬と申します
>>>   >
>>>   >
>>>   > Pacemaker+Heartbeatでの取り扱いになりますが、掲題の通りに
>>>   > リソースは純粋に仮想IPだけが主役となるノードがあったとします
>>>   >
>>>   >
>>>   > ■要約したリソース定義は以下(細かいパラメータは省きました)
>>>   > =============================================================
>>>   > primitive res_pingd ocf:pacemaker:ping
>>>   > primitive res_vip ocf:heartbeat:IPaddr2
>>>   > primitive res_vipchk ocf:heartbeat:VIPcheck
>>>   > primitive res_diskd ocf:pacemaker:diskd
>>>   > group rg_test res_vipchk res_vip
>>>   > clone cl_diskd res_diskd
>>>   > clone cl_pingd res_pingd
>>>   > location l_test rg_test \
>>>   >     rule 200: #uname eq A-host.local \
>>>   >     rule 100: #uname eq B-host.local \
>>>   >     rule -inf: not_defined ping_chk or ping_chk lt 100 \
>>>   >     rule -inf: not_defined disk_chk or disk_chk eq ERROR
>>>   > =============================================================
>>>   >
>>>   >
>>>   > 基本的にはこれだけでも動作はすると思います。位置制約で設定した
>>>   > 値に従い、以下で起動してくれます
>>>   >
>>>   >  ①優先ActはA-host.localで起動
>>>   >  ②F/Oした場合、Failbackは基本的にはしない
>>>   >  ③Act側のPing、またはDisk監視が異常となった場合、F/Oする
>>>   >  ④両系ともPing、またはDisk監視が異常ならば一切リソースは
>>>   >   起動しない
>>>   >
>>>   > 事実上各Primitiveに指定された条件に従い正常にF/Oしますし、両系
>>>   > が異常ならリソースは両系ともにリソースは起動しませんので、これ
>>>   > だけでも条件は満たしているのかなと思います。
>>>   > この状況下において、同居制約、並びに順序制約は必要とする理由は
>>>   > あるのか疑問が浮かんできました
>>>   > 順序制約に関しては、Cloneリソースが起動しない内にGroupリソース
>>>   > が起動する懸念がありますが、起動速度からしてもさして問題にはな
>>>   > らないかなとも思います
>>>   >
>>>   >  ※そもそも論、Ping/Disk異常がある状態で起動させる事自体があり
>>>   >   得ないので、正常な構成状態であって初めて起動するので・・・
>>>   >
>>>   >
>>>   > 上記の事例においてはcolocation/orderが必要となりうる理由があり
>>>   > ましたら、ご指摘いただけると幸いです。
>>>   >
>>>   >
>>>   > 以上、よろしくお願いいたします。
>>>   >
>>>   >
>>>   > _______________________________________________
>>>   > Linux-ha-japan mailing list
>>>   > Linux-ha-japan@lists.osdn.me
>>>   > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>   >
>>>
>>>   _______________________________________________
>>>   Linux-ha-japan mailing list
>>>   Linux-ha-japan@lists.osdn.me
>>>   http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: 仮想IPだけがリソースの場合の同居・順序制約は必要か? [ In reply to ]
広瀬です

山内さま、ご返答並びにわざわざの検証までして頂き、
ありがとうございます。
周りのHA環境が殆どPM+DRBD(MySQLなど)であるため、
colocation/orderの概念が必然的な感覚で捉えていた所
にあったのかもしれません。

3つある制約--今回の場合は同居と順序ですが--は
必ずしも必要である訳では無いという概念は分かって居
るつもりでしたが、あまり深く考えて作り込みをした事
がありませんでした。

orderに関して言えば、先に書いた通りですが起動時点の
何らかの問題によるリソース故障の回避という繋がりは
あり得るだろうと推察はしていましたので、運用面でどう
考えるかだけかと思いますので、検討したいと思います


この度はありがとうございました。

renayama19661014@ybb.ne.jpさん:
> 広瀬さん
>
> こんばんは、山内です。
>
> 手元の環境ですが、早速、確認してみました。
>
> 失礼しました。
> 私の方のPM1.1確認時の、CLIファイルの設定ミスですね。
>
> ### Resource Location ###
> location rsc_location-prmDummy-1 prmDummy \
>         rule 200: #uname eq xxxx-01 \
>         rule 100: #uname eq xxxx-02 \
>         rule -inf: not_defined disk_chk or disk_chk eq ERROR
>
> (↑-infが抜けていました。すいません。)
>
>
> PM1.1、PM1.0共にdiskdのプロセス故障でもFOしますね。
>
> pingd/diskdと単純なリソースの組み合わせであれば、locationルールでpingd/diskd故障検知のFOが実現出来
るので、
> colocationは不要だと思います。
>
> orderルールは設定によっては、orderを組んだリソース故障によってrestartが実現出来ますが、これらの動作
が不要であれば
> 起動が完了してからの監視という観点から言えば、不要かと思います。
>
> 以上です。
>
>
>
> ----- Original Message -----
> > From: "renayama19661014@ybb.ne.jp" <renayama19661014@ybb.ne.jp>
> > To: "linux-ha-japan@lists.osdn.me" <linux-ha-japan@lists.osdn.me>
> > Cc:
> > Date: 2015/11/10, Tue 23:05
> > Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
> >
> > 広瀬さん
> >
> > こんばんは、山内です。
> >
> >> 全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
> >> 内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
> >> にF/O発動はいたしました<改めて試験いたしました。
> >> また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
> >> を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
> >
> >
> > すいません。
> > 先ほどの回答ですが、私の方では、PM1.1系で確認していました。
> >
> > 再度、PM1.0系(PM+Heartbeat)でも明日、確認してみます。
> > #記憶違いがなければ、同じ動作だと思うのですが。。。。
> >
> > diskdは、primitiveの他にdiskdプロセスが上がっているのでそちらをkillして、先ほどの回答は記載してい
ました。
> > 広瀬さんの方でも、同様の手順であれば、PM1.1の相違だと思います。
> >
> > また、明日にでも回答いたします。
> >
> > 以上です。
> >
> >
> >
> > ----- Original Message -----
> >> From: "momoko@mail.t-momoko.org" <momoko@mail.t-momoko.org>
> >> To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
> >> Cc:
> >> Date: 2015/11/10, Tue 22:53
> >> Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
> >>
> >> 広瀬です。
> >>
> >>
> >> 山内さま、ご回答ありがとうございます。
> >>
> >> Ping/Disk監視プロセスが落ちた場合という事を頭に入れておらず、
> >> Ping/Disk監視で、”異常”を検知した場合のみに固執していました。
> >> ご指摘ありがとうございます。
> >>
> >> primitive res_diskd ocf:pacemaker:diskd \
> >>         params name="disk_chk" write_dir="/tmp"
> >> interval="10" \
> >>         op start interval="0" timeout="60"
> >> on-fail="restart" \
> >>         op stop interval="0" timeout="60"
> >> on-fail="block" \
> >>         op monitor interval="10" timeout="60"
> >> on-fail="restart" \
> >>         meta migration-threshold="1"
> >>
> >> primitive res_pingd ocf:pacemaker:ping \
> >>         params name="ping_chk" host_list="<IPアドレス>"
> >> multiplier="100" dampen="10" \
> >>         op start interval="0" timeout="60"
> >> on-fail="restart" \
> >>         op stop interval="0" timeout="20"
> >> on-fail="block" \
> >>         op monitor interval="10" timeout="60"
> >> on-fail="restart" \
> >>         meta migration-threshold="1"
> >>
> >> 全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
> >> 内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
> >> にF/O発動はいたしました<改めて試験いたしました。
> >> また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
> >> を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
> >>
> >>
> >>  ※本設定ではシステム領域のDisk異常発生時を見ていますが、実はこれで
> >>   はI/Oエラー発動させると正常には動作しません。別HDDのデータドライ
> >>   ブや、共有ディスクであれば問題なく発動しますが・・・
> >>
> >>
> >> このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも
> >> ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように
> >> 解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス
> >> コア計算の概念にどう当てはまって行くのかが悩みどころです。
> >>
> >>
> >> よろしくお願いいたします。
> >>
> >> renayama19661014@ybb.ne.jpさん:
> >>>   広瀬さん
> >>>
> >>>   こんばんは、山内です。
> >>>
> >>>   例えば、
> >>>
> >>>    2ノードACT/STB構成で、primitiveリソースA(Dummy)とcloneリソース(diskd)
> >>>
> >>>   をcolocation無(通常、colcation リソースA with cloneリソースを省略)で配置した場合、
> >>>
> >>>   diskdのプロセスが落ちた場合にprimiverリソースAは、STBノードへファイルオーバーしなくなります。
> >>>   #diskdの故障自体は、検知しますが。。。
> >>>
> >>>   これは、colocationがない為に、故障後のSTBノードへの配置計算にdiskdの故障が反映出来ない為です。
> >>>
> >>>   当然、diskdなどリソースの作りにもよる話ですが、colocationを組んでおいた方が良いと思います。
> >>>
> >>>   以上です。
> >>>
> >>>
> >>>
> >>>
> >>>   ----- Original Message -----
> >>>   > From: "momoko@mail.t-momoko.org"
> >> <momoko@mail.t-momoko.org>
> >>>   > To: Linux-ha-japan@lists.osdn.me
> >>>   > Cc:
> >>>   > Date: 2015/11/10, Tue 13:17
> >>>   > Subject: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
> >>>   >
> >>>   > 広瀬と申します
> >>>   >
> >>>   >
> >>>   > Pacemaker+Heartbeatでの取り扱いになりますが、掲題の通りに
> >>>   > リソースは純粋に仮想IPだけが主役となるノードがあったとします
> >>>   >
> >>>   >
> >>>   > ■要約したリソース定義は以下(細かいパラメータは省きました)
> >>>   > =============================================================
> >>>   > primitive res_pingd ocf:pacemaker:ping
> >>>   > primitive res_vip ocf:heartbeat:IPaddr2
> >>>   > primitive res_vipchk ocf:heartbeat:VIPcheck
> >>>   > primitive res_diskd ocf:pacemaker:diskd
> >>>   > group rg_test res_vipchk res_vip
> >>>   > clone cl_diskd res_diskd
> >>>   > clone cl_pingd res_pingd
> >>>   > location l_test rg_test \
> >>>   >     rule 200: #uname eq A-host.local \
> >>>   >     rule 100: #uname eq B-host.local \
> >>>   >     rule -inf: not_defined ping_chk or ping_chk lt 100 \
> >>>   >     rule -inf: not_defined disk_chk or disk_chk eq ERROR
> >>>   > =============================================================
> >>>   >
> >>>   >
> >>>   > 基本的にはこれだけでも動作はすると思います。位置制約で設定した
> >>>   > 値に従い、以下で起動してくれます
> >>>   >
> >>>   >  ①優先ActはA-host.localで起動
> >>>   >  ②F/Oした場合、Failbackは基本的にはしない
> >>>   >  ③Act側のPing、またはDisk監視が異常となった場合、F/Oする
> >>>   >  ④両系ともPing、またはDisk監視が異常ならば一切リソースは
> >>>   >   起動しない
> >>>   >
> >>>   > 事実上各Primitiveに指定された条件に従い正常にF/Oしますし、両系
> >>>   > が異常ならリソースは両系ともにリソースは起動しませんので、これ
> >>>   > だけでも条件は満たしているのかなと思います。
> >>>   > この状況下において、同居制約、並びに順序制約は必要とする理由は
> >>>   > あるのか疑問が浮かんできました
> >>>   > 順序制約に関しては、Cloneリソースが起動しない内にGroupリソース
> >>>   > が起動する懸念がありますが、起動速度からしてもさして問題にはな
> >>>   > らないかなとも思います
> >>>   >
> >>>   >  ※そもそも論、Ping/Disk異常がある状態で起動させる事自体があり
> >>>   >   得ないので、正常な構成状態であって初めて起動するので・・・
> >>>   >
> >>>   >
> >>>   > 上記の事例においてはcolocation/orderが必要となりうる理由があり
> >>>   > ましたら、ご指摘いただけると幸いです。
> >>>   >
> >>>   >
> >>>   > 以上、よろしくお願いいたします。
> >>>   >
> >>>   >
> >>>   > _______________________________________________
> >>>   > Linux-ha-japan mailing list
> >>>   > Linux-ha-japan@lists.osdn.me
> >>>   > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >>>   >
> >>>
> >>>   _______________________________________________
> >>>   Linux-ha-japan mailing list
> >>>   Linux-ha-japan@lists.osdn.me
> >>>   http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >>
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan@lists.osdn.me
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: 仮想IPだけがリソースの場合の同居・順序制約は必要か? [ In reply to ]
広瀬さん

おはようございます。山内です。

色々とPacemakerも難解な部分もあるかと思いますが。。。頑張って構築してみてください。

補足ですが、Pacemaker1.0系(Heartbeat+Pacemaker)は、既に開発がほぼ終わっています。
今後、バグなどの対応もあまり期待出来ない部分がありますし、新しい機能も盛り込まれる予定はありません。

可能でありましたら、是非、Paemaker1.1系(corosync+Pacemaker)での環境の方もご検討ください。

また、何かありましたら、MLにご相談ください。

以上です。


----- Original Message -----
> From: "momoko@mail.t-momoko.org" <momoko@mail.t-momoko.org>
> To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
> Cc:
> Date: 2015/11/11, Wed 02:00
> Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>
> 広瀬です
>
> 山内さま、ご返答並びにわざわざの検証までして頂き、
> ありがとうございます。
> 周りのHA環境が殆どPM+DRBD(MySQLなど)であるため、
> colocation/orderの概念が必然的な感覚で捉えていた所
> にあったのかもしれません。
>
> 3つある制約--今回の場合は同居と順序ですが--は
> 必ずしも必要である訳では無いという概念は分かって居
> るつもりでしたが、あまり深く考えて作り込みをした事
> がありませんでした。
>
> orderに関して言えば、先に書いた通りですが起動時点の
> 何らかの問題によるリソース故障の回避という繋がりは
> あり得るだろうと推察はしていましたので、運用面でどう
> 考えるかだけかと思いますので、検討したいと思います
>
>
> この度はありがとうございました。
>
> renayama19661014@ybb.ne.jpさん:
>> 広瀬さん
>>
>> こんばんは、山内です。
>>
>> 手元の環境ですが、早速、確認してみました。
>>
>> 失礼しました。
>> 私の方のPM1.1確認時の、CLIファイルの設定ミスですね。
>>
>> ### Resource Location ###
>> location rsc_location-prmDummy-1 prmDummy \
>>         rule 200: #uname eq xxxx-01 \
>>         rule 100: #uname eq xxxx-02 \
>>         rule -inf: not_defined disk_chk or disk_chk eq ERROR
>>
>> (↑-infが抜けていました。すいません。)
>>
>>
>> PM1.1、PM1.0共にdiskdのプロセス故障でもFOしますね。
>>
>> pingd/diskdと単純なリソースの組み合わせであれば、locationルールでpingd/diskd故障検知のFOが実現出来
> るので、
>> colocationは不要だと思います。
>>
>> orderルールは設定によっては、orderを組んだリソース故障によってrestartが実現出来ますが、これらの動作
> が不要であれば
>> 起動が完了してからの監視という観点から言えば、不要かと思います。
>>
>> 以上です。
>>
>>
>>
>> ----- Original Message -----
>> > From: "renayama19661014@ybb.ne.jp"
> <renayama19661014@ybb.ne.jp>
>> > To: "linux-ha-japan@lists.osdn.me"
> <linux-ha-japan@lists.osdn.me>
>> > Cc:
>> > Date: 2015/11/10, Tue 23:05
>> > Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>> >
>> > 広瀬さん
>> >
>> > こんばんは、山内です。
>> >
>> >>  全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
>> >>  内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
>> >>  にF/O発動はいたしました<改めて試験いたしました。
>> >>  また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
>> >>  を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
>> >
>> >
>> > すいません。
>> > 先ほどの回答ですが、私の方では、PM1.1系で確認していました。
>> >
>> > 再度、PM1.0系(PM+Heartbeat)でも明日、確認してみます。
>> > #記憶違いがなければ、同じ動作だと思うのですが。。。。
>> >
>> > diskdは、primitiveの他にdiskdプロセスが上がっているのでそちらをkillして、先ほどの回答は記載してい
> ました。
>> > 広瀬さんの方でも、同様の手順であれば、PM1.1の相違だと思います。
>> >
>> > また、明日にでも回答いたします。
>> >
>> > 以上です。
>> >
>> >
>> >
>> > ----- Original Message -----
>> >>  From: "momoko@mail.t-momoko.org"
> <momoko@mail.t-momoko.org>
>> >>  To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
>> >>  Cc:
>> >>  Date: 2015/11/10, Tue 22:53
>> >>  Subject: Re: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>> >>
>> >>  広瀬です。
>> >>
>> >>
>> >>  山内さま、ご回答ありがとうございます。
>> >>
>> >>  Ping/Disk監視プロセスが落ちた場合という事を頭に入れておらず、
>> >>  Ping/Disk監視で、”異常”を検知した場合のみに固執していました。
>> >>  ご指摘ありがとうございます。
>> >>
>> >>  primitive res_diskd ocf:pacemaker:diskd \
>> >>          params name="disk_chk"
> write_dir="/tmp"
>> >>  interval="10" \
>> >>          op start interval="0" timeout="60"
>> >>  on-fail="restart" \
>> >>          op stop interval="0" timeout="60"
>> >>  on-fail="block" \
>> >>          op monitor interval="10" timeout="60"
>
>> >>  on-fail="restart" \
>> >>          meta migration-threshold="1"
>> >>
>> >>  primitive res_pingd ocf:pacemaker:ping \
>> >>          params name="ping_chk"
> host_list="<IPアドレス>"
>> >>  multiplier="100" dampen="10" \
>> >>          op start interval="0" timeout="60"
>> >>  on-fail="restart" \
>> >>          op stop interval="0" timeout="20"
>> >>  on-fail="block" \
>> >>          op monitor interval="10" timeout="60"
>
>> >>  on-fail="restart" \
>> >>          meta migration-threshold="1"
>> >>
>> >>  全体コンフィグは改めて添付いたしました通りですが、Ping/Diskdリソース
>> >>  内容は上記の通りであり、colocation無くともDiskdプロセス停止時は正常
>> >>  にF/O発動はいたしました<改めて試験いたしました。
>> >>  また、Pingリソースも名称の違いはあれど、同じ条件ですのでPingリソース
>> >>  を停止した場合、またICMPを遮断してもF/Oする事も確認しました。
>> >>
>> >>
>> >>   ※本設定ではシステム領域のDisk異常発生時を見ていますが、実はこれで
>> >>    はI/Oエラー発動させると正常には動作しません。別HDDのデータドライ
>> >>    ブや、共有ディスクであれば問題なく発動しますが・・・
>> >>
>> >>
>> >>  このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも
>> >>  ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように
>> >>  解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス
>> >>  コア計算の概念にどう当てはまって行くのかが悩みどころです。
>> >>
>> >>
>> >>  よろしくお願いいたします。
>> >>
>> >>  renayama19661014@ybb.ne.jpさん:
>> >>>   広瀬さん
>> >>>
>> >>>   こんばんは、山内です。
>> >>>
>> >>>   例えば、
>> >>>
>> >>>    2ノードACT/STB構成で、primitiveリソースA(Dummy)とcloneリソース(diskd)
>> >>>
>> >>>   をcolocation無(通常、colcation リソースA with cloneリソースを省略)で配置した場合、
>> >>>
>> >>>   diskdのプロセスが落ちた場合にprimiverリソースAは、STBノードへファイルオーバーしなくなります。
>> >>>   #diskdの故障自体は、検知しますが。。。
>> >>>
>> >>>   これは、colocationがない為に、故障後のSTBノードへの配置計算にdiskdの故障が反映出来ない為です。
>> >>>
>> >>>   当然、diskdなどリソースの作りにもよる話ですが、colocationを組んでおいた方が良いと思います。
>> >>>
>> >>>   以上です。
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>   ----- Original Message -----
>> >>>   > From: "momoko@mail.t-momoko.org"
>> >>  <momoko@mail.t-momoko.org>
>> >>>   > To: Linux-ha-japan@lists.osdn.me
>> >>>   > Cc:
>> >>>   > Date: 2015/11/10, Tue 13:17
>> >>>   > Subject: [Linux-ha-jp] 仮想IPだけがリソースの場合の同居・順序制約は必要か?
>> >>>   >
>> >>>   > 広瀬と申します
>> >>>   >
>> >>>   >
>> >>>   > Pacemaker+Heartbeatでの取り扱いになりますが、掲題の通りに
>> >>>   > リソースは純粋に仮想IPだけが主役となるノードがあったとします
>> >>>   >
>> >>>   >
>> >>>   > ■要約したリソース定義は以下(細かいパラメータは省きました)
>> >>>   >
> =============================================================
>> >>>   > primitive res_pingd ocf:pacemaker:ping
>> >>>   > primitive res_vip ocf:heartbeat:IPaddr2
>> >>>   > primitive res_vipchk ocf:heartbeat:VIPcheck
>> >>>   > primitive res_diskd ocf:pacemaker:diskd
>> >>>   > group rg_test res_vipchk res_vip
>> >>>   > clone cl_diskd res_diskd
>> >>>   > clone cl_pingd res_pingd
>> >>>   > location l_test rg_test \
>> >>>   >     rule 200: #uname eq A-host.local \
>> >>>   >     rule 100: #uname eq B-host.local \
>> >>>   >     rule -inf: not_defined ping_chk or ping_chk lt 100
> \
>> >>>   >     rule -inf: not_defined disk_chk or disk_chk eq
> ERROR
>> >>>   >
> =============================================================
>> >>>   >
>> >>>   >
>> >>>   > 基本的にはこれだけでも動作はすると思います。位置制約で設定した
>> >>>   > 値に従い、以下で起動してくれます
>> >>>   >
>> >>>   >  ①優先ActはA-host.localで起動
>> >>>   >  ②F/Oした場合、Failbackは基本的にはしない
>> >>>   >  ③Act側のPing、またはDisk監視が異常となった場合、F/Oする
>> >>>   >  ④両系ともPing、またはDisk監視が異常ならば一切リソースは
>> >>>   >   起動しない
>> >>>   >
>> >>>   > 事実上各Primitiveに指定された条件に従い正常にF/Oしますし、両系
>> >>>   > が異常ならリソースは両系ともにリソースは起動しませんので、これ
>> >>>   > だけでも条件は満たしているのかなと思います。
>> >>>   > この状況下において、同居制約、並びに順序制約は必要とする理由は
>> >>>   > あるのか疑問が浮かんできました
>> >>>   > 順序制約に関しては、Cloneリソースが起動しない内にGroupリソース
>> >>>   > が起動する懸念がありますが、起動速度からしてもさして問題にはな
>> >>>   > らないかなとも思います
>> >>>   >
>> >>>   >  ※そもそも論、Ping/Disk異常がある状態で起動させる事自体があり
>> >>>   >   得ないので、正常な構成状態であって初めて起動するので・・・
>> >>>   >
>> >>>   >
>> >>>   > 上記の事例においてはcolocation/orderが必要となりうる理由があり
>> >>>   > ましたら、ご指摘いただけると幸いです。
>> >>>   >
>> >>>   >
>> >>>   > 以上、よろしくお願いいたします。
>> >>>   >
>> >>>   >
>> >>>   > _______________________________________________
>> >>>   > Linux-ha-japan mailing list
>> >>>   > Linux-ha-japan@lists.osdn.me
>> >>>   > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> >>>   >
>> >>>
>> >>>   _______________________________________________
>> >>>   Linux-ha-japan mailing list
>> >>>   Linux-ha-japan@lists.osdn.me
>> >>>   http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> >>
>> >
>> > _______________________________________________
>> > Linux-ha-japan mailing list
>> > Linux-ha-japan@lists.osdn.me
>> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> >
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan