月刊あんどりゅーくん(7月号)


2. 知恵袋

先月は Dummy RA を使用して、migration-threshold の設定方法を紹介しました。

今月は、故障回数が migration-threshold に達して
フェイルオーバが発生した後の復旧手順を紹介します。

リソースは先月と同じく Dummy RA を使用します。

dummy.crm

### Cluster Option ###
property \
        no-quorum-policy="ignore" \
        stonith-enabled="false" \
        startup-fencing="false"

### Resource Defaults ###
rsc_defaults \
        resource-stickiness="INFINITY" \
        migration-threshold="1"

### Primitive Configuration ###
primitive prmDummy 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="block"

location location-01 prmDummy \
        rule 200: #uname eq xen01 \
        rule 100: #uname eq xen02

(1) リソースの起動
早速、リソースを起動させてみましょう。

# crm configure load update dummy.crm  

crm_verify[2854]: 2011/06/27_19:51:32 WARN: unpack_nodes: Blind faith: not fencing unseen nodes

STONITHを設定していない場合(stonith-enabled=”false”)、上記のエラーが出力されますが今回は無視してください。
ホントはちゃんとSTONITHを設定したほうがよいです。

crm_mon に -f オプションをつけて、リソースの状態を確認してみます。
起動したばかりなので、「Migration summary」にはノード名しか表示されていません。
故障が発生すると、ここになんやかんやと表示されます。

# crm_mon -i1 -f  

============
Last updated: Mon Jun 27 19:51:54 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 ]

prmDummy        (ocf::pacemaker:Dummy): Started xen01

Migration summary:
* Node xen02:
* Node xen01:


(2) リソースの故障

prmDummy は xen01 で起動しています。
migration-threshold=”1″ なので、xen01 で一回故障すると
すぐに xen02 にフェイルオーバするはずです。

では、ノード xen01 で Dummy RA のステータスファイルを削除して故障を発生させてみます。

# rm -f /var/run/Dummy-prmDummy.state

リソースの状態を確認すると…

# crm_mon -i1 -f  

============
Last updated: Mon Jun 27 19:52:31 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 ]

prmDummy (ocf::pacemaker:Dummy): Started xen02

Migration summary:
* Node xen02:
* Node xen01:
prmDummy: migration-threshold=1 fail-count=1

Failed actions:
prmDummy_monitor_10000 (node=xen01, call=4, rc=7, status=complete): not running

prmDummy は xen02 へフェイルオーバしました!
「Migration summary」を見ると、xen01 で prmDummy の fail-count が 1 となったことがわかります。

(3) failcount のクリア
では、failcount をクリアしてみましょう。
まず、次のようにコマンドラインから crm シェルを実行してみてください。

# crm resource failcount  

usage:
failcount <rsc> set <node> <value>
failcount <rsc> delete <node>
failcount <rsc> show <node>

crm_mon の表示はハイフンつきの「fail-count」で
crm シェルはハイフンなしの「failcount」なんですね…。
普段、気にしてないけどこういうとき妙に気になる…。
どっちかに統一しようよ、あんどりゅーくん。
(crm シェルつくってるのは、でやんくんだけど)

さて、気をとりなおしまして
failcount を削除するには、リソース名とノード名を指定する必要があります。
故障したノードは xen01 ですよね。
リソース名はえーっと…と思ったときは、次のコマンドを実行してください。

# crm resource show  

prmDummy (ocf::pacemaker:Dummy) Started

そうそう、リソース名は「prmDummy」でした。
というわけで、いよいよ failcount をクリア!
の前に、今のカウント数をちょっと確認しておきましょう。

# crm resource failcount prmDummy show xen01  

scope=status  name=fail-count-prmDummy value=1

failcount は 1 ですね。あたりまえですが crm_mon -f の表示と同じです。
今度こそは failcount をクリア!

# crm resource failcount prmDummy delete xen01

ちゃんと消えたかなー…。

# crm resource failcount prmDummy show xen01  

scope=status  name=fail-count-prmDummy value=0

failcount は 0 になりました!成功です。
crm_mon -f でも確認してみましょう。

# crm_mon -i1 -f  

============
Last updated: Mon Jun 27 19:53:05 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 ]

prmDummy        (ocf::pacemaker:Dummy): Started xen02

Migration summary:
* Node xen02:
* Node xen01:

Failed actions:
prmDummy_monitor_10000 (node=xen01, call=4, rc=7, status=complete): not running

「Migration summary」に表示されていた fail-count は消えています。
でも、「Failed actions」っていうのが残っちゃってますね。
これは、fail-count とは別にオペレーションの「故障履歴」が保存されているためです。
故障履歴も削除しておきましょう。

(4) 故障履歴のクリア
故障履歴を削除するためには cleanup コマンドを使用します。
コマンドラインから次のように crm シェルを起動してみましょう。

# crm resource cleanup  

usage: cleanup <rsc> [<node>]

今回もリソース名とノード名を指定する必要があるようです。
ノード名には故障が発生したほうのノードを指定してください。今回の例では xen01 です。

ノード名はあくまでオプションですが、指定しておいたほうがよいです。
今回は2ノード構成なので、そんなに大変なことにはなりませんが
例えば、10ノード構成の場合、10ノードすべてに cleanup コマンドが
実行されることになるので、思いがけず実行時間がかかってしまう可能性もあります。

では、cleanup コマンドを実行してみましょう。

# crm resource cleanup prmDummy xen01  

Cleaning up prmDummy on xen01
Waiting for 2 replies from the CRMd..

crm_mon -f で確認してみると…

# crm_mon -i1 -f  

============
Last updated: Mon Jun 27 19:55:17 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 ]

prmDummy        (ocf::pacemaker:Dummy): Started xen02

