各種リソース作成

さて、いよいよ大詰めだ。

各種リソースの作成、リソースの制約の付与、そして動作確認だ。
今回必要なのは、

• dlm
• clvmd
• gfs2マウント

の3つのはず。
で、依存関係としては…
dlm起動→clvmd起動→gfs2マウント
となる様子。
＃あれ？ってことはgfs2を使用しないクラスターLVMでも、dlmは必要なのか？
＃nfsクラスター構築時に検証してみよう。

まずはdlmリソースの作成
$ sudo pcs resource show
(sagittarius) $ sudo pcs resource create dlm \
  ocf:pacemaker:controld \
  op monitor \
       interval=30s \
       on-fail=fence \
     clone \
     interleave=true \
     ordered=true
$ sudo pcs resource show
リソースが出来たし、いきなり起動した。
詳細確認
$ sudo pcs resource show dlm-clone

sagittarius/aquarius どちらも ps コマンドで確認したら、dlm プロセスが動き出しているはずだ。

続いて、clvmdリソースの作成。
(sagittarius) $ sudo pcs resource create clvmd ocf:heartbeat:clvm \
  op monitor interval=30s on-fail=fence \
  clone \
  interleave=true \
  ordered=true
$ sudo pcs status
数秒後、sagittarius/aquarius 両ノードで clvmd-clone リソースが起動してくるはずだ。
$ ps -ef | grep clvmd | grep -v grep
プロセスも起動してくる。

clvmd-clone リソースを停止すれば、clvmdプロセスも落ちるはず。
$ sudo pcs resource disable clvmd-clone
$ sudo pcs status
$ ps -ef | grep clvmd | grep -v grep
$ sudo pcs resource enable clvmd-clone
$ sudo pcs status
$ ps -ef | grep clvmd | grep -v grep

clvmd-clone リソースの追加ができたので、dlm リソースとの順序と起動ノードの設定。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start dlm-clone then clvmd-clone
$ sudo pcs constraint colocation add clvmd-clone with dlm-clone
$ sudo pcs constraint show --full

そういえば、clvmd リソースが起動したら、過去に作ってあった共有ボリューム(kvmcluster VG)もアクティベートされたぞ。

そしたら、ファイルシステムマウントのリソース作成。
(sagittarius) $ sudo pcs resource create shared-pool Filesystem \
    device="/dev/kvmcluster/var-lib-libvirt" \
    directory="/var/lib/libvirt" \
    fstype="gfs2" \
    op monitor interval=10s on-fail=fence clone interleave=true
$ sudo pcs status
動き出した！
$ sudo pcs resource show shared-pool
$ df /var/lib/libvirt
両ノードでちゃんとマウントされた！

clvmdの時と同じように、順序と起動ノードの設定をしておこう。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start clvmd-clone then shared-pool-clone
$ sudo pcs constraint colocation add shared-pool-clone with clvmd-clone
$ sudo pcs constraint show --full

できた！

しかし、別の問題が発生。

次回はその問題の確認と対策だ…。結構メンドウだよ…。

2019/06/20 追記
ファイルシステムマウントのリソース、クローンリソース化するのなら、force_clones というパラメータを yes に設定しておく必要があるようだ。
実際のところ、違いがわからなかったんだけど、マニュアル上はそう書いてあるよう。
というわけで、設定を変更しておく。

$ sudo pcs resource update shared-pool force_clones=yes
$ sudo pcs resource show shared-pool

設定が反映されていれば OK だ。

dlm.conf の削除

dlm.conf はデフォルトのままで良いことが分かったので、このタイミングで消しておく。
$ ls -l /etc/dlm
$ sudo rm /etc/dlm/dlm.conf
$ ls -l /etc/dlm
他にもゴミが残っていたら削除しておこう。

というわけでgemini/cancerのクラスタ修正

前回判明した内容を、gemini/cancerのクラスタに適用してみる。

その前にまず、状態確認をしておく。
sudo pcs status
クラスタとリソースが起動している状態であること。

sudo corosync-quorumtool -s
Flags: が Quorate LastManStanding AutoTieBreaker になっている。
＃2Nodeがない。

ls /etc/dlm/dlm.conf
カスタマイズされたファイルが存在しているはず。

