LinuxのPacemaker/Corosyncクラスター障害：HA構成の復旧

【注意】 本記事はPacemaker/Corosyncを用いたLinux HAクラスタ運用の一般的な解説です。実環境の構成（STONITH機器、ネットワーク冗長、共有ストレージ方式、業務要件、SLA等）により最適手順は変わり、誤操作はサービス停止やデータ不整合を招きます。判断に迷う場合や停止影響が大きい場合は、株式会社情報工学研究所のような専門事業者へ相談し、状況に合わせた切り分けと復旧計画を立ててください。

　

第1章：『また夜中か…』— crm_mon が赤いとき、必要なのは“原因当て”より先に“状況把握”

夜間にアラートが鳴って、端末を開いた瞬間に crm_mon が赤い。現場の頭の中はだいたいこうです。

「え、切り替わってない？ いや、片系に寄ってる？ そもそも“今”サービスは生きてるの？」

この瞬間にやりがちなのが、ログを掘る前に設定を触ったり、リソースを手で動かしたりすることです。気持ちは分かります。早く沈静化したい。でもHAクラスタの障害は、“現象が連鎖する”のが厄介です。焦って触ると、状況が変わって「何が原因で、何をして、どう悪化したか」が見えなくなります。

ここで最初にやるべきは、原因当てではなくダメージコントロール（被害最小化）です。具体的には「いまの実害」と「クラスタが判断している状態」を分離して把握します。

---

最初の5分で揃える“事実”は次の3つです。

• サービス影響：エンドポイントは応答しているか（LB/VIP/HTTP/DB接続など）
• クラスタ視点：どのノードがOnline/Offline扱いか、どのリソースがStarted/Stoppedか
• 安全装置：quorum と STONITH（フェンシング）が機能する前提が残っているか

たとえば、観測の入口はこれだけでも十分です（環境によりコマンドは異なります）。

• pcs status / crm status：全体の要約（DC、ノード状態、リソース状態）
• crm_mon -Afr1：状態変化も含めた観測（頻繁に叩くより、一度保存して比較する）
• journalctl：該当時間帯のpacemaker/corosyncログの“流れ”を掴む

ポイントは「コマンドを何回も叩いて画面が変わる」こと自体が情報だ、ということです。HAの障害は、クラスタが再計算し続けている場合があります。だから、最初はスクリーンショットやコピペで“現時点の証拠”を固定しておくと、後で原因に戻れます。

そして次に大事なのが、“触る順番”を決めることです。現場の本音として「とにかく復旧させたい」のは自然です。ただ、順番を誤ると、復旧したように見えても再発しやすい“不安定状態”が残ります。本記事では、まず状況を固定し、次にクラスタの安全装置（quorum/STONITH）を確認し、その上でリソースやノードを扱う、という一本の線で進めます。

なお、ここで「いま何が起きているか、どこまで触っていいか」を短時間で判断できない場合は、一般論で粘るより、専門家に状況を共有して収束（落とし込み）を図る方が結果的に早いことが多いです。特に共有ストレージやDRBDが絡む場合、誤った再起動や手動マウントがデータ不整合につながります。

　

第2章：Pacemaker と Corosync の役割分担を5分で思い出す（誰が何を決めている？）

障害対応で迷子になる一番の原因は、「どの層の問題か」を混ぜて考えてしまうことです。Pacemaker/Corosyncは、ざっくり言うと“通信（メンバーシップ）”と“意思決定（リソース制御）”を分担しています。

要素	主な役割	障害時に起きがちなこと
Corosync	ノード間のクラスタ通信、メンバーシップ（参加/離脱）、quorum判定の土台	ネットワーク断・遅延で「見えているメンバー」が変わり、分断のきっかけになる
Pacemaker	クラスタ全体の状態（CIB）に基づき、リソースをどこで動かすか決定し実行	リソース起動失敗→移動→再試行が連鎖し、状態が揺れる（フラッピング）
STONITH/Fencing	分断時に“片側を確実に止める”安全装置（データ破壊の回避）	無効化・設定不備だとsplit-brainの危険が増し、復旧が難しくなる

ここを押さえると、切り分けが速くなります。たとえば「pcs statusでノードがOfflineに見える」場合、まず疑うのはCorosync側（ネットワーク、リング、MTU、遅延、パケットロス、NIC/スイッチ）です。一方「ノードはOnlineだがリソースが止まる/移る」を繰り返しているなら、Pacemaker側（リソースエージェント、依存関係、監視（monitor）設定、実体サービス）を疑います。

---

もう一つの重要概念がCIB（Cluster Information Base）です。PacemakerはCIBに記録された“望ましい状態”と“現在の状態”を比較して、どのノードで何を起動/停止するかを決めます。障害時に状態が暴れるときは、CIB上で失敗回数が積み上がっていたり、制約（location/colocation/order）が期待と違う形で効いていたりします。

