Installing the Internal Load Balancer (ILB)
Azure cannot recognize a [VIP protected by IP resource] in an Azure VNET. As a result, network communication using [VIP protected by IP resource] normally used in LifeKeeper for Windows cannot be performed. In this configuration, install ILB as follows and set [VIP set by ILB] as the network communication path.
Connection from the client
- Since the lkclient connects to the application (Oracle Listener in the figure above), a connection is attempted using the virtual IP address and application port number (10.20.1.200:1521).
- LKNODE01 and LKNODE02 are registered as the backend pool of the ILB. The ILB health probe checks which node has opened the health probe port (12345). The Generic ARK for Load Balancer probe reply (GenLB), which is provided as generic application scripts, responds to the ILB health probe. Since LifeKeeper ensures that the GenLB is only active on either machine, the ILB health probe always detects that only the active side is healthy. As a result, ILB always allocates requests to the active side of the nodes (in the figure above, LKNODE01 is active).
- The floating IP setting is set to be enabled in the load balancing rule. The ILB forwards the connection requests from client to the active side of the nodes without applying network address translation. Then, the requests arrive to the active side of the nodes with the destination address set to 10.20.1.200.
- A LifeKeeper IP resource (10.20.1.200) is necessary in order to receive the connection requests. However, 10.20.1.200 cannot be active on the NIC on Subnet #1 because the ILB on Subnet #1 is already using the same IP address as shown above. Therefore, for convenience, set the NIC on Subnet #2 to [VIP protected by IP resource]. The application waits for requests on the application port on the IP addresses (10.20.1.200). Lastly, connection requests to the virtual IP address and application port number (10.20.1. 200:1521) on LKCLIENT are delivered to the application.