cat /etc/corosync/corosync.conf
quorum{} の中に

• auto_tie_breaker: 1
• last_man_standing: 1
• two_node: 1
• wait_for_all :0

が記載されている。

まずは、dlm.conf だが、すでに dlm-clone リソースが動いているので、それを止めてしまう。
sudo pcs resource disable dlm-clone
sudo pcs status
dlm-clone が止まることで、それに引きずられて他のリソースも停止したはずだ。

(gemini/cancer) $ sudo rm /etc/dlm/dlm.conf
(gemini/cancer) $ sudo ls /etc/dlm/dlm.conf
ファイルが無くなったはずだ。

この状態で、リソースを復旧させる。
sudo pcs resource enable dlm-clone
sudo pcs status
数秒でリソースが起動してくるはず。

続いて、corosync.conf を修正する。
ここでは gemini で実施。
(gemini) $ sudo vi /etc/corosync/corosync.conf
auto_tie_breaker と last_man_standing の2行を削除し、two_node: 1 と wait_for_all: 0 の2行を残す。(provider 行も残す)

そしたら、corosync.conf を再読込する。
(gemini) $ sudo pcs cluster reload corosync
(gemini) $ sudo pcs cluster sync
(gemini) $ sudo corosync-quorumtool -s
あれ？ダメだ。

となると、corosyncを再起動かなぁ？
(gemini) $ sudo systemctl restart corosync
(gemini) $ sudo pcs status
リソースが再起動するのを待つ。
(cancer) $ sudo systemctl restart corosync
(cancer) $ sudo pcs status
リソースが再起動するのを待つ。

(gemini/cancer) $ sudo corosync-quorumtool -s
Flags: が 2Node Quorate になったのが確認できる。
更に、Quorum: が 2 だったものが 1 になった。
これで、片系ダウンした時の挙動が安定するはずだ。

gemini/cancer は仮想マシンなので、ホスト側で片方ずつ落としながら、生き残った方のノードで
sudo pcs status
sudo corosync-quorumtool -s
を実行したり、片方落ちている状態で、生き残っている方のノードを再起動させてみよう。
問題なく稼働するはずだ。
ってあれー？やっぱりdlmがクラッシュしたー。gemini/cancerを再起動させたら、少しはマシになった。
う～ん。1604のdlmだと不安定なのかなぁ。

試しに、gemini/cancerを1804にアップグレードして、同じようにクラッシュテストをしてみたが…。
dlmがクラッシュする事象が発生しない…。これは…1604のdlm(4.0.4)と、1804のdlm(4.0.7)の差か…？changelog見てみても、それっぽい記述は無いが…。

ということで、結論としては1804を使え、ということか。
ホスト側である sagittarius/aquarius はいずれも1604。
gfs2を使用しているがpacemaker管理になっていない。
今後は

• sagittarius/aquariusにpacemakerを導入し、gfs2をpacemaker管理下に置く
• 1604→1804のアップグレードを行う

という流れで、sagittarius/aquariusをメンテナンスしよう。
バックアップ取るのを忘れないようにしないとね。

2ノード構成でのdlm.confやらcorosync.confやら

や～っと分かった！
2ノードクラスタが全然期待通りに動かなかったんだけど、どうやらこれで決定稿だ。
長かった…。

2ノードで組む場合は、corosync.conf は

• auto_tie_breaker: 0 (もしくは未設定)
• last_man_standing: 0 (もしくは未設定)
• two_node: 1

にする必要があった。
auto_tie_breaker や last_man_standing をごにょごにょと 1 に設定したりしたもんだから、two_node が働いていなかったようだ。
で、dlm.conf は特にいじる必要なく、デフォルトのままで良かったようだ。

corosync.conf の wait_for_all は、2ノードの場合は自動で 1 に設定され、2ノードともpacemakerが起動しないと、サービス(リソース)は自動起動しない。
手作業でブロック解除すれば、片ノードだけでも起動する。
wait_for_all を 0 に設定すれば、片ノードだけでもリソースは起動する。
この辺は、クラスタに対してどこまで信頼性・可用性を求めるかによって変わってくるので、好きなように設定を。

あと、サービスは、pacemaker/corosync/pcsd の3つはOS起動時に自動起動(systemd管理下)にして、dlm/clvmd は pacemaker のリソースにする必要があるようだ。