ただし、だからといってCIBをいきなり編集して直そうとすると危険です。障害対応の序盤は「設定を直す」より先に、いまのクラスタがどんな判断をしているかを説明できる状態にするのが優先です。説明できないまま触ると、復旧後に「結局なぜ起きたか」が残らず、同じ夜勤が繰り返されます。

現場の心の声としては、こうなりがちです。

「リソースエージェントが悪い？ いやネットワーク？ それともストレージ？ もう全部じゃん…」

この“全部じゃん”を分解するのが、役割分担の理解です。次章では、障害時に必ず見るべき3点（quorum/STONITH/resource）を、順番込みで整理します。

　

第3章：最初の5分で見るべき3点セット：quorum / stonith / resource

HAクラスタ障害の初動で、どれだけ複雑に見えても、まず外してはいけない確認が3つあります。quorum、STONITH、resourceです。これを順番に見るだけで、無駄な操作が激減します。

1) quorum：クラスタが“多数決できる状態”か

quorumが失われると、クラスタは「どちらが正しい側か」を決められません。ここで軽率にリソースを動かすと、分断状態で両側がサービスを提供し、後から整合性が取れなくなる危険が増します。

確認は、pcs系なら status 出力にquorumに関する情報が出ますし、quorum関連のツール（環境により corosync-quorumtool など）で確認できる場合もあります。重要なのは、“いまクラスタは意思決定できる状態か”を先に確定することです。

2) STONITH：分断時に“片側を確実に止める”安全装置が生きているか

STONITH（フェンシング）は、分断や異常時に片側ノードを強制停止させることで、二重稼働（split-brain）による破壊的な競合を避ける仕組みです。運用現場では「とりあえず動かすためにSTONITHを無効化」してしまうケースがありますが、障害時にはそれが“地雷”になります。

初動では、STONITHが有効か、フェンスデバイスが定義されているか、直近でフェンスが失敗していないか、を確認します。もしSTONITHが成立しない状態なら、復旧方針は一段慎重になります（どちらが正で、どちらを止めるかを人間が確実に決める必要が出ます）。ここで迷いがある場合、一般論では危険なので、専門家と一緒に安全な収束（落とし込み）を設計する価値があります。

3) resource：止まって困る“実体”と、クラスタが見ている“論理”を一致させる

最後にresourceです。ここで大事なのは、アプリやDBの“実体プロセス”と、Pacemakerが見ている“起動状態”がズレることがある点です。たとえば、アプリは死んでいるのにPacemakerはStarted扱い、逆に手動で起動してしまってPacemakerがStopped扱い、などです。

このズレがあると、クラスタは正常に制御できません。初動では、次のような観点で整理します。

• どのリソースが失敗しているか（fail count、last failure）
• どのノードで動くべきか（制約・優先度・stickiness）
• なぜ失敗したか（リソースエージェントの戻り値、監視間隔、依存関係）

---

この3点セットを見ずに「とりあえず再起動」「とりあえずcleanup」は、復旧の再現性を下げます。もちろん状況によっては再起動が正しい選択になることもありますが、それはquorum/STONITHを把握した上で判断したい。

現場の本音として「また運用が増えるだけじゃないの？」と思うのは自然です。でも、ここでの手順は“運用を増やす”ためではなく、障害時に余計な操作を減らしてノイズカット（情報の整理）をするための型です。型があると、上司や役員への説明も「何が起きて、何を確認し、どこがリスクか」を短時間で言語化できます。

次章では、この3点セットの中でも特に事故につながりやすい split-brain とフェンシング不発を、典型原因と“やってはいけない動き”込みで整理します。

　

第4章：『切替わらない』『両方動く』— split-brain の前兆とフェンシング不発の典型原因

HAクラスタ障害で一番怖いのは、「止まる」より「両方動く」です。とくに共有ストレージや同期レプリケーション（例：DRBD）と組み合わさると、二重書き込みや整合性崩壊につながり、復旧難易度が跳ね上がります。これがsplit-brainの本質です。

split-brainの“前兆”は、だいたい通信品質から始まる

完全断ではなく、遅延・パケットロス・片方向断のような“中途半端な通信不良”が特に厄介です。ノードAからBは見えるが、BからAは見えない、といった状態や、マルチリング構成で片側だけ品質が悪化している状態などが、クラスタの判断を揺らします。

このとき現場はこう思いがちです。

「ネットワークっぽいけど、サービスは死んでる。だったら先にサービスを起こしたい…」

しかし、通信が不安定なままリソースを動かすと、再び分断して“両方起動”のリスクが増えます。ここはブレーキ（歯止め）をかけるポイントです。

フェンシング不発の典型原因

STONITHがあるのに効かない、あるいはSTONITHを無効化してしまっている。よくある原因は次の通りです（環境差はあります）。

