Azureで仮想IPは使えない？LifeKeeper×ILB構成で解決

こんにちは。SCSKの津田です。

今回は、Azureの環境で仮想IPアドレスをどのように機能させるかについてご紹介します。

クラウド環境では、オンプレミスで当たり前に使えていた「仮想IP（VIP）」が、実はそのままでは使えないケースが多くあります。
AWSでは、第4回でご紹介したように、EC2やRoute 53といったリソースを活用することで、クライアントからの接続を実現していました。

【LifeKeeper】AWSでは仮想IPアドレスが使えない！？をこうして解決する！！ – TechHarmony

では、Azureではどうでしょうか？
Azureでは、AWSとは異なるアプローチで仮想IPを実現しています。
本記事では、実際に仮想IPを実装し、簡単な動作確認を行ってみました。

Azure環境では仮想IPが使えない？ではどうする？
検証した構成
仮想IP実装に必要となる設定
仮想IP機能検証
1. 事前準備
2. 動作確認
注意点
さいごに

Azure環境では仮想IPが使えない？ではどうする？

仮想IPは、HAクラスタ構成において非常に重要な役割を果たします。
仮想IPは現在稼働しているノード（アプリケーションが実行されているノード）に常にマッピングされ、クライアントは常にこの仮想IPアドレスでアクセスできることで、障害時でもクライアントは意識することなくシステムを利用することができます。

しかし、Azure の仮想ネットワークでは LifeKeeper で設定した仮想IPがオンプレや仮想環境のようには認識されません。
そのため、通常では仮想IPを使用したネットワーク通信や保護はできません。

この問題を解決するため、Azureではロードバランサー、LifeKeeperのLB Health Check Kitを使用することで仮想IPを機能させます。
クラスタを同一リージョン内に構築する場合、内部ロードバランサー（Internal Load Balancer、ILB）でフロントエンドIPを設定し、バックエンドプールに稼働系ノードと待機系ノードのNICの IP アドレスに設定し、そのIPアドレス宛に正常性プロープを行います。
ILBのフロントエンドIPは仮想IPとして活用でき、クライアントからの仮想IP宛のネットワーク通信はILBに到達し、クラスタに負荷分散されます。負荷分散は正常性プローブで応答が返り正常な結果となるノードにのみ行われます。
この正常性プローブに対しノード側で応答するのがLB Health Check Kit (LB Health Checkリソース) の機能であり、
LifeKeeperによってLB Health Check Kitはアクティブ側のみで稼働し、正常性プローブに応答する状態となっています。
よって、クライアントからのネットワーク通信はILB経由で常にアクティブなノードに転送され、LifeKeeperによってアクティブノードに付与された仮想IPで接続要求を受信し応答を返します。

SIOSオンラインマニュアルには、仮想IPアドレスを利用したクライアントからの接続フローがイメージ図付きで解説されています！

■Windows
Azure 特有の設定について – LifeKeeper for Windows LIVE – 8.11.0
■Linux
Azure 上の LifeKeeper 特有の設定について – LifeKeeper for Linux LIVE – 9.9.1

正常性プローブとは？
「プローブ（probe）」とは、「探査」を意味する用語であり、Azure 正常性プローブとは、バックエンドプールの正常性を監視するためのヘルスチェックのような機能です。
正常性プローブへの応答がない仮想マシンについては適切に検出し、新しい接続の送信を停止します。

LB Health Check Kitとは？
クラウド環境でロードバランサーの負荷分散対象インスタンスへのヘルスチェックプローブを待ち受けて応答する仕組みを提供します。
参考：https://docs.us.sios.com/sps/8.11.0/ja/topic/lifekeeper-for-linux-lbhc

検証した構成

今回は実際に仮想IPを実装してみました。
以下はノード・ネットワーク構成のイメージ図となります。

※「LBHC」= LB Health Checkの略

■OS：Windows Server 2022 Datacenter
■LifeKeeper：LifeKeeper for Windows 8.11.0

※Windowsでの注意点として、LifeKeeperで仮想IPを付与するNICとILBのバックエンドプールとして指定するNIC(IP)を別にする必要があります。

仮想IP実装に必要となる設定

Azureで仮想IPを機能させる場合、ロードバランサー、IPリソース、LBHCリソースの作成がポイントになります。
今回の検証にあたって作成した内容をそれぞれご紹介します。
※WindowsOSで検証を行った際の内容となります。
※環境により各設定値は変わる場合があります。

ロードバランサー作成

前提：仮想ネットワーク、仮想マシンの作成が完了していること。

Azure Portalの　ホーム＞　負荷分散とコンテンツ配信　＞　ロードバランサー　の画面から［作成する］をクリックし、
[Standard Load Balancer]を選択。
以下の通り各項目を記入、選択し、[次：フロントエンドIP構成＞]をクリック。

※今回は内部ロードバランサーを使用するため、[種類]は[内部]を選択。

［フロントエンドIP構成の追加］をクリックすると、画面右に「フロントエンドIP構成の追加」が表示されるため、
以下の通り各項目を記入、選択した後、［保存］⇒[次：フロントエンドIP構成＞]をクリック。

※このクラスタへの仮想IPでの接続時は、この［IPアドレス］を仮想IPとして利用。

