[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-ha-jp
Subject: Re: [Linux-ha-jp] =?iso-2022-jp?b?GyRCJTklPyVzJVAlJEImJHJAWiRqGyhC?= =?iso-2022-jp?b?GyRCTiUkOSRIGyh
From: kazuh () goo ! jp
Date: 2016-02-01 0:18:20
Message-ID: 350778402.156294678.1454285900365.JavaMail.root () goo ! jp
[Download RAW message or body]
広瀬様
ひがしです。お世話になります。
期待通り動作したとのことで、よかったです。
orderを含め、制約のスコアは、私も動かしてみないとわからない
というところで、理解しきっているわけではないですよ・・
(そのため、回答に少し時間をいた きました)
特にスコア絡みの動作はエラーが出るわけでもなく、
なかなか気づきにくいですよね。
取り急ぎ以上です。
よろしくお願いいたします。
----- 元のメッセージ -----
From: momoko@mail.t-momoko.org
宛先: linux-ha-japan@lists.osdn.me
送信済み: 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.jpさん:
> 広瀬様
>
> ひがしです。お世話になります。
>
> いた いた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: momoko@mail.t-momoko.org
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 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.jpさん:
> > 広瀬様
> >
> > ひがしと申します。お世話になります。
> >
> > > しかしながら、どちらかひとつのサーバに2グループ全部寄せたあと、完全にスタ
> > > ンバイ機と化したサーバ側のHeartbeatを停止すると、DRBDがコケてしまい結果的
> > > にMySQLが死亡することになるので、HAが崩壊します
> > 私がDRBDにあまり明るくないせいもあり、設定を見た \
> > けでは ちょっと原 がわかりませんでした。
> >
> > 「DRBDがコケる」とあるので、何らかのエラーが絡んでいるの
> > ではないかと思います。
> >
> > 解析のため、当該事象発生時のPacemakerのログ(ha-logまたは/var/log/messages)と
> > OSログ(/var/log/messages)をいた けないでしょうか。
> >
> >
> > 以上です。
> > よろしくお願いいたします。
> >
> > ----- 元のメッセージ -----
> > From: momoko@mail.t-momoko.org
> > 宛先: linux-ha-japan@lists.osdn.me
> > 送信済み: 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の制約に関しては期待通りの起動、並びに
> > マイグレーション動作をします
> > しかしながら、どちらかひとつのサーバに2グループ全部寄せたあと、完全にスタ
> > ンバイ機と化したサーバ側の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-ha-japan@lists.osdn.me
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux-ha-japan@lists.osdn.me
> > http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic