リソースが勝手に再起動する

謎な挙動が2つ見つかっているが、そのうち1つが「vm-leo が稼働してない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう」というものだ。

vm-leo が sagittarius で稼働している状態で、leo にログインしたセッションを作り、sagittairus/aquarius のいずれかで以下のコマンドを実行するとわかる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

で、どのタイミングで vm-leo が再起動するのかを調べるために、以下のように設定した。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

つまり、aquarius では、vm-leo 以外のすべてのリソースの自動起動を停止した。
(vm-leo 自体は、前提となる pool-default-clone が起動しないと起動しないし、そもそも sagittarius 上で起動しているので、aquarius が起動しても影響ないはずなのだが…)

その状態で、まず aquarius のクラスタの停止・起動を実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

なんと、aquarius のクラスタ起動だけで、vm-leo が再起動してしまう。

ということは、クラスタパラメータが関係しているということだ。

$ sudo pcs property show --all

それっぽいパラメータは、enable-startup-probes か。
デフォルト値は true なので、 false に設定してみよう。

$ sudo pcs property set enable-startup-probes=false
$ sudo pcs property show --all

これで aquarius のクラスタ停止・起動を実行してみる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

vm-leo は再起動しなかったと思う。

続いて、リソースを一つずつ許可してみよう。
まずは dlm-clone

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY

大丈夫のようだ。
次は clvmd-clone

$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

ここで vm-leo が再起動してしまう。
更に先を確認するために、vm-leo が復帰したら、shared-pool-clone も確認しておこう。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

ここでも vm-leo が再起動してしまう。
最後に、pool-default-clone だ。vm-leo が復帰してから試してみよう。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

ここでは vm-leo の再起動は発生しない。

vm-leo の基盤となるリソースのうち、clvmd-clone と shared-pool-clone のリソースが起動すると、vm-leo が再起動する。

corosync.log をチェックしてみたら、clvmd-clone が起動すると、なぜか pool-default-clone と vm-leo が restart していた。
clvmd-clone と pool-default-clone の間には、shared-pool-clone が入っているが、そちらは restart になっていない。
う～ん。ということは、clone リソースに何か違いが？
と調べてみたら、いくつか違いがあった。

• dlm-clone
• interleave=true
• ordered=true
• clvmd-clone
• interleave=true
• ordered=true
• shared-pool-clone
• interleave=true
• ordered=(未設定:false)
• pool-default-clone
• interleave=(未設定:false)
• ordered=(未設定:false)

コレ、clone リソース固有のパラメータのようだ。
っていうか、interleave パラメータが関係あるんじゃないか？
というわけで設定してみよう。

$ sudo pcs resource update pool-default-clone meta interleave=true
$ sudo pcs resource show pool-default-clone

そしてもう一度テスト。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY
$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

先程はここで vm-leo が再起動してしまったが、今回は大丈夫のようだ。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

今回、ここでも大丈夫のようだ。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

こちらは問題なし。

というわけで、interleave=true の設定が必要だった。
振り返って過去の設定を見てみたら、ちゃんと interleave=true の設定を入れていた。
ちゃんと設定項目の意味を理解してれば、こんなに悩まなかったのに…。

リソースが勝手に再起動する問題はこれで解決かな？

仮想マシンのクラスタリソース化その2

とりあえず vm-leo が動くところまで行った。
今度はこのリソースを細かく設定する。

まず、リソースの実行順。
vm-leo 自体は、default プールを使用している。そのため、vm-leo の起動の前提条件として、 default プールの有効化、つまり pool-default-clone を前提にする必要がありそうだ。
それを設定する。

$ sudo pcs constraint order start shared-pool-clone then vm-leo

続いて、リソースの実行条件。
当然、shared-pool の起動に成功したノードと同じノードでないと、vm-leo を動かすわけにはいかない。
その制約をつける。

$ sudo pcs constraint colocation add vm-leo with shared-pool-clone

このままでもいいんだけど、何故かいつも aquarius から起動しようとしてしまう。
gemini/cancer でクラスタ組んで、簡単なリソーステストを行っていた時も、 gemini をプライマリノードにしたいのに、なぜか cancer から起動しようとしてた。
多分、ノード名のアルファベット順で若い方を優先してしまうのではないか？と思っている。
で、vm-leo は sagittarius をプライマリノード、aquarius をスレーブノードとして定義したい。
(sagittarius に問題が無ければ sagittarius で起動、問題がある場合は aquarius で起動、みたいな)
以下のように実行する。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs constraint location vm-leo prefers sagittarius=100 aquarius=50
$ sudo pcs resource enable vm-leo
$ sudo pcs status

どうだろう？ vm-leo は sagittarius で起動してきたのではないだろうか？

今回は一旦ココまでにするが、まだ問題が2つ残っている。

1. vm-leo が稼働していない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう
2. vm-leo が稼働しているノードを再起動しようとすると、dlm がハングしてしまう

の2点だ。
ちょっと調べたがまだ解決していない。
解決できるか分からないが、次回からちょっと調査をする。

仮想マシンのクラスタリソース化その1

これまでの作業で、 gfs2 を pacemaker で運用する方法が固まった。

