
皆さんこんにちは。LifeKeeperプリセールスの西下です。
AWSの構築の現場でもTransit Gateway(トランジットゲートウェイ)の採用がよく聞かれるようになってきました。このTransit Gatewayを使うとHAクラスターの構築がシンプルになりとてもメリットがあります。
どう使うと、どんなメリットが有るのか、そしてTransit Gatewayを使ったHAクラスター構成の設定例をご説明いたします。
Transit Gatewayとは
Transit Gatewayは2018年11月に登場したAWSのネットワークサービスで、VPC間をハブ・アンド・スポーク方式でつなぐことによりネットワーク接続をシンプルにできるサービスです。例えば「オンプレ-VPC」や「VPC-VPC」といった接続を単一のゲートウェイで実現できます。
従来の方法では、複数のアカウントの運用で複数のVPCの管理が必要になった場合、VPC間のピアリングやVPN、Direct Connect接続要件があれば経路は複雑になり、その分運用コストも増えてしまいますが、Transit Gatewayを使うことで、経路を集約して管理することができます。
詳しくは公式のドキュメントをご参照ください。→[AWS Transit Gateway]
Transit Gatewayの料金
Transit Gatewayの利用料金は従来の方式と比べて高いのでしょうか?安いのでしょうか?
Transit Gatewayの1アタッチメントにつき1時間あたり0.07USDかかります。処理データについては1GBあたり0.02USDかかります。 →[AWS Transit Gateway の料金]
Transit Gatewayの料金はVPNの料金に追加されるので、それだけを聞くと割高な印象を受けてしまいます。しかしVPCの数が増えてくればVPC間のピアリングの経路の組み合わせが掛け算で爆発的に増えてきます。これらの多くのVPCピアリングの設定コストを、Transit Gatewayはハブ・アンド・スポーク方式のシンプルな構成で埋めてくれるので、VPCが増えれば割安になります。
HAクラスターと組み合わせた時のメリット
さて、このTransit GatewayはHAクラスターの観点でどんなメリットがあるかというと、HAクラスターの構成に関わらず、1つのシンプルな構成で構築できる点にあります。ここをご理解いただくために、少し製品の話をさせて頂きます。
当社のHAクラスターソリューションのLifeKeeperは、AWS上での冗長構成を標準機能でサポートしています。この標準機能を使うことで、個別に制御スクリプトを開発すること無く、AWS上でのAZ(Availability Zone)を跨いだHAクラスターを短工数で構築できます。
現時点でLifeKeeperが対応しているのは下記の構成です。
※下図では省略していますが、いずれの構成もAZを跨いだ構成を前提としています。
<製品の標準機能でサポートされるHAクラスター構成>
この4つの構成の中で主に使われているのが、「ルートテーブルによる制御」と「Route53による制御」です。
ルートテーブルによる制御「ルートテーブルシナリオ」
AWS上のHAクラスター構成に対してクライアントが同一のVPCにある場合は、ルートテーブルシナリオがよく使われます。これはクライアントに対してVPCのレンジ外を指しているダミーの仮想IPアドレスにアクセスさせ、ルートテーブルを使ってルーティングの制御を行います。
<ルートテーブルシナリオの概念図>
Route53による制御
一方、AWS上のHAクラスター構成に対して、クライアントがVPCの外部…例えばオンプレミスの環境からDirect Connectを使ってアクセスする場合は、AWSの仕様上VPC外部からダミーの仮想IPによるルーティング制御ができません。このためRoute53を使ってホスト名の名前解決でルーティングの制御を行います。
<Route53による制御の概念図>
Transit Gatewayを使うと「ルートテーブルシナリオ」1つでまかなえる
LifeKeeperの観点でどんなメリットがあるかというと、クライアントがVPC外部にある場合でもルートテーブルシナリオを使える点にあります。ルートテーブルシナリオではVPCのCIDR外の「ダミーの仮想IP」をVPC内部のクライアントが使いますが、これはVPCのCIDR外のアドレスなのでVPCの外部のクライアントからはアクセスできません。Transit Gatewayを使うと、VPC外部からダミーの仮想IPにアクセスが可能になるので、VPCの外からでもルートテーブルシナリオが使えるのです。
Route53を使った制御は、システム要件でホスト名によるアクセスができない場合は使えないといったケースがあり、また、TTLなどDNSの設計の負担も増えます。Transit Gatewayとルートテーブルシナリオの組み合わせにより、今後シンプルな構成で効率的な構築が実現します。
<Transit GatewayとLifeKeeperを組み合わせた概念図>
このTransitGatewayとHAクラスタの構成についてもっと詳しく知りたい方は、こちらの動画をご覧ください。
アジェンダ ・AWS TransitGatewayについて ・TransitGatewayを使わないHAクラスター構成 ・TransitGatewayを使ったHAクラスター構成 |
Transit Gatewayを使ったHAクラスター構築ハンズオン
LifeKeeperはいち早くTransit GatewayをサポートしたHAクラスター製品です。既に導入実績も増えてきていますので、ぜひ採用をご検討ください。
また、当社ではTransit GatewayとLifeKeeperとを組み合わせたハンズオンセミナーを不定期に開催しています。下記の2通りの構成で実施しています。次回開催予定またはセミナーの資料をご希望の方は下記からお気軽にお問い合わせください。
→[お問い合わせ]
Windows版のJP1/ASJ3 – ManagerとLifeKeeperとの組み合わせ
Linux版のHULFTとLifeKeeperとの組み合わせ
実際に検証した手順と結果
ここからは、実際にTransitGatewayを使ったHAクラスタ構成の実施環境及び検証手順についてご紹介いたします。※2019年9月17日時点
環境と検証パターン
各サーバーの役割は下記のとおりです。
踏み台サーバー | ・クラスタサーバーを操作するための踏み台用 ・同VPC内でのルートテーブルシナリオ確認用 |
クラスタサーバーA | LifeKeeperを利用したクラスタ用 |
クラスタサーバーB | LifeKeeperを利用したクラスタ用 |
VyOSサーバー | VPNを張るためのルータ用 |
クライアントサーバー | 別のVPCから仮想IPへのアクセスの確認用 |
構成は下記のとおりです。
検証パターン | LifeKeeper for LinuxとLifeKeeper for Windows |
利用ARK | IP ARKとRecovery Kit for EC2™ |
RK for EC2™利用シナリオ | ルートテーブルシナリオ ※通常の利用方法と同じ |
IP ARK保護IPアドレス | いずれのVPCのCIDRにも含まれないアドレス |
保護アプリケーション | なし。疎通確認が目的のため。 |
クラスタ構成 | 2ノード構成 Active-Standby |
インスタンスタイプ | t2.micro ※VyOSのみt3.large(該当AMI利用可能範囲の関係) |
検証パターン1:LifeKeeper for Linux
OS | RedHat Enterprise Linux 7.4 64bit |
LifeKeeper | SIOS Protection Suite for Linux 9.3.2 |
検証パターン2:LifeKeeper for Windows
OS | Windows Server 2016 64bit |
LifeKeeper | SIOS Protection Suite for Windows 8.6.3 |
ネットワーク構成は下記のとおりです。
・シンガポールリージョン
VPC | 10.226.0.0/16 |
サブネットA(AZ-A) | 10.226.1.0/24 |
サブネットB(AZ-B) | 10.226.2.0/24 |
サブネットC(AZ-A) | 10.226.3.0/24 |
・東京リージョン
VPC | 99.99.0.0/16 |
サブネットA(AZ-A) | 99.99.99.0/24 |
各インスタンスのプライベートIPと仮想IPは下記のとおりです。
・検証パターン1:LifeKeeper for Linux
踏み台サーバー | 10.226.3.31 |
クラスタサーバーA | 10.226.1.101 |
クラスタサーバーB | 10.226.2.102 |
仮想IPアドレス | 111.111.111.111 |
VyOSサーバー | 99.99.99.10 |
クライアントサーバー | 99.99.99.99 |
・検証パターン2:LifeKeeper for Windows
踏み台サーバー | 10.226.3.31 |
クラスタサーバーA | 10.226.1.11 |
クラスタサーバーB | 10.226.2.12 |
仮想IPアドレス | 100.100.100.100 |
VyOSサーバー | 99.99.99.10 |
クライアントサーバー | 99.99.99.99 |
環境の構築手順
環境の大まかな構築手順は下記のとおりです。
|
下記のテストの範囲では、問題なく通信と切り替わりを確認できました。
- 踏み台サーバーからクラスタサーバーへの疎通確認 主旨:通常のルートテーブルシナリオが動作することの確認。
- IPリソースを切り替えながら、Activeノードの仮想IPへアクセスできることを確認。
- 実IPへのアクセスも確認。
- クライアントサーバーからクラスタサーバーへのpingでの疎通確認 主旨:TransitGatewayの設定が正しくできているかを実IPでのアクセスによる確認。
- IPリソースを切り替えながら、仮想IPアドレス(Activeノード)へアクセスできることを確認
- 実IPへのアクセスも確認。
- クライアントサーバーからクラスタサーバーへのRDP/SSHでの疎通確認 主旨:TransitGatewayでping以外の方法(RDP/SSH)でも通信ができることの確認。
- IPリソースを切り替えながら、仮想IPアドレス(Activeノード)へアクセスできることを確認
- 実IPへのアクセスも確認。
- クラスタサーバーからクライアントサーバーへの疎通確認 主旨:仮想IPを送信元とした通信に失敗することがないかの確認
- Active側のクラスタサーバーからping実行時に仮想IPを送信元としてクライアントサーバーへ接続を確認。
・LifeKeeper for Linux
Case | 方法 | 通信元サーバー | 通信元IP | 通信先サーバー | 通信先IP | 結果 |
1 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーA | 10.226.1.101 | 〇 |
2 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーB | 10.226.2.102 | 〇 |
3 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーA | 111.111.111.111 | 〇 |
4 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーB | 111.111.111.111 | 〇 |
5 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーA | 10.226.1.101 | 〇 |
6 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーB | 10.226.2.102 | 〇 |
7 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーA | 111.111.111.111 | 〇 |
8 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーB | 111.111.111.111 | 〇 |
9 | SSH | クライアントサーバー | 99.99.99.99 | クラスタサーバーA | 111.111.111.111 | 〇 |
10 | SSH | クライアントサーバー | 99.99.99.99 | クラスタサーバーB | 111.111.111.111 | 〇 |
11 | Ping | クラスタサーバーA | 111.111.111.111 | クライアントサーバー | 99.99.99.99 | 〇 |
12 | Ping | クラスタサーバーB | 111.111.111.111 | クライアントサーバー | 99.99.99.99 | 〇 |
・LifeKeeper for Windows
Case | 方法 | 通信元サーバー | 通信元IP | 通信先サーバー | 通信先IP | 結果 |
1 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーA | 10.226.1.11 | 〇 |
2 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーB | 10.226.2.12 | 〇 |
3 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーA | 100.100.100.100 | 〇 |
4 | Ping | 踏み台サーバー | 10.226.3.31 | クラスタサーバーB | 100.100.100.100 | 〇 |
5 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーA | 10.226.1.101 | 〇 |
6 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーB | 10.226.2.102 | 〇 |
7 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーA | 100.100.100.100 | 〇 |
8 | Ping | クライアントサーバー | 99.99.99.99 | クラスタサーバーB | 100.100.100.100 | 〇 |
9 | RDP | クライアントサーバー | 99.99.99.99 | クラスタサーバーA | 100.100.100.100 | 〇 |
10 | RDP | クライアントサーバー | 99.99.99.99 | クラスタサーバーB | 100.100.100.100 | 〇 |
11 | Ping | クラスタサーバーA | 100.100.100.100 | クライアントサーバー | 99.99.99.99 | 〇 |
12 | Ping | クラスタサーバーB | 100.100.100.100 | クライアントサーバー | 99.99.99.99 | 〇 |
検証結果は以上です。
TransitGatewayとHAクラスタの構成についてもっと詳しく知りたい方は、こちらの動画をご覧ください。
アジェンダ ・AWS TransitGatewayについて ・TransitGatewayを使わないHAクラスター構成 ・TransitGatewayを使ったHAクラスター構成 |
関連情報
下記ページではLifeKeeperを使ったAWS上でのHAクラスター構築手順を公開しています。