systemd設定見直し

随分前の話になるが、初めて dlm/clvmd/gfs2 と openvswitch を導入した時、OSの起動停止が上手く行かず、原因を systemd の起動順や起動速度だと思って、 systemd の各 unit ファイルをいじった。

ここまでの作業で、 corosync.conf の設定内容が pacemaker によって大幅に変更されたり、 dlm を systemd 起動ではなく pacemaker から起動するように変更された。
もしかしたら、これまで問題としていた内容は、これによって解消しているのでは？ということで、 systemd の設定を元に戻してみる。
これまで弄ってきたファイルは、 /etc/systemd/system と /lib/systemd/system の以下のファイルだと思う。

• corosync.service
• openvswitch-switch.service
• lvm2-cluster-activation.service
• lvm2-clvmd.service
• open-iscsi.service

この内、open-iscsi.service はアップデートの過程で元のファイルに戻っているので、バックアップファイルだけ削除すれば OK のはず。
他にも弄っているファイルがあるかもしれないので、各自対応しておこう。

っと、systemd を弄る前に、個別にクラスタを止めておいた方がいいな。

(aquarius) $ sudo pcs cluster stop aquarius
(aquarius) $ sudo systemctl stop corosync
(aquarius) $ sudo systemctl stop pacemaker
(aquarius) $ sudo systemctl stop pcsd
(aquarius) $ mkdir ~/systemd.unit
(aquarius) $ sudo mv /etc/systemd/system/corosync.service ~/systemd.unit/
(aquarius) $ sudo mv /etc/systemd/system/openvswitch-switch.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-cluster-activation.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-cluster-activation.service.orig /lib/systemd/system/lvm2-cluster-activation.service
(aquarius) $ sudo mv /lib/systemd/system/lvm2-clvmd.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-clvmd.service.orig /lib/systemd/system/lvm2-clvmd.service
(aquarius) $ sudo rm /lib/systemd/system/open-iscsi.service.orig

systemd の unit ファイルを再読込して、OS ごと再起動してみよう。

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot

う～ん。やっぱり corosync.service の起動に失敗する。
OpenvSwitch より後に起動させる必要があるみたいだな。

(aquarius) $ sudo EDITOR=vi systemctl edit corosync.service

---空のエディタが起動するので、以下のように作成

[Unit]
After=openvswitch-nonetwork.service
[Service]
ExecStartPre=/bin/sleep 5

---
これでいいのかな？

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot

どうやら上手くいったよう。
sagittarius にも同じ作業を適用しておこう。

というわけで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ノードクラスタでの特殊運用やっと分かった！

https://uramocha02.blogspot.com/2019/05/1604gfs2pacemaker.html
ココで書いたけど、2ノードクラスタは半分諦めていた。
もう一度書くと
2ノードクラスタ
片方のノードが死亡
生きている方のノードをメンテナンスで再起動
させると、生きている方のノードでもクラスタが正常起動しない、という問題だ。

これ、過半数のquorumに到達しない(2ノードなので、1ノードしか生きていなければ50%、つまり過半数に到達していない)というのが直接の原因。

で、クラスタによってはquorum diskという特殊な共有ディスクを用意して、そのquorum diskのロックに成功したノードは、quorumを1つ余分に得る、という仕組みを用意している。
これによって、生き残っているノードは、自身のquorum＋quorum diskをロックすることによって得られるquorumの合計2つのquorumを得て、過半数に到達する、という作りだ。

で、RHEL6時代のpacemakerには、そのものズバリのquorum disk(qdiskd)というソフトがあり、これを利用することで1ノードでも暫定運用が可能、という動きになる。

Ubuntu16.04にはこのquorum diskが無く、またUbuntu18.04やRHEL7は、quorum diskではなく、quorum deviceというのが使えるのだが、こちらはクラスタとは別に1つマシンが必要。
ということで、2ノードクラスタなのに3台のマシンが必要ということで、正直諦めていた。