で、 pacemaker を調べていく過程で、リソースエージェントに ocf:redhat:vm.sh と ocf:heartbeat:VirtualDomain の2つが存在することに気付いた。
これ、KVM等の仮想マシンをリソース化するものっぽい。
ってことは、pcs コマンドで仮想マシンを起動停止させたり、sagittarius から aquarius へのマイグレーションが出来たりするのかもしれない。

pacemaker化 の最後に、これを試してみたい。
リソースエージェントに redhat版と heartbeat版 があるのだが、これまでずっと heratbeat版 を使っていたので、今回も heartbeat版 で進めてみる。

まずは設定内容の確認

$ sudo pcs resource describe ocf:heartbeat:VirtualDomain

必須パラメータは config だけだけど、libvirt自体は様々なハイパーバイザに対応しているので、qemu/kvm用のハイパーバイザを指定する必要はある。
それ以外はとりあえずデフォルトのままで作ってみよう。仮想マシンは leo でいいかな？

$ sudo pcs resource create vm-leo \
 ocf:heartbeat:VirtualDomain \
 config="/etc/libvirt/qemu/leo.xml" \
 hypervisor="qemu:///system" \
 meta op start timeout="120s"
$ sudo pcs status

おっと！？いきなりコケてるぞ？いや、ちょっと待ってから再確認すると、vm-leo を aquarius で起動しようとして失敗し、sagittarius で起動成功、という流れのようだ。

いろいろ調査したんだけど、非常にツマらない理由だった。
今回の pacemaker化 の主旨とは全く異なるポイントだったんだけど、メモしておく。

この辺りは、各人の持っているPCのスペックに依るところが大きいので、あくまで参考程度に見てほしい。

それぞれのホストマシンで使っているCPUは以下の通り。

• sagittarius : Intel core i7-6700
• aquarius : Intel core i7-5557U

CPUの世代が1世代違うだけでなく、aquarius の方はノート用の省電力モデルだ。
で、5557UというCPU、Broadwell世代なんだけど、TSXという機能に対応していない。

で、仮想マシン leo の方の仮想CPU定義はと言うと… Broadwell にしている。
仮想マシンのCPU定義が Broadwell の場合、ホスト側のCPUにもTSXという機能が必要なので、5557U というCPU上で動かすことは出来ない。
仮想マシン側の CPU定義を Broadwell-noTSX か、それ以下のモデルにする必要があるようだ。
つまり、今までパワーのある sagtitarius 上で色々検証していたけど、実は aquarius では動かない検証をしていた、ということだ。ナンテコッタイ。

調べてみたら、多くの仮想マシンが仮想CPUを Broadwell と指定してて、ほとんど aquarius では動かせないことが判明。
とりあえず leo だけでも直しておこう。

まずは vm-leoリソースを停止。

$ sudo pcs resource disable vm-leo
$ sudo pcs status
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all

leoが止まっているのを確認しておく。

そしたら、leo の定義変更だ。

(aquarius) $ virsh edit leo
(sagittarius) $ virsh edit leo

---
cpuの <model> の部分を Broadwell から Broadwell-noTSX に書き換える。
---

変更出来たら、まずは各ノードで手作業で上げてみよう。

(aquairus) $ virsh start leo
(aquarius) $ virsh list --all

起動したら leo にログインして、シャットダウンしておこう。

(leo) $ sudo systemctl poweroff

sagittarius でも。

(sagittarius) $ virsh start leo
(sagittarius) $ virsh list --all

起動確認が出来たら leo をシャットダウンしておく。

(leo) $ sudo systemctl poweroff

ココまでが、各人の環境に応じて差が出る部分だ。

leo が両ノードで動かせるのが確認できたら、vm-leoリソースをクリーンナップして起動してみる。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs resource enable vm-leo
$ sudo pcs status

今度は無事に aquarius で動き出した。
aquarius 側で virsh を使ってみると、動いていることがわかるはずだ。

(aquarius) $ virsh list --all

これで vm-leo が動かせるようになったが、まだ設定しておかなければならない項目がある。
起動条件、起動順と起動ノードの優先順、マイグレーション設定だ。
ちょっと長くなってしまったので、これは次回に回す。
っとその前に、vm-leo を停止させて、自動的に上がってこないように抑えておこう。

$ sudo pcs resource disable vm-leo
$ sudo pcs status

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 にも同じ作業を適用しておこう。

ストレージプールのStart/Stopをリソース化

前回、gfs2マウントまでリソース化して、これで環境が整ったかと思ったんだけど、別の問題が発生した。
kvm/libvirt で default という名前がつけられたストレージプールが空っぽになってしまっている、という状態だ。
default というストレージプール、実際のパスは /var/lib/libvirt/images になっている。

そもそも、 /var/lib/libvirt 自体が外部ディスクで、今回の一連の作業でこの領域のマウント自体をクラスタ制御にした。

考えてみたら当たり前で、/var/lib/libvirt のマウントより先に、kvm/libvirt が起動する。kvm/libvirt では default ストレージプールは自動起動になっているため、/var/lib/libvirt がマウントされる前に default ストレージプールが起動してきて、中身が空っぽの /var/lib/libvirt/images を見て、空のストレージプールとして定義された、というわけだ。
(ウチの環境では、/var/lib/libvirt のマウント前に、/var/lib/libvirt/images というディレクトリが存在している。もし存在して無ければ、 default プールの自動起動に失敗し、default プールが停止していると思う。)