Migration summary:
* Node xen02:
* Node xen01:

「Failed actions」も消えています。よかったよかった。

(5) リソースの移動
fail-cout も Failed actions もうまく消えてくれたところで、フェイルオーバしたリソースを元のノードに戻してみましょう。
リソースの移動には move コマンドを使用します。

# crm resource move  

usage: migrate <rsc> [<node>] [<lifetime>] [force]

このコマンドもリソース名とノード名が必要ですね。
なにがなんでも移動させたい場合は、force オプションもつけてください。

で、move コマンドを実行する前に、ちょっと現在の configure を表示させてみましょう。

# crm configure show

node $id=”11111111-1111-1111-1111-111111111111″ xen01
node $id=”22222222-2222-2222-2222-222222222222″ xen02

primitive prmDummy 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=”block”

location location-01 prmDummy \
rule $id=”location-01-rule” 200: #uname eq xen01 \
rule $id=”location-01-rule-0″ 100: #uname eq xen02

property $id=”cib-bootstrap-options” \
dc-version=”1.0.11-db98485d06ed stable-1.0 tip” \
cluster-infrastructure=”Heartbeat” \
no-quorum-policy=”ignore” \
stonith-enabled=”false” \
startup-fencing=”false” \
last-lrm-refresh=”1309172113″

rsc_defaults $id=”rsc-options” \
resource-stickiness=”INFINITY” \
migration-threshold=”1″

「dc-version」とか「cluster-infrastructure」とか「last-lrm-refresh」とか
なんか見慣れない設定もありますが、このへんは Pacemaker が追加で挿入してくれた設定です。
それ以外は、dummy.crm とほとんど同じですね。

では、prmDummy を xen02 から xen01 へ移動させてみましょう。

# crm resource move prmDummy xen01 force  

WARNING: Creating rsc_location constraint ‘cli-standby-prmDummy’ with a score of -INFINITY for resource prmDummy on xen02.
This will prevent prmDummy from running on xen02 until the constraint is removed using the ‘crm_resource -U’ command or manually with cibadmin
This will be the case even if xen02 is the last node in the cluster
This message can be disabled with -Q

ごりっとエラーみたいなのがでたけど…。
まあ、ここはちょっと無視して crm_mon -f を確認してみると
prmDummy は xen02 から xen01 へちゃんと移動しています。

# crm_mon -i1 -f  

============
Last updated: Mon Jun 27 19:59:36 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 ]

prmDummy (ocf::pacemaker:Dummy): Started xen01

Migration summary:
* Node xen02:
* Node xen01:

ちなみに、move コマンドを実行したときに表示されたメッセージは
「xen02 で起動している prmDummy を xen01 に移動させるために
xen02 のスコア値を -INFINITY に変更しますよ」と言っていたのです。
移動後に configure を表示させてみると
xen01 の prmDummy は  INFINITY
xen02 の prmDummy は -INFINITY
という location が追加されていることがわかります。
location の設定を変更することによって、リソースを移動させているわけですね。

# crm configure show  

node $id=”11111111-1111-1111-1111-111111111111″ xen01
node $id=”22222222-2222-2222-2222-222222222222″ xen02

primitive prmDummy 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=”block”

location cli-prefer-prmDummy prmDummy \
rule $id=”cli-prefer-rule-prmDummy” inf: #uname eq xen01
location cli-standby-prmDummy prmDummy \
rule $id=”cli-standby-rule-prmDummy” -inf: #uname eq xen02

location location-01 prmDummy \
rule $id=”location-01-rule” 200: #uname eq xen01 \
rule $id=”location-01-rule-0″ 100: #uname eq xen02

property $id=”cib-bootstrap-options” \
dc-version=”1.0.11-db98485d06ed stable-1.0 tip” \
cluster-infrastructure=”Heartbeat” \
no-quorum-policy=”ignore” \
stonith-enabled=”false” \
startup-fencing=”false” \
last-lrm-refresh=”1309172113″

rsc_defaults $id=”rsc-options” \
resource-stickiness=”INFINITY” \
migration-threshold=”1″

もしこの状態で xen01 の prmDummy が壊れてしまうと、-INFINITY のxen02 ではリソースが起動できないので
フェイルオーバ先がなくなってしまいます。

ということで、move コマンドを実行した後は、セットで unmove コマンドも実行して、-INFINITY を削除しておきましょう。
unmove コマンドはノード名を指定する必要はありません。

# crm resource unmove prmDummy

ここで、configure を確認してみると…

# crm configure show  

node $id=”11111111-1111-1111-1111-111111111111″ xen01
node $id=”22222222-2222-2222-2222-222222222222″ xen02

primitive prmDummy 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=”block”

location location-01 prmDummy \
rule $id=”location-01-rule” 200: #uname eq xen01 \
rule $id=”location-01-rule-0″ 100: #uname eq xen02

property $id=”cib-bootstrap-options” \
dc-version=”1.0.11-db98485d06ed stable-1.0 tip” \
cluster-infrastructure=”Heartbeat” \
no-quorum-policy=”ignore” \
stonith-enabled=”false” \
startup-fencing=”false” \
last-lrm-refresh=”1309172113″

rsc_defaults $id=”rsc-options” \
resource-stickiness=”INFINITY” \
migration-threshold=”1″

move コマンドで追加されていた location は削除されています。
これでやっと初期起動時の状態に戻りました。

failcount と cleanup はセットで

  • crm resource failcount
  • crm resource cleanup

move と unmove もセットで

  • crm resource move
  • crm resource unmove

と、覚えてあげてください。

では、今月はこれにてどろん!εεεεεヾ(*´ー`)ノ

Pages: 1 2 3

Comments are closed.