pacemaker ってのは、その上で動かす(クラスタ制御下に置く)サービス(例えばデータベースサービス)とかを、リソースと呼ばれる単位の集まりで制御している。
意味がわからんね。
HAクラスタを実現するためには、大きく3つの物を制御する必要がある。
- サービス用IPアドレス
- サービス用ディスク
- サービスプロセス
- クライアントからアクセスを受け付ける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
というわけで一旦終了。