• 運用都合でSTONITHを無効化：導入時の暫定対応がそのまま本番化
• フェンス装置の疎通不良：iLO/iDRAC、PDU、クラウドAPI等への到達性や認証の問題
• 権限・認証の更新漏れ：パスワード更新や証明書更新でAPIが失敗する
• 名前解決・時刻ずれ：DNS/hosts不整合、NTP不調で相互認証が崩れる
• 依存ネットワークの同時障害：クラスタ通信とフェンス経路が同じ機器に依存している

---

重要なのは、「STONITHが効かない状態」は、クラスタの安全装置が外れているのと同義だということです。この状態での復旧は、一般論の手順をそのまま適用すると危険があります。どちらが正のデータを持っているか、どちらを止めるべきか、止めた後に整合をどう取るか、を構成に合わせて設計する必要があります。

たとえば共有ストレージが絡む場合、片側ノードの“論理停止”だけでは不十分なことがあります（実体としてI/Oが止まっていない、マウントが残っている等）。このあたりは、リソースの種類・ストレージ方式・RAID/ファイルシステム・レプリケーション方式で最適解が変わります。つまり、ここには一般論の限界があります。

だからこそ、終盤で触れる結論につながります。HAは魔法ではなく、「分断したときに誰を止めるか」を設計に組み込んだ仕組みです。もし自社環境でSTONITHが成立しない、あるいは構成が複雑で判断が難しい場合は、株式会社情報工学研究所のような専門家と一緒に、フェンス経路を分離し、再発防止まで含めて“場を整える”方が、結果的に夜間対応を減らせます。

　

第5章：ログは味方：corosync / pacemaker / journalctl の読みどころ（見る順番）

「ログを見れば分かる」と言われても、Pacemaker/Corosyncのログは量が多く、初動では逆に迷子になります。ここで効くのが“見る順番”です。全部を精読するのではなく、時系列で何が起きたかを短時間で掴むための型を持ちます。目的は原因究明の前に、状況をノイズカット（情報整理）して収束方向を決めることです。

まずは「いつからおかしいか」を固定する

障害対応で最初に揃えるべきは、監視通知やユーザー申告などの「事象開始時刻」です。時刻が曖昧だと、ログの探索範囲が膨らみます。できるだけ次のように固定します。

• 監視のアラート時刻（Prometheus/Zabbix等）
• 業務影響が出た時刻（アプリログ、アクセスログ）
• クラスタが状態変化した時刻（crm_monのtransition）

この“起点”が決まると、journalctlで狙い撃ちできます。

journalctlでの基本形（環境差はあるが考え方は同じ）

多くのLinux環境では、Pacemaker/Corosyncはsystemd管理下にあります。まずは該当時間帯のログを、短い範囲で引きます。

• corosync：メンバーシップ変化、リンク状態、quorum関連の変化が見える
• pacemaker：DC選出、リソースの起動/停止、失敗判定、フェンス試行が見える

大事なのは、ログの1行1行に深追いしないことです。最初は「流れ」を見ます。典型的には、次の順序で現象が出ます。

1. 通信品質低下やリンク断（corosync側）
2. メンバーシップ変化→quorumの変化（corosync/quorum）
3. DC選出や再計算（pacemaker）
4. リソースの停止/移動/再起動、フェンス試行（pacemaker/stonith）

---

見るべき“キーワード”の方向性

ログの表現はディストリやバージョン、設定で差がありますが、探すべきテーマは共通です。

• Membership change：ノードの参加/離脱、リングの状態変化
• Quorum：quorate/non-quorate の遷移
• DC：どのノードがDC（意思決定者）になったか、切り替わったか
• Fencing：stonithの実行・失敗・タイムアウト
• Resource action：start/stop/monitor/promote/demote の実行と結果

ここで一つ現場あるあるを言うと、「リソースの失敗」だけ見てしまうことです。でも、リソース失敗は結果で、前段にquorum喪失や通信断があることも多い。だからこそ、corosync→quorum→pacemakerの順で流れを押さえます。

“証拠”を残す：ログは採取して比較する

障害時は状態が揺れます。だから、調査中にログが流れて条件が変わることがあります。コマンド出力やログ断片は、できれば採取して保存し、後で比較できるようにします。これは原因究明だけでなく、上司への説明や再発防止の設計にも効きます。

そして、ログが示す“方向性”が見えたら、次章の「触る順番（停止→隔離→整合→再起動→再配置）」に入ります。ログ解析は、復旧手順の前に“温度を下げる（落ち着かせる）”ための材料です。

　

第6章：復旧手順の“触る順番”を固定化する：停止→隔離→整合→再起動→再配置

Pacemaker/Corosyncの障害で一番やってはいけないのは、「思いつきで手を出す」ことです。だからこそ、どの環境でも通用しやすい“触る順番”を先に持っておきます。細部は構成で変わっても、順番の思想は共通です。

手順の骨格：5ステップ

