はじめに
クラスタ構成を初めて担当する方から、よく次の質問を受けます。
「クラスタ組んどけば落ちないんですよね?」
この質問には、明確に「いいえ」と答える必要があります。ここを誤解したまま設計や運用に入ると、事故につながります。
この記事は、HA クラスタという仕組みを初めて学ぶ方に向けて、何をする仕組みなのか、そしてなぜ難しいのかを説明するものです。特定製品の設定手順書ではありません。手順はマニュアルに書いてあります。マニュアルに書かれていないのは、「なぜその設定項目が存在するのか」の方です。
扱う範囲
対象は HA(High Availability / フェイルオーバー)クラスタ —— 「片方が壊れたらもう片方が引き継ぐ」タイプのものです。
以下は対象外とします。
- 負荷分散(スケールアウト)クラスタ —— 性能を上げるためのクラスタ
- 並列 DB・分散 DB —— Oracle RAC のような、複数ノードが同時に稼働するもの
- クラウドのマネージド冗長化(Multi-AZ、可用性セット等) —— これらは「クラスタウェアを使わずに可用性を確保する」手段であり、別テーマです
製品名の扱いについて
概念を主軸に説明しますが、概念だけでは現場の会話と接続できません。そこで以下の 3 つを例示として随所に挙げます。
| 類型 | 製品例 | 位置づけ |
|---|---|---|
| OSS / Linux | Pacemaker + Corosync | 各 Linux ディストリビューションが HA クラスタスタックとして提供(RHEL では High Availability Add-On) |
| OS 標準 / Windows | WSFC(Windows Server Failover Clustering) | Windows Server の機能として同梱 |
| 商用 / 国内 | CLUSTERPRO X | 国内での採用例が多い商用 HA 製品 |
これらの使い方を解説する記事ではありません。同じ概念が製品によって別の名前・別の実装で提供されているという事実を示すための例示です。製品仕様はバージョンによって変わるため、実案件では必ず当該バージョンのマニュアルで確認してください。
1. 結論を先に
この記事で最も伝えたいことを先に書きます。
クラスタは「止まらない仕組み」ではない。
壊れた側を切り離し、残った側で起動し直す仕組みである。
この一文から、HA クラスタの性質がほぼすべて導出できます。
「起動し直す」から導かれること
- 起動には時間がかかる。つまりダウンタイムはゼロにならない
- 起動は失敗しうる。つまりフェイルオーバーしても復旧しないことがある
「切り離す」から導かれること
- 切り離すには、「壊れた」という判断が必要になる
- そして —— これがこの記事の中心ですが —— その判断は原理的に確実には行えません
判断機構が増えることから導かれること
- クラスタウェア自身が新たな障害要因になる。可用性を上げるつもりで、壊れる箇所を増やしている側面がある
まず、「クラスタを組めば無停止になる」というイメージはいったん外して考えます。クラスタとは、壊れることを前提に、壊れた後の振る舞いを設計する仕組みです。
クラスタは目的ではなく、手段である
もう一つ、最初に置いておきたい枠組みがあります。
現場では「クラスタを入れるかどうか」から議論が始まりがちですが、順序としては逆です。先に決めるべきは、どこまでの停止とデータ損失を許容するのかです。この 2 つには名前がついています。
| 用語 | 意味 | 問い |
|---|---|---|
| RTO(Recovery Time Objective) | 目標復旧時間 | 障害発生から、どれだけの時間でサービスを復旧させるか |
| RPO(Recovery Point Objective) | 目標復旧時点 | 障害時、どの時点までのデータ損失を許容するか |
この 2 つが決まって初めて、手段を選べます。HA クラスタ、データレプリケーション、バックアップ、アプリケーション側の冗長化は、それぞれ守れるものが違います。
- RTO を数秒にしたいなら、HA クラスタでは足りない可能性があります(後述のとおり、起動時間がかかるため)
- RPO をゼロにしたいなら、非同期のデータ複製では要件を満たせません
- 逆に「1 日以内に復旧できればよい」なら、クラスタを入れずバックアップからの復旧で足りるかもしれません
「とりあえずクラスタを入れておく」は、要件を確認していないことの言い換えになっていることが少なくありません。
2. 「引き継ぐ」とは何をすることか
フェイルオーバーの説明に入る前に、前提となる部品を確認します。「サービスが引き継がれる」と言うとき、実際に何が引き継がれているのかという話です。
2-1. 仮想 IP アドレス(VIP)
サーバ A(192.168.1.11)とサーバ B(192.168.1.12)があるとします。クライアントはどちらに接続すればよいでしょうか。
A に接続する設定にしておくと、A が壊れたときにクライアント側の設定変更が必要になります。これでは自動切り替えの意味がありません。
そこで、どちらか稼働中のノードに付け替えられる 3 つ目の IP アドレスを用意します。これが仮想 IP(VIP)です。
クライアントは常に 192.168.1.10 を見ています。裏側でこの IP がどちらのノードに付いているかは意識しません。フェイルオーバーとは、この VIP を付け替える動作を含みます。
ここで一つ注目したい点があります。VIP はどちらか一方にしか付いてはいけません。 両ノードが同じ IP アドレスを名乗ると、ARP 情報などが競合して接続先が不定になり、どちらに繋がるか保証できない不安定な状態になります。この「一方にしか存在してはいけない」という性質は、後で重要になります。
2-2. データをどうするか
VIP が移っても、データが引き継げなければ意味がありません。データの持ち方には大きく 2 つの方式があります。
共有ディスク方式
外部ストレージを両ノードから接続し、稼働している側だけがマウントして使います。
- 利点: データは 1 つしかないので、切り替えても中身は当然同じ
- 欠点: 共有ストレージが必要でコストがかかる。またストレージ自体が単一障害点になりうる
ミラーリング(データレプリケーション)方式
各ノードがローカルディスクを持ち、書き込みを相手にも複製します。
- 利点: 共有ストレージが不要。2 台のサーバだけで HA 構成が組める
- 欠点: 複製の仕組みが必要。同期方式によっては性能に影響し、非同期ならデータ欠損の可能性がある(= RPO に影響する)
【製品例】CLUSTERPRO X はミラーディスク方式を早くから提供しており、「共有ストレージを買う予算はないが冗長化はしたい」という需要に応えてきました。Linux では DRBD 等を Pacemaker と組み合わせて同種の構成を作ることもできます。
ここでも重要な性質があります。共有ディスクは、両ノードから同時に書き込んではいけません。 ext4、XFS、NTFS といった単一ノードからの利用を前提とした一般的なファイルシステムを、排他制御なしに複数ノードから同時に利用すると、データやファイルシステムを破損するおそれがあります。
なお GFS2 や OCFS2 のように、複数ノードからの同時アクセスを前提として設計されたクラスタファイルシステムも存在します。本記事が対象とする HA クラスタでは使わない構成のため、ここでは扱いません。
VIP は一方にしか存在できない。共有ディスクは一方からしかマウントできない。この「一方だけ」という制約が、クラスタウェアの設計を難しくしている根本原因です。
3. クラスタウェアの 4 つの仕事
クラスタウェアの仕事は、大きく 4 つに分解できます。
| 仕事 | 内容 | |
|---|---|---|
| ① | 監視 | 相手ノードやサービスが正常かを継続的に確認する(ハートビート) |
| ② | 判断 | 異常を検知したとき、フェイルオーバーすべきかを決める |
| ③ | 切り離し | 旧稼働ノードを確実に停止させる(フェンシング) |
| ④ | 起動し直し | VIP を付け替え、ディスクをマウントし、サービスを起動する(リソース制御) |
多くの入門解説は ① と ④ に紙幅を割きます。しかし現場で事故が起きるのは、多くの場合 ② と ③ です。 この記事では ② と ③ を重点的に扱います。
3-1. 正常時とフェイルオーバー時の流れ
まず、正常に動いている状態です。
待機系は、原則として何もしていません。ただ相手の生死を確認しながら待っています。「サーバを 2 台買ったのに 1 台は遊んでいる」という状態です。これは HA クラスタの本質的な性質であり、コスト面での説明が必要になる場面がよくあります。
次に、ノード A のハードウェアが故障した場合です。
注目したい点が 2 つあります。
1. 「応答なし」を即座に故障と判断していない
一度応答がなかっただけで切り替えると、瞬間的な負荷やパケットロスで無用なフェイルオーバーが発生します。そのため「何秒間、何回応答がなければ異常とみなすか」という猶予時間が設定されます。
そして、この猶予時間はそのままダウンタイムに加算されます。検知を早くすれば誤検知が増え、慎重にすればダウンタイムが延びる。ここには純粋なトレードオフがあり、一律の正解はありません。
2. 「A を強制停止(念のため)」という手順がある
A はもう電源故障で止まっているのに、なぜ B はわざわざ A を止めようとするのか。この問いへの答えが、この記事の中心テーマです。
3-2. ハートビート —— 何を見ているのか
ハートビート(heartbeat)は、その名の通り「心拍」の確認です。ノード同士が定期的に信号をやり取りし、相手の生存を確認します。
「生きている」の判定には、複数のレイヤがあります。
| レイヤ | 何を見るか | 検知できないもの |
|---|---|---|
| ノードの生死 | 相手ノードから応答があるか | OS は動いているがサービスが停止している状態 |
| サービスの生死 | プロセスが存在するか | プロセスは存在するが応答しないハング状態 |
| サービスの応答性 | 実際にリクエストを投げて応答するか | (検知力は高いが、負荷による誤検知のリスクが増す) |
初学者が陥りがちなのは、ノードの生死だけを見て安心してしまうことです。**現場の障害で多いのは「サーバは動いているのにサービスが応答しない」**という状態で、ノード監視だけではこれを検知できません。
一方で、監視を深くすればするほど誤検知の余地も増えます。この振り子については後述します。
なお、「サービスが応答しているか」をクラスタウェアがどう判定するのかという疑問が湧くはずです。クラスタウェアは、載せる業務アプリのことを何も知りません。この点は 5 章で扱います。
3-3. ハートビートの経路と、その冗長化
ハートビートを流す経路にも種類があります。
- ① 専用 LAN(インターコネクト): ハートビート専用に用意したネットワーク。最も一般的
- ② 業務 LAN: 業務通信と同じ経路。予備として併用されることが多い
- ③ 共有ディスク経由: 共有ディスク上の特定領域に書き込み合うことで生存を確認する。ネットワークが全滅しても機能する
ここが重要です。
ハートビート経路が 1 本しかない場合、その 1 本が切れると、ノードは「相手が死んだ」と判断します。実際には相手が元気に動いているにもかかわらず。
ケーブル 1 本、スイッチ 1 台の障害が、システム全体を巻き込む重大事故に発展しうる。この現象が、次章のスプリットブレインです。
4. スプリットブレイン —— 原理的に解けない問題
ここがこの記事の中心です。
4-1. 何が起きるのか
ノード A が稼働中、ノード B が待機中の構成で、両ノードは正常なまま、ハートビート経路だけが切断されたとします。
結果として、
- VIP が両ノードに存在する → 接続先が不定になり、正常なサービス継続を保証できない
- 共有ディスクが両ノードからマウントされる → 同時書き込みによるデータ破損
これがスプリットブレイン(split-brain / ネットワークパーティション)です。片方が停止するだけの単純な障害よりも、はるかに深刻な被害をもたらします。冗長化したことによって、冗長化しなかった場合より悪い結果になる —— これが HA クラスタの持つ危険性です。
4-2. なぜ「判断できない」のか
ノード B の立場になってみます。B に見えている事実は、たった一つです。
相手からの応答がない。
この事実から考えられる原因は、少なくとも 2 つあります。
- 相手ノードが本当に停止した
- 相手ノードは動いているが、通信経路が切れている
そして B には、この 2 つを区別する手段がありません。 相手に「生きてる?」と聞こうにも、聞くための経路が切れているのですから。
これは実装の巧拙の問題ではなく、分散システムにおける原理的な制約です。どんなに優れたクラスタウェアを選んでも、この問題は消えません。だからこそ、あらゆるクラスタウェアが何らかの対策機構を持ち、設計時にその設定を必ず求められます。
ここで冒頭の結論に戻ります。クラスタは「壊れた側を切り離す」仕組みでした。しかし、何が壊れたのかを確実に知ることはできない。 これが HA クラスタ設計の根本的な難しさです。
4-3. 対策その 1 —— クォーラム(多数決)
対策の考え方の一つは、多数決です。
ノードが 3 台あるとします。ネットワークが分断され、2 台のグループと 1 台のグループに分かれたとしましょう。
ここで、「過半数を確保できたグループだけがサービスを継続してよい」というルールを作ります。グループ 1 は 3 票中 2 票で過半数を確保しているので稼働を継続します。グループ 2 は 1 票しかないため過半数を取れず、自ら停止します。
これで、両方が同時に稼働することはなくなります。この「サービス継続の資格を得るのに必要な票数」をクォーラム(quorum、定足数)と呼びます。
クラスタのノード数が奇数で語られることが多いのは、これが理由です。 4 台構成で 2 対 2 に分断されると、素朴な多数決ではどちらも過半数を取れません(実際の製品には、偶数ノード時にどちらを残すか決めるための追加の仕組みが用意されています)。
4-4. しかし現場の多くは 2 ノードである
各ノードに 1 票ずつ与えるだけでは、2 ノード構成で 1 対 1 に分断されたとき、どちらを残すか決められません。 どちらも過半数(2 票中 2 票以上)を取れないからです。この原則をそのまま適用すれば、両方が停止することになります。片方は正常に動いていたにもかかわらず、です。
そして現場で多く見かける構成は、まさにこの 2 ノードです。コスト的にも、2 台で済むなら 3 台は買いません。
つまり、「2 ノードでスプリットブレインをどう防ぐか」が実務上の中心課題になります。解決策は 2 系統あります。
4-5. 対策その 2 —— 外部の力を借りて「残る側」を決める
2 票しかないなら、外部から判断材料を持ってくればよい、という発想です。ここには性質の異なる 2 つのアプローチがあります。混同されやすいので、分けて理解する必要があります。
(a) 第三の投票者を立てる —— 票そのものを増やす
ノードを増やすのではなく、投票だけする第三者を用意し、クラスタの票数を奇数にします。
実体は、たとえば以下のようなものです。
- 全ノードからアクセスできる共有ディスク上の領域
- ファイルサーバ上の共有フォルダ
- クラウドストレージ上の領域
- 別ホスト上で動く投票専用のサービス
分断されると、この第三者と通信できた側が 2 票を確保して過半数を取り、稼働を継続します。多数決の枠組みはそのままに、票数の問題だけを解いているのが特徴です。
【製品例】WSFC ではディスク監視 / ファイル共有監視 / クラウド監視(英語資料では Disk / File Share / Cloud Witness)として提供されます。「監視」は Microsoft の日本語訳ですが、機能としては正常性監視ではなくクォーラムの投票者です。ここは誤解しやすい部分です。Pacemaker では別ホスト上で動作するクォーラムデバイスがこれに相当します。
(b) 外部への到達性で判定する —— 自分が残ってよい側かを自分で決める
もう一つは、票を数えるのではなく、外部の基準点に到達できるかどうかで判断する方法です。
たとえば、デフォルトゲートウェイに ping を打ってみる。届かなければ、少なくとも自分はネットワークから孤立している。ならば自分が引き下がる —— という判断です。
ここで何が起きたかに注目してください。
「相手が死んだかどうか」は、依然として分かりません。しかし、「自分がサービスを継続してよい側かどうか」は判定できました。 問題を「相手の状態を知る」から「自分の状態を知る」に置き換えたわけです。
【製品例】CLUSTERPRO X の NP 解決には、DISK 方式のほか PING 方式・HTTP 方式があります。前者が (a)、後者が (b) の考え方です。Pacemaker でも ping による到達性を監視し、その結果を配置の判断材料に使う構成が採られます。
(a) と (b) は目的が似ていますが、同じものではありません。 (a) はクラスタメンバーシップ上の票を足す仕組み、(b) は外部到達性から自ノードの資格を判定する仕組みです。製品によってはどちらか一方しか持たないこともあり、両方を組み合わせることもあります。
4-6. 対策その 3 —— 相手を物理的に止める(フェンシング / STONITH)
もう一つの系統は、もっと直接的です。
相手が生きているか分からないのなら、確実に止めてから引き継げばよい。
これがフェンシング(fencing)であり、Linux 界隈では STONITH(Shoot The Other Node In The Head)という物騒な名前で呼ばれます。名前の物騒さは、この動作の性格をよく表しています。
具体的な手段は主に 2 つです。
(a) 電源を落とす
サーバに搭載された管理コントローラ(BMC。ベンダによって iLO、iDRAC 等の名称)に対して、業務 LAN とは別経路から電源断を指示します。OS がハングしていようが関係なく、物理的に電源が切れます。仮想環境であれば、ハイパーバイザに対して仮想マシンの強制停止を指示する方式もあります。
実務上の謎が一つ解ける部分です。 クラスタ構成の設計時に、なぜ iLO や iDRAC の IP アドレスとアカウント情報を聞かれるのか。なぜ管理 LAN の疎通が要件に入るのか。フェンシングのためです。 これを知らないと、ヒアリングシートの項目が意味不明な事務作業に見えます。
(b) ストレージ側で締め出す
ストレージに対して「このノードからのアクセスを拒否せよ」と指示し、共有ディスクへの経路を断ちます。ノード自体は動き続けますが、書き込みができないためデータは守られます。SCSI-3 Persistent Reservation という仕組みが使われることが多いです。
フェンシングにも弱点があります。 フェンシングの経路自体が死んでいたら、相手を止められません。止められない以上、安全のためにフェイルオーバーもできません。結果としてサービスは停止したままになります。これは 6 章の事故 2 で扱います。
4-7. 実装名称の対応表
ここまでの概念が、3 つの製品でどう呼ばれているかを対照します。
| 概念 | Pacemaker + Corosync | WSFC | CLUSTERPRO X |
|---|---|---|---|
| 多数決の仕組み | Corosync の投票機構(votequorum) | クォーラム構成(ノードマジョリティ等) | 多数決方式の NP 解決 |
| 第三の投票者(票を足す) | クォーラムデバイス(別ホスト上の投票サービス) | ディスク監視 / ファイル共有監視 / クラウド監視(Disk / File Share / Cloud Witness) | DISK 方式の NP 解決リソース |
| 外部到達性で判定 | ping 等による到達性監視を配置判断に利用 | (クォーラム構成が中心) | PING 方式 / HTTP 方式の NP 解決リソース |
| 相手の強制停止 | STONITH(フェンスエージェント経由で BMC・仮想基盤・ストレージを操作) | ストレージ側の排他制御による保護。クォーラムを失った側はクラスタサービスを停止 | 強制停止機能(BMC や仮想化基盤を経由) |
| この分野の呼称 | フェンシング / STONITH | クォーラム管理 | ネットワークパーティション解決(NP 解決) |
この表から読み取ってほしいのは、次の点です。
- やろうとしていることは 3 製品とも同じです。「多数決」「第三者」「強制停止」の組み合わせで解いています
- しかし名前が違います。 CLUSTERPRO X の「NP 解決」という用語を知らずに Pacemaker の知識だけで臨むと、設定画面で迷います。逆もまた然りです
- 設計思想の表れ方に差があります。 Pacemaker では STONITH が独立した設定項目として明示的に扱われ、利用者が手段を選んで構成します。一方 WSFC では、クラスタメンバーシップ、クォーラム、リソース所有権、ストレージ側の排他制御が OS 機能として統合されており、利用者から見える形が異なります。どちらが優れているという話ではありません
4-8. なぜ実装が分かれたのか
同じ問題を解いているのに、なぜ製品ごとに違う形になったのか。
- Pacemaker + Corosync は、多様なハードウェア・多様な用途に対応する必要がありました。だから「フェンスエージェント」という差し替え可能な部品構造を採り、あらゆる機器に対応できる代わりに、利用者が自分で選んで設定することを求めます
- WSFC は、Windows Server という単一のプラットフォーム上で動くことが前提です。だから OS 機能として深く統合でき、Active Directory やストレージ機能と連携した作りになっています。選択肢を絞る代わりに、踏み外しにくい
- CLUSTERPRO X は、製品として検証済みの構成、管理 GUI、国内向けドキュメントと問い合わせ窓口を備えています。ミラーディスク方式による共有ストレージ不要の構成を早くから提供してきたことも、国内で選ばれてきた要因の一つです
**「OSS があるのに、なぜ商用製品を買うのか」**という疑問については、誤解しやすい点を補足しておきます。
「OSS だからサポートがない」わけではありません。 Pacemaker は RHEL の High Availability Add-On のように、OS ベンダの製品としてサポート付きで提供される形態があります。
選定で比較すべきは、ライセンス費だけではなく、対応構成が製品として検証されているか、運用体制に合うか、障害時の責任分界がどうなるかです。「技術的にできるか」と「業務システムとして採用できるか」は別の問いです。
5. 「起動し直す」側の問題
ここで、冒頭の結論の前半に戻ります。クラスタは「残った側で起動し直す」仕組みでした。この「起動し直す」にも固有の問題があります。
5-1. クラスタウェアは、アプリの起動方法を知らない
実際の構築作業で最も時間を使うのが、この部分です。
クラスタウェアは汎用的な仕組みです。これから載せる業務アプリケーションが何であるか、何も知りません。どうやって起動するのか、どうやって止めるのか、正常に動いているとはどういう状態なのか —— すべて知りません。
したがって、それを教えるのが設定作業の実体です。教える内容は 3 つあります。
【製品例】Pacemaker ではリソースエージェントと呼ばれるスクリプトに
start/stop/monitorの処理を実装します(主要なミドルウェア向けには既製のものが用意されています)。CLUSTERPRO X ではスクリプトリソースとして起動スクリプトと停止スクリプトを記述し、監視は監視リソースとして設定します。WSFC は Windows サービスとして動くものであれば汎用サービスリソースで扱えます。名前と形式は違いますが、「起動・停止・監視の 3 つを教える」という構造はどれも同じです。
書くときの注意点が 2 つあります。
冪等(べきとう)であること —— すでに起動しているものに起動処理を呼ばれても、エラーではなく成功を返す。すでに止まっているものに停止処理を呼ばれても、成功を返す。クラスタウェアは状態が不明なときに念のため呼ぶことがあるため、「二度呼ばれても壊れない」作りが要求されます。
起動処理は「起動した」ではなく「使えるようになった」まで待つこと —— プロセスを起動しただけで成功を返すと、まだ受付準備中のサービスに対して次のリソースが起動され、依存関係が壊れます。データベースであれば、接続を受け付ける状態になったことまで確認して返す必要があります。
なお、リソースには起動順序の依存関係があります(ディスクをマウント → VIP を付与 → ミドルウェア起動 → 業務アプリ起動)。停止時はこの逆順です。この依存関係の記述方法は製品ごとの差が最も大きい部分なので、実案件では該当製品のマニュアルにあたってください。
5-2. 停止に失敗すると、何が起きるか
停止処理には、起動処理にはない特殊な重みがあります。ここは 4 章と直結します。
クラスタウェアにとって、「止められなかった」は「止まったか分からない」と同義です。
止まったか分からないノードにサービスを引き継がせるわけにはいきません。VIP を二重に持ち、共有ディスクを二重にマウントする —— スプリットブレインそのものだからです。
では、どうするか。確実に止める手段は、もう一つありました。
製品や設定によっては、アプリケーションの停止に失敗しただけで、サーバの電源が落ちます。 実際にどこまで進むかは、リソースの失敗時ポリシー、再試行回数、フェンシングの構成によって変わります。ただし**「アプリを止められないことが、ノード全体の強制停止につながり得る」**という因果関係は押さえておく価値があります。4 章の原則がここでも貫かれています —— 状態が不確実なら、データ保全を優先する。
このため、停止処理の設計は起動処理より神経を使います。
- 停止タイムアウトを短くしすぎない。 大きなデータベースの正常停止には時間がかかります。まだ止まっている最中なのにタイムアウトと判定されると、不必要にノードが強制停止されます
- 停止処理は「必ず止まる」ように書く。 正常停止を試み、それでも残っているなら強制終了する、といった段階的な作りが基本です
5-3. OS の自動起動は、無効にする
通常、業務サービスは OS 起動時に自動的に立ち上がるよう設定します。ところがクラスタ配下に置くサービスでは、この自動起動を無効にする必要があります。
理由は単純で、サービスの起動・停止を決めるのはクラスタウェアだからです。OS が勝手に起動してしまうと、クラスタウェアの管理外でサービスが動き出します。待機系のはずのノードで、OS 再起動をきっかけにサービスが起動する —— そして稼働系でも動いている。共有ディスクを使っていればデータが壊れます。
「クラスタ配下のリソースは、クラスタウェアだけが起動・停止する」 —— この原則を崩さないことが重要です。裏返せば、運用担当者が手動でサービスを停止するのも同じ理由で危険です。クラスタウェアは「異常停止した」と判断してフェイルオーバーを始めます。保守作業でサービスを止めるときは、クラスタウェアの機能(メンテナンスモード等)を使う必要があります。
5-4. 監視処理をどう書くか
3-2 で「監視には 3 つのレイヤがある」と書きました。そのレイヤを実際に決めるのが、この監視処理です。
- プロセスの存在確認 —— 実装は簡単。ただしハング状態は検知できない
- 応答確認 —— 実際にリクエストを投げ、応答を確認する。検知力は高いが、負荷時の誤検知リスクが上がる
- 業務レベルの確認 —— 特定のテーブルに問い合わせる等。最も確実だが、監視自体が負荷になり、監視の失敗要因も増える
深くすれば止まらない障害を拾えるが、誤検知でサービスを止めるリスクが上がる。 どちらに倒すかは業務要件次第であり、技術的な正解はありません。だからこそ設計判断として明示的に決め、記録に残す必要があります。
もう一つ、監視処理が異常を返したとき何をするかも設定項目です。
- 何もしない(通知だけ)
- そのサービスだけ再起動を試みる
- フェイルオーバーする
- ノードごと強制停止する
いきなりフェイルオーバーさせるのではなく、まず同一ノードでの再起動を数回試みる設定が一般的です。切り替えは高コストな操作なので、その場で直るなら直した方がよい。ただし再試行回数を増やせば、その分だけ復旧が遅れます。
5-5. フェイルオーバーは失敗しうる
フェイルオーバーとは、要するに待機系での「起動」です。 起動は失敗することがあります。
- 待機系のミドルウェア設定が稼働系と異なっていた
- 待機系に必要なライセンスが入っていなかった
- OS のパッチレベルが乖離していて、アプリが起動しない
- 前回の異常停止でファイルシステムに不整合が残り、マウントに失敗した
稼働系と待機系は、時間とともに乖離していきます。 稼働系にだけ緊急パッチを当てた、稼働系にだけ設定を変えた —— こうした差分が積み重なり、いざという時に切り替わらない。
5-6. ダウンタイムはゼロにならない
フェイルオーバーに要する時間を分解します。
どの工程が支配的になるかは構成によって変わります。 障害検知の猶予時間、フェンシングの実行と再試行、ストレージの再認識、データベースのクラッシュリカバリ —— いずれも切替時間に大きく影響します。特にデータベースは、データ量やトランザクション量によって起動時間が大きく変動します。
したがって、「クラスタを入れたので無停止です」は誤りです。正しくは、**「検知・切り離し・再起動に要する時間だけ停止し、条件が整えば自動で復旧する仕組み」**です。
そして、具体的な停止時間を口にするなら、それは設計と障害試験の実測値に基づかなければなりません。 1 章で触れた RTO は、ここで実測値と突き合わされます。無停止を求められているなら、そもそも HA クラスタは要件を満たしません。
5-7. 切り替わった後の話 —— 再参加とフェイルバック
フェイルオーバーが成功しても、そこで運用が終わるわけではありません。この点は見落とされがちです。
- 障害ノードをどこまで復旧させるか
- いつクラスタへ再参加させるか
- 元のノードへ戻すのか、戻さないのか
- 自動フェイルバックを許可するか
最後の項目が要注意です。自動フェイルバックは便利に見えますが、復旧直後の不安定なノードへサービスを戻してしまうリスクがあります。 ハードウェアを交換した直後のサーバは、まだ十分に検証されていません。そこへ自動的に業務が戻り、再び障害を起こす —— という事態は起こり得ます。
このため、自動フェイルバックを無効にし、計画的な作業として手動で戻す運用が選ばれることは珍しくありません。どちらが正しいという話ではなく、明示的に決めて記録しておくべき設計判断です。「デフォルトのままだった」が最も危険です。
6. クラスタを入れたのに止まる、3 つのパターン
ここまでの内容を、事故の形で整理します。
注記: 以下は、起こり得る事象を理解しやすいよう単純化・再構成したシナリオです。特定の案件や製品における実際の事故をそのまま記載したものではありません。
事故 1:保守作業でスイッチを再起動したら、データが壊れた
現象
ネットワークスイッチをファームウェア更新のため再起動した。その後、共有ディスク上のデータベースが破損し、起動しなくなっていた。
原因
ハートビートがそのスイッチ 1 台だけを経由していた。スイッチ停止中、両ノードは相手が死んだと判断。両方が稼働状態になり、共有ディスクへ同時書き込みが発生した。典型的なスプリットブレインである。
本来どうすべきだったか
- ハートビート経路を冗長化し、単一機器の停止で全経路が失われないようにする
- 第三の投票者やフェンシングを設定し、経路全損時でも両系稼働にならないようにする
- ハートビート経路上の機器を停止する作業は、クラスタにとって障害と同じである。作業前にクラスタを停止するか、影響を評価しておく
事故 2:片系が壊れたのに、切り替わらずシステム全停止
現象
稼働系のサーバが故障。しかし待機系は引き継がず、システムは停止したまま。待機系のハードウェアは正常だった。
原因
フェンシング用の管理 LAN(BMC への経路)が、業務 LAN と同じスイッチ配下に収容されていた。障害でそのスイッチも巻き込まれ、待機系は稼働系を強制停止できなくなった。相手を確実に止められない以上、データ保護のためフェイルオーバーは実行されない —— クラスタウェアは設計通りに、安全側に倒れた。
本来どうすべきだったか
- フェンシング経路を、業務経路と物理的に独立させる
- フェンシング手段を複数用意する(電源断が失敗したらストレージ側で隔離する、等)
- フェンシング経路の死活も監視対象に含める。 この経路は普段使われないため、壊れていても気づかれない
この事故は理不尽に見えますが、クラスタウェアの判断は一貫しています。「相手が生きているかもしれない状況で引き継げば、データを壊す」—— 停止とデータ破壊なら、停止を選ぶ。設計思想として、可用性よりデータ保全が優先されるわけです。
事故 3:切り替わったが、業務が動かない
現象
フェイルオーバー自体は成功し、VIP もディスクもサービスも起動した。しかし業務アプリケーションがエラーを返し続けた。
原因
稼働系にのみ適用されていた設定変更・パッチ・ライセンスが待機系に反映されていなかった。運用開始から長期間、待機系は一度も使われず、その間に構成が乖離していた。
本来どうすべきだったか
- 変更作業の手順に、両系への適用と確認を必ず組み込む
- 定期的に計画切替を実施する。 半年に一度でも待機系を実際に稼働させれば、乖離は早期に発見できる。「使われない待機系は、いつの間にか使えなくなっている」と考えた方がよい
7. おわりに
最後に、冒頭の一文に戻ります。
クラスタは「止まらない仕組み」ではない。
壊れた側を切り離し、残った側で起動し直す仕組みである。
「切り離す」の難しさ —— 何が壊れたのかを確実に知る方法はありません。ハートビートが途絶えたとき、相手が死んだのか経路が切れただけなのかは原理的に区別できない。だから多数決を使い、第三者に投票させ、あるいは相手を物理的に止める。クラスタウェアの設定項目の多くは、この解けない問題への対処です。
「起動し直す」の難しさ —— クラスタウェアは、載せるアプリの起動方法も、止め方も、正常の定義も知りません。それを教えるのが構築作業の実体です。そして起動には時間がかかり、失敗もする。止められなければノードごと停止される。待機系は放っておけば稼働系から乖離していく。だから試験と定期的な切替が要ります。
そして、クラスタを入れることは、可用性と引き換えに複雑性を増やす行為でもあります。事故 1 と事故 2 は、どちらもクラスタを組んでいなければ起きなかった事故です。単体サーバなら、スイッチの再起動でデータが壊れることはありませんでした。
だからといってクラスタが無意味なわけではありません。トレードオフを理解した上で使えば、極めて有効な手段です。理解せずに「入れておけば安心」と考えたときに、事故が起きます。
クラスタが守れるのは、クラスタが管理している範囲だけ
最後にもう一点。クラスタウェアが冗長化できるのは、管理対象として定義されたノードとリソースだけです。それ以外に単一障害点が残っていれば、クラスタが完璧に動作していても業務は止まります。
- DNS、認証基盤(名前が引けなければ、サービスが動いていても届きません)
- 上位ネットワーク、ロードバランサ
- 共有ストレージそのもの
- 外部連携先の API やファイル授受先
- 監視基盤、バックアップ
クラスタは可用性設計の一部品です。1 章の RTO / RPO に立ち返れば、守るべきは「業務が使えること」であって、「サーバが動いていること」ではありません。
構成に触れるときの確認ポイント
既存システムのクラスタ構成に触れる機会があったら、以下を確認してみてください。この記事の内容が、具体的な設定として目の前にあるはずです。
- ハートビートは何経路あるか。それらは物理的に独立しているか
- スプリットブレイン対策は何が設定されているか(フェンシングか、第三の投票者か、両方か)
- フェンシング経路は業務経路と分離されているか。その経路自体は監視されているか
- 起動処理・停止処理には何が書かれているか
- 監視は、どのレイヤまで見ているか。プロセスの存在確認だけで終わっていないか
- クラスタ配下のサービスは、OS の自動起動が無効になっているか
- 直近の切替試験はいつ実施されたか。異常系は含まれていたか。切替時間は実測されているか
- 待機系の構成は、稼働系と一致していることが確認されているか
- 自動フェイルバックは有効か無効か。それは意図して決められたものか
- そもそも、このシステムの RTO / RPO は何と合意されているか
- クラスタの管理範囲外に、単一障害点は残っていないか
答えられない項目があれば、そこがそのシステムのリスクが潜んでいる場所かもしれません。
以上