notice: High CPU load detected
info: New throttle mode
debug: New job limit is 1

このログを初めて見たとき、「クラスタに異常が発生したのではないか」と不安に感じる方もいるかもしれません。しかし結論から言うと、これらのログは障害ではありません。クラスタノードの負荷が高くなったため、Pacemaker の 負荷保護機構 (スロットリング) が正常に動作したことを示すログです。

本記事では、Pacemaker の運用で頻繁に遭遇する負荷スロットリングについて、ログの意味を読み解きながら分かりやすく解説します。なお、本記事は Pacemaker 3.0.1 を前提としています。

負荷スロットリングとは何か

Pacemaker の負荷スロットリングとは、ノードの負荷が高くなった際にリソースアクション (start / stop / monitor など) の同時実行数を自動的に減らす安全機構です。Pacemaker はクラスタの状態を維持するために、リソースの起動や停止、監視など多くの処理を常に実行しています。これらは通常、並列に実行されることで迅速なフェイルオーバーや復旧を実現しています。

しかし、ノードがすでに高負荷状態のときに大量のリソース操作を同時実行すると、状況がさらに悪化する可能性があります。monitor のタイムアウトやフェイルオーバーの誤発生、さらには STONITH の誤発動などが連鎖的に発生し、クラスタ全体が不安定な状態に陥ることがあります。

このような事態を防ぐために、Pacemaker は自らの動作を意図的に減速させます。これがスロットリングです。

通常時の並列制御の仕組み

Pacemaker のリソースアクションは、通常時でも無制限に並列実行されるわけではありません。次の 2 つのパラメータで制御されています。

• node-action-limit（ノード単位）
• batch-limit（クラスタ全体）

node-action-limit

node-action-limit は、ノード単位で同時実行できるアクション数の上限を決めるパラメータです。デフォルト値は 0 (自動) であり、次の式で自動計算されます。

node-action-limit = CPUコア数 × 2

たとえば 4 コアのサーバであれば、最大 8 個のリソース操作を同時に実行できます。この設計により、通常時は効率よくリソース操作を処理できるようになっています。

batch-limit

batch-limit はクラスタ全体での同時実行数を制御します。node-action-limit が「各ノード単位の上限」であるのに対し、batch-limit は「クラスタ全体で同時に実行できるアクション数の上限」です。デフォルト値は 0（自動）で、Pacemaker がクラスタの状態や負荷状況を見ながら動的に調整します。

では、ノードが高負荷になった場合はどうなるのでしょうか。ここから動的スロットリングについて見ていきます。

代表的な負荷制御ログ

Pacemaker は、ノード負荷に応じたスロットリングが発生すると、次のようなログを出力します。

ここでは debug ログを有効化した場合の出力例を示します。

debug: Current load is 1.110000 across 4 core(s)
notice: High CPU load detected: 8.040000
info: New throttle mode: high load (was medium)
debug: Node node1 has high load and supports at most 8 jobs; new job limit 1

以降では、これらのログがそれぞれ何を意味しているのかを順番に解説していきます。

Current load (現在のノード負荷)

debug: Current load is 1.110000 across 4 core(s)

このログは、Pacemaker が現在のノード負荷をどのように認識しているかを示しています。

Pacemaker が負荷判定に使用している指標は load average です。ここで表示されている「Current load」は、/proc/loadavg の先頭フィールドである 1 分平均の load average を示しています。

High CPU load detected (高負荷の検出)

notice: High CPU load detected: 8.040000

このメッセージは、load average が Pacemaker の定義するしきい値を超えたことを示しています。

しきい値は load-threshold (デフォルト 80%) を基準に、CPU コア数から自動的に計算されます。Pacemaker は load average に対して、low / medium / high の 3 段階のしきい値を次の式で算出します。

low    = load-threshold × CPUコア数 × 1.2
medium = load-threshold × CPUコア数 × 1.6
high   = load-threshold × CPUコア数 × 2.0

例えば CPU 4 コア、load-threshold = 80% の場合、各段階のしきい値は次のようになります。

low    = 0.8 × 4 × 1.2 = 3.84
medium = 0.8 × 4 × 1.6 = 5.12
high   = 0.8 × 4 × 2.0 = 6.40

4 コア環境では、load average が 6.4 を超えた時点で High 判定となります。そのため、ログに表示されている 8.04 は、Pacemaker が明確に「高負荷」と判断した状態であることを意味します。

New throttle mode (スロットルモードの遷移)

高負荷が検出されると、Pacemaker はスロットルモードを変更します。

info: New throttle mode: high load (was medium)

このログは、CPU 負荷の段階に応じて、Pacemaker が並列実行数を制御するスロットルモードを medium から high に変更したことを示しています。Pacemaker は高負荷時に自らのアクション発行がさらに負荷を悪化させることを防ぐため、ジョブの同時実行数を段階的に制限します。

なお、古いバージョンではスロットルモードがビット表記で表示されることがあります。

スロットルモードが頻繁に変動している場合は、CPU 負荷が継続的に高い状態にある可能性があります。その場合は ps や top などを用いて高負荷の原因となっているプロセスを特定する必要があります。

New job limit is 1 の意味

debug: Node node1 has high load and supports at most 8 jobs; new job limit 1

このログは、ノードの高負荷を検知した結果、Pacemaker が同時実行できるジョブ数を制限したことを示しています。

通常時、Pacemaker は CPU コア数 × 2 のジョブを同時に実行できます。例えば 4 コアのノードであれば、デフォルトでは最大 8 ジョブを並列実行できます。負荷の上昇に応じて同時実行数は段階的に引き下げられ、high モード に到達すると最終的に 1 まで縮小されます。

つまりこのログは、Pacemaker がクラスタの安定性を優先し、意図的に並列処理を最小化した状態を示しています。

動作検証

stress-ng を使用して CPU 負荷を段階的に上げると、スロットルモードがどのように遷移するかを確認できます。ここでは、その挙動をログから読み取ります。

以下のログから分かるように、負荷の上昇に伴いスロットルモードは low → medium → high と段階的に遷移し、それに合わせて job limit が 8 → 4 → 2 → 1 と減少していきます。
これは Pacemaker が想定どおりに負荷保護を実施していることを示しています。

debug: Current load is 0.020000 across 4 core(s)
debug: Current load is 0.070000 across 4 core(s)
debug: Current load is 0.240000 across 4 core(s)
debug: Current load is 1.110000 across 4 core(s)
debug: Noticeable CPU load detected: 4.750000
debug: Current load is 4.750000 across 4 core(s)
info: New throttle mode: low load (was negligible)
debug: Node node1 has low load and supports at most 8 jobs; new job limit 4
info: Moderate CPU load detected: 6.060000
debug: Current load is 6.060000 across 4 core(s)
info: New throttle mode: medium load (was low)
debug: Node node1 has medium load and supports at most 8 jobs; new job limit 2
notice: High CPU load detected: 8.040000
debug: Current load is 8.040000 across 4 core(s)
info: New throttle mode: high load (was medium)
debug: Node node1 has high load and supports at most 8 jobs; new job limit 1
notice: High CPU load detected: 9.860000
debug: Current load is 9.860000 across 4 core(s)
notice: High CPU load detected: 11.480000
debug: Current load is 11.480000 across 4 core(s)

おわりに

今回は、Pacemaker の負荷スロットリングの動作について、ログの意味や挙動を中心に解説しました。

「High CPU load detected」や「New throttle mode」といったメッセージは、障害ではなく、クラスタを安定させるための自己防衛機構が正常に動作していることを示しています。ただし、この状態が頻繁に発生する場合は、ノードに継続的な高負荷が発生している可能性があります。CPU 使用率や実行中プロセスを確認し、負荷の原因を特定・改善することが重要です。

本記事では、スプリットブレイン対策の中でも、2 ノードクラスタにおけるクォーラム確立を支援する「クォーラムデバイス」に焦点を当て、その仕組みと基本的な使い方について紹介します。

クォーラムデバイスの仕組み

クォーラムデバイスは、ノード間通信が切断された際に、どのノード (またはパーティション) がクラスタの運用を継続すべきかを判断するための外部投票ノードです。

偶数ノードで構成されたクラスタでは、ネットワーク分断時に投票数が同数となり、クォーラム (過半数) が成立しないという問題があります。特に2ノードクラスタでは、インターコネクトが切断されると双方が相手を障害と誤認し、スプリットブレイン状態に陥るリスクが高くなります。

このような構成では、クラスタノードとは別に調停役となるクォーラムデバイスを追加することで、クラスタ全体の投票数が奇数となり、過半数による多数決が成立します。その結果、スプリットブレイン発生時でも、どちらのノードがクラスタを継続すべきかを適切に判断できるようになります。

2ノードクラスタの場合、通常は各ノードが1票ずつを持ちますが、クォーラムデバイスを追加すると合計3票となります。ネットワーク分断が発生した際には、クォーラムデバイスの投票を含めた多数決により、過半数を得たノードのみがクラスタ管理を継続できます。これにより、両ノードが同時にリソースを稼働させる事態を防止できます。

偶数ノード構成、特に2ノードクラスタではスプリットブレインのリスクが高いため、クォーラムデバイスの利用が推奨されます。

クォーラムデバイスを利用したクラスタ構成

以下は、クォーラムデバイスを利用したクラスタ構成です。

クォーラムデバイスを利用する場合、クラスタノードには corosync-qdevice をインストールし、調停役となるサーバには corosync-qnetd をインストールします。corosync-qnetd デーモンはクラスタ外部で動作し、投票を行います。分断時には corosync-qnetd の判定結果に基づき、過半数を得たノードのみがクラスタを維持し、過半数を得られなかったノードはクラスタサービスを停止します。

corosync-qnetd の判定アルゴリズム

corosync-qnetd は、以下の判定アルゴリズムに対応しています。

• ffsplit (fifty-fifty split)：デフォルトのアルゴリズムです。アクティブなノード数が最も多いパーティションに 1 票を与えます。クラスタが同数（1:1）に分断された場合は、tie_breaker の設定に基づいて投票先を決定します。デフォルトでは、最も小さな node ID を含むパーティションに 1 票を与えます。
• lms (last-man-standing)：corosync-qnetd サーバと通信できるノードが 1 台のみになった場合、そのノードに 1 票を与えます。

クォーラムデバイス構成時の注意点

クォーラムデバイスを構成する際には、以下の点を考慮する必要があります。

• クォーラムデバイスはクラスタノードとは別のサーバで動作させる必要があります。既存のクラスタノード上で実行しないでください。
• 可能であれば、クォーラムデバイスを Corosync が使用するネットワークとは異なるネットワークに配置します。
• 複数のクラスタで 1 つのクォーラムデバイスを共有できますが、1 つのクラスタに複数のクォーラムデバイスを構成することはできません。

検証環境と前提条件

本記事では、クォーラムデバイスを利用した 2 ノードクラスタ構成で動作検証を行います。

クラスタ構成およびクォーラムデバイスは以下になります。

今回は検証目的で RHEL クローン OS の Rocky Linux 環境を用いて検証を行います。Rocky Linux では Red Hat High Availability Add-On 相当のパッケージが highavailability リポジトリに含まれているため、今回はそちらのリポジトリを利用してインストールします。バージョン情報は以下になります。

すべてのクラスタノードおよびクォーラムデバイスとして動作するノードにおいて、/etc/hosts にホスト名と IP アドレスを設定します。

# vi /etc/hosts
(以下を追加)
192.168.100.101 node1
192.168.100.102 node2
192.168.100.100 qdevice

Pacemaker のインストールおよびクラスタの初期設定

