どちらかと言うと「こういう事もあったなー」的なエピソードのまとめです。
systemctl restart network はしてはいけない
死にます。
単一ノードの reboot は問題無くできます。
といって network の restart はノードが fence されてしまってクラスタから切り離されます。
クラスタから切り離されるのはまだ良い方で、最悪 HACluster 全体を巻き込んで死にます。
具体的には gfs2 を mount しているディレクトリに ls したら永遠に返ってこない。
全体を reboot で復活します。
network の configuration を変える時は pcs stop --all とかしてくださいね。
fsck.gfs2 は(直る時もある|直らない時もある)
死んだ時にはファイルが壊れたりするのですが、場合によれば fsck.gfs2 で直ります。
ただし、直らない時もあります。具体的には24時間以上かかっても終わらない。
gfs2 のサイズを大きく(テラオーダー)作ったのが原因かもしれませんが、直らない時は直らないです。
gfs2 を作った後に小さくすることはできませんが、大きくすることはできるます。
なので、最初は小さいサイズから作るのが良さそうです。
CPU/Network の利用率が100%になると fence される
各ノードの死活管理には fence というものを使います。
初期設定だと Network の利用率が100% になった時、ノードがクラスタから外されます。
あとは CPU の使用率が高すぎる時とか。
VMイメージのバックアップを取るためにノードが死んだりしました。
まー1ノードくらい落ちても動くための HACluster だから良いのかもしれないけれど。
umount までできるスクリプトを組んでおく + PowerChute との連携はしっかり
当然ですが、gfs2 上にあるファイルに読み書きしている時には umount できません。
例えば VM を gfs2 に置いてると、destroy する必要があります。
停電した際に電源が UPS に切り替わった時、 umount できないと焦ります。
スクリプトとかを書いておいて、よしなにしてくれるようにした方が良いでしょう。
出来れば pcs で管理して、gfs2 を止める時に kvm で動いている VM を全て destroy した方が良いです。
あとは停電対策として PowerChute とかとも連携すると良いですね。
scsi-shooter は暇なノードに置いておくと良い
fence を行なうノードはクラスタに1つで良いです。
なので、全ノードが fence 用のプロセスを起動している訳ではない。
死活監視のプロセスなので忙しいノードよりは暇なノードに置いた方が良いことが多いです(さっきの100%問題とか)。
公式ドキュメントを読もう
Redhad は公式ドキュメントを豊富に提供しています。
というかgfs2の参考文献とかだと公式ドキュメントしかなかったりします。
設定から何から書かれているので読みましょう。
環境
- OS: CentOS Linux release 7.2.1511 (Core)
- Kernel: 3.10.0-327.10.1.el7.x86_64
- pcs: 0.9.143
