Azure 特有の設定について

インターナルロードバランサー（ILB）の導入

Azure では [IP リソースが保護する VIP] を Azure の VNET で認識する事が出来ません。この影響で、通常 LifeKeeper for Windows が想定している [IP リソースが保護する VIP] によるネットワーク通信を行うことが出来ません。そのため本構成では、以下の様に ILB の導入を行い、[ILB が設定する VIP] をネットワーク通信経路として設定します。

クライアントからの接続

1. LKCLIENT が、アプリケーション（上図では Oracle Listener）へ接続するため、仮想 IP アドレスとアプリケーションのポート番号（上図では10.20.1.200:1521）で接続を試みます。

2. ILB は、負荷分散先である 10.20.1.11:1521 と 10.20.1.12:1521 のどちらかに振り分けます。アプリケーションは、LifeKeeper によってどちらか一方のマシンでのみ Active になっているため、ILB の正常性プローブは必ず Active 側のみが正常であることを検知します。結果として、ILB は常に Active 側（上図では LKNODE01 上で Active のため 10.20.1.11:1521）へ要求を振り分けます。

3. アプリケーションは、[Azure のプライベートアドレス]（を含む任意の IP アドレス）のアプリケーションポート上でも要求を待ち受けています。最終的に、LKCLIENT 上での仮想 IP アドレスとアプリケーションのポート番号（10.20.1.200:1521）への接続要求がアプリケーションに届けられます。

稼働系サーバー内部からの接続

1. ILB は NAT loopback 機能をサポートしていないため、稼働系サーバー内部から仮想 IP アドレスとアプリケーションのポート番号を指定してアプリケーションへ接続する場合は、ILB を経由することができません。この問題を解決するために、LifeKeeper の IP リソース（10.20.1.200）を作成します。

2. しかしながら、上図の通り Subnet#1 上ではすでに ILB が 10.20.1.200 を使用しているため、Subnet#1 上の NIC 上では同一の IP アドレスを Active にできません。そのため、[IP リソースが保護する VIP] には、便宜的に Subnet#2 上の NIC を設定します。

3. 稼働系サーバーから仮想 IP アドレスとアプリケーションのポート番号を指定したパケットは、稼働系サーバー内部のルーティングにより、サーバーの外部を経由することなく稼働系サーバー内部で処理されます。

4. アプリケーションは、仮想 IP アドレス（を含む任意の IP アドレス）のアプリケーションポート上でも要求を待ち受けています。最終的に、LKCLIENT 上での仮想 IP アドレスとアプリケーションのポート番号（10.20.1.200:1521）への接続要求がアプリケーションに届けられます。

IP リソースを必須とするアプリケーションの注意事項

IP リソースを必須とする ARK で保護されるアプリケーション（Oracle, Microsoft SQL Server, IIS）を Azure 環境以外で使用する場合は、接続を待ち受ける IP アドレスとして仮想 IP アドレスを設定します。しかし、上述の説明の通り、Azure 環境ではクライアントからの接続についてはそれぞれのサーバーのプライベートアドレスを使って通信し、サーバー内部からの接続については仮想 IP アドレスを使って通信します。そのため、IP リソースを必須とする ARK で保護されるアプリケーションであっても、接続を待ち受ける IP アドレスとして、任意の IP アドレス (INADDR_ANY) を設定する必要があります。このような設定が必要な例として本ガイドでは Oracle を取り上げます。