動かして理解するPacemaker ~CRM設定編~ その3


■実験2 orderのスコア値をINFINITYにしてみる

orderのスコア値に0およびINFINITYを設定し、0とINIFINITYの意味の違いを確認します。

CRM設定は、3つのDummyリソースをorderで順序制約をかけただけのシンプルなものを使用します。

### Cluster Option ###
property no-quorum-policy="ignore" \
    stonith-enabled="false" \
    crmd-transition-delay="2s"

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

### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource2 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource3 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

### Resource Order ###
order rsc_order-1 0: resource1 resource2 resource3

2016.3.24 修正:以前の記事ではorderに「symmetrical=false」を付与していましたが、この場合Pacemaker-1.1系では、以下実験では0とINFINITYの動作の差が無くなった(いずれも以下0の場合と同じ)ため、「symmetrical=false」を削除しました。

なお、Dummyリソース(/usr/lib/ocf/resource.d/heartbeat/Dummy)が起動したタイミング(前後関係)をわかりやすくするため、start時に1秒sleepするよう改造しています。

また、order制約しかかけていないためpm01とpm02を同時に起動すると各リソースが分散してしまい挙動がわかりにくくなります。そのためまずはpm01を起動、設定を読み込み、全リソースがpm01で起動してからpm02を起動します。

# crm_mon -rfA
~略~

Online: [ pm01 pm02 ]

Full list of resources:

resource1       (ocf::heartbeat:Dummy): Started pm01
resource2       (ocf::heartbeat:Dummy): Started pm01
resource3       (ocf::heartbeat:Dummy): Started pm01

Node Attributes:
* Node pm01:
    + pm02-eth1                         : up
* Node pm02:
    + pm01-eth1                         : up

Migration summary:
* Node pm01:
* Node pm02:

以下コマンドを実行し、resource1を故障させます。

# rm -f /var/run/resource-agents/Dummy-resource1.state

Pacemakerが故障を検知し、F/Oを実行します。

# crm_mon -rfA
~略~

Online: [ pm01 pm02 ]

Full list of resources:

resource1       (ocf::heartbeat:Dummy): Started pm02 ★F/Oし、pm02で起動
resource2       (ocf::heartbeat:Dummy): Started pm01
resource3       (ocf::heartbeat:Dummy): Started pm01

Node Attributes:
* Node pm01:
    + pm02-eth1                         : up
* Node pm02:
    + pm01-eth1                         : up

Migration summary:
* Node pm01:
   resource1: migration-threshold=1 fail-count=1
* Node pm02:

Failed actions:
    resource1_monitor_10000 (node=pm01, call=52, rc=7, status=complete): not running

故障(ファイル削除)を発生させた時刻以降のログをgrepし、両ノードでリソースがどのような挙動をしたかを確認してみましょう。
Pacemaker-1.0系と1.1系でログの形式が異なるため、以下それぞれの場合を示します。

Pacemaker-1.0系の場合
○pm01のログ

# egrep "lrmd:.*info: rsc:[A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan  8 12:57:58 pm01 lrmd: [1518]: info: rsc:resource1 stop[53] (pid 4772)

○pm02のログ

# egrep "lrmd:.*info: rsc:[A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan  8 12:57:58 pm02 lrmd: [1492]: info: rsc:resource1 start[21] (pid 7667)

Pacemaker-1.1系の場合
○pm01のログ

# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:29:51 pm01 crmd[25011]:  notice: process_lrm_event: Operation resource1_stop_0: ok (node=pm01, call=21, rc=0, cib-update=72, confirmed=true)

○pm02のログ

# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:29:51 pm02 crmd[6357]:  notice: process_lrm_event: Operation resource1_start_0: ok (node=pm02, call=14, rc=0, cib-update=14, confirmed=true)

故障したresource1がpm01で停止後、pm02で起動し、F/Oが成功したことがログでも確認できました。



