2017/10/12

CentOS7 で GFS2 を構築/本番運用したノウハウまとめ

GFS2 を構築したり運用した時のノウハウを共有。
どちらかと言うと「こういう事もあったなー」的なエピソードのまとめです。


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%問題とか)。


公式ドキュメントを読もう

というかgfs2の参考文献とかだと公式ドキュメントしかなかったりします。
設定から何から書かれているので読みましょう。


環境

  • OS: CentOS Linux release 7.2.1511 (Core) 
  • Kernel: 3.10.0-327.10.1.el7.x86_64
  • pcs: 0.9.143


参考

1 件のコメント:

  1. > network の configuration を変える時は pcs stop --all とかしてくださいね。
    クラスタ全体を止めなくても config 変えたいノードだけ pacemaker と corosync 止めればいいですね。
    なので pcs cluster stop あたりで良いかと

    > 死活監視のプロセスなので
    死活監視は corosync の役割ですね
    中途半端に生きてるときにとどめを刺すのが shooter の認識
    実は ipmi とかでとどめ刺すことができたような・・・

    > umount までできるスクリプトを組んでおく + PowerChute との連携はしっかり
    クラスタのノード数が quorum 割る前に umount できることが条件なるかと
    quorum 割ると止まる

    返信削除