KVM仮想マシンをHAクラスタ化

さて、意味があるのか無いのか、KVM仮想マシンごと、クラスタ制御にしてみようと思う。
ここでネックになる課題は、分かっている限り以下の2つ。

• そもそも実現出来るの？
• ライブマイグレーション機能との相性は？

この辺りを含めて検証していきたい。

まずは仮想マシンの用意。
既に gemini / cancer 上には、leo と virgo の2つの仮想マシンが用意してある。
過去の検証で作成したものだ。
今回は、leo を使ってみよう。
作業前に、leo を起動して、ライブマイグレーションが可能かをチェックしておこう。
対象の仮想マシンが壊れていたら、HAクラスタ検証で問題が起きても切り分けが出来ない。
(gemini) $ virsh start leo
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(gemini) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(cancerのIP)/system \
--migrateuri tcp://(cancerのIP)/ \
--verbose
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(cancer) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(geminiのIP)/system \
--migrateuri tcp://(geminiのIP)/ \
--verbose
(cancer) $ virsh list --all
(gemini) $ virsh list --all
(leo) $ sudo systemctl poweroff
(gemini) $ virsh list --all

続いて、leo を1つのリソースとして、pacemaker に登録する。
使うリソースエージェントだけど…、どうやら ocf:vm.sh ってのがある。これのようだ。
(gemini) $ crm ra list ocf
(gemini) $ crm ra info ocf:vm.sh

info で出てきたオプションを頼りに、実際に登録してみる。
(gemini) $ sudo crm configure primitive vm-leo \
ocf:vm.sh \
params \
name=leo \
domain="geminiのIP cancerのIP" \
use_virsh=1
う～む。どう考えてもオプション少ないよなぁ。もっと設定しないとアカンと思うんだけど…。
WARNING: vm-leo: default timeout 20s for start is smaller than the advised 300
WARNING: vm-leo: default timeout 20s for stop is smaller than the advised 120
おっと！？ワーニングが出た。
タイムアウト値をチューニングする必要があったか。
それは別途実施しよう。

さて、どうなったかな？
(gemini) $ sudo crm configure show
ちゃんと定義が入ってる。
(gemini) $ sudo crm resouce show vm-leo
おっと、cancer 側で起動してるみたいだ。
(gemini) $ virsh list --all
(cancer) $ virsh list --all
確かに、cancer 側の leo が起動している。

さて…リソースを落とすと、どういう動きになるのだろうか？
leo を virt-viewer で見ておこう。
(cancer) $ virt-viewer vm-leo &
この状態でリソースを落としてみる。
(gemini) $ sudo crm resource stop vm-leo
gemini からでも実行できた。
普通にシャットダウンのシグナルが飛んでるようだ。

今度は、leo の内側からシャットダウンしてみよう。
この場合、pacemaker が「リソースが落ちた」と判断してリソース起動をし始めるのか、「正常停止」と見なすのか？どっちだろうか？
明示的に leo を止めているので、本来なら後者の正常停止なのだが…。

というわけで実践。
(gemini) $ sudo crm resource show vm-leo
(gemini) $ sudo crm resource start vm-leo
(cancer) $ virsh list --all
leo が起動したのを確認。
(cancer) $ virt-viewer leo &
leo のコンソールにログインして、シャットダウンしよう。
(leo) $ sudo systemctl poweroff
結果、どうなったかな…？
(gemini) $ virsh list --all
(cancer) $ virsh list --all
仮想マシンは停止している…。
(gemini) $ sudo crm resource show vm-leo
んっ！？リソース vm-leo は相変わらず cancer 上で動いていることになってるぞ！？
これはモニター機能が働いてないってことか？違うかも。

とりあえず leo を起動させ、リソースから停止しておく。
(cancer) $ virsh start leo
(gemini) $ sudo crm resource stop vm-leo
(gemini) $ sudo crm resouce show vm-leo

