AWS Transit Gatewayを利用したHAクラスター構築〜マルチリージョン HAクラスター〜(WIndows/Linux)

Tweet
Share

はじめに

AWS Transit Gateway (以降、Transit Gateway)を利用して、Amazon Web Services(以降、AWS)上で異なるリージョンに配置したインスタンスのHAクラスター構築を試してみました。
さらに今回は、HAクラスター構成に「VIP制御によるHAクラスター」を選択し、接続先切り替えにVIPを使用しました。

本ブログでは今までに、Transit Gatewayを利用したVIP接続として以下の記事をご紹介しました。
popup オンプレミス(疑似環境)からAWS上のVPCにあるHAクラスターに接続
 popup 異なるVPCに配置したクライアントからHAクラスターに接続

VIP制御方式ではVIPのルーティングが課題となり、上記のブログはいずれもHAクラスターを構成するインスタンスは同一のVPC上に配置していました。
今回は、スクリプトによりリージョン間のルーティング設定をすることで、マルチリージョンHAクラスターの構築が実現できましたのでご紹介いたします。

※大阪リージョンでは、AWS Transit Gatewayのピアリングアタッチメント(Peering接続タイプのTransit Gatawayアタッチメント)がサポートされていないため、本構成は構築できませんのでご注意ください。(2021/06/18現在)

1. HAクラスター構成

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

東京リージョンとシンガポールリージョンにそれぞれHAクラスターを構成するインスタンス（Server-A、Server-B）を配置したマルチリージョン構成です。

インスタンスは異なるリージョンに配置されるため、各リージョンに１つずつTransit Gatewayを作成しています。
HAクラスターを構成するインスタンスはプライベートサブネットに配置しますが、AWS CLIを利用したルートテーブルの制御時にリージョンエンドポイントとの通信を行う必要があるため、それぞれのリージョンにパブリックネットワークを設け、インターネットゲートウェイとNATゲートウェイを追加しています。

ここでVPCエンドポイントが使用できないことに注意します。
VIPの活性時に自リージョンだけでなく他リージョンのルートテーブルも更新する必要がありますが、VPCエンドポイントは自リージョンに対するアクセスしか受け付けないためです。（たとえば東京リージョンのインスタンスからVPCエンドポイントを利用してシンガポールリージョンのルートテーブルを更新できません）

VIPにアクセスするクライアントは、通常オンプレミス側か、別VPCもしくは別アベイラビリティゾーンに配置するのが一般的だと思いますが、今回は構成をシンプルにするためにServer-Aと同じVPCのパブリックサブネット上に置いています。

1.1 ルーティング

VPCのルートテーブルとは別に、各Transit Gatewayは、Transit Gateway用のルートテーブル（以降、TGWルートテーブル）を持っています。
TGWルートテーブルには、送信先とTransit Gatewayアタッチメント（以降、TGWアタッチメント）の対応が経路情報として登録されています。

まず、Server-AでVIPが活性している場合を考えると、各ルートテーブルのVIPに関する経路情報は次のようになっています。

[A]、[B]はTGWルートテーブル、[1]～[4]はVPCのルートテーブルを意味しています。本来は他VPCへのルートなど固定の経路情報もありますが、この図ではVIPの経路情報に関するもののみ記載しています。

TGWアタッチメントのタイプは今回の場合、VPCとPeering接続の２種類を使用しています。
VPCとTransit Gatewayとの間はVPCタイプのTGWアタッチメント（図のtgw-attach-Aおよびtgw-attach-B）、2つあるTransit Gateway同士は、Peering接続タイプのTGWアタッチメント（図のtgw-attach-peering）で接続されています。

同じVPC-A内のインスタンスからVIPにアクセスする場合は、VPC-Aのルートテーブル（[1]または[2]）を参照します。
このルートテーブルでVIPはServer-AのENIを示しているため、そのまま直接Server-Aにアクセスできることになります。

一方、VPC-B内のインスタンスからVIPにアクセスする場合は、まずVPC-Bのルートテーブル（[3]または[4]）が参照されます。
VIPはVPC-BのTransit Gateway（tgw-B）を示していますので、パケットはVPC-BのTransit Gateway（tgw-B）に転送されます。
次に、VPC-BのTransit Gatewayにおいて、[B]のTGWルートテーブルが参照され、VIPに対応する経路であるTGWアタッチメント（tgw-attach-peering）を通じてVPC-AのTransit Gateway（tgw-A）に転送されます。
VPC-AのTransit Gatewayでは、[A]のTGWルートテーブルにおいてVIPの経路としてTGWアタッチメント（tgwattach-A）が指定されているため、パケットはVPC-Aに転送されます。
その後はVPCのルートテーブルである[1]および[2]に従い、Server-Aに配送されます。

