Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux-HA>
  3. Japanese
OSハングアップ時の挙動
k.xnakamu at gmail
Jan 8, 2016, 2:20 AM
Post #1 of 3 (1300 views)
Permalink
関係者各位
お世話になっております。nakaと申します。
小出しで申し訳ありません。

環境：
CentOS 6.2(x86_64)
pacemaker-1.0.12-1.el6.x86_64
稼働系：hoge01v
待機系：hoge02v

異常時の動作検証をしております。
2ノードクラスタ構成にて、稼働系をSYSRQにてハングアップさせた時に
待機系にF/Oしてそのまま待機系でサービスリソース(MySQL)が起動することを
期待しております。

実際に稼働系を
# echo c > /proc/sysrq-trigger
でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動しておかしな
状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにクラスタリソースがF/Bされました。

（crm_mon -Afr1）
Migration summary:
* Node hoge02v:
service_sfdb01v: migration-threshold=1000000 fail-count=1000000
* Node hoge01v:

Failed actions:
service_sfdb01v_monitor_300000 (node=hoge02v, call=24, rc=7,
status=complete): not running
service_sfdb01v_start_0 (node=hoge02v, call=27, rc=-2, status=Timed
Out): unknown exec error

「service_sfdb01v」というのがMySQLサービスのリソースとなります。

（設定内容）
# crm configure save current.crm
# cat current.crm
node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" hoge01v
node $id="4a851515-443f-6140-b38f-dfb4bb46c010" hoge02v
primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
meta migration-threshold="5" \
params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
op monitor interval="3s"
primitive res_ping ocf:pacemaker:ping \
params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200"
dampen="1" debug="true" attempts="10" \
op monitor interval="10s" timeout="60" \
op start interval="0" timeout="60"
primitive service_naka01v lsb:pkg_naka01v \
op start interval="0s" timeout="90s" \
op monitor interval="300s" timeout="20s" \
op stop interval="0s" timeout="100s" \
meta is-managed="true"
primitive service_sfdb01v lsb:pkg_sfdb01v \
op start interval="0s" timeout="90s" \
op monitor interval="300s" enabled="true" timeout="20s" \
op stop interval="0s" timeout="100s" \
meta is-managed="true"
primitive vgsfdb01v ocf:heartbeat:LVM \
params volgrpname="vgsfdb01v"
primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
meta migration-threshold="5" \
params device="/dev/vgsfdb01v/LogVol00" fstype="ext4"
directory="/mysf" \
op monitor interval="20s"
primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
params index="1" device="/dev/vgsfdb01v/lv_quorum"
group pkg_naka01v service_naka01v \
meta is-managed="true" target-role="Started"
group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum
vgsfdb01v_LogVol00 service_sfdb01v \
meta is-managed="true" target-role="Started"
clone clone_ping res_ping \
meta target-role="Started"
location pkg_naka01v-location pkg_naka01v \
rule $id="pkg_naka01v-location-0" 200: #uname eq hoge01v \
rule $id="pkg_naka01v-location-1" 100: #uname eq hoge02v
location pkg_naka01v-service-location pkg_naka01v \
rule $id="pkg_naka01v-service-location-rule" -inf: defined
eth0_ping_set and eth0_ping_set lt 200
location pkg_sfdb01v-location pkg_sfdb01v \
rule $id="pkg_sfdb01v-location-0" 200: #uname eq hoge01v \
rule $id="pkg_sfdb01v-location-1" 100: #uname eq hoge02v
location pkg_sfdb01v-service-location pkg_sfdb01v \
rule $id="pkg_sfdb01v-service-location-rule" -inf: defined
eth0_ping_set and eth0_ping_set lt 200
property $id="cib-bootstrap-options" \
dc-version="1.0.12-066152e" \
cluster-infrastructure="Heartbeat" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
default-action-timeout="120s" \
last-lrm-refresh="1450681148" \
maintenance-mode="false"
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY"


異常時にどのような仕組みでF/Oするか正確なところを理解しておらず、私も
調査段階ではありますが、被疑箇所とみられる部分等ご存知でしたら、アドバイスを
頂けると幸いです。Packemakerというより、こちらのMySQL起動停止のスクリプトだったり
エラーハンドリングに問題があるのかも未調査です。

曖昧な状態でのメールとなり恐縮ですが、宜しくお願い致します。

