はじめに
前回の第1回記事では、Pacemakerを管理するための2大ツール「crmsh」と「pcs」の歴史と特徴について解説しました。今回からは、モダンなRHEL系環境（RHEL 8/9やAlmaLinuxなど）の標準ツールである pcs コマンドにフォーカスし、実際に高可用性（HA）クラスタを構築していく手順を解説します。
HAクラスタの構築と聞くと難しく感じるかもしれませんが、役割を人間社会に例えると分かりやすくなります。
- Corosync（通信レイヤー）: ノード同士が「生きてるか？」と連絡を取り合うトランシーバーの役割を果たします。
- Pacemaker（リソースマネージャー）: トランシーバーからの情報をもとに、「お前が倒れたなら、俺がサービスを引き継ぐ！」と指示を出す現場監督です。
- pcs（管理ツール）: 現場監督やトランシーバーの設定を一括で行う司令塔（コントロールパネル）です。
今回は、この司令塔である pcs を使って、2つのノード（サーバー）を連携させる土台作りを行っていきましょう。
1. 必要なパッケージのインストール
まずは、クラスタを構成する両方のノード（例として node1.example.com, node2.example.com とします）に必要なソフトウェアをインストールします。
Red Hat High Availability Add-On（または互換リポジトリ）から、Pacemaker、pcs、および障害発生時にノードを切り離すためのフェンスエージェントをインストールします。
# dnf install pcs pacemaker fence-agents-all
💡 現場の知見：
共有ストレージの代わりにDRBDを用いてデータを同期する場合は、ここで併せてDRBDのパッケージ群（
kmod-drbd,drbd-pacemakerなど）もインストールしておきます。
2. pcsdサービスの起動とノード認証
pcs コマンドは、各ノードで稼働する pcsd デーモンと通信することで、1台のサーバーからクラスタ全体の設定を透過的に管理します。
そのため、まずは pcs の管理用アカウントである hacluster ユーザーのパスワードを両ノードで設定します。
# passwd hacluster
次に、システムの起動時に pcsd デーモンが立ち上がるように起動と有効化を行います。これも両ノードで実行します。
# systemctl start pcsd.service
# systemctl enable pcsd.service
準備が整ったら、どちらか1つのノード（例えばnode1）から、クラスタを構成するノード間の認証を行います。先ほど設定した hacluster のパスワードを入力します。
# pcs host auth node1.example.com node2.example.com
Authorized と表示されれば、ノード間の信頼関係が結ばれたことになります。
3. クラスターのセットアップと起動
認証が完了したら、いよいよ現場監督（Pacemaker）とトランシーバー（Corosync）の設定を一気に流し込みます。pcs を使えば、たった1行のコマンドでクラスターのセットアップとサービスの起動が可能です。
ここではクラスター名を my_cluster としてセットアップします。
# pcs cluster setup my_cluster --start node1.example.com node2.example.com
--start オプションを付与することで、設定の伝播と同時にクラスタサービスが自動的に起動します。
クラスタがOS起動時に自動で立ち上がるようにするには、以下のコマンドを実行します。
# pcs cluster enable --all
構築が完了したら、ステータスを確認してみましょう。
# pcs cluster status
両ノードが Online と表示されていれば、ベースとなるHAクラスタの構築は成功です！
4. 安全な運用のための初期設定（フェンシングとSplit-brain対策）
クラスタの土台は完成しましたが、実運用に向けて重要な設定があります。それはフェンシング（STONITH）の設定です。
ノード間のネットワークが途絶えた際、お互いが「相手が死んだ」と勘違いして両方がサービスを起動してしまう現象をSplit-brain（スプリットブレイン）と呼びます。DRBD等のデータ同期を行っている環境でこれが発生すると、データが分岐してしまい致命的な損壊を招きます。
これを防ぐため、Pacemakerは相手のノードの電源を強制的に落とすフェンシング（STONITH）機能を持っています。STONITHは Pacemaker フェンシングの実装であり、強制的にノードをシャットダウンし、クラスターからノードを削除してデータの整合性を確保します。
Pacemakerはデフォルトでフェンシングが有効化されており、フェンスデバイス（電源スイッチを制御する機器など）を設定しないとリソース（サービス）が起動しない安全設計になっています。
⚠️ 注意：テスト環境でのフェンシング無効化
動作検証などでフェンスデバイスを用意できない場合、一時的にフェンシングを無効化することができます。
# pcs property set stonith-enabled=falseただし、この設定は障害が発生したノードが適切にフェンスされていることを装うようにクラスターに指示するため、本番運用・実稼働クラスタには全く適していません。本番環境では必ずフェンスデバイスを設定してください。
5. 初めてのリソースを定義してみよう（仮想IPの作成）
いよいよ、Pacemakerに管理させる「リソース（サービス）」を定義します。ここでは、HAクラスタで最もよく使われる「仮想IPアドレス（Virtual IP）」を作成してみましょう。
pcs resource create コマンドを使用して、IPアドレス（ocf:heartbeat:IPaddr2）リソースを定義します。
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.100.10 cidr_netmask=24 op monitor interval=20s
(※ ip= の値と cidr_netmask= は、ご自身の環境に合わせて変更してください)
コマンドの構成は以下のようになっています。
VirtualIP: 任意のわかりやすいリソース名ocf:heartbeat:IPaddr2: 使用するリソースエージェント（スクリプト）の種類ip=... cidr_netmask=...: リソースに渡す固有のパラメータop monitor interval=20s: 20秒間隔でリソースが正常に稼働しているか死活監視（モニター）する設定
作成後、ステータスを確認してみましょう。
# pcs status
Cluster name: my_cluster
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: node2.example.com (version 2.1.10-3.el9_8-5693eaeee) - partition with quorum
* Last updated: Thu Oct 8 08:45:25 2026 on node1.example.com
* Last change: Thu Oct 8 08:45:22 2026 by root via root on node1.example.com
* 2 nodes configured
* 1 resource instance configured
Node List:
* Online: [ node1.example.com node2.example.com ]
Full List of Resources:
* VirtualIP (ocf:heartbeat:IPaddr2): Started node1.example.com
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
出力内の Full List of Resources: に VirtualIP (ocf:heartbeat:IPaddr2): Started node1.example.com と表示されています。 クラスタが指定したIPアドレスを起動し、監視を開始しました。
まとめと次回予告
今回は、pcs コマンドを使ったPacemakerクラスタのインストールから、ノード間の認証、クラスタの初期セットアップまでの手順を解説しました。pcs を使うことで、複雑なXML（CIB）を直接触ることなく、安全かつシンプルにクラスタを構築できることがお分かりいただけたかと思います。
土台となるクラスタが完成しましたので、次回（第3回）は、実運用に入ってから直面する「リソースの移動」や「障害発生時の復旧手順」など、現場のエンジニアがいざという時にコピペして使える「便利なpcsコマンドリファレンス」をご紹介します。お楽しみに！