VIPがServer-Bに切り替わった場合の経路情報は次のとおりです。
経路情報が、先述とは逆の流れになっていることがわかります。

1.2 CLUSTERPROによるルーティングの制御

先述の通り、VPCおよびTransit Gatewayのルートテーブルを適切に設定することで、VIPによる接続先切り替えを行うことが可能となります。

CLUSTERPRO Xには、AWSでのVIP切り替えとしてAWS 仮想IPリソース/モニタリソースが用意されています。
しかし、AWS 仮想IPリソースが更新するルートテーブルは活性化するインスタンスの属しているVPCのみとなり、異なるVPC、および、TGWルートテーブルは対象外です。

そこで、AWS 仮想IPリソースが更新しないルートテーブルをAWS CLIコマンドを実行し、適切な経路情報で更新するようにします。

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

CLUSTERPRO Xを使用した「VIP制御によるマルチリージョンHAクラスター」を構築します。

2.1 VPC、サブネットの作成

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

Internet Gateway、NAT Gatewayなども作成しておきます。ネットワークACLは任意ですが今回はDefaultのままでも問題ありません。
ルートテーブルやセキュリティグループについては後述します。

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

VPC(VPC ID：vpc-1234abcd)

－CIDR：10.0.0.0/16
－Subnets

■Subnet-A1 (Public) ：10.0.10.0/24
■Subnet-A2 (Private)：10.0.110.0/24

－Internet Gateway
－NAT Gateway (Subnet-A1上に作成)

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

VPC(VPC ID：vpc-5678cdef)

－CIDR：10.1.0.0/16
－Subnets

■Subnet-B1 (Public) ：10.1.10.0/24
■Subnet-B2 (Private)：10.1.110.0/24

－Internet Gateway
－NAT Gateway (Subnet-B1上に作成)

2.2 Transit Gatewayの作成

今回は２つのリージョンを使用するため、2つのTransit Gatewayを作成します。
また、Transit GatewayとVPC、および、Transit Gateway同士を接続するためのTGWアタッチメントも作成します。

Transit Gateway A [tgw-A]

－TGWアタッチメント (VPCタイプ、VPC-Aと接続) [tgw-attach-A]
－TGWアタッチメント (Peering接続タイプ、Transit Gateway Bと接続) [tgw-attach-peering]

Transit Gateway B [tgw-B]

－TGWアタッチメント (VPCタイプ、VPC-Bと接続) [tgw-attach-B]
－TGWアタッチメント (Peering接続タイプ、Transit Gateway Aと接続) [tgw-attach-peering]

ここで注意が必要なのが、Peering接続タイプのTGWアタッチメントの作成方法です。
VPCタイプのTGWアタッチメントは、両方のリージョンで1つずつ作成しますが、Peering接続タイプのTGWアタッチメントは、どちらか一方のリージョンでのみ作成します。その後、もう一方のリージョンでそのアタッチメントに対してAccept操作を行います。

Peering接続タイプのTGWアタッチメントを作成する流れは次の通りです。

1.東京リージョンでTGWアタッチメント（Peering接続タイプ）を作成する。

まず、AWS管理コンソールで東京リージョンに切り替え、TGWアタッチメントをPeering接続タイプで作成します。

Transit Gateway ID: 東京リージョンのTransit Gateway ID
Attachment type: Peering Connection
Attachment name tag: 識別可能な任意のアタッチメント名
Account: My account
Region: Singapore (ap-southeast-1)
Transit Gateway (accepter): シンガポールリージョンのTransit Gateway ID

2.シンガポールリージョンでTGWアタッチメント（Peering接続タイプ）に対するAccept操作を行う。

リージョンをシンガポールに切り替え、作成したTGWアタッチメントがシンガポールリージョン側にも表示されていることを確認します。

ただし、シンガポールリージョン側でのTGWアタッチメントの状態が"pending acceptance"のままであるため、そのままでは機能しません。
TGWアタッチメントを選択し、[アクション]－[Accept]を選択し、状態が[available]になるまで待ちます。

2.3 ルートテーブルの作成

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

VPC-A Subnet-A1 (Public) 用ルートテーブル

