作っておぼえるHAシステム4

2020-12-232023-11-07

２台のLinuxサーバを使ってアクティブ・スタンバイで動くDBクラスターが構築できたので、実際に障害を発生させてHAシステムの動きを見てみましょう。

サーバのハングアップ試験

サーバ機の電源障害やマザーボードの故障が発生したことを想定して、アクティブなノードを停止してみます。

まず正常時の動作の状態を確認します。

動作の確認にはcrm_mon コマンドを使います。-frを引数に実行するとリソースの状態が表示されます。（引数に1を加えるとこの表示は1度だけ行われます。）

[root@node2 ~]# crm_mon -fr1
Stack: corosync
Current DC: node1.sios.com (version 1.1.21.linbit-4.0.el7-f14e36fd43) - partition with quorum
Last updated: Fri Dec 18 13:26:07 2020
Last change: Fri Dec 18 13:23:14 2020 by hacluster via crmd on node1.sios.com

2 nodes configured
5 resources configured

Online: [ node1.sios.com node2.sios.com ]

Full list of resources:

 Resource Group: rg_mariadb
     res_ipadr	(ocf::heartbeat:IPaddr2):	Started node1.sios.com
     res_fsmnt	(ocf::heartbeat:Filesystem):	Started node1.sios.com
     res_mysql	(ocf::heartbeat:mysql):	Started node1.sios.com
 Master/Slave Set: ms_drbd_r0 [res_drbd_r0]
     Masters: [ node1.sios.com ]
     Slaves: [ node2.sios.com ]

Migration Summary:
* Node node1.sios.com:
* Node node2.sios.com:

Started node1.sios.comの表示からMariaDBはnode1.sios.comで動いています。DRBDもnode1.sios.comがPrimaryになっていることがわかります。

ではnode1.sios.comを停止します。

本Blogのテスト環境はVirtualbox上で動いていますので、Virtualboxのウィンドウを閉じると、実行中の仮想ゲストを強制停止できます。実サーバで試されている場合は、電源ボタンを長押ししたり、リセットボタンを押すことで強制停止ができます。

上の図の「仮想マシンの電源オフ(P）」を選ぶとnode1.sios.comが停止します。node2.sios.comではDRBDとPacemakerが動いてるので、crm_monコマンドを実行すると、node2.sios.comに運転が切り替わったことが確認できます。この切り替わりのことをフェールオーバーと言います。

[root@node2 ~]# crm_mon -fr1
Stack: corosync
Current DC: node2.sios.com (version 1.1.21.linbit-4.0.el7-f14e36fd43) - partition with quorum
Last updated: Fri Dec 18 13:36:18 2020
Last change: Fri Dec 18 13:23:14 2020 by hacluster via crmd on node1.sios.com

2 nodes configured
5 resources configured

Online: [ node2.sios.com ]
OFFLINE: [ node1.sios.com ]

Full list of resources:

 Resource Group: rg_mariadb
     res_ipadr	(ocf::heartbeat:IPaddr2):	Started node2.sios.com
     res_fsmnt	(ocf::heartbeat:Filesystem):	Started node2.sios.com
     res_mysql	(ocf::heartbeat:mysql):	Started node2.sios.com
 Master/Slave Set: ms_drbd_r0 [res_drbd_r0]
     Masters: [ node2.sios.com ]
     Stopped: [ node1.sios.com ]

Migration Summary:
* Node node2.sios.com:
[root@node2 ~]#

試験前の表示と比べると、各リソースがnode2.sios.comで動いているのがわかります。またnode1.sios.comは停止しているので、Pacemaker上からは管理できないオフライン（「OFFLINE:」)のノードになります。

この時点でnode1.sios.comを起動して、Pacemakerを起動すると次のように状態が変わります。

[root@node2 ~]# crm_mon -fr1
Stack: corosync
Current DC: node2.sios.com (version 1.1.21.linbit-4.0.el7-f14e36fd43) - partition with quorum
Last updated: Fri Dec 18 13:39:09 2020
Last change: Fri Dec 18 13:23:14 2020 by hacluster via crmd on node1.sios.com

