株式会社グローバルゲート公式ブログ
サーバが落ちても止まらない仕組み｜DRBDで作るHAクラスター入門【前編】
近年、Webサービスや業務システムにおいて「止まらないこと」は当たり前の要件となっています。しかし、サーバを1台で運用している場合、ハードウェア障害やOSトラブルなど、ひとたび問題が発生すればサービスは即座に停止してしまいます。バックアップを取得していても、それはあくまで復旧のための手段であり、「停止しない」ことを保証するものではありません。
そこで重要となるのが「HA（High Availability：高可用性）」構成です。複数のサーバを連携させ、万が一の障害時にも自動的にサービスを引き継ぐことで、システム停止のリスクを最小限に抑えることが可能になります。
本記事では、ディスクをリアルタイムで同期する「DRBD」を中心に、PacemakerやCorosyncといったコンポーネントを組み合わせたHAクラスターの基本的な仕組みを、初心者にもわかりやすく解説します。まずは全体像を理解し、「なぜ止まらないサーバが実現できるのか」を一緒に見ていきましょう。
1. サーバが止まると何が起きるのか？
ある日突然、サービスは止まる
どれだけ安定して稼働しているように見えるサーバでも、トラブルは予告なく訪れます。ハードウェア障害、OSの不具合、ネットワークの断絶など、原因はさまざまですが、その結果として起きるのは「サービス停止」です。
例えばWebサイトであればページが表示されなくなり、メールサーバであれば送受信ができなくなります。利用者からすれば、ただ「使えない」という事実だけが残り、その裏で何が起きているかは関係ありません。サーバの停止は、そのままサービスの停止を意味するのです。
売上機会の損失と信頼低下
サービスが停止すると、まず影響を受けるのはビジネスです。ECサイトであれば注文機会の損失、予約システムであれば顧客離れにつながる可能性があります。わずか数分の停止であっても、その間に失われる機会は決して小さくありません。
さらに深刻なのは「信頼の低下」です。一度「このサービスは不安定だ」という印象を持たれてしまうと、ユーザーは簡単には戻ってきません。技術的な問題以上に、ビジネスへの影響は長期的に残ることになります。
運用担当者にのしかかる負担
サーバ停止の影響は、ユーザーだけでなく運用担当者にも及びます。突然のアラート、夜中の呼び出し、原因調査と復旧作業。状況によっては長時間にわたる対応が必要となり、精神的・肉体的な負担は非常に大きなものになります。
特に1台構成のサーバでは、復旧が完了するまでサービスは停止したままです。バックアップからのリストアや設定の再構築など、復旧までの時間がそのままダウンタイムとなり、対応のプレッシャーも増していきます。
バックアップでは防げない「停止」という問題
ここでよくある誤解が「バックアップがあれば安心」という考え方です。確かにバックアップは重要ですが、それはあくまで「データを守る」ための仕組みであり、「サービスを止めない」ための仕組みではありません。
障害発生時には、バックアップからの復旧に時間がかかります。その間、サービスは停止したままとなり、ユーザーへの影響は避けられません。つまり、バックアップだけでは「止まらないシステム」は実現できないのです。
「止まらない仕組み」が求められる理由
こうした背景から、現在のシステム運用においては「いかに早く復旧するか」ではなく、「いかに止めないか」という考え方が重要になっています。そこで登場するのが、サーバを複数台で構成し、障害時にもサービスを継続できる仕組み、すなわちHA（高可用性）構成です。
次章では、この「止まらない仕組み」を実現するための基本的な考え方について、さらに詳しく解説していきます。
2. 1台構成の限界とリスク
単一障害点（SPOF）という大きな問題
サーバを1台で運用している場合、そのサーバはシステム全体の「単一障害点（Single Point of Failure）」となります。つまり、その1台が停止した瞬間に、すべてのサービスが同時に停止してしまうという構造です。
どれだけ高性能なサーバを用意しても、ハードウェアは必ず故障しますし、OSやアプリケーションの不具合も避けることはできません。「今まで問題なく動いていた」という実績は、将来の安定を保証するものではないのです。
冗長性がないことによる即時停止リスク
1台構成の最大の問題は「代替手段が存在しない」ことです。通常時は問題なく稼働していたとしても、ひとたび障害が発生すれば、サービスは即座に停止します。
例えばディスク障害が発生した場合、その時点でデータの読み書きができなくなり、サービスは継続できません。また、電源トラブルやネットワーク断も同様に、復旧するまでサービスは完全に停止した状態が続きます。
このように、冗長性がない環境では「障害＝サービス停止」という非常にシンプルかつ致命的な構図になってしまいます。
復旧時間がそのままダウンタイムになる
1台構成では、障害発生後の復旧作業が完了するまでサービスを再開することができません。原因調査、部品交換、OSの再起動、データの復旧など、すべての工程が完了して初めてサービスが復帰します。
この間、ユーザーはサービスを利用できず、ビジネス的な損失も拡大していきます。復旧に30分かかれば30分、数時間かかればその間すべてがダウンタイムとなるのです。
特に夜間や休日に障害が発生した場合、対応開始までの時間も含めて、影響はさらに長期化する傾向があります。
スケーラビリティと運用の限界
1台構成には、障害対応だけでなく、将来的な拡張性にも限界があります。アクセス増加に対応するためのスケールアップには限界があり、サーバの性能に依存した運用となります。
また、メンテナンス作業を行う場合にも、サービスを停止する必要が出てきます。OSアップデートやハードウェア交換といった作業が、そのままサービス停止に直結してしまうため、運用の自由度が大きく制限されます。
「問題が起きてから対処する」構成の限界
1台構成は、「障害が発生したら復旧する」という前提で成り立っています。しかし、この考え方ではサービス停止を完全に防ぐことはできません。
現在のシステム運用に求められているのは、「障害が起きてもサービスを継続する」ことです。そのためには、あらかじめ障害を前提とした設計、すなわち冗長構成を取り入れる必要があります。
ここまで見てきたように、1台構成のサーバには構造的な限界があります。では、どのようにすればサービスを止めずに運用することができるのでしょうか。
次章では、その解決策となる「HA（高可用性）構成」の基本的な考え方について詳しく解説していきます。
3. サービスを止めないための考え方「HA構成」とは？
「止まったら復旧」から「止めない」へ
これまで多くのシステム運用では、「障害が発生したら復旧する」という考え方が一般的でした。しかし、前章で見てきた通り、この方法ではサービス停止そのものを防ぐことはできません。
そこで重要になるのが、「そもそも止めない仕組みを作る」という発想です。障害が起きることを前提とし、その影響を最小限に抑える設計が求められています。この考え方こそが、現在のインフラ運用におけるスタンダードとなっています。
HA（High Availability）構成とは何か
HA（High Availability：高可用性）構成とは、システムの稼働率を高め、障害発生時でもサービスを継続できるように設計された構成のことを指します。
具体的には、複数のサーバを用意し、常にどちらかがサービスを提供できる状態を維持します。仮に1台が停止した場合でも、もう一方のサーバが自動的に処理を引き継ぐことで、ユーザーへの影響を最小限に抑えることが可能になります。
このように、HA構成は「止まらないサービス」を実現するための基本的な仕組みと言えます。
フェイルオーバーという仕組み
HA構成の中核となるのが「フェイルオーバー」という仕組みです。これは、稼働中のサーバに障害が発生した際に、待機している別のサーバへ自動的に処理を引き継ぐ動作を指します。
例えば、通常は「プライマリ」と呼ばれるサーバがサービスを提供し、「セカンダリ」は待機状態にあります。そしてプライマリに障害が発生すると、セカンダリが即座にサービスを引き継ぎ、ユーザーから見れば“止まっていないように見える”状態を維持します。
この自動切り替えがスムーズに行われることが、HA構成の品質を大きく左右します。
HA構成を支える要素技術
HA構成を実現するためには、単にサーバを複数用意するだけでは不十分です。重要なのは「状態を同期し」「適切に制御する」ための仕組みです。
例えば、以下のような技術が組み合わされます。
・データを同期する仕組み
・サーバの状態を監視する仕組み
・フェイルオーバーを制御する仕組み
これらが連携することで、初めて実用的なHA構成が成立します。本記事で扱うDRBDやPacemaker、Corosyncも、この役割を担う重要なコンポーネントです。
ここまでで、サービスを止めないための基本的な考え方と、HA構成の全体像について理解できたかと思います。
では、実際にどのようにして複数のサーバ間でデータを同期し、同じ状態を維持するのでしょうか。
次章では、その中核となる技術である「DRBD」について、初心者にもわかりやすく解説していきます。
4. DRBDとは何か？ディスクを同期する仕組み
DRBDとは「ディスクをコピーする仕組み」
DRBD（Distributed Replicated Block Device）とは、複数のサーバ間でディスクの内容をリアルタイムに同期するためのソフトウェアです。簡単に言えば、「2台のサーバのディスクを常に同じ状態に保つ仕組み」と考えるとイメージしやすいでしょう。
通常、アプリケーションがデータを書き込むと、その内容はローカルディスクに保存されます。しかしDRBDを利用すると、その書き込み内容がネットワークを通じてもう一方のサーバにも同時に反映されます。これにより、2台のサーバは常に同じデータを持つ状態を維持することができます。
なぜディスク同期が重要なのか
HA構成において重要なのは、「どちらのサーバでも同じサービスを提供できる状態にしておくこと」です。そのためには、アプリケーションの設定だけでなく、データそのものも完全に一致している必要があります。
例えば、Webサーバであればコンテンツデータ、データベースであればトランザクションデータが該当します。もしデータが同期されていなければ、フェイルオーバー時に不整合が発生し、サービスの継続が困難になります。
DRBDはこの問題を解決し、「どちらのサーバでも同じデータを使える状態」を実現するための重要な役割を担っています。
リアルタイム同期の仕組み
DRBDの大きな特徴は「リアルタイム同期」です。これは、データの書き込みと同時にもう一方のサーバへデータを転送する仕組みです。
具体的には、アプリケーションがディスクへ書き込みを行う際、そのデータはまずDRBDによってキャッチされ、ネットワーク経由で相手側サーバへ送信されます。そして両方のサーバで書き込みが完了したことを確認してから、処理が完了します。
この仕組みにより、常にデータの整合性が保たれ、「ほぼ同時に同じ状態」が実現されます。
プライマリとセカンダリの役割
DRBDでは、2台のサーバにそれぞれ役割が割り当てられます。
・プライマリ：実際にデータの読み書きを行うサーバ
・セカンダリ：データを受け取り同期するサーバ
通常はプライマリ側のみが書き込みを行い、セカンダリは同期を受け取る待機状態となります。そしてフェイルオーバーが発生した場合、セカンダリがプライマリへ昇格し、サービスを引き継ぎます。
この役割の切り替えがスムーズに行われることで、サービスの継続が可能になります。
同期モードとパフォーマンスの関係
DRBDにはいくつかの同期モードがあり、それぞれデータの安全性とパフォーマンスのバランスが異なります。
例えば、完全同期モードでは両サーバへの書き込み完了を待つため、データの安全性は高い一方で、ネットワーク遅延の影響を受けやすくなります。一方で非同期モードでは高速な処理が可能ですが、障害発生時にわずかなデータ差分が発生する可能性があります。
運用環境に応じて、適切なモードを選択することが重要です。
DRBDだけではHAは完成しない
ここまで見てきたように、DRBDはデータ同期という重要な役割を担っています。しかし、これだけではHA構成は完成しません。
なぜなら、サーバの状態を監視し、障害時に自動的に切り替える仕組みが別途必要だからです。DRBDはあくまで「データを揃える役割」であり、「制御」や「判断」は他のコンポーネントに委ねられます。
では、サーバの状態を監視し、フェイルオーバーを制御するのはどのような仕組みなのでしょうか。
次章では、PacemakerやCorosyncといったコンポーネントを含めた「HAクラスター全体の構成」について、さらに詳しく解説していきます。
5. HAクラスターの全体構成を理解する
HAクラスターは「役割の分担」で成り立つ
HA構成は、単に複数のサーバを用意すれば実現できるものではありません。重要なのは、それぞれのコンポーネントが役割を分担し、連携することでシステム全体を成立させている点です。
前章で紹介したDRBDは「データを同期する」役割を担っていますが、それだけでは障害時の切り替えは実現できません。サーバの状態を監視し、適切に制御する仕組みがあって初めて、HAクラスターとして機能します。
構成要素①：DRBD（データ同期）
まず中核となるのが、データを同期する仕組みであるDRBDです。プライマリとセカンダリ間でディスクの内容を常に一致させることで、どちらのサーバでも同じデータを利用できる状態を維持します。
これにより、フェイルオーバーが発生してもデータの不整合が起きず、サービスを継続することが可能になります。
構成要素②：Corosync（クラスタ通信）
次に重要なのが、サーバ同士の状態を共有するための仕組みです。ここで登場するのがCorosyncです。
Corosyncは、ノード間の通信を担い、お互いのサーバが「正常に稼働しているかどうか」を監視します。いわば、サーバ同士が常に「生きているか」を確認し合う仕組みです。
この情報があることで、どのサーバに障害が発生したのかを正しく判断することができます。
成要素③：Pacemaker（制御）
そして、HAクラスター全体を制御するのがPacemakerです。PacemakerはCorosyncから受け取った情報をもとに、サービスの起動・停止やフェイルオーバーの実行を管理します。
例えば、プライマリサーバに障害が発生した場合、Pacemakerはその情報をもとにセカンダリサーバへサービスを移動させます。この一連の処理が自動で行われることで、ユーザーへの影響を最小限に抑えることができます。
3つのコンポーネントの連携
これらの仕組みは、それぞれ単独で動作するのではなく、密接に連携しています。
・DRBD：データを同期する
・Corosync：ノードの状態を共有する
・Pacemaker：全体を制御する
この3つが組み合わさることで、「データが揃っている」「障害を検知できる」「自動で切り替えられる」という条件がすべて満たされ、HAクラスターが成立します。
全体の流れをイメージする
通常時は、プライマリサーバがサービスを提供し、セカンダリサーバは待機状態でデータ同期を行っています。
そして障害が発生すると、Corosyncが異常を検知し、その情報をPacemakerへ伝えます。Pacemakerはセカンダリをプライマリへ昇格させ、サービスを再開します。
この一連の流れが数秒〜数十秒で完了することで、ユーザーから見れば“ほとんど止まっていない”状態が実現されます。
ここまでで、HAクラスターがどのような構成で成り立っているのか、その全体像を理解できたかと思います。
次章では、実際に障害が発生した際にどのようにフェイルオーバーが行われるのか、その具体的な流れについて詳しく解説していきます。
6. フェイルオーバーの流れをイメージする
フェイルオーバーは「自動で切り替わる仕組み」
HA構成の最大の特徴は、障害が発生しても自動的にサービスが継続される点にあります。この仕組みの中心となるのが「フェイルオーバー」です。
フェイルオーバーとは、稼働中のサーバ（プライマリ）に障害が発生した際、待機しているサーバ（セカンダリ）へ自動的に処理を引き継ぐ仕組みを指します。これにより、ユーザーはサービス停止をほとんど意識することなく利用を続けることができます。
通常時の状態を理解する
まずは通常時の状態を整理してみましょう。
・プライマリサーバ：サービスを提供している
・セカンダリサーバ：待機状態でデータ同期を実施
・DRBD：データをリアルタイムで同期
・Corosync：ノードの状態を監視
・Pacemaker：サービスの状態を管理
この状態では、ユーザーからのアクセスはすべてプライマリ側で処理され、セカンダリは常に同じデータを保持しながら待機しています。
障害発生から切り替えまでの流れ
では、実際に障害が発生した場合の流れを見てみましょう。
① 障害の検知（Corosync）
まず、プライマリサーバに障害が発生すると、Corosyncがノードの異常を検知します。例えば、サーバが応答しなくなったり、ネットワークが途切れた場合に異常と判断されます。
② 状態の判断（Pacemaker）
次に、PacemakerがCorosyncからの情報を受け取り、「プライマリが利用できない状態である」と判断します。この判断が正確であることが、安定したフェイルオーバーの鍵となります。
③ サービスの切り替え
Pacemakerはセカンダリサーバに対して、サービスを起動する指示を出します。同時に、必要に応じてリソースの移動や設定の変更が行われます。
④ セカンダリがプライマリへ昇格
DRBDの役割として、セカンダリサーバがプライマリへ昇格し、ディスクの読み書きが可能な状態になります。これにより、サービスを正常に提供できる状態が整います。
⑤ サービス再開
最終的に、セカンダリサーバが新たなプライマリとしてサービスを開始します。この一連の流れが短時間で完了することで、ユーザーから見れば「一瞬遅れた程度」でサービスが継続されるように見えます。
フェイルオーバーが成功するための条件
フェイルオーバーを正しく機能させるためには、いくつかの重要な条件があります。
・データが完全に同期されていること（DRBD）
・ノードの状態を正確に検知できること（Corosync）
・適切な制御が行われること（Pacemaker）
これらが正しく連携していなければ、切り替えが失敗したり、最悪の場合は両方のサーバが停止する可能性もあります。
「止まらない」ように見える理由
ここまでの流れを理解すると、なぜHA構成が「止まらないシステム」と呼ばれるのかが見えてきます。
実際にはサーバの切り替えは発生していますが、その処理が短時間で自動的に行われるため、ユーザーはサービス停止をほとんど意識することがありません。
つまり、完全に止まらないわけではなく、「止まったことを感じさせない仕組み」がHA構成の本質と言えるでしょう。
ここまでで、フェイルオーバーの流れと、その仕組みについて理解できたかと思います。
しかし、実際の運用では理論通りにいかないケースも多く、注意すべきポイントがいくつも存在します。
次章では、実務でよくあるトラブルや、運用時に気をつけるべきポイントについて詳しく解説していきます。
7. 実務で注意すべきポイント
理論通りにいかないのが現場
ここまでHA構成の仕組みを見てきましたが、実際の運用では必ずしも理論通りに動くとは限りません。むしろ、トラブルが発生したときこそ設計の甘さや設定ミスが露呈しやすくなります。
HA構成は「組めば安心」というものではなく、「正しく設計し、検証し、運用する」ことで初めて効果を発揮します。ここでは、実務で特に注意すべきポイントをいくつか紹介します。
split brainという最も危険な状態
HA構成において、最も注意すべきトラブルのひとつが「split brain（スプリットブレイン）」です。
これは、2台のサーバが互いに相手を「停止している」と誤認し、両方がプライマリとして動作してしまう状態を指します。この状態になると、双方で異なるデータが書き込まれ、データの整合性が完全に崩れてしまいます。
復旧時にはデータのどちらを正とするか判断が必要となり、場合によってはデータ損失にもつながる非常に危険な状態です。
フェイルオーバーは必ずテストする
HA構成を構築したら、必ずフェイルオーバーテストを実施することが重要です。
実際にサーバを停止させたり、ネットワークを遮断するなどして、想定通りに切り替えが行われるかを確認します。このテストを行わないまま本番運用に入ると、いざ障害が発生した際に正しく動作せず、かえって復旧が遅れる原因となります。
「動くはず」ではなく、「実際に動くことを確認する」ことが大切です。
監視とログの重要性
HA構成では複数のコンポーネントが連携して動作するため、問題発生時の原因特定が難しくなることがあります。そのため、各コンポーネントの状態を監視し、ログを適切に取得・管理することが重要です。
CorosyncやPacemakerのログ、DRBDの同期状態などを日常的に確認できる環境を整えておくことで、トラブル発生時の対応スピードが大きく向上します。
ネットワーク設計の重要性
DRBDによるデータ同期はネットワークに依存しているため、ネットワークの品質や設計も非常に重要です。
帯域不足や遅延が発生すると、同期に影響が出たり、パフォーマンス低下の原因となります。また、クラスタ通信とサービス通信を分離することで、安定性を高める設計もよく採用されます。
単にサーバだけでなく、「ネットワークも含めた設計」が求められます。
運用設計まで考えて初めて完成する
HA構成は構築して終わりではありません。運用フェーズにおいても、定期的な状態確認やテスト、障害時の手順整備などが必要です。
例えば、フェイルバック（元の構成への戻し方）をどうするか、メンテナンス時の手順はどうするかなど、事前にルールを決めておくことで、いざという時にスムーズな対応が可能になります。
「安心できる構成」は準備で決まる
HA構成の本当の価値は、「障害が起きたときに慌てなくて済むこと」にあります。そのためには、事前の設計・検証・運用準備がすべてです。
しっかりと準備されたHA環境は、トラブル時にも冷静に対応できる“安心できるシステム”へと変わります。
ここまで、HA構成における実務上の注意点について解説してきました。
最終章では、これまでの内容を振り返りながら、「止まらないサーバを実現するために重要な考え方」を改めて整理していきます。
まとめ
本記事では、サーバが停止した場合の影響から始まり、1台構成の限界、そしてHA構成の考え方とその仕組みについて解説してきました。
ここで改めて重要なのは、「止まらないサーバ」は偶然実現されるものではなく、最初の設計段階から意図的に作り込まれるものだという点です。障害が発生することを前提にし、その影響を最小限に抑える構成を選択することが、安定したサービス運用の第一歩となります。
HAクラスターは、単一の技術で成り立っているわけではありません。
・DRBDによるデータ同期
・Corosyncによるノード監視
・Pacemakerによる制御
これらが連携することで、「データが揃っている」「障害を検知できる」「自動で切り替えられる」という条件が成立し、サービスを継続する仕組みが実現されます。
それぞれの役割を理解し、全体としてどう動くのかを把握することが、HA構成を正しく扱うための鍵となります。
HA構成は構築して終わりではありません。むしろ、運用フェーズに入ってからが本番です。
フェイルオーバーテストの実施、ログの監視、ネットワークの安定性確保など、日常的な運用の積み重ねが、いざという時の安定動作につながります。
また、split brainのような重大なトラブルを防ぐためにも、事前の設計と定期的な検証は欠かせません。「理解している」だけでなく、「実際に扱える」状態にしておくことが重要です。
A構成は一見すると難しく感じるかもしれませんが、基本的な仕組みを理解すれば、決して特別な技術ではありませんので、まずは検証環境などで小さく構築し、実際にフェイルオーバーの動きを確認することで、理解は一気に深まります。自分の手で動かしてみることが、最も確実な学習方法です。
次回（後編）では、実際にRocky Linux環境上でDRBD・Pacemaker・Corosyncを組み合わせたHAクラスターを構築する手順を、実践形式で解説していきます。
GSVは企業の大切なデータを守る安全なNASサーバーシステムです。自動バックアップやRAID構成による多重保存で、データの消失リスクを最小限に抑えます。ネットワーク接続だけで社内外から安全にデータにアクセス可能で、異なるOS間でもスムーズな運用が可能です。
スケジュール管理やToDoリストの一元管理機能を備え、チームの業務効率化を支援します。契約期間中の無償アップデートで常に最新機能を利用可能です。
さらに、無停電電源装置（UPS）の標準装備、ウイルス検知システム、柔軟なアクセス制限により、物理的な障害やセキュリティリスクからも企業データを保護。GSVは安全で効率的なデータ管理環境を提供します。
【関連記事】
