「高可用性システム」で、DRBDをどう活用するか：DRBDの仕組みを学ぶ（2）（1/3 ページ）

障害監視ツールなどと一緒に使い、サービスの継続提供を助けるDRBD。今回は「高可用性システム」でどう使うか、実践的な運用方法を解説します。

[澤田健，株式会社サードウェア]

連載バックナンバー

　連載第一回目の前回は、「DRBD（Distributed Replicated Block Device）」の基本的な機能と動作について解説しました。

• DRBDの仕組みを学ぶ（1）：DRBD（Distributed Replicated Block Device）とは何か

　今回は、より実践を踏まえた話に入ります。DRBDが最も使われている「高可用性システム」での活用例を解説します。

高可用性システムにおけるDRBDの活用例

　前回、サーバー2台の冗長構成でサービスを継続させるために、DRBDがどのような動きをするのか、この基本を説明しました。プライマリ機で障害が発生したら、プライマリ機とセカンダリ機を切り替えて、これまでのセカンダリ機をプライマリ機に変更します。そして、データの書き込み先も新たなプライマリ機へ変更します。このようにDRBD構成でサーバーを冗長化しておけば、片方に障害が発生してもサーバーのサービスを継続できることになります。

　しかし、原則としてDRBDだけでは「自動化」できません。障害発生時にいちいち手動で切り替えていたのでは、復旧までに時間がかかってしまいます。

　そこで、DRBDは他のソフトウエアと組み合わせて使い、障害発生時に他方へ自動で切り替える高可用性システムを実現します。

「高可用性システム」とは何か

　高可用性システムは、HA（High Availability）構成、HAサーバー、HAクラスターなどとも呼ばれます。

　呼び方はいくつかありますが、要はサービスのダウンタイムが少ないシステム、つまり可用性の高いシステムを指します。

　基本的な構成は図1のようになります。高可用性システムの基本はサーバー2台の冗長構成となります。

図1　MySQLサーバーを使った高可用性システムの基本構成図

　図1の状態は、プライマリ側のMySQLサーバーが稼働し、セカンダリ側では停止しています。セカンダリ側にはアクセスさせず、DRBDによってデータのリアルタイムレプリケーション（同期）が行われている状態になります。

　ネットワーク構成は以下の通りです。

インターフェース	プライマリ機	セカンダリ機	用途
VIP	192.168.0.1		仮想アドレス
eth0	192.168.0.2	192.168.0.3	サービス用LAN
eth1	10.0.0.1	10.0.0.2	Corosync監視用
eth2	10.0.1.1	10.0.1.2	DRBD同期＋監視用

　この表の詳細を順に解説します。

　まずユーザーはVIP（仮想アドレス）である192.168.0.1にアクセスします。

　図1の構成では、左側のサーバーがプライマリのため仮想アドレスを通じてプライマリ機にアクセスします。赤線が該当するルートです。

　eth1とeth2は、それぞれのサーバー同士を直結した構成です。eth1では「Corosync」というソフトウエアでノードを監視し、障害の発生を検知します。eth2では「DRBDによる同期」と「Corosyncによる監視」を行います。

　Corosyncでは二重に監視を行っています（eth1とeth2）。ここを二重化する理由は、インターフェース障害への備えのためです。この対策をしておかないと、障害発生時にプライマリ機とセカンダリ機のどちらがプライマリなのかが分からなくなり、両方プライマリ機になる障害「スプリットブレイン状態」に陥ってしまいます。

　図1の構成ならば、プライマリ機で障害が発生すると自動的にセカンダリ機に切り替わり、MySQLサーバーを引き続き使用できます。その際、ユーザーは仮想アドレスでアクセスしているので、サーバーが切り替わってもアクセス先は192.168.0.1から変わることはありません。