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を作り直して、もう一度ゼロから実施してみることとする。

げ、stonith(fence)の設定が先だ(gfs2用)

RedHat社のサイトをよくよく読んでみると、「クラスターにはフェンシングを設定する必要があります」って書いてあった。
「いつフェンシング設定するんだろう？」って思ってたんだけど、実は先に設定する必要があったのね。

というわけで、fenceの設定を。

まずは、fence-agentsをインストールする。
(gemini) $ sudo apt-get install fence-agents
(cancer) $ sudo apt-get install fence-agents

で、フェンシングを設定するんだけど、どのフェンスデバイスがいいのか…。
(gemini) $ sudo pcs stonith list
gemini / cancer は kvm/libvirt で動かしているので、fence_virsh を使用するのがスジなんだけど…。
そもそも、今検証している gemini / cancer 環境は、物理マシン(sagittarius / aquarius)で正しく gfs2 を使用するための環境なので、物理マシンで使えるフェンスデバイスにする必要がある。
よく見てみたら、fence_scsi というタイプがある。これを使ってみよう。

とりあえず、gemini/cancer 両ノードで共有する1GBのディスクを追加しておく。
これをストレージフェンシングデバイスとして使用してみたい。

OSの再起動等をこなして、/dev/vdc として確認できたら、ストレージフェンシングデバイスを設定してみる。(できるのか？)
と思ったけど、ディスクデバイス側にpersistent reservationの機能が必要みたいで、virtoio 及び scsi passthrough では対応していないっぽい…。

となると、iSCSIデバイスを作ってみるのが正解か。
過去の記事などを参考に、gemini/cancerに1GBの共有iSCSI-LUNが接続されるようにしておく。
合わせて、/dev/vdc は解除しておこう。

で、色々試していってるんだが、どうやら /var/run/cluster/fence_scsi.key と /var/run/cluster/fence_scsi.dev という2つのファイルが必要っぽい。
ただ、/var/run は tmpfs なので、ココのファイルはOS再起動で消えてしまう。
自動で作ってくれる仕組みがあると思うんだが…。

とりあえず fence_scsi のフェンシングデバイスを作成する。
×(gemini) $ sudo pcs stonith create scsi-fence fence_scsi action=off devices=/dev/sda verbose meta provides=unfencing
(gemini) $ sudo pcs stonith create scsi-fence fence_scsi pcmk_host_list="gemini cancer" devices=/dev/sda verbose meta provides=unfencing
meta設定(provides=unfencing)は必要のようだ。

gemini で実行すれば、cancer 側からも確認できる。
(cancer) $ sudo pcs stonith show
 scsi-fence     (stonith:fence_scsi):   Stopped

デバイスとして指定した /dev/sda で、fence_scsi の情報を見てみる。
$ sudo fence_scsi -d /dev/sda -n gemini -o status -v
(略)
0   PR generation=0x0, there are NO registered reservation keys
No registration for key 2b4d0000 on device /dev/sda
Status: OFF

Status は OFF で、 PR の欄を見ると鍵情報が登録されていない。

gemini、cancer の両ノードで、鍵を登録してみる。
(gemini) $ sudo fence_scsi -o on -d /dev/sda -n gemini
(cancer) $ sudo fence_scsi -o on -d /dev/sda -n cancer

(gemini) $ sudo fence_scsi -d /dev/sda -n gemini -o status -v
0   PR generation=0x2, 2 registered reservation keys follow:
    0x2b4d0000
    0x2b4d0001
Status: ON

鍵情報が登録されて、Status が ON になった。

(gemini) $ sudo pcs stonith show
でも、まだ pacemaker 的には stop のままだ。

cleanup すればいいのだろうか…。
(gemini) $ sudo pcs stonith cleanup scsi-fence

実際には、色々試しているうちに動くところまで確認できた。
動き出したのはいいが、cancerで動いている。
(gemini) $ sudo pcs stonith show
 scsi-fence     (stonith:fence_scsi):   Started cancer

これはもしかして…。各ノードごとにフェンスの設定を入れて、自ノードでのみ稼働するように設定する必要があるのだろうか…。
＃fence_virsh などはそのように定義する。2ノードクラスタなら良いのだが、3ノード以上のクラスタの場合はどうするんだろうか…？

やっぱりイマイチ分からん。
とりあえずこのまま進めていくか。

16.04のpacemakerのsystemd定義修正

どうにも挙動がよくわからないので色々調べてみたら、定義に問題がありそうだ…。
/lib/systemd/system/pacemaker.service を見ると、どうもRHEL系の定義っぽい。またパッケージミスかよ。ちなみに、18.04の同ファイルは、.deb系に書き換わっている様子。
ちょっと手直ししておこう。

sudo cp -pi /lib/systemd/system/pacemaker.service /etc/systemd/system/
sudo vi /etc/systemd/system/pacemaker.service
--ココから
23-24行目
EnvironmentFile=-/etc/sysconfig/pacemaker
EnvironmentFile=-/etc/sysconfig/sbd
↓
EnvironmentFile=-/etc/default/pacemaker
EnvironmentFile=-/etc/default/sbd
--ココまで
sudo systemctl daemon-reload
sudo systemctl reboot

とりあえずこれでヨシ。

16.04のpacemakerどうもおかしい

16.04でpacemakerを動かそうと、色々調査を進めてるんだけど、どうもおかしい。
パッケージの内容がRHEL系っぽい。
で、18.04のpacemakerパッケージと比較してみたら、かなりガッツリ修正が入ってるわ。
16.04でpacemaker動かすの諦めて、18.04にバージョンアップしてからpacemaker動かすようにした方がいいのかなー？？

でも、今のメインの環境(sagittarius/aquarius)は、過去に18.04にバージョンアップしたら、gfs2にアクセス出来なくなったしなー…。
どういう順番で作業すべきか…。

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/

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

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