これを元に、もう一度 gemini/cancer を見直そう…。

gemini停止時とcancer停止時の違い

おかしい…。
gemini/cancerのクラスタ構成で、cancerを停止させても、geminiから見ると with quorum (クォーラムを失っていない)状態なのに、geminiを停止させると WITHOUT quorum (クォーラムを失った)状態になる。
これが原因で、gemini停止→cancer停止を行おうとすると、cancerが無事に停止しない。
corosyncの設定もdlmの設定も、クラスタのプロパティも同じなのに、この違い。
なんだこりゃ…。

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がダウンしてしまうってことなんだよなぁ。
これを解決できれば、全て通ると思うんだけど…。

あかん。まだや。

https://uramocha02.blogspot.com/2019/05/2.html
ココで、片方のノードがダウンした時の、もう片方のノードの運用について記載したけど、まだ問題があった。

上記は、片方のノードを正常停止(systemctl poweroff)してから、もう片方のノードを運用する、というスタンスで書いていた。
ところが、正常停止ではなく異常終了(電源停止などによるクラッシュ)の時は、生き残っている方のノードもマトモに稼働しない、ということが判明。
この時、生き残っている方のクラスタリソース、dlmが落ちるという事象が発生している。
これ、dlmのパラメータ(/etc/dlm/dlm.conf)を適切に設定すれば良いんだと思っていたんだが、どうも良くワカラン。そもそも、dlmに関するドキュメント類が薄すぎるんだよなー。

もっと調べないとアカンかなぁ。まぁdlmは、GFS2等の共有ファイルシステムを使っている時にのみ利用するデーモンだから、情報量少ないのはしょうがないか…。

イマイチ本運用まで到達出来ないなぁ。

シングルノード状態でのgfs2

いろいろ試しているうちに、いくつかまだ設定がおかしいと思われるところが見つかった。
致命的なのは、

• 片方のノード(例えばcancer)が障害で起動できない
• 生き残っている方のノード(この場合gemini)を再起動させると、clvmリソースが正常に立ち上がって来ない→gfs2が利用できない

という状態だ。
しかも、この状態だとgeminiが再起動できない。(停止処理でハングしてしまう)

調べていったら、起動後にdlmは起動するが、clvmdがうまく起動できていないのだが、clvmdがdlmと通信を行い、dlmがエラーを返すことで、clvmdが起動に失敗する、という流れのよう。
dlmがシングルノードで稼働している(相方が死んでいるので、シングルで稼働させても問題はない)という状態をうまく認識できていないのが問題のよう。

やっぱりdlmがネックになるなー。

dlmとclvmdの依存関係(gfs2用)

dlmとclvmdリソースの起動順を定義しておく必要があるようだ。
＃と言っても、dlmもclvmdもOS起動時にsystemdから起動されるので、あまり意味が無い気がするんだけど…。
＃RHEL7だと、systemdから起動させず、各リソース定義から起動させるのだろうか…。

RedHat社のサイトだと、以下のコマンドとして記載されている。
pcs constraint order start dlm-clone then clvmd-clone
pcs constraint colocation add clvmd-clone with dlm-clone
起動順だけでなく、「clvmdもdlmも同じノードで起動するよ」という制約も付けていた。

まずは起動順から。
pcsd の画面から dlm-cloneリソース か clvmd-cloneリソース の Resource Ordering Preferences から設定するようだ。

dlm-clone リソースから設定する場合は、以下のように入力する。

• Resource : clvmd-clone
• Action : starts
• Before/After : after dlm-clone
• Action : starts
• Score : 無し

これは、「dlm-clone が起動した後に、clvmd-cloneを起動させる」という意味だ。

clvmd-clone リソースから設定する場合は、以下のように入力する。

• Resource : dlm-clone
• Action : starts
• Before/After : before
• Action : starts
• Score : 無し

これは「dlm-clone を先に起動させる」という意味。

リソースの起動順はこれでおしまい。

続いて起動ノードの制約。
こちらは pcsd の dlm-cloneリソース か clvmd-cloneリソース の Resource Colocataion Preferences という設定画面から設定可能。
設定内容は以下の通り。

