renay****@ybb*****
renay****@ybb*****
2015年 11月 10日 (火) 23:37:45 JST
広瀬さん こんばんは、山内です。 手元の環境ですが、早速、確認してみました。 失礼しました。 私の方の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: "renay****@ybb*****" <renay****@ybb*****> > To: "linux****@lists*****" <linux****@lists*****> > 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: "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 >> > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.osdn.me/mailman/listinfo/linux-ha-japan >
Fork