ストレージプールを start する作業を gfs2 ファイルシステムマウントの後に、stop する作業を gfs2 ファイルシステムマウントの前に実行する必要がある。

gfs2 マウントがクラスタリソースなので、ストレージプールの stop/start もクラスタリソースとして定義してしまうのがスマートだろう。

ということで、ストレージプールの start/stop をするリソースエージェントを探したのだが…見つからない。存在していないようだ。

ということは、リソースエージェントを自作する必要があるということだ。
面倒だが、この辺を参考に作っていくことにしよう。

まずは、リソースエージェントを配置するパス。
/usr/lib/ocf/resource.d/プロジェクト名/ に配置することになるらしい。他の環境と被って欲しくないので、プロジェクト名は kvmcluster にしよう。
$ sudo mkdir /usr/lib/ocf/resource.d/kvmcluster

そして、とりあえず以下のようにファイルを作成してみる。
$ sudo vi /usr/lib/ocf/resource.d/kvmcluster/virt-pool
-----ココから

#!/bin/bash
#
#   Resource Agent for libvirt storage pool resources.
#
#   License:      GNU General Public License (GPL)
#   Original
#
# Initialization:
: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs
virt_pool_meta_data() {
cat <<EOF
<?xml version="1.0"?>
<!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
<resource-agent name="virt-pool">
  <version>0.1</version>
  <longdesc lang="en">
This is a resource agent to start / stop libvirt storage-pool.
  </longdesc>
  <shortdesc lang="en">start / stop storage-pool</shortdesc>
  <parameters>
    <parameter name="poolname" unique="0" required="1">
      <longdesc lang="en">
      Name of Storage pool
      </longdesc>
      <shortdesc lang="en">Pool Name</shortdesc>
      <content type="string"/>
    </parameter>
  </parameters>
  <actions>
    <action name="start"        timeout="20" />
    <action name="stop"         timeout="20" />
    <action name="monitor"      timeout="20"
                                interval="10" depth="0" />
    <action name="meta-data"    timeout="5" />
    <action name="validate-all"   timeout="20" />
  </actions>
</resource-agent>
EOF
}
virt_pool_usage() {
    return $OCF_SUCCESS
}
virt_pool_validate_all() {
    #check_binary virsh
    ocf_run -q virsh pool-info $OCF_RESKEY_poolname
    case "$?" in
        0)
            rc=$OCF_SUCCESS
            ocf_log debug "poolname is OK"
            ;;
        1)
            rc=$OCF_ERR_CONFIGURED
            ocf_log err "No pool"
            ;;
    esac
}
virt_pool_monitor() {
    local rc
    # 設定が不正な場合は即終了する
    virt_pool_validate_all || exit $?
    virsh pool-info $OCF_RESKEY_poolname | grep State: | grep running > /dev/null 2>&1
    # 0: pool-start済
    # 1: pool-stop済
    # それ以外: エラー
    case "$?" in
        0)
            rc=$OCF_SUCCESS
            ocf_log debug "Resource is running"
            ;;
        1)
            rc=$OCF_NOT_RUNNING
            ocf_log debug "Resource is not running"
            ;;
        *)
            ocf_log err "Resource has failed"
            exit $OCF_ERR_GENERIC
    esac
    return $rc
}
virt_pool_stop() {
    ocf_run -q virsh pool-destroy $OCF_RESKEY_poolname
    return $OCF_SUCCESS
}
virt_pool_start() {
    ocf_run -q virsh pool-start $OCF_RESKEY_poolname
    return $OCF_SUCCESS
}
case $__OCF_ACTION in
meta-data)      virt_pool_meta_data
                exit $OCF_SUCCESS
                ;;
usage|help)     virt_pool_usage
                exit $OCF_SUCCESS
                ;;
esac
virt_pool_validate_all || exit $?
case $__OCF_ACTION in
start)          virt_pool_start;;
stop)           virt_pool_stop;;
status|monitor) virt_pool_monitor;;
validate-all)   virt_pool_validate_all;;
*)              virt_pool_usage
                exit $OCF_ERR_UNIMPLEMENTED
                ;;
esac
rc=$?
ocf_log debug "${OCF_RESOURCE_INSTANCE} $__OCF_ACTION returned $rc"
exit $rc

-----ココまで
必要最小限の機能だけ盛り込んだ。
エラーハンドリング等、甘い部分もあるが、とりあえずの実装なので良しとする。
正規のリソースエージェントがリリースされたら、それに移行すればいい。

作成したらパーミッション変更。
$ sudo chmod 755 /usr/lib/ocf/resource.d/kvmcluster/virt-pool

テスターがあるので実行してみる。
テストの時、実際にプールのStart/Stopが行われるので、default プールは止めておく。
また、合わせて default プールの自動起動も止めておく。(sagittarius/aquarius 両方やっておくのを忘れないように)
$ virsh pool-destroy default
$ virsh pool-autostart default --disable
$ virsh pool-list --all

そしたらテスター実行
$ sudo ocf-tester -n ocf:kvmcluster:virt-pool -o poolname=default /usr/lib/ocf/resource.d/kvmcluster/virt-pool
最後に
/usr/lib/ocf/resource.d/kvmcluster/virt-pool passed all tests
と出てきたらなんとか成功だ。
もしダメだったら、詳細表示状態でテスターを実行してみよう。もしかしたら何が悪いか分かるかも。
$ sudo ocf-tester -v -n ocf:kvmcluster:virt-pool -o poolname=default /usr/lib/ocf/resource.d/kvmcluster/virt-pool