• Resource : 相手側のリソース名。clvmd-clone リソースから定義しているのなら、dlm-clone
• Together/Apart : Together
• Score : 無し(未設定だと INFINITY で設定される)

どちらか片方で設定すれば、もう片方からも自動設定されるぞ。

設定出来たら設定内容を確認してみよう。
(gemini) $ sudo pcs constraint show --full

依存関係等はこれで終了かな？

dlmリソース作成(gfs2用)

続いて、dlmをリソースとして作成する。
RedHat社のサイトを参照すると、以下のコマンドがサンプルとして載っている。
pcs resource create dlm \
  ocf:pacemaker:controld \
  op monitor \
       interval=30s \
       on-fail=fence \
     clone \
     interleave=true \
     ordered=true

今回は、pcsdを使ってセットアップしているので、このコマンド例を参考にpcsdの画面にどのように入力するのか？

まずは、pcsdの画面からgfs2-clusterを選択する。
そして、RESOURCESタブから「Add」を選んで、リソース情報入力ダイアログを表示させよう。
で、ダイアログを以下のように設定する。

• Class/Provider : ocf:pacemaker
• Type : controld
• Resource Group : None
• Clone : チェックOn
• Master/Slave : チェックOff
• Disabled : チェックOff
• ResourceID : dlm
• args : なし
• configdir : なし
• daemon : なし
• allow_stonith_disabled : なし

これで、Create Resourceボタンを押して作ってみる。
cloneリソースとして作成しているので、自動的にdlm-cloneというグループ？が作られて、そこにdlmリソースが定義される。

作成したdlmリソースに関して、コマンドラインでも確認してみよう。
(gemini) $ sudo pcs resource show
(cancer) $ sudo pcs resource show
cloneリソースとして、dlmリソースが提議されているのが確認でき、Startedになっているのが確認できる。

詳細確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full

詳細を見てみると、start / stop / monitor の3つの項目に、それぞれ interval やその他のパラメータが設定されていることがわかる。
redhat社のサイトでは、op monitor interval=30s on-fail=fence と指定しているので、おそらく monitor 項目の interval パラメータを 30s 、on-fail パラメータを fence に設定しているのだろう。

pcsd の画面からはどうやって設定するのだろうか？
今回のリソースはクローンリソース(複数のノードで同じリソースが稼働するタイプ)で、interval項目は、個別のノードごとに設定を変える必要は無さそうだ。
つまり、全体に影響させればいい。
ということは、dlmではなくdlm-cloneリソースの方のパラメータだろう。
pcsdの画面から、dlm-cloneリソースを選択し、Resource-Meta-Attributeを開いてみる。
Meta Attribute と Value という入力項目があるので、そこに interval と 30s を入れてみる。
…変化なし…。

どうも良くわからないのだが、Operationsパラメータは、pcsdの画面からは修正することが出来ないようだ。
コマンドラインから設定してみることにする。
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
おっとエラーになった。
monitor 定義が既に入っているので、重ねて定義出来ないよ、もし重ねて定義したいのなら、--force を付けてね、とのこと。
同じ interval パラメータ等を定義しても意味が無さそうなので、一旦削除してから定義する。
(gemini) $ sudo pcs resource op remove dlm monitor
(gemini) $ sudo pcs resource show dlm --full
monitor定義が消えたのを確認して
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show dlm --full

一応、cancerの方でも確認してみる。
(cancer) $ sudo pcs resource show dlm --full
反映されているようだ。

これで、redhat社のサイトに掲示されていたコマンドのうち、op monitor interval=30s on-fail=fence の部分は対応できた。
残りは interleave=true と orderded=true だ。
これは結論から言うと、pcsd の画面の dlm-clone リソースから Resource Meta Attribute を入力することで設定することになる。
というわけで、dlm-clone リソースの Resource Meta Attribute の Meta Attribute と Value にそれぞれ以下の値を入れよう。

Meta Atribute	Value
interleave	true
orderded	true

確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full

Meta Attrs に値が表示されていればOKだ。

とりあえず今回はここまで。

GFS2/DLM導入(16.04)

