pacemaker_remoteについて(その4) 注意点

Pacemakerでpacemaker_remoteを使う場合の注意点を記載しておきます。

# コンパイル時の注意
pacemaker_remoteを使う場合、Pacemakerのコンパイル時にgnu-tls関連のパッケージを追加して、構築が必要です。

```
rpm -ivh gnutls-devel-3.1.18-8.el7.x86_64.rpm  gnutls-c++-3.1.18-8.el7.x86_64.rpm libtasn1-devel-3.3-3.el7.x86_64.rpm p11-kit-devel-0.18.7-4.el7.x86_64.rpm 
```

また、くどいようですが、pacemaker_remoteはまだまだ開発中の機能ですので、極力、新しいPacemakerのソースを利用することをおすすめします。

# クラスタ構築時の注意
remoteの通信ポートを空ける必要があります。
また、KVM環境で利用する場合、VirtualDomainリソースの起動に時間がかかると、VirtualDomain上のpacemaker_remoteとホストのPamaker間の通信がタイムアウトして起動に失敗する場合があります。あまり非力なホスト環境では試さないことをお勧めします。
もし、非力なホスト環境で、タイムアウトが起きる場合には、CLIファイルのstartのタイムアウト(remote-connect-timeout)を伸ばしてみてください。

```
(snip)
primitive guest1 VirtualDomain \
        meta remote-node=remote1 \
                remote-connect-timeout=120s \
(snip)
primitive guest2 VirtualDomain \
        meta remote-node=remote2 \
                remote-connect-timeout=120s \
(snip)
```

また、pacemaker_remoteへの配置制約(location)が正しく処理されず、意図したノードに配置されない場合がある為、remoteノードがクラスタに参加するのを待たせる制約が必要になります。
今回紹介したCLIファイルでは記載していませんが、以下のような特殊な設定（最後の-inf設定)が必要となります。

```
location loc1 dummy-remote \
 rule 200: #uname eq remote1 \
 rule 100: #uname eq remote2 \
 rule -inf: #uname eq sl7-01 \
 rule -inf: #uname ne remote1 and #uname ne remote2
```

ただし、すべてのpacemaker-remoteのノードを配置制約に書くことは、ノード数が増えた場合には非現実的ですので、この配置制約を記載する問題は今後のPacemakerの改善で修正されると思われます。

# STONITH利用時の注意
ベアメタル、Docker、KVM環境と紹介しましたが、pacemaker_remoteを構成する場合、実際にSTONITHが実行できるのは、Pacemakerが動作しているホストのみとなります。
また、Docker,KVM環境の場合、普通にpacemaker_remote環境を構築すると、STONITHを有効にした場合でも、実際には、stonithのプラグインは実行されません。
実際にstonithプラグインを利用したSTONITHが実行されるのは、ベアメタル環境のみとなります。
その他の構成の場合、STONITHは、dockerリソース、VirtualDomainリソースを停止・開始することで
代用されています。
この場合、pengineが故障発生からSTONITHを実行する状態遷移を作成する場合に以下のログが出力されます。

```
Nov  2 09:49:30 sl7-01 pengine[19444]: warning: Remote node remote1 will be fenced by recovering container resource guest1

```

