2017年8月2日水曜日

リソースの稼働先(優先度)を指定

前回、testip というリソースを作成した。

この testip 、起動時には gemini / cancer のいずれのノードで稼働するかは不定だ。
(どうも、cancer で起動しようとするようだ…。)

これを、
  • 通常時は gemini で稼働
  • gemini が停止している時は cancer で稼働
という具合に固定化させてみたい。

やり方はそんなに難しくない。
リソースの稼働優先度を付ければいい。
(前回、stonith リソースの稼働先を指定したコマンドとほぼ同じだ。)

まずは testip の停止
$ sudo crm resource show testip
$ sudo crm resource stop testip
$ sudo crm resource show testip

testip のリソースに対して、 gemini:100 cancer:50 の優先度をつける
$ sudo crm configure show
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
$ sudo crm configure show
$ sudo crm configure show testip_loc

これで、gemini の方が優先度が高くなったため、gemini が稼働中であれば、testip は gemini で起動してくるはずだ。
試してみよう。
$ sudo crm resource show testip
$ sudo crm resource start testip
$ sudo crm resource show testip

start / stop を繰り返してみたり、cancer のコマンドラインから start を仕掛けてみて、毎回必ず gemini 側で起動することを確認しよう。

gemini 側で起動することが確認できたら、手作業でフェイルオーバー(厳密にはテイクオーバー)させてみよう。
自動的に、cancer 側で動き出すはずだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
フェイルオーバーさせたら、
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
というルールが追加されたと思う。
前回の解説の通り、「このリソースは gemini では動かさないよ」というものだ。

この状態で、もう一度 migrate 仕掛けてみよう。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
testip は停止している。
$ sudo crm configure show
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
というルールも追加された。
gemini / cancer の2つしかノードが無いので、このルールによって、稼働可能なノードが無くなり、リソース停止になったわけだ。
#イメージとしては、gemini がシステムダウンをし、cancer 側でサービスを継続していたが、gemini を復旧させる前に cancer もダウンしてしまった、という状態だ。

さて、では元に戻すにはどうすればいい?
単純に起動させてみると…
$ sudo crm resource start testip
$ sudo crm resource show testip
動いていない。

やはり unmigrate なのだろうか?
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
おっと!gemini で動き出した。
状態は…?
$ sudo crm configure show
追加された2つのルールは削除されている。これによって gemini で稼働し始めたか。

さて今度は、本当に障害を発生させてみよう。
gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させてみる。
これで testip が cancer 側に移ってくれれば、期待した動きと言える。
(sagittarius) $ virsh destroy gemini

10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、例の「gemini では動かしちゃダメだよ」ルールが追加されていない。
crm migrate を実施した時と若干挙動が違うな…。そういうものなのか?

もしかして、gemini が復旧したら、リソースが自動的に gemini に戻る?
確認してみよう。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
なんと!?gemini 側に戻ってきている!

これはちょっとよろしく無いな…。
プライマリノードがダウンした場合、スレーブノード(待機系)で自動的にサービス再開する、というのはHAクラスタとしては理想の動き。
だけど、プライマリノードが復旧したら、サービスが自動的にプライマリノードに戻る、というのは良くない。
戻る時、スレーブノードでサービスが停止し、プライマリノードでサービスが起動する、という動きになるため、一時的にサービスが止まってしまう。
サービスが止まることが予め予想出来るのなら、業務影響の少ない夜間の特定時間帯に戻す、という要求が出て当然だ。
大抵の業務クラスタはそうなっている。
#自動フェイルバック禁止、というような表現だ。

さて、その自動フェイルバックを禁止する方法だけど…。
これについては次回にして、今回はココまでにしよう。

0 件のコメント:

コメントを投稿