gemini/cancerクラスタは、gfs2ファイルシステムの運用を想定している。
そのため、gemini/cancer両ノードにgfs2ファイルシステムを導入しておく必要があった。
また、gfs2ファイルシステムを複数のノードで共有するためには、dlmも必要になる。
一緒に導入しておこう。
(gemini) $ sudo apt-get install gfs2-utils dlm
(cancer) $ sudo apt-get install gfs2-utils dlm

さくっと導入できた。

ダメだ…。

やっぱり、きちんと corosync / dlm の運用を把握しておかないと、片方のマシンを再起動させるだけで挙動が不安定になる…。
ちゃんと調べないとな…。

壊れた…

しばらく忙しくてあまりメンテしてなかったら、KVMゲストのWindowsマシンのリモートデスクトップが不安定になってしまった。
ネットワークの方の問題かなぁ？と思ってたんだけど、ある時突然リモートデスクトップも接続できなくなった。
で、ホスト側を見てみたら、iSCSIへのアクセスが一部出来なくなっていて、corosync / dlm等が動かなくなってしまっていた。
上で動いている仮想マシンはiSCSIストレージを利用していたので、当然仮想マシンも動かず。
とりあえず、2台のホストマシン(sagittarius / aquarius)を強制再起動。
そしたら、corosync / dlm が正常稼働しなくなって、その後ろで動く Clusterd-LVM も動かない。
今はその原因追求と対策をしている最中…。
corosync / dlm は厳しいな…。

cancer で dlm と corosync を

続いて、dlm と corosync だ。
これは色々苦労したんだけど、本当にこれまでのやり方が正しいのか分からない。

とりあえず、手を出せるところに手を出してみる。

まずは、dlm.conf だ。
(cancer) $ sudo mkdir /etc/dlm
(cancer) $ sudo bash -c "dlm_tool dump_config > /etc/dlm/dlm.conf"
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing を 0 に
enable_fencing=1
↓
enable_fencing=0
--ココまで

(cancer) $ sudo systemctl restart dlm.service

再起動して確認してみる。
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ systemctl status
(cancer) $ tail -f /var/log/syslog
(cancer) $ dlm_tool status

ここまでは問題無さそうだ。
続いて corosync。
(cancer) $ sudo vi /etc/corosync/corosync.conf
gemini を参照しながら修正しよう。
修正内容は gemini と同じだ。
--ココから
cluster_name: debian
↓
cluster_name: mycluster

bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0

quorum {} 内に2行追加
two_node: 1
wait_for_all: 0
--ココまで

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl restart corosync.service
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ dlm_tool status

再起動して確認。
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
やっぱり、dlm_controld が落ちる現象が出てるな。

というわけで、corosync の起動を openvswitch の後に変更する。
今までは、Requires エントリと After エントリに追記する形にしてたけど、どうやら両エントリとも複数行書くことが可能のようだ。
今回は、Requires と After の行を増やす方向で実施してみる。
(cancer) $ sudo cp -pi /lib/systemd/system/corosync.service \
/lib/systemd/system/corosync.service.orig
(cancer) $ sudo vi /lib/systemd/system/corosync.service
--ココから
ConditionKernelCommandLine=!nocluster
Requires=network-online.target
After=network-online.target
↓(Requires と After の行を増やす)
ConditionKernelCommandLine=!nocluster
Requires=network-online.target
Requires=openvswitch-switch.service
After=network-online.target
After=openvswitch-switch.service
--ココまで

設定を反映させ、再起動して確認。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --failed
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ ps -ef | grep -e corosync -e dlm | grep -v grep
(cancer) $ dlm_tool status
やはり、corosync がダウンして期待した動作にならない。

今度は、openvswitch の起動処理後に sleep を入れてみる。
(cancer) $ sudo cp -pi /lib/systemd/system/openvswitch-switch.service \
/lib/systemd/system/openvswitch-switch.service.orig
(cancer) $ sudo vi /lib/systemd/system/openvswitch-switch.service
--ココから
以下の行を[Service]エントリに追記する。
ExecStart=/bin/sleep 10
--ココまで

再び設定を反映させ、再起動して確認。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --failed
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ ps -ef | grep -e corosync -e dlm | grep -v grep
(cancer) $ dlm_tool status
今度は大丈夫なようだ。
何度か再起動して、挙動を確認してみよう。

これで gemini との間の通信は確立できた。
次は CLVM の設定か。