OS側から正規に停止したのがダメだったのかもしれない。
というわけで、ホントに障害を想定して、仮想マシンleo のプロセスを殺してみよう。
まずは起動。
(gemini) $ sudo crm resource start vm-leo
(gemini) $ sudo crm resource show vm-leo
(cancer) $ virsh list --all

cancer で稼働している leo のプロセスを確認してみよう。
(cancer) $ ps -ef | grep leo | grep -v grep
今回はプロセスID 5639 だった。
これを殺してみる。
(cancer) $ sudo kill 5639
(cancer) $ ps -ef | grep 5639 | grep -v grep
落ちた。
リソースは…？
(gemini) $ sudo crm resource show vm-leo
(cancer) $ sudo crm resource show vm-leo
あれ？cancer で動いていることになってるぞ…？
(cancer) $ virsh list --all
仮想マシンは停止している…。何故だ？

う～ん。
cancer ごと落としてみるか…。
まずは leo を起動しておく。
(cancer) $ virsh start leo
(cancer) $ virsh list --all
leo が起動したのを確認したら、leo のホストマシンである cancer を強制停止してみる。
cancer は今、aquarius 上で稼働しているので、aquarius から落としてみよう。
(aquarius) $ virsh list --all
(aquarius) $ virsh destroy cancer
(aquarius) $ virsh list --all
停止したのを確認したら、gemini から vm-leo の状態を確認してみよう。
(gemini) $ sudo crm resource show vm-leo
む？リソース的には gemini で稼働したことになったぞ？
仮想マシンは？
(gemini) $ virsh list --all
こっちで稼働し始めたようだ。

ちなみに、リソース定義は…予想では「vm-leo は cancer では起動しないよ」という定義も追加されてない…はず…。
(gemini) $ sudo crm configure show
やっぱり追加されてない。
優先順位は付けてないから、この状態で cancer を復旧させたら…？
(aquarius) $ virsh start cancer
(aquarius) $ virsh list --all

(cancer) $ sudo crm resource show
Error signing on to the CIB service: Transport endpoint is not connected
あ、あれ？エラーになった…。
(cancer) $ systemctl status pacemaker
pacemaker が corosync と通信できずに落ちた…？
pacemaker 再起動してみよう。
(cancer) $ sudo systemctl restart pacemaker
(cancer) $ systemctl status pacemaker
これで大丈夫かな？
(cancer) $ sudo crm resource show
(cancer) $ sudo crm resource show vm-leo
ん？cancer で動き出した！？
(cancer) $ virsh list --all
(gemini) $ virsh list --all
やっぱり、cancer で動き出したぞ！？
どうやら、cancer の各種プロセスが正常起動してなかったようだ。

これは…「ノードダウン」と「リソースダウン」で挙動が違う。
整理しないと…。リソースダウンの挙動と設定がまだ掴めて無いから、もっと調査しないと…。
自動フェイルバックについても整理する必要がありそうだ。

う～ん。

作業用PC買い替え

先日、作業用のノートPCを買い替えた。
元々使っていたのは、acer Aspire One 752 というモデル。
これ、全然問題なく使えていて、バッテリーの持ちも悪くなかった。
だから、そのまま使い続けるツモリで、メモリも4GBへ増強し、HDD320GBからSSD240GBに換装してたんだ。
ホントに全然問題なかったんだけど、重さがカタログスペック上で1.38kgと少しヘビーだった。
なので、もう少し軽いのに買い換えようと思っていたら、安くて都合のいいのがあったので、それに買い替えたんだ。
新しく買ったのは、ASUS VivoBook E203NA。
これの Mem4GB / SSD64GB モデル。(色はピンクｗ)
カタログスペック上で、重量は900g。

買い換える前に店頭でチェックしてみたけど、キーボードも変態配列じゃなくて快適に入力出来るし、作業端末としては全然問題なさげ。
なんと値段は税込みで4万円弱。
こんなに安く手に入るのね…。