1. 停止：これ以上状況が変わらないようにする（必要なら一時的に制御を止める）
2. 隔離：問題ノード/経路/リソースを切り分け、影響範囲を閉じる
3. 整合：データ・マウント・役割（Master/Slave等）が一貫する状態に揃える
4. 再起動：必要最小限でサービス/リソース/ノードを復帰させる
5. 再配置：最終的に“あるべき場所”に戻し、監視・制約も含めて正常系に戻す

この順番が重要な理由は、HAクラスタが自律的に再計算して動くからです。こちらが何かを直している最中に、クラスタが別の判断をして状態が変わると、復旧が難しくなります。だから最初にブレーキをかけて、状況を固定します。

---

1) 停止：クラスタ制御を落ち着かせる

状態がフラッピングしているとき、リソースは起動→失敗→移動→起動を繰り返します。この状態でログを追うのは厳しい。まずはクラスタが暴れない状態にします。

注意点は、停止の仕方です。単純にサービスを止めるのではなく、クラスタの仕組みに従って「制御を止める」「特定リソースを管理外にする」など、設計に合った方法を取ります。ここは環境依存が強く、誤るとサービス影響が拡大します。業務影響が大きい場合は、一般論で踏み込まず、専門家と一緒に“止め方”を決めるのが安全です。

2) 隔離：分断・二重稼働の可能性を潰す

次に隔離です。通信が不安定なノードや、疑わしい経路を残したまま復旧を進めると、再分断します。ネットワーク断が疑わしければネットワーク側の修復・迂回が先ですし、ノード障害なら問題ノードを切り離して片系運転に寄せる判断もあります。

ここでのゴールは「とにかく動かす」ではなく、両方動く可能性を消すことです。STONITHが成立しない環境では特に重要です。

3) 整合：データと役割を揃える

整合フェーズは、ストレージ方式で難易度が大きく変わります。共有ストレージ、DRBD、アプリ内レプリケーション、分散ストレージなど、どれも“正”の決め方が異なります。ここで無理に一般論を当てはめると、後で整合が取れなくなります。

現場の心の声はこうです。

「動いてるっぽいし、もう戻していい？…いや、後で怖いかも」

この“後で怖い”が整合フェーズです。必要ならファイルシステム整合、レプリケーション状態確認、アプリの書き込み停止などを行い、一貫した状態に揃えます。

4) 再起動：必要最小限で復旧する

整合が取れたら、必要最小限の再起動で復旧させます。全部再起動すると、原因が隠れます。たとえばネットワーク問題が残っているのに再起動で“たまたま直った”ように見えると、再発時に同じ夜勤が戻ってきます。

5) 再配置：正常系に戻し、再発防止の入り口を作る

最後は再配置です。片系運転で一旦復旧したなら、どの条件で元の配置に戻すか（failback）、stickinessや制約が適切か、監視（monitor）間隔が過剰ではないか、などを確認します。ここで“場を整える”と、次の障害が沈静化しやすくなります。

次章以降は、この5ステップを前提に、よくある障害パターン（ノード障害、ネットワーク断、ストレージ不整合）を具体的に整理します。

　

第7章：パターン別復旧① ノード障害（片系ダウン・再参加・誤検知）

まず一番多いのがノード障害です。「本当に落ちた」のか「落ちたように見えている」のかで、対応が変わります。ここで重要なのは、クラスタがどう見ているかと、OSがどうなっているかを分けて確認することです。

典型シナリオA：片系が物理的に落ちた（電源断・カーネルパニック等）

この場合、クラスタは通常、残りのノードでサービス継続を試みます。焦点は次の2点です。

• 残系でリソースが期待通り動いているか（サービス影響の沈静化）
• 落ちたノードが復帰したときに、勝手に二重稼働しないか（復帰時の安全）

STONITHが正しく機能していれば、落ちたノードが“中途半端に生きている”ケースを潰せます。逆にSTONITHが不確実だと、復帰時にsplit-brainのリスクが上がります。

典型シナリオB：ノードは生きているが、クラスタから見えない（誤検知）

ネットワーク断や一時的な高負荷で、クラスタがノードをOffline扱いにすることがあります。この場合は、ノード単体でOSログやNIC状態、負荷（CPU/メモリ/I/O待ち）を確認し、「なぜハートビートが落ちたか」を掴む必要があります。

現場の本音はこうです。

「落ちてないのに落ちた扱い？ それ一番困るやつ…」

はい、困ります。しかも再発します。だから、このパターンは“復旧”より“原因固定”が重要です。例えばI/O詰まりでスケジューリングが遅延し、ハートビートが間に合わないケースもあります。単純な再起動で一瞬直っても、根は残ります。

---

復旧の要点：戻す前に「クラスタ側の失敗履歴」を整理する

ノードが復帰したあと、Pacemakerは過去の失敗回数（fail count）やlocation制約に基づき、リソース配置を変えることがあります。ここで「なぜ戻らない？」が発生します。

