Pacemaker+DRBD HAシステムのバージョンアップガイド

高可用性（HA）クラスタシステムの運用において、OSやミドルウェアのパッケージ更新は避けて通れないメンテナンス作業です。

しかし、Pacemaker と DRBD を組み合わせた構成では、不適切な順序で作業を行うと意図しないフェイルオーバー、不要なフェンシング（STONITHによる強制再起動）、あるいはデータ不整合（Split-brain）を引き起こすリスクがあります。

本記事では、サービス停止時間を最小化しつつ、データの安全性を最優先に確保するローリングアップデートの手順、事前準備として取得しておくべきバックアップ情報、および作業失敗時の切り戻し（リカバリ）方法を実機検証の知見に基づいて詳しく解説します。

1. はじめに（基本方針と前提環境）
- 本記事の前提環境
2. 事前準備：バックアップと状態情報の取得
- 構成ファイルの保存に関する前提知識
- バックアップ項目と取得コマンド
3. バージョンアップ実行手順（ローリングアップデート）
4. 万が一失敗した場合の切り戻し（リカバリ）手順
- ケース1：1台目（スタンバイ側）の更新・再起動失敗時
- ケース2：切替後に不具合やDRBD不整合（Split-brain）が発生した場合
【コラム】pcsd 認証ファイルとノード個別バックアップの注意点
- CIB構成ファイルと pcsd 領域の同期仕様の違い
- 推奨されるバックアップとトラブル対処法
5. まとめ

1. はじめに（基本方針と前提環境）

HAクラスタのバージョンアップでは、1台ずつ順番に更新を行うローリングアップデート（Rolling Upgrade）が基本です。

[全体の作業フロー]
1. 事前準備：CIBバックアップ、CIB XML、RPMリストの退避
2. スタンバイノード(node2)の切り離し・OS/パッケージ更新・再起動
3. 【最重要】node2 でDRBDのみ単体起動＆同期確認 (UpToDate)
4. node2 のPacemaker起動・スタンバイ解除
5. サービスを node2 へ安全にフェイルオーバー
6. 旧アクティブノード(node1)の切り離し・更新・再起動
7. node1 のDRBD単体起動・同期確認・Pacemaker復帰
8. 全体状態確認と必要に応じた位置戻し（スイッチオーバー）

本記事の前提環境

OS: Red Hat Enterprise Linux (RHEL) / AlmaLinux 8 または 9 系列
HA構成: Pacemaker + Corosync + DRBD 9.x
スコープ: 同一メジャーバージョン内でのパッケージ更新（例: AlmaLinux 9.6 → 9.8 への dnf update） (※DRBD 8から9へのメジャーバージョンアップは構造変更を伴うため対象外とします)
ノード名: 本説明では2ノード構成のHAクラスターを想定し、node1、node2がノード名になります。初期状態はnode1がアクティブノード、node2がスタンバイノードです。

2. 事前準備：バックアップと状態情報の取得

バージョンアップ前にバックアップを取得する際、「静的な設定ファイル」と「動的なクラスター情報（CIB）」の性質の違いを理解しておくことが重要です。

構成ファイルの保存に関する前提知識

