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

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

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

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

    目次

    1 TransitGatewayとは
    2 TransitGatewayのコスト
    3 HAクラスターと組み合わせた時のメリット
    4 実際に検証した手順と結果


    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クラスタの構成もっと詳しく知りたい方は、こちらの動画をご覧ください。

     

    アジェンダ
    ・AWS TransitGatewayについて
    ・TransitGatewayを使わないHAクラスター構成
    ・TransitGatewayを使った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

    EC2 RK利用シナリオ

    ルートテーブルシナリオ

    ※通常の利用方法と同じ

    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

    環境の構築手順

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

    1. VPC/ネットワーク/インスタンス作成 構成に合わせてAWS環境を作成。 ※VyOSはマーケットプレイスから選択して作成(この段階では作成のみ)
    2. クラスターの構築 EC2 RK(ルートテーブルシナリオ)を使用してクラスターを構築します。 ※合わせて下記の詳細な構築手順ガイドをご参照ください。 →[AWS EC2環境でのHAクラスター構築 Step by Step ガイド]
    1. TransitGateway作成 クラスターサーバーを配置しているVPCでTransitGatewayを作成。 作成したTransitGatewayにVPN接続を追加。
    2. VPNの設定 コンフィグを構成に合わせて変更。
    3. Transit GatewayにVPCをアタッチ Transit GatewayにVPCをアタッチして、Transit Gateway側で必要なルーティングを追加します。 ※仮想IPへのルーティングは手動で設定する必要があります。 ※クラスター側のルートテーブルへの設定追加を忘れないようにしてください。

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

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

       

      • 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

    以上。

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

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

     

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

    SNSでもご購読できます。