このとき必要なのは、まず“クラスタがそう判断している理由”を説明できることです。失敗履歴が積み上がっているなら、それを整理しないと、復帰してもまた追い出されます。

ただし、失敗履歴の整理（cleanup等）を乱用すると、本当に危険な状態でも再試行が走り続けます。だから第6章の順番どおり、隔離と整合が取れた後に、“必要最小限”で整理します。

次章では、ノード障害と並んで頻度が高く、かつ再発しやすい「ネットワーク断」を扱います。リング、冗長、スイッチ、MTUなど、現場がハマりがちなポイントを整理します。

　

第8章：パターン別復旧② ネットワーク断（リング/スイッチ/冗長の落とし穴）

Pacemaker/Corosyncクラスタで「いちばん厄介な障害」を挙げるなら、完全断よりも“品質劣化”です。遅延、パケットロス、片方向断、MTU不一致などは、ノードが落ちたように見えたり、quorumが揺れたり、DCが頻繁に入れ替わったりします。現場の体感としては「動いてるのに動いてない」「たまに直る」が混ざり、状況説明が難しくなります。

まず整理する：クラスタ通信と業務通信は同じネットワークか

Corosyncのクラスタ通信が業務LANと同居している場合、業務トラフィック増大や瞬間的な輻輳で、クラスタのハートビートが遅れます。逆に、クラスタ通信を分離していても、冗長スイッチやLACP、VLAN設定の揺れで“片方だけ悪い”状態が起きます。

ここは一般論として、次の観点で見える化します。

• 経路：クラスタ通信が通るNIC/スイッチ/VLAN/ルータはどれか
• 冗長：冗長が「冗長として機能している」設計になっているか（同一障害点がないか）
• 制御：ファイアウォールやセキュリティ製品がクラスタ通信を落としていないか

---

Corosync側で起きがちな“症状”と方向性

ログや状態から、よくあるパターンを整理すると切り分けが速くなります。

症状	クラスタで起きがちなこと	疑う方向
ノードが頻繁にJoin/Leave	メンバーシップが揺れる、再計算が連発	遅延/ロス、NICドライバ、スイッチ輻輳、LACP/VLAN不整合
DCが頻繁に変わる	意思決定者が入れ替わりリソースが落ち着かない	通信品質低下、CPU/I/O詰まりでハートビートが遅れる
quorumが出たり消えたり	安全側に倒れてリソース停止、あるいは起動抑制	分断/片方向断、タイムアウト設定と実環境のギャップ

ここでの注意点は「設定値を闇雲に変更しない」ことです。たとえばタイムアウトを延ばせば“見かけ上”落ち着くことがありますが、実際にはネットワーク品質が悪いまま、障害検知が遅れる形になることもあります。どちらが正しいかは、業務要件（切替に許容される時間）とネットワーク設計に依存します。

復旧の基本：通信を安定させてから、クラスタを落ち着かせる

ネットワークが原因の場合、クラスタ側の操作（cleanupや手動移動）で一時的に整っても、根が残っていれば再発します。復旧の順番としては次が基本です。

1. クラスタ通信経路の不安定要因を除去する（リンク、スイッチ、VLAN、MTU、フィルタ）
2. メンバーシップが安定し、quorumが安定していることを確認する
3. その後で、必要最小限のリソース再配置・失敗履歴整理を行う

そして、ネットワーク原因が濃厚なのに確証が取れない場合は、ここで“温度を下げる”判断が効きます。つまり、片系運転に寄せる、影響範囲を閉じる、暫定的にリソースを固定するなど、被害最小化を優先することです。構成によってはこの暫定策が危険にもなり得るため、停止影響が大きい現場ほど、株式会社情報工学研究所のような専門家と一緒に「安全に収束させる」方針を作る方が結果的に早いことがあります。

　

第9章：パターン別復旧③ ストレージ不整合（DRBD/iSCSI/FS、整合性の取り方）

HAクラスタの復旧で最も慎重さが求められるのがストレージです。なぜなら、サービス停止よりもデータ不整合の方が復旧コストを跳ね上げるからです。Pacemaker/Corosync自体はリソースを“動かす枠組み”ですが、ストレージの整合性は構成次第で前提が変わります。ここには強い一般論の限界があります。

まず分類する：共有ストレージか、同期レプリケーションか

代表的には次のように分かれます。

方式	例	注意点（障害時）
共有ストレージ	SAN/NAS、iSCSI、FC、共有LUN	二重マウントや二重書き込みの回避が最重要（STONITHの成立が鍵）
同期レプリケーション	DRBD、アプリ/DBレプリケーション	Primary/Secondaryの役割と整合を崩すとsplit-brainが発生しやすい

現場の心の声はこうなりがちです。

「サービスは戻したい。でもストレージを触るのが一番怖い…」

