この記事は、ニフクラブログで2018-07-02に公開された記事を移転したものです。
こんにちは、ニフクラテクニカルアカウントチームです。
ニフクラではデータセンター(リージョン)内に複数のゾーンを提供しています。そのため、複数のゾーンを利用して、システムを冗長化することも可能です。
今回は、一般的なWEBシステムを想定してゾーン間で冗長構成とし、ゾーン間を相互に監視できるような構成を考えて、検証してみました。最終的には以下のような構成を構築して検証しています。
本ブログではゾーン間の接続をゾーンコネクトを利用した構成となっています。
現在同等の機能を持つサービスとして、プライベートブリッジが提供されているため、実装する際はこちらをご利用ください。
ブログ：プライベートLAN同士を接続する機能 プライベートブリッジ の提供を開始しましたもご参考にしてください。
はじめに
ニフクラでは、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 | ||||
| DBサーバー#1 | 無 | DBサーバー用途(PostgreSQL) | ||
| DBサーバー#2 | ||||
| 監視サーバー#1 | 監視用サーバー(Zabbix) | |||
| 監視サーバー#2 | ||||
| 監視サーバー#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 |
監視実装
監視サーバーで監視を行う項目を以下に記載します。
※実際のシステムでは要件に応じて詳細を検討してください。
| 監視サーバー | 監視対象 | |
|---|---|---|
| 監視サーバー#1,#2 | Web/APサーバー#1,#2 | 死活監視 |
| DBサーバー#1,#2 | ||
| 監視サーバー間(#1⇒#2,#2⇒#1) | ||
| Web/APサーバー#1,#2のApache | プロセス監視 | |
| Web/APサーバー#1,#2のTomcat | ||
| DBサーバーのPostgreSQL(VIP) | ||
| 監視サーバー#3 | LBのURL | URL監視 |
システム監視 テスト項目
今回の構成実装後のテスト項目を以下に記載します。
主にいずれかのリソースに障害が発生した際の、監視の観点でのテストをピックアップして記載しています。
定常時テスト
- 想定したシステム構成が組めること
- 監視サーバーと監視対象のサーバー間で通信が正常に実施できること
障害時テスト
省略したパターンを記載しています。実際の試験としては記載以外のものも実施しています。
例：試験No.1でWeb/APサーバー#1だけではなくWeb/APサーバー#2のプロセスkillパターンも実施している。
| No. | 試験項目 | 試験内容 | 確認事項 | |
|---|---|---|---|---|
| 1 | ① | Web/APサーバー方系障害 | Web/APサーバー#1のApacheのプロセスをkill. | LBからWeb/APサーバー#1が切り離されること |
| ② | 監視サーバー#1(主系)で検知すること | |||
| ③ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
| 2 | ① | Web/APサーバー#1のTomcatのプロセスをkill. | LBからWeb/APサーバー#1が切り離されること | |
| ② | 監視サーバー#1(主系)で検知すること | |||
| ③ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
| 3 | ① | Web/APサーバー#1のOSを停止 | LBからWeb/APサーバー#1が切り離されること | |
| ② | 監視サーバー#1(主系)で検知すること | |||
| ③ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
| 4 | ① | Web/APサーバー全系障害 | Web/APサーバー#1,#2のOSを同時に停止 | 監視サーバー#1(主系)で検知すること |
| ② | 監視サーバー#3のWeb監視でアクセスNGを検知すること | |||
| 5 | ① | DBサーバー主系障害 | DBサーバー#1(主系)のPostgreSQLのプロセスをkill. | DBサーバーがF/Oすること |
| ② | 監視サーバー#1(主系)で検知すること | |||
| ③ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
| 6 | ① | DBサーバー#1(主系)のOSを停止 | DBサーバーがF/Oすること | |
| ② | 監視サーバー#1(主系)で検知すること | |||
| ③ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
| 7 | ① | DBサーバー副系障害 | DBサーバー#2(副系)のOSを停止 | DBサーバーがF/Oしないこと |
| ② | 監視サーバー#1(主系)で検知すること | |||
| ③ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
| 8 | ① | 監視サーバー障害 | 監視サーバー#1(主系)のOSを停止 | 監視サーバーがF/Oすること |
| ② | F/O後も監視が継続できること | |||
| 9 | ① | 監視サーバー#2(副系)のOSを停止 | 監視サーバーがF/Oしないこと | |
| ② | 監視サーバー#1(主系)で検知すること | |||
| 10 | ① | ゾーン障害 | 片方のゾーンの全てのサーバー(主系)のOSを停止 | LBからWeb/APサーバー#1(主系)が切り離されること |
| ② | DBサーバー、監視サーバーがF/Oすること | |||
| ③ | F/O後も監視が継続できること | |||
| ④ | Web/APサーバーへのアクセスが可能で、問題なく画面が表示できること | |||
結果
全て当初の想定どおりの動作を行い、テスト結果としても問題ないことが確認できました。
まとめ
今回は east-1 リージョン内で複数のゾーンを利用することで、システムを冗長化し、ゾーン間で冗長化したシステムも問題なく監視が可能か確認してみました。
有事の際にシステムが止まらないことはもちろんですが、縮退状況の中、監視が継続できることも重要だと考えます。
また冗長化したDBサーバー、監視サーバーのF/Oに関しても数十秒秒程度で完了していました。データも入っていない状態なので早い可能性もありますが、現実的な切替時間かと考えています。
ゾーンが全壊するようなことはほぼないと思いますが、万が一に備えると考えると非常に有用な構成だと考えられます。
※本記事については検証結果の１つであり、実際のシステムの場合には、事前にそれぞれの要件を鑑みて実装するか検討してください。また、実装される際には要件を満たせるか十分に検証を行っていただくようお願いします。
[2021年2月19日追記：ゾーン間の接続にプライベートブリッジの利用ができる旨を追記]
