はじめに

今回はAmazon Web Services(以降、AWS)で、HAクラスターへの接続先切り替えにNetwork Load Balancer(以降、NLB)を利用したHAクラスターの構築を試してみました。NLBは、ロードバランサー機能を提供するElastic Load Balancing(以降、ELB)の内の1つです。
NLBを利用したHAクラスターでは、ロードバランサーの負荷分散の機能により、クライアントマシンからHAクラスターへの接続先を切り替えます。また、HAクラスターへのアクセスには、NLBのDNS名(仮想ホスト名)を利用します。

アクセスにDNS名を利用したHAクラスター構成には、AWS DNSリソースを利用したDNS名制御のHAクラスターもあり、こちらはAWS CLIを利用してAmazon Route 53(以降、Route 53)のAレコードを書き換えることで接続先を切り替えます。
2022年7月時点では、Route 53はPrivateLinkに対応していないため、AWS CLIを利用してRoute 53のAレコードを操作するためには、HAクラスターのインターネット接続が必要になります。
対して今回の構成では、アクセスにはDNS名を利用しますが、接続先切り替えにはNLBのヘルスチェック機能を利用し、AWS CLIを実行しません。そのため、HAクラスターのインターネット接続は不要になります。

この記事の内容

1. Network Load Balancerとは

前述の通り、NLBはAWSのロードバランサー機能を提供するELBの1つです。
この章ではNLBを利用したHAクラスターを構築するにあたり、理解すべきNLBの機能を説明します。
詳細は以下を参照ください。

【参考】

Network Load Balancer とは? - Elastic Load Balancing

NLBの機能概要

NLBはOSI基本参照モデルの第4層で機能し、NLBが受信したトラフィックを、ターゲットグループに登録したインスタンス(以降、ターゲットのインスタンス)へと分散することができるサービスです。ターゲットのインスタンスへ定期的にヘルスチェックを実行し、ヘルスチェックが成功したインスタンスに対して、TCP/UDPのポート番号単位でトラフィックを分散します。

下の図は、NLBにTCP80番ポートを設定した例です。

NLBの種類

NLBには「内部ロードバランサー」と「インターネット向けロードバランサー」の2種類があります。
NLBの作成時に、クライアントマシンからNLBへのアクセスに使用するIPアドレス(以降、NLBのIPアドレス)を設定します。
「内部ロードバランサー」は、NLBのIPアドレスにプライベートIPアドレスを設定し、VPC内からのアクセスをターゲットのインスタンスに分散します。
「インターネット向けロードバランサー」は、NLBのIPアドレスにパブリックIPアドレスを設定し、インターネットを経由したVPC外からのアクセスをターゲットのインスタンスに分散します。

NLBへのアクセス方法

NLBへのアクセス方法として、NLBのIPアドレスまたはNLBのDNS名を利用する2種類があります。
この節では可用性を考慮して、ターゲットのインスタンスを複数AZに配置していることを前提とします。

NLBのIPアドレスはAZ毎に1つずつ作成することができます。デフォルトのNLBの設定では、NLBのIPアドレスにアクセスすることで、同じAZ内にあるターゲットのインスタンスにトラフィックを分散することができます。また、NLBの設定で「クロスゾーン負荷分散」を有効にすることで、異なるAZにあるターゲットのインスタンスにもトラフィックを分散できるようになります。
ただし、次の図のようにNLBのIPアドレスを1つだけ作成する場合、NLBが単一障害点になってしまいます。

そのため、次の図のようにNLBのIPアドレスは複数AZに作成することを推奨します。
これにより、アクセスに利用しているNLBのIPアドレスに異常が発生した場合でも、他のNLBのIPアドレスに切り替えることでターゲットのインスタンスにアクセスできます。
ただし、クライアントマシンでNLBのIPアドレスを切り替える仕組みが必要になります。

一方で、NLBのDNS名は1つのNLBにつき1つ作成され、全てのNLBのIPアドレスがDNS名と紐づきます。
NLBのDNS名はAWS内部のRoute 53で管理しているため、Route 53は異常になったNLBのIPアドレスを名前解決から自動的に除外します。そのため、クライアントマシンから同じDNS名を利用することで、NLBのIPアドレスの切り替えを意識することなく、継続してターゲットのインスタンスにアクセスできます。

また、NLBのDNS名は、AWS内部のRoute 53のパブリックホストゾーンとプライベートホストゾーンに登録されています。NLBを「内部ロードバランサー」で作成し、NLBのDNS名をRoute 53 リゾルバーなどを利用してプライベートホストゾーンで名前解決することで、オンプレミス環境からNLBにインターネット接続なしでアクセスすることができます。

2. HAクラスター構成

今回は、東京リージョンに「NLBを利用したHAクラスター」を構築します。
また、オンプレミス環境の疑似環境としてシンガポールリージョンにクライアントマシンを構築します。

今回構築するHAクラスターの構成図は以下の通りです。

今回はセキュリティを考慮して、インターネット接続を必要としない構成にするために、NLBは「内部ロードバランサー」で作成します。また、NLBへのアクセス方法には、接続先の切り替えを容易に設定できるNLBのDNS名を利用します。アクセス経路については後述します。

シンガポールリージョンのVPCには、クライアントマシンに加え、VPN接続用のVyOSとNLBのDNS名の名前解決用のDNSサーバーを用意します。
東京リージョンのVPCには、HAクラスターとNLBに加え、NLBのDNS名の名前解決先となるRoute 53 リゾルバーを用意します。