諦めつつ、18.04のクラスタの構築を始めていたのだが、corosyncのコマンドにcorosync-quorumtoolというのがあるのに気づいた。
もしかしてコレ…と調べてみたら、ノードが持つquorum数を、意図的に変更することができるようだ。
だったら、生き残っている方のノードのquorum数を、1ではなく2にしてみたら、quorum数が過半数に到達し、1ノードでもクラスタ動くんじゃないか？ということで急遽実験。

結論は成功。

生き残っている方のノードで
sudo corosync-quorumtool -s
を実行し、自身のノードIDを確認する。
続いて
sudo corosync-quorumtool -v 2 -n (先程確認したノードID)
と実行し、指定したノードが持つquorum数を2つにすることで、クラスタが稼働し始めた。
なるほど…こういうことか…。

注意事項としては、OS再起動させるとquorum数も元に戻ってしまうので、再起動のたびにquorum数を再設定する必要がある、という点だ。
quorum数を固定することもできるかもしれないが、死んだノードを復旧させた後、またquorum数を1に戻す必要があるので、固定する機能は多分無いだろう。

やー、ここまで辿り着くの、永かった…。

まずはpcsdの導入と初期セットアップ(18.04)

というわけで、18.04の構成(pisces/aries)を使って、NFSクラスタを構築する。

最初はpcsdの導入だ。
sudo apt-get update
sudo apt-get dist-upgrade
(必要に応じて再起動)
sudo apt-get install pcs
合わせて、pacemakerもインストールされる。

pcsdは自動起動にセットされた。

16.04の時と同様、haclusterアカウントが出来ているはずなので、パスワードを設定しておく。
sudo passwd hacluster

ついで、pisces/ariesと管理ノードのleoに、pisces/ariesのホスト名とIPアドレスを/etc/hostsに記載しておく。

sudo vi /etc/hosts
(127.0.1.1に自身のホスト名が定義されていると思うので、それは外しておくこと)
相互にpingを打って、名前解決出来ていることを確認しておこう。

gemini/cancerの時は、ブラウザからクラスタを組んだが、今回はコマンドで組んでみることにする。
sudo pcs cluster auth pisces aries -u hacluster
sudo pcs cluster setup --name nfs-cluster pisces aries --force
sudo pcs status
sudo pcs cluster start pisces aries
sudo pcs status

これでクラスタの構成は出来たが、corosync.serviceとpacemaker.serviceが自動起動になっていない。(pcs cluster setup に --start --enable のオプションを付与しておけば、自動起動に設定されると思うが、今回は敢えて設定しなかった。)
両方共自動起動にしておく。(pisces / ariesの両方で実施しておくこと)
sudo systemctl enable corosync.service
sudo systemctl enable pacemaker.service

これで、OS再起動させても自動的にクラスタが構成されるはずだ。
試しておくこと。

16.04でのgfs2のpacemaker化(一部諦め)

あーでもないこーでもない、と色々検証していった結果、Ubuntu16.04でgfs2をpacemaker管理下に置くのは、いくつか問題があって厳しいことが分かった。

今現在分かっているのは、

• 2ノードで稼働
• 片方のノードが死亡
• 生きている方のノードをメンテナンスのために再起動

という3つの条件が重なった時に、クラスタが上がってこない(厳密には、clvmdリソースが上がってこない)ということ。

クラスタ製品の仕様として、「クラスタを構成するノード数のうち、過半数のノードが起動しない限り、クラスタは稼働させない(3ノードの場合は2台以上、4ノード・5ノードの場合は3台以上)」というのがある。
これはクラスタとしては当然の仕様だ。

2ノードの場合、この条件を満たすためには、2台が正常稼働する必要がある。
クラスタを組んでいるのに、1台も障害を受け付けない、というのはクラスタとしては片手落ちだ。