次に、orderのスコア値をINFINITYと変更し、さきほどと同じようにresource1を故障させます。

order rsc_order-1 0: resource1 resource2 resource3

  ↓書き換え

order rsc_order-1 INFINITY: resource1 resource2 resource3

故障後、crm_monは以下のようになると思います。

# crm_mon -rfA
~略~

Online: [ pm01 pm02 ]

Full list of resources:

resource1       (ocf::heartbeat:Dummy): Started pm02 ★F/Oし、pm02で起動
resource2       (ocf::heartbeat:Dummy): Started pm01
resource3       (ocf::heartbeat:Dummy): Started pm01

Node Attributes:
* Node pm01:
    + pm02-eth1                         : up
* Node pm02:
    + pm01-eth1                         : up

Migration summary:
* Node pm01:
   resource1: migration-threshold=1 fail-count=1
* Node pm02:

Failed actions:
    resource1_monitor_10000 (node=pm01, call=60, rc=7, status=complete): not running

スコア値が0のときと同じようにpm02でresource1が起動(F/O)しました。
しかし、若干挙動がさきほどとは違ったことに気付いたでしょうか?
crm_monをよーく見ていた方は気づいたかもしれませんが、実はresource2,3もresource1の故障につられ再起動しました。

ログ(/var/log/ha-log)からresource1~3の挙動を確認してみます。

Pacemaker-1.0系の場合
○pm01のログ

# egrep "lrmd:.*info: rsc:[:A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan  8 13:19:02 pm01 lrmd: [1518]: info: rsc:resource3 stop[61] (pid 5848) ★
Jan  8 13:19:02 pm01 lrmd: [1518]: info: rsc:resource2 stop[62] (pid 5849) ★
Jan  8 13:19:02 pm01 lrmd: [1518]: info: rsc:resource1 stop[63] (pid 5850)
Jan  8 13:19:04 pm01 lrmd: [1518]: info: rsc:resource2 start[64] (pid 5859) ★
Jan  8 13:19:05 pm01 lrmd: [1518]: info: rsc:resource3 start[66] (pid 5869) ★

○pm02のログ

# egrep "lrmd:.*info: rsc:[:A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan  8 13:19:03 pm02 lrmd: [8126]: info: rsc:resource1 start[5] (pid 8154)

Pacemaker-1.1系の場合
○pm01のログ

# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:33:11 pm01 crmd[25288]:  notice: process_lrm_event: Operation resource3_stop_0: ok ~略~ ★
Mar 24 10:33:13 pm01 crmd[25288]:  notice: process_lrm_event: Operation resource2_stop_0: ok ~略~ ★
Mar 24 10:33:15 pm01 crmd[25288]:  notice: process_lrm_event: Operation resource1_stop_0: ok ~略~
Mar 24 10:33:19 pm01 crmd[25288]:  notice: process_lrm_event: Operation resource2_start_0: ok ~略~ ★
Mar 24 10:33:21 pm01 crmd[25288]:  notice: process_lrm_event: Operation resource3_start_0: ok ~略~ ★

○pm02のログ

# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:33:15 pm02 crmd[6453]:  notice: process_lrm_event: Operation resource1_start_0: ok (node=pm02, call=14, rc=0, cib-update=11, confirmed=true)

★部分で、先ほどとは違い、resource2,3も停止→起動をしていることがわかります。
それぞれがstartした時刻を確認すると、resource1→resource2→resource3の順に起動したことがわかります。

これは設定したorder制約が
絶対に(=INFINITY)resource1→resource2→resource3の順に起動/停止しなければならない」
というものだったため、故障による状態変化に伴い、resource2およびresource3を一旦停止→起動という挙動になったためです。

一方スコア値が0の場合のorder制約は
なるべく(=0)resource1→resource2→resource3の順に起動/停止する」
というものであり、故障による状態変化はresource2およびresource3には影響しませんでした。

Pages: 1 2 3 4

Comments are closed.