今回は例として、Webサーバーのクラスターを構築し、NLBでTCP80番ポートのトラフィックを振り分けます。
接続先切り替えには、ロードバランサーの持つヘルスチェック機能を利用し、意図的に成功・失敗させることで切り替えます。
具体的には、ヘルスチェック用に設定するポートの通信可/不可をCLUSTERPROから制御し、現用系で通信可、待機系で通信不可の状態にします。これにより、NLBはヘルスチェックが成功する現用系にのみトラフィックを割り振ることができます。

アクセス経路

前述の通り、今回はセキュリティを考慮して、インターネット接続を必要としないアクセス経路にします。

これらにより、NLBのDNS名の名前解決からNLBへのアクセスまでを、インターネットを経由せずに行うことができます。

3. HAクラスター構築手順

今回のHAクラスターの構築手順をご紹介します。
疑似的なオンプレミス環境のため、シンガポールリージョンのルートテーブルとセキュリティーグループ、EC2インスタンスの記載は割愛します。

3.1 AWS環境の設定

3.1.1 VPC、サブネットの作成

まず、VPCやサブネットなどを作成します。CIDRやサブネットアドレスなどは以下の通りです。

東京リージョン (ap-northeast-1)

シンガポールリージョン (ap-southeast-1)

3.1.2 ルートテーブルの作成

東京リージョンのVPCにおいてルートテーブルを必要に応じて作成します。

■ 東京リージョン (ap-northeast-1)
今回の構成では、シンガポールリージョンへの経路のみの追加になるため、全サブネットで共通のルートテーブルになります。

3.1.3 セキュリティグループの作成

東京リージョンのVPCにおいてセキュリティグループを必要に応じて作成します。
セキュリティグループは、システムのポリシーに応じて適切に設定してください。

3.1.4 EC2インスタンスの作成

東京リージョンのSubnet-A2 (Private)とSubnet-C2 (Private)のそれぞれに、HAクラスター用のEC2インスタンスを作成します。
また、Webサーバーの構築に使用するソフトウェアとして、Windows版はIIS、Linux版はApacheをインストールします。

3.1.5 NLBの作成

HAクラスター用として作成した2つのインスタンスをターゲットとするNLBを「内部ロードバランサー」で作成します。

NLBのIPアドレスの設定先として東京リージョンのSubnet-A1 (Private)とSubnet-C1 (Private)を選択します。

今回はWebサーバーへの接続先切り替えを行うために、リスナーにTCPの80番ポートを設定します。

設定完了後、ターゲットグループを新規作成します。

ターゲットグループの作成画面に遷移するので、ヘルスチェックのポート番号を設定します。ポート番号には業務で利用しない任意のポートを指定します。
今回は例として、ポート番号に「12345」を設定します。
次に、「正常のしきい値」や「間隔」を目標とする接続先切り替え時間に合わせて設定します。「正常のしきい値」は小さく、「間隔」は短く設定することにより接続先の切り替え時間が短くなりますが、「間隔」を短くするとヘルスチェックに対する処理がより頻繁に発生することになります。今回はデフォルト値を設定します。

HAクラスター用として作成した2つのインスタンスにチェックを入れ、ターゲットに登録します。

ロードバランサー作成画面に戻り、ターゲットグループに先ほど作成したものを選択し、ロードバランサーを作成します。また、作成後にNLBの「クロスゾーン負荷分散」を有効にします。

3.1.6 VPNの作成

東京リージョンのVPCに仮想プライベートゲートウェイおよび、シンガポールリージョンのVyOSのパブリックIPアドレスを設定したカスタマーゲートウェイを作成します。
また、仮想プライベートゲートウェイとカスタマーゲートウェイ間のVPN接続も作成します。

3.1.7 VyOSの設定

作成したVPN接続から設定情報をダウンロードします。
シンガポールリージョンのVyOSに設定を投入し、VPN接続を有効にします。

3.1.8 Route 53 リゾルバーの作成

東京リージョンのVPCにRoute 53 リゾルバーを作成します。
また、インバウンドエンドポイントにSubnet-A3 (Private)とSubnet-C3 (Private)を選択します。
詳しい設定方法は、以下の記事を参照してください。

【参考】

Route 53 リゾルバーを使用してAWS上のHAクラスターへの接続を試してみました(後編)
　2.3 Route 53 リゾルバーの設定

3.2 HAクラスターの構築

CLUSTERPROの構成は以下の通りです。
今回の検証ではCLUSTERPRO X 4.3(内部Ver. Windows：12.30、Linux：4.3.0-1)を利用しています。
CLUSTERPROのフェールオーバーグループには「Azureプローブポートリソース」(※)と「ミラーディスクリソース」、Webサーバー制御用リソース(Windows版は「サービスリソース」、Linux版は「EXECリソース」)の3つを登録します。
また、「Azureプローブポートリソース」の「プローブ待ち受けのタイムアウト」は、NLBのヘルスチェックの間隔より長く設定する必要があります。今回は、NLBのヘルスチェックの間隔を既定値の30秒で設定しているため、「プローブ待ち受けのタイムアウト」は31秒以上に設定します。

4. 動作確認

シンガポールリージョンのクライアントマシンからNLBのDNS名を利用して、Server1のWebページにアクセスできることを確認します。次に、Server1からServer2にフェールオーバーをし、同一DNS名でServer2のWebページにアクセスできることを確認します。

まとめ

今回はNLBとVPNを利用して、AWS上に構築したHAクラスター環境への接続を試してみました。
今回の構成では、CLUSTERPROからAWS CLIによるAWS環境の設定変更を行わず、またクライアントやクラスターサーバーのインターネット接続が必要ありません。セキュリティ要件等により今回のような構成にする際は、本手順を参考にHAクラスターを構築してください。

本記事の構成をご検討の際は、CLUSTERPROの試用版を用いて検証した後、ご提案・構築ください。

お問い合わせ