作っておぼえるHAシステム4(2022年版）

2022-12-152022-12-16

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

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

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

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

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

[root@node2 ‾]# 
Cluster Summary:
  * Stack: corosync
  * Current DC:	node1 (version 2.0.5.linbit-1.0.el8-ba59be712) - partition with quorum
  * Last updated: Thu Dec 15 16:21:27 2022
  * Last change:  Thu Dec 15 16:17:36 2022 by hacluster via crmd on node1
  * 2 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ node1 node2 ]

Full List of Resources:
  * Resource Group: rg_mariadb:
    * res_ipadr (ocf::heartbeat:IPaddr2):        Started node1
    * res_fsmnt (ocf::heartbeat:Filesystem):     Started node1
    * res_mysql (ocf::heartbeat:mysql):  Started node1
  * Clone Set: ms_drbd_r0 [res_drbd_r0] (promotable):
    * Masters: [ node1 ]
    * Slaves: [ node2 ]

Node Attributes:
  * Node: node1:
    * master-res_drbd_r0                : 10000
  * Node: node2:
    * master-res_drbd_r0                : 10

Migration Summary:

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

ではnode1を停止します。

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

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

[root@node2 ‾]# crm_mon -fr1
Cluster Summary:
  * Stack: corosync
  * Current DC: node2 (version 2.0.5.linbit-1.0.el8-ba59be712) - partition with quorum
  * Last updated: Thu Dec 15 16:23:42 2022
  * Last change:  Thu Dec 15 16:17:36 2022 by hacluster via crmd on node1
  * 2 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ node2 ]
  * OFFLINE: [ node1 ]

Full List of Resources:
  * Resource Group: rg_mariadb:
    * res_ipadr	(ocf::heartbeat:IPaddr2):	 Started node2
    * res_fsmnt	(ocf::heartbeat:Filesystem):	 Started node2
    * res_mysql	(ocf::heartbeat:mysql):	 Started node2
  * Clone Set: ms_drbd_r0 [res_drbd_r0] (promotable):
    * Masters: [ node2 ]
    * Stopped: [ node1 ]

Migration Summary:

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

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

[root@node2 ‾]# crm_mon -fr1
Cluster Summary:
  * Stack: corosync
  * Current DC: node2 (version 2.0.5.linbit-1.0.el8-ba59be712) - partition with quorum
  * Last updated: Thu Dec 15 16:24:53 2022
  * Last change:  Thu Dec 15 16:17:36 2022 by hacluster via crmd on node1
  * 2 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ node1 node2 ]

Full List of Resources:
  * Resource Group: rg_mariadb:
    * res_ipadr	(ocf::heartbeat:IPaddr2):	 Started node2
    * res_fsmnt	(ocf::heartbeat:Filesystem):	 Started node2
    * res_mysql	(ocf::heartbeat:mysql):	 Started node2
  * Clone Set: ms_drbd_r0 [res_drbd_r0] (promotable):
    * Masters: [ node2 ]
    * Slaves: [ node1 ]

Migration Summary:

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

DRBDのデータ確認

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

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

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

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

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

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

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

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

また障害から復旧したnode1で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同期は再開します。