Get Postgres Tips and Tricks
Subscribe to get advanced Postgres how-tos.
Using Failover Manager with Virtual IP Addresses¶
Failover Manager uses the efm_address
script to assign or release a
virtual IP address.
Please note: Virtual IP addresses are not supported by many cloud providers. In those environments, another mechanism should be used (such as an Elastic IP Address on AWS), which can be changed when needed by a fencing or post-promotion script.
By default, the script resides in:
/usr/edb/efm-4.0/bin/efm_address
Use the following command variations to assign or release an IPv4 or IPv6 IP address.
To assign a virtual IPv4 IP address:
# efm_address add4 <interface_name> <IPv4_addr>/<prefix>
To assign a virtual IPv6 IP address:
# efm_address add6 <interface_name> <IPv6_addr>/<prefix>
To release a virtual address:
# efm_address del <interface_name> <IP_address/prefix>
Where:
<interface_name>
matches the name specified in thevirtual.ip.interface
property in the cluster properties file.
<IPv4_addr>
or<IPv6_addr>
matches the value specified in thevirtual.ip
property in the cluster properties file.
prefix
matches the value specified in thevirtual.ip.prefix
property in the cluster properties file.
For more information about properties that describe a virtual IP address, see The Cluster Properties File.
You must invoke the efm_address
script as the root user. The efm
user is
created during the installation, and is granted privileges in the
sudoers file to run the efm_address
script. For more information about
the sudoers file, see Extending Failover Manager Permissions.
Please note: : If a VIP address (or any address other than the
bind.address
) is assigned to a node, the operating system can choose the
source address used when contacting the database. Be sure that you
modify the pg_hba.conf
file on all monitored databases to allow contact
from all addresses within your replication scenario.
Testing the VIP
When using a virtual IP (VIP) address with Failover Manager, it is important to test the VIP functionality manually before starting failover manager. This will catch any network-related issues before they cause a problem during an actual failover. The following steps test the actions that Failover Manager will take. The example uses the following property values:
virtual.ip=172.24.38.239
virtual.ip.interface=eth0
virtual.ip.prefix=24
ping.server.command=/bin/ping -q -c3 -w5
Please note: : The virtual.ip.prefix
specifies the number of significant
bits in the virtual Ip address.
When instructed to ping the VIP from a node, use the command defined by
the ping.server.command
property.
1. Ping the VIP from all nodes to confirm that the address is not already in use:
# /bin/ping -q -c3 -w5 172.24.38.239
PING 172.24.38.239 (172.24.38.239) 56(84) bytes of data.
--- 172.24.38.239 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss,
time 3000ms
You should see 100% packet loss.
2. Run the efm_address add4
command on the Primary node to assign the VIP
and then confirm with ip address:
# efm_address add4 eth0 172.24.38.239/24
# ip address
<output truncated>
eth0 Link encap:Ethernet HWaddr 36:AA:A4:F4:1C:40
inet addr:172.24.38.239 Bcast:172.24.38.255
...
3. Ping the VIP from the other nodes to verify that they can reach the VIP:
# /bin/ping -q -c3 -w5 172.24.38.239
PING 172.24.38.239 (172.24.38.239) 56(84) bytes of data.
--- 172.24.38.239 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.023/0.025/0.029/0.006 ms
You should see no packet loss.
4. Use the efm_address del
command to release the address on the primary
node and confirm the node has been released with ip address:
# efm_address del eth0 172.24.38.239/24
# ip address
eth0 Link encap:Ethernet HWaddr 22:00:0A:89:02:8E
inet addr:10.137.2.142 Bcast:10.137.2.191
...
The output from this step should not show an eth0 interface
5. Repeat step 3, this time verifying that the Standby and Witness do not see the VIP in use:
# /bin/ping -q -c3 -w5 172.24.38.239
PING 172.24.38.239 (172.24.38.239) 56(84) bytes of data.
--- 172.24.38.239 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss,
time 3000ms
You should see 100% packet loss. Repeat this step on all nodes.
6. Repeat step 2 on all Standby nodes to assign the VIP to every node. You can ping the VIP from any node to verify that it is in use.
# efm_address add4 eth0 172.24.38.239/24
# ip address
<output truncated>
eth0 Link encap:Ethernet HWaddr 36:AA:A4:F4:1C:40
inet addr:172.24.38.239 Bcast:172.24.38.255
...
After the test steps above, release the VIP from any non-Primary node before attempting to start Failover Manager.
Please note: : The network interface used for the VIP does not have to be
the same interface used for the Failover Manager agent’s bind.address
value. The primary agent will drop the VIP as needed during a failover,
and Failover Manager will verify that the VIP is no longer available
before promoting a standby. A failure of the bind address network will
lead to primary isolation and failover.
If the VIP uses a different interface, you may encounter a timing
condition where the rest of the cluster checks for a reachable VIP
before the primary agent has dropped it. In this case, EFM will retry the
VIP check for the number of seconds specified in the node.timeout
property to help ensure that a failover happens as expected.