LifeKeeper-Specific Configurations in Azure

Internal Load Balancer (ILB)

Azure is not capable of recognizing [VIP protected with IP resources] with the VNET. Because of this, network communication using [VIP protected with IP resources], which is usually assumed by LifeKeeper for Linux, cannot be performed. Therefore, LifeKeeper introduces ILB as follows with the [VIP set by ILB] set as a network communication path.

1. In order for the Oracle Client to connect to the Oracle Listener, start the connection to 10.3.1.200 (port 1521) via ILB.
2. In the ILB, 10.3.1.11 and 10.3.1.12 are registered in the load balancing destination (backend pool) with no port settings. Packets received by the ILB for 10.3.1.200 (port 1521) are forwarded to both the active and standby nodes.
3. Due to the LifeKeeper specifications, it is necessary to specify [VIP protected with IP resources] for the Oracle Listener resource and an IP resource for receiving needs to be created. Since the LifeKeeper IP resource (10.3.1.200) is in-service only on the active node, only the active node (10.3.1.11) receives requests.
4. As a result, the connection request from the Oracle Client is received by the active Oracle Listener (10.3.1.200: port 1521).

Address Conversion

LifeKeeper uses PING to external hosts to monitor IP resources, but due to the Azure’s specifications, PING with virtual IP as the source cannot be performed. However, by changing the packet source information as described below, PING can be enabled and network failures between external hosts can be detected.

1. From the IP resource, start ping with the VIP protected by the IP resource as an origin.
2. Replace the PING origin address from 10.3.1.200 (VIP protected by the IP resource) to 10.3.1.11 (Azure private IP address).
3. After replacing the origin, send the packet to the PING destination. If it is replaced with [Azure Private IP address], the response will be returned if the network is reachable.

Quorum/Witness

In an Azure environment, DataKeeper replication disks are used as an alternative to cluster shared disks. In a cluster that uses DataKeeper, when the network fails such that the communication path is completely disconnected, it may result in a split brain due to its mechanism. To avoid this, configure I/O Fencing using the Quorum/Witness functionality.