送信先	ターゲット	備考
0.0.0.0/0	Internet Gateway	Internet通信用
10.0.0.0/16	local	VPC内通信用
10.1.0.0/16	tgw-A	VPC-Bとの通信用
172.16.0.1/32	tgw-A	VIP用、ターゲットは仮指定

VPC-A Subnet-A2 (Private) 用ルートテーブル

送信先	ターゲット	備考
0.0.0.0/0	NAT Gateway	Internet通信用
10.0.0.0/16	local	VPC内通信用
10.1.0.0/16	tgw-A	VPC-Bとの通信用
172.16.0.1/32	tgw-A	VIP用、ターゲットは仮指定

Transit Gateway A [tgw-A] 用ルートテーブル

送信先	ターゲット	備考
10.0.0.0/16	tgw-attach-A	VPC-Aとの通信用
10.1.0.0/16	tgw-attach-peering	VPC-Bとの通信用
172.16.0.1/32	tgw-attach-A	VIP用、ターゲットは仮指定

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

VPC-B Subnet-B1 (Public) 用ルートテーブル

送信先	ターゲット	備考
0.0.0.0/0	Internet Gateway	Internet通信用
10.1.0.0/16	local	VPC内通信用
10.0.0.0/16	tgw-B	VPC-Aとの通信用
172.16.0.1/32	tgw-B	VIP用、ターゲットは仮指定

VPC-B Subnet-B2 (Private) 用ルートテーブル

送信先	ターゲット	備考
0.0.0.0/0	NAT Gateway	Internet通信用
10.1.0.0/16	local	VPC内通信用
10.0.0.0/16	tgw-B	VPC-Aとの通信用
172.16.0.1/32	tgw-B	VIP用、ターゲットは仮指定

Transit Gateway B [tgw-B] 用ルートテーブル

送信先	ターゲット	備考
10.1.0.0/16	tgw-attach-B	VPC-Bとの通信用
10.0.0.0/16	tgw-attach-peering	VPC-Aとの通信用
172.16.0.1/32	tgw-attach-B	VIP用、ターゲットは仮指定

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

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

今回はさらにTransit Gatewayを経由してVIPでアクセスされる可能性のあるインスタンス用に、Transit Gateway 経由でのアクセスを許可するセキュリティグループも以下の通り作成します。

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

・Transit Gateway 経由のアクセス許可用セキュリティグループ
- インバウンドルール

－すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.1.0.0/16

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

・Transit Gateway 経由のアクセス許可用セキュリティグループ
- インバウンドルール

－すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.0.0.0/16

2.5 インスタンスの作成と疎通確認

VPC-AのSubnet-A2 (Private)、VPC-BのSubnet-B2 (Private)のそれぞれに、HAクラスター用インスタンスを作成します。
また、VPC-AのSubnet-A1 (Public)にクライアント用インスタンスを作成します。

どちらのインスタンスにも、セキュリティグループに先ほど作成したTransit Gateway経由のアクセス許可用セキュリティグループを含めます。

HAクラスター用インスタンスは、VIP接続を許可するために、[送信元/送信先の変更チェック]を無効にする必要があります。
AWS管理コンソール(EC2)から[アクション]－[ネットワーキング]－[送信元/送信先の変更チェック]を選択し、無効に設定します。各インスタンスのOSでFirewallが有効になっている場合は、いったん無効にするか、ICMP通信が可能となるよう適切に設定します。

インスタンスが起動したら、それぞれのインスタンスから他のインスタンスのPrivateアドレスに対してPingを行います。
適切にルーティング、セキュリティグループの設定ができていればPingが成功します。
（この時点ではまだVIPに対するPing確認はできないことにご注意ください）

2.6 CLUSTERPROによるHAクラスターの作成

「VIP制御によるHAクラスター」を構築します。CLUSTERPROの構成は以下の通りです。
CLUSTERPROのフェールオーバーグループには「AWS 仮想IPリソース」、「ミラーディスクリソース」の2つを登録します。

CLUSTERPRO

－フェールオーバーグループ (failover)

■AWS 仮想IPリソース

・IPアドレス：172.16.0.1
・VPC ID：vpc-1234abcd ★VPC AのVPC ID
・VPC ID：vpc-5678cdef ★VPC BのVPC ID

■ミラーディスクリソース(Windows版)

・データパーティション：M:\
・クラスタパーティション：R:\

■ミラーディスクリソース(Linux版)

・データパーティション：/dev/nvme1n1p2
・クラスタパーティション：/dev/nvme1n1p1

