Japan
サイト内の現在位置を表示しています。
AWSの大阪リージョンを利用したHAクラスター構築～VIP制御によるマルチリージョンHAクラスター～(Windows/Linux)
CLUSTERPRO オフィシャルブログ ～クラブロ～
はじめに
今回はAmazon Web Services(以降、AWS)の東京リージョンと大阪リージョンを利用したVIP制御によるマルチリージョンHAクラスターの構築を試してみました。
本ブログでは、これまで東京リージョンと大阪リージョンを利用したマルチリージョンHAクラスターをご紹介してきましたが、これらのHAクラスター構成は、いずれも接続先切り替えにAmazon Route53と連携したDNS名を使用する「DNS名制御によるマルチリージョンHAクラスター」でした。
AWSの大阪リージョンを利用したHAクラスター構築～マルチリージョンHAクラスター～
AWSの大阪リージョンを利用したHAクラスター構築～マルチリージョンでハイブリッドディスク型HAクラスター～
昨年の大阪リージョンのアップデートにおいてTransit Gatewayのピアリングアタッチメントがサポートされたことにより、接続先切り替えにVIP(仮想IPアドレス)を利用する「VIP制御によるマルチリージョンHAクラスター」が東京リージョンと大阪リージョン間で構築可能になりましたので、以前公開した以下の記事をベースに改めてHAクラスターの構築手順をご紹介します。
AWS Transit Gatewayを利用したHAクラスター構築～マルチリージョン HAクラスター～(Windows/Linux)
また、上記記事ではクライアントが同一リージョンに存在する想定でしたので、今回は、クライアントがオンプレミス環境に存在する想定で「VIP制御によるマルチリージョンHAクラスター」へのアクセスも試してみます。
【参考】
この記事の内容
1. VIP制御によるマルチリージョンHAクラスターの構成
今回は、東京リージョンと大阪リージョンのVPC環境に「VIP制御によるマルチリージョンHAクラスター」を構築します。
また、オンプレミス環境の疑似環境としてバージニア北部リージョンにクライアントマシンを構築し、「バージニア北部リージョンのVPC」から「東京リージョンのVPC」と「大阪リージョンのVPC」に対してVPNで接続します。
- ※実際にオンプレミス環境から接続する場合は、以降のバージニア北部リージョンをオンプレミス環境に読み替えてください。
構築するHAクラスターの構成図は以下の通りです。
東京リージョンと大阪リージョンにそれぞれHAクラスターを構成するインスタンス（Server-A、Server-B）を配置したマルチリージョン構成です。
インスタンスは異なるリージョンに配置されるため、東京リージョンと大阪リージョンに１つずつTransit Gatewayを作成しています。
HAクラスターを構成するインスタンスはプライベートサブネットに配置しますが、AWS CLIを利用したルートテーブルの制御時にリージョンエンドポイントとの通信を行う必要があるため、パブリックネットワークを作成し、インターネットゲートウェイとNATゲートウェイを追加しています。
接続先切り替えは、東京リージョン、大阪リージョンの各VPC用のルートテーブル、各Transit Gateway用のルートテーブル(以降、TGWルートテーブル)と連携してVIP(仮想IPアドレス)による接続先切り替えを実現します。
インスタンスは異なるリージョンに配置されるため、東京リージョンと大阪リージョンに１つずつTransit Gatewayを作成しています。
HAクラスターを構成するインスタンスはプライベートサブネットに配置しますが、AWS CLIを利用したルートテーブルの制御時にリージョンエンドポイントとの通信を行う必要があるため、パブリックネットワークを作成し、インターネットゲートウェイとNATゲートウェイを追加しています。
接続先切り替えは、東京リージョン、大阪リージョンの各VPC用のルートテーブル、各Transit Gateway用のルートテーブル(以降、TGWルートテーブル)と連携してVIP(仮想IPアドレス)による接続先切り替えを実現します。
- ※ルートテーブルを制御する際に、VPCエンドポイントは使用できません。
VIPの活性時に自リージョンだけでなく他リージョンのルートテーブルも更新する必要がありますが、VPCエンドポイントは自リージョンに対するアクセスしか受け付けないためです。（たとえば東京リージョンのインスタンスからVPCエンドポイントを利用して大阪リージョンのルートテーブルを更新できません）
ルートテーブルの制御の詳細は、以下の記事を参照ください。
- ※以下の記事では、東京リージョンとシンガポールリージョンでHAクラスターを構築しているため、シンガポールリージョンを大阪リージョンに読み替えてください。
2. HAクラスター構築手順
CLUSTERPRO Xを使用した「VIP制御によるマルチリージョンHAクラスター」を構築します。
今回、VPN接続の経路切り替えの手順は割愛します。
HAクラスターの構築手順は、基本的に以下の記事と同様ですが、今回はバージニア北部リージョンが追加となりますので、改めて各種手順について記載します。
2.1 AWS環境の設定
2.1.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-northeast-3)
- 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上に作成)
バージニア北部リージョン (us-east-1)
- VPC(VPC ID：vpc-3333cccc)
- －CIDR：10.2.0.0/16
- －Subnets
- ■Subnet-C1 (Public) ：10.2.10.0/24
- －Internet Gateway
2.1.2. Transit Gatewayの作成
今回は東京リージョンと大阪リージョンに、それぞれTransit Gatewayを作成します。
また、Transit GatewayとVPC、Transit Gateway同士、および、Transit GatewayとVPNで接続するためのTGWアタッチメントも作成します。
- Transit Gateway A [tgw-A]
- －TGWアタッチメント (VPCタイプ、VPC-Aと接続) [tgw-attach-A]
- －TGWアタッチメント (Peering接続タイプ、Transit Gateway Bと接続) [tgw-attach-peering]
- －TGWアタッチメント (VPNタイプ、VPC-Cと接続) [tgw-attach-vpn-A]
- Transit Gateway B [tgw-B]
- －TGWアタッチメント (VPCタイプ、VPC-Bと接続) [tgw-attach-B]
- －TGWアタッチメント (Peering接続タイプ、Transit Gateway Aと接続) [tgw-attach-peering]
※東京リージョンで作成したTGWアタッチメントを承諾 - －TGWアタッチメント (VPNタイプ、VPC-Cと接続) [tgw-attach-vpn-B]
VPCタイプとVPNタイプのTGWアタッチメントは、東京リージョンと大阪リージョンでそれぞれ1つずつ作成します。
VPNタイプのTGWアタッチメントの作成すると、合わせてVPN接続が作成されます。作成されたVPN接続から設定情報をダウンロードしておきます。
取得した設定情報は、バージニアリージョンのvyosの設定に使用します。
Peering接続タイプのTGWアタッチメントは、東京リージョンと大阪リージョンのどちらか一方のリージョンでのみ作成します。その後、もう一方のリージョンで作成したTGWアタッチメントに対してAccept操作を行います。
Transit Gateway、各TGWアタッチメントの作成手順は以下を参考にしました。
Transit Gateway、VPCタイプとVPNタイプのTGWアタッチメントの作成手順は割愛します。
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: Osaka (ap-northeast-3)
Transit Gateway (accepter): 大阪リージョンのTransit Gateway ID
Attachment type: Peering Connection
Attachment name tag: 識別可能な任意のアタッチメント名
Account: My account
Region: Osaka (ap-northeast-3)
Transit Gateway (accepter): 大阪リージョンのTransit Gateway ID
- 2.大阪リージョンでTGWアタッチメント（Peering接続タイプ）に対するAccept操作を行う。
リージョンを大阪リージョンに切り替え、先ほど作成したTGWアタッチメントが大阪リージョン側にも表示されていることを確認します。
大阪リージョン側でのTGWアタッチメントの状態が"pending acceptance"のため、そのままでは機能しません。
TGWアタッチメントを選択し、[アクション]－[Trasit Gatewyアタッチメントの承諾]を選択し、状態が[available]になるまで待ちます。
2.1.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との通信用 |
| 10.2.0.0/16 | tgw-A | VPC-Cとの通信用 |
| 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との通信用 |
| 10.2.0.0/16 | tgw-A | VPC-Cとの通信用 |
| 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との通信用 |
| 10.2.0.0/16 | tgw-attach-vpn-A | VPC-Cとの通信用 |
| 172.16.0.1/32 | tgw-attach-A | VIP用、ターゲットは仮指定 |
- 大阪リージョン (ap-northeast-3)
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との通信用 |
| 10.2.0.0/16 | tgw-B | VPC-Cとの通信用 |
| 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との通信用 |
| 10.2.0.0/16 | tgw-B | VPC-Cとの通信用 |
| 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との通信用 |
| 10.2.0.0/16 | tgw-attach-vpn-B | VPC-Cとの通信用 |
| 172.16.0.1/32 | tgw-attach-B | VIP用、ターゲットは仮指定 |
- バージニア北部リージョン (us-east-1)
VPC-C Subnet-C1 (Public) 用ルートテーブル
| 送信先 | ターゲット | 備考 |
|---|---|---|
| 0.0.0.0/0 | Internet Gateway | Internet通信用 |
| 10.2.0.0/16 | local | VPC内通信用 |
| 10.0.0.0/16 | vyosのENI ID | VPC-Aとの通信用 |
| 10.1.0.0/16 | vyosのENI ID | VPC-Bとの通信用 |
| 172.16.0.1/32 | vyosのENI ID | VIP用 |
2.1.4 セキュリティグループの作成
各VPCにおいてセキュリティグループを作成します。
セキュリティグループは、システムのポリシーに応じて適切に設定してください。
今回はさらにVPC間をTransit Gateway経由で接続するため、Transit Gateway経由でのアクセスを許可するセキュリティグループも以下の通り作成します。
東京リージョン (ap-northeast-1)
・Transit Gateway経由のアクセス許可用セキュリティグループ
- インバウンドルール
- インバウンドルール
- －すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.1.0.0/16
- －すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.2.0.0/16
大阪リージョン (ap-northeast-3)
・Transit Gateway経由のアクセス許可用セキュリティグループ
- インバウンドルール
- インバウンドルール
- －すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.0.0.0/16
- －すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.2.0.0/16
バージニア北部リージョン (us-east-1)
・Transit Gateway(VPN)経由のアクセス許可用セキュリティグループ
- インバウンドルール
- インバウンドルール
- －すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.0.0.0/16
- －すべてのトラフィック、すべてのプロトコル・ポート範囲、ソース:10.1.0.0/16
2.1.5 インスタンスの作成と疎通確認
VPC-AのSubnet-A2 (Private)、VPC-BのSubnet-B2 (Private)のそれぞれに、HAクラスター用インスタンスを作成します。
また、VPC-CのSubnet-C1 (Public)にクライアント用インスタンス、vyos用インスタンスを作成します。
各インスタンスのセキュリティグループに先ほど作成したTransit Gateway経由のアクセス許可用セキュリティグループを追加します。
HAクラスター用インスタンスは、VIP接続を許可するために、[送信元/送信先チェック]を停止する必要があります。
AWSマネジメントコンソールから[アクション]－[ネットワーキング]－[送信元/送信先チェック]を選択し、停止を設定します。各インスタンスのOSでFirewallが有効になっている場合は、いったん無効にするか、ICMP通信が可能となるよう適切に設定します。
vyos用インスタンスについても、[送信元/送信先チェック]を停止する必要があります。また、「2.1.2. Transit Gatewayの作成」でVPNタイプのTGWアタッチメントを作成した際に入手したVPN接続の設定情報を投入し、VPN接続を有効にします。合わせて、VIP(172.16.0.1)の通信がTransit Gatewayへ向かうようにvyosに設定を追加します。
各インスタンスが起動したら、それぞれのインスタンスから他のインスタンスのPrivateアドレスに対してPingを行います。
適切にルーティング、セキュリティグループの設定ができていればPingが成功します。
（この時点ではまだVIPに対するPingによる接続確認はできません）
2.2 VPC制御によるマルチリージョンHAクラスターの構築
2.2.1 CLUSTERPROによるHAクラスターの作成
今回の検証ではCLUSTERPRO X 4.3を利用しています。(Windows：内部Ver. 12.30、Linux：内部Ver. 4.3.0-1)
「VIP制御によるHAクラスター」を構築します。CLUSTERPROの構成は以下の通りです。
CLUSTERPROのフェールオーバーグループには「AWS 仮想IPリソース」、「ミラーディスクリソース」の2つを登録します。
- CLUSTERPRO
- －フェールオーバーグループ (failover)
- ■AWS 仮想IPリソース
- ・IPアドレス：172.16.0.1
- Server-A
- ・VPC ID：vpc-1234abcd ★VPC AのVPC ID
- ・ENI ID：eni-xxxxxxxxxxxxxxxxx ★Server-AのENI ID
- Server-B
- ・VPC ID：vpc-5678cdef ★VPC BのVPC ID
- ・ENI ID：eni-yyyyyyyyyyyyyyyyy ★Server-BのENI ID
- ■ミラーディスクリソース(Windows版)
- ・データパーティション：M:\
- ・クラスタパーティション：R:\
- ■ミラーディスクリソース(Linux版)
- ・データパーティション：/dev/nvme1n1p2
- ・クラスタパーティション：/dev/nvme1n1p1
AWS 仮想IPリソースを使用したHAクラスターの構築手順の詳細はAWS構築ガイドをご参照ください。
AWS 仮想IPリソースのノード別設定を行う際に、VPC IDにはインスタンスが存在するVPCのVPC IDを設定します。
Server-Aのノード別設定
Server-Bのノード別設定
【参考】
- Windows > クラウド > Amazon Web Services > HAクラスタ構築ガイド
- Linux > クラウド > Amazon Web Services > HAクラスタ構築ガイド
2.2.2 Transit Gateway ルートテーブル操作用リソースの追加、設定
マルチリージョンもしくはマルチVPCでHAクラスターを構築する場合は、AWS 仮想IPリソースの設定に加え、TGWルーティング用スクリプト(tgw.py)をAWS 仮想IPリソースと同じフェールオーバーグループで実行するように設定します。
このスクリプトを実行するリソースを、本記事では「TGWルーティング用リソース」と呼びます。
- CLUSTERPRO
- －フェールオーバーグループ (failover)
- ■AWS 仮想IPリソース
- ■ミラーディスクリソース
- ■TGWルーティング用リソース ★追加
- ※ TGWルーティング用スクリプト(tgw.py)は別途提供しております。
ご希望の方は、本記事末尾に記載のお問い合わせ窓口から"ご購入前のお問い合わせ"フォームまでお問い合わせください。
TGWルーティング用スクリプトを実行するためにはAWS CLIおよびPythonが実行可能である必要があります。
各HAクラスター用インスタンスで以下の設定を実施します。
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>: ★tgw-AのTransit Gateway ID
type: tgw
region: <region-name> ★tgw-Aのリージョン名
routeTable: <tgw-route-table> ★tgw-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>: ★tgw-BのTransit Gateway ID
type: tgw
region: <region-name> ★tgw-Bのリージョン名
routeTable: <tgw-route-table> ★tgw-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接続)
<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>: ★tgw-AのTransit Gateway ID
type: tgw
region: <region-name> ★tgw-Aのリージョン名
routeTable: <tgw-route-table> ★tgw-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>: ★tgw-BのTransit Gateway ID
type: tgw
region: <region-name> ★tgw-Bのリージョン名
routeTable: <tgw-route-table> ★tgw-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-northeast-3
routeTable: tgw-rtb-bbbbbbbbbbbbbbbbb
attaches:
tgw-attach-bbbbbbbbbbbbbbbbb: vpc-5678cdef
peerings:
tgw-aaaaaaaaaaaaaaaaa: tgw-attach-xxxxxxxxxxxxxxxxx
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-northeast-3
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には何も設定しません）
※ tgw.py、tgw.conf のパスには 3.及び 4.で配置したパスを指定します。
Windowsの場合
@echo off
python -B "c:\test\tgw.py" --vip 172.16.0.1 -c "c:\test\tgw.conf" start
exit /B %ERRORLEVEL%
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 $?
/usr/bin/tgw.py --vip 172.16.0.1 -c /etc/tgw.conf start
exit $?
- 6.Windowsであればカスタム監視リソース、Linuxであればカスタムモニタリソースにおいて、以下の内容を記述してください。
なお、監視タイミングは、TGWルーティングリソースの活性時監視に設定します。
※ tgw.py、tgw.conf のパスには 3.及び 4.で配置したパスを指定します。
Windowsの場合
@echo off
python -B "c:\test\tgw.py" --vip 172.16.0.1 -c "c:\test\tgw.conf" monitor
exit /B %ERRORLEVEL%
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 $?
/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クラスターについて、現用系、待機系の切り替えが行えることを確認できました。
まとめ
今回は東京リージョンと大阪リージョンを使用したVIP制御によるマルチリージョンHAクラスターを構築しました。
国内リージョンにおけるマルチリージョンHAクラスターでも、Transit Gatewayを使用してVIP制御方式により現用系/待機系の切り替えが行えます。異なるリージョンやオンプレミス環境からの接続も可能ですので、ディザスタリカバリのために異なるリージョンに配置したいが、サービスにはVIPでアクセスしたいという場合に、是非ご検討ください。
本記事の構成をご検討の際は、CLUSTERPROの試用版を用いて検証した後、ご提案・構築ください。
お問い合わせ
本記事に関するお問い合わせは、お問い合わせ窓口までお問い合わせください。
お問い合わせ窓口までお問い合わせください。- ※本記事で紹介しているスクリプトの内容についてのお問い合わせ、および、お客様環境に合わせたカスタマイズにつきましてはCLUSTERPRO導入支援サービスにて承っておりますので、上記窓口の"ご購入前のお問い合わせ"フォームまでお問い合わせください。