以上、宜しくお願い致します。

--
Nakamura
Re: OSハングアップ時の挙動 [ In reply to ]
k.xnakamu at gmail
Jan 26, 2016, 6:15 PM
Post #2 of 3 (1248 views)
Permalink
ひがし様、関係者各位

お世話になっております。nakaと申します。
返信が遅くなってしまい申し訳ありません。
ご連絡頂き有難うございます。

> 待機系(hoge02v)で起動したという２つのMySQLはそれぞれ誰が起動したものか
> 心当たりはないでしょうか？
> (元々、待機系(hoge02v)で手動でMySQLを起動させてはいませんでしたか？
> もしくはOSのMySQLサービスの自動起動が有効になっていませんか？)

特に待機系側で手動でMySQLを起動させていたわけでもなく、
OSでMySQLサービスの自動起動を有効にしていたわけでもありませんでした。
MySQLサービススクリプトは独自のものを使っており、LSBに準拠した形（7つの
返り値のルール）で作っておりました。

2つのMySQLはそれぞれ誰が起動してるのか、ログを調べました。
どうやらサービスリソースのstartとmonitorの起動がほぼ同時に行われてるのが原因かなと
推測しています。MySQLサービスが完全に起動する前にmonitorがstatusをチェックして
「MySQLは起動していないから、restartしよう」と動作し、二重起動になってしまった
かなと考えています。

# grep "rsc:" /var/log/heartbeat_info.log-20160124
(一部抜粋)
6 local3.info<158> 2016-01-20T10:57:27.110393+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v start[18] (pid 8866)　★
6 local3.info<158> 2016-01-20T10:57:27.192217+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v monitor[19] (pid 8938)　★
6 local3.info<158> 2016-01-20T10:57:27.617212+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v stop[20] (pid 9573)
6 local3.info<158> 2016-01-20T10:57:27.667986+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v start[21] (pid 9637)
6 local3.info<158> 2016-01-20T10:57:29.721799+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v monitor[22] (pid 10364)
6 local3.info<158> 2016-01-20T10:59:10.098877+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v stop[23] (pid 13968)
6 local3.info<158> 2016-01-20T10:59:10.152291+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v start[24] (pid 14000)
6 local3.info<158> 2016-01-20T11:00:40.268121+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v stop[25] (pid 18137)

試しに、開始時間を遅らせるオプションをサービスリソースに設定してみました。
primitive service_sfdb01v lsb:pkg_sfdb01v \
op monitor interval="300s" enabled="true" timeout="20s"
start-delay="10s" \
として「start-delay="10s"」を追記してみたところ、OSハングさせると想定通りに
待機系へF/Oしてくれました。startの10秒後にmonitorが起動する旨のログが出ていました。


疑問なのは、
shutdownコマンドを実施した時、/etc/init.d/heartbeat stopさせた時等のケースでは、
上記のstart-delayオプションをつけなくても必ず正常に待機系へF/Oしてくれます。
ログを見ると、サービスがstartしてから数秒後～数十秒後にminitorが起動しているので、
サービスがstartしたことをどこかでちゃんと認識してるようです。
OSハングアップの時では、start・monitorの開始が必ずほぼ同じタイミングで行われます。
OSハングアップ時だと挙動が異なるものなのでしょうか。。？
同じ境遇でstart-delayオプションを設定した方はいらっしゃいませんでしょうか。

お手数おかけ致しますが、もし情報等お持ちでしたら共有頂けると幸いです。
以上、宜しくお願い致します。


