リソースが起動しない

16.04 から 18.04 へのバージョンアップは実施できたけど、pacemaker のリソースが起動しない。
stonith は起動しているようなんだけど、リソースが起動しなきゃクラスタにならないじゃん。

で、corosync.log を見てみると、どうも stonith(fence_scsi) でエラー出している様子。
pcs status だと起動しているように見えるので、問題無いかと思っていたんだけど、もともと 16.04 時代の設定も誤っていたんじゃないか？で、偶然上手く動いていた、と。

というわけで、stonith(fence_scsi) の設定を見直してみる。

そもそも、pcmk_host_list って必要なのか？

$ sudo pcs stonith update scsi-fence pcmk_host_list=
$ sudo pcs stonith show scsi-fence
$ sudo pcs status --full

ダメだ。

nodenameは？

$ sudo pcs stonith update scsi-fence nodename=
$ sudo pcs stonith show scsi-fence
$ sudo pcs status --full

上がってきた…。

どうやら、fence_scsi で全ノードを管理する場合は、pcmk_host_list も nodename も未設定で良かったらしい…。
オプションパラメータをきちんとチェックしないとアカンなぁ…。

この後分かったんだが、pcmk_host_list は設定していないとアカンらしい。
ん…？もしかして pcmk って pacemaker のことか？
というわけで再設定する。

$ sudo pcs stonith show scsi-fence
$ sudo pcs stonith update scsi-fence pcmk_host_list="sagittarius aquarius"
$ sudo pcs stonith show scsi-fence

あと、corosync.log を見ていたら、 Startup probes: disabled (dangerous) という記載があった。以前、enable-startup-probes を false に設定していたが、これも誤りのようだ。
元に戻しておこう。

$ sudo pcs property set enable-startup-probes=
$ sudo pcs property show --all | grep enable-startup-probes

stonith 関連の設定が問題だったので、幾つかテストしてみる。
まずは普通にクラスタの起動停止

$ sudo pcs cluster stop --all
$ sudo pcs cluster start --all
$ sudo pcs status --full

問題なしだ。

続いて、片方のノードのクラスタ停止起動