1. Pacemaker をインストールします。

各クラスタノードで highavailability リポジトリを有効にし、Pacemaker 関連パッケージをインストールします。

(node1、node2 で実行)
# dnf install -y --enablerepo=highavailability pacemaker pcs

※ RHEL 環境を利用している場合は、Red Hat 社によって提供される Red Hat High Availability Add-On のパッケージを利用してインストールしてください。詳細についてはこちらを参照してください。

2. firewalld デーモンが起動している場合は、クラスタ通信に必要なポートを許可するように以下のコマンドを実行します。

(node1、node2 で実行)
# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --reload

3. 両ノードで hacluster ユーザのパスワードを設定します。

(node1、node2で実行)
# passwd hacluster
Changing password for user hacluster.
New password: (haclusterユーザのパスワードを入力)
Retype new password: (haclusterユーザのパスワードを入力)
passwd: all authentication tokens updated successfully.

4. 両ノードで以下のコマンドを実行し、pcsd の自動起動を有効化します。

(node1、node2 で実行)
# systemctl start pcsd.service
# systemctl enable pcsd.service

5. いずれかのノードからクラスタを構成するノードに対して、hacluster ユーザの認証を行います。

(node1 または node2 のいずれかで実行)
# pcs host auth node1 node2 -u hacluster
Password: (haclusterユーザのパスワードを入力)
node1: Authorized
node2: Authorized

6. クラスタを作成します。クラスタの名前を test_cluster とします。

(node1 または node2 のいずれかで実行)
# pcs cluster setup test_cluster node1 addr=192.168.100.101 node2 addr=192.168.100.102
Destroying cluster on hosts: 'node1', 'node2'...
node1: Successfully destroyed cluster
node2: Successfully destroyed cluster
Requesting remove 'pcsd settings' from 'node1', 'node2'
node1: successful removal of the file 'pcsd settings'
node2: successful removal of the file 'pcsd settings'
Sending 'corosync authkey', 'pacemaker authkey' to 'node1', 'node2'
node1: successful distribution of the file 'corosync authkey'
node1: successful distribution of the file 'pacemaker authkey'
node2: successful distribution of the file 'corosync authkey'
node2: successful distribution of the file 'pacemaker authkey'
Sending 'corosync.conf' to 'node1', 'node2'
node1: successful distribution of the file 'corosync.conf'
node2: successful distribution of the file 'corosync.conf'
Cluster has been successfully set up.

7. クラスタを起動します。

(node1 または node2 のいずれかで実行)
# pcs cluster start --all

pcs status コマンドを使用して、作成したクラスタのステータスを表示します。node1、node2 が Online になっていることを確認します。

(node1 または node2 のいずれかで実行)
# pcs status
Cluster name: test_cluster
...
Node List:
  * Online: [ node1 node2 ]

8. クラスタを安全に運用するために、フェンシングの設定が必要になりますが、今回はクォーラムデバイスを検証することを目的としているため、以下のコマンドを実行し、フェンシングを無効にします。

(node1 または node2 のいずれかで実行)
# pcs property set stonith-enabled=false

9. 検証用の Dummy リソースを作成します。

(node1 または node2 のいずれかで実行)
# pcs resource create Dummy ocf:heartbeat:Dummy

リソースが作成されていることを確認します。

(node1 または node2 のいずれかで実行)
# pcs status
Cluster name: test_cluster
...
Full List of Resources:
* Dummy (ocf:heartbeat:Dummy): Started node1

以上で、Pacemaker クラスタの初期設定は完了です。

クォーラムデバイスを使わない場合の動作確認

ここでは、クォーラムデバイスを使用しない状態で、2 ノード間のインターコネクト通信を切断した場合の挙動を確認します。

まず、疑似障害を起こすため、node1 と node2 間のインターコネクト通信を切断します。

しばらく待ってから pcs status コマンドを実行し、クラスタの状態を確認します。すると、両ノードがそれぞれ DC (Designated Controller) として選出され、それぞれのノード上でリソースが起動していることが確認できます。

