• WEBシステムを想定したゾーン間での冗長構成

ニフクラでは、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
    • DBサーバー冗長化方式

  • 監視サーバー冗長化方式
    • OS CentOS 7.1
    クラスタソフト Pacemaker 1.1.15 / Corosync 2.4.1
    データ同期 DRBD 8.4.9
    制御対象 Filesystem / 仮想IP / DRBD / Zabbix / Apache / MySQL
    alt

    続きは、ニフティクラウド ユーザーブログよりご覧ください。 (別サイトへ移動します)

    続きを読む

[PR]提供：富士通クラウドテクノロジーズ