(sagittarius) $ sudo pcs cluster stop aquarius
(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs cluster start aquarius
(sagittarius) $ sudo pcs status --full

問題なし。

(aquarius) $ sudo pcs cluster stop sagittarius
(aquarius) $ sudo pcs status --full
(aquarius) $ sudo pcs cluster start sagittarius
(aquarius) $ sudo pcs status --full

問題無いようだ。

今度は、ノード自体の再起動だ。
その前に、以前設定した tmpfiles の設定を削除してみよう。fence_scsi の設定が誤っていたことが原因なのかもしれないので。

$ cat /etc/tmpfiles.d/var-run.conf
$ sudo rm /etc/tmpfiles.d/var-run.conf
(aquarius) $ sudo systemctl reboot
(sagittarius) $ sudo pcs status --full

おっといけない。まだクラスタの自動起動を設定していないんだった。
手で起動する。

(aquarius) $ sudo pcs cluster start aquarius
(sagittarius) $ sudo pcs status --full

問題なさげだ。(tmpfiles の /var/run/cluster も自動生成されてる)

さて…次は鬼門。vm-leo が稼働したままの sagittarius を再起動させるパターンだ。

(sagittarius) $ sudo systemctl reboot
(aquarius) $ sudo pcs status --full

やっぱり、sagittarius の停止に詰まる症状が出る。
sagittarius のコンソールを見ている限り、vm-leo が停止し切る前にその他のリソースが停止しようとしてエラーとなり、それが原因で libvirt や iscsi-initiater の停止が上手く行かず、強制停止が完了するまでリブートしない、という状態のようだ。
この辺りは、リソース停止のタイムアウト値を設定したりすれば解決しそうだ。
ただ、これまではこの症状が起きると、aquarius 側の dlm もハングしてしまい、aquarius も再起動させないと復旧しなかった。
今回は、aquarius は正常稼働している。この辺りが、fence_scsi の設定を見直した結果か。

(sagittarius) $ sudo pcs cluster start sagittarius

う～ん。なんとか起動してきたな。
vm-leo が停止するのに必要なタイムアウト設定は別途調べることにしよう。
vm-leo はオンラインマイグレーションさせる方法も調べて実装しておきたいし。

続いて、フェンシングとアンフェンシングのテストをやってみる。
sagittarius から aquarius をフェンシング

(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs stonith fence aquarius
(sagittarius) $ sudo pcs status --full

クラスタから aquarius が切り離され、aquarius 上の pacemaker プロセスがダウンした。ん？ corosync は起動しているぞ…？
この時点で気になるのは、stonith(scsi-fence) が sagittarius 上で動いていない、という点。aquarius をシャットダウンさせた時は、scsi-fence は sagittarius 上で動き出したのだが…。
一旦、aquarius 上の corosync を止めてみるか…。

(aquarius) $ sudo systemctl stop corosync
(sagittarius) $ sudo pcs status

あー、aquarius 上の corosync を停止させたら、scsi-fence が sagittarius 上で動き出した。そーゆーことか。
一旦この状態で、sagittarius を再起動させてみたい。一応、クラスタは正常終了させてからね。

(sagittarius) $ sudo pcs cluster stop sagittarius --force
(sagittarius) $ sudo systemctl reboot

リブートしてきたら、クラスタが( sgaittarius 単独で)起動するか確認だ。

(sagittarius) $ sudo pcs cluster start sagittarius
(sagittarius) $ sudo pcs status

sagittarius 上で起動してきたな。

fence された aquarius は、プロセスが中途半端の状態のはずなので、きっちり再起動させておこう。

(aquarius) $ sudo systemctl reboot

むぅ。停止処理に時間がかかってるな…。fence されたことで、プロセス状態が半端な状態になっているのが原因か。
いや、どうやら停止処理がハングしたようだ…。一旦強制的に(物理的に)電源Off/ONしよう。
pacemaker プロセスを systemctl で停止させたのが問題だったのかもしれない。
aquarius が起動してきたらクラスタを起動させ、もう一度同じことを実施してみる。

(aquarius) $ sudo pcs cluster start aquarius
$ sudo pcs status
(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs stonith fence aquarius
(sagittarius) $ sudo pcs status --full

aquarius からクラスタの停止は…？

(aquarius) $ sudo pcs cluster stop aquarius

う～ん…。それっぽい動きはしたが、dlm プロセスが中途半端だ…。
クラスタ起動は…？

(aquarius) $ sudo pcs cluster start aquarius

ダメだな…。
イマイチ対応方法が良くわからない。リブートさせて復旧させるけど、--force のオプションをつけよう。

(aquarius) $ sudo systemctl reboot --force

かなり時間はかかるが起動してくるはずだ。
再びクラスタに組み入れておこう。

(aquarius) $ sudo pcs cluster start aquarius

fence されたノードは、再起動させないと復旧出来ないような記載を何処かで見かけたので、--force で再起動させるしかないか。オプションつけ忘れると、再起動がハングするという最悪の自体になるので、何か他に方法はありそうだが…。

よく考えてみたら、stonith の説明は主に UPS や IPMI による強制停止・強制再起動が中心だ。ってことは、fence 発生時は相手方は強制的に電源が落ちる(or再起動する)ことが前提になっていて、今回採用しているような fence_scsi はある意味例外なのかもしれない。
であれば、再起動に手間がかかるのは、例外として受け入れるしか無いのかな？

まぁ、当初の目的であった「リソースが起動しない」という問題は解決したから、これでヨシとするか。

fence_scsi がコケる

リソースの再起動問題は解決したと思ったんだけど、次の作業である「ノード再起動で dlm がハング」を調査しようとしたら…クラスタ起動時に fence_scsi(scsi-fenceデバイス)がコケる、という事象が発生した。

調べて行ったら、前回行った作業( sudo pcs property set enable-startup-probes=false )で、scsi-fence デバイスの.keyファイル等が自動作成されなくなった、というのが原因。

一度試してみると分かる。

$ sudo pcs status

vm-leo が aquarius で稼働していないことを確認。
続いて、aquarius のクラスタを再起動させる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

この状態では、問題なく aquarius がクラスタ参加するはずだ。
では、aquarius を OSごと再起動させてみよう。

$ sudo pcs cluster stop aquarius
(aquarius) $ sudo systemctl reboot

リブート後…

$ sudo pcs status

scsi-fence デバイスが aquarius 上で起動失敗、sagittarius で起動しているはずだ。
これは、/var/run/cluster にあるはずの fence_scsi.dev と fence_scsi.key ファイルが再作成されていないことが原因。
今まではクラスタ起動時に自動的に作成されていたようだから、問題なかった。
とりあえずこのままではよろしく無いので、再作成しておこう。

(aquarius) $ sudo fence_scsi -n aquarius -d /dev/mapper/fence-device  -o on

これで、/var/run/cluster にファイルが作成されたはずだ。

ただ、クラスタ上は aquarius 上で scsi-fence の起動に失敗した、という情報が残っているので、それもクリアしておこう。

$ sudo pcs stonith cleanup scsi-fence

これで一旦復旧。

さて、原因と対策なんだけど…。
調べたけどさっぱり分からない。ただなんとなく、Ubuntu18.04にバージョンアップしたら解決してる気がする。
なので、この先18.04にバージョンアップしてから再確認しよう。
それまでは、上に記載した暫定対処で回避することにする。

fence-agent のインストールと設定

dlm を使用するのなら、stonith/fence の設定が必須らしい。参ったな。
というわけで、インストールと設定を行おう。

$ sudo apt-get update
$ sudo apt-get install fence-agents

さて、フェンスデバイスだが…、今回使用している環境は、ベアメタル、所謂物理マシンだ。
しかも普通のPCで、IPMIは搭載していない。UPSに繋いでいるわけでもない。
使えそうなのは

• fence_mpath
• fence_sbd
• fence_scsi

あたりか…。ubuntu 1604 だと、fence_sbd は使えなかったような気がする…。

となると、fence_scsi か fence_mpath だけど、こちらはほぼ同じモノのようだ。
使うデバイスは、SCSI-3 PR(Persistend Reservation)に対応した共有ディスク。
iSCSI や FCデバイスだけど、家で FCデバイス なんて運用していない。
また、multipathd を動かしているので、fence_mpath を使うことになると思うのだが…。
fence_mpath は fence_scsi と違い、keyパラメータを指定する必要がある。
が…、「ノードごとに固有に設定」なのに、pcs stonith create で一発指定…。ノードごとにどうやって指定するのか分からない…。
デバイスは multipath にしておいて、stonith は fence_scsi でやってみるか。

しょうがないので、iSCSIストレージから、1GBの共有ディスクを追加する。混乱しないように「fence-device」とでも名付けておくか。

dmesg で確認すると sagittarius で /dev/sdk 、aquarius で /dev/sdi というデバイスで認識された。
(sagittarius) $ sudo multipath -a /dev/sdk
wwid が見える。(今回は 23166363164363639 だった)
(sagittarius) $ sudo vi /etc/multipath/bindings
-----
見つかったwwidを追加する。
fence-device 23166363164363639
-----
(sagittarius) $ sudo multipath -r /dev/sdk
これで、/dev/mapper/fence-device として認識されたはずだ。

aquarius でも同様に。
(aquarius) $ sudo multipath -a /dev/sdi
(aquarius) $ sudo vi /etc/multipath/bindings
-----
wwidの追加
fence-device 23166363164363639
-----
(aquarius) $ sudo multipath -r /dev/sdi

そうしたら、stonith/fence の設定だ。
fence_scsi は、デフォルトでは /var/run/cluster ディレクトリの下に情報を書き込む。
ところが、/var/run は tmpfs で、OS再起動のたびに中身が綺麗サッパリ消えてしまう。
そのため、/var/run/cluster というディレクトリそのものも消えてしまい、fence_scsi がファイルを作成するのに失敗してしまう。

/var/run 以下は tmpfiles という仕組みによって、OS起動時に作成してくれるのだが、そのための設定ファイルが漏れている。
もしかしたら、Ubuntu1604のバグで、Ubuntu1804なら解決しているのかもしれないが…。

というわけで、OS起動時に /var/run/cluster ディレクトリが作成されるように設定ファイルを作っておく。
細かいところや配置ディレクトリは個別に調べてもらうとして、sagittarius/aquarius で以下のように実行。
$ sudo vi /etc/tmpfiles.d/var-run.conf
-----中身は以下の1行
d /var/run/cluster - - - -
-----
これを作成したら、OS再起動して反映させよう。
$ sudo systemctl reboot
$ ls -ld /var/run/cluster
ディレクトリが作成されているはずだ。

やっと準備が出来た。stonith/fence の作成だ。
(sagittarius) $ sudo pcs stonith create scsi-fence fence_scsi \
  pcmk_host_list="sagittarius aquarius" \
  devices=/dev/mapper/fence-device \
  verbose \
  meta provides=unfencing

$ sudo pcs status
いきなり scsi-fence が動き出したと思う。
＃動いていなければ、sudo pcs resource cleanup scsi-fence 等でクリーンアップしよう。

scsi-fence は、稼働しているノードがダウンしたら、もう片方のノードで動き出すはずだ。
sagittarius/aquarius を交互にリブートしてみて、sudo pcs status で確認してみよう。
問題なく動いていたら、stonith/fence の完成だ。

これでようやくリソースの作成に入れるかな？

2ノード構成で両ノードでサービス稼働なのでstonithを捨てる

今回のgemini/cancerの構成は、2ノードで両方でgfs2をマウントする、という構成。
なので、そもそもstonithを稼働させる必要は無いのでは？
ということを調べてみたら、stonith自体を無効化させることが出来ることが分かった。

stonithが有効だと、stonithで定義したfence-deviceが有効にならないと、リソースが起動しない。
無理やり、シングルノードでfence-deviceを有効にする必要も無いので、無効にしてしまう。
無効の仕方は以下の通り。
クラスタのプロパティ確認。
sudo pcs property show --all
そもそも、--allをつけないと全パラメータが確認できないなんて…。
stonith-enabledがtrueになっていると思う。
ちなみに、最初にクラスタを作った時に指定したno-quorum-policyもfreezeに設定されているのが分かる。

stonithを無効化する。
sudo pcs property set stonith-enabled=false
確認。
sudo pcs property show --all

これでクラスタの状態を見てみると…fence-deviceは動いているな…。
クラスタを再起動させてみよう。
sudo pcs cluster stop --all
sudo pcs cluster start --all

あれ？今度は dlm が起動しなくなった…。これは一体…？？？

う～ん。dlmを動かすためには、stonithの設定は必須みたいだ…。
元に戻そう。
sudo pcs property set stonith-enabled=true
sudo pcs cluster stop --all
sudo pcs cluster start --all

dlmリソースのパラメータに「allow_stonith_disabled」というのがあった。
これをtrueに設定してみたが…、やっぱりダメっぽいな。

う～ん…。dlmの制御がネックだなぁ…。
問題になっているのは、dlm不意にが対向ノードと通信できなくなった時、dlmがダウンしてしまうってことなんだよなぁ。
これを解決できれば、全て通ると思うんだけど…。

とりあえずリソース作ってみる

pacemaker が起動したので、今度は リソース を作ってみる。

pacemaker ってのは、その上で動かす(クラスタ制御下に置く)サービス(例えばデータベースサービス)とかを、リソースと呼ばれる単位の集まりで制御している。
意味がわからんね。

HAクラスタを実現するためには、大きく3つの物を制御する必要がある。

1. サービス用IPアドレス
2. サービス用ディスク
3. サービスプロセス

例えばデータベースをクラスタ化する場合、

• クライアントからアクセスを受け付けるIPアドレス
  サービスを提供する方のノード(サーバ)に、このIPアドレスを付与する。
• データやプログラムが入っているディスク
  サービスを提供する方のノード(サーバ)で、このディスクをマウントする。
• データベースプロセスそのもの
  上の2つが整ったら、データベースを起動する

という感じだ。
(これら3要素のうち、幾つかを必要としないサービスも存在する)

で、pacemaker では、これらの要素1つ1つを「リソース」として登録し、リソースの組み合わせでサービスを提供する形になっている。

あくまでとりあえず、1つリソースを登録してみる。
IPアドレスが簡単かな？

登録は crm コマンドを使用する。
また、リソースは resource agent (ra)というキットに用意されているものを使用するのがラクだ。(自分で作ることも出来るけど、それはまた後日…)
というわけで、ra の確認だが…。
ra はクラスごとに分けられている。
まずは、クラスの一覧を確認してみよう。
(gemini) $ crm ra classes
lsb
ocf / .isolation heartbeat lvm2 pacemaker redhat
service
stonith
systemd
5個出てきた。
それぞれ、
lsb : linux standard base (/etc/init.d のスクリプトだ)
ocf : Open Cluster Framework 準拠のサービス
service : service コマンドで起動停止する対象のサービス
stonith : stonith 専用の処理
systemd : systemd のルールに則ったサービス
という意味だ。うん。さっぱり分からんね。

殆どは ocf クラスに定義されていると思っていい。
ただ、今まで /etc/init.d や systemd によって起動停止していたサービスを pacemaker によってクラスタ化する、というのであれば、lsb や systemd 等のクラスに定義されているはずだ。

IPアドレスは ocf に定義されているが、一応リストを見てみよう。
(gemini) $ crm ra list lsb
(gemini) $ crm ra list ocf
(gemini) $ crm ra list service
(gemini) $ crm ra list stonith
(gemini) $ crm ra list systemd

たくさん出てきたと思うが、ocf の中に IPaddr、IPaddr2、IPsrcaddr、IPv6addr というソレっぽいのが見つかったと思う。
答えから言ってしまうと IPaddr2 が今回使用する ra だが、これらの詳細を確認するコマンドも実行しておこう。
(gemini) $ crm ra info ocf:IPaddr
(gemini) $ crm ra info ocf:IPaddr2
(gemini) $ crm ra info ocf:IPsrcaddr
(gemini) $ crm ra info ocf:IPv6addr

ざっと見ても分かる通り、IPaddr2 が Linux 専用に用意された ra だ。
専用というぐらいだから、これを使うのがいいだろう。

パラメータは…
ip
nic
cidr_netmask
broadcast
iflabel
lvs_support
lvs_ipv6_addrlabel
lvs_ipv6_addrlabel_value
mac
clusterip_hash
unique_clone_address
arp_interval
arp_count
arp_bg
arp_mac
arp_sender
flush_routes
だ。(結構あるな…)
さらに、オペレーションデフォルト値として、
start timeout=20s
stop timeout=20s
status timeout=20s intervals=10s
monitor timeout=20s intervals=10s
とある。
まぁ、必須なのは最初の ip だけなので、これだけ指定して作ってみよう。

(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
おっと！
ERROR: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
   error: unpack_resources:     Either configure some or disable STONITH with the stonith-enabled option
   error: unpack_resources:     NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
Do you still want to commit (y/n)?
というエラーが出た。
とりあえず、最後の質問には n と答えておく。

どうやら、stonith の設定を施すか、stonith 自体を無効化しておく必要があるようだ。

stonith ってのは、どうやら対向ノードが完全クラッシュではなく、中途半端に止まってしまった時に、強制的に再起動等を実施する仕組みのようだ。
今回、gemini / cancer でクラスタにしないサービスも稼働させるツモリなので、再起動はしないようにしておきたい。
なので、stonith を無効にする。
無効にするには、stonith として null を使用するか、stonith 自体を無効化するようだ。
null を使用するのはあくまでテスト目的のようだが、今回は敢えて null を使用してみたい。

まずは stonith の一覧確認。
(gemini) $ crm ra list stonith
たくさん出てくるが、null というのがあるか確認しておく。

stonith:null の詳細確認。
(gemini) $ crm ra info stonith:null

実際に設定してみる。
(ココでは、stonith2gemini というのが gemini 障害時に gemini を強制再起動させるリソース、stonith2cancer というのを cancer 障害時に cancer を強制再起動させるリソースとして想定している。null エージェントなので、実際には何も起きないはずだが。)
(gemini) $ sudo crm configure primitive stonith2gemini \
stonith:null \
params \
hostlist="gemini"
(gemini) $ sudo crm configure primitive stonith2cancer \
stonith:null \
params \
hostlist="cancer"
を？すんなり通った。

出来たのだろうか…？
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon
動いているようだ。

ただこのままでは、stonith2gemini が gemini で、stonith2cancer が cancer で稼働してしまうかもしれない。
そのため、リソースが稼働するサーバ(ノード)を固定させる必要がある。

どうやら、 location という定義で指定できるようだ。
(gemini) $ sudo crm configure help location
ヘルプを見てみると、どうやら以下のような記述でリソース稼働を固定させることが出来るようだ。
location ＜識別子＞ ＜リソース名＞ \
rule 100: #uname eq ＜リソースを動かしたいノード名＞ \
rule -INFINITY: #uname eq ＜リソースを動かしたくないノード名＞
＃-INFINITY は -inf と書くことも出来るみたいだ。

これを実際に適用するコマンドは以下の通り。
(gemini) $ sudo crm configure \
location stonith2gemini_loc stonith2gemini \
rule 100: \#uname eq cancer \
rule -inf: \#uname eq gemini
(gemini) $ sudo crm configure \
location stonith2cancer_loc stonith2cancer \
rule 100: \#uname eq gemini \
rule -inf: \#uname eq cancer
＃コマンドラインから実行する場合、 #uname でシェルのコメントになってしまう。
＃そのため、 \ でコメントを無効化しよう。

出来上がったか確認。
(gemini) $ sudo crm_mon -A
(gemini) $ sudo crm configure show

設定は出来たっぽい。

さて、とりあえずこの2つ、起動停止してみたい。(単なるリソースだから、起動停止できるはず…)
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm resource stop stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
止まったっぽい。
今度は起動。
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm resource start stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
ちゃんと起動したっぽい。

起動停止させると、それぞれの syslog にも記録される。
これ、強制的にノードを指定して起動させるコマンドは無いのだろうか？
(対向ノードでは起動しない設定(-inf)なので、ノード指定の起動はエラーになるはず…)

う～ん。調べてみても、リソースを起動する時に、ノードを指定する方法が見当たらない。起動しているリソースを、他のノードに移動させる、というコマンドなら用意されているようだ。
それが resource migrate コマンドのようだ。(crm help resource migrate で簡単なオプションが表示される)
試してみよう。
(gemini) $ sudo crm status --verbose
stonith2gemini が cancer 上で動いており、stonith2cancer が gemni 上で動いているのが分かる。

では、stonith2gemini を gemini 上に移動させてみよう。(移動出来ないのが正解のはずだ。)
(gemini) $ sudo crm resource migrate stonith2gemini gemini
…何もエラーは起きない。

どうなっただろうか。
(gemini) $ sudo crm status --verbose
おや？何も変化していないぞ？
いや、変化しないことが正解なんだけど…。何もメッセージが出ていないのはちょっと気持ち悪いな。

ただ、クラスタ定義に1つエントリが追加されているのに気付いた。
(gemini) $ sudo crm configure show
--
前略
location cli-prefer-stonith2gemini stonith2gemini role=Started inf: gemini
後略
--
だ。
これを見ると、stonith2gemini は gemini で動く、という定義に見えるが…。

この状態でリソースを停止→起動してみるとどうなるだろうか？
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
やっぱりリソースは cancer で動いているし、謎の location エントリは消えていない。
これが正しい動作なのだろうか…。

とりあえず、謎の location エントリは削除しておこう。
migrate で現れたステータスなので、消すのは unmigrate だ。
(gemini) $ sudo crm resource unmigrate stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
元に戻った。

とりあえず、ダミーの stonith リソースは出来た。
一旦仕切り直して、IPアドレスのリソースを作ってみよう。

最初の方で警告が出たコマンドを実行してみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
今度はすんなり通った。

状態を確認してみる。
(gemini) $ sudo crm configure show
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
testip リソースは cancer で動き出したな。
(何故か、cancer で優先的に動く。この辺りは何か理由があるんだろうけど、location 定義で制御するのが正しいんだろうな。)

とりあえず、cancer で IPアドレス が付与されているはずなので確認してみよう。
(cancer) $ ip address show
cancer で 192.168.55.155 が付与されたのが確認できた。

gemini から疎通確認。
(gemini) $ ping -c 5 192.168.55.155
ちゃんと応答がある。

では、cancer で動き出したリソースを、他のノード(今回は gemini しかいないので gemini )へ移動させてみよう。
(gemini) $ sudo crm resource migrate testip
(gemini) $ sudo crm status show
(gemini) $ sudo ip address show
(cancer) $ sudo ip address show
192.168.55.155 の IPアドレス は、無事に gemini に移動した。

この状態で configure を見てみると…
(gemini) $ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリが追加されている。
これ、よく見てみると -inf: cancer となっていて、このリソースはもう cancer では動かせない、という定義だ。

pacemaker で primtive リソースとして定義されたリソースは、migrate させると、元のノード(先程の例では cancer )がダウンしたものとして、そのリソースは cancer には戻らないようになるようだ。
この辺り、クラスタ定義かリソース定義で変更出来ると思うけど、別途調査しないと分からない。

そのため、もう一回この testip リソースを migrate しようとすると、移動先のノードが無いため、リソース自身が停止してしまう。

もう少しこのリソースを元に調査をしたいが、今回はここまでにしよう。
(ちょっと長すぎたかな？)
一旦、リソースは元に戻しておく。
(gemini) $ sudo crm resource unmigrate testip

というわけで一旦終了。

pacemaker を入れよう

というわけで、HA クラスタソフトを入れる。
とは言え、ドレがいいのか分からないので、ここでは定番とも言える pacemaker にしよう。
対象は gemini / cancer だ。
$ sudo apt-get update
$ sudo apt-get --simulate install pacemaker
$ sudo apt-get install pacemaker

インストールが終わったら起動してみる。(基本設定してないけど…。)
(gemini) $ sudo systemctl start pacemaker
(gemini) $ systemctl --no-pager -l status pacemaker
Stonith 関係のエラーが出てる。

(gemini) $ ps -ef | grep pacemaker | grep -v grep
起動はしているようだ。

cancer も…。
(cancer) $ sudo systemctl start pacemaker
(cancer) $ systemctl --no-pager -l status pacemaker
あれ？Stonith 関連のエラーは出てこなかった…。

(cancer) $ ps -ef | grep pacemaker | grep -v grep
こちらも、起動はしているようだ。

pacemaker は、crm というコマンドを通して操作を行うようだ。
まずはステータスを見てみよう。
$ sudo crm status --verbose
どうやら、過去に構築した corosync を通して、ノード間の通信と Online 状態であることは確認できているみたいだ。
ただ、STONITHリソースが定義出来ていないので、他のリソースが起動できないよ、という警告が。っても、何のリソースも定義していないのだが…。

この後、Stonith を含む基本設定を施すことになるのだが、設定を施す前に、今どのような設定になっているかを確認しておこう。
クラスタ全体の Property 一覧は、crm の configure show_property で出力出来る。
$ sudo crm configure show_property
ただコレは、設定可能な項目の一覧なので、各項目にどのような値が設定されているか分からない。
設定されている値は、先程のコマンドの後ろに、設定項目名を入れると分かる。
例えば…
$ sudo crm configure show_property stop-orphan-resources
true
この stop-orphan-resouces というパラメータは、true が設定されている、ということだ。
一度、全部洗い出しておこう。

#	項目名	値	備考
1	stop-orphan-resources	true
2	dc-deadtime	20s
3	placement-strategy	default
4	symmetric-cluster	true
5	maintenance-mode	false
6	default-action-timeout	20s
7	node-health-yellow	0
8	start-failure-is-fatal	true
9	shutdown-escalation	20min
10	stop-all-resources	false
11	no-quorum-policy	stop
12	dc-version	1.1.14-70404b0
13	startup-fencing	true
14	stonith-enabled	true
15	pe-input-series-max	4000
16	stonith-action	reboot
17	pe-error-series-max	-1
18	is-managed-default	true
19	node-health-red	-INFINITY
20	remove-after-stop	false
21	crmd-transition-delay	0s
22	election-timeout	2min
23	node-health-green	0
24	node-action-limit	0
25	stonith-timeout	60s
26	enable-acl	false
27	batch-limit	0
28	pe-warn-series-max	5000
29	enable-startup-probes	true
30	stop-orphan-actions	true
31	default-resource-stickiness	0
32	cluster-recheck-interval	15min
33	cluster-infrastructure	corosync
34	crmd-integration-timeout	3min
35	stonith-watchdog-timeout	(null)
36	crmd-finalization-timeout	30min
37	have-watchdog	false
38	migration-limit	-1
39	load-threshold	80%
40	node-health-strategy	none
41	cluster-delay	60s

デフォルト値が分かったが、どの値が何を意味しているのか分からない。
おいおい調査していくことにしよう。

逆に言うと、何をどう設定すれば何が起きるのか分からない。
なので、今はデフォルトのママにして、必要に応じて修正していくことにする。

次回は、ゲストOS(leo) をクラスタサービスにしてみる。(出来るのか？)