corosync が落ちる？

とりあえず、gfs2 を復旧させて、2台のPC(aquarius / sagittairus)を起動しておいたんだけど、aquarius の corosync がクラッシュしてた…。

まだ corosync / dlm が不安定だな…。何が原因だろう…。

まだ色々不具合が…

次のアクションとしては、NASのCIFS領域のマウントに autofs を使用してみよう、というプランがあったんだけど…。
それ以前にまだ、起動停止時の不具合が残っているし、仮想マシンを稼働させたまま、ホストマシンを停止させてしまうと不具合が起きる事象、それに合わせて反対側(aquarius を停止させたのなら sagittarius側)でも dlm 関連のトラブルが起きる…。

これらのトラブルの発生要因を整理し、修正しないと全然利用出来ないな…。

シャットダウン時に刺さる現象再び！

シャットダウン・リブート時にハングする現象、ココで暫定対策を施しておいたんだけど、また再発した。
遠隔からリブート仕掛けたらハングしてしまったので、何が起きたのかは分からず。
帰宅後にコンソールを見てみてもよく分からなかった。

ただ、どうも dlm 絡みのような気がしてならない。
問題が起きたから dlm がトラブったのか、dlm がトラブったから問題が発生したのか、どちらが主要因かは分からない。

何せ、再現性に乏しいのが辛いところ。

とりあえず、lvm2-cluster-activation.service の停止処理の sleep 10 と、openvswitch-switch.service の起動処理の sleep 10 を、sleep 20 に伸ばしてみた。
直接の原因が分からないので、これが効果あるのかどうかも分からない。

取り急ぎ、これで逃げておくことにする。

corosync / dlm / gfs2

というわけで、corosync / dlm / gfs2 か。
この辺からの作業だ。
結構苦労した記憶があるので、今回も手こずるんだろうな…。
記憶を呼び戻しながら、整理しながら記載していくことにする。

まずは corosync の導入。
$ sudo apt-get update
$ sudo apt-get install corosync

$ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
$ sudo vi /etc/corosync/corosync.conf

