株式会社グローバルゲート公式ブログ
DRBD + Pacemakerで実現する高可用性構成：実践で学ぶHAクラスター構築手順【後編】
こんにちは！株式会社グローバルゲートでサーバ管理をしてるタカです。
これまで「firewalldを使わずiptablesを選ぶ理由」から始まり、Linuxサーバにおけるネットワーク制御の本質、そして実務で求められるFirewallおよびルーター構築の考え方について解説してきました。さらに前回の「準備編」では、高可用性（HA）構成を実現するための設計思想に踏み込み、単なる冗長化に留まらない“止めないシステム”を作るための前提条件や構成のポイントを整理しました。
サーバ運用において「障害は必ず発生するもの」という前提に立ったとき、重要になるのは障害を完全に防ぐことではなく、「障害が発生してもサービスを継続できる仕組み」をいかに構築するかという点です。ディスク障害、ネットワーク断、ハードウェアトラブルなど、現場ではさまざまな要因によってシステム停止のリスクが常に存在します。
その中で、サービス停止時間を最小限に抑えるための手段として、高可用性クラスタは非常に重要な役割を果たします。
今回の実践編では、前編で整理した設計をもとに、実際に「DRBD」と「Pacemaker」を用いたHAクラスター構築を行います。DRBDによるリアルタイムなデータ同期と、Pacemakerによるリソース管理および自動フェイルオーバー制御を組み合わせることで、2台構成のサーバでも高い可用性を実現することが可能です。本記事では、単なる手順の紹介にとどまらず、実務でつまずきやすいポイントや設計時に意識すべき考え方にも触れながら、実際に“動くHA構成”を構築していきます。
また、構築後のフェイルオーバーテストや運用時の注意点についても解説し、「作って終わり」ではなく「安定して使い続ける」ための視点を重視しています。これからHA構成を導入しようとしている方はもちろん、既存環境の見直しを検討している方にとっても、実践的なヒントとなる内容を目指してるので、設計から一歩踏み込み実際の構築フェーズへ進んでいきましょう。
ここからは、理論ではなく手を動かす技術としてのHA構成を体験していきます。
1. はじめに：いよいよHAクラスターを構築する
いよいよ実践編として、実際にHAクラスターを構築していきます。本記事では、OSにRocky Linux 9を使用し、2台のサーバを用いたシンプルな構成で、高可用性を実現する環境を作り上げます。できるだけ初心者の方でも理解しやすいように、専門用語は丁寧に解説しながら進めていきますので、初めてHA構成に触れる方も安心して読み進めてください。
HAクラスターとは、複数のサーバを連携させることで、どちらか一方に障害が発生してもサービスを継続できる仕組みです。例えば、Webサーバやメールサーバなど、停止が許されないシステムにおいては、このような構成が非常に重要になります。本記事で構築する環境では、「DRBD」によるディスクデータのリアルタイム同期と、「Pacemaker」によるサービスの監視・制御を組み合わせることで、片方のサーバが停止した際に、もう一方へ自動的に処理を引き継ぐ仕組みを実現します。
一見すると難しそうに感じるかもしれませんが、仕組み自体は「データを同期する」「サービスを監視する」「障害時に切り替える」というシンプルな考え方の組み合わせです。本記事では、その流れを一つひとつ分解しながら、実際に手を動かして構築できるレベルまで落とし込んで解説していきます。
また、単に構築手順を追うだけでなく、「なぜその設定が必要なのか」「どこでつまずきやすいのか」といった実務視点でのポイントも随所に盛り込んでいます。これにより、単なる検証環境ではなく、実際の運用にも応用できる知識として身につけることができるでしょう。
本記事では、Rocky Linux 9を使用した2ノード構成のHAクラスターを構築します。各ノードは以下のホスト名で構成しています
2. 構築前の最終チェック：環境と前提条件の確認
HAクラスターの構築において、最も重要なのは「事前準備」です。DRBDやPacemakerの設定自体は手順通りに進めれば構築できますが、前提条件が整っていない状態で作業を進めてしまうと、原因不明のエラーや不安定な動作につながることが少なくありません。本章では、Rocky Linux 9を用いたHAクラスター構築において、事前に必ず確認しておくべきポイントを整理していきます。
まず、今回の構成は「2台構成のサーバ（プライマリ／セカンダリ）」を前提としています。それぞれのサーバには同一のスペックを用意し、ディスク構成やパーティションも可能な限り揃えておくことが重要です。DRBDはブロックデバイス単位で同期を行うため、デバイスサイズが異なると正常に動作しない場合があります。
次に、ネットワーク設定です。本構成では、最低でも以下の2つのネットワークを用意します。
・管理用ネットワーク（クライアントアクセス・SSH接続）
・同期用ネットワーク（DRBDレプリケーション専用）
同期トラフィックと通常通信を分離することで、パフォーマンスと安定性を確保できます。IPアドレスやホスト名はあらかじめ固定しておき、/etc/hostsにも両ノードの情報を登録しておきましょう。
また、クラスタ構成ではノード間の時刻ズレが大きな問題を引き起こすため、NTPによる時刻同期も必須です。Rocky Linux 9ではchronyが標準で利用できるため、以下のように設定・確認を行います。
ファイアウォールについては、本記事ではfirewalldは使用せず、iptablesによる制御を前提とします。PacemakerやCorosyncは特定のポートを使用するため、必要な通信を許可しておく必要があります。最低限、以下のポートを開放しておきましょう。
・5404, 5405（Corosync）
・7789（DRBD）
さらに、SELinuxの設定も事前に確認しておきます。検証環境では一時的に無効化することもありますが、本番環境では適切なポリシー設定を行うことが望ましいです。
最後に、ホスト名の設定と名前解決の確認です。Pacemakerはノード名をもとにクラスタを構成するため、hostnameコマンドで設定した内容と名前解決結果が一致している必要があります。
ここまでの準備が整っていれば、HAクラスター構築の土台は完成です。次章からはいよいよ、DRBDによるデータ同期の設定に進んでいきます。焦らず一つひとつ確認しながら進めていきましょう。
3. DRBDの構築：リアルタイムデータ同期の実装
ここからは、HAクラスターの中核となる「データ同期」の仕組みを構築していきます。本章では、2台のサーバ間でディスクデータをリアルタイムに同期するためのソフトウェア「DRBD（Distributed Replicated Block Device）」を導入します。DRBDはネットワーク越しにブロックデバイスをミラーリングする技術で、いわば“ネットワークRAID1”のような役割を果たします。
まずは、両ノードにDRBDをインストールします。Rocky Linux 9では、EPELリポジトリを利用してインストールします。
インストールが完了したら、同期に使用するディスク領域を準備します。今回は例として「/dev/sdb」をDRBD用デバイスとして使用します。パーティションを作成し、ファイルシステムは作成せずにそのまま使用します。
次に、DRBDの設定ファイルを作成します。設定ファイルは「/etc/drbd.d/r0.res」として作成します。
内容は以下の通りです。
ここでのポイントは、「protocol C」を指定している点です。これは同期書き込みモードを意味し、両ノードにデータが書き込まれて初めて完了とみなされるため、データ整合性が非常に高くなります。
設定が完了したら、DRBDリソースを作成します。
初回のみ、どちらか一方のノードをPrimaryとして昇格させ、初期同期を開始します。
同期状況は以下のコマンドで確認できます。
または
同期が完了すると、両ノードの状態が「UpToDate」となります。
Primaryノードでは、このDRBDデバイスにファイルシステムを作成します。
この時点で、DRBDによるデータ同期の基盤は完成です。以降は、このデバイスをPacemakerから制御し、サービスのフェイルオーバーに組み込んでいきます。
DRBDの構築は一見複雑に見えますが、「ディスクを共有しているように見せる」というシンプルな役割を担っています。この仕組みを理解しておくことで、後続のPacemaker設定もスムーズに理解できるようになります。
次章では、このDRBDリソースを実際にクラスタで制御するために、PacemakerとCorosyncの設定に進んでいきます。
4. Pacemaker + Corosyncの導入とクラスタ構成
ここからは、HAクラスターの制御を担う「Pacemaker」と「Corosync」を導入し、クラスタの基本構成を作成していきます。前章で構築したDRBDはデータを同期する役割でしたが、Pacemakerは「どのサーバでサービスを動かすか」を制御し、Corosyncはノード間の状態を監視・通信する役割を担います。この2つを組み合わせることで、障害発生時に自動的にサービスを切り替えるHA構成が実現できます。
まずは、両ノードに必要なパッケージをインストールします。
インストール後、クラスタ管理用のユーザー「hacluster」のパスワードを設定します。このユーザーは、ノード間の認証やクラスタ操作に使用されます。
次に、pcsサービスを起動し、自動起動を有効にします。
ここまで完了したら、両ノード間で認証を行います。以下のコマンドは、どちらか一方のノードから実行します。
認証が成功すると、クラスタ構築の準備が整います。続いて、クラスタを作成します。
クラスタを起動し、自動起動設定も行います。
クラスタの状態は以下のコマンドで確認できます。
正常に構成されていれば、両ノードが「Online」と表示されます。
次に、クラスタの基本設定として「STONITH（フェンシング）」を一時的に無効化します。検証環境では簡略化のため無効にしますが、本番環境では必ず設定が必要です。
さらに、クォーラムポリシーも調整します。2ノード構成ではクォーラムを満たせないケースがあるため、以下の設定を行います。
これで、Pacemaker + Corosyncによるクラスタの基本構成が完成しました。ここまでで「ノード同士が状態を監視し合い、制御できる状態」が整っています。
現時点では、まだサービスは何も動作していませんが、次章ではいよいよDRBDリソースやファイルシステム、仮想IPなどをクラスタに登録し、実際にサービスを制御できる状態へと進めていきます。
Pacemakerの設定は一見難しそうに見えますが、「どのリソースをどのノードで動かすか」というシンプルなルールの積み重ねです。この考え方を意識しながら進めることで、より柔軟で安定したHA構成を構築することができます。
5. リソース制御の設定：サービスをクラスタで管理する
前章では、PacemakerとCorosyncを導入し、HAクラスターとしての基本構成を作成しました。しかし、この時点ではまだ「クラスタが動いているだけ」の状態であり、実際にサービスは制御されていません。本章では、DRBDやファイルシステム、仮想IPアドレス（VIP）、ApacheなどのサービスをPacemakerへ登録し、障害時に自動で切り替わるHA構成を完成させていきます。
まず最初に、DRBDリソースをPacemakerへ登録します。
続いて、このDRBDリソースをMaster/Slave構成として管理できるよう設定します。
これにより、片方のノードのみがPrimaryとして動作し、もう片方はSecondaryとして待機する状態になります。
次に、DRBDデバイス上に作成したファイルシステムをクラスタ管理へ登録します。
ここでは、「/dev/drbd0」を「/data」へマウントしています。事前にマウントポイントを作成しておきましょう。
続いて、クライアントがアクセスするための仮想IP（VIP）を登録します。このIPアドレスは、障害時に自動的に待機ノードへ移動します。
さらに、Apacheサービスもクラスタ管理下へ登録します。
ここまでで、DRBD、ファイルシステム、VIP、Apacheの各リソースが登録されました。しかし、このままでは起動順序が保証されていないため、依存関係を設定する必要があります。
例えば、Apacheはファイルシステムがマウントされていなければ正常に起動できません。また、ファイルシステムはDRBDがPrimaryになっていなければ利用できません。
そのため、以下のように起動順序を設定します。
さらに、各リソースが同じノード上で動作するよう、colocation設定も追加します。
設定後は、現在のクラスタ状態を確認します。
正常に設定されていれば、Primaryノード側でDRBD、Filesystem、VIP、Apacheが起動していることを確認できます。
ここまで設定できれば、HAクラスターとしての基本機能はほぼ完成です。障害発生時には、Pacemakerがサービス停止を検知し、自動的に待機ノードへリソースを移動させます。
6. フェイルオーバーテスト：障害時の挙動を検証する
ここまでの章では、DRBDによるデータ同期、Pacemaker + Corosyncによるクラスタ構成、そして各種リソースの管理設定までを行ってきました。本章では、いよいよHAクラスターの最も重要な機能である「フェイルオーバー」の動作確認を行います。
フェイルオーバーとは、現在サービスを提供しているサーバに障害が発生した際、自動的に待機系サーバへ処理を引き継ぐ仕組みです。HA構成の目的は「障害を防ぐこと」ではなく、「障害が起きてもサービスを継続すること」にあります。そのため、実際に障害を想定したテストを行うことは非常に重要です。
まずは、現在どちらのノードでサービスが動作しているかを確認します。
正常な状態では、Primaryノード側で以下のリソースが動作しています。
・DRBD（Primary）
・Filesystem
・VIP
・Apache（httpd）
次に、クライアント側から仮想IPへアクセスできることを確認します。
Apacheのテストページなどが表示されれば正常です。
それでは、実際に障害を発生させてみましょう。今回は検証として、PrimaryノードのPacemakerサービスを停止します。
あるいは、より実践的なテストとして、サーバ自体をシャットダウンしても構いません。
障害が発生すると、Corosyncがノードダウンを検知し、Pacemakerが待機ノードへのリソース移動を開始します。
数十秒後、待機ノード側で以下が自動的に実行されます。
・DRBDのPrimary昇格
・Filesystemのマウント
・VIPの引き継ぎ
・Apacheサービス起動
再度クラスタ状態を確認してみましょう。
今度はSecondaryだったノード側で、すべてのリソースが起動していることが確認できます。
さらに、クライアント側から再びVIPへアクセスします。
障害発生後も正常にWebページが表示されれば、フェイルオーバー成功です。ユーザー側から見ると、サーバが切り替わったことをほとんど意識せずにサービスを利用し続けることができます。
ただし、HA構成では「split-brain（スプリットブレイン）」と呼ばれる状態に注意が必要です。これは、ネットワーク分断などにより両ノードが自分をPrimaryと誤認識してしまう状態で、データ不整合の原因となります。
そのため、本番環境ではSTONITH（フェンシング）を適切に設定し、異常ノードを強制停止できる構成が重要になります。本記事では初心者向け構成として簡略化していますが、実運用では必須となるポイントです。
フェイルオーバーテストは、「構築したつもり」の状態から「本当に動作するHA環境」へ進むための重要な工程です。実際に障害を起こし、クラスタの挙動を確認することで、初めて高可用性構成の価値を体験できます。
次章では、安定運用を続けるために必要な監視やメンテナンス、運用時の注意点について解説していきます。
7. 運用設計のポイント：安定運用のために必要なこと
ここまでの章では、DRBDによるデータ同期、Pacemaker + Corosyncによるクラスタ制御、そしてフェイルオーバーテストまでを行い、HAクラスターとしての基本構成を完成させました。しかし、HA構成は「構築して終わり」ではありません。実際の運用では、監視やメンテナンス、障害時の対応方法まで含めて設計しておくことが重要です。本章では、HAクラスターを安定して運用するために必要なポイントについて解説していきます。
まず重要なのが「監視」です。Pacemakerは自動でリソース監視を行っていますが、管理者側でも現在の状態を定期的に確認できるようにしておく必要があります。
最も基本となる確認コマンドは以下です。
また、リアルタイムでクラスタ状態を監視したい場合は、以下のコマンドが便利です。
クラスタ障害やリソース停止が発生した際には、ログ確認も非常に重要になります。PacemakerやCorosync関連のログは、Rocky Linux 9ではjournalctlから確認できます。
障害時には、「どのタイミングでノードダウンを検知したのか」「なぜリソース移動が発生したのか」をログから読み取ることができます。
次に重要なのが、「STONITH（フェンシング）」です。本シリーズでは初心者向け検証構成として無効化していましたが、本番環境では必須となる機能です。
STONITHとは、異常ノードを強制的に停止させる仕組みで、split-brain対策として非常に重要です。例えば、片方のノードが応答不能になった場合でも、完全停止させることでデータ不整合を防ぎます。
検証環境では以下のように無効化していました。
しかし、本番運用ではIPMIやiLOなどを利用し、STONITHデバイスを構成することが推奨されます。
さらに、定期的なメンテナンス方法も理解しておく必要があります。例えば、片方のノードをメンテナンスする際は、事前にリソースを安全に移動させてから作業を行います。
これにより、Pacemakerが自動的にリソースを待機ノードへ移動します。
メンテナンス完了後は、以下のコマンドで復帰させます。
また、DRBDの同期状態についても定期的な確認が重要です。
状態が「UpToDate」になっているかを確認しましょう。
HAクラスターは、一度構築すると非常に強力な仕組みですが、「自動化されているから安心」ではなく、「常に状態を把握できる運用」が重要になります。特に本番環境では、監視・ログ確認・フェンシング・定期点検を組み合わせることで、初めて“止まらないシステム”として安定運用が可能になります。
次章では、本シリーズのまとめとして、DRBD + Pacemaker構成のメリットや注意点、そして今後の発展的な活用方法について整理していきます。
まとめ：実践構築から見えたHA設計の本質
本シリーズでは、DRBDとPacemakerを利用したHAクラスター構築について、準備編から実践編まで段階的に解説してきました。最初は難しく感じられたかもしれませんが、一つひとつ役割を整理しながら構築を進めることで、「高可用性」という仕組みが決して特別なものではなく、論理的な技術の組み合わせによって実現されていることを体験できたのではないでしょうか。
今回構築したHAクラスターでは、DRBDによるリアルタイムデータ同期、Pacemakerによるリソース管理、Corosyncによるノード監視を組み合わせることで、障害発生時でもサービスを継続できる環境を実現しました。単にサーバを冗長化するだけではなく、「障害を前提として設計する」という考え方こそが、HA構成において最も重要なポイントです。
特に実際にフェイルオーバーテストを行うことで、「障害が起きても自動で待機ノードへ切り替わる」というHA構成の価値を、より具体的に理解できたのではないでしょうか。ユーザーから見ればサービスが継続しているように見えても、その裏側ではDRBD、Pacemaker、Corosyncが連携しながら、複雑な制御をリアルタイムで行っています。
また、本記事では初心者向けにシンプルな2ノード構成で解説しましたが、実際の現場ではさらに高度な構成が採用されることもあります。例えば、STONITHによるフェンシング、複数拠点間でのレプリケーション、監視システムとの連携、仮想化基盤との統合など、HA技術はさまざまな形で発展しています。
しかし、どれだけ高度な構成になったとしても、本質は変わりません。
・データを安全に保持する
・障害を素早く検知する
・サービスを継続する
この3つを実現するために、各技術が役割分担しているのです。
近年では、企業システムだけでなく、ファイルサーバやバックアップ環境などにおいても「止まらない仕組み」が強く求められるようになっています。特に、業務データを扱うNAS環境では、万が一の障害時にも継続利用できる設計が重要になります。
弊社が提供しているGSV（NAS）サービスにおいても、このようなHA技術の考え方を取り入れながら、安定したサービス提供を行っています。表面的には「普通に使えるNAS」に見えても、その裏側では、障害時にもデータやサービスを継続できるよう、冗長化や可用性を意識した設計が支えています。
HA構成は、一見すると難易度の高い分野に見えるかもしれません。しかし、実際には「止めないためにどう設計するか」を考える技術です。本シリーズを通して、その考え方や構築の流れを少しでも身近に感じていただけたなら幸いです。
これからHA構成に挑戦する方も、既存環境を見直したい方も、ぜひ実際に手を動かしながら、止まらないシステムづくりを体験してみてください。
GSVは企業の大切なデータを守る安全なNASサーバーシステムです。自動バックアップやRAID構成による多重保存で、データの消失リスクを最小限に抑えます。ネットワーク接続だけで社内外から安全にデータにアクセス可能で、異なるOS間でもスムーズな運用が可能です。
スケジュール管理やToDoリストの一元管理機能を備え、チームの業務効率化を支援します。契約期間中の無償アップデートで常に最新機能を利用可能です。
さらに、無停電電源装置（UPS）の標準装備、ウイルス検知システム、柔軟なアクセス制限により、物理的な障害やセキュリティリスクからも企業データを保護。GSVは安全で効率的なデータ管理環境を提供します。
【関連記事】