そこで、クラスタ製品は幾つかの対策を施している。
2ノードのみ特定の設定をし、片方がダウンしてもサービスを継続させる、という仕組みもその一つ。今回使用しているpacemakerの場合、corosync.confに記載する「two_node」というパラメータが該当する。
確かにこのパラメータを1に設定しておけば、片方のノードがダウンしてもサービスは継続実行可能だ。
ただし、これはクラスタ稼働中の話だ。
片系ダウンしている時に、生きている方のノードを再起動させた場合、「クラスタ稼働中」ではなく「クラスタを起動させる時」に該当する。
この時、もう片方のノード(死んでいる方のノード)がクラスタに参加するのを待ってしまうため、いつまで経ってもクラスタが上がってこない。

pcsコマンドにある cluster quorum unblock というのが「ノード数が過半数に達しなくても、サービスを稼働させる」というコマンドのようなのだが、16.04で試してみても期待した動きにならない。

他のクラスタ製品では、「quorum disk」という設定を施すことで、上記の状態を回避することが可能になっている。これは、2ノードの片系ダウンだけでなく、4ノードなどの「偶数台クラスタ」による「スプリットブレイン」にも対応している。
quorum diskは、クラスタを構成しているすべてのノードに接続している共有ディスクで、ほんの僅かなサイズ(数百MB程度？)のディスクであればいい。

偶数クラスタがちょうど半分に分離してしまった場合(ちょうど半数のノードから応答が無かった場合)、予め定義していたquorum diskにロックを仕掛け、ロックを取得することが出来たノード、及びそのノードと通信可能な方のノードの組でクラスタサービスを継続し、ロックを取得できずに切り離されてしまった組はクラスタから離れる、という仕様だ。
これによって、スプリットブレインに対応している。
ちょうど、quorum diskをロックすることによって、ノード数(投票数)が一つ増えたイメージになる。

pacemaker にも同様の仕組みがあると思っていたのだが、なかなかその情報が見つけられず、スプリットブレイン対策がイマイチ分からなかった、というのが先日までの状態。

で、もう一度調査したところ、RHEL6.xまでは、そのものズバリのquorum diskという設定があったようだ。
ところが、RHEL7.xになって、quorum diskが無くなり、quorum deviceという仕組みに置き換わっていた。

Ubuntu16.04のpacemakerで同様の仕組みを探してみたが、corosyncのバージョン違いからか、quorum diskもquorum deviceも設定が無い。
Ubuntu18.04の方を見てみたら、quorum deviceという設定はあるようだ。

この時点で、quorum diskを使用したスプリットブレイン対策は施せないことが分かったのだが、quorum deviceの方を調べてみたら、クラスタ構成ノードとは別に、サーバが1環境必要であることが分かった。
2ノードクラスタを組むのに、3台必要、ということだ。

ちなみに、quorum deviceというのは、スプリットブレインが発生した時に、どちらの組でサービスを継続させるかを決定する、調停役として存在させるみたいだ。
HPE社のクラスタソフトであるServiceGuard for Linuxでは、確か「quorum server」と呼ばれるものに相当するようだ。

とまぁ色々書いてきたが、今のホストOS(sagittarius/aquarius)の2台では、16.04のpacemakerどころか、18.04のpacemakerでも不都合が起きる。
とりあえず、動かすことはできるので、2台のいずれかが故障しないことを祈るか、もう1台手配して、quorum deviceとしてセットアップするか…。

gfs2を使用するためのクラスタだけでなく、nfsサーバもクラスタ化することを考えているので、現状ではかなり厳しい状態なのが判明。果たしてどうするか？

18.04でquorum diskが使えるといいんだが…。

とりあえず今後は、16.04でのgfs2クラスタは一旦放置し、18.04のnfsクラスタの方を少し調査してみることにする。

corosync.confの追記

構成見直しの前に、/etc/corosync/corosync.confに2行ほど追加した。

追加したのは、quorumセクション。
追加前には provider: corosync_votequorum というエントリだけが存在していると思う。
そこに、
wait_for_all: 0
auto_tie_breaker: 1
の2行を追加した。