一部修正
--ココから
totem {
cluster_name: debian
↓
cluster_name: kvmcluster

interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
quorum {
    (2行追加)
two_node: 1
wait_for_all: 0
}
--ココまで
今回は、クラスタ名を「kvmclulster」にした。かっこ悪いか？

corosync の起動順変更
$ cd /lib/systemd/system
$ sudo cp -pi corosync.service corosync.service.orig

$ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで

$ sudo systemctl daemon-reload
$ sudo systemctl restart corosync.service
$ systemctl --no-pager -l status corosync.service

$ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
$ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓
ExecStart=/bin/sleep 10
--ココまで
$ sudo systemctl daemon-reload
$ cd

dlm の導入だ。
$ sudo apt-get update
$ sudo apt-get install dlm

$ systemctl -l status dlm.service

$ sudo mkdir /etc/dlm
$ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
$ cat /etc/dlm/dlm.conf
--以下の内容になっていた
daemon_debug=0
foreground=1
log_debug=0
timewarn=0
protocol=detect
debug_logfile=0
enable_fscontrol=0
enable_plock=1
plock_debug=0
plock_rate_limit=0
plock_ownership=0
drop_resources_time=10000
drop_resources_count=10
drop_resources_age=10000
post_join_delay=30
enable_fencing=1
enable_concurrent_fencing=0
enable_startup_fencing=1
enable_quorum_fencing=1
enable_quorum_lockspace=1
help=-1
version=-1
--ココまで

$ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_fencing=1
↓この行を以下のように書き換え
enable_fencing=0
--ココまで

$ sudo systemctl restart dlm
$ systemctl --no-pager -l status dlm

$ dlm_tool ls
$ dlm_tool status

gfs2 の導入
$ sudo apt-get update
$ sudo apt-get install gfs2-utils

とりあえずはこんなもんかね。
次は CLVM の導入か…。

dlmのフェンシング(その4:fence_all /bin/true)

続いて、enable_fencing は 1 だけど、fence_all を /bin/true にする形を検証する。
前回と同様、gemini / cancer の /etc/dlm/dlm.conf を書き換えるところから。

(gemini) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=0
↓1に書き戻す
enable_fencing=1

1行追加する。
fence_all /bin/true
--ココまで

cancer も同様に。
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=0
↓1に書き戻す
enable_fencing=1

1行追加する
fence_all /bin/true
--ココまで

どうも、dlm.service の再起動が上手く行かなったので、leo を停止し、gemini / cancer は再起動する。
(leo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot

状態確認だ。
(gemini) $ dlm_tool status
(cancer) $ dlm_tool status
(gemini) $ dlm_tool ls
(cancer) $ dlm_tool ls

前回のテスト前半部分はすっ飛ばして、leo を起動してテストする。

既に gemini 上で leo が動いていると思うので、前回の後半部分、仮想マシンの起動からテストする。
(gemini) $ virsh list --all
(gemini) $ virsh start leo
(gemini) $ virsh list --all

leo にログインし、ping を打ち続ける。
(leo) $ ping 192.168.55.130

leo を cancer へ移動。(今回は sagittarius から実行する。対象ホストに注意。)
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

gemini を強制再起動
(sagittarius) $ virsh reset gemini
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

(gemini の再起動が確認できたら) leo を gemini に移動。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

問題無いな…。
というわけで、この設定をそのまま採用しよう。

と思ったけど、dlm_controld がダウンする現象が発生した。
多分、その他のフェンシング設定が関係している気がする…。
enable_fencing=0 の方では発生しないっぽい…。

ちょっと調べたけど分からなかったので、当面は「その3」で記載した方法で進めていくことにする。
将来的に pacemaker を使う時に、もう一度検討することになると思う。

dlmのフェンシング(その3:enable_fencing=0)

というわけで、dlm.conf の enable_fencing を 0 に書き換えて試してみよう。
gemini / cancer の両ノードを起動して、dlm.conf を書き換える。

(gemini) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=1
↓
enable_fencing=0
--ココまで

cancer も同様に。
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=1
↓
enable_fencing=0
--ココまで

dlm.conf は、dlm.service だけが参照していると思うので、dlm.service の設定を読み直す。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl restart dlm.service
(gemini) $ sudo systemctl status dlm.service

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl restart dlm.service
(cancer) $ sudo systemctl status dlm.service

(gemini) $ dlm_tool status
(cancer) $ dlm_tool status
(gemini) $ dlm_tool ls
(cancer) $ dlm_tool ls

きちんと動いてそうなら、ココと同様にテストしてみる。
ホスト側から cancer の強制停止。
(sagittarius) $ date ; virsh destroy cancer

プロセスの確認
(gemini) $ ps -ef | grep dlm_controld | grep -v grep
プロセスは死んでない。

dlm の状態確認
(gemini) $ dlm_tool status
(gemini) $ dlm_tool ls

共有ファイルシステムの確認
(gemini) $ grep -e /etc/libvirt -e /var/lib/libvirt /etc/mtab
rw モードでマウントされていることを確認。

(gemini) $ sudo bash -c "sync;sync;sync"
(gemini) $ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"

(gemini) $ ls -l /etc/libvirt
(gemini) $ ls -l /var/lib/libvirt
ちゃんと読める。

cancer を起動したら、自動的に組み込まれるか？
(sagittarius) $ virsh start cancer
(gemini) $ dlm_tool status
(gemini) $ dlm_tool ls
自動的に組み込まれた。

どうやら上手く行ってるようだ。
なら今度は、仮想マシンのオンラインマイグレーションを含めた挙動確認してみるか。

流れとしては、

1. gemini 上で leo を起動
2. leo を cancer 上へ移動
3. gemini を強制再起動
4. leo を gemini へ移動

かな？

というわけで、gemini 上で leo を起動。
(gemini) $ virsh list --all
(gemini) $ virsh start leo
(gemini) $ virsh list --all

leo にログインし、ping を打ち続ける。
(leo) $ ping 192.168.55.130

leo を cancer へ移動。(今回は sagittarius から実行する。対象ホストに注意。)
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

gemini を強制再起動
(sagittarius) $ virsh reset gemini
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

(gemini の再起動が確認できたら) leo を gemini に移動。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

全然問題無さそうだ。

enable_fencing=0 のパターンはコレで終了かな？
次回は、enable_fencing=1 and fence_all /bin/true を試してみよう。