連載
» 2015年10月23日 05時00分 UPDATE

DRBDの仕組みを学ぶ(2):「高可用性システム」で、DRBDをどう活用するか (1/3)

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

[澤田健,株式会社サードウェア]
backn2.gif

連載バックナンバー

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

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

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

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

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

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

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

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

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

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

photo 図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から変わることはありません。

       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

Focus

- PR -

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。