/etc/drbd.d/* や /etc/corosync/corosync.conf などの静的テキスト設定ファイルは、通常 dnf update によって勝手に上書き・削除されることはありません。これらは「両ノードが全損し、システムをゼロから再構築する場合の保険」として管理します。

作業前には、復元に必要な「動的なクラスターデータ」を必ず退避してください。

バックアップ項目と取得コマンド

アクティブノード（稼働側）にて、以下のコマンドを実行します。

# 1. バックアップ用ディレクトリの作成
mkdir -p /root/backup_$(date +%Y%m%d)
cd /root/backup_$(date +%Y%m%d)

# 2. Pacemaker クラスター構成の一括アーカイブ取得
# ※接尾辞（拡張子）を付けずに指定すると適切な圧縮アーカイブが生成されます
pcs config backup cluster_backup

# 3. Pacemaker CIB構成のXML保存（テキスト可読性・差分確認用）
pcs cluster cib cib_backup.xml

# 4. 適用済みRPMパッケージ一覧の保存（切り戻し時のバージョン特定用）
rpm -qa | grep -E 'pacemaker|corosync|drbd|resource-agents' > rpm_list.txt

DRBDとCorosyncのファイルはバージョンアップで更新はされないので、バージョンアップ前のバックアップは不要です。

3. バージョンアップ実行手順（ローリングアップデート）

作業は「スタンバイノード（待機側）」から開始し、正常性を確認した後に「アクティブノード（稼働側）」へ引き継ぎます。

Step 1: 1台目（スタンバイノード：node2）の更新

1. クラスターのスタンバイ化と停止

意図しないフェイルオーバーやフェンシング（STONITH）の発動を防止するため、node2 をスタンバイ状態にしてクラスターサービスを停止します。

# node2 をスタンバイモードに設定
pcs node standby node2

pcs status を実行し、node2 が OFFLINE（または standby）となり、サービスリソースが node1 上で無停止で稼働し続けていることを確認します。

2. パッケージの更新とOS再起動

node2 にてパッケージの更新を行います。

# パッケージのアップデート実行
dnf update -y 

# OSの再起動
reboot

★最重要ポイント：OS再起動後の安全な起動手順

OS再起動直後に いきなり Pacemaker を起動（pcs cluster start）させてはいけません。データ同期が完了していない状態でクラスターがリソース昇格を判断すると、サービス起動失敗やデータ不整合を招く恐れがあります。

3. DRBD単体での起動とデータ同期確認

OS再起動後（pacemaker や drbd の自動起動が disabled であることを前提）、まずは DRBDサービスのみ を起動し、アクティブノード（node1）とのデータ同期が正常に完了したことを確認します。

# node2 でDRBDのみを単体起動
drbdadm up all

# DRBDステータスの確認
drbdadm status

【確認ポイント】 drbdadm status の結果において、自ノードおよび対向ノードのディスク状態が共に UpToDate（完全同期状態）になっていることを確認してください。

r0 role:Secondary
  disk:UpToDate
  node1 role:Primary
    peer-disk:UpToDate

4. DRBD正常確認後に Pacemaker を起動・復帰

DRBDの同期（UpToDate）が確認できたら、Pacemakerを起動してスタンバイ状態を解除します。

# クラスターの起動
systemctl start pacemaker

# スタンバイ状態の解除
pcs node unstandby node2

# クラスター状態の確認
pcs status

Step 2: サービスフェイルオーバーと2台目（旧アクティブノード：node1）の更新

node2 が Online に復帰したら、サービスを node2 へ移行させ、node1 の更新を行います。

1. サービスのフェイルオーバー

定足数（クォーラム）を維持するため、node2 が Online であることを確認した上で node1 をスタンバイ化します。

# node1 で実行
pcs node standby node1

pcs status を実行し、サービスリソース（IP、マウント、DB等）および DRBD（Promoted/Primary）が node2 上へ安全に引き継がれ昇格したこと を確認します。

2. node1 の更新と再起動（Step 1と同様のシーケンス）

# パッケージ更新
dnf update -y

# 再起動
reboot

3. node1 のDRBD確認とクラスター復帰

node1 再起動後も、必ずDRBD単体で起動し同期を完了させてから Pacemakerを起動します。

# DRBD起動と確認
drbdadm up all
drbdadm status   # -> 両ノード UpToDate を確認！

# Pacemaker起動とスタンバイ解除
systemctl start pacemaker
pcs node unstandby node1

Step 3: 最終確認とスイッチオーバー

両ノードの更新が完了したら、システム全体の正常性を確認します。

# クラスター全体のステータス確認
pcs status

# DRBDの同期ステータス確認
drbdadm status

サービスの位置を元のノード（node1）に戻したい（スイッチオーバーする）場合は、一時的に node2 をスタンバイ化して切り戻します。

pcs node standby node2
# サービスが node1 に戻ったことを確認後
pcs node unstandby node2

4. 万が一失敗した場合の切り戻し（リカバリ）手順

更新作業中に障害が発生した場合のシナリオ別切り戻し手順です。

ケース1：1台目（スタンバイ側）の更新・再起動失敗時

状況: node2 の更新後にOSやDRBDが正常起動しない。
影響: node1 側でサービスは無停止で継続稼働中（ダウンタイムなし）。
切り戻し手順:
1. 事前に記録した rpm_list.txt を参考に、node2 側でパッケージをダウングレードします。
  dnf downgrade -y drbd-utils ...
2. クラスター構成に不整合がある場合は、事前取得したバックアップから復元します。
  pcs config restore cluster_backup.tar.gz --local
3. DRBD単体起動で同期を確認した後、Pacemakerへ再参加させます。

ケース2：切替後に不具合やDRBD不整合（Split-brain）が発生した場合

状況: 通信切断や不整合によりDRBDが StandAlone に移行し同期不能となった場合。
切り戻し手順:
1. パッケージダウングレード: 両ノードのパッケージを元バージョンへ揃えます。
2. CIBの復元: 必要に応じてXMLからCIBを書き戻します。
  pcs cluster cib-push cib_backup.xml --config
3. 手動スプリットブレイン解決: データを最新として採用するノード（生存ノード）と切り捨てるノード（犠牲ノード）を定めて接続を復旧させます。
  - 犠牲ノード側（データを破棄するノード）:
    drbdadm secondary <リソース名>
    drbdadm disconnect <リソース名>
    drbdadm connect --discard-my-data <リソース名>
  - 生存ノード側（最新データを持つノード）:
    drbdadm disconnect <リソース名>
    drbdadm connect <リソース名>

【コラム】pcsd 認証ファイルとノード個別バックアップの注意点

Web UIやノード間通信を管理する pcsd デーモンは、認証トークンや証明書を /var/lib/pcsd/ 配下に保存しています。

CIB構成ファイルと pcsd 領域の同期仕様の違い

Pacemaker / Corosync 設定（cib.xml, corosync.conf）: 「クラスター共通定義」のため、アクティブノードで変更された内容がスタンバイノードへ自動的にレプリケーション・完全同期されます。
pcsd 管理ファイル（/var/lib/pcsd/）: トークン等は同期されますが、SSL/TLS証明書（pcsd.crt / pcsd.key）は各ノードのホスト名等に基づき生成される「ノード固有情報」です。

注意！ ノードAの /var/lib/pcsd/ をそのままノードBへ丸ごとコピー（上書き）すると、証明書やトークンの不一致により pcs コマンドによるノード間通信が壊れる原因になります。

推奨されるバックアップとトラブル対処法

バックアップ時: /var/lib/pcsd/ は他ノードへの上書きを行わず、各ノード個別にバックアップを保持してください。
認証エラー時の対応: 万が一バージョンアップ後にノード間通信エラーが発生した場合は、ファイルを復元するよりも以下のコマンドで認証を再設定する方が安全かつ確実です。
# ノード間認証の再実行コマンド
pcs host auth node1 node2 -u hacluster -p <パスワード>

5. まとめ

Pacemaker + DRBD 環境における安全なバージョンアップの鍵は以下の2点になります。

順番にアップデートする ：
スタンバイノードを先にバージョンアップして、成功したらアクティブノードの作業を行う。
DRBDの先行起動と同期確認:
OS再起動直後にPacemakerを起動せず、「まずDRBDを単体起動し UpToDate を確認してからPacemakerを起動する」 というデータファーストの原則を守る。

本記事の手順を活用し、本番環境での安全なメンテナンス作業にお役立てください。