AWS 仮想IPリソースを使用したHAクラスターの構築手順の詳細はAWS構築ガイドをご参照ください。

ただし、AWS 仮想IPリソースのノード別設定を行う際に、VPC IDには
インスタンスが存在するVPCのVPC IDを設定します。

Server-Aのノード別設定

Server-Bのノード別設定

【参考】

CLUSTERPRO X ソフトウェア構築ガイド

Windows > クラウド > Amazon Web Services > HAクラスタ構築ガイド
Linux > クラウド > Amazon Web Services > HAクラスタ構築ガイド

2.7 Transit Gateway ルートテーブル操作用リソースの追加、設定

「1.2 CLUSTERPROによるルーティングの制御」に記載の通り、マルチリージョンもしくはマルチVPCでHAクラスターを構築する場合は、AWS 仮想IPリソースだけでは不十分です。これを補うTGWルーティング用スクリプト(tgw.py)をAWS 仮想IPリソースと同じフェールオーバーグループで実行するようにします。
このスクリプトを実行するリソースを、本ブログでは「TGWルーティング用リソース」と呼びます。

CLUSTERPRO

－フェールオーバーグループ (failover)

■AWS 仮想IPリソース

■ミラーディスクリソース

■TGWルーティング用リソース　　★追加

※ TGWルーティング用スクリプト(tgw.py)は別途提供しております。
ご希望の方は、本ブログ末尾に記載のお問い合わせ窓口から"ご購入前のお問い合わせ"フォームまでお問い合わせください。

TGWルーティング用スクリプトを実行するためにはAWS CLIおよびPythonが実行可能である必要があります。
AWS 仮想IPリソースの起動に成功していれば、AWS CLIおよびPythonはすでにインストール済みです。

1.PyYAMLをインストールします。

PythonモジュールのPyYAMLがインストールされているかどうかを調べます。

pip show pyyaml

もし未インストールであれば、インストールします。

pip install pyyaml

2.TGWルーティング用スクリプトの設定ファイル(tgw.conf)を作成します。
内容の例は次の通りyaml形式で記述します。すべてのインスタンスで共通です。

設定ファイルの記述内容（<>内は実際のホスト名、IDを指定する）

servers:
    <Server-A>:                                  ★Server-Aのホスト名
        vpc: <VPC-A>                            ★Server-Aの属するVPC ID

    <Server-B>:                                  ★Server-Bのホスト名
        vpc: <VPC-B>                            ★Server-Bの属するVPC ID

gateways:
    <tgw-A>:                                      ★東京リージョンのTransit Gateway ID
        type: tgw
      region: ap-northeast-1                ★Transit Gateway Aのリージョン
        routeTable: <Transit Gateway Aのルートテーブル ID>
        attaches:
            <tgw-attach-A>: <VPC-A>    ★VPC-A用TGWアタッチメント ID(VPC)とVPC-AのVPC ID
        peerings:
            <tgw-B>: <tgw-attach-peering>  ★tgw-BのIDとTGWアタッチメント ID(Peering接続)

    <tgw-B>:                                     ★シンガポールリージョンのTransit Gateway ID
        type: tgw
        region: ap-southeast-1              ★Transit Gateway Aのリージョン
        routeTable: <Transit Gateway Bのルートテーブル ID>
        attaches:
            <tgw-attach-B>: <VPC-B>    ★VPC-B用TGWアタッチメント ID(VPC)とVPC-BのVPC ID
        peerings:
            <tgw-A>: <tgw-attach-peering>  ★tgw-AのIDとTGWアタッチメント ID(Peering接続)

実際の設定ファイルの記述例

servers:
    server-a.test.local:
        vpc: vpc-1234abcd

    server-b.test.local:
        vpc: vpc-5678cdef

gateways:
    tgw-aaaaaaaaaaaaaaaaa:
        type: tgw
        region: ap-northeast-1
       routeTable: tgw-rtb-aaaaaaaaaaaaaaaaa
        attaches:
            tgw-attach-aaaaaaaaaaaaaaaaa: vpc-1234abcd
        peerings:
            tgw-bbbbbbbbbbbbbbbbb: tgw-attach-xxxxxxxxxxxxxxxxx

    tgw-bbbbbbbbbbbbbbbbb:
        type: tgw
        region: ap-southeast-1
        routeTable: tgw-rtb-bbbbbbbbbbbbbbbbb
        attaches:
            tgw-attach-bbbbbbbbbbbbbbbbb: vpc-5678cdef
        peerings:
            tgw-aaaaaaaaaaaaaaaaa: tgw-attach-xxxxxxxxxxxxxxxxx