［バックエンドプールの追加］をクリック。
［バックエンドプールの追加］で以下の通り各項目を記入、選択し、[追加］をクリック。
画面右側に「バックエンドプールへのIP構成の追加」が表示されるため、バックエンドプールに指定するIPアドレスを選択し［追加］⇒［保存］をクリック。

※Windowsでは仮想IPリソースで使用するNICとは異なるNICのIPアドレスを選択。

[次：インバウンド規則＞]をクリック。
[負荷分散規則の追加]をクリックすると画面右側に［負荷分散規則の追加］が表示される。
［正常性プローブ］で［新規作成］をクリックし、以下の通り各項目を記入し、[保存］をクリック。

※［ポート］は正常性プローブを行うポートの宛先となる。クラスタ内のノードで使用可能な任意のポートを指定。

画面右側の[負荷分散規則の追加]に以下の通り各項目を記入し、［保存］⇒［確認及び作成］をクリック。
デプロイを完了させる。

※1、※2 クラスタ内のアプリケーションが使用するポート番号を指定。(今回は検証の為IISを導入するためポート80(HTTP)を指定。)
※3 クライアントからクラスターへ向けた通信を、IP リソース(VIP）宛のパケット通信とする必要があるため、［フローティングIP］は有効にする。

IPリソース作成

前提：OSの設定、LKインストール、コミュニケーションパスの作成が完了していること

LifeKeeperのGUIで以下赤枠の［+］ボタンをクリックします。

ウィザードに従い、以下の表のとおり設定値を入力します。

IPアドレス(作成)
プライマリサーバ	LKNODE01
バックアップサーバ	LKNODE02
保護するアプリケーション	IPアドレス
IPアドレスのタイプ	仮想IPアドレス
IPアドレス	10.10.5.200	※1
サブネットマスク	255.255.255.255	※2
IPリソースタグ名	ip-10.10.5.200
ネットワーク接続	Ethernet 2	※3
ローカル・リカバリー	いいえ
IPアドレス(拡張)
サブネットマスク	255.255.255.255	※3
ネットワーク接続	Ethernet 2
ターゲット・リストアモード	有効
ターゲット・ローカルリカバリー	いいえ
バックアップの優先順位	10

※1 設定済の Azure ロードバランサーのフロントエンド IP と同じ値を使用。
※2 ルーティングの競合を避けるため 255.255.255.255 を設定。
※3 仮想IPを付与するNICとして、ILBのバックエンドプールに指定したNIC(IP)とは別のNICを指定。

LBHCリソース作成

前提：OSの設定、LKインストール、コミュニケーションパスの作成が完了していること

LifeKeeperのGUIで以下赤枠の［+］ボタンをクリックします。

ウィザードに従い、以下の表のとおり設定値を入力します。

IPアドレス(作成)
プライマリサーバ	LKNODE01
バックアップサーバ	LKNODE02
保護するアプリケーション	LB Health Check
応答デーモンポート	12345	※1
応答デーモンメッセージ	空欄
LB Health Checkリソースタグ名	lbhc-12345
IPアドレス(拡張)
LB Health Checkリソースタグ名	lbhc-12345
バックアップの優先順位	10

※1 ILBの［正常性プローブ］の［ポート］で設定した値を設定。

仮想IP機能検証

クラスタ内の各ノードでIISの導入およびIISリソース作成を行い、仮想IPの簡単な動作検証を行いました。

事前準備

クラスタ内各ノードのIISのドキュメントルートに、サーバ名を記載したテストページ(htmlファイル)を格納します。
＜LKNODE01 %SystemDrive%\inetpub\wwwroot\test_page.html＞

＜LKNODE02 %SystemDrive%\inetpub\wwwroot\test_page.html＞

動作確認

想定：クライアント端末から仮想IPにアクセスすると、LKNODE01とLKNODE02のどちらがアクティブかスタンバイかに関係なく、常にアクティブ側のテストページが返される。

LKNODE01がアクティブ
クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLKNODE01のテストページが表示されました。
LKNODE02がアクティブ
クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLKNODE02のテストページが表示されました。

どちらも想定通りの結果となり、仮想IPが機能していることが確認できました！

ちなみに…
lbhcリソースを削除して、IISのテストページにアクセスしてみたところ、
lbhcリソースのヘルスプローブへの応答がなくなるためか、テストページに到達できなくなりました。

注意点

ここまでご紹介した仮想IPの実装に関して、以下点にご注意ください。

WindowsとLinuxでクライアントからの接続フロー・設計・設定が異なるため、事前のマニュアル確認を行う。
■Windows
　Azure 特有の設定について – LifeKeeper for Windows LIVE – 8.11.0
■Linux
　Azure 上の LifeKeeper 特有の設定について – LifeKeeper for Linux LIVE – 9.9.1
Windowsでは、LifeKeeperで仮想IPを付与するNICとILBのバックエンドプールとして指定するNIC(IP)を別にする。
IPリソース作成時、対象サブネット(本検証では10.10.5.0/24)に対するルーティングの競合を避けるため、
「255.255.255.255」で設定する。
クライアントからクラスターへ向けた通信を、IP リソース(VIP）宛のパケット通信とする必要があるため、
［フローティングIP］は有効にする。 (アクティブノードからの応答も仮想 IP から送信される)
ホスト名に小文字が含まれている場合、LifeKeeper で不具合が発生する恐れがあるため、ホスト名は大文字で作成する。
⇒ 当初ホスト名に小文字を含めてLifeKepperを構築していたところ、LBHCリソースの作成でエラー(No140321)が発生。
　ホスト名を全て大文字にすることで事象解消。
OSの設定漏れに注意。
Azure固有のOS設定が必要のため、以下の対応漏れに注意する。
■Windows
　　OS の設定 – LifeKeeper for Windows LIVE – 8.11.0
■Linux
　　OSの設定 – LifeKeeper for Linux LIVE – 9.9.1