renay****@ybb*****
renay****@ybb*****
2015年 11月 10日 (火) 23:05:30 JST
広瀬さん こんばんは、山内です。 > 全体コンフィグは改めて添付いたしました通りですが、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: "momok****@mail*****" <momok****@mail*****> > To: renay****@ybb*****; linux****@lists***** > 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のデータドライ > ブや、共有ディスクであれば問題なく発動しますが・・・ > > > このような条件下であった場合、色々エラー起こして見る限りでは、必ずしも > ある必要性を見いだせず、同居(配置)、順序制約とも要否に関してどのように > 解釈すれば良いのかと迷う部分があります。一番気になるのはやはり内部のス > コア計算の概念にどう当てはまって行くのかが悩みどころです。 > > > よろしくお願いいたします。 > > 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 >
Fork