kazuh****@goo*****
kazuh****@goo*****
2016年 2月 1日 (月) 09:18:20 JST
広瀬様 ひがしです。お世話になります。 期待通り動作したとのことで、よかったです。 orderを含め、制約のスコアは、私も動かしてみないとわからない というところで、理解しきっているわけではないですよ・・ （そのため、回答に少し時間をいただきました） 特にスコア絡みの動作はエラーが出るわけでもなく、 なかなか気づきにくいですよね。 取り急ぎ以上です。 よろしくお願いいたします。 ----- 元のメッセージ ----- From: momok****@mail***** 宛先: linux****@lists***** 送信済み: 2016年1月30日, 土曜日 午前 8:41:16 件名: Re: [Linux-ha-jp] スタンバイ側を切り離すとDRBDがFailを起こしてしまう ひがしさま 広瀬です。お忙しい中ご確認と的確なご助言をいただき大変助かりました。 ご説明頂いた通り、Act側のDRBDが先にdemote処理に陥ってしまう挙動と、 そのタイムアウトが起因で最終的な崩壊につながっていたことは読めては おりましたが、その先がどこに関連するかで理解不足であり、orderの記述 にまで頭が回っておりませんでした。 ※どちらかと言えば、colocationの定義に腐心していました order odr_app-01 0: cl_diskd_db ms_drbd_app symmetrical=false order odr_app-02 0: cl_diskd_os ms_drbd_app symmetrical=false order odr_app-03 0: cl_pingd_ope ms_drbd_app symmetrical=false order odr_app-04 inf: ms_drbd_app:promote rg_mysqld rg_app:start ご提示いただいた内容に従い設定を追加し、動作確認しましたところ、 rg_mysqld、rg_appの片系に寄せてから、Standbyの停止が正常に行え ました。 また、寄せずにHA停止、またはHeartbeat Masterプロセス強制Killなど 考えられる障害パターンも確認し期待どおりとなりました。 symmetricalパラメータの意味合いは至極わかりやすいものですが、そ のあたりへの理解というか、関連性に気づかない点はまだまだ勉強が 足りてないなぁと思う次第です＜スコア概念はさらにボロクソ この度はご丁寧なご説明と解説、および解法のご提示いただき大変助か りました(実は来週には正式稼働予定で困っていたところでした)。 以上です。 kazuh****@goo*****さん： > 広瀬様 > > ひがしです。お世話になります。 > > いただいたha-logより、1系のshutdown実行直後の状態遷移計算で、 > 特にエラーは発生していないのに、2系側のDRBD（res_drbd_app:0）が > 再起動(Restart)されるようPacemakerによって判断されています。 > > Jan 26 21:53:39 appwd02p pengine: [22849]: info: stage6: Scheduling Node appwd01p.local for shutdown > Jan 26 21:53:39 appwd02p.local pengine: [22849]: notice: LogActions: Restart resource res_drbd_ app:0 (Master appwd02p.local) > > その状態遷移計算結果にのっとり、Pacemakerは2系側のDRBDを > demote→stop→start→promoteしようとしましたが、demoteは、 > DRBDデバイスを誰か(おそらくmysql)が使用中のため失敗し、 > タイムアウトしています。 > > Jan 26 21:53:40 appwd02p lrmd: [22835]: info: rsc:res_drbd_app:0 demote[71] (pid 30997) > Jan 26 21:53:40 appwd02p lrmd: [22835]: info: RA output: (res_drbd_app:0:demote:stderr) 0: State change failed: (-12) Device is held open by someone > Jan 26 21:53:40 appwd02p lrmd: [22835]: info: RA output: (res_drbd_app:0:demote:stderr) Command 'drbdsetup-84 secondary 0' terminated with exit code 11 > ・・・demoteを繰り返し試みるが失敗し続ける・・ > Jan 26 21:54:00 appwd02p lrmd: [22835]: WARN: res_drbd_app:0:demote process (PID 30997) timed out (try 1). Killing with signal SIGTERM (15). > > > demoteの失敗(タイムアウト)により故障フラグが立ったため > PacemakerはDRBDの停止を試みます。しかし、これもdemote時と > 同様の理由で失敗(タイムアウト)しています。 > > Jan 26 21:54:01 appwd02p pengine: [22849]: WARN: unpack_rsc_op: Forcing res_drbd_app:0 to stop after a failed demote action > Jan 26 21:54:01 appwd02p lrmd: [22835]: info: rsc:res_drbd_app:0 stop[76] (pid 31995) > Jan 26 21:54:02 appwd02p lrmd: [22835]: info: RA output: (res_drbd_app:0:stop:stderr) 0: State change failed: (-12) Device is held open by someone > Jan 26 21:54:02 appwd02p lrmd: [22835]: info: RA output: (res_drbd_app:0:stop:stderr) Command ' drbdsetup-84 secondary 0' terminated with exit code 11 > ・・・stopを繰り返し試みるが失敗し続ける・・ > Jan 26 21:56:01 appwd02p lrmd: [22835]: WARN: res_drbd_app:0:stop process (PID 31995) timed out (try 1). Killing with signal SIGTERM (15). > > > さて、では、なぜ、 > 「特にエラーは発生していないのに、2系側のDRBD（res_drbd_app:0）が > 再起動されるようPacemakerに判断された」 > か、ですが、これは、おそらく、クローンリソースとDRBDリソースの > order設定がinfで設定されていることと、「symmetrical」がtrue(デフォルト) > になっていることが原因のようです。 > > おそらく、1系のshutdownに伴う1系のクローンリソースの停止で、 > このorder制約が働き、両系のDRBDを(一旦)停止しようとしたと > 思われます。 > > 以下、「order回避案」のようにorder制約のスコアを0にし、 > 「symmetrical=false」を設定してみてください。 > > ---- order変更前 ---- > order odr_app-01 inf: cl_diskd_db ms_drbd_app > order odr_app-02 inf: cl_diskd_os ms_drbd_app > order odr_app-03 inf: cl_pingd_ope ms_drbd_app > --------------------- > ↓以下の通り変更してみてください。 > ---- order回避案 ---- > order odr_app-01 0: cl_diskd_db ms_drbd_app symmetrical=false > order odr_app-02 0: cl_diskd_os ms_drbd_app symmetrical=false > order odr_app-03 0: cl_pingd_ope ms_drbd_app symmetrical=false > --------------------- > > > ＃外していたらごめんなさい。 > > ＃なお、Pacemaker1.1系では、上記orderでも、1系のクローン停止に > 2系のDRBDが道連れになる、ということは無いようです。 > 制約の仕様がPacemaker1.0と1.1で微妙に変わっているようですね・・ > > > 以上です。 > よろしくお願いいたします。 > > ----- 元のメッセージ ----- > From: momok****@mail***** > 宛先: linux****@lists***** > 送信済み: 2016年1月26日, 火曜日 午後 10:30:08 > 件名: Re: [Linux-ha-jp] スタンバイ側を切り離すとDRBDがFailを起こしてしまう > > ひがしさま > > > お世話になっております、広瀬です。 > 添付としますが、ご指示通りにha-logとmessagesのログをそれぞれ > 取得いたしました。解決の糸口があればよいのですが・・・ > > 尚、このログ出力前におこなったことですが、以下の通りです。 > > > ◆正常状態 > �1号機側で、rg_appグループが起動中 > > �2号機側で、rg_mysqldグループが起動中 > > > ◆マイグレーション > > �上記、正常状態から1号機で稼働していたrg_appグループを、2号機 > にmigrateコマンドで移動＜unmigrateは行わず > > �正常に移動したことを確認 > > > ⇒この状態から、ログの吐き出しが落ち着いたタイミングで、ログ > リネームして、以降の新規ログを今回ご提示させて頂きました。 > > ⇒上記のログは2号機側のみとなります＜1号機側も必要な場合はご提示可能です > > > ◆完全にスタンバイと化した1号機の停止 > > �heartbeat停止を実施 > > ⇒2号機側でcrm_mon -fAを実行しますが、すぐにDRBDのdemote処理で > エラーを吐き出した模様＜なお、発生したのは何故か2号機側のDRBD > リソース＜1号機のリソースでは無い > > �時間は係るものの、1号機のHAは最終的には停止します > > > ⇒ログは概ね1号機側が停止し、ログが落ち着いた当たりまでです > > > 以上となります。よろしくお願いいたします。 > > ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ > 追伸 > > 上記対応直後のcrm_mon -fA結果は以下となります > > Online: [ appwd02p.local ] > OFFLINE: [ appwd01p.local ] > > Resource Group: rg_app > res_vip_chk_app (ocf::heartbeat:VIPcheck): Started appwd02p.local > res_vip_app (ocf::heartbeat:IPaddr2): Started appwd02p.local > res_app_svr (ocf::heartbeat:appserver): Started appwd02p.local > res_app_jgw (lsb:javagateway): Started appwd02p.local > res_MailTo_app (ocf::heartbeat:MailTo): Started appwd02p.local > Master/Slave Set: ms_drbd_app > res_drbd_app:0 (ocf::linbit:drbd): Slave appwd02p.local (unmanaged) FAILED > Stopped: [ res_drbd_app:1 ] > Clone Set: cl_diskd_db > Started: [ appwd02p.local ] > Stopped: [ res_diskd_db:1 ] > Clone Set: cl_diskd_os > Started: [ appwd02p.local ] > Stopped: [ res_diskd_os:1 ] > Clone Set: cl_pingd_ope > Started: [ appwd02p.local ] > Stopped: [ res_pingd_ope:1 ] > > Node Attributes: > * Node appwd02p.local: > + disk_chk_db : normal > + disk_chk_os : normal > + master-res_drbd_app:0 : 10000 > + ope_l3sw_chk : 100 > > Migration summary: > * Node appwd02p.local: > res_drbd_app:0: migration-threshold=1 fail-count=1000000 > > Failed actions: > res_drbd_app:0_demote_0 (node=appwd02p.local, call=71, rc=-2, status=Timed Out): unknown exec > error > res_drbd_app:0_stop_0 (node=appwd02p.local, call=76, rc=-2, status=Timed Out): unknown exec e > rror > ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ > > > > > > kazuh****@goo*****さん： > > 広瀬様 > > > > ひがしと申します。お世話になります。 > > > > > しかしながら、どちらかひとつのサーバに２グループ全部寄せたあと、完全にスタ > > > ンバイ機と化したサーバ側のHeartbeatを停止すると、DRBDがコケてしまい結果的 > > > にMySQLが死亡することになるので、HAが崩壊します > > 私がDRBDにあまり明るくないせいもあり、設定を見ただけでは > > ちょっと原因がわかりませんでした。 > > > > 「DRBDがコケる」とあるので、何らかのエラーが絡んでいるの > > ではないかと思います。 > > > > 解析のため、当該事象発生時のPacemakerのログ(ha-logまたは/var/log/messages)と > > OSログ(/var/log/messages)をいただけないでしょうか。 > > > > > > 以上です。 > > よろしくお願いいたします。 > > > > ----- 元のメッセージ ----- > > From: momok****@mail***** > > 宛先: linux****@lists***** > > 送信済み: 2016年1月26日, 火曜日 午前 1:33:45 > > 件名: [Linux-ha-jp] スタンバイ側を切り離すとDRBDがFailを起こしてしまう > > > > 広瀬と申します > > > > > > ★環境 > > CentOS6.7 x86_64 > > Pacemaker(1.0.13-2.el6.x86_64) > > Heartbeat(3.0.5-1.1.el6.x86_64) > > > > > > 上記環境において、1号機側ではアプリケーションA、2号機側ではMySQL＋DRBDを > > Activeとした、配置制約違いの両系Act/Act構成をとりました(コンフィグは最後 > > に張り付けます) > > > > > > 具体的にはrg_mysqldグループは2号機で起動させ、rg_applicationグループは1号 > > 機で起動させ、どちらかが故障、停止した場合は生き残っているサーバ側に寄る > > ように構成しました(HA起動時の優先起動順として) > > 構成としては、公開されているLinuxHA-JPの過去のOSCの公開資料にある東さまの > > 「雷」パターンに近いと考えていただければと思います。 > > > > ※「CRM-CLIでHAクラスタを自在に制御しよう！」参考 > > > > ただし、上記資料の場合はグループ化はせず、単一リソースをバラバラに起動させ > > たい場合、且つDRBDは存在しない前提のため、MSリソースを絡めた各種の制約条件 > > 定義は独自の解釈に基づいたものとなります。 > > > > > > ★グループ定義 > > group rg_mysqld res_vip_chk_db res_vip_db res_fs_db res_mysql_app res_MailTo_db > > group rg_app res_vip_chk_app res_vip_app res_app_svr res_app_jgw res_MailTo_app > > > > > > ★配置制約定義 > > location loc_app rg_app \ > > rule $id="l_app-01" $role="master" 200: #uname eq appwd01p.local \ > > rule $id="l_app-02" $role="master" 100: #uname eq appwd02p.local \ > > > > > > location loc_mysql ms_drbd_app \ > > rule $id="l_sql-01" $role="master" 200: #uname eq appwd02p.local \ > > rule $id="l_sql-02" $role="master" 100: #uname eq appwd01p.local \ > > > > > > 基本的な、location、colocation、orderの制約に関しては期待通りの起動、並びに > > マイグレーション動作をします > > しかしながら、どちらかひとつのサーバに２グループ全部寄せたあと、完全にスタ > > ンバイ機と化したサーバ側のHeartbeatを停止すると、DRBDがコケてしまい結果的 > > にMySQLが死亡することになるので、HAが崩壊します > > > > > > 起因はDRBDの状態にあるとみているので、MSリソースの同居制約、配置になんらか > > の問題があるとみています(Diskdも関係するか・・・) > > 私としても難易度の高い構成にしたなぁと少し後悔気味ですが、MySQLを主軸とする > > グループと、Javaを主軸とするアプリケーショングループのメモリの利用率がとも > > に高いので、分離させた次第です(まぁ、あとスタンバイ機が遊んでいるともったい > > ないので) > > > > > > 簡便なご質問内容で大変申し訳ございませんが、本件何かご指摘いただける部分が > > 御座いましたら、ご返答いただけると助かります > > > > > > 以上、よろしくお願いいたします > > > > ★以下パラメータ(primitiveの詳細はおそらく関係が無いので省いてます) > > ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ > > primitive res_MailTo_db ocf:heartbeat:MailTo \ > > primitive res_MailTo_app ocf:heartbeat:MailTo \ > > primitive res_diskd_db ocf:pacemaker:diskd \ > > primitive res_diskd_os ocf:pacemaker:diskd \ > > primitive res_drbd_app ocf:linbit:drbd \ > > primitive res_fs_db ocf:heartbeat:Filesystem \ > > primitive res_mysql_app ocf:heartbeat:mysql \ > > primitive res_pingd_ope ocf:pacemaker:pingd \ > > primitive res_vip_chk_db ocf:heartbeat:VIPcheck \ > > primitive res_vip_chk_app ocf:heartbeat:VIPcheck \ > > primitive res_vip_db ocf:heartbeat:IPaddr2 \ > > primitive res_vip_app ocf:heartbeat:IPaddr2 \ > > primitive res_app_jgw lsb:java_application \ > > primitive res_app_svr ocf:heartbeat:application \ > > > > group rg_mysqld res_vip_chk_db res_vip_db res_fs_db res_mysql_app res_MailTo_db > > group rg_app res_vip_chk_app res_vip_app res_app_svr res_app_jgw res_MailTo_app > > > > ms ms_drbd_app res_drbd_app \ > > meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" > > > > clone cl_diskd_db res_diskd_db \ > > meta clone-max="2" clone-node-max="1" > > clone cl_diskd_os res_diskd_os \ > > meta clone-max="2" clone-node-max="1" > > clone cl_pingd_ope res_pingd_ope \ > > meta clone-max="2" clone-node-max="1" > > > > location loc_mysql ms_drbd_app \ > > rule $id="l_sql-01" $role="master" 200: #uname eq appwd02p.local \ > > rule $id="l_sql-02" $role="master" 100: #uname eq appwd01p.local \ > > rule $id="l_sql-03" $role="master" -inf: defined ope_l3sw_chk and ope_l3sw_chk lt 100 \ > > rule $id="l_sql-04" -inf: defined os_disk_chk and os_disk_chk eq ERROR \ > > rule $id="l_sql-05" -inf: defined db_disk_chk and db_disk_chk eq ERROR > > location loc_apprg_app \ > > rule $id="l_app-01" $role="master" 200: #uname eq appwd01p.local \ > > rule $id="l_app-02" $role="master" 100: #uname eq appwd02p.local \ > > rule $id="l_app-03" $role="master" -inf: defined ope_l3sw_chk and ope_l3sw_chk lt 100 \ > > rule $id="l_app-04" -inf: defined os_disk_chk and os_disk_chk eq ERROR \ > > rule $id="l_app-05" -inf: defined db_disk_chk and db_disk_chk eq ERROR > > > > colocation col_app-01 inf: ms_drbd_app cl_diskd_db > > colocation col_app-02 inf: ms_drbd_app cl_diskd_os > > colocation col_app-03 inf: ms_drbd_app cl_pingd_ope > > colocation col_app-04 inf: rg_mysqld ms_drbd_app:Master > > > > order odr_app-01 inf: cl_diskd_db ms_drbd_app > > order odr_app-02 inf: cl_diskd_os ms_drbd_app > > order odr_app-03 inf: cl_pingd_ope ms_drbd_app > > order odr_app-04 inf: ms_drbd_app:promote rg_mysqld rg_app:start > > > > property $id="cib-bootstrap-options" \ > > default-resource-stickiness="200" \ > > no-quorum-policy="ignore" \ > > stonith-enabled="false" \ > > dc-version="1.0.13-a83fae5" \ > > cluster-infrastructure="Heartbeat" > > ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ > > > > _______________________________________________ > > 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 _______________________________________________ Linux-ha-japan mailing list Linux****@lists***** http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Fork