AWS Transit Gatewayを使用したHAクラスタ構成を試してみました

皆さんこんにちは。東の西下です。

あまり冬らしい季節が来ないまま春になってきましたね。
AWSの構築の現場でもTransit Gateway（トランジットゲートウェイ）の採用がよく聞かれるようになってきました。このTransit Gatewayを使うとHAクラスターの構築がシンプルになりとてもメリットがあります。

どう使うと、どんなメリットが有るのか、そして実際の設定例をご説明いたします。

Transit Gatewayとは

Transit Gatewayは2018年11月に登場したサービスで、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クラスターを短工数で構築できます。

現時点で対応しているのは下記の構成です。
※下図では省略していますが、いずれの構成も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クラスタの構成もっと詳しく知りたい方は、こちらの動画をご覧ください。

LifeKeeperはいち早くTransit GatewayをサポートしたHAクラスター製品です。既に導入実績も増えてきていますので、ぜひ採用をご検討ください。

また、当社ではTransit GatewayとLifeKeeperとを組み合わせたハンズオンセミナーを不定期に開催しています。下記の2通りの構成で実施しています。次回開催予定またはセミナーの資料をご希望の方は下記からお気軽にお問い合わせください。
→[お問い合わせ]
　　

＜Windows版のJP1/ASJ3 – ManagerとLifeKeeperとの組み合わせ＞

＜Linux版のHULFTとLifeKeeperとの組み合わせ＞

実際に検証した手順と結果

ここからは、実際にTransitGatewayを使ったHAクラスタ構成の実施環境及び検証手順についてご紹介いたします。※2019年9月17日時点

環境と検証パターン

各サーバーの役割は下記のとおりです。

構成は下記のとおりです。

検証パターン1：LifeKeeper for Linux

検証パターン2：LifeKeeper for Windows

ネットワーク構成は下記のとおりです。

・シンガポールリージョン

・東京リージョン

各インスタンスのプライベートIPと仮想IPは下記のとおりです。

・検証パターン1：LifeKeeper for Linux

・検証パターン2：LifeKeeper for Windows

環境の構築手順

環境の大まかな構築手順は下記のとおりです。

下記のテストの範囲では、問題なく通信と切り替わりを確認できました。

• 踏み台サーバーからクラスタサーバーへの疎通確認 主旨：通常のルートテーブルシナリオが動作することの確認。

   

  • 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

・LifeKeeper for Windows

以上。

LifeKeeperを使ったAWS上でのHAクラスタ構築手順書を公開しております。ご興味がございましたらぜひ資料請求ページからお申込みください。

本検証についてのお問い合わせはこちらから気軽にお願いします。

関連ソリューション：Amazon EC2上での可用性向上