技術者が語る、パブリッククラウド活用のすすめ from ニフティクラウドユーザーブログ(32) ゾーン間冗長構成システムの監視実装検証

ニフクラでは、HA機能(自動フェイルオーバー)が標準搭載となっており物理サーバー故障時には対象の仮想サーバーが別物理サーバー上に再起動して立ち上がります。しかし以下のような要件がある場合には別途構成を検討する必要があります。

HAでのサーバー停止時間も許容できない。
物理サーバー障害だけではなくOS以上のレイヤーでの不具合(サービスダウンなど)にも対応する必要がある。

上記の場合は、各サーバーリソースを2台以上用意し独自に冗長構成とすることで、要件を満たすことが可能となります。 (サーバーリソースを異なる物理サーバーに設置して、より高い可用性を得るためにサーバーセパレートの利用を推奨します。)

上記構成をとったとしても、ニフクラのゾーン自体に障害が発生した際には対応できません。ニフクラでは複数のゾーンを提供しているため、複数のゾーンを利用して、システムを冗長化することも可能です。また、システムを冗長構成としても、障害中、正常に監視できていないと不測の事態が発生した場合に対応が難しくなります。そのため、今回は監視にも焦点をあて、監視システム含めてゾーン間で冗長構成としたシステムを構築し障害時の検知/切替などをテストしてみました。 ※今回の検証ではOS以上のレイヤーについても触れていますが、ニフクラではOS以上は利用者責任で実装する範囲となります。実際に実装を検討される場合は、慎重な検討/検証、入念な設計等をお願いします。 ※冗長化する際の詳細な手順等には今回は触れていません。構成検討の際の参考となるような記事となっています。

前提条件

本稿は、以下の前提知識がある方を想定しています。

基本的なサーバーOSを構築する知識

利用リソース

今回の検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。 ※各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定の上実施しています。

ニフクラ利用サービス

サービス	数量
仮想サーバー	8
プライベートLAN	5
ルーター	2
ロードバランサー(L4)	1
ゾーンコネクト	2

各サービス詳細

仮想サーバー

名前	OS	グローバルNIC	プライベートNIC	備考
Web/APサーバー#1	CentOS 7.1	有	プライベートLAN	Web、APサーバー用途
Web/APサーバー#2		有		Web、APサーバー用途
DBサーバー#1		無		DBサーバー用途(PostgreSQL)
DBサーバー#2				DBサーバー用途(PostgreSQL)
監視サーバー#1				監視用サーバー(Zabbix)
監視サーバー#2				監視用サーバー(Zabbix)
監視サーバー#3		有	共通プライベート	監視用サーバー(URL監視)
Zabbix画面アクセス用Windows	Windows Server 2012 R2	有	プライベートLAN	踏み台兼 Zabbix管理画面アクセス用

プライベートLAN

名前	CIDR	用途
プライベートLAN#1	192.168.10.0/24	east-13ゾーン Web/AP層
プライベートLAN#2	192.168.20.0/24	east-13ゾーン DB層
プライベートLAN#3	192.168.11.0/24	east-14ゾーン Web/AP層
プライベートLAN#4	192.168.20.0/24	east-14ゾーン DB層

ルーター

名前	所属するネットワーク
ルーター#1	プライベートLAN#1、#2
ルーター#2	プライベートLAN#3、#4

ロードバランサー(L4)

名前	用途
ロードバランサー	Web/APサーバー#1,#2負荷分散用

ゾーンコネクト

名前	用途
ゾーンコネクト	プライベートLAN#2,#4接続用

通信フロー

今回の構成での通信フローを以下図に示します。

注意事項

本構成を実装するにあたる注意事項を以下に記載します。 (本構成はあくまで一例になります。)

ルーターに関して、east-13,14ゾーン双方に設置しています。ゾーン間で冗長化を実現する機能はなく、それぞれ独立しています。各ルーターでは冗長化されています。障害時は5分を目安として切り替るための停止が発生します。

今回は実装していませんが、5分の停止を許容できない場合の対処として以下が考えられます。
ルーターの障害を検知(ping監視)
障害を検知した場合、該当ルーターが所属しているゾーンのWeb/APサーバーをAPIでロードバランサーから切り離す
経路情報の設定には入念に注意して、設計/実装してください。

例:DBサーバー#1に異常が発生し、DBサーバー#2に切り替わった際のWeb/APサーバー#1⇔DBサーバー#2の経路に注意する必要がある。など
今回DBサーバーにはIaaSでサーバーを配備し、DB(PostgreSQL)を導入して検証しています。

PaaSのRDBでは複数ゾーンでは冗長構成とできないため本構成は実現が難しいです。注意してください。

冗長化方式

今回の検証で利用した冗長化方式を以下に記載します。

DBサーバー冗長化方式

OS	CentOS 7.1
クラスタソフト	Pacemaker 1.1.15 / Corosync 2.4.1
データ同期	DRBD 8.4.9
制御対象	Filesystem / 仮想IP / DRBD / PostgreSQL

監視サーバー冗長化方式

OS	CentOS 7.1
クラスタソフト	Pacemaker 1.1.15 / Corosync 2.4.1
データ同期	DRBD 8.4.9
制御対象	Filesystem / 仮想IP / DRBD / Zabbix / Apache / MySQL