LASSIC Media らしくメディア
Pacemakerとは？自動で切り替わる仕組みと構築・保守を解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Pacemakerは複数のサーバーでサービスを引き継ぐHAクラスタの頭脳の役を担う無料のソフトウェアです。
- 正しい切り替えには、応答しないサーバーを止めるフェンシングと過半数の確認が欠かせません。
- 構築後も版上げが続くため、版上げの方法と切り替え試験を含む保守の体制を最初に決めておきます。
※ 本記事は2026年11月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
サーバーが1台止まっただけで、業務のシステムが丸ごと使えなくなった。待機用のサーバーはあるのに、切り替えは担当者の手作業頼み——。オンプレミスのLinuxサーバーでシステムを動かす現場では、こうした悩みがよく聞かれます。Pacemaker（ペースメーカー）は、複数のサーバーを組にして、1台が止まったら別のサーバーで自動的にサービスを動かし直す、HAクラスタ（高可用性クラスタ）のためのオープンソースのソフトウェアです。
止めたくないデータベースなどを守る場面で使われます。ただし万能ではなく、切り離しの装置や版上げの体制を決めずに入れると、障害時の動きが読めなくなります。本記事では、情報システムの担当者に向けて、Pacemakerの仕組み、障害時の切り替わり方、保守と版上げの体制、そして外部に頼むときに確認したい点を整理します。
目次
Pacemakerとは
公式の手引きは、Pacemakerの目的を、サービスの停止時間を短くしながらデータの整合性を守ることとしています。*3 実際のクラスタは、Pacemakerだけでなく次の部品の組み合わせで成り立っています。
- サービス（リソース）：Webサーバー、データベース、仮想IPアドレスなど、止めたくないもの
- リソースエージェント：サービスの起動・停止・監視を受け持つ部品
- フェンスエージェント：応答しなくなったサーバーを電源やネットワークから切り離す部品
- Corosync（コロシンク）：サーバー同士の通信と、いま誰がクラスタにいるかを伝える層
- Pacemaker：起きたことを受けて、サービスをどのサーバーで動かすかを決める頭脳の役
開発は2004年に始まり、Red HatとSUSEの開発者も加わるClusterLabsのコミュニティで進められています。多くのLinuxディストリビューションに同梱されています。*2 ライセンスはGPLv2以上（ライブラリはLGPLv2.1以上）で、利用料はかかりません。*5 ただし、無料で手に入ることと、障害時に正しく切り替わる構成になることは別の話です。
冗長化の構成との関係
冗長化は、機器やサーバーを二重にして、1つが止まってもサービスを続けられるようにする考え方です。考え方の基本は冗長化とはで扱っています。Pacemakerは、そのうちサーバーの層の切り替えを自動で行う道具です。
| 構成 | 動き方 | 考えどころ |
|---|---|---|
| アクティブ／パッシブ | 1台がサービスを動かし、止まったらもう1台が引き継ぐ | 2台構成でDRBD（ディスクの中身を2台で同期する仕組み）と組み合わせる形が多い |
| N+1 | いくつかのアクティブ／パッシブの組で、予備のサーバー1台を共有する | 予備機を減らしてハードウェアの費用を抑える |
| N-to-N | 共有ストレージがあれば、どのサーバーでも引き継げる。サービスを複数のサーバーで同時に動かすこともできる | 負荷を分けられる一方、構成は複雑になる |
公式の手引きは、PacemakerとDRBDを使う2台以上のアクティブ／パッシブ構成を、多くの場面で費用対効果の高い選択肢としています。*3 1台の中で起動を管理するsystemdと違い、クラスタは全サーバーの状態を把握しているため、サーバー単位の障害からも立て直せます。*1 「データベースの起動後にアプリを起動する」といった、サービスどうしの順番も決められます。
障害時に切り替わる仕組み
Pacemakerの切り替えで欠かせないのが、フェンシング（STONITHとも呼ぶ）です。応答しなくなったサーバーを、電源を切れる装置やネットワークを遮断できる装置で止める仕組みで、公式の手引きは、これが無いと応答しないサーバーからの復旧を正しく行えない場合があるとしています。*3 通信が途切れたサーバーが同じサービスをそれぞれ立ち上げると、データが壊れるおそれがあります。*1
- クォーラム（過半数の確認）：クラスタが通信できないグループに分かれたとき、全体の半数を超えるサーバーがそろう側だけがサービスを動かせます
- 5台が3台と2台に分かれた場合は、3台の側がサービスを続けます*3
- 6台が3台ずつに分かれると、どちらも過半数に届かず、既定ではすべてのサービスを止めます
- 2台構成で互いに通信できなくなった場合は、それぞれが相手の切り離しを試み、成功するまではどちらもサービスを動かしません
設計で見落としやすいのが、切り離しに使う装置の選び方です。サーバーに内蔵された管理用のボード（IPMI）が本体と電源を共有していると、電源の障害で本体と装置が同時に止まり、クラスタは復旧できずにすべてのサービスを止めます。*3
保守と版上げの体制
Pacemakerは、構築後もOSの更新に合わせた版上げが続きます。版番号はx.y.zの3つの数字で、先頭の数字が上がるときは、前の版から1台ずつの版上げができない場合があります。*4 版上げの方法は3つあり、止まる時間と手間が違います。
| 方法 | サービスへの影響 | 考えどころ |
|---|---|---|
| 全体を止めて上げる | 版上げの間はサービスが止まる | どの版の間でも使える。新しいサーバーに新しいクラスタを作って切り替える形もある |
| 1台ずつ上げる | サービスを別のサーバーへ移すため短い停止は起きる。稼働中のまま移せるサービスなら止まらない | どの版の間でも使えるわけではない。切り替えの動きを本番で確かめる機会にもなる |
| 管理を外して上げる | サービスは動かしたまま。止まるのは障害が起きたときだけ | 版上げの間に障害が起きても自動では立て直さない |
1台ずつ上げる場合、3系の版を入れるには、ほかのサーバーが2.0.0以上である必要があります。*4 また、Red HatのRHEL High Availabilityでは、フェンシングを無効にした構成や、切り離しの装置が割り当てられていないサーバーがある構成はサポートの対象外です。*6 保守の体制は、版上げの周期とOSの提供元のサポート条件の両方から決めておきます。
外部に頼むときに確認しておきたい点
Pacemakerは手引きが公開されており、自社で組むこともできます。ただ、切り離しの装置の選び方や切り替え試験は経験の差が出やすい部分です。外部に頼むときは、見積もりの前に次の点を確かめておきます。
- どこまで頼むか：設計、構築、切り替え試験、手順書づくり、版上げを含む保守のうち、どれを任せるか
- 切り離しの方法：どの装置でサーバーを止めるか。その装置が本体と同時に止まらないか
- 切り替え試験：サーバーの停止、ネットワークの断、サービスの異常のどれを、本番の前に試すか
- 版上げの計画：OSの更新の周期に合わせて、どの方法で、誰が、いつ版を上げるか
- サポート条件：OSの提供元のサポートを受けられる構成になっているか
切り替え試験は、構築の最後に一度だけ行って終わりにしやすい点です。保守の契約に試験の手順を含めておくと、障害時の動きを読みやすくなります。災害対策まで含めた設計は可用性・DR(災害対策)設計を外注で進めるにまとめています。
まとめ：Pacemakerで確かめておきたい3つの点
PacemakerでHAクラスタを組むうえで、確かめておきたい点は3つに整理できます。第一に、守りたいサービスと構成を決めること。第二に、切り離しの装置を、本体と同時に止まらない形で用意すること。第三に、版上げの方法と切り替え試験の手順を、保守の体制として最初に決めておくことです。この3点を踏まえておけば、「クラスタを組んだのに、障害時に切り替わらなかった」という事態を避けやすくなります。設計や保守に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
サーバー2台だけでもクラスタを組めますか
組めます。2台構成では、通信に使うCorosyncが1台だけで過半数とみなす設定を持っています。*3 ただし、2台が互いに通信できなくなったときに正しく切り替えるには、切り離しの装置の設定が前提になります。
共有ストレージは欠かせませんか
欠かせないものではありません。Pacemakerは共有ストレージを使えますが、無くても動きます。*3 共有ストレージを使わない場合は、DRBDで2台のディスクの中身を同期する形があります。
クラウドの仮想マシンでも使えますか
使えます。Red HatのRHEL High Availabilityのサポート方針には、AWS、Microsoft Azure、Google Cloudなどの仮想マシンをクラスタのサーバーとして使う場合の方針が並んでいます。*7 切り離しの方法はクラウドごとに異なるため、先に確かめておきます。
HAクラスタの構築と保守のご相談
Pacemakerを使ったHAクラスタの設計・構築から、切り替え試験、版上げを含む保守の体制づくりまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：ClusterLabs 公式サイト（トップページ）（https://clusterlabs.org/）。出典：HAクラスタの説明、systemdとの違い、フェンシングが無い場合にデータが壊れるおそれについての記述を参照（2026年11月確認）
- *2 参考：ClusterLabs「Pacemaker」プロジェクトページ（https://clusterlabs.org/projects/pacemaker/）。出典：2004年の開発開始、Red HatとSUSEの開発者の参加、多くのLinuxディストリビューションへの同梱、起動の順番と同居の条件の指定についての記述を参照（2026年11月確認）
- *3 参考：ClusterLabs「Clusters from Scratch」（Pacemaker 3.0）（https://clusterlabs.org/projects/pacemaker/doc/3.0/Clusters_from_Scratch/singlehtml/）。出典：Pacemakerの定義と構成部品、フェンシング、構成の種類、クォーラム、2台構成の扱い、IPMIを切り離しに使うときの注意、共有ストレージの扱いの記述を参照（2026年11月確認）
- *4 参考：ClusterLabs「Pacemaker Administration」（Pacemaker 3.0）（https://clusterlabs.org/projects/pacemaker/doc/3.0/Pacemaker_Administration/singlehtml/）。出典：10章「Upgrading a Pacemaker Cluster」の版番号の意味、3つの版上げの方法、版の互換表を参照（2026年11月確認）
- *5 参考：ClusterLabs/pacemaker（GitHub）（https://github.com/ClusterLabs/pacemaker）。出典：リポジトリのCOPYINGに記載のライセンス（GPLv2以上・LGPLv2.1以上）を参照（2026年11月確認）
- *6 参考：Red Hat「Support Policies for RHEL High Availability Clusters – General Requirements for Fencing/STONITH」（https://access.redhat.com/articles/2881341）。出典：フェンシングを有効にすること、すべてのサーバーに切り離しの装置を割り当てることをサポートの条件とする記述を参照（2026年11月確認）
- *7 参考：Red Hat「Support Policies for RHEL High Availability Clusters」（https://access.redhat.com/articles/2912891）。出典：AWS・Microsoft Azure・Google Cloudなどの仮想マシンをクラスタのサーバーとする場合の方針の一覧を参照（2026年11月確認）