さて、このリソースエージェントを使って、defaultプールの start/stop を作るのだが…認識されているかな？
$ sudo pcs resource list
どうやら出てきたようだ。

詳細は？
$ sudo pcs resource describe ocf:kvmcluster:virt-pool
出た。

じゃぁコレを使ってリソースを作ってみよう。
$ sudo pcs resource create pool-default ocf:kvmcluster:virt-pool \
  poolname=default \
  --clone \
  --disabled

$ sudo pcs resource show
pool-default-clone が定義されたはずだ。
ただ、今はまだ disabled のはず。

$ sudo pcs resource show pool-default-clone
詳細も見える。

リソースの前後関係・起動ノード関係を設定しておく。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start shared-pool-clone then pool-default-clone
$ sudo pcs constraint colocation add pool-default-clone with shared-pool-clone
$ sudo pcs constraint show --full

設定できたらリソースを有効化してみよう。
$ virsh pool-list --all
$ sudo pcs status
$ sudo pcs resource enable pool-default
$ sudo pcs status
$ virsh pool-list --all
無事に defaultプール が起動してきたはず。
念のために中身も見てみよう。
$ virsh vol-list default
中身も見れる。

shared-pool-clone が落ちれば、pool-default-clone も落ちるはず。
$ sudo pcs status
$ sudo pcs resource disable shared-pool-clone
$ sudo pcs status
落ちた。
$ sudo pcs resource enable shared-pool-clone
$ sudo pcs status
上がった。

OS再起動等して、リソースが起動、プールが起動するところも確認しておこう。

問題が無ければ、このあたりで一度システムバックアップを取得しておこう。
1台ずつ、クラスタを停止してからバックアップを取るように。
$ sudo pcs cluster stop aquarius --force
$ sudo pcs status
(ここでaquariusをバックアップ)
$ sudo pcs cluster start aquarius
$ sudo pcs status
$ sudo pcs cluster stop sagittarius --force
$ sudo pcs status
(ここでsagittariusをバックアップ)
$ sudo pcs cluster start sagittarius
$ sudo pcs status

ふぅ。これでなんとかなったか？
あと少し、整理・調整したいので、もう少し続ける。

各種リソース作成

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

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

• 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 だ。

fence-agent のインストールと設定

dlm を使用するのなら、stonith/fence の設定が必須らしい。参ったな。
というわけで、インストールと設定を行おう。

$ sudo apt-get update
$ sudo apt-get install fence-agents

さて、フェンスデバイスだが…、今回使用している環境は、ベアメタル、所謂物理マシンだ。
しかも普通のPCで、IPMIは搭載していない。UPSに繋いでいるわけでもない。
使えそうなのは

• fence_mpath
• fence_sbd
• fence_scsi

あたりか…。ubuntu 1604 だと、fence_sbd は使えなかったような気がする…。

となると、fence_scsi か fence_mpath だけど、こちらはほぼ同じモノのようだ。
使うデバイスは、SCSI-3 PR(Persistend Reservation)に対応した共有ディスク。
iSCSI や FCデバイスだけど、家で FCデバイス なんて運用していない。
また、multipathd を動かしているので、fence_mpath を使うことになると思うのだが…。
fence_mpath は fence_scsi と違い、keyパラメータを指定する必要がある。
が…、「ノードごとに固有に設定」なのに、pcs stonith create で一発指定…。ノードごとにどうやって指定するのか分からない…。
デバイスは multipath にしておいて、stonith は fence_scsi でやってみるか。

しょうがないので、iSCSIストレージから、1GBの共有ディスクを追加する。混乱しないように「fence-device」とでも名付けておくか。

dmesg で確認すると sagittarius で /dev/sdk 、aquarius で /dev/sdi というデバイスで認識された。
(sagittarius) $ sudo multipath -a /dev/sdk
wwid が見える。(今回は 23166363164363639 だった)
(sagittarius) $ sudo vi /etc/multipath/bindings
-----
見つかったwwidを追加する。
fence-device 23166363164363639
-----
(sagittarius) $ sudo multipath -r /dev/sdk
これで、/dev/mapper/fence-device として認識されたはずだ。

aquarius でも同様に。
(aquarius) $ sudo multipath -a /dev/sdi
(aquarius) $ sudo vi /etc/multipath/bindings
-----
wwidの追加
fence-device 23166363164363639
-----
(aquarius) $ sudo multipath -r /dev/sdi

そうしたら、stonith/fence の設定だ。
fence_scsi は、デフォルトでは /var/run/cluster ディレクトリの下に情報を書き込む。
ところが、/var/run は tmpfs で、OS再起動のたびに中身が綺麗サッパリ消えてしまう。
そのため、/var/run/cluster というディレクトリそのものも消えてしまい、fence_scsi がファイルを作成するのに失敗してしまう。

/var/run 以下は tmpfiles という仕組みによって、OS起動時に作成してくれるのだが、そのための設定ファイルが漏れている。
もしかしたら、Ubuntu1604のバグで、Ubuntu1804なら解決しているのかもしれないが…。