内蔵ストレージの容量が大幅減なんだけど、実際のところ、作業は全て自宅のタワーマシンとIntel NUCで処理していて、ノートPCはあくまでソレに繋ぐための端末。
だから、内蔵ストレージはそんなに必要無かった。
これに64GBのMicroSDを付けて、もう十分だった。
実際に導入したアプリケーションは…

• google Chrome
• google日本語入力
• teraterm
• putty
• VcXsrv
• Virt Viewer(32bit)
• UsbDk(64bit)
• 高機能テキストエディタ

ぐらいか。
で、Virt Viewer が64bit版ではなく32bit版なのは…。
暗号化ライブラリ関連だと思うんだけど、プリインストールされているアプリケーションと、Virt Viewer64bit版がバッティングするようで、Virt Viewerで仮想マシンのコンソールに接続しようとすると、Virt Viewerが落ちてしまう。
32bit版なら接続出来たので、とりあえず32bit版にしているところ。
UsbDkが64bit版なので、組み合わせ的に大丈夫か不明。

で、結構快適に使えている。
重量が300g以上削減できて、それでいてバッテリーの持ちは問題無さそう。
(WiFiグリグリ使い続けても、4時間以上稼働するっぽい)
で、強いて問題点を挙げるのなら…

• ケンジントンロックホールが無い
• 外部モニタ出力にD-Sub15pinが無い(HDMIのみ)
• 有線LAN(RJ45)が無い

と言ったトコロか…。
下2つはUSBで何とかなる(そもそも必要か？)。
ケンジントンロックホールに関しては、喫茶店や新幹線で作業中にトイレに行きたくなった時、結構重要。
まぁ軽いから、そのまま手に持ってトイレに行く、って形になりそうだ。

しかし、Aspire One 752 って、現時点で既に7年落ちだったのね…。全然問題なく使えてたから、そこまで古いモデルだとは思ってなかったよ…。

virt-viewer 6.0 がリリースされてたけど…

virt-viewer 6.0 がリリースされてた。
でも…
過去の接続リスト(Recent connections)が空になって、その後接続に成功してもリストに残らないという問題が…。
(だから、Recent connections がいつまで経っても空のままという…)
これがバグなのか、こちらのPCの問題なのかは不明だけど。

もしバグなら、virt-viewer 4.0 のリリースの時にもバグが含まれてた件に続いて2度目だ。
もう少しリリース管理きちんと出来ないかな…。

リソースの自動フェイルバック禁止設定

というわけで前回、リソースが稼働しているノード(gemini)を強制停止、リソースが対向ノード(cancer)へ自動フェイルオーバーすることを確認した。
その後、gemini を起動させたら、リソースが自動でフェイルバックしてしまった。
これはあまりよろしくない、ということで、自動フェイルバックはしないように設定してみたい。
これは、resouce-stickiness というパラメータで制御するようだ。
ただ、resource-agent(ra)固有のパラメータではなく、汎用パラメータのようで、crm ra info ocf:IPaddr2 では表示されない。
そのために探すのに時間がかかった。
他にも汎用パラメータはあるようだけど、とりあえずはコレだけ調べがついた。

取り急ぎ、設定を反映させる手順を。
手順としては2種類。

• 既に作成済みのリソース、iptest に対して設定を追加するやり方
• 一旦リソースを削除し、新たに作成するやり方

だ。
既に稼働中のシステムに対しては前者を使用することになるが、新たにリソースを作成するときには後者の知識があったほうが便利だ。
そのため、両方を試してみよう。

まずは前者、既に作成済みのリソースに対して設定を追加するやり方。
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
そんなパラメータ無い！と怒られる。
$ sudo crm resource meta testip set resource-stickiness INFINITY
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
設定できた。

果たしてこれでいいのだろうか？
前回と同じように試してみよう。

まずは手作業でフェイルオーバーだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
gemini で動いていた testip が cancer に移動した。

元に戻そう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
…あれ？戻らなかったぞ？
ちなみに
--
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
--
のエントリは消えた。

