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

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

というわけで一旦終了。