というわけで、OS起動時に /var/run/cluster ディレクトリが作成されるように設定ファイルを作っておく。
細かいところや配置ディレクトリは個別に調べてもらうとして、sagittarius/aquarius で以下のように実行。
$ sudo vi /etc/tmpfiles.d/var-run.conf
-----中身は以下の1行
d /var/run/cluster - - - -
-----
これを作成したら、OS再起動して反映させよう。
$ sudo systemctl reboot
$ ls -ld /var/run/cluster
ディレクトリが作成されているはずだ。

やっと準備が出来た。stonith/fence の作成だ。
(sagittarius) $ sudo pcs stonith create scsi-fence fence_scsi \
  pcmk_host_list="sagittarius aquarius" \
  devices=/dev/mapper/fence-device \
  verbose \
  meta provides=unfencing

$ sudo pcs status
いきなり scsi-fence が動き出したと思う。
＃動いていなければ、sudo pcs resource cleanup scsi-fence 等でクリーンアップしよう。

scsi-fence は、稼働しているノードがダウンしたら、もう片方のノードで動き出すはずだ。
sagittarius/aquarius を交互にリブートしてみて、sudo pcs status で確認してみよう。
問題なく動いていたら、stonith/fence の完成だ。

これでようやくリソースの作成に入れるかな？

クラスタパラメータ設定

ここまで設定できれば、ブラウザからもアクセス出来ると思う。
ブラウザを起動して、https://(sagittariusかaquariusのIP):2224/ にアクセスすれば、ブラウザから設定確認や設定変更が出来るんじゃないか？
と思ったけど、pcsd(ブラウザでアクセスする先のサービス)に、今回のクラスタを組み込ませていなかった。
ブラウザでアクセスし、Add Existing から組み込んでおこう。設定をブラウザから確認できるのはなんだかんだ便利だ。

クラスタの基本パラメータを設定しておこう。
今作っているクラスタは2Nodeで、既にcorosync.confには2Nodeパラメータは設定されている。
設定しておきたいのは

• 片方落ちていて、片方しか動かせない時の起動時状態
• スプリットブレイン時に働くstonithをどうするか？
• スプリットブレインが発生した時の各ノードグループの動作

の3点。
今回の構成的には、
ハートビート/Stonith用のLANは存在しない。(サービスLANと共有)
ストレージはiSCSIで、専用LANは無い。(サービスLANと共有)
だ。
そもそもスプリットブレインが発生するシチュエーションはほとんど無い。
そのため、後者2点はほとんど考えなくて良いのだが、一応設定しておく。

まずは1点目。
ただ、これを実行すると、作ったクラスタが破壊されて再構築される。今はまだ何も設定していないから大丈夫なはずだ。
(sagittarius) $ sudo pcs cluster setup --name kvmcluster sagittarius aquarius --wait_for_all=0 --force
(sagittarius) $ sudo pcs cluster start --all
(sagittarius) $ sudo pcs cluster enable
せっかく作ったクラスタが破壊されて作り直されるのが嫌なら、以下の手順だ。
(sagittarius) $ sudo pcs cluster stop --all
(sagittarius) $ sudo vi /etc/corosync/corosync.conf
-----
two_node: 1 の上に、以下の行を追加する。
wait_for_all: 0
-----
(sagittarius) $ sudo pcs cluster sync
(aquarius) $ sudo cat /etc/corosync/corosync.conf
wait_for_all:0 が反映されているのを確認する。

wait_for_all の設定が出来たら、反映を確認しておこう。
$ sudo corosync-quorumtool -s
Flags に有ったはずの WaitForAll が無くなったはずだ。

これで、片方故障していても、起動停止出来るはずだ。
試してみよう。
(sagittarius) $ sudo pcs cluster stop aquarius --force
(sagittarius) $ sudo pcs status
aquariusが切り離されたはず。
(sagittarius) $ sudo pcs cluster stop sagittarius --force
(sagittarius) $ sudo pcs status
クラスタダウンしている。
(sagittarius) $ sudo pcs cluster start sagittarius
(sagittarius) $ sudo pcs cluster enable sagittarius
(sagittarius) $ sudo pcs status
1ノード(sagittarius)のみでも、partition with quorum になったはずだ。
(sagittarius) $ sudo corosync-quorumtool -s
Quorate が Yes のはず。
これで「片方落ちていて、片方しか動かせない時の起動状態」の設定が完了。

次は stonith だ。過去には色々検証したが、今の構成だと stonith はあまり意味が無いと思われるので、無効化してしまう。
$ sudo pcs property show --all
stonith-enabled: が true になっているはずだ。
これを無効化してしまおう。
$ sudo pcs property set stonith-enabled=false
$ sudo pcs property show --all
stonith-enabled: が false に変わったのが確認できるはずだ。

と思ったのだが、stonith-enabled が falseの場合、dlm や dlmに依存するリソース(clvmやgfs2)が起動できなくなるようだ。
ということで、デフォルトに戻しておこう。
$ sudo pcs property set stonith-enabled=
$ sudo pcs property show --all
これでデフォルト(true)に戻った。

ってことは、fence-device も定義しないとアカンのかなー。