ホントは two_node: 1 というエントリも追加したいんだが、ノードを切り離して1ノード状態にすると、two_node: 1 というエントリも消えてしまう。
イマイチ良くわからない。

いずれにせよ、上で追加した2行は障害発生時の処理に関わるので、追加しておく。

クラスタ用LVMとファイルシステム作成(gfs2用)

フェンシングが全然わからず、すげー時間がかかった…。

というわけで、今度はgemini/cancerで共有しているディスクに、LVM構成とgfs2ファイルシステムを作成する。

この辺の内容で既に検証してるけど、今一度整理しよう。

当時の手順、間違いもあるから。

あと、サービスの導入やら起動やらを変更しているので、gemini/cancerとも再起動しておいた方が良いかな。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ systemctl status lvm2-cluster-activation.service
(cancer) $ systemctl status lvm2-cluster-activation.service

起動出来てなかった。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
              /etc/systemd/system/lvm2-cluster-activation.service
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
              /etc/systemd/system/lvm2-cluster-activation.service
(gemini) $ sudo vi /etc/systemd/system/lvm2-cluster-activation.service
--以下のように修正
After=lvm2-clvmd.service lvm2-cmirrord.service
↓
#After=lvm2-clvmd.service lvm2-cmirrord.service
After=lvm2-clvmd.service
--ココまで
cancerも同様に修正しておく。

修正終わったら反映。
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl daemon-reload
(gemini) $ systemctl status lvm2-cluster-activation.service
(cancer) $ systemctl status lvm2-cluster-activation.service

これで起動してみる。
(gemini) $ sudo systemctl start lvm2-cluster-activation.service
やっぱり起動しない…。

まずは、VGの作成。

同じ仮想ディスクをgemini/cancerの両方に接続しており、いずれも/dev/vdbとして見えている。

(gemini) $ lsblk

(cancer) $ lsblk

これを使って作成していく。

(gemini) $ sudo pvcreate /dev/vdb

(gemini) $ sudo vgcreate vg-gfs2 /dev/vdb

(gemini) $ sudo vgdisplay vg-gfs2

(gemini) $ sudo lvcreate -L 10G -n lv-gfs2 vg-gfs2

(gemini) $ sudo vgdisplay -v vg-gfs2

(cancer) $ sudo vgdisplay -v vg-gfs2

なぜか、意図的にクラスタマークを付与(vgchange -c y)しなくても、クラスタマークが付与された。

さて、LVまで作成できたので、今度はファイルシステムだ。
(gemini) $ sudo mkfs.gfs2 -j2 -p lock_dlm -t gfs2-cluster:fs-gfs2 /dev/vg-gfs2/lv-gfs2
-tオプションは、「クラスタ名」＋「:」＋「任意の名前」だ。
-jオプションはジャーナル数で、同時にマウントするノード数以上の数字を指定する必要がある。
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs2
(cancer) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs2

マウントできるのかな…？
(gemini) $ sudo mkdir /mnt/test
(gemini) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(gemini) $ df /mnt/test
(cancer) $ sudo mkdir /mnt/test
(cancer) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(cancer) $ df /mnt/test
マウントは出来た…。

読み書きテスト
(gemini) $ sudo bash -c "echo \"This is a test\" > /mnt/test/hoge"
(cancer) $ cat /mnt/test/hoge
出来た…。
lvm2-cluster-activation.service は必要無いのか？

一旦再起動して、再度マウントしてみるか…。
(gemini) $ sudo umount /mnt/test
(cancer) $ sudo umount /mnt/test
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(cancer) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(gemini) $ cat /mnt/test/hoge
(cancer) $ cat /mnt/test/hoge
(gemini) $ sudo umount /mnt/test
(cancer) $ sudo umount /mnt/test

確認ができたら、リソースを作成する。
(gemini) $ sudo pcs resource create cluster-gfs Filesystem \
    device="/dev/vg-gfs2/lv-gfs2" \
    directory="/mnt/test" \
    fstype="gfs2" \
    op monitor interval=10s on-fail=fence clone interleave=true