その感覚は正しいです。だからこそ、復旧の順番は第6章のとおり隔離→整合→再起動が軸になります。

---

共有ストレージでの典型リスク：二重マウントと“見えないI/O”

共有LUNを使う構成では、「ノードAは止めたつもり」でも、実体としてI/Oが止まっていないケースがあります。たとえば、OSは応答しているがアプリが固まっている、あるいはネットワーク断で管理者がSSHできないがI/Oは続いている、などです。ここで別ノードから同じファイルシステムをマウントして書き込みを始めると、整合性事故につながります。

したがって、復旧では次を徹底します。

• “どちらが書いているか”を確実に一つにする（STONITHが成立しない場合は特に慎重）
• ファイルシステムは“安全に停止した状態”で整合確認を行う（方式により手順が異なる）
• マウント・ロック・クラスタFSの前提（GFS2/OCFS2等の有無）を誤認しない

共有ストレージでクラスタFSを使っていないのに、結果的に二重マウント状態を作るのは典型的な事故パターンです。

DRBDでの典型リスク：split-brainと“どちらが正か”

DRBDのような同期レプリケーションは、役割（Primary/Secondary）と接続状態の理解が前提です。分断後に両側がPrimaryになる、あるいは再接続時に双方が「自分が正」と主張する状態が、いわゆるsplit-brainです。この状態の解消は、データの新旧・アプリ整合・業務要件で選択が変わります。したがって、一般論で「このコマンドで直る」と断言するのは危険です。

実務上は、少なくとも次の情報が必要になります。

• 分断が起きた時刻と、その間にどちらで書き込みが走ったか
• アプリ/DB側にトランザクション整合の仕組みがあるか
• DRBDの設定（プロトコル、フェンシング方針、after-sb-*ポリシー等）
• Pacemakerの制約（昇格/降格順序、colocation、order）

この情報が揃って初めて、「どちらを正として同期するか」「どこまで業務を止めて整合を取るか」を決められます。ここは穴埋め（整合の取り直し）の局面で、誤ると後戻りが難しくなります。

---

“整合が取れた”の定義を、運用の言葉に落とす

ストレージ復旧で重要なのは、「整合が取れた」の定義を、クラスタ視点だけで終わらせないことです。PacemakerがStartedと表示しても、アプリケーション整合が崩れていれば障害は再発します。逆にアプリが動いていても、レプリケーションが不健全なら将来の切替で破綻します。

したがって復旧の終盤では、次の二重チェックが有効です。

• クラスタ視点：リソース状態、失敗履歴、制約どおりか
• 業務視点：アプリの整合確認（DBチェック、アプリヘルス、ログのエラー有無）

ストレージが絡む障害は、個別の構成・契約（保守範囲）・停止許容時間・データ重要度で最適解が変わります。迷いがある場合に一般論で押し切ると、後日「実は不整合が残っていた」という形で炎上/クレーム対応に発展しかねません。だからこそ、判断が難しい局面ほど、株式会社情報工学研究所のような専門家に状況を共有し、再発防止まで含めた復旧計画を作ることが現実的です。

　

第10章：結論：HAは魔法じゃない—“説明できる運用”が夜間対応を減らし事業停止リスクを下げる

ここまで見てきたように、Pacemaker/CorosyncのHAクラスタ障害は「コマンドを知っているか」だけでは沈静化しません。鍵になるのは、クラスタが何を根拠に何を判断したのかを説明できること、そして触る順番を守って被害最小化に寄せることです。

現場エンジニアの本音としては、こう思うのが自然です。

「HAにしたのに、なんで俺たちが夜中に起きてるんだっけ…」

これに対する現実的な答えは、「HAは“止まらない”仕組みではなく、止まるときの形を制御する仕組み」ということです。フェンシング（STONITH）が成立しない、ネットワーク品質が揺れる、ストレージ整合の前提が曖昧、運用手順が人によって違う——このどれかが欠けると、HAは不安定になります。逆に言えば、設計と運用を“説明可能”な形に整えるほど、夜間対応は減り、復旧の再現性が上がります。

---

「説明できる運用」を作るための最低限チェックリスト

復旧対応の直後は疲れています。だからこそ、翌営業日に「記憶が残っているうちに」事実だけを整理し、次の障害で迷わない材料を残します。おすすめは、論理ではなく時系列です。

項目	残すべき内容（例）	狙い
発生時刻	最初のアラート時刻、業務影響開始、復旧完了	ログ探索範囲の固定、説明の起点
クラスタ状態	pcs/crm_mon出力、Online/Offline、DC、quorum状態	「クラスタがどう見ていたか」を固定
安全装置	STONITH有効/無効、フェンス試行の成否、失敗理由の有無	split-brainリスクの評価
リソース挙動	失敗したリソース、失敗回数、移動履歴、監視（monitor）結果	復旧の再現性、根本原因の方向
実施操作	誰が何をいつ実行したか（手動起動/停止、隔離、再起動など）	「操作で変わったこと」を切り分ける
根の仮説	ネットワーク品質、ノード負荷、ストレージ要因など“方向性”	次の調査・改善の優先順位付け