最後に、スプリットブレイン(というか、2ノードなのでクォーラムロストか)が発生した時の挙動だ。
$ sudo pcs property show --all
no-quorum-policy: が stop に設定されている。これを freeze に設定し直す。
$ sudo pcs property set no-quorum-policy=freeze
$ sudo pcs property show --all
設定が変わったのが確認できる。
ちなみに、no-quorum-policyは、stop/freeze/ignore/suicide の4つが指定出来るようだ。

これで、基本的な初期パラメータ設定はおしまいかな。

クラスタ作成

さて、ココからクラスタを構築していく。

ノード間のhaclusterの結びつけ。
これは確か、片方のノードから実施すればOKだったはずだ。
(sagittarius) $ sudo pcs cluster auth sagittarius aquarius -u hacluster
sagittarius/aquairsuの両方ともAuthorizedになればOK。

続いてクラスタ構築。
こちらも片方から実施すればOK。
クラスタ名は、既に gfs2 で使っている kvmcluster にしないと、ファイルシステムマウントでコケるはずなので、間違えないように。
(sagittarius) $ sudo pcs cluster setup --name kvmcluster sagittarius aquarius
Success になっていればOK

ちょっと見てみよう。
$ sudo pcs status
おっと、まだクラスタ起動していないか。

クラスタを起動させる。
(sagittarius) $ sudo pcs cluster start --all

もう一度確認。
$ sudo pcs status

おや、corosyncとpacemakerが自動起動になっていないっぽいぞ？
確認してみる。
$ sudo systemctl status corosync
$ sudo systemctl status pacemaker

自動起動にしておくか。
ここでpacemakerを自動起動にするかどうかは、クラスタの運用ポリシーによる。
自動起動になっている場合、サーバ障害が発生し、片肺運転になった後、サーバ復旧すると、自動的にクラスタに組み込まれてしまう。
OSの稼働を確認し、問題ないと判断できてからクラスタに組み込むような信頼性を求める場合は、自動起動はOffにしておいた方がいいかもしれない。
$ sudo systemctl is-enabled corosync
$ sudo systemctl enable corosync
$ sudo systemctl is-enabled corosync
$ sudo systemctl is-enabled pacemaker
$ sudo systemctl enable pacemaker
$ sudo systemctl is-enabled pacemaker

$ sudo pcs status

OS再起動して確認しておこう。
$ sudo systemctl reboot
$ sudo pcs status

作成されている corosync.conf も確認しておこう。
$ cat /etc/corosync/corosync.conf
sagittarius と aquarius が nodelist に入っていて、two_node フラグが付与されているのが確認できるはずだ。
$ sudo corosync-quorumtool -s
Expected votes が 2、Quorum が 1、Flags に 2Node Quorate WaitForAll がついているのが確認できる。

ココまで確認できたら、クラスタの初期構築は完了だ。
次はクラスタの基本パラメータの設定を行う。

おっと忘れてた。Ubuntu1604のpacemakerは、インストーラのバグなのか、/etc/corosync/uidgid.d というディレクトリが作られない。
無くても稼働に問題はないが、一応作っておこう。
$ sudo mkdir /etc/corosync/uidgid.d
$ sudo chmod 755 /etc/corosync/uidgid.d
$ sudo chown root:root /etc/corosync/uidgid.d

クラスタ定義の削除

次はクラスタ定義の削除だ。

これまで、手作業でcorosync等の設定を実施していたが、これらのファイルが存在する状態でpacemakerでクラスタを組もうとすると、「このノードは既に他のクラスタに組み込まれているで」とエラーになってしまう。

というか、corosync.conf が残っているので、中途半端にクラスタが組まれている状態になっている。
$ sudo pcs status

そのため、クラスタ定義(corosync.conf)を削除する。
コマンド一発で実施できるので、それで構わない。
$ ls -l /etc/corosync
$ sudo pcs cluster destroy
$ sudo pcs status
$ ls -l /etc/corosync
他にも、/etc/corosync に過去のゴミが残っていたら削除しておこう。

これでキレイになったので、次回からクラスタの構築だ。

hacluster アカウントにパスワードを付与

pacemakerのインストールが終わったら、haclusterというアカウントが出来ているはずだ。
こちら、pcsd同士の通信に使うものなので、クラスタを構成するサーバ(sagittarius/aquairus)全体で統一のパスワードを設定しておく。
$ sudo passwd hacluster
それだけ。

pcs のインストール

続いて、pcsのインストールだ。
コレをインストールすれば、pacemaker諸々インストールされるので、まとめてインストールしておく。
$ sudo apt-get update
パッケージ追加インストールの前に、最新のパッチは適用しておこう。
$ LANG=C sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot

リブートが終わったらパッケージインストール。
$ sudo apt-get update
$ sudo apt-get --simulate install pcs
$ sudo apt-get install pcs

インストール終わったら、念の為OS再起動しておこう。
$ sudo systemctl reboot

最後に、systemdのサービス状態をチェック。failedが無ければ一旦終了。
$ systemctl status

dlm.conf の削除

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

dlm.service の停止と自動起動解除

dlm.service も同様に実施する。

同じく、両方のサーバで実施だ。
$ systemctl status dlm.service
$ sudo systemctl stop dlm.service
$ systemctl status dlm.service
$ systemctl is-enabled dlm.service
$ sudo systemctl disable dlm.service
$ systemctl is-enabled dlm.service