(gemini) $ sudo pcs resource show cluster-gfs
(cancer) $ sudo pcs resource show cluster-gfs
できてる。

(gemini) $ df
(cancer) $ df
両方ともマウントされている。

これでいいのか…？
おっと、リソースの起動順と、起動するノードを定義してなかった。
clvmdより後に起動させる必要があるため、それに従って設定する。
(gemini) $ sudo pcs constraint order start clvmd-clone then cluster-gfs-clone
(gemini) $ sudo pcs constraint colocation add cluster-gfs-clone with clvmd-clone

(gemini) $ sudo pcs constraint show cluster-gfs-clone
(cancer) $ sudo pcs constraint show cluster-gfs-clone

これでいいのだろうか？
一旦再起動仕掛けてみる。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
片方ずつ落としたらどうなる？
(gemini) $ sudo systemctl poweroff
(cancer) $ cat /mnt/test/hoge

どうやら上手く行っているようだ。
ちょっと時間がかかって、全体の流れがわかりにくくなったので、次回はgemini/cancerを作り直して、もう一度ゼロから実施してみることとする。

Ubuntu16.04のパッケージングミス？(/etc/corosync/uidgid.d/)

忙しくて全然進められなんだ…。
すでに18.04どころか18.10も出て、もうすぐ19.04も出るっていうのに…。

pcs config でエラーが出るんだけど、ちょっと確認してみたら /etc/corosync/uidgid.d/ というディレクトリが存在しないためのようだ。
18.04 の方は、corosyncパッケージに /etc/corosync/uidgid.d/ というディレクトリは含まれているが、16.04 の方には含まれていない。
それが原因っぽい。

ので、gemini / cancer でディレクトリ作っておく。
sudo mkdir /etc/corosync/uidgid.d/
sudo chmod 755 /etc/corosync/uidgid.d/
sudo chown root:root /etc/corosync/uidgid.d/
ls -ld /etc/corosync/uidgid.d/

クラスタベース作ってみる(16.04)

とりあえず、16.04のノード(gemini / cancer)でクラスタを作ってみたい。
同じ16.04のvirgoで動いているpcsdを使って実装してみる。

構成的には

• virgo:クラスタ管理サーバ
• gemini:クラスタノード1
• cancer:クラスタノード2

になる。

ただ、pcsdを使う場合、管理サーバや各ノード間がpcsd同士で通信を行い、各種コマンドや状態のやり取りを行うようだ。
そのため、gemini/cancerでもpcsを導入しておく必要がある。
(gemini) $ sudo apt-get install pcs
(cancer) $ sudo apt-get install pcs

また、pcsdが起動してきてないと思うので、起動しておく。
(gemini) $ sudo systemctl start pcsd
(cancer) $ sudo systemctl start pcsd

gemini/cancerのhaclusterユーザも作成されているはずなので、このアカウントにパスワードを設定しておこう。
(gemini) $ sudo passwd hacluster
(cancer) $ sudo passwd hacluster
設定するパスワードは、virgoに設定したものと同じものが良いだろう。
＃クラスタノード(gemini/cancer)でのパスワードは合わせておくのが推奨のようだ。

実はこの他にも、事前準備として実施しておく必要があるものがある。
まずは、/etc/hosts。
DNSが運用できているのであれば不要だと思うけど、ウチのN/Wではローカルの名前解決にDNSは導入できていない。(したいけど…)
そのため、名前解決のために3つのサーバそれぞれの/etc/hostsにエントリを書いておく必要がある。

• virgo(クラスタ管理サーバ)はgemini/cancerの名前解決ができること
• gemini/cancer(クラスタ構成ノード)は自分自身とお互いの名前解決ができること

が必要になる。