3.TGWルーティング用スクリプト(tgw.py)をHAクラスターを構成するすべてのインスタンスの適当な場所に配置します。すべてのインスタンスで共通のパスとなるようにしてください。
Linuxの場合は実行権限も付与しておきます。

4.TGWルーティング用スクリプトの設定ファイル（tgw.conf）を、同様にHAクラスターを構成するすべてのインスタンスの適当な場所に配置します。tgw.pyと異なる場所でも構いませんが、すべてのインスタンスで共通のパスとなるようにしてください。

5.Windowsであればスクリプトリソース、LinuxであればEXECリソースにおいて、Start Scriptに以下の内容を記述してください。（Stop Scriptには何も設定しません）

Windowsの場合

@echo off
python -B "c:\test\tgw.py" --vip 172.16.0.1 -c "c:\test\tgw.conf" start
exit /B %ERRORLEVEL%

Linuxの場合

#! /bin/sh
/usr/bin/tgw.py --vip 172.16.0.1 -c /etc/tgw.conf start
exit $?

6.Windowsであればカスタム監視リソース、Linuxであればカスタムモニタリソースにおいて、以下の内容を記述してください。
なお、監視タイミングは、TGWルーティングリソースの活性時監視に設定します。

Windowsの場合

@echo off
python -B "c:\test\tgw.py" --vip 172.16.0.1 -c "c:\test\tgw.conf" monitor
exit /B %ERRORLEVEL%

Linuxの場合

#! /bin/sh
/usr/bin/tgw.py --vip 172.16.0.1 -c /etc/tgw.conf monitor
exit $?

注意点

・AWS CLIの実行時に使用されるIAMに、各リージョンのルートテーブル、Transit Gateway ルートテーブルの参照・更新権限が与えられていることを確認してください。
・コマンドにパスが通っていることを確認してください。なお、スクリプトはWindowsの場合はSYSTEMユーザで動作するため、システム環境変数PATHに設定する必要があります。

3. 動作確認

クライアントマシンから、VIPアドレス(172.16.0.1)を使用して、現用系EC2インスタンス（Server-A）、待機系EC2インスタンス（Server- B）にアクセスできることを確認します。

1.現用系EC2インスタンスでフェールオーバーグループを起動します。
2.東京リージョンのクライアントマシンから、VIP(172.16.0.1)にアクセスし、現用系EC2インスタンス（Server- A）に接続できることを確認します。
3.Cluster WebUIから、フェールオーバーグループをシンガポールリージョンの待機系EC2インスタンス（Server- B）に手動で移動します。
4.東京リージョンのクライアントマシンから、VIP(172.16.0.1)にアクセスし、待機系EC2インスタンス（Server- B）に接続できることを確認します。
5.Cluster WebUIから、シンガポールリージョンの待機系EC2インスタンス（Server-B）をシャットダウンします。
6.東京リージョンのクライアントマシンから、VIP(172.16.0.1)にアクセスし、現用系EC2インスタンス（Server- A）に接続できることを確認します。

VIP制御方式のマルチリージョンHAクラスターについて、現用系、待機系の切り替えが行えることを確認できました。

まとめ

今回はTransit Gatewayを使用して、AWS上の異なるリージョンに配置したインスタンスでHAクラスターを構築し、VIP制御方式により現用系/待機系の切り替えが行えることを確認しました。
ディザスタリカバリのために異なるリージョンに配置したいが、サービスにはVIPでアクセスしたいという場合に、是非ご検討ください。

なお、今回ご紹介した構成はクライアントがHAクラスター用インスタンスと同じVPC上にありましたが、HAクラスターとは別の、独立したVPCまたはリージョンにクライアントを配置することも可能です。
このような構成については別途ご紹介していきたいと思います。

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

お問い合わせ

本記事に関するお問い合わせは、 popup

お問い合わせ窓口までお問い合わせください。

※本記事で紹介しているスクリプトの内容についてのお問い合わせ、および、お客様環境に合わせたカスタマイズにつきましてはCLUSTERPRO導入支援サービスにて承っておりますので、上記窓口の"ご購入前のお問い合わせ"フォームまでお問い合わせください。

Tweet
Share

資料請求・お問い合わせ

サイト内の現在位置を表示しています。

AWS Transit Gatewayを利用したHAクラスター構築～マルチリージョン HAクラスター～(Windows/Linux)