このチェックリストは「立派な報告書」を作るためではありません。次回の障害で、最初の5分の判断を速くし、無駄な操作を減らすための防波堤です。

---

復旧後にやるべき“再発防止テスト”は、設計の前提を確認すること

復旧が終わると、つい「直った」で終わりがちです。しかしHAは、設計の前提（quorumが保てる、フェンスが効く、ネットワークが想定品質、ストレージ整合が守られる）が満たされて初めて成立します。再発防止は、これら前提が本当に満たされているかを確認する作業です。

一般論として、次のような観点で“安全に”確認します（実施可否や手順は環境・契約・停止許容で変わります）。

• フェンシングの成立確認：フェンスデバイスが到達可能で、想定どおりに動作する前提が維持されているか
• ネットワークの健全性：クラスタ通信経路の輻輳・片方向断・MTU不一致が起きにくい構成か
• リソース監視の妥当性：monitor間隔が過剰でフラッピングを誘発していないか、逆に検知が遅すぎないか
• ストレージ整合の運用：二重マウントが起きない運用になっているか、障害時の“正”の決め方が定義されているか

ここは「とりあえず設定をいじって改善」ではなく、設計の前提を点検して、どの前提が崩れたかを特定する作業です。

---

終盤の結論：一般論の限界と、個別案件で専門家に相談すべき理由

本記事は、Pacemaker/Corosyncクラスタ障害の「よくある形」と「触る順番」をまとめました。ただし、ここまで繰り返し触れた通り、HAは構成・契約・停止許容・データ重要度で最適解が変わります。特に次の条件が絡むと、一般論の手順だけで判断するのは危険になりがちです。

• STONITHが有効でも、フェンス経路が業務ネットワークと同一障害点になっている
• 共有ストレージでクラスタFSではないのに、運用上二重マウントの可能性が残る
• DRBD等のレプリケーションで、分断時の“正”の決め方（ポリシー）が曖昧
• 業務要件として停止許容が短く、切替時間の調整が設計判断になる
• 運用担当が複数チームにまたがり、障害時の意思決定経路が複雑

こうしたケースでは、現場が頑張っても「判断材料が足りない」ことが起きます。だからこそ、読者が具体的な案件・契約・システム構成で悩んだときは、一般論で粘るより、専門家と一緒に“収束（落とし込み）”の筋道を作る方が現実的です。

もし「STONITHをどう設計すべきか」「ネットワーク冗長のどこが単一障害点か」「ストレージ整合の手順をどうRunbook化するか」「監視・タイムアウトをSLAに合わせてどう調整するか」など、具体論に踏み込む必要があるなら、株式会社情報工学研究所のような専門家に相談して、現場エンジニアが説明できる形に設計・運用を整えることをおすすめします。一般論では埋めきれないギャップを埋めることが、夜間対応を減らす最短ルートになりやすいからです。

　

付録：現在のプログラム言語各種における「障害対応・運用設計」の注意点（HA運用の現場目線）

Pacemaker/Corosyncそのものはミドルウェアですが、現実のHA運用ではアプリケーションや運用ツールの実装が復旧難易度を左右します。ここでは「どの言語が良い/悪い」ではなく、障害対応・運用の観点で気をつけるべきポイントを整理します。一般論としての注意点なので、最終的には自社の要件・体制・既存資産で判断してください。

---

共通の前提：言語より先に“運用要件”を固定する

どの言語でも、HA運用で最低限決めておくべきことは共通です。

• タイムアウト方針：外部依存（DB/ストレージ/API）に対して待ち続けない設計か
• 冪等性：同じ操作が繰り返されても壊れない（再試行が前提）
• 観測可能性：ログ、メトリクス、トレースで「何が起きたか」を後から追える
• 終了と再起動：プロセスが停止できる、起動時に自己修復できる（中途半端に残らない）

Pacemakerのリソース監視（monitor）は「落ちたら再起動/移動」が基本動作なので、アプリ側も「再起動される前提」で作られていることが重要です。

---

主要言語別の注意点

C / C++

• メモリ安全性：ヒープ破壊や未定義動作は“たまに落ちる”形で出やすく、再現性が低い。障害対応を難しくするため、ASan等の検査やクラッシュダンプ運用を設計に組み込む
• 依存ライブラリ：OS更新・ライブラリ更新で挙動が変わることがある。ビルド再現性（固定化）と脆弱性対応の両立が課題
• フォーク/スレッド：デッドロックや競合が起きると監視がタイムアウトし、クラスタ側でフラッピングが起きやすい

Rust