ということは、もう一回 migrate したら…？
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
ふぅむ。リソースは gemini に戻ってきたが、その代わりに
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
というエントリが追加されたか…。

もう一度 unmigrate してみよう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
gemini で稼働している状態で変化なし。
$ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリは無くなった。

なるほど…。migrate コマンドは、「当該ノードでは動かさないよ」マークを付けるだけの仕様なのか…。
ちょっと試してみよう。
(migrate コマンドではなく、直接 location を入れてみる)
$ sudo crm configure show
$ sudo crm resouce show testip
gemini で動いていることを確認して…
$ sudo crm configure location cli-ban-testip-on-gemini testip role=Started -inf: gemini
$ sudo crm configure show
$ sudo crm resource show testip
ふむ。やっぱり予想通り、testip リソースが cancer に移った。

なるほどねぇ。じゃぁこの状態で unmigrate したら…？
$ sudo crm resource unmigrate testip
$ sudo crm configure show
追加した location エントリは消えた。
$ sudo crm resource show testip
でも cancer で稼働し続けている。

だんだん見えてきた。

それじゃぁ今度は、実際の障害テストだ。
testip リソースを gemini に戻すが、面倒なので停止→起動の手順を踏む。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
ヨシ。

障害テストだ。
前回と同様、gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させる。
testip が cancer 側に移ってくるはずだ。
(sagittarius) $ virsh destroy gemini

やはり 10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、「gemini では動かしちゃダメだよ」ルールも追加されていない。
前回と同じ挙動だ。

ここで gemini を復旧させる。
前回は、testip リソースが勝手に gemini に戻ったが、今回は勝手に戻ることは無いはずだ。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
予想通り、cancer 側には戻ってきていない。
これが前回との差異か。

実際の障害→復旧の流れだと、この時点で gemini の H/W 及び OS の正常性確認を行った後、サービス(リソース)を gemini 側に移動させるのだけど、クラスタ製品によっては、「戻す」というオペレーションではなく、「サービスを停止→起動」というオペレーションになる。
pacemaker だとどうなんだろう？
migrate だと location 制約が出来てしまい、unmigrate だと移動まではしてくれない。
「障害からの復旧」だから、「サービス停止→起動」でいいんだろう。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
復旧オペレーションはこれでオシマイかな？

さて最後に「一旦リソースを削除し、新たに作成するやり方」方法を書いておく。
まずは当該リソースを停止
$ sudo crm resource stop testip
$ sudo crm resource show testip
$ sudo crm configure show

続いて、リソースを削除
$ sudo crm configure delete testip_loc
$ sudo crm configure delete testip
$ sudo crm configure show

自動フェイルバックを Off にしてリソースを作成
$ sudo crm configure primitive testip \
  ocf:heartbeat:IPaddr2 \
   params \
    ip="192.168.55.155" \
   meta \
    resource-stickiness="INFINITY"
$ sudo crm configure \
  location testip_loc testip \
    rule 100: \#uname eq gemini \
    rule  50: \#uname eq cancer

結果の確認
$ sudo crm resource show testip
(cancer で起動してしまったので、リソースを再起動)
$ sudo crm resource restart testip
$ sudo crm resource show testip
$ sudo crm configure show

出来た。
これでリソースの自動フェイルバック禁止はOKだ。

リソース定義は他にも色々細かい設定があるようだけど、IPリソースの定義はこのあたりにしておいて、次回は KVMゲストを HA クラスタのリソースとして定義してみようと思う。

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

前回、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クラスタとしては理想の動き。
だけど、プライマリノードが復旧したら、サービスが自動的にプライマリノードに戻る、というのは良くない。
戻る時、スレーブノードでサービスが停止し、プライマリノードでサービスが起動する、という動きになるため、一時的にサービスが止まってしまう。
サービスが止まることが予め予想出来るのなら、業務影響の少ない夜間の特定時間帯に戻す、という要求が出て当然だ。
大抵の業務クラスタはそうなっている。
＃自動フェイルバック禁止、というような表現だ。

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