言い換えると、Docker環境、KVM環境などでも、Pacemakerでコンテナ・ゲストの起動・停止を管理せずに、コンテナ・ゲスト内のpacemaker_remoteと通信する構成(ベアメタル環境のように、コンテナ・ゲストを扱わせる）すれば、STONITHは可能ということになります。

よって、この場合、Docker環境を変更すると以下のようなCLIになります。
以下のCLIであれば、コンテナ内のpacemaker_remoteと通信をする構成ですので、external/fecne_dockerでのSTONITHは可能となります。
CLI設定上もdocker RAは利用せず、ベアメタル環境と同じremote RAを利用しています。
(以下の例の場合は、コンテナ(remote1,remote2)の起動はPacemaker外でPacemaker起動より先に行っておく必要があります)

```
property no-quorum-policy="ignore" \
  stonith-enabled="true" \
  startup-fencing="false"

fencing_topology \
  remote1: Stonith1 \
  remote2: Stonith1

rsc_defaults resource-stickiness="INFINITY" \
  migration-threshold="1"

primitive Stonith1 stonith:fence_docker \
 params \
  pcmk_reboot_timeout="300" \
  pcmk_reboot_retries="1" \
  pcmk_host_list="remote1 remote2" \
  action="off" \
  ipaddr="127.0.0.1" \
  ipport="4243" \
  api_version="1.12" \
 op start interval="0s" timeout="60s" on-fail="restart" \
 op monitor interval="3600s" timeout="60s" on-fail="restart" \
 op stop interval="0s" timeout="60s" on-fail="ignore"

primitive remote1 ocf:pacemaker:remote \
  params \
        server="remote-node1" \
        port=10001 \
        op monitor interval="3s" timeout="30s" on-fail="restart" \

primitive remote2 ocf:pacemaker:remote \
  params \
        server="remote-node2" \
        port=10002 \
        op monitor interval="3s" timeout="30s" on-fail="restart" \

primitive dummy-remote Dummy \
  op start interval=0s timeout=60s \
  op monitor interval=30s timeout=60s \
  op stop interval=0s timeout=60s on-fail="fence"

location loc1 dummy-remote \
 rule 300: #uname eq remote1 \
 rule 200: #uname eq remote2

location loc2 dummy-remote resource-discovery="never" \
 rule -inf: #uname eq cent7-host
```

次のような２つのCLIファイルを用意して、docker RAとremote RAの併用も可能なようですが、故障検知のタイミングによって動作的におかしくなる時があるようです。
(CLIファイルを１つにまとめると、CLIファイルの投入時にクラスタ構成が完了しないので注意が必要）

また、試していませんが、VirtualDomain RAとremote RAも同様に設定自体は併用も可能だと思われます。
先に書いた通りで、故障検知のタイミングによって動作がおかしくなる為、現状は、このような設定は利用はしない方が良いでしょう。

```
property no-quorum-policy="ignore" \  stonith-enabled="true" \
  startup-fencing="false"

fencing_topology \
  remote1: Stonith1 \
  remote2: Stonith1

rsc_defaults resource-stickiness="INFINITY" \
  migration-threshold="1"

primitive Stonith1 stonith:fence_docker \
 params \
  pcmk_reboot_timeout="300" \
  pcmk_reboot_retries="1" \
  pcmk_host_list="remote1 remote2" \
  action="off" \
  ipaddr="127.0.0.1" \
  ipport="4243" \
  api_version="1.12" \
 op start interval="0s" timeout="60s" on-fail="restart" \
 op monitor interval="3600s" timeout="60s" on-fail="restart" \
 op stop interval="0s" timeout="60s" on-fail="ignore"

primitive container1 ocf:heartbeat:docker \
  params \
        run_opts="-P -p 127.0.0.1:10001:3121 -v /etc/pacemaker:/etc/pacemaker" \
        run_cmd="/usr/sbin/pacemaker_remoted" \
        image="centos:remote2" \
        name="remote1" \
        op start interval="0s" timeout="90s" on-fail="restart" \
        op monitor interval="3s" timeout="30s" on-fail="restart" \
        op stop interval="0s" timeout="90s" on-fail="block"

primitive container2 ocf:heartbeat:docker \
  params \
        run_opts="-P -p 127.0.0.1:10002:3121 -v /etc/pacemaker:/etc/pacemaker" \
        run_cmd="/usr/sbin/pacemaker_remoted" \
        image="centos:remote2" \
        name="remote2" \
        op start interval="0s" timeout="90s" on-fail="restart" \
        op monitor interval="3s" timeout="30s" on-fail="restart" \
        op stop interval="0s" timeout="90s" on-fail="block"

location loc3 container1 resource-discovery="never" \
 rule -inf: #uname eq remote1 \
 rule -inf: #uname eq remote2
location loc4 container2 resource-discovery="never" \
 rule -inf: #uname eq remote1 \
 rule -inf: #uname eq remote2
```

```
primitive remote1 ocf:pacemaker:remote \
  params \
        server="remote-node1" \
        port=10001 \
        op monitor interval="3s" timeout="30s" on-fail="restart" \

primitive remote2 ocf:pacemaker:remote \
  params \
        server="remote-node2" \
        port=10002 \
        op monitor interval="3s" timeout="30s" on-fail="restart" \

primitive dummy-remote Dummy \
  op start interval=0s timeout=60s \
  op monitor interval=30s timeout=60s \
  op stop interval=0s timeout=60s on-fail="fence"

location loc1 dummy-remote \
 rule 300: #uname eq remote1 \
 rule 200: #uname eq remote2

location loc2 dummy-remote resource-discovery="never" \
 rule -inf: #uname eq cent7-host

order rsc-order-1 inf: container1 remote1
order rsc-order-2 inf: container2 remote2
order rsc-order-3 inf: remote1 dummy-remote
order rsc-order-4 inf: remote2 dummy-remote
```

以下に上記のCLIファイルを投入すると...

```
[root@cent7-host ~]# crm_mon -1 -Af
(snip)

Online: [ cent7-host ]
RemoteOnline: [ remote1 remote2 ]

 Stonith1       (stonith:fence_docker): Started cent7-host
 container1     (ocf::heartbeat:docker):        Started cent7-host
 container2     (ocf::heartbeat:docker):        Started cent7-host
 dummy-remote   (ocf::heartbeat:Dummy): Started remote1
 remote1        (ocf::pacemaker:remote):        Started cent7-host
 remote2        (ocf::pacemaker:remote):        Started cent7-host

Node Attributes:
* Node cent7-host:
* Node remote1:
* Node remote2:

Migration Summary:
* Node cent7-host:
* Node remote1:
* Node remote2:
```

クラスタ構成後に、remote1のコンテナに入って、dummy-remoteで停止故障を起こした後の様子を示します。
dummy-remote故障後にremote1コンテナに対して、STONITHが実行された為、その後、container1,remote1のRAでもmonitorエラーが起きていますが、remote2にdummy-remoteはフェイルオーバーしています。

```
[root@cent7-host ~]# crm_mon -1 -Af
(snip)
Online: [ cent7-host ]
RemoteOnline: [ remote2 ]
RemoteOFFLINE: [ remote1 ]

 Stonith1       (stonith:fence_docker): Started cent7-host
 container2     (ocf::heartbeat:docker):        Started cent7-host
 dummy-remote   (ocf::heartbeat:Dummy): Started remote2
 remote2        (ocf::pacemaker:remote):        Started cent7-host

Node Attributes:
* Node cent7-host:
* Node remote2:

Migration Summary:
* Node cent7-host:
   container1: migration-threshold=1 fail-count=1 last-failure='Wed Nov  4 17:33:23 2015'
   remote1: migration-threshold=1 fail-count=1 last-failure='Wed Nov  4 17:33:21 2015'
* Node remote2:

Failed Actions:
* container1_monitor_3000 on cent7-host 'not running' (7): call=18, status=complete, exitreason='none',
    last-rc-change='Wed Nov  4 17:33:22 2015', queued=0ms, exec=0ms
* remote1_monitor_3000 on cent7-host 'unknown error' (1): call=5, status=Error, exitreason='none',
    last-rc-change='Wed Nov  4 17:33:21 2015', queued=0ms, exec=0ms

```