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


■実験

migration-thresholdは何回故障したらフェイルオーバするかを指定するものでした。

これを変更して、挙動が変わることを実験してみます。例のCRM設定が稼働している環境で、以下手順をやってみてください。

手順1)故障発生

Dummyリソースは/var/run/resource-agents/に空のファイルを作成し、それが存在するかどうかでリソースの稼働をmonitorしています。

このファイルを削除するとわざと故障を発生させることができます。ここではresource1リソースを故障させてみます。

[root@pm01 ~]# ls /var/run/resource-agents/
Dummy-resource1.state  Dummy-resource2.state  Dummy-resource3:0.state
[root@pm01 ~]# rm /var/run/resource-agents/Dummy-resource1.state
rm: remove regular empty file `/var/run/resource-agents/Dummy-resource1.state'? y

これを行うと、10秒以内にPacemakerは故障を検知し、F/Oを開始します。
crm_mon -rfAを別のコンソールに表示させながら行うと、故障の検知~F/Oの動作をリアルタイムに把握することができます。

手順2)F/O完了確認

crm_monの表示が以下のようになればF/Oは完了です。

~略~
Online: [ pm01 pm02 ]

Full list of resources:

 Resource Group: grp
     resource1  (ocf::heartbeat:Dummy): Started pm02 ★1
     resource2  (ocf::heartbeat:Dummy): Started pm02 ★2
 Clone Set: clnResource
     Started: [ pm01 pm02 ]

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

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

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

★1、★2部分で、resource1,2が現在pm02で稼働していることがわかります。また★3、★4でresource1に故障があったことがわかります。
手順1を1回実施し、dummy1、dummy2リソースがpm02へF/Oしたことが確認できました。

手順3)migration-threshold変更

次にexample01.crmのmigration-thresholdをmigration-threshold=”2″と書き換え、同じことを実施してみます。

書き換え後、前述のインストール手順5でPacemakerを一旦停止し、インストール手順2~4をもう一度実施し、新たなCRM設定ファイルを有効にしてください。

その後、上記手順1をもう一度実行してください。いろいろごにょごにょPacemakerが反応したのちcrm_mon表示が以下のように落ち着くはずです。

~略~
Online: [ pm01 pm02 ]

Full list of resources:

 Resource Group: grp
     resource1  (ocf::heartbeat:Dummy): Started pm01 ★1'
     resource2  (ocf::heartbeat:Dummy): Started pm01 ★2'
 Clone Set: clnResource
     Started: [ pm01 pm02 ]

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

Migration summary:
* Node pm01:
   resource1: migration-threshold=2 fail-count=1 ★3'
* Node pm02:

★1’、★2’でresource1,2リソースはpm01でまだ稼働していることがわかります。★3’でresource1の故障があったことがわかります。
つまり1回の故障ではpm02へのF/Oは発生しなかったことになります。
crm_mon表示をじっと見ていた方は気づいたかもしれませんが、上記表示に落ち着くまでに実はresource1,2リソースは一度再起動しています。migration-threshold回に達するまではリソース故障はリソース再起動で対処されるためです。

手順4)故障(2回目)

この状態でさらにもう一度resource1を故障させます。上記手順1をもう一度行ってください。
crm_mon -rfA表示が以下のように落ち着くはずです。

~略~
Online: [ pm01 pm02 ]

Full list of resources:

 Resource Group: grp
     resource1  (ocf::heartbeat:Dummy): Started pm02 ★1"
     resource2  (ocf::heartbeat:Dummy): Started pm02 ★2"
 Clone Set: clnResource
     Started: [ pm01 pm02 ]

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

Migration summary:
* Node pm01:
   resource1: migration-threshold=2 fail-count=2 ★3"
* Node pm02:

Failed actions:
    resource1_monitor_10000 (node=pm01, call=14, rc=7, status=complete): not running ★4"

★4″で故障が発生したことを、★3″のfail-count=2でそれが累積2回となったことを示しています。
★1″、★2″でresource1,2がpm02で稼働していることがわかります。今度はresource1,2リソースがpm02へF/Oしました。

migration-threshold=”2″としたことで2回の故障でF/Oするようになったことが確認できました。

今回はCRM設定ファイルの冒頭部分を読み解きました。
次回以降では、適宜実験も行いつつそれ以降の部分を読み解いていきます。
次回以降もおつきあいいただければ幸いです。

Pages: 1 2 3 4

Comments are closed.