virgoの/etc/hostsには、geminiとcancerのホスト名/IPアドレスを追記すればいい。
(virgo) $ sudo vi /etc/hosts
gemini/cancerは、既に自分自身のホスト名とIPアドレスの対応として、127.0.1.1がエントリされているはずだ。これをコメント化(先頭に#を付与)しつつ、自分自身と相手のIPアドレスを記載しよう。
(gemini) $ sudo vi /etc/hosts
(cancer) $ sudo vi /etc/hosts

virgo(クラスタ管理サーバ)では、pacemaker/corosyncは稼動させる必要がなく、稼動していたらちょっと他に影響が出るようだ。
そのため、pacemaker/corosyncを停止させ、自動起動も止める。
(virgo) $ sudo systemctl stop pacemaker
(virgo) $ sudo systemctl stop corosync
(virgo) $ sudo systemctl disable pacemaker
(virgo) $ sudo systemctl disable corosync

合わせて、/etc/corosync/corosync.conf が存在していては上手く動作しないようなので、リネームしておく。
(virgo) $ sudo mv /etc/corosync/corosync.conf /etc/corosync/corosync.conf.orig

続いて、gemini/cancerでの準備だ。
クラスタを組む前からpacemaker/corosyncが動いていると、「このノードは既にどこかのクラスタに属している」と勘違いされる。
また、corosync.confが存在しているだけでも、同様に勘違いされる。
そのため、pacemaker/corosyncを停止させ、corosync.confを削除しておく。
(gemini) $ sudo systemctl stop pacemaker
(gemini) $ sudo systemctl stop corosync
(gemini) $ sudo rm /etc/corosync/corosync.conf
(cancer) $ sudo systemctl stop pacemaker
(cancer) $ sudo systemctl stop corosync
(cancer) $ sudo rm /etc/corosync/corosync.conf

ちなみに、上記オペレーションは、pcsコマンドで一括実施できたりする。
(gemini) $ sudo pcs cluster destroy
(cancer) $ sudo pcs cluster destroy
なお、pacemaker/corosyncの自動起動停止はしない(自動起動のままにしておく)。

ここまでやったら事前準備完了だ。
クラスタを組んでみよう。

前回と同様、virgo上のpcsdにブラウザでアクセスする。
(pcsdへのログインは、haclusterアカウントだ)

ログインできたら、「MANAGE CLUSTERS」の中にある「Create New」をクリック。
これから作成するクラスタ名と、そのノード名、その他オプションを設定するダイアログが出てきた。
クラスタ名を gfs2-cluster
ノードをgemini/cancerとする。
その他のオプションはデフォルトのまま「Create Cluster」をクリック。

gemini/cancerのhaclusterアカウントのパスワードを聞いてくると思うので、設定したパスワードを入力しよう。

これでクラスタが出来上がる。
この時点で、gemini/cancerのpacemaker/corosyncともに起動する。
また、gemini/cancerで削除したcorosync.confも自動作成されているはずだ。

次回以降は、クラスタの基本設定から続けていく予定。

ダメだ…。

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

あれ？openvswitchの起動処理が…。

色々調べていったんだけど、openvswitch-switchの起動処理、sleepを入れておいたはずなのに消えている。なんで？どこかで消したか？

これが今回の原因かもしれない。
なので、openvswitch-switch の起動処理に sleep を入れてみることにする。
まずは aquarius から。
(aquarius) $ cd /lib/systemd/system
(aquarius) $ sudo vi openvswitch-switch.service
今回は、ExecStart ではなく、ExecStartPost で定義を足してみる。
--[Service]セクションに1行追記
ExecStartPost=/bin/sleep 6
--ここまで

この状態で再起動してみよう。
(aquarius) $ sudo systemctl daemon-reload
(aquairus) $ sudo systemctl reboot

再起動後に確認。
(aquarius) $ sudo systemctl status corosync
(aquarius) $ sudo systemctl status dlm
(aquarius) $ sudo systemctl status lvm2-cluster-activation
おっと、lvm2-cluster-activation は無効化してたんだった。
corosync と dlm は無事に起動しているっぽいな。

では、lvm2-cluster-activation も有効化してから再起動だ。
(aquarius) $ sudo systemctl is-enabled lvm2-cluster-activation.service
(aquarius) $ sudo systemctl enable lvm2-cluster-activation.service
(aquarius) $ sudo systemctl is-enabled lvm2-cluster-activation.service
(aquarius) $ sudo systemctl reboot

もう一度確認
(aquarius) $ sudo systemctl status corosync
(aquarius) $ sudo systemctl status dlm
(aquarius) $ sudo systemctl status lvm2-cluster-activation
どうやら無事に起動したみたいだ。

そしたら続いて、fstab の修正。
(aquarius) $ sudo vi /etc/fstab
/etc/libvirt のエントリと、 /var/lib/libvirt のエントリを有効化する。

一応、マウントテスト
(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ df
(aquarius) $ sudo systemctl start /etc/libvirt
(aquarius) $ sudo systemctl start /var/lib/libvirt
(aquarius) $ df
マウントできた。

この状態でもう一度再起動して、無事にマウントされているか確認。
(aquarius) $ sudo systemctl reboot
(aquarius) $ sudo systemctl status corosync
(aquarius) $ sudo systemctl status dlm
(aquarius) $ sudo systemctl status lvm2-cluster-activation

(aquarius) $ df
良さそうだ。

sagittarius の方も同様に修正しておこう。

これでなんとか回復できたかな？

う～ん、まだ少し不安定だ。
障害で片方のノード(sagittarius か aquarius)が落ちてしまった時の復旧手順が特殊なんだろう。おそらく、落ちたノードを単純に再起動するだけじゃダメだ。
この辺りをきちんと検証しないといけないなぁ。

やっぱりcorosyncか

とりあえず、以下の手順で原因の絞込を実施した。

1. /etc/fstab で x-systemd.requires=lvm2-cluster-activation.service の制限が入っているエントリをコメントにして、自動マウントしないようにする。
2. sudo systemctl disable lvm2-cluster-activation.service で、lvm2-cluster-activation.service が自動起動しないようにする。
3. そして sudo systemctl reboot でリブート。

どうやら、やっぱり corosync が正しくスタートしないのが原因のようだ。
起動時に、192.168.x.x の方にバインディングせず、127.0.0.1 にバインディングしてしまう。この現象、以前も出てたよな…。

はてさて、どうしたものかな…。

壊れた…

しばらく忙しくてあまりメンテしてなかったら、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 が不安定だな…。何が原因だろう…。

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 の導入か…。

これまでを踏まえて、aquarius / sagittarius の手入れを

gemini / cancer を用いて、かなりの検証が出来た。
で、その内容はホストである aquarius / sagittarius に反映させておきたい。

一体いくつの変更/修正点があるのだろうか…

1. openvswitch の仮想スイッチ名の変更(br-external→extsw)
2. 自動起動ネットワークの手直し(/etc/default/networking)
3. OpenvSwitch と open-iscsi の起動停止順の制御
4. multipathd の導入
5. corosync / dlm / gfs2 の導入とセットアップ
6. CLVM の導入とセットアップ
7. 仮想マシン領域の gfs2 化

え？コレだけ？結構色々検証したと思ったけど、まとめてみるとこの程度か…。
結構時間がかかったんだな…。

というわけで、次回から上記に従って進めていくことにする。

今後の予定

とりあえず、今後直近でやっておきたいことをリストアップ。

• 2つのゲストOS(gemini/cancer)で共有ボリュームを用いたKVM環境構築
• dlm/corosyncのフェンシングについて調査

特に、dlm/corosyncは、片方のノードが止まって暫くたつと、行きてる方のノードのdlmがハングしたような状態になる。
これは美味しくないので、この原因追求と、正しい設定の確認がしたい。
共有ボリュームを用いたKVM環境は、ノード間のオンラインマイグレーションと、片方のノードがダウンした時に、もう片方のノードでゲストを起動する、という動作の確認がしたい。
これらが落ち着いたら、また更にやりたいことがあるけど、とりあえずはこの2つかな。