皆さんこんにちは、西下です。
昨今の自然災害の増加などの背景から、Amazon Web ServicesやMicrosoft Azureといったパブリッククラウド環境で、リージョンを跨いだHAクラスター構成（DR要件）のご要望が増えています。
LifeKeeperは、Amazon EC2環境では既にリージョンを跨いだHAクラスター構成に対応しています。
詳しくは下記のマニュアルをご参照下さい。
- Linux版：AWS VPC ピアリング接続を使用した複数 VPC クラスター構成クイックスタートガイド
- Windows版：AWS VPC ピアリング接続を使用した複数 VPC クラスター構成クイックスタートガイド
一方、MS Azure環境では昨今のニーズの高まりから、1/15のLifeKeeper for Linux v9.9.0の追加サポートで対応を開始しました。本日はこのサポートの内容についてお伝え致します。
リージョンを跨いだ「クロスリージョン構成」の中心となるサポート条件は下記のとおりです。
- LifeKeeper for Linux v9.9.0以降が前提。※Windows版は追ってサポート予定
- Azureのリージョンを跨いだ１：１の2ノード構成が前提。 ※将来的に3ノード構成のサポートも検討しています。
クロスリージョン構成の大きなポイントは、リージョン間ロードバランサーを使う点にあります。既にLifeKeeperでサポートされている単一のリージョンに閉じた構成の場合、LifeKeeperはAzureの内部ロードバランサー（ILB）のヘルスチェックプローブを使ってActiveノードを確認し、ILBからActiveノードの仮想IPに向けて通信していました（Floating IPを有効にしておく必要あり）。
リージョンを跨いだ構成でもAzureのロードバランサーのヘルスチェックプローブを使う点に変わりはありません。違いとしては、リージョンの間に「リージョン間ロードバランサー」を使う点です。各リージョンの仮想マシンに対しては、「パブリックロードバランサー」を通じてヘルスチェックが行われます。
＜構成イメージ：東日本リージョンと南アジアリージョンを跨いだ場合＞
それでは簡単に、ヘルスチェック→仮想IPへの通信→切り替えの流れに沿って、通信がどのように行われるのかを説明致します。
まず、クライアントはリージョン間ロードバランサーのフロントエンドIP（仮想IPと同じ）に向けて通信します。
ヘルスチェックでは、リージョン間ロードバランサーからパブリックロードバランサーを介してヘルスチェックが行われます。ヘルスチェックはILBの構成と同様に、ヘルスチェックに応答するためのリーソース「LB Health Check Kit」のポート（この絵では26001）に対して行います。
続いて、ヘルスチェックに応答した稼働系ノードの仮想IPに対して、リージョン間ロードバランサーから通信が行われます。これにより、クライアントから仮想IPに向けて通信することで、仮想IPに到達させることが出来ます。 ※仮想マシンに向けて通信するため、リージョン間ロードバランサーのFloating IPは有効にしておく必要があります。
LifeKeeperが切り替わった場合は、仮想IP（IPリソース）とLB Health Check Kitの両リソースが待機系ノードに切り替わっているので、ヘルスチェックは待機系から応答があり、待機系に切り替わった仮想IPに通知が到達します。
詳細な設定方法は下記のマニュアルをご参照下さい。
今後ニーズが増えることが見込まれる、パブリッククラウド環境でのDR構成にLifeKeeperをご検討下さい。