こちらも念の為、再起動しておこう。
$ sudo systemctl reboot
$ systemctl status dlm.service

おしまい。

clvmdの停止と自動起動解除

さて、clvmdの停止と自動起動解除だ。
clvmd自体、クラスタリソースにする予定なので、このタイミングで解除しておく。
が、clvmd自体は他のサービスに紐付けられて起動している。
lvm2-cluster-activation.service のようだ。

やっぱり、sagittairus/aquarius 両方の作業だ。
$ systemctl status lvm2-clvmd.service
$ systemctl status lvm2-cluster-activation.service
$ sudo systemctl stop lvm2-cluster-activation.service
$ systemctl status lvm2-cluster-activation.service
$ systemctl status lvm2-clvmd.service
$ sudo systemctl is-enabled lvm2-cluster-activation.service
$ sudo systemctl disable lvm2-cluster-activation.service
$ sudo systemctl is-enabled lvm2-cluster-activation.service

一度再起動して確認しておこう。
$ sudo systemctl reboot
$ systemctl status lvm2-cluster-activation.service
$ systemctl status lvm2-clvmd.service
両方止まっていたら完了だ。

/var/lib/libvirt の自動マウント解除

仮想マシンの停止が終わったら、/var/lib/libvirt をアンマウント、自動マウントの解除をする。
クラスタ化する上で、各種サービスの停止などもあるので、アンマウントしないと作業が続行できない。
ちなみに、初期には /etc/libvirt、/var/lib/libvirt、/var/log/libvirt を共有ボリュームとして定義していたが、結局 /var/lib/libvirt 以外は共有化させる意味が無かったので、解除している。

作業は sagittarius/aquarius 両方で実施すること。
$ grep /var/lib/libvirt /etc/mtab
$ sudo systemctl stop /var/lib/libvirt
$ systemctl status /var/lib/libvirt
$ grep /var/lib/libvirt /etc/mtab

アンマウントしたら、自動マウントを解除する。
$ grep /var/lib/libvirt /etc/fstab
$ sudo vi /etc/fstab
-----
/var/lib/libvirt をマウントしている行をコメント化する
-----
$ sudo systemctl daemon-reload
$ systemctl status /var/lib/libvirt
定義が消えていたらOKだ。

どうやら、過去の作業で内蔵ディスクの方の /var/lib/libvirt を空にしていなかったらしい。
ま、いいか。

仮想マシンの全停止

続いて、仮想マシンを全停止させる。
理由は簡単で、これからsagittarius/aquariusをpacemakerクラスタ化させる上で、クラスタリソースにする予定の/var/lib/libvirtをアンマウントしないといけないからだ。
OSの再起動も発生するかもしれないしね。

というわけで、稼働している仮想マシンは全停止させておこう。

/etc/hostsにエントリ追加

さて、最初はsagittarius/aquariusで相互に名前解決できるように、/etc/hostsにエントリ追加だ。
どちらのホストも、デフォルトで127.0.1.1が自分のホスト名を指すようになっていると思う。
それをコメントにして、自身のIPと自身のホスト名、相手のIPと相手のホスト名を記載しよう。
(sagittarius) $ sudo vi /etc/hosts
-----
以下の行はコメント化
127.0.1.1       sagittarius
以下の2行を追記
192.168.55.130  sagittarius
192.168.55.131  aquarius
-----
名前解決できているか確認。
(sagittarius) $ ping -c 4 sagittarius
(sagittarius) $ ping -c 4 aquarius
どちらも、192.168.55.*のアドレスにping打てていればOKだ。

続いてaquarius
(aquairus) $ sudo vi /etc/hosts
-----
以下の行はコメント化
127.0.1.1       aquairus
以下の2行を追記
192.168.55.130  sagittarius
192.168.55.131  aquarius
-----
(aquarius) $ ping -c 4 sagittarius
(aquarius) $ ping -c 4 aquarius
アドレスに間違いがなければOK。

簡単だけどココまで。

ホストのpacemaker化作業リスト

さて…ホスト側である sagittarius/aquarius は、/var/lib/libvirt も共有化している。
これ、本当に共有していいのだろうか…？

それはとりあえず置いておいて、sagittarius/aquarius を pacemaker化するための作業リストを作っておこう。
抜け漏れはあると思うので、都度追記していく。

1. /etc/hosts に相互に名前解決できるようにエントリ追加
2. 仮想マシンの全停止
3. /var/lib/libvirt の自動マウント解除
4. clvmdの停止と自動起動解除
5. dlm.service の停止と自動起動解除
6. dlm.conf の削除
7. pcs のインストール
8. hacluster アカウントにパスワードを付与
9. クラスタ定義の削除
10. クラスタ作成
11. クラスタパラメータ設定
12. fence-agent のインストールと設定
13. dlmリソース、clvmdリソース、gfs2リソース作成
14. ストレージプールのStart/Stopをリソース化
15. systemd設定見直し
16. 仮想マシンのクラスタリソース化その1
17. 仮想マシンのクラスタリソース化その2
18. リソースが勝手に再起動する
19. fence_scsi がコケる
20. ノード再起動で dlm がハング(他にも問題発生、一旦停止)

といった感じだろうか…。
次回からこれに合わせて設定していこう。

