1. /
  2. /
  3. AWS Transit Gatewayを使用したHAクラスタ構成を試してみました

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

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

    本日はAWSのTransit Gatewayを使用したLifeKeeperの構成を試した所、一通りの動作が問題なく確認できましたことをご報告いたします。

    AWS上での高可用性ソリューション

    当社のHAクラスターソリューションのLifeKeeperは、AWS上での冗長構成を標準機能でサポートしています。この標準機能を使うことで、個別に制御スクリプトを開発すること無く、AWS上でのAZ（Availability　Zone）を跨いだHAクラスターを短工数で構築できます。
    現時点で対応しているのは下記の構成です。※図では省略していますが、いずれの構成もAZを跨いだ構成を前提としています。

    aws_lk_design_patern

    この4つの構成の中で主に使われているのが、「ルートテーブルシナリオ」と「オンプレミスからの接続」の２つのパターンです。

    ルートテーブルシナリオ

    AWS上のHAクラスター構成に対してクライアントが同一のVPCにある場合は、ルートテーブルシナリオがよく使われます。これはクライアントに対してダミーの仮想IPアドレスにアクセスさせ、実際にはルートテーブルを使ってルーティングの制御を行います。

    aws_lk_routetable_scenario

    オンプレミスからの接続

    一方、AWS上のHAクラスター構成に対して、クライアントがVPCの外部…例えばオンプレミスの環境からDirect Connectを使ってアクセスする場合はAWSの制約でルートテーブルシナリオが使えないので、Route53を使ってホスト名の名前解決でルーティングの制御を行います。]

    aws_lk_route53_scenario

    Transit Gatewayの利用

    Transit Gatewayは2018年11月に登場した新しいサービスで、VPC間をハブ・アンド・スポーク方式でつなぐことが可能です。例えば「オンプレ－VPC」や「VPC－VPC」といった接続を単一のゲートウェイで実現できます。

    →[AWS Transit Gateway]
    https://aws.amazon.com/jp/transit-gateway/

    LifeKeeperの観点でどんなメリットがあるかというと、クライアントがVPC外部にある場合でもルートテーブルシナリオを使える点にあります。ルートテーブルシナリオではVPCのCIDR外の「ダミーの仮想IP」をVPC内部のクライアントが使いますが、これはVPCのCIDR外のアドレスなのでVPCの外部のクライアントからはアクセスできません。Transit Gatewayを使うと、VPC外部からダミーの仮想IPにアクセスが可能になるので、VPC外部からでもルートテーブルシナリオが使えるのです。
    Route53を使った制御は、システム要件でホスト名によるアクセスができない場合は使えないといったケースもあるので、Transit Gatewayとルートテーブルシナリオの組み合わせは今後適用が増えると考えております。

    そこで当社では、シンガポールリージョンと東京リージョン間をTransit GatewayとVPNでつないで、LifeKeeperが切り替わるかどうかの簡易的なテストを行いました。構成イメージは下記になります。

    aws_lk_transitgw_design

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

    お問合せフォーム：お問い合わせ
    関連ソリューション：Amazon EC2上での可用性向上

    以降、検証内容の詳細。

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

    踏み台サーバー

    ・クラスタサーバーを操作するための踏み台用

    ・同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

    〇

    以上。

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

    お問合せフォーム：お問い合わせ

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

    SNSでもご購読できます。