momok****@mail*****
momok****@mail*****
2015年 11月 10日 (火) 22:53:23 JST
Fork広瀬です。
山内さま、ご回答ありがとうございます。
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のデータドライ
ブや、共有ディスクであれば問題なく発動しますが・・・
このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも
ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように
解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス
コア計算の概念にどう当てはまって行くのかが悩みどころです。
よろしくお願いいたします。
renay****@ybb*****さん：
> 広瀬さん
>
> こんばんは、山内です。
>
> 例えば、
>
> 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: "momok****@mail*****" <momok****@mail*****>
> > To: Linux****@lists*****
> > 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****@lists*****
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux****@lists*****
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
-------------- next part --------------
$B%F%-%9%H7A<00J30$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
$B%U%!%$%kL>(B: pm.conf
$B7?(B: application/octet-stream
$B%5%$%:(B: 1852 $B%P%$%H(B
$B ＠ bL@(B: $BL5$7(B
ダウンロード