momok****@mail*****
momok****@mail*****
2015年 11月 11日 (水) 02:00:57 JST
広瀬です 山内さま、ご返答並びにわざわざの検証までして頂き、 ありがとうございます。 周りのHA環境が殆どPM+DRBD(MySQLなど)であるため、 colocation/orderの概念が必然的な感覚で捉えていた所 にあったのかもしれません。 ３つある制約－－今回の場合は同居と順序ですが－－は 必ずしも必要である訳では無いという概念は分かって居 るつもりでしたが、あまり深く考えて作り込みをした事 がありませんでした。 orderに関して言えば、先に書いた通りですが起動時点の 何らかの問題によるリソース故障の回避という繋がりは あり得るだろうと推察はしていましたので、運用面でどう 考えるかだけかと思いますので、検討したいと思います この度はありがとうございました。 renay****@ybb*****さん： > 広瀬さん > > こんばんは、山内です。 > > 手元の環境ですが、早速、確認してみました。 > > 失礼しました。 > 私の方の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 > > > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Fork