ふたつの川うるおう日記

_ [Server][Admin] DRBD (Primary/Primary) + GFS2で1ノード落としても大丈夫に

DRBDとクラスタファイルシステムのテストで手詰まり中で書いたDRBD (Primary/Primary)で構成した2ノードのうち、1ノード落とすともう1ノードでGFS2領域にアクセスできなくなるのは、コメントにあるRAさんの情報をもとにQuorumをよく調べることで解決しました。

Red Hat Cluster Suite(GFS/GFS2はこの一部)では、Quorumを次の式で決定し、この数字より小さいノード数になるとサービスが停止する作りになっています。

Quorum = 稼働していたノード台数 / 2 + 1

具体的な数字を書くと次のとおり。

6台構成: 6/2+1 = 4台以上稼働し続けていればOK、3台以下になったらアウト
3台構成: 3/2+1 = 2台以上稼働し続けていればOK、1台以下になったらアウト

ここで今回やっていたDRBDの場合、2台構成なので次のようになります。

2台構成: 2/2+1 = 2台以上稼働し続けていればOK、1台以下になったらアウト

つまり2台構成の時は、普通であれば1台落ちたらアウトだったんです。稼働中のQuorumを知りたい場合は、cman_tool status コマンドで知ることができます。

# cman_tool status
...
Expected votes: 2
Total votes: 2
Quorum: 2
Active subsystems: 8
Flags: Dirty
...

で、それだと困るわけで実は2台構成の時にQuorumを1に固定する設定として、<cman two_node="1" expected_votes="1"> があります。この設定は、ccs_tool コマンドで設定することはできないみたいなので、次のように /etc/cluster/cluster.conf を編集します。

• 編集前: /etc/cluster/cluster.conf

<cluster name="drbd_cluster" config_version="5">
  <clusternodes>
...

• 編集後: /etc/cluster/cluster.conf
  • config_versionは編集前 +1 の数字にすること

<cluster name="drbd_cluster" config_version="6">
  <cman two_node="1" expected_votes="1">
  </cman>
  <clusternodes>
...

編集したら、次のコマンドで稼働中の全ノードへ設定を反映させます。

ccs_tool update /etc/cluster/cluster.conf

早速 cman_tool status を調べます。

# cman_tool status
...
Expected votes: 1
Total votes: 2
Quorum: 2
Active subsystems: 8
Flags: 2node Dirty
...

ここで困ったことが起きていて、Expected votesとFlagsの値は変わったのにQuorumは2のままです。これが前回上手くいかなかった原因です。ccs_tool update してもQuorumは書き換わって無かったのです。これはマシンごと再起動してcmanを起動し直すことで次のように意図する値になりました。

# cman_tool status
...
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 8
Flags: 2node Dirty
...

これで1ノード障害でいなくなってもOKです。実際に断線させると次のようになり、生きているノードでマウントしていたGFS2領域もそのまま読み書きできます。

[root@host01 ~]# cman_tool services
type             level name     id       state
fence            0     default  00010001 none
[1]
dlm              1     clvmd    00020001 none
[1]
dlm              1     drbd0    00040001 none
[1]
gfs              2     drbd0    00030001 none
[1]

fence_manual以外のfenceデバイスを設定している場合は自動的に上記の状態になります。fence_manualを使っている場合は、fence_as_manualを使って手動でサービスを継続するよう指示しないといけません。次のようなコマンドです。

fence_ack_manual -O -e -n 落ちたノード名

今回の構成ではデータはDRBDで同期されていることが前提ですので、上記は自動的に実行して欲しいです。そこでDRBDの outdate-peer を使って自動的に実行するようにすれば良いです。これについては下記の資料を参考にしました。

• DRBD_Cookbook
  • outdate-peer用スクリプト (このままではダメ)

outdate-peer用スクリプトは、fence_manual用になっていないので、 DRBD-user MLのoutdate-peerスクリプトの編集例を真似て編集します。GFS2用の場合、cman_tool nodesが返す値が違うのでそこも直します。最終的な編集箇所は次のとおりです。

--- drbd-peer-outdater.default  2008-07-01 02:46:16.000000000 +0900
+++ drbd-peer-outdater  2008-07-13 09:53:22.000000000 +0900
@@ -49,7 +49,7 @@
-done < <(cman_tool nodes 2>/dev/null | grep -v '^Node' | awk '{print $1,$6}')
+done < <(cman_tool nodes 2>/dev/null | grep -v '^Node' | awk '{print $1,$4,$6}')
@@ -71,7 +71,8 @@
-fence_node $REMOTE
+#fence_node $REMOTE
+fence_ack_manual -O -e -n $REMOTE

以上でfence_manualでも1ノードで自動でサービスを継続できるようになりました。

まだ良く検証していませんが懸念事項として、障害で1ノード完全に死ぬのではなく、短い時間ネットワークがLink Downしてクラスタから切り離されても、切り離されているときに両方とも同じGFS/GFS2領域をマウントしている状態だと、一度どちらかのノードのマシンを再起動しないといけなくなります(どっちが必要なPrimaryかが自動では判別が付かないため)。それをどうするかや、そういったことが起きる頻度がどれくらいあるかを今後調べる必要があります。

| Bookmark: