２．知恵袋
日本語コミュニティのメーリングリストで、故障契機の話題がでていましたが
そういえば、Pacemakerでは「migration-threshold」という
パラメータが導入されておるのです。
Heartbeat v2時代は、一回故障が起こったらなにがなんでもフェイルオーバという
仕様だったのですが（on-failの設定にもよりますが）
Pacemakerは、故障回数が「migration-threshold」で設定した値に達するまで
故障とみなしません。
しかも、「migration-threshold」のデフォルト値は「0 (=disabled)」！
つまり、「migration-threshold」を明示的に設定しておかないと
いつまでたっても故障とみなしてくれないのです。
ということで、知恵袋では「migration-threshold」の設定方法をご紹介します。
Pacemakerのドキュメントで該当する箇所はこちら。
今回は「Dummy RA」を使用して動作を確認してみます。
Dummy RAは非常に単純なRAで、ちょっと新しい設定方法を試してみたい、というときに便利なRAです。
新しくRAを作るときも参考になるので、簡単に start, monitor, stop処理の中身を見てみましょう。
- start処理
start処理とはいいつつ、とりあえずmonitor処理を実行。
monitor OKであれば、もう自分起動済みじゃんということで return $OCF_SUCCES
monitor NGであれば、なんだ自分まだ起動できてないじゃんということで touch ${OCF_RESKEY_state}ここで作ってる${OCF_RESKEY_state}は
${HA_VARRUN}/Dummy-{OCF_RESOURCE_INSTANCE}.state”
です。
95 dummy_start() {
96 dummy_monitor
97 if [ $? = $OCF_SUCCESS ]; then
98 return $OCF_SUCCESS
99 fi
100 touch ${OCF_RESKEY_state}
101 }
- monitor処理
${OCF_RESKEY_state}があればmonitor OK
${OCF_RESKEY_state}がなければmonitor NG
という単純な処理です。
Dummy RAで擬似故障を発生させる場合は、${OCF_RESKEY_state}を削除すればよいということになります。
111 dummy_monitor() {
112 # Monitor _MUST!_ differentiate correctly between running
113 # (SUCCESS), failed (ERROR) or _cleanly_ stopped (NOT RUNNING).
114 # That is THREE states, not just yes/no.
115
116 if [ -f ${OCF_RESKEY_state} ]; then
117 return $OCF_SUCCESS
118 fi
119 if false ; then
120 return $OCF_ERR_GENERIC
121 fi
122 return $OCF_NOT_RUNNING
123 }
- stop処理 ${OCF_RESKEY_state}を削除します。
103 dummy_stop() {
104 dummy_monitor
105 if [ $? = $OCF_SUCCESS ]; then
106 rm ${OCF_RESKEY_state}
107 fi
108 return $OCF_SUCCESS
109 }
Dummy RAは、かなりまるめて説明すると
- start処理でステータスファイルを作って
- monitor処理でステータスファイルの有無を確認して
- stop処理でステータスファイルを削除
という単純な動作をするRAです。
他のRAの代替として動作確認に使用することも可能ですが、
単純すぎるがためにはまる罠というのもたまにありますのでご注意ください。
では、Dummy RAを起動させてみましょう。
(1) Dummy RAの起動
- Dummy RA用のcrmファイルを作成します。
まずは、migration-thresholdを設定せずに動作を確認してみましょう。
dummy00.crm
### Cluster Option ###
property no-quorum-policy="ignore" \
stonith-enabled="false" \
startup-fencing="false"
### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY"
### Primitive Resource ###
primitive dummy01 ocf:pacemaker:Dummy \
op start interval="0s" timeout="100s" on-fail="restart" \
op monitor interval="10s" timeout="100s" on-fail="restart" \
op stop interval="0s" timeout="100s" on-fail="stop"
- クラスタを起動します。
# service heartbeat start
- crmファイルをクラスタに反映します。
# crm configure load update dummy00.crm
- クラスタの状態を確認します。
-foオプションをつけると、failcount情報（故障回数）やoperation情報(start,monitorなどの状態)も表示されます。
# crm_mon -i1 -fo
============
Last updated: Mon May 30 13:08:55 2011
Stack: Heartbeat
Current DC: xen02 (22222222-2222-2222-2222-222222222222) – partition with quorum
Version: 1.0.11-db98485d06ed stable-1.0 tip
2 Nodes configured, unknown expected votes
1 Resources configured.
============
Online: [ xen01 xen02 ]
dummy01 (ocf::pacemaker:Dummy): Started xen01
Operations:
* Node xen02:
* Node xen01:
dummy01: migration-threshold=1000000
+ (3) start: rc=0 (ok)
+ (4) monitor: interval=10000ms rc=0 (ok)
なんと、migration-threshold=1000000！
1000000回目の故障でやっとフェイルオーバ！ということになります。
なんかいろいろムリですが、とりあえずノードxen01で起動しているdummy01を故障させてみましょう。
xen01でdummy01のステータスファイルを削除します。
# rm -f /var/run/Dummy-dummy01.state
しばらく crm_mon -i1 -fo を眺めていると。。。
============
Last updated: Mon May 30 13:09:42 2011
Stack: Heartbeat
Current DC: xen02 (22222222-2222-2222-2222-222222222222) – partition with quorum
Version: 1.0.11-db98485d06ed stable-1.0 tip
2 Nodes configured, unknown expected votes
1 Resources configured.
============
Online: [ xen01 xen02 ]
dummy01 (ocf::pacemaker:Dummy): Started xen01
Operations:
* Node xen02:
* Node xen01:
dummy01: migration-threshold=1000000 fail-count=1
+ (5) stop: rc=0 (ok)
+ (6) start: rc=0 (ok)
+ (7) monitor: interval=10000ms rc=0 (ok)
dummy01のfail-countが「1」にあがりましたね！
でも、フェイルオーバはしていません（xen01のまま）。
ログ（/var/log/ha-log）を見ると、monitor NGを検知してstopが実行されてはいます。
ただし、今回の例ではmonitorにon-fail=restartと設定してあるので、同一ノードで再起動に挑戦、
ステータスファイルの作成に成功（再起動成功）したので
dummy01は、再びxen01で動いているというわけです。
DCノード（この例ではxen02）でha-logを検索してみると、こんな感じになります。
# grep match_graph_event /var/log/ha-log
May 30 13:08:30 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_0 (6) confirmed on xen02 (rc=0)
May 30 13:08:32 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_0 (4) confirmed on xen01 (rc=0)
May 30 13:08:34 xen02 crmd: []: info: match_graph_event: Action dummy01_start_0 (7) confirmed on xen01 (rc=0)
May 30 13:08:35 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_10000 (8) confirmed on xen01 (rc=0
May 30 13:09:38 xen02 crmd: []: info: match_graph_event: Action dummy01_stop_0 (2) confirmed on xen01 (rc=0)
May 30 13:09:40 xen02 crmd: []: info: match_graph_event: Action dummy01_start_0 (5) confirmed on xen01 (rc=0)
May 30 13:09:42 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_10000 (6) confirmed on xen01 (rc=0)