2 nodes configured
5 resources configured

Online: [ node1.sios.com node2.sios.com ]

Full list of resources:

 Resource Group: rg_mariadb
     res_ipadr	(ocf::heartbeat:IPaddr2):	Started node2.sios.com
     res_fsmnt	(ocf::heartbeat:Filesystem):	Started node2.sios.com
     res_mysql	(ocf::heartbeat:mysql):	Started node2.sios.com
 Master/Slave Set: ms_drbd_r0 [res_drbd_r0]
     Masters: [ node2.sios.com ]
     Slaves: [ node1.sios.com ]

Migration Summary:
* Node node1.sios.com:
* Node node2.sios.com:

「OFFLINE:」の表示が消えて、「Online:」の項目にnode1.sios.comのホスト名が加わっています。またDRBDも「Stopped:」から「Slave:」に表示が変わりました。
HAクラスタとしては完全に復旧しているので、次にnode2.sios.comが停止するとサービスはnode1.sios.comへフェールオーバーできます。

DRBDのデータ確認

DRBDのデータも確認してみましょう。drbdadm statusコマンドでデータの状態を確認します。node1.sios.comで実行してみたところ次のようになりました。

[root@node1 ~]# drbdadm status r0
r0 role:Secondary
  disk:UpToDate
  node2 role:Primary
    peer-disk:UpToDate

自ノードのストレージの状態が「disk:UpToDate」、同期中のnode2のストレージの状態が「peer-disk:UpToDate」と両方とも「UpToDate」になっているのでデータの同期は正常で、node1.sios.comはいつでもサービスを引き継げる状態になっているとわかります。drbdadmコマンドはnode1.sios.comで実行したので、node2.sios.comがPrimaryになっていることがわかります。

次のような状態になっている場合は、node2.sios.comからデータ同期をまさに行っている状態になります。

[root@node1 ~]# drbdadm status r0
r0 role:Secondary
  disk:Inconsistent
  node2 role:Primary
    replication:SyncTarget peer-disk:UpToDate done:17.37

node1.sios.comが停止している間はnode2.sios.comで生じたデータの差分をDRBDは記録していて、再接続後に不足しているデータを差分同期します。上記の表示の「disk:Inconsistent」の状態はデータの不整合が発生していること、「replication:SyncTarget」はnode2.sios.comからnode1.sios.comにデータの同期が行われていること、「done:17.37」は同期対象のデータの17.37%の同期が終了したことを意味しています。同期が100%になると、「disk:UpToDate」になり、node1.sios.comのデータはnode2.sios.comに完全に同期した状態になります。

次は同期終了後の正常な状態の表示になります。

[root@node1 ~]# drbdadm status r0
r0 role:Secondary
  disk:UpToDate
  node2 role:Primary
    peer-disk:UpToDate

また障害から復旧したnode1.sios.comでDRBDの状態が、次のようになる場合があります。

[root@node1 ~]# drbdadm status r0
r0 role:Secondary
  disk:Outdated
  node2 connection:StandAlone

「connection:StandAlone」は相手との通信が切れていることを意味します。相手との通信を試みている場合は「connection:Connecting」となります。
「connection:StandAlone」となった場合は”drbdadm connect <リソース名>”で復旧出来る場合もありますが、すぐにStandAloneになってしまう場合は、DRBDのデータがスプリットブレインになっていることが大半です。

スプリットブレインになっているかどうかは/var/log/messagesに記録されるDRBDのログの中に”Split-Brain detected”の文字列があるか確認して下さい。

Dec 18 14:21:13 node1 kernel: drbd r0/0 drbd0: Split-Brain detected but unresolved, dropping connection!

スプリットブレインであると確認できたら復旧作業を行います。方法の詳細はユーザーズ・ガイドを参照して下さい。
復旧作業後、両ノードのDRBD同期は再開します。