一旦20項目書いたが、色々問題が出てきたのでここで切る。
18.04 にバージョンアップ後、別途書こうと思う。

ホスト側のpacemaker化の前に

pacemakerでgfs2を運用する方法がある程度見えてきたので、メインマシンのホスト(sagittarius/aquarius)のpacemaker化を進めたい。
が、その前にやっておかなきゃいけないことがある。

今、KVMホストであるsagittarius/aquariusの2台は、/etc/libvirtと/var/lib/libvirtの2箇所をgfs2で共有している。
が、調べてみたら/etc/libvirtはやはり、共有化してはいけないことが分かった。

というわけで、両サーバとも/etc/libvirtをローカル化(内蔵ディスク化)することにする。
サイズは1GBもあれば十分。
空き領域を確認する。
$ sudo vgdisplay vg-root
Free PE / Size が数十GB空いていればOKだ。(システムバックアップ取得のために、スナップショット領域を必要とするので、1GBきっちりしか空いてなかったらダメだぞ)

$ sudo lvcreate -L 1G -n lv-etc-libvirt vg-root
$ sudo mkfs.ext4 /dev/vg-root/lv-etc-libvirt
暫定のマウントポイントを作成する。
$ sudo mkdir /mnt/libvirt
マウント
$ sudo mount /dev/vg-root/lv-etc-libvirt /mnt/libvirt

そしたら、ファイルをコピーする。
$ cd /etc
$ sudo tar cSf - libvirt | (cd /mnt ; sudo tar xSf -)
$ sudo ls -alR /etc/libvirt > /tmp/etc-libvirt-gfs2.list
$ sudo ls -alR /mnt/libvirt > /tmp/etc-libvirt-ext4.list
$ diff -w /tmp/etc-libvirt-gfs2.list /tmp/etc-libvirt-ext4.list
ディレクトリのサイズ差が若干あるのは、gfs2とext4のファイルシステムの違いによるものだ。lost+foundの有無も同様。

ファイルコピーが終わったら、一時マウントを解除し、暫定マウントポイントを削除する。
$ sudo umount /mnt/libvirt
$ sudo rmdir /mnt/libvirt

続いて、既存の/etc/libvirtをアンマウントし、/etc/fstabを書き換え、新しい/etc/libvirtをマウントする。
$ sudo systemctl stop /etc/libvirt
$ sudo vi /etc/fstab
-----
/etc/libvirtのマウント行をコメント化し、以下の行を追加する。
/dev/mapper/vg--root-lv--etc--libvirt /etc/libvirt ext4 defaults 0 2
-----

マウントする
$ sudo systemctl daemon-reload
$ sudo systemctl start /etc/libvirt
$ df /etc/libvirt
$ grep /etc/libvirt /etc/mtab
新しいファイルシステムの方(vg-rootの方)がマウントされていたら、念の為libvirt-binをリロードする。
$ sudo systemctl reload libvirt-bin
$ virsh list --all

システムバックアップの対象ボリュームが増えたので、定義ファイルを追加しておく。
$ sudo -i
# cd ~/backup/etc/fsconfig
# vi 0030_lv-etc-libvirt
-----
#
# USELVM:
# Area to be backed up or LVM region, simple partition of the flag.
# Specify a Yes in the case of LVM of LVOL area.
#
USELVM=Yes

#
# VOLNAME:
# You want to specify the volume device name of the target volume.
# For simple partition, sda1 and sda2 like.
# You can easily find LVM of LVOL area, specify the LVOL name (lvol1, etc.).
#
VOLNAME=lv-etc-libvirt

#
# MOUNTPOINT:
# Specify the mount point of the target area.
#
MOUNTPOINT=/etc/libvirt

#
# SNAPSIZE:
# If the area of interest was the LVM region, we want to create
# a LVM Snapshot.
# It will specify the capacity of the Snapshot area.
# ex.
#   SNAPSIZE=32M
#   SNAPSIZE=320M
# If you specify a larger size than the capacity of the backup target,
# it will be the same capacity as the size of the backup target.
#
SNAPSIZE=32M
-----

定義ファイルが作成できたら、バックアップを取っておこう。
# cd ~/backup/bin
# ./0000_backup
# exit

sagittarius/aquariusの両方で実施すること。
kvmclusterの方のetc-libvirt(旧/etc/libvirt)は念のために暫く残しておこう。

この後は、sagittarius/aquairusにpacemakerを導入し、gfs2をpacemakerで運用するための設定だ。
そして、1804へのアップグレードも控えている。
うまく進むといいけどな。

あれ？libvirt-binとか、pacemakerのリソースにしないとアカン？

gfs2をpacemakerで使用するための前提を色々調査していたけど…。

gfs2を複数ノードで使用するためには、clvmdとdlmが必要。

gfs2はKVMの仮想ディスク領域で使用。

ということは、KVMの構成要素であるlibvirt-binとかもpacemakerのクラスタリソースに入れて、gfs2より後に起動しないとアカンのかな？

いや、でも仮想マシンが起動していない限り、特に仮想ディスク領域を使用している様子は無いな…。

pacemakerのリソースには入れずに実行してみて、ダメだったらリソースに入れるか。

というわけで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の設定も、クラスタのプロパティも同じなのに、この違い。
なんだこりゃ…。