インターナルロードバランサー(ILB)の導入
Azure では [IP リソースが保護する VIP] を Azure の VNET で認識する事が出来ません。この影響で、通常 LifeKeeper for Windows が想定している [IP リソースが保護する VIP] によるネットワーク通信を行うことが出来ません。そのため本構成では、以下の様に ILB の導入を行い、[ILB が設定する VIP] をネットワーク通信経路として設定します。
クライアントからの接続
- LKCLIENT が、アプリケーション(上図では Oracle Listener)へ接続するため、仮想 IP アドレスとアプリケーションのポート番号(上図では10.20.1.200:1521)で接続を試みます。
- LKNODE01およびLKNODE02は、ILBのバックエンドプールとして登録されます。ILBヘルスプローブは、どのノードでヘルスプローブポート(12345)が開かれているかを確認します。ジェネリックアプリケーションスクリプトとして提供される、Generic ARK for Load Balancer probe reply(GenLB)は、ILBヘルスプローブに応答します。LifeKeeperによって、GenLBはどちらかのマシンでのみアクティブになっているため、ILB の正常性プローブは必ず Active 側のみが正常であることを検知します。結果として、ILBは常にノードのアクティブ側に要求を割り当てます(上の図では、LKNODE01がアクティブです)。
- フローティングIP設定は、ロードバランシングルールで有効になるように設定されています。ILBは、クライアントからの接続要求を、ネットワークアドレス変換を適用せずにノードのアクティブ側に転送します。そして接続要求は、宛先アドレスが10.20.1.200に設定されたまま、アクティブ側のノードに到達します。
- 接続要求を受信するには、LifeKeeper IPリソース(10.20.1.200)が必要です。ただし、サブネット#1のILBはすでに上記と同じIPアドレスを使用しているため、サブネット#1のNICで10.20.1.200をアクティブにすることはできません。そのため便宜上、サブネット#2のNICを [IPリソースで保護されたVIP] に設定してください。また、アプリケーションは、IPアドレス(10.20.1.200)のアプリケーションポートで要求を待ち受けます。最終的に、LKCLIENT 上での仮想 IP アドレスとアプリケーションのポート番号(10.20.1.200:1521)への接続要求がアプリケーションに届けられます。
このトピックへフィードバック