(node1 で実行) 
[root@node1 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node1 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
...
Node List:
  * Online: [ node1 ]
  * OFFLINE: [ node2 ]

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Started node1

(node2 で実行) 
[root@node2 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node2 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
...
Node List:
  * Online: [ node2 ]
  * OFFLINE: [ node1 ]

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Started node2

これは、両ノードが自身を稼働系と誤認識している状態であり、典型的なスプリットブレイン状態です。

クォーラムデバイスのインストールおよび設定

ここでは、既存のクラスタ (node1、node2) にクォーラムデバイスを追加し、スプリットブレイン防止について動作検証を通して効果を検証します。

クォーラムデバイスのインストール

1. 既存のクラスタノード node1 と node2 に corosync-qdevice をインストールします。

(node1、node2 で実行)
# dnf install -y --enablerepo=highavailability corosync-qdevice

2. クォーラムデバイスとして使用されるノード qdevice に pcs および corosync-qnetd をインストールします。

(qdevice で実行)
[root@qdevice ~]# dnf install -y --enablerepo=highavailability pcs corosync-qnetd

3. qdevice 上で pcsd サービスを起動し、自動起動の設定を行います。

(qdevice で実行)
[root@qdevice ~]# systemctl start pcsd.service
[root@qdevice ~]# systemctl enable pcsd.service

4. firewalld デーモンが起動している場合は、クラスタで必要なポートを有効化するように以下のコマンドを実行します。

(qdevice で実行)
[root@qdevice ~]# firewall-cmd --permanent --add-service=high-availability
[root@qdevice ~]# firewall-cmd --reload

クォーラムデバイスの設定

ここでは、既存のクラスタにクォーラムデバイスを追加する手順を記載します。

1. クォーラムデバイスモデル net を指定し、クォーラムデバイスのセットアップおよび起動を行います。また、システム起動時にクォーラムデバイスが起動するように設定します。

(qdevice で実行) 
[root@qdevice:~]# pcs qdevice setup model net --enable --start
Quorum device 'net' initialized
quorum device enabled
Starting quorum device...
quorum device started

起動後、pcs qdevice status net --full を実行し、クォーラムデバイスの状態を確認します。

(qdevice で実行)
[root@qdevice ~]# pcs qdevice status net --full
QNetd address:                  *:5403
TLS:                            Supported (client certificate required)
Connected clients:              0
Connected clusters:             0
Maximum send/receive size:      32768/32768 bytes

2. クラスタノードの pcs がクォーラムデバイス qdevice にアクセスできるように、hacluster ユーザの認証を行います。

(node1 または node2 のいずれかで実行)
# pcs host auth qdevice -u hacluster
Password: (hacluster ユーザのパスワードを入力)
qdevice: Authorized

3. クォーラムデバイスをクラスタに追加します。

クォーラムデバイスを追加する前に、後で比較するために、クォーラムデバイスの現在の設定と状況を確認できます。
このコマンドの出力から、クラスタがクォーラムデバイスを使用しておらず、各ノードの Qdevice メンバーシップのステータスが NR (Not Registered：登録されていない) であることが分かります。

[root@node1 ~]# pcs quorum config
[root@node1 ~]# pcs quorum status
Quorum information
------------------
Date:            Sun Feb 2 11:39:03 2026
Quorum provider: corosync_votequorum
Nodes:           2
Node ID:         1
Ring ID:         1.1d
Quorate:         Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           1
Flags:            2Node Quorate WaitForAll

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    NR      node1 (local)
         2          1    NR      node2

以下のコマンドを実行し、クォーラムデバイスをクラスタに追加します。host にクォーラムデバイスとして動作するノードのホスト名、algorithm に使用するアルゴリズム (ffsplit) を指定します。

(node1 または node2 のいずれかで実行)
# pcs quorum device add model net host=qdevice algorithm=ffsplit
Setting up qdevice certificates on nodes...
node1: Succeeded
node2: Succeeded
Enabling corosync-qdevice...
node1: not enabling corosync-qdevice: corosync is not enabled
node2: not enabling corosync-qdevice: corosync is not enabled
Sending updated corosync.conf to nodes...
node2: Succeeded
node1: Succeeded
node1: Corosync configuration reloaded
Starting corosync-qdevice...
node2: corosync-qdevice started
node1: corosync-qdevice started

上記コマンドを実行後、クォーラムデバイスの設定を確認するには、pcs quorum config を実行します。

(node1 または node2 のいずれかで実行)
# pcs quorum config
Device:
  votes: 1
  Model: net
    algorithm: ffsplit
    host: qdevice

4. クラスタノード側からクォーラムデバイスの状態を確認します。

クォーラムデバイスをクラスタに追加した後、まずはクラスタノード側から、クォーラムデバイスが正しく認識・動作しているかを確認します。

(node1 または node2 のいずれかで実行)
# pcs quorum status
Quorum information
------------------
Date:             Sun Feb  2 11:45:38 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          1
Ring ID:          1.1d
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW node1 (local)
         2          1    A,V,NMW node2
         0          1            Qdevice

この Membership information は、現在のクォーラム判定に参加しているメンバー (投票者) 一覧を表しています。Qdevice が 1 vote を持つメンバーとして参加していることが分かります。

なお、A,V,NMW は votequorum におけるノード状態フラグであり、それぞれの意味は次のとおりです。

• A/NA
  • A (Active)：クォーラムデバイスがそのノードに対して有効な状態
  • NA (Not Active)：クォーラムデバイスがそのノードに対して無効な状態
• V/NV
  • V (Voting)：クォーラムデバイスがそのノードへ投票を与えている
  • NV (Not Voting)：クォーラムデバイスがそのノードに投票を与えていない
• MW/NMW
  • MW (Master Wins)：master_wins フラグが有効
  • NMW (Not Master Wins)：master_wins フラグが無効 (デフォルト)

続いて、pcs quorum device status コマンドを使って、クォーラムデバイスとの接続状態やアルゴリズム設定を確認します。

(node1 または node2 のいずれかで実行)
[root@node1 ~]# pcs quorum device status
Qdevice information
-------------------
Model:                  Net
Node ID:                1
Configured node list:
      0 Node ID = 1
      1 Node ID = 2
Membership node list:   1, 2

Qdevice-net information
----------------------
Cluster name:           test_cluster
QNetd host:             qdevice:5403
Algorithm:              Fifty-Fifty split
Tie-breaker:            Node with lowest node ID
State:                  Connected

Qdevice-net information の結果から、判定アルゴリズムと決定ルールを確認できます。

• Algorithm: Fifty-Fifty split は、クラスタが同数に分断された場合（2 ノードクラスタでは 1:1 の分断）に適用される判定アルゴリズムです。
• Tie-breaker: Node with lowest node ID は、分断時に最も小さな node ID を含むパーティションを primary component（quorum を持つ側）として選択する決定ルールを示しています。

5. 次に、クォーラムデバイス側で、corosync-qnetd デーモンの状態を確認します。

以下のコマンドを実行します。

(qdevice サーバで実行)
[root@qdevice:~]# pcs qdevice status net --full
QNetd address:                  *:5403
TLS:                            Supported (client certificate required)
Connected clients:              2
Connected clusters:             1
Maximum send/receive size:      32768/32768 bytes
Cluster "test_cluster":
    Algorithm:          Fifty-Fifty split (KAP Tie-breaker)
    Tie-breaker:        Node with lowest node ID
    Node ID 1:
        Client address:         ::ffff:192.168.100.101:33624
        HB interval:            8000ms
        Configured node list:   1, 2
        Ring ID:                1.1d
        Membership node list:   1, 2
        Heuristics:             Undefined (membership: Undefined, regular: Undefined)
        TLS active:             Yes (client certificate verified)
        Vote:                   No change (ACK)
    Node ID 2:
        Client address:         ::ffff:192.168.100.102:32998
        HB interval:            8000ms
        Configured node list:   1, 2
        Ring ID:                1.1d
        Membership node list:   1, 2
        Heuristics:             Undefined (membership: Undefined, regular: Undefined)
        TLS active:             Yes (client certificate verified)
        Vote:                   ACK (ACK)

両ノードとも、同一の Membership node list、正常な ACK 応答となっており、qnetd から見てもクラスタは健全な状態であることが確認できます。

クォーラムデバイスを使ったクラスタの動作確認

前の検証では、クォーラムデバイスを使用しない 2 ノードクラスタにおいて、ノード間のネットワークを切断すると、両ノードがそれぞれ DC となり、リソースを起動してしまう (いわゆるスプリットブレイン状態) ことを確認しました。

ここでは、クォーラムデバイスを導入した場合に、同じ障害を発生させたときの挙動がどのように変わるのかを確認します。

正常時の状態確認

まずは、ネットワーク切断前の状態を確認します。

[root@node1 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: node1 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
* Last updated: Mon Feb 2 13:51:22 2026 on node1
* Last change: Mon Feb 2 13:36:39 2026 by root via root on node1
* 2 nodes configured
* 1 resource instance configured

Node List:
* Online: [ node1 node2 ]

Full List of Resources:
* Dummy (ocf:heartbeat:Dummy): Started node1

Quorum 情報を確認すると、Qdevice が投票に参加していることが分かります。

[root@node1:~]# pcs quorum status
Quorum information
------------------
Date:             Mon Feb  2 13:55:20 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          1
Ring ID:          1.26
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW node1 (local)
         2          1    A,V,NMW node2
         0          1            Qdevice

ノード間ネットワークの切断

次に、疑似障害として node1 と node2 間のインターコネクト通信を切断します。（Qdevice との通信は維持された状態）

障害発生後の状態確認

node1 と node2 間のネットワークを切断した後、それぞれのノードで pcs status を実行し、クラスタの状態を確認します。

[root@node1 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node1 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
  * Last updated: Mon Feb  2 15:14:59 2026 on node1
  * Last change:  Mon Feb  2 15:14:13 2026 by root via root on node1
  * 2 nodes configured
  * 1 resource instance configured

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

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Started node1

node1 は クォーラムデバイスからの投票を含めて quorum を維持しており、引き続き DC として選出され、リソースを起動した状態で稼働しています。

[root@node2 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node2 (version 3.0.1-3.el10-b1a23a6) - partition WITHOUT quorum
  * Last updated: Mon Feb  2 15:15:04 2026 on node2
  * Last change:  Mon Feb  2 15:14:14 2026 by root via root on node1
  * 2 nodes configured
  * 1 resource instance configured

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

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Stopped

node2 はクラスタ内では単独ノードとなり、クォーラムを満たせない状態 (partition WITHOUT quorum) となっています。その結果、DC にはなっているものの、quorum を持たないため、リソースは起動されない、という状態になっています。

クォーラム状態の確認

次に、node1 側で pcs quorum status を実行し、クォーラム状態を確認します。

[root@node1 /]# pcs quorum status
Quorum information
------------------
Date:             Mon Feb  2 15:16:14 2026
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          1
Ring ID:          1.86
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      2
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW node1 (local)
         0          1            Qdevice

この結果から分かる通り、node1 と Qdevice がそれぞれ 1 vote を保持し、合計 2 votes（quorum＝2）となるため、node1 側では quorum が維持されています。クォーラムデバイスは、デフォルト設定では存続しているノードのうち、最も小さな node ID を持つノードを含むパーティションを選択します。今回の構成では node1 が選択され、node2 側は quorum を失う結果となりました。

ログの確認

node2 側のログを確認すると、quorum 喪失に伴う挙動が明確に分かります。

(node2ログ)
Feb 2 15:14:48 node2 pacemaker-controld[4354]: notice: Node node1 state is now lost
Feb 2 15:14:48 node2 corosync[4330]: [QUORUM] This node is within the non-primary component and will NOT provide any services.

このログは、このノードは non-primary component (quorum を持たない側) に属しており、サービスを提供してはならない、ことを示しています。

続く Pacemaker のログでも、quorum 喪失によりリソース管理が抑止されていることが分かります。

(node2ログ)
Feb 2 15:14:49 node2 pacemaker-schedulerd[4353]: warning: Fencing and resource management disabled due to lack of quorum
Feb 2 15:14:49 node2 pacemaker-schedulerd[4353]: notice: Actions: Start Dummy ( node2 ) due to no quorum (blocked)

おわりに

本記事では、2 ノードクラスタにおけるスプリットブレイン対策として、クォーラムデバイスの仕組みと設定方法、そして実際の動作検証結果について解説しました。

クォーラムデバイスを導入しない場合、ノード間のネットワーク分断時に双方が自身を正当なクラスタと判断し、同時にリソースを起動してしまう可能性があります。一方で、クォーラムデバイスを追加することで投票数が奇数となり、外部の調停役による判定が加わることで、過半数を得た側のみがサービスを継続できるようになります。これにより、2 ノードクラスタ特有のスプリットブレインリスクを大きく低減できます。

特に、コストや設計上の理由から 2 ノード構成を採用せざるを得ない環境や、環境要件や構成上の制約により電源制御を用いたフェンシングを採用しない場合には、クォーラムデバイスは有効な補完策となります。

本記事が、2 ノードクラスタの設計やスプリットブレイン対策を検討されている方の参考になれば幸いです。

一方で、冗長化によって単一障害点は解消できるものの、クラスタノード間の通信が途絶えた場合には「スプリットブレイン」状態に陥るリスクが残ります。スプリットブレインが発生すると、複数のノードが同時に稼働系として振る舞い、IP アドレスの競合やファイルシステムの二重マウントなどが発生する可能性があります。最悪の場合、データ破損といった深刻な障害につながる恐れもあります。

そのため、クラスタ構成を安定して運用するうえで、スプリットブレイン対策は欠かせないポイントです。

本記事では、Pacemaker/Corosync クラスタで広く利用されているスプリットブレイン対策の仕組みについて解説します。

スプリットブレインとは

スプリットブレインとは、クラスタを構成するノード間の通信が途絶えた際に、各ノードが互いの状態を正しく認識できなくなり、複数のノードが同時に稼働系として動作してしまう状態を指します。

通常、クラスタではノード同士が定期的にハートビート通信を行い、相互監視を行っています。しかし、ネットワーク障害などにより通信が分断されると、各ノードは相手を「障害」と誤認する可能性があります。この状態では、同一サービスやリソースが複数ノードで同時に起動されるため、IP  アドレスの競合、ファイルシステムの二重マウント、共有データへの同時書き込み、などが発生する可能性があります。

スプリットブレイン対策

Pacemaker/Corosync クラスタでは、スプリットブレインを防止するために複数の仕組みが用意されています。

Stonith によるフェンシング

STONITH (Shoot The Other Node In The Head) は、クラスタ環境で発生し得るスプリットブレインを防止するためのフェンシング手法です。ノード間の通信が途絶えた場合に、インターコネクト (クラスタ通信用ネットワーク) とは独立した経路を用いて問題のあるノードを強制的に停止または再起動させることで、データ破壊やサービスの二重起動を防ぎます。具体的には、IPMI などのハードウェア制御ボードや、共有ストレージを介した制御を利用して、異常が発生したノードを停止/再起動させます。

具体的には、以下のような仕組みが利用されます。

• • IPMI などのハードウェア制御ボード
  • 仮想化基盤の API
  • 共有ストレージを利用した制御 (SBD など)

  
  

  Pacemaker/Corosync を利用した HA クラスタにおいて、STONITH は最も確実で推奨されるスプリットブレイン対策です。

  リソースの排他制御

  リソースの排他制御により、複数ノードでの同時起動を防止する方法もあります。sfex や VIPCheck は、排他制御を実現するリソースエージェントです。

  sfex は共有ディスクを使った排他制御を実現するリソースエージェントとなります。稼働系ノードが共有ディスク上に定期的に書き込みを行うことで排他状態を維持し、ノード間通信が途絶えた場合に、両系が同時に稼働系となることを防止します。

  VIPCheck は仮想 IP 状態をチェックすることで排他制御を実現します。共有ディスクが利用できない環境でも、リソースの二重起動を抑止できます。

  なお、sfex および VIPCheck は Linux-HA Japan が提供するリソースエージェントであり、RHEL HA Add-on の標準パッケージには含まれていません。

  クォーラムによる多数決制御

  クォーラムとは、クラスタ処理を継続するために必要な最低限の投票数のことを指します。スプリットブレイン対策として広く使われている一般的な手法です。

  一般的に、3台以上のノードでクラスタを構成し、過半数を獲得したパーティションのみがクラスタを継続できる仕組みです。過半数を満たさない場合はクォーラムを喪失し、no-quorum-policy の設定に従ってリソース停止やフェンシングが実行されます。

  

  Pacemaker における no-quorum-policy の各設定値の動作は以下の通りです。

  • stop (デフォルト)
    クォーラムを喪失したノード上のすべてのリソースを停止します。
  • freeze
    現在動作しているリソースはそのまま維持しますが、新規起動や再配置は行いません。
  • ignore
    クォーラム喪失を無視し、通常どおりリソース管理を継続します。
  • demote
    Master/Slave (Promotable) リソースが存在する場合、Master を Slave に降格します。
  • suicide
    クォーラムを喪失したノードをフェンシングします。

  クォーラムデバイス

  クォーラムデバイスは、ノード間通信が切断された際に、どのノード (またはパーティション) がクラスタの運用を継続すべきかを判断するための外部投票ノードです。特に偶数ノードで構成されたクラスタでは、ネットワーク分断時に投票数が同数となり、クォーラム (過半数) が成立しないという問題があります。なかでも2ノードクラスタでは、インターコネクトが切断されると双方が相手を障害と誤認し、スプリットブレイン状態に陥るリスクが高まります。

  このような構成では、クラスタノードとは別に調停役となるクォーラムデバイスを追加することで、クラスタ全体の投票数が奇数となり、過半数による多数決が成立します。その結果、スプリットブレイン発生時でも、どちらのノードがクラスタを継続すべきかを適切に判断できるようになります。

  2ノードクラスタの場合、通常は各ノードが1票ずつを持ちますが、クォーラムデバイスを追加すると合計3票となります。ネットワーク分断が発生した際には、クォーラムデバイスの投票を含めた多数決により、過半数を得たノードのみがクラスタ管理を継続できます。これにより、両ノードが同時にリソースを稼働させる事態を防止できます。

  

  クォーラムデバイスを利用する場合、クラスタノードには corosync-qdevice をインストールし、調停役となるサーバには corosync-qnetd をインストールします。corosync-qnetd デーモンはクラスタ外部で動作し、投票を行います。分断時には corosync-qnetd の判定結果に基づき、過半数を得たノードのみがクラスタを維持し、過半数を得られなかったノードはクラスタサービスを停止します。

  偶数ノード構成、特に2ノードクラスタではスプリットブレインのリスクが高いため、クォーラムデバイスの利用が推奨されます。

  クォーラムデバイスの具体的な設定方法や、ネットワーク分断時の挙動を含む詳細な動作確認については、こちらの記事にて詳しく解説していますので、あわせてご参照ください。

  おわりに

  本記事では、スプリットブレイン対策として広く利用される以下の仕組みについて解説しました。

  • STONITH によるフェンシング
  • リソースの排他制御
  • クォーラムによる多数決制御
  • クォーラムデバイス

  Pacemaker には多数のフェンスエージェントが用意されており、物理サーバ、仮想化基盤、共有ディスク環境など、それぞれの構成に応じたフェンシング方式を選択できます。HA クラスタにおいては、フェンシングの実装が最も確実なスプリットブレイン対策といえます。

  一方で、環境要件や構成上の制約により電源制御を用いたフェンシングを採用しない場合には、クォーラム制御やクォーラムデバイスの利用によって多数決の仕組みを補強する方法があります。特に2ノードクラスタでは、クォーラムデバイスを追加することで投票数を奇数化し、分断時の判断を明確にできます。

  HA クラスタでは、冗長化するだけでは不十分で、障害時の挙動まで考えた設計が欠かせません。本記事が、より安全で堅牢なクラスタ構築の参考になれば幸いです。

内部的には複数のデーモンプロセスがそれぞれ役割を担い、連携しながら動作しています。本記事では、Pacemaker/Corosync のプロセス構成とプロセス間のデータ処理の流れ、さらに状態遷移の仕組みについて解説します。

※バージョンによって挙動が異なる場合があるため、本記事では Pacemaker 2.1 を前提としています。

Pacemaker/Corosync のプロセス構成

Pacemaker の内部では、複数のデーモンプロセスが役割を分担し、クラスタ全体の監視、制御、リソース管理を行います。一方、Corosync はクラスタを構成するノード間の通信や死活監視、クォーラム管理を担当するプロセスです。両者が連携することで、障害が発生した場合でもサービスを継続できる、高可用性クラスタを実現できます。

主要なプロセスの役割は以下のとおりです。

pacemakerd

Pacemaker クラスタ全体の管理を担う親デーモンであり、以下の各サブデーモンプロセスの起動・監視を行い、異常時は再起動します。

pacemaker-based

クラスタの設定や状態情報を保持する CIB (Cluster Information Base、詳細は後述) を管理するプロセスです。CIB は XML 形式で構造化されており、クラスタ設定やリソースの構成、ノードの状態などが記録されています。pacemaker-based は CIB の読み書きを行い、常に最新の情報を反映させるとともに、複数ノード間で内容が一致するよう同期処理を行い、クラスタ全体の一貫性を維持します。

pacemaker-attrd

クラスタノードやリソースに関する動的属性情報 (稼働状況、フェイルカウントなど) を管理するプロセスです。pacemaker-attrd は各ノードから収集した属性情報を保持し、必要に応じてクラスタ全体に伝達します。

pacemaker-schedulerd

CIB の情報をもとに、どのノードでどのリソースを動かすかを決定するプロセスです。フェイルオーバー時のリソース配置計画もここで決定されます。

pacemaker-controld

Pacemaker クラスタにおける「調整役」を担うプロセスです。このプロセスは pacemaker-schedulerd が決定した計画に基づき、各ノード上の pacemaker-execd に対してリソースの起動、停止、監視を指示します。

pacemaker-execd

ローカルノード上でリソースエージェントの起動、停止、監視を実行するプロセスです。操作結果は pacemaker-controld に報告され、クラスタ全体の判断材料として利用されます。

pacemaker-fenced

障害を起こしたノードを強制的にリブートまたはシャットダウンするフェンシングを担当するプロセスです。データ破壊や二重書き込みなどの重大な障害を防ぐため、STONITH デバイスを操作して信頼できないノードをクラスタから隔離します。

なお、Pacemaker 2.0 系ではプロセス名が変更されました。ただし、機能自体は従来と同じです。旧プロセス名との対応関係を以下の表に示します。

CIB (Cluster Information Base) とは

Pacemaker では、各プロセスが CIB を中心に情報を共有・同期することで、クラスタ全体の一貫性を保っています。

CIB は XML 形式で管理されるクラスタ情報のデータベースであり、クラスタの構成や各リソースの状態を記録します。CIB には、クラスタの状態変化に応じてリアルタイムで更新される動的な情報が保持されており、クラスタ全体の整合性を維持するうえで重要な役割を担っています。各ノード上の pacemaker-based プロセスが CIB を管理し、更新や同期を行うことで、pacemaker-schedulerd は常に最新の情報に基づいてリソースの配置やフェイルオーバーの判断を行うことができます。

CIB の構造は主に以下のセクションで構成されています。

<cib crm_feature_set="3.19.6" ...>
  <configuration>
    <!-- クラスタ設定（リソース定義、制約、ノード設定など） -->
  </configuration>
  <status>
    <!-- 実行中のリソースの状態やノードの状態 -->
  </status>
</cib>

プロセス間データ処理の流れと状態遷移の仕組み

Pacemaker では、複数のサブデーモンが連携してクラスタを制御します。その中心的役割を担う pacemaker-controld は、クラスタの「頭脳」として動作し、ノードの参加・離脱、リソースの起動・停止、フェイルオーバーなど、クラスタ内で発生する各種イベントに応じて内部状態を遷移させつつ、クラスタ全体を制御します。

代表的な状態は次のとおりです。

次に、一例として 起動時および障害発生時における状態遷移の流れについて解説します。

起動時の状態遷移

クラスタの起動時、Pacemaker の各サブデーモンは協調しながら、ノード間でメンバーシップを確立し、リソース配置を決定します。このプロセスは段階的に進み、各状態で必要な初期化や情報収集、計算処理が行われた上で、最終的にクラスタは安定状態に到達します。

起動
│  
│  親デーモン pacemakerd が起動し、各サブデーモンをを順次起動
│  (controld, schedulerd, execd, based, attrd, fenced)
│
▼
S_STARTING (初期化開始)
│
│  自ノード (node1) の状態を unknown → member に更新
│  CIB 読み込み、Corosync 接続
│  他ノードの参加を待機
│
▼
S_PENDING (待機)
│
│  node2 の参加を検知
│  DC 選挙開始
│
▼
S_ELECTION (DC選挙)
│
│  投票の結果、node1 が DC に選出
│
▼
S_INTEGRATION (ノード統合)
│
│  JOIN 要求を受け入れ、node2 をクラスタに統合
|
▼
S_FINALIZE_JOIN (JOIN確定)
│ 
│  クラスタメンバーシップを確定
│  
│  * pacemaker-based
│     JOIN が完了したノード情報を CIB に反映
│  
▼
S_POLICY_ENGINE
│
│  * pacemaker-schedulerd
│     DC (node1) が決定後、リソース配置計算を開始
│     クラスタ全体のリソースの起動／配置プランを生成
│     計算結果を pacemaker-controld に渡す
│
▼
S_TRANSITION_ENGINE
│
│  * pacemaker-execd
│     pacemaker-controld の指示に従って start/stop/monitor を実行
│     成否を pacemaker-controld にフィードバック
│
│  * pacemaker-controld
│     リソース操作の成功を確認
│
▼
S_IDLE (安定状態)
│
│  リソース操作がすべて正常終了
│  クラスタは安定状態に遷移
│

障害発生時の状態遷移

クラスタ稼働中にリソース障害やノード障害が発生した場合、Pacemaker はそのイベントを検知し、自動的に回復処理を行います。障害発生時は、クラスタが持つ最新の CIB 情報に基づいて、フェイルオーバーや再起動などのアクションを決定し、適切に実行します。

S_IDLE (安定状態)
│
│  クラスタは安定稼働中
│  * pacemaker-execd (node1)
│     VIP_monitor_10000 が定期的に実行される
│     結果: 失敗 (rc=7, not running)
│     この結果を pacemaker-controld に返却
│  
│  * pacemaker-controld (node1)
│     monitor 失敗を検知
│     CIB 更新要求を pacemaker-based に送信
│  
│  * pacemaker-based (node1)
│     CIB 更新要求を処理
│     CIB をディスクに書き込み
│
│  * pacemaker-attrd (node1)
│     属性を更新：
│        ・last-failure-VIP#monitor_10000[node1] = 1756193718
│        ・fail-count-VIP#monitor_10000[node1] = 1
│     CIB に反映
│
▼
S_POLICY_ENGINE (リソース配置計算)
│
│  * pacemaker-schedulerd (node1)
│     CIB の変更を検知し、リソース配置計算を再実行
│     migration-threshold=1 のため node1 での再起動不可と判断
│     VIP を node2 へ移動する決定
│     Transition 10（遷移グラフ）を生成：
│       ・VIP_stop on node1
│       ・VIP_start on node2
│       ・VIP_monitor_10000 on node2 (recurring)
│
▼
S_TRANSITION_ENGINE (アクション実行)
│
│  * pacemaker-controld (node1)
│     pacemaker-schedulerd から受け取った Transition 10 を順次実行
│     まず pacemaker-execd (node1) に VIP_stop を要求
│  
│  * pacemaker-execd (node1)
│     VIP_stop を実行し、結果を pacemaker-controld に返却
│
│  * pacemaker-controld (node1)
│     次に node2 に VIP_start を指示
│
│  * pacemaker-execd (node2)
│     VIP_start を実行
│     VIP_monitor_10000 を開始
│     結果を pacemaker-controld (node2) に返却
│
▼
S_IDLE (安定状態復帰)
│
│  VIP が node2 上で正常稼働開始
│  monitor 監視も復帰
│  クラスタは再び安定状態へ移行
│

おわりに

今回は、Pacemaker/Corosync のプロセス構成と、pacemaker-controld を中心とした状態遷移の仕組みについて解説しました。

Pacemaker は複数のデーモンプロセスが協調して動作しており、CIB を中心とした情報共有や状態遷移の制御を正しく理解することで、クラスタの挙動をより深く把握できます。これにより、トラブルシューティングやクラスタ構成の最適化を行う際に大いに役立つでしょう。

本記事では、Booth の概要、インストール・設定方法、基本的な使い方について紹介します。

Booth とは

Pacemaker は WAN 経由で複数のサイトのクラスタ状態を管理できないため、サイトの障害やサイト間のネットワークに問題が発生した場合には、別のサイトが稼働中であるかどうかは Pacemaker が判断できません。各サイトの状態の確認およびサイト間の切り替えは人間の判断で行うか、クラスタチケット管理 (CTR) 機能を用いて自動的に行います。

CTR 機能を使うと、マルチサイトクラスタにおいて、チケットが付与されたサイトが稼働系になり、そのチケットに依存するリソースを起動する権限が与えられます。
チケットが取り消された場合は、サイトが待機系に切り替わり、そのチケットに依存するリソースが停止状態になります。

Pacemaker で CTR を実現するには、アドオン機能である Booth を導入する必要があります。

Booth を利用することで、地理的に離れた複数のサイトを跨いでチケット管理を行うことができ、チケットを付与/取り消しすることで、サイト間での稼働系/待機系の切り替えや自動フェイルオーバ、リソースの起動/停止を制御することが可能になります。

Booth によるチケット管理の仕組み

Booth を用いたマルチサイトクラスタ環境では、通常のサイト (稼働系サイト/待機系サイト) に加えて、アービトレータ (調停役) と呼ばれるもう1つのサイト (1つのノード) を追加する必要があります。

ネットワーク障害等によりサイト間の通信が途絶えた場合には、別のサイトの障害なのか、サイト間のネットワークの障害なのかを区別する方法はないため、スプリットブレインに陥る可能性があります。これはクラスタ環境での固有の問題となります。そのため、フェイルオーバなどの決定について多数決による合意形成のために3つのサイトが必要です。3つ目のサイト (アービトレータ) を導入することで、合意形成によってサイト間のフェイルオーバーを制御することができ、スプリットブレインに陥ることを防ぎます。

以下はマルチサイトクラスタの基本的な構成となります。

両方のサイトおよびアービトレータで boothd デーモンが起動しており、お互い通信し、情報交換します。稼働系のサイトに障害が発生した場合、Booth の合意形成によって待機系のサイトにチケットを付与し、待機系のサイトを自動的に稼働系に昇格させます。

Booth を利用することで、チケット管理の自動化ができ、複数の拠点にまたがるマルチサイトクラスタでの自動フェイルオーバが可能になり、ダウンタイムを最小限に抑えることができます。

クラスタ構成

本記事では、2つのクラスタサイト (2ノード構成) および1つのアービトレータを含むマルチサイトクラスタを構築します。

クラスタ構成は以下になります。

仮想IPは Booth 間通信で利用されるIPアドレスとなります。

前提条件

• 今回は検証目的で RHEL クローン OS の Rocky Linux 環境を用いて検証を行います。Rocky Linux では Red Hat High Availability Add-On 相当のパッケージが HighAvailability リポジトリに含まれているため、今回はそちらのリポジトリを利用してインストールします。バージョン情報は以下になります。

• アービトレータを含むすべてのノードの /etc/hosts にノード情報が登録されています。

(両サイトのすべてのノードおよびアービトレータで実行)
# vi /etc/hosts
(以下を追加)
192.168.101.101 clusterA-1
192.168.101.102 clusterA-2
192.168.102.101 clusterB-1
192.168.102.102 clusterB-2
192.168.100.100 arbitrator

Pacemaker のインストールおよびクラスタの初期設定

ここでは、Pacemaker のインストールおよびクラスタの初期設定の手順を記載します。

1. Pacemaker をインストールします。

両サイトのすべてのノードで Rocky Linux の HighAvailability リポジトリを有効にして Pacemaker をインストールします。

(両サイトのすべてのノードで実行)
# yum install -y --enablerepo=ha pacemaker pcs fence-agents-all

RHEL 環境を利用している場合は、Red Hat 社によって提供される Red Hat High Availability Add-On のパッケージを利用してインストールしてください。詳細についてはこちらを参照してください。

2. firewalld デーモンが起動している場合は、クラスタで必要なポートを有効化するように以下のコマンドを実行します。

(両サイトのすべてのノードおよびアービトレータで実行)
# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --reload

3. 両サイトのすべてのノードで hacluster ユーザのパスワードを設定します。

(両サイトのすべてのノードで実行)
# passwd hacluster
Changing password for user hacluster.
New password: (haclusterユーザのパスワードを入力)
Retype new password: (haclusterユーザのパスワードを入力)
passwd: all authentication tokens updated successfully.

4. 両サイトのすべてのノードで以下のコマンドを実行し、pcsd の自動起動を有効化します。

(両サイトのすべてのノードで実行)
# systemctl start pcsd.service
# systemctl enable pcsd.service

5. 両サイトでクラスタを構成するノードに対して、hacluster ユーザの認証を行います。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs host auth clusterA-1 clusterA-2 -u hacluster
Password: (haclusterユーザのパスワードを入力)
clusterA-1: Authorized
clusterA-2: Authorized

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs host auth clusterB-1 clusterB-2 -u hacluster
Password: (haclusterユーザのパスワードを入力)
clusterB-1: Authorized
clusterB-2: Authorized

6. 両サイトでクラスタを作成します。それぞれの名前を clusterA、clusterB とします。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs cluster setup clusterA clusterA-1 clusterA-2

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs cluster setup clusterB clusterB-1 clusterB-2

7. 両サイトでクラスタを起動します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs cluster start --all
[root@clusterA-1 ~]# pcs status
Cluster name: clusterA
...
Node List:
* Online: [ clusterA-1 clusterA-2 ]

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs cluster start --all
[root@clusterB-1 ~]# pcs status
Cluster name: clusterB
...
Node List:
* Online: [ clusterB-1 clusterB-2 ]

8. クラスタを安全に運用するために、フェンシングの設定が必要になりますが、今回は Booth によるマルチサイトクラスタを説明することを目的としているため、以下のコマンドを実行し、フェンシングを無効にします。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs property set stonith-enabled=false

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs property set stonith-enabled=false

9. 両サイトで検証用のリソースグループを作成します。今回は、Apache および IPaddr2 を含むリソースグループを作成します。作成手順はこちらを参照してください。

リソースが作成されていることを確認します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs status
Cluster name: clusterA
...
Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Started clusterA-1
    * VIP       (ocf::heartbeat:IPaddr2):        Started clusterA-1

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs status
Cluster name: clusterB
...
Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Started clusterB-1
    * VIP       (ocf::heartbeat:IPaddr2):        Started clusterB-1

以上で、Pacemaker クラスタの初期設定は完了です。

Booth のインストールおよび設定

ここでは、Booth のインストールおよび設定手順を記載します。

1. Booth をインストールします。

両サイトのすべてのノードに booth-core および booth-site パッケージをインストールします。

(両サイトのすべてのノードで実行)
# yum install -y --enablerepo=ha booth-site booth-core

アービトレータノードに pcs、booth-core、および booth-arbitrator パッケージをインストールします。

(アービトレータノードで実行)
[root@arbitrator ~]# yum install -y --enablerepo=ha pcs booth-core booth-arbitrator

2. Booth の設定を行います。

Booth の設定やチケットは、まず片方のサイトで 作成した後、すべてのクラスタノードおよびアービトレータで設定の同期を行うという流れになります。
今回は、まずサイトAのノード1で設定を行います。

サイトAのノード1で以下のコマンドを実行し、Booth の設定を行います。
sites に各サイトの仮想IP、arbitrators にアービトレータノードのIPアドレスを指定します。

(サイトAのノード1で実行)
[root@clusterA-1 ~]# pcs booth setup sites 192.168.101.100 192.168.102.100 arbitrators 192.168.100.100

3. チケットを作成します。

サイトAのノード1でチケットを作成します。

(サイトAのノード1で実行)
[root@clusterA-1 ~]# pcs booth ticket add apacheticket expire=120 acquire-after=60 timeout=5

それぞれのオプションの意味は以下の通りです。

• timeout: Booth 間パケット送信のタイムアウト時間。
• expire: 通信が失敗した後のチケットの有効期限。有効期限を過ぎるとチケットが取り消される (revoke)。
• acquire-after: チケットが取り消された後、他のサイトに付与されるまでの時間。

Booth の設定は /etc/booth/booth.conf ファイルに書き込まれます。
現在の設定を確認するには pcs booth config を実行します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth config
authfile = /etc/booth/booth.key
site = 192.168.101.100
site = 192.168.102.100
arbitrator = 192.168.100.100
ticket = "apacheticket"
  acquire-after = 60
  expire = 120
  timeout = 5

その他の設定オプションについてはこちらを参照してください。

4. 現在のクラスタのすべてのノードに対して Booth 設定の同期を行います。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth sync
Sending booth configuration to cluster nodes...
clusterA-1: Booth config saved
clusterA-2: Booth config saved

5. アービトレータノードで Booth 設定を同期します。

(アービトレータノードで実行)
[root@arbitrator ~]# pcs host auth clusterA-1 -u hacluster
Password: (haclusterユーザのパスワードを入力)
clusterA-1: Authorized

(アービトレータノードで実行)
[root@arbitrator ~]# pcs booth pull clusterA-1
Fetching booth config from node 'clusterA-1'...
Booth config saved

6. サイトBで Booth 設定を同期します。

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs host auth clusterA-1 -u hacluster
Password: (haclusterユーザのパスワードを入力)
clusterA-1: Authorized

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs booth pull clusterA-1

[root@clusterB-1 ~]# pcs booth sync

7. アービトレータノードで Booth を起動します。

サイトAおよびサイトBでは、Booth は Pacemaker のリソースとして管理され、Pacemakerによって起動するため、各クラスタノードで Booth を手動で起動しないでください。

(アービトレータノードで実行)
[root@arbitrator ~]# pcs booth start
[root@arbitrator ~]# pcs booth enable

8. 両サイトで Booth リソースを作成します。IPアドレスにそれぞれのクラスタの仮想IPを指定します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth create ip 192.168.101.100

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs booth create ip 192.168.102.100

上記コマンドを実行すると、booth-ip および booth-service を含むリソースグループ booth-booth-group が作成されます。

9. 両サイトで作成した検証用のリソースグループ apachegroup にチケット制約を追加します。

チケット制約とは、チケットがクラスタサイトに付与された場合にのみ、リソースの起動を許可する制約となります。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs constraint ticket add apacheticket apachegroup

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs constraint ticket add apacheticket apachegroup

上記チケット制約を追加すると、apachegroup のリソースが Stopped になり、チケットが付与されるまで起動しません。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs status
Cluster name: clusterA
...
Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Stopped
    * VIP       (ocf::heartbeat:IPaddr2):        Stopped
  * Resource Group: booth-booth-group:
    * booth-booth-ip    (ocf::heartbeat:IPaddr2):        Started clusterA-2
    * booth-booth-service       (ocf::pacemaker:booth-site):     Started clusterA-2

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs status
Cluster name: clusterB
...
Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Stopped
    * VIP       (ocf::heartbeat:IPaddr2):        Stopped
  * Resource Group: booth-booth-group:
    * booth-booth-ip    (ocf::heartbeat:IPaddr2):        Started clusterB-2
    * booth-booth-service       (ocf::pacemaker:booth-site):     Started clusterB-2

現在設定されているチケット制約確認するには、pcs constraint ticket を実行します。

10. 片方のサイトにチケットを付与します。

ここでは、サイトAを稼働系にするために、サイトAのいずれかのノードで以下のコマンドを実行し、チケットを付与します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth ticket grant apacheticket

サイトAのクラスタにチケットを付与すると、サイトAのクラスタのリソースが起動します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs status
Cluster name: clusterA
...
Node List:
  * Online: [ clusterA-1 clusterA-2 ]

Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Started clusterA-1
    * VIP       (ocf::heartbeat:IPaddr2):        Started clusterA-1
  * Resource Group: booth-booth-group:
    * booth-booth-ip    (ocf::heartbeat:IPaddr2):        Started clusterA-2
    * booth-booth-service       (ocf::pacemaker:booth-site):     Started clusterA-2

サイトBでは、チケットが付与されていないため、リソースが Stopped のままの状態となります。

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs status
Cluster name: clusterB
...
Node List:
  * Online: [ clusterB-1 clusterB-2 ]

Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Stopped
    * VIP       (ocf::heartbeat:IPaddr2):        Stopped
  * Resource Group: booth-booth-group:
    * booth-booth-ip    (ocf::heartbeat:IPaddr2):        Started clusterB-2
    * booth-booth-service       (ocf::pacemaker:booth-site):     Started clusterB-2

以上で、Booth の設定は完了です。

Booth の基本的な使い方

Booth クラスタの状態の確認

現在の稼働系サイト、チケットや Booth 間の接続詳細情報などを確認するには、pcs booth status を実行します。

(いずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth status
TICKETS:
ticket: apacheticket, leader: 192.168.101.100, expires: 2022-08-17 13:07:03

PEERS:
site         192.168.102.100, last recv: 2022-08-17 13:05:03
        Sent pkts:13 error:0 resends:0
        Recv pkts:12 error:0 authfail:0 invalid:0

arbitrator   192.168.100.100, last recv: 2022-08-17 13:05:03
        Sent pkts:13 error:0 resends:0
        Recv pkts:12 error:0 authfail:0 invalid:0

フェイルオーバ

稼働系サイトに障害が発生した場合の自動フェイルオーバを検証します。

稼働系サイトAのクラスタを停止します。

(サイトAのいずれかのノードで実行)
[root@clusterA-1 ~]# pcs cluster stop --all

しばらくすると、サイトBにチケットが付与され、リソースが起動することを確認します。

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs booth status
TICKETS:
ticket: apacheticket, leader: 192.168.102.100, expires: 2022-08-17 13:21:10

PEERS:
site         192.168.101.100, last recv: 2022-08-17 13:12:04
        Sent pkts:86 error:0 resends:49
        Recv pkts:26 error:0 authfail:0 invalid:0

arbitrator   192.168.100.100, last recv: 2022-08-17 13:19:09
        Sent pkts:13 error:0 resends:0
        Recv pkts:12 error:0 authfail:0 invalid:0

(サイトBのいずれかのノードで実行)
[root@clusterB-1 ~]# pcs status
Cluster name: clusterB
...
Node List:
  * Online: [ clusterB-1 clusterB-2 ]

Full List of Resources:
  * Resource Group: apachegroup:
    * WebSite   (ocf::heartbeat:apache):         Started clusterB-1
    * VIP       (ocf::heartbeat:IPaddr2):        Started clusterB-1
  * Resource Group: booth-booth-group:
    * booth-booth-ip    (ocf::heartbeat:IPaddr2):        Started clusterB-2
    * booth-booth-service       (ocf::pacemaker:booth-site):     Started clusterB-2

サイトBに以下のようなログが出力され、チケットがサイトBに付与されていることが分かります。

Aug 17 13:15:03 clusterB-2 booth: [4088]: warning: apacheticket (Fllw/0/0): lost at 192.168.101.100
Aug 17 13:15:04 clusterB-2 booth: [4088]: info: apacheticket (Fllw/1/0): starting new election (term=1)
Aug 17 13:15:09 clusterB-2 booth: [4088]: info: apacheticket (Cndi/1/0): elections finished
Aug 17 13:15:09 clusterB-2 booth: [4088]: info: apacheticket (Lead/1/119997): granted successfully here

手動でフェイルオーバさせたい場合には、稼働系でチケットの取り消し (revoke) した後、待機系に付与 (grant) するという流れになります。

例えば、サイトAが稼働系の場合は、まず、サイトAからチケットを取り消します。
サイトの仮想IPを明示的に指定して pcs booth ticket revoke/grant を実行する場合は、どちらのノードでも実行可能です。

(いずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth ticket revoke apacheticket 192.168.101.100

次に、待機系サイトBにチケットを付与します。

(いずれかのノードで実行)
[root@clusterA-1 ~]# pcs booth ticket grant apacheticket 192.168.102.100

サイトBにチケットを付与すると、サイトBが稼働系になり、リソースが起動します。

マルチサイトクラスタにおける DRBD の使用

マルチサイトクラスタで DRBD を使用する場合には、DRBD のデータを WAN を介して待機系サイトにレプリケーションする仕組みが必要になります。

DRBD Proxy を使うことで、WAN 環境のような遠距離レプリケーションを効率的に行えます。DRBD Proxy は LINBIT 社が提供している有償オプション製品であり、詳細についてはこちらを参照してください。

おわりに

今回は、Pacemaker のアドオン機能 Booth を用いてマルチサイトクラスタの構築・設定方法や基本的な使い方について紹介しました。

Booth を使うことで、地理的に離れた複数の拠点にまたがる高可用性クラスタを構築できます。システムの高可用性や災害対策を検討している方に、本記事の内容がお役に立てれば幸いです。

2ノードで完結させたい場合や、その他のリソースもあわせて管理したい場合はPacemaker/Corosyncを使用するのが便利です。Pacemakerには標準でRedisのリソースエージェントが含まれているため、比較的容易にRedisのクラスタを構築することができます。

前提

以下の環境を前提とします。今回はOS標準のPacemakerを使用します。

• OS: CentOS 7.4
• パッケージ:
  • redis-5.0.5-1.el7.remi
  • pacemaker-1.1.19-8.el7_6.4
  • corosync-2.4.3-4.el7

RedisとPacemakerのクラスタ構成は以下のようになります。

Pacemakerのインストールと初期設定

両方のノードに必要なパッケージをインストールします。なお、Redisのインストールおよびマスター・スレーブレプリケーションの設定は完了しているものとします。

# yum install corosync pacemaker pcs fence-agents-all

クラスタを新規作成します。

server1# pcs cluster auth server1 server2 -u hacluster -p (haclusterユーザのパスワード) --force
server1# pcs cluster setup --name cluster1 server1 server2

corosync.conf の quorum の設定に以下を追加します。これは2ノードクラスタで片方のノード単独で起動できるようにするために必要です(理由は後述します)。

quorum {
    provider: corosync_votequorum
    two_node: 1
    wait_for_all: 0  ★追加
}

クラスタを起動します。

server1# pcs cluster start --all

server1# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Mon Jul  1 16:57:00 2019
Last change: Mon Jul  1 16:56:58 2019 by root via cibadmin on server1

2 nodes configured
0 resources configured

Online: [ server1 server2 ]

No resources


Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

今回は動作確認のためSTONITHを無効化し、1回の障害検知でフェイルオーバーするように設定します。

# pcs property set stonith-enabled=false
# pcs resource defaults resource-stickiness=INFINITY migration-threshold=1

Pacemakerリソースの作成

仮想IPリソースを作成します。

# pcs resource create VIP ocf:heartbeat:IPaddr2 
  ip=192.168.237.150 cidr_netmask=24 nic=eth1 
  op monitor interval=10s

Redisのマスター・スレーブリソースを作成します。Pacemakerのマスター・スレーブリソースは、複数のノードに複製され、主従関係をもつリソースです。リソースエージェントは resource-agents パッケージに含まれる ocf:heartbeat:redis を使用します。以下の例では、redisリソースおよびそのマスター・スレーブリソースを一度に作成しています。マスター・スレーブリソースはデフォルトで「<リソースID>-master」(redis-master)という名前が付きます。

# pcs resource create redis ocf:heartbeat:redis 
  op start timeout=300s 
  op monitor interval=5s 
  op monitor interval=3s role=Master 
  master

VIPリソースとRedisのマスター・スレーブリソースのマスター側を colocation 制約で同じサーバに結び付けます。

# pcs constraint colocation add VIP with master redis-master score=INFINITY

この時点でリソースは起動しますが、一度両ノードのPacemakerを停止します。設定中にリソースを起動させたくない場合は先に両ノードをスタンバイモード(pcs node standby/unstandby)にしておいてもよいです。

server2# systemctl stop pacemaker
server1# systemctl stop pacemaker

クラスタの起動

Masterにしたいノード(server1)でPacemakerを起動します。

server1# systemctl start pacemaker
server1# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Fri Jul 19 14:20:49 2019
Last change: Fri Jul 19 14:15:52 2019 by root via crm_attribute on server2

2 nodes configured
3 resources configured

Online: [ server1 ]
OFFLINE: [ server2 ]

Full list of resources:

 VIP    (ocf::heartbeat:IPaddr2):       Started server1
 Master/Slave Set: redis-master [redis]
     Masters: [ server1 ]
     Stopped: [ server2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

server1ですべてのリソースの起動が完了したことを確認したら、server2のPacemakerを起動します。

server2# systemctl start pacemaker

しばらく待ち、リソースの起動が正常に完了すると以下のようになります。

# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Fri Jul 19 14:24:24 2019
Last change: Fri Jul 19 14:15:52 2019 by root via crm_attribute on server2

2 nodes configured
3 resources configured

Online: [ server1 server2 ]

Full list of resources:

 VIP    (ocf::heartbeat:IPaddr2):       Started server1
 Master/Slave Set: redis-master [redis]
     Masters: [ server1 ]
     Slaves: [ server2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

# pcs constraint
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  VIP with redis-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master)
Ticket Constraints:

Redisのレプリケーションが正常に行われていることを確認します。

server1# redis-cli info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.237.102,port=6379,state=online,offset=1372,lag=0

server2# redis-cli info replication
# Replication
role:slave
master_host:server1
master_port:6379
master_link_status:up

また、MasterノードにVIPが割り振られていることを確認します。

server1# ip -4 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.237.101/24 brd 192.168.237.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet 192.168.237.150/24 brd 192.168.237.255 scope global secondary eth1
       valid_lft forever preferred_lft forever

server2# ip -4 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.237.102/24 brd 192.168.237.255 scope global eth1
       valid_lft forever preferred_lft forever

フェイルオーバー

RedisのMasterプロセスに障害を発生させ、server2がMasterになることを確認します。

server1# killall redis-server
server1# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Fri Jul 19 15:34:23 2019
Last change: Fri Jul 19 15:33:18 2019 by root via crm_attribute on server2

2 nodes configured
3 resources configured

Online: [ server1 server2 ]

Full list of resources:

 VIP    (ocf::heartbeat:IPaddr2):       Started server2
 Master/Slave Set: redis-master [redis]
     Masters: [ server2 ]
     Stopped: [ server1 ]

Failed Actions:
* redis_demote_0 on server1 'not running' (7): call=49, status=complete, exitreason='',
    last-rc-change='Fri Jul 19 15:33:18 2019', queued=0ms, exec=85ms


Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

redis リソースをクリーンアップし、server1がSlaveとして復旧することを確認します。

server1# pcs resource cleanup redis
Cleaned up redis:0 on server2
Cleaned up redis:0 on server1
Cleaned up redis:1 on server2
Cleaned up redis:1 on server1
Waiting for 1 replies from the CRMd. OK

# pcs status resources
 VIP    (ocf::heartbeat:IPaddr2):       Started server2
 Master/Slave Set: redis-master [redis]
     Masters: [ server2 ]
     Slaves: [ server1 ]

リソース起動時の注意点

Pacemaker/Corosyncの2ノードクラスタのデフォルトでは、両ノードのPacemakerが起動した時点でリソースを起動します。この場合、RedisのMasterとSlaveはほぼ同時に起動し、Masterの準備が完了していない状態でSlaveが接続しようとするため、レプリケーションの開始に失敗する場合があります。これを防ぐため、上記手順ではCorosyncの設定を変更し、Masterの起動を待ってからSlaveを起動するようにしています。

1. DRBD9について

DRBDは複数台のLinuxサーバで、ネットワーク経由で共有ストレージを構築するためのシステムです。

DRBD9はDRBD8.xから以下のような機能が強化されています。

• 自動プロモーション機能によりマウント時に自動でプライマリへの昇格・セカンダリへの降格が行えるようになった
• drbdmanage コマンドによりノードやボリュームの追加・削除が簡単に行えるようになった
• 1階層で最大31ノードまでの多ノード構成が可能(DRBD8まではスタック構成のみ可)

特に、自動プロモーション機能によりPacemakerでクラスタを組む場合に大幅に設定を簡略化できるようになりました。

2. 構成

本記事では以下のサーバ構成を想定します。

3. パッケージのインストール

本記事ではELRepoリポジトリ(http://elrepo.org)のrpmパッケージをインストールします。/

両ノードにDRBD9をインストールします。

# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
# yum install kmod-drbd90 drbd90-utils

4. 設定ファイルの作成

drbdmanage を使用せず自分でDRBDのリソースを管理する場合はリソースの設定ファイルを作成します。

/etc/drbd.d/drbd0.res として設定ファイルを作成します。

resource drbd0 {
        protocol C;

        disk /dev/sdb1;
        device /dev/drbd0;
        meta-disk internal;
        on server1 {
                address 192.168.1.11:7789;
        }
        on server2 {
                address 192.168.1.12:7789;
        }
}

/etc/drbd.d/global_common.conf に以下の設定を追加します。自動プロモーションはデフォルトで有効のため、「auto-promote yes;」は追加しなくてもOKです。

global {
        usage-count no;
        ...
}

common {
        ...
        options {
                auto-promote yes;
        }
        ...
}

5. DRBDデバイスの作成

両ノードのディスクsdbにsdb1パーティションを作成し、先頭を0初期化します。
※対象のディスクのデータはすべて削除されるので注意!

# cfdisk /dev/sdb
# dd if=/dev/zero of=/dev/sdb1 bs=1M count=1

両ノードでメタデータを作成します。

# drbdadm create-md drbd0

リソースを有効化します。

[root@server1 ~]# drbdadm up drbd0
[root@server1 ~]# drbdadm status drbd0
drbd0 role:Secondary
  disk:Inconsistent
  server2 connection:Connecting

[root@server2 ~]# drbdadm up drbd0
[root@server2 ~]# drbdadm status drbd0
drbd0 role:Secondary
  disk:Inconsistent
  server1 role:Secondary
    peer-disk:Inconsistent

[root@server1 ~]# drbdadm status drbd0
drbd0 role:Secondary
  disk:Inconsistent
  server2 role:Secondary
    peer-disk:Inconsistent

この時点ではまだデバイスの同期が行われていないため、「Inconsistent」状態になります。

6. デバイスの初期同期

server1を同期元として指定し、同期を開始します。

[root@server1 ~]# drbdadm primary --force drbd0

同期が完了した場合、両方のディスクが「UpToDate」になります。

[root@server1 ~]# drbdadm status drbd0
drbd0 role:Primary
  disk:UpToDate
  server2 role:Secondary
    peer-disk:UpToDate

[root@server2 ~]# drbdadm status drbd0
drbd0 role:Secondary
  disk:UpToDate
  server1 role:Primary
    peer-disk:UpToDate

なお、 DRBD 8.xでは cat /proc/drbd でもステータスを確認できましたが、DRBD9では利用できませんのでご注意ください。

7. ファイルシステムの作成

現在プライマリとなっているノードでDRBDデバイス上にファイルシステムを作成します。

[root@server1 ~]# mkfs.ext4 /dev/drbd0
...

[root@server1 ~]# mkdir /mnt/drbd
[root@server1 ~]# mount /dev/drbd0 /mnt/drbd
[root@server1 ~]# df /mnt/drbd
ファイルシス   1K-ブロック  使用   使用可 使用% マウント位置
/dev/drbd0         5029276 20472  4730288    1% /mnt/drbd

テストファイルを作成し、プライマリを移動して複製されていることを確認します。

[root@server1 ~]# echo test > /mnt/drbd/test.txt
[root@server1 ~]# umount /dev/drbd0
[root@server1 ~]# drbdadm secondary drbd0

[root@server2 ~]# drbdadm primary drbd0
[root@server2 ~]# mount /dev/drbd0 /mnt/drbd
[root@server2 ~]# ls /mnt/drbd
lost+found test.txt
[root@server2 ~]# cat /mnt/drbd/test.txt
test
[root@server2 ~]# umount /dev/drbd0
[root@server2 ~]# drbdadm secondary drbd0

8. DRBDの自動起動設定

OS起動時にDRBDが起動するように設定します。

[root@server1 ~]# systemctl enable drbd
Created symlink from /etc/systemd/system/multi-user.target.wants/drbd.service to /usr/lib/systemd/system/drbd.service.
[root@server2 ~]# systemctl enable drbd
Created symlink from /etc/systemd/system/multi-user.target.wants/drbd.service to /usr/lib/systemd/system/drbd.service.

両ノードのOSを再起動し、DRBDが両方Secondary状態で起動することを確認します。

9. 自動プロモーション

自動プロモーションが有効になっているので、mount操作を実行すると自動的にPrimaryに昇格され、
umountで自動的にSecondaryに降格されます。

[root@server1 ~]# drbdadm status drbd0
drbd0 role:Secondary
  disk:UpToDate
  server2 role:Secondary
    peer-disk:UpToDate
[root@server1 ~]# mount /dev/drbd0 /mnt/drbd
[root@server1 ~]# drbdadm status drbd0
drbd0 role:Primary
  disk:UpToDate
  server2 role:Secondary
    peer-disk:UpToDate

なお、既にPrimaryになっているノードがある状態でmount実行しようとすると以下のように失敗します。

drbd drbd0: Auto-promote failed: Multiple primaries not allowed by config

また、注意点として、一度 drbdadmコマンドで手動でPrimary/Secondaryを切り替えると、自動プロモーションは無効になります。再度有効にするにはDRBDを再起動する必要があります。

10. Pacemaker/Corosyncの設定

Pacemaker/CorosyncでDRBDデバイス上のファイルシステムを管理する設定を行います。

DRBDリソースの昇格・降格はDRBDの自動プロモーションにより制御されるため、従来のようにPacemakerでMaster/Slaveリソースを作成する必要がなくなり、設定を大幅に簡略化できます。また、DRBDの管理をDRBD自体に任せることにより、DRBDのスプリットブレインが発生しにくくなるメリットもあります。

ここではFilesystemリソースとIPaddr2(仮想IP)リソースをグループ化して管理します。なお、Pacemaker/Corosyncのインストール自体は完了しているものとします。

# pcs resource create VIP ocf:heartbeat:IPaddr2 
    ip=192.168.1.101 cidr_netmask=24 op monitor interval=10s
# pcs resource create FS ocf:heartbeat:Filesystem 
    device=/dev/drbd0 directory=/mnt/drbd fstype=ext4 
    op start timeout=60s on-fail=restart 
    op stop timeout=60s on-fail=block 
    op monitor interval=10s timeout=60s on-fail=restart
# pcs resource group add Group-FS FS VIP

ファイルシステムリソースが仮想IPリソースと同じノードで起動し、DRBDリソースがPrimaryとなり実際にマウントされていることを確認します。

# pcs status
  ...
  Resource Group: Group-FS
      FS (ocf::heartbeat:Filesystem):    Started server1
      VIP        (ocf::heartbeat:IPaddr2):       Started server1

[root@server1 ~]# drbdadm status
drbd0 role:Primary
  disk:UpToDate
  server2 role:Secondary
    peer-disk:UpToDate

[root@server1 ~]# df /mnt/drbd
ファイルシス   1K-ブロック  使用  使用可 使用% マウント位置
/dev/drbd0         5029276 37916 4712844    1% /mnt/drbd

server1をスタンバイモードにしてserver2にスイッチオーバーすることを確認します。

[root@server1 ~]# pcs cluster standby server1
[root@server1 ~]# pcs status
...
Node server1: standby
Online: [ server2 ]

Full list of resources:

 Resource Group: Group-FS
     FS (ocf::heartbeat:Filesystem):    Started server2
     VIP        (ocf::heartbeat:IPaddr2):       Started server2

[root@server2 ~]# drbdadm status
drbd0 role:Primary
  disk:UpToDate
  server1 role:Secondary
    peer-disk:UpToDate

[root@server2 ~]# df /mnt/drbd
ファイルシス   1K-ブロック  使用  使用可 使用% マウント位置
/dev/drbd0         5029276 37916 4712844    1% /mnt/drbd

• 脆弱性の修正
• 重要な不具合の修正
• サポート期間の終了

単体で動作しているソフトウェアの場合は、「サービス停止→パッケージ更新→サービス起動」のように比較的簡単な方法でアップデートが可能ですが、クラスタを組んでいる場合は、事前にいくつかの方法を検討した上で計画的に実施する必要があります。

クラスタ全体を停止してまとめてアップデートする方法

この方法は最も確実ですが、クラスタを停止している間はサービスが利用できません。
ある程度のサービス停止が許容できる場合はこの方法を選択してもよいでしょう。
また、メジャーバージョンアップ等でデータや設定の互換性がなくなる場合もこの方法をとることになります。

ローリングアップデートについて

ローリングアップデートとは、サービスを継続しながら各サーバを順次アップデートしていく方法です。

まずスタンバイサーバに対してアップデートを実施し、スタンバイサーバをプライマリサーバに切り替え、旧プライマリサーバ(現スタンバイサーバ)に対してアップデートを実施します。

この方法の場合、アップデート前後でソフトウェアの互換性が保たれていることが前提となります。
メジャーバージョンアップ等でデータや設定に互換性がなくなる場合は、この方法をとることが困難となります。

以下、具体的にローリングアップデートを行う手順をみていきます。

なお、前提とする環境はRHEL7.xおよびLinux-HA Japan提供のPacemaker/Corosyncとなります。

リソースとして管理されているサービスのアップデート

Pacemaker配下のリソースとして管理されているサービス(例: Apache, PostgreSQL)をアップデートする場合は、メンテナンスモードを使用することが一般的です。メンテナンスモードを有効にすると、リソースはunmanaged状態となり、リソースの起動・停止・監視が行われなくなります。
メンテナンスモード状態で各サービスのアップデートを行い、作業が完了したらメンテナンスモードを解除します。

クラスタ全体をメンテナンスモードにする場合

1. クラスタ全体をメンテナンスモードにします。

(crm)# crm configure property maintenance-mode=true
(pcs)# pcs property set maintenance-mode=true

crm_mon -rfA1もしくはpcs statusで状態を確認すると、両ノードのリソースは以下のように (unmanaged) と表示されます。

Clone Set: ping-clone [ping] (unmanaged)
 ping (ocf::pacemaker:ping): Started server2 (unmanaged)
 ping (ocf::pacemaker:ping): Started server1 (unmanaged)

2. 両ノードで各ソフトウェアのメンテナンスやアップデートなどの作業を行います。このときプライマリ側でサービスを停止してもフェイルオーバーは発生しません。

3. メンテナンスモードを解除します。

(crm)# crm configure property maintenance-mode=false
(pcs)# pcs property set maintenance-mode=false

注: メンテナンスモードを解除するとき、各リソースの状態はメンテナンスモードに入る前と同一の状態になっている必要があります。状態が異なる場合は予期せぬフェイルオーバーなどが発生する場合があります。

ノード単位でメンテナンスモードにする場合

1. スタンバイノード(メンテナンス対象ノード)で以下を実行します。デフォルトはコマンドを実行したノードが対象となるため、ノード名は省略できます。

(crm)# crm node maintenance <スタンバイノード名>
(pcs)# pcs node maintenance <スタンバイノード名>

crm_mon -rfA1もしくはpcs statusで状態を確認すると、メンテナンスモード中のノードのリソースは以下のように (unmanaged) と表示されます。

Clone Set: ping-clone [ping]
 ping (ocf::pacemaker:ping): Started server2 (unmanaged)
 Started: [ server1 ]

Node Attributes:
 * Node server1:
 + pingd : 100
 * Node server2:
 + maintenance : on
 + pingd : 100

2. メンテナンス対象ノードで各ソフトウェアのメンテナンスやアップデートなどの作業を行います。

3. メンテナンスモードを解除します。

(crm)# crm node ready <スタンバイノード名>
(pcs)# pcs node unmaintenance <スタンバイノード名>

4. リソースをプライマリノードからスタンバイノードへフェイルオーバーします。
以下はプライマリノードを一度standbyモードにしてリソースをフェイルオーバーさせています。

(crm)# crm node standby <プライマリノード名>
(crm)# crm node online <プライマリノード名>
(pcs)# pcs cluster standby <プライマリノード名>
(pcs)# pcs cluster unstandby <プライマリノード名>

5. 現スタンバイ(旧プライマリ)ノードで同様に1.～3.のメンテナンス作業を実施します。

6. 必要に応じてリソースのフェイルバックを行います。

スタンバイモードを利用する場合

メンテナンスモードの代わりにスタンバイモードを使用し、ノードのリソースを停止させた状態でアップデートを実施してもよいです。サービスの起動を Pacemaker に任せるため、こちらのほうが比較的確実かもしれません。

1. スタンバイノード(メンテナンス対象ノード)で以下を実行し、スタンバイモードに移行します。

(crm)# crm node standby <スタンバイノード名>
(pcs)# pcs cluster standby <スタンバイノード名>

2. メンテナンス対象ノードで各ソフトウェアのメンテナンスやアップデートなどの作業を行います。

3. スタンバイモードを解除します。

(crm)# crm node online <スタンバイノード名>
(pcs)# pcs cluster unstandby <スタンバイノード名>

4. プライマリノードで1.を実行し、スタンバイモードに移行します。このときリソースはスタンバイノードへフェイルオーバーします。

5. 現スタンバイ(旧プライマリ)ノードで同様に2.～3.のメンテナンス作業を実施します。

6. 必要に応じてリソースのフェイルバックを行います。

Pacemaker/Corosyncのアップデート

Pacemaker/Corosyncのアップデートを行う場合は、各ノードでPacemaker/Corosyncを一時的に停止する必要があります。

1. スタンバイサーバの Pacemaker を停止します。

# systemctl stop pacemaker

2. スタンバイサーバの Pacemaker/Corosync のアップデートを実施します。

# yum update ...

3. スタンバイサーバの Pacemaker を起動します。

# systemctl start pacemaker

4. クラスタの状態が正常であることを確認したら、リソースをプライマリノードからスタンバイノードへフェイルオーバーします。
以下はプライマリノードを一度standbyモードにしてリソースをフェイルオーバーさせています。

(crm)# crm node standby <プライマリノード名>
(crm)# crm node online <プライマリノード名>
(pcs)# pcs cluster standby <プライマリノード名>
(pcs)# pcs cluster unstandby <プライマリノード名>

5. 現スタンバイ(旧プライマリ)ノードで同様に1.～3.のメンテナンス作業を実施します。

6. 必要に応じてリソースのフェイルバックを行います。

Pacemakerの設定のデフォルト値について

Pacemakerの設定には主に以下の種類があります。

• クラスタのプロパティ
• リソースのパラメータ
• 制約のパラメータ

各種設定のデフォルト値は以下のドキュメントに記載されています。

• High Availability Add-On リファレンス
• ClusterLabs Pacemaker 1.1 Configuration Explained

以下、主に検討が必要な設定項目について説明します。

クラスタのプロパティ

• no-quorum-policy: クラスタがquorumを持っていないときの動作を定義します。デフォルトはstop(全リソース停止)です。
  2台構成の場合は、片方が停止しても動作を続行できるよう、ignore(全リソースはそのまま動作を続行)を指定します。
• stonith-enabled: フェンシング(STONITH)を有効にするかどうかを指定します。デフォルトはtrue(有効)です。
  これが有効、かつSTONITHリソースが未設定の場合リソースが起動できません。
• cluster-recheck-interval: クラスタのチェック間隔を指定します。デフォルトは15分です。
  failure-timeout(failcountを自動クリアするまでの時間)など、時間ベースの動作が反映されるまでの時間に影響します。

クラスタの設定のデフォルト値についてはRed Hat社の以下のページも参照ください。

• High Availability Add-On リファレンス – 12.1. クラスタープロパティとオプションの要約

リソースのパラメータ

リソースのパラメータには共通のものと、特定のリソース固有のものがあります。
共通のものについてはクラスタにおけるデフォルト値を設定することができます。

• migration-threshold: リソースをフェイルオーバーするまでの障害の発生回数(failcount)を指定します。デフォルトはINFINITY(無効)です。
  failcountがこの値に達するまでPacemakerはリソースの再起動により復旧を試みます。
• failure-timeout: 障害検知によりfailcountがカウントされた後、一定時間障害が発生しなかった場合にfailcount自動でクリアします。デフォルトは0(無効)です。
  この値を短くしても、実際に条件を満たしたかどうかがチェックされるのはcluster-recheck-interval(デフォルト:15分)の間隔となるため、failcountの自動クリアを早くしたい場合は両方の値を調整する必要があります。

リソース固有のパラメータについては、以下のコマンドで確認することができます。

(crm) crm ra info <リソース名>
(pcs) pcs resource describe <リソース名>

(ocf:pacemaker:pingリソースの場合の例)

# crm ra info ping
node connectivity (ocf:pacemaker:ping)

Every time the monitor action is run, this resource agent records (in the CIB) the current number of nodes the host can
 connect to using the system fping (preferred) or ping tool.

Parameters (*: required, []: default):

pidfile (string, [/var/run/ping-ping]):
    PID file

dampen (integer, [5s]): Dampening interval
    The time to wait (dampening) further changes occur
...
Operations' defaults (advisory minimum):

    start timeout=60
    stop timeout=20
    monitor timeout=60 interval=10

# pcs resource describe ping
Assumed agent name 'ocf:pacemaker:ping' (deduced from 'ping')
ocf:pacemaker:ping - node connectivity

Every time the monitor action is run, this resource agent records (in the CIB) the current number of nodes the host can
 connect to using the system fping (preferred) or ping tool.

Resource options:
  pidfile: PID file
  dampen: The time to wait (dampening) further changes occur
  name: The name of the attributes to set. This is the name to be used in the constraints.
  multiplier: The number by which to multiply the number of connected ping nodes by
  host_list (required): A space separated list of ping nodes to count.
...

Default operations:
  start: interval=0s timeout=60
  stop: interval=0s timeout=20
  monitor: interval=10 timeout=60

リソースの設定のデフォルト値についてはRed Hat社の以下のページも参照ください。

High Availability Add-On リファレンス – 6.4. リソースのメタオプション

Corosyncの設定のデフォルト値について

Corosyncの設定のデフォルト値はman corosync.confで表示されるマニュアルページにに記載されています。

totem {}

クラスタ間の通信方法などを定義します。

• transport: クラスタ間の通信プロトコル。デフォルトはudp(UDPマルチキャスト通信)です。udpuにするとUDPユニキャスト通信となります。
• token: Corosync間の通信のタイムアウト値を指定します。デフォルトは1000ミリ秒(1秒)です。
  デフォルト値は多くの場合短すぎるため、要件に応じて10000ミリ秒(10秒)程度に長くすることを検討してください。

totem {
    version: 2
    crypto_cipher: none
    crypto_hash: none
    cluster_name: cluster1
    transport: udpu
    token: 10000
}

quorum {}

• two_node: 2ノードクラスタの場合1を指定する必要があります。デフォルトは無効です。

quorum {
    provider: corosync_votequorum
    two_node: 1
}

設定値の単位について

Pacemakerの場合、監視間隔やタイムアウトなどの時間の指定は「10s」「1m」「10000ms」などの単位が指定できます。単位を指定しない場合は秒数として扱われます。以下の単位が使用できます。

(複数の単位を使用した例)

crm configure primitive ping ocf:pacemaker:ping 
  params host_list="x.x.x.x" 
  op start interval="0s" timeout="1m" on-fail="restart" 
  op monitor interval="10000ms" timeout="60s" on-fail="restart" 
  op stop interval="0" timeout="60" on-fail="fence"

pcs resource create ping ocf:pacemaker:ping 
  host_list="x.x.x.x" 
  op start interval="0s" timeout="1m" on-fail="restart" 
  op monitor interval="10000ms" timeout="60s" on-fail="restart" 
  op stop interval="0" timeout="60" on-fail="fence"

Corosyncの場合、tokenなどの時間はミリ秒単位で指定します。単位は指定できません。

今回の記事では、RHEL7でPacemaker/Corosyncを使ってHAクラスタを構築する際に利用できる2種類のパッケージについて解説します。Web上ではLinux-HA Japanに関する情報は比較的多く見つかりますが、RHEL HA Add-Onについてはあまり情報がないように思われますので、本記事が参考になれば幸いです。

RHEL HA Add-On

RHEL High Availability Add-On (以下HA Add-On)は、 Red Hat社によって提供されるRed Hat Enterprise Linux (以下RHEL)向けのHAクラスタパッケージ集です。Pacemaker、Corosyncおよび各種ツールにより構成されています。

High Availability Add-On の概要

Linux-HA Japan

Linux-HA Japanは、Linux上でHAクラスタを構築するための各種ソフトウェアの提供やメンテナンスを行っている、国内のコミュニティベースのプロジェクトです。

Linux-HA Japan プロジェクト

それぞれの特長

RHEL HA Add-On は、RHEL 6/7本体に対するオプションの形で販売されており、購入することでパッケージおよびサポートを利用することができます。
RHEL 6.5以降およびRHEL 7では、Pacemaker, Corosyncおよび各種関連パッケージ群で構成されています。RHEL 6.4以前まではPacemakerの代わりにRGManagerというツールが使用されていました。それぞれの違いはRed Hat社の以下のページを参照ください。

Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 でのクラスターの作成

なお、CentOSなどのRHEL互換ディストリビューションにはHA Add-On相当のパッケージも含まれています。

Linux-HA JapanではRHEL/CentOS 6/7用のrpmパッケージが配布されており、無償でダウンロード、利用することができます。
こちらもPacemaker, Corosyncおよび各種関連パッケージ群で構成されています。

なお、HA Add-On、Linux-HA Japanのパッケージを混在させて使うことはできません。

機能の差異

どちらもPacemaker+Corosyncという構成は同じですが、それぞれ細かな差異があります。

RHEL HA Add-On

• 管理コマンドはpcsのみ
• クォーラムデバイス機能(corosync-qdevice)が含まれる
  • テクノロジープレビューという位置付け
• フェンシング(STONITH)機能はfence-agentsのみ

Linux-HA Japan

• 管理コマンドはpcsとcrmshの両方を同梱
  • Linux-HA Japanではcrmshの利用を推奨
  • pcsはテクノロジープレビューという位置付け
• フェンシング(STONITH)機能としてfence-agentsとcluster-glueの両方を同梱
  • Linux-HA Japanではcluster-glueの利用を推奨
• 同梱のリソースエージェント(リソース管理モジュール)の種類が多い
  • HA Add-Onにのみ含まれるものもある
• リソースエージェントとしてディスク監視を行うLinux-HA Japan独自開発のpm_diskdなどを同梱

2018年5月現在、RHEL7版Pacemaker/Corosyncの各パッケージのバージョンは以下の差異があります。

選択のポイント

RHEL HA Add-OnはRHELの有償オプションですが、Red Hat社の正式なサポートが受けられるというメリットがあります。国内ではWeb上の情報はあまり多くありません。

Linux-HA Japanについては無償で利用でき、Linux-HA Japan独自開発のツールおよびcrmshが利用できます。コミュニティベースのため、正式なサポートはありません。国内では多くの利用実績があり、Web上でも情報が比較的多く得られます。

なお、弊社のOSSサポート・OSSプロフェッショナルサポートサービスでは、いずれのパッケージにおいてもサポートサービスを提供しております。

SRA OSS, Inc. 日本支社 – サポートメニュー

参考情報

High Availability Add-On の概要
High Availability Add-On リファレンス
Linux-HA Japan – Pacemakerの概要
Linux-HA Japan – マニュアル