• メモリ安全性：安全性の恩恵は大きいが、unsafeやFFIが入ると運用上の落とし穴が戻る。境界の監査が必要
• 非同期：async設計は強力だが、タイムアウト/キャンセルの一貫性が崩れると“止まらない処理”が残りやすい
• バイナリ配布：静的リンク等で配布しやすい一方、脆弱性修正時の再ビルド・再配布の運用を確立しておく

Go

• goroutineリーク：外部依存が詰まるとgoroutineが溜まり、間接的に監視タイムアウトやOOMにつながることがある。タイムアウトとキャンセルを徹底
• GC停止とレイテンシ：通常は安定しやすいが、低レイテンシ要件では監視間隔との相性を意識する
• 単一バイナリ運用：デプロイは楽だが、設定・秘密情報・証明書更新の運用（再起動要否）を設計に織り込む

Java（JVM）

• GCとメモリ設計：ヒープ設定やGC挙動次第で一時停止やスループット低下が出る。監視のタイムアウト設計と整合させる
• スレッド枯渇：外部依存待ちが増えるとスレッドプール枯渇で“見かけ上の停止”が起きる。タイムアウトと隔離（バルクヘッド）を設計に入れる
• 依存管理：Maven/Gradle依存が増えると脆弱性対応が重くなる。SBOMや更新手順を運用に組み込む

C#（.NET）

• スレッドプールと非同期：async/awaitでも外部依存のタイムアウトやキャンセルが曖昧だと処理が溜まりやすい
• ランタイム更新：.NETの更新とOS更新の関係、コンテナ運用時のベースイメージ更新が障害要因になり得る
• ログと観測：構造化ログを前提にしないと、障害時に因果関係が追いにくい

Python

• 依存解決：ライブラリ依存（pip）が運用上の不確実性になりやすい。ロックファイルやイメージ固定で再現性を確保
• 性能とタイムアウト：I/O待ちや外部依存で詰まると監視に引っかかる。タイムアウトとリトライ方針を明文化し、冪等性を担保
• 障害時ツール用途：運用スクリプトに向く一方、例外処理が雑だと“途中までやって止まる”事故が起きやすい。必ずロールバックやドライラン設計を入れる

JavaScript / TypeScript（Node.js）

• 単一スレッド：CPUを食う処理が混ざるとイベントループが詰まり、ヘルスチェックが落ちる。重い処理は分離する
• 依存の広さ：npm依存が増えやすく、脆弱性対応・供給網リスクの管理が重要。更新運用と検証環境が必須
• プロセス管理：再起動前提で動く設計（ステートレス化、外部永続化）が特に重要

PHP

• 実行モデル：FPM等のプロセスモデル次第で“詰まり方”が変わる。ワーカー枯渇は監視上の停止に見えやすい
• 拡張・バージョン：拡張やバージョン差で挙動が変わる。OS更新・PHP更新計画を運用に組み込む
• ログ整備：アプリログとWebサーバログの突合ができるように相関ID等を導入すると障害対応が速くなる

Ruby

• 依存と更新：gem依存やランタイム更新で挙動が変わることがある。固定化と脆弱性対応のバランスが課題
• 性能劣化の見え方：GCやI/O待ちで遅くなり、監視タイムアウトに繋がることがある。ヘルスチェック設計と合わせる

Shell（bash等）/ PowerShell

• 運用スクリプトの事故：小さなスクリプトでも本番障害を増幅し得る。タイムアウト、リトライ、エラー時停止、ログ出力を必ず入れる
• 冪等性：同じ操作を複数回実行しても壊れないようにする（存在チェック、差分適用）
• 権限：sudo/権限不足が原因で途中失敗しやすい。実行ユーザーと権限設計を明確にする

SQL（言語というより運用対象）

• 整合性と復旧：HA障害はDBの整合性確認が最後の関門になりやすい。バックアップ/リストア、レプリケーション、フェイルオーバー手順を必ずRunbook化
• スキーマ変更：障害時にスキーマ変更が重なると復旧難易度が上がる。変更管理（メンテ時間、ロールバック）を厳格にする

---

付録のまとめ：言語の違いは「運用の落とし穴の違い」

ここで挙げた注意点は、言語の優劣ではありません。HA運用では、タイムアウト・冪等性・観測可能性・再起動前提が守られているかが本質で、言語ごとに崩れやすいポイントが違う、という話です。

そして最終的には、クラスタ（Pacemaker/Corosync）・ネットワーク・ストレージ・アプリの境界にまたがる判断が必要になります。ここに一般論の限界があります。もし「自社の構成でどこが単一障害点か」「フェンシングは成立しているか」「ストレージ整合の手順が安全か」「監視とタイムアウトはSLAに合っているか」など、具体的な設計判断に踏み込む必要があるなら、株式会社情報工学研究所への相談・依頼を検討してください。現場の制約を前提に、収束しやすい運用と再発防止の設計まで一緒に組み立てることができます。