皆さんこんにちは、西下です。
先日こちらのブログで、Azureのクロスリージョン構成をLifeKeeperがサポート開始した旨*1をご紹介しました。
昨今の自然災害の増加などの背景から、Amazon Web ServicesやMicrosoft Azureといったパブリッククラウド環境で、リージョンを跨いだHAクラスター構成（DR要件）のご要望が増えています。
LifeKeeperは、Amazon EC2環境では既にリージョンを跨いだHAクラスター構成に対応しています。
詳しくは下記のマニュアルをご参照下さい。
- Linux版：AWS VPC ピアリング接続を使用した複数 VPC クラスター構成クイックスタートガイド
- Windows版：AWS VPC ピアリング接続を使用した複数 VPC クラスター構成クイックスタートガイド
上記は、Route53でホスト名の名前解決を行い、解決した「実IP」に向けて通信が行われる方式です。クラスターが切り替わる時には、LifeKeeperのRecovery Kit for Route53*2がAWS CLIを使ってRoute53のAレコードを書き換えることで、待機系の実IPに向けて通信が行われます。
最近は、LifeKeeperの保護対象のソフトウェアの事情により、「実IP」ではなく切り替えの前後で同じIPアドレスを使える「仮想IP」を使うご要望が増えてきています。そこでクライアントから仮想IPに向けて通信することで、Activeノードへ到達する新機能がLifeKeeper for Linuxで2025年2月からリリースされました。（LifeKeeper for Windowsでも追ってリリース予定）
当ブログではこの新機能についてご紹介致します。
当機能が想定している構成です。
HAクラスターはリージョンAとリージョンBを跨いで構成されています。クライアントはリージョンA、B、Cのいずれかにあることを想定しています。
各クライアントからPrimaryノードへの通信は、↓の図のイメージとなります。各VPCのルートテーブルと各Transit Gatewayのルートテーブルは、送信先が仮想IPのエントリーの転送先をLifeKeeperから制御します。これにより、各クライアントから仮想IPに向けて通信することでPrimaryノードへ到達します。
クラスターの切り替わり時には、LifeKeeperのクラスターリソース情報にセットされた仮想IPアドレスをキーに必要情報を芋づる式に取得し、ルートテーブルに仮想IPのエントリーが存在すれば、転送先を適宜変更して通信制御が行われます。
クラスターが切り替わると、各クライアントからBackupノードへの通信は、↓の図のイメージとなります。各クライアントから仮想IPに向けて通信することでBackupノードへ到達します。
※当構成の条件は下記のとおりです。
- EC2インスタンス、VPC、TransitGateway等、上記構成図に含まれるオブジェクトは全て同一AWSアカウントに所属
- クラスタノードからAmazon EC2サービスのエンドポイントにHTTPおよびHTTPSを使用してアクセスできること
当機能は「Generic ARK for AWS Transit Gateway」として提供されます。
制御スクリプトと管理ガイドはこちらでご入手頂けます。
→[Linux] AWSのクロスリージョン環境において仮想IPで通信できる構成をサポート
リージョンを跨いだHAクラスター構成に仮想IPで接続するご要件をお持ちの方は、ぜひお試し下さい。
■参考情報
AWSのユースケースページ（LifeKeeper製品サイト）
■脚注
*1：Azureのクロスリージョン構成に関するマニュアル
- 概要：Azure Global Load Balancer(リージョン間ロードバランサー)シナリオ
- ロードバランサーの設定：Azure – Global Load Balancer(リージョン間ロードバランサー)の作成
*2：Recovery Kit for Route53は、クラスターの切り替え時にLifeKeeperからAWS CLIを介してRoute53のAレコードをStandby側の実IPアドレスに書き換える標準機能です。クライアントはホスト名の名前解決をRoute53で行うことで、実IPに向けて通信することでActiveノードへ到達できます。
