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

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

CLUSTERPRO オフィシャルブログ ~クラブロ~

はじめに

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)を配置したマルチリージョン構成です。

インスタンスは異なるリージョンに配置されるため、各リージョンに1つずつ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接続の2種類を使用しています。
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、サブネットの作成

まず、VIPやサブネットなどを作成します。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つのリージョンを使用するため、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のノード別設定

AWS_VIP1

Server-Bのノード別設定

AWS_VIP2

【参考】
  • 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導入支援サービスにて承っておりますので、上記窓口の"ご購入前のお問い合わせ"フォームまでお問い合わせください。