2016年1月14日 14:09 <kazuh@goo.jp>:
>
> naka様
>
> ひがしと申します。
> お世話になります。
>
> >実際に稼働系を
> ># echo c > /proc/sysrq-trigger
> >でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動
> >しておかしな
> >状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにク
> >ラスタリソースがF/Bされました。
>
> 待機系(hoge02v)で起動したという２つのMySQLはそれぞれ誰が起動したものか
> 心当たりはないでしょうか？
> (元々、待機系(hoge02v)で手動でMySQLを起動させてはいませんでしたか？
> もしくはOSのMySQLサービスの自動起動が有効になっていませんか？)
>
> Pacemaker以外がMySQLを起動することの無いよう、運用を行ってください。
>
>
> > primitive service_sfdb01v lsb:pkg_sfdb01v \
> とのことなので、Pacemakerに付属(resource-agentsパッケージに同梱のmysql RAでは
> なく、独自のスクリプトでMySQLを制御しているとお見受けしました。
>
> Pacemakerのリソース制御スクリプトとして使用するためには、スクリプトは
> 以下の仕様(LSB)を満たす必要があります。
>
> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/ap-lsb.html
>
> 特に、既に起動時にstartされた場合や、既に停止時にstopされた場合の挙動と引数も
> 重要です。
>
> 今回のケースでは、この「既に起動時にstartされた場合」に、pkg_sfdb01vが、
> 「何もせず、0を返す。(already running等ログメッセージを表示してもよい。)」
> という動作になるか、確認してください。(上記URLの3のケース)
>
>
> 以上です。
> よろしくお願いいたします。
>
>
> ----- 元のメッセージ -----
> From: "Keisuke Nakamura" <k.xnakamu@gmail.com>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月8日, 金曜日 午後 7:20:26
> 件名: [Linux-ha-jp] OSハングアップ時の挙動
>
>
>
>
>
> 関係者各位
> お世話になっております。nakaと申します。
> 小出しで申し訳ありません。
>
> 環境：
> CentOS 6.2(x86_64)
> pacemaker-1.0.12-1.el6.x86_64
> 稼働系：hoge01v
> 待機系：hoge02v
>
> 異常時の動作検証をしております。
> 2ノードクラスタ構成にて、稼働系をSYSRQにてハングアップさせた時に
> 待機系にF/Oしてそのまま待機系でサービスリソース(MySQL)が起動することを
> 期待しております。
>
> 実際に稼働系を
> # echo c > /proc/sysrq-trigger
> でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動しておかしな
> 状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにクラスタリソースがF/Bされました。
>
> （crm_mon -Afr1）
> Migration summary:
> * Node hoge02v:
> service_sfdb01v: migration-threshold=1000000 fail-count=1000000
> * Node hoge01v:
>
> Failed actions:
> service_sfdb01v_monitor_300000 (node=hoge02v, call=24, rc=7, status=complete): not running
> service_sfdb01v_start_0 (node=hoge02v, call=27, rc=-2, status=Timed Out): unknown exec error
>
> 「service_sfdb01v」というのがMySQLサービスのリソースとなります。
>
>
>
> （設定内容）
> # crm configure save current.crm
>
> # cat current.crm
>
> node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" hoge01v
> node $id="4a851515-443f-6140-b38f-dfb4bb46c010" hoge02v
> primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
> meta migration-threshold="5" \
> params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
> op monitor interval="3s"
> primitive res_ping ocf:pacemaker:ping \
> params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200" dampen="1" debug="true" attempts="10" \
> op monitor interval="10s" timeout="60" \
> op start interval="0" timeout="60"
> primitive service_naka01v lsb:pkg_naka01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive service_sfdb01v lsb:pkg_sfdb01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" enabled="true" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive vgsfdb01v ocf:heartbeat:LVM \
> params volgrpname="vgsfdb01v"
> primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
> meta migration-threshold="5" \
> params device="/dev/vgsfdb01v/LogVol00" fstype="ext4" directory="/mysf" \
> op monitor interval="20s"
> primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
> params index="1" device="/dev/vgsfdb01v/lv_quorum"
> group pkg_naka01v service_naka01v \
> meta is-managed="true" target-role="Started"
> group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum vgsfdb01v_LogVol00 service_sfdb01v \
> meta is-managed="true" target-role="Started"
> clone clone_ping res_ping \
> meta target-role="Started"
> location pkg_naka01v-location pkg_naka01v \
> rule $id="pkg_naka01v-location-0" 200: #uname eq hoge01v \
> rule $id="pkg_naka01v-location-1" 100: #uname eq hoge02v
> location pkg_naka01v-service-location pkg_naka01v \
> rule $id="pkg_naka01v-service-location-rule" -inf: defined eth0_ping_set and eth0_ping_set lt 200
> location pkg_sfdb01v-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-location-0" 200: #uname eq hoge01v \
> rule $id="pkg_sfdb01v-location-1" 100: #uname eq hoge02v
> location pkg_sfdb01v-service-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-service-location-rule" -inf: defined eth0_ping_set and eth0_ping_set lt 200
> property $id="cib-bootstrap-options" \
> dc-version="1.0.12-066152e" \
> cluster-infrastructure="Heartbeat" \
> stonith-enabled="false" \
> no-quorum-policy="ignore" \
> default-action-timeout="120s" \
> last-lrm-refresh="1450681148" \
> maintenance-mode="false"
> rsc_defaults $id="rsc-options" \
> resource-stickiness="INFINITY"
>
>
> 異常時にどのような仕組みでF/Oするか正確なところを理解しておらず、私も
> 調査段階ではありますが、被疑箇所とみられる部分等ご存知でしたら、アドバイスを
> 頂けると幸いです。Packemakerというより、こちらのMySQL起動停止のスクリプトだったり
> エラーハンドリングに問題があるのかも未調査です。
>
>
> 曖昧な状態でのメールとなり恐縮ですが、宜しくお願い致します。
>
> 以上、宜しくお願い致します。
>
> --
>
> Nakamura
>
> _______________________________________________
> 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




--
Nakamura
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: OSハングアップ時の挙動 [ In reply to ]
takehiro.dreamizm at gmail
Jan 26, 2016, 10:15 PM
Post #3 of 3 (1247 views)
Permalink
nakaさん

こんにちは、松島と申します。

MySQLの制御スクリプトはLSB準拠のお手製とのことですが、たとえばスクリプトの"start"処理の中で、SQLを受け付けるようになったら起動成功とするようにしてはいかがでしょうか。
SysVInitのスクリプトは投げっぱなしのものがあり、サービスとして正しく起動できたかどうか確認するには不十分なので、たとえばApacheのようにリクエストに対してレスポンスがあることを確認することができるようRAが作られています。

また、二重起動していたとのことですが、これはmigration-threshold=1にすることで防止可能と思います。
ただし、サービスの準備ができる前にmonitorが走ってしまいfailcountが上がってしまいますと、2ノードしかない場合にはF/O先がなくなってしまい、サービス停止の状態になります。

start-delayを設定することが一番お手軽ですが、サービスの準備ができるまでの時間は一定ではありませんので、もし可能な場合にはinitスクリプトの中で起動完了を確認して成否を返却するのがベターだと思います。

横から失礼いたしました。

----
Takehiro Matsushima


2016年1月27日 11:15 Keisuke Nakamura <k.xnakamu@gmail.com>:
> ひがし様、関係者各位
>
> お世話になっております。nakaと申します。
> 返信が遅くなってしまい申し訳ありません。
> ご連絡頂き有難うございます。
>
>> 待機系(hoge02v)で起動したという２つのMySQLはそれぞれ誰が起動したものか
>> 心当たりはないでしょうか？
>> (元々、待機系(hoge02v)で手動でMySQLを起動させてはいませんでしたか？
>> もしくはOSのMySQLサービスの自動起動が有効になっていませんか？)
>
> 特に待機系側で手動でMySQLを起動させていたわけでもなく、
> OSでMySQLサービスの自動起動を有効にしていたわけでもありませんでした。
> MySQLサービススクリプトは独自のものを使っており、LSBに準拠した形（7つの
> 返り値のルール）で作っておりました。
>
> 2つのMySQLはそれぞれ誰が起動してるのか、ログを調べました。
> どうやらサービスリソースのstartとmonitorの起動がほぼ同時に行われてるのが原因かなと
> 推測しています。MySQLサービスが完全に起動する前にmonitorがstatusをチェックして
> 「MySQLは起動していないから、restartしよう」と動作し、二重起動になってしまった
> かなと考えています。
>
> # grep "rsc:" /var/log/heartbeat_info.log-20160124
> (一部抜粋)
> 6 local3.info<158> 2016-01-20T10:57:27.110393+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v start[18] (pid 8866)　★
> 6 local3.info<158> 2016-01-20T10:57:27.192217+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v monitor[19] (pid 8938)　★
> 6 local3.info<158> 2016-01-20T10:57:27.617212+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v stop[20] (pid 9573)
> 6 local3.info<158> 2016-01-20T10:57:27.667986+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v start[21] (pid 9637)
> 6 local3.info<158> 2016-01-20T10:57:29.721799+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v monitor[22] (pid 10364)
> 6 local3.info<158> 2016-01-20T10:59:10.098877+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v stop[23] (pid 13968)
> 6 local3.info<158> 2016-01-20T10:59:10.152291+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v start[24] (pid 14000)
> 6 local3.info<158> 2016-01-20T11:00:40.268121+09:00 hoge02v lrmd:
> [2729]: info: rsc:service_sfdb01v stop[25] (pid 18137)
>
> 試しに、開始時間を遅らせるオプションをサービスリソースに設定してみました。
> primitive service_sfdb01v lsb:pkg_sfdb01v \
> op monitor interval="300s" enabled="true" timeout="20s"
> start-delay="10s" \
> として「start-delay="10s"」を追記してみたところ、OSハングさせると想定通りに
> 待機系へF/Oしてくれました。startの10秒後にmonitorが起動する旨のログが出ていました。
>
>
> 疑問なのは、
> shutdownコマンドを実施した時、/etc/init.d/heartbeat stopさせた時等のケースでは、
> 上記のstart-delayオプションをつけなくても必ず正常に待機系へF/Oしてくれます。
> ログを見ると、サービスがstartしてから数秒後～数十秒後にminitorが起動しているので、
> サービスがstartしたことをどこかでちゃんと認識してるようです。
> OSハングアップの時では、start・monitorの開始が必ずほぼ同じタイミングで行われます。
> OSハングアップ時だと挙動が異なるものなのでしょうか。。？
> 同じ境遇でstart-delayオプションを設定した方はいらっしゃいませんでしょうか。
>
> お手数おかけ致しますが、もし情報等お持ちでしたら共有頂けると幸いです。
> 以上、宜しくお願い致します。
>
>
> 2016年1月14日 14:09 <kazuh@goo.jp>:
>>
>> naka様
>>
>> ひがしと申します。
>> お世話になります。
>>
>> >実際に稼働系を
>> ># echo c > /proc/sysrq-trigger
>> >でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動
>> >しておかしな
>> >状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにク
>> >ラスタリソースがF/Bされました。
>>
>> 待機系(hoge02v)で起動したという２つのMySQLはそれぞれ誰が起動したものか
>> 心当たりはないでしょうか？
>> (元々、待機系(hoge02v)で手動でMySQLを起動させてはいませんでしたか？
>> もしくはOSのMySQLサービスの自動起動が有効になっていませんか？)
>>
>> Pacemaker以外がMySQLを起動することの無いよう、運用を行ってください。
>>
>>
>> > primitive service_sfdb01v lsb:pkg_sfdb01v \
>> とのことなので、Pacemakerに付属(resource-agentsパッケージに同梱のmysql RAでは
>> なく、独自のスクリプトでMySQLを制御しているとお見受けしました。
>>
>> Pacemakerのリソース制御スクリプトとして使用するためには、スクリプトは
>> 以下の仕様(LSB)を満たす必要があります。
>>
>> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/ap-lsb.html
>>
>> 特に、既に起動時にstartされた場合や、既に停止時にstopされた場合の挙動と引数も
>> 重要です。
>>
>> 今回のケースでは、この「既に起動時にstartされた場合」に、pkg_sfdb01vが、
>> 「何もせず、0を返す。(already running等ログメッセージを表示してもよい。)」
>> という動作になるか、確認してください。(上記URLの3のケース)
>>
>>
>> 以上です。
>> よろしくお願いいたします。
>>
>>
>> ----- 元のメッセージ -----
>> From: "Keisuke Nakamura" <k.xnakamu@gmail.com>
>> 宛先: linux-ha-japan@lists.osdn.me
>> 送信済み: 2016年1月8日, 金曜日 午後 7:20:26
>> 件名: [Linux-ha-jp] OSハングアップ時の挙動
>>
>>
>>
>>
>>
>> 関係者各位
>> お世話になっております。nakaと申します。
>> 小出しで申し訳ありません。
>>
>> 環境：
>> CentOS 6.2(x86_64)
>> pacemaker-1.0.12-1.el6.x86_64
>> 稼働系：hoge01v
>> 待機系：hoge02v
>>
>> 異常時の動作検証をしております。
>> 2ノードクラスタ構成にて、稼働系をSYSRQにてハングアップさせた時に
>> 待機系にF/Oしてそのまま待機系でサービスリソース(MySQL)が起動することを
>> 期待しております。
>>
>> 実際に稼働系を
>> # echo c > /proc/sysrq-trigger
>> でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動しておかしな
>> 状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにクラスタリソースがF/Bされました。
>>
>> （crm_mon -Afr1）
>> Migration summary:
>> * Node hoge02v:
>> service_sfdb01v: migration-threshold=1000000 fail-count=1000000
>> * Node hoge01v:
>>
>> Failed actions:
>> service_sfdb01v_monitor_300000 (node=hoge02v, call=24, rc=7, status=complete): not running
>> service_sfdb01v_start_0 (node=hoge02v, call=27, rc=-2, status=Timed Out): unknown exec error
>>
>> 「service_sfdb01v」というのがMySQLサービスのリソースとなります。
>>
>>
>>
>> （設定内容）
>> # crm configure save current.crm
>>
>> # cat current.crm
>>
>> node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" hoge01v
>> node $id="4a851515-443f-6140-b38f-dfb4bb46c010" hoge02v
>> primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
>> meta migration-threshold="5" \
>> params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
>> op monitor interval="3s"
>> primitive res_ping ocf:pacemaker:ping \
>> params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200" dampen="1" debug="true" attempts="10" \
>> op monitor interval="10s" timeout="60" \
>> op start interval="0" timeout="60"
>> primitive service_naka01v lsb:pkg_naka01v \
>> op start interval="0s" timeout="90s" \
>> op monitor interval="300s" timeout="20s" \
>> op stop interval="0s" timeout="100s" \
>> meta is-managed="true"
>> primitive service_sfdb01v lsb:pkg_sfdb01v \
>> op start interval="0s" timeout="90s" \
>> op monitor interval="300s" enabled="true" timeout="20s" \
>> op stop interval="0s" timeout="100s" \
>> meta is-managed="true"
>> primitive vgsfdb01v ocf:heartbeat:LVM \
>> params volgrpname="vgsfdb01v"
>> primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
>> meta migration-threshold="5" \
>> params device="/dev/vgsfdb01v/LogVol00" fstype="ext4" directory="/mysf" \
>> op monitor interval="20s"
>> primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
>> params index="1" device="/dev/vgsfdb01v/lv_quorum"
>> group pkg_naka01v service_naka01v \
>> meta is-managed="true" target-role="Started"
>> group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum vgsfdb01v_LogVol00 service_sfdb01v \
>> meta is-managed="true" target-role="Started"
>> clone clone_ping res_ping \
>> meta target-role="Started"
>> location pkg_naka01v-location pkg_naka01v \
>> rule $id="pkg_naka01v-location-0" 200: #uname eq hoge01v \
>> rule $id="pkg_naka01v-location-1" 100: #uname eq hoge02v
>> location pkg_naka01v-service-location pkg_naka01v \
>> rule $id="pkg_naka01v-service-location-rule" -inf: defined eth0_ping_set and eth0_ping_set lt 200
>> location pkg_sfdb01v-location pkg_sfdb01v \
>> rule $id="pkg_sfdb01v-location-0" 200: #uname eq hoge01v \
>> rule $id="pkg_sfdb01v-location-1" 100: #uname eq hoge02v
>> location pkg_sfdb01v-service-location pkg_sfdb01v \
>> rule $id="pkg_sfdb01v-service-location-rule" -inf: defined eth0_ping_set and eth0_ping_set lt 200
>> property $id="cib-bootstrap-options" \
>> dc-version="1.0.12-066152e" \
>> cluster-infrastructure="Heartbeat" \
>> stonith-enabled="false" \
>> no-quorum-policy="ignore" \
>> default-action-timeout="120s" \
>> last-lrm-refresh="1450681148" \
>> maintenance-mode="false"
>> rsc_defaults $id="rsc-options" \
>> resource-stickiness="INFINITY"
>>
>>
>> 異常時にどのような仕組みでF/Oするか正確なところを理解しておらず、私も
>> 調査段階ではありますが、被疑箇所とみられる部分等ご存知でしたら、アドバイスを
>> 頂けると幸いです。Packemakerというより、こちらのMySQL起動停止のスクリプトだったり
>> エラーハンドリングに問題があるのかも未調査です。
>>
>>
>> 曖昧な状態でのメールとなり恐縮ですが、宜しくお願い致します。
>>
>> 以上、宜しくお願い致します。
>>
>> --
>>
>> Nakamura
>>
>> _______________________________________________
>> 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
>
>
>
>
> --
> Nakamura
> _______________________________________________
> 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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal