How To
Summary
Setting up Virtual IP (VIP) for HADR or Mutual Failover with Pacemaker automation provides a common connection point for clients without the need to disclose the actual IP address of the database server. In the event of a failover, the client can still connect to the database by using the VIP, effectively achieving automatic client reroute at the network level. The prerequisite for VIP setup is for both hosts to be located on the same network subnet.
Objective
This document provides a step-by-step procedure to set up a virtual IP address as well the Azure Internal Load Balancer as prerequisite for the virtual IP address with Db2 V11.5.8.0 and later. For prior Db2 version, refer to the original document.
Below is a high-level overview of a 2-node Db2 Pacemaker setup with virtual IP address via an internal load balancer providing access for clients.
Note:
For access to the cluster from the internet or your company network, refer to the appropriate Azure documentation:
- Networking Azure Virtual Network | Microsoft Docs
- How to use a public load balancer Azure Load Balancer components | Microsoft Doc
Environment
Refer to the following IBM Documentation page for a list of platforms supported by Pacemaker, the same restrictions apply here: Restrictions on Pacemaker - IBM Documentation
Steps
1. Refer to the “Configuring high availability with the Db2 cluster manager utility (db2cm)” page of the IBM Documentation to deploy one of the automated HADR or Mutual Failover solution: Configuring high availability with the Db2 cluster manager utility (db2cm)
2. Decide on an IP address and interface:
Compile a list of all host names, including virtual host names, and update your DNS servers to enable proper IP address to host-name resolution. If a DNS server doesn't exist or you can't update and create DNS entries, you need to use the local host files of the individual virtual machines that are participating in this scenario. If you're using host files entries, make sure that the entries are applied to all virtual machines in the environment.
Compile a list of all host names, including virtual host names, and update your DNS servers to enable proper IP address to host-name resolution. If a DNS server doesn't exist or you can't update and create DNS entries, you need to use the local host files of the individual virtual machines that are participating in this scenario. If you're using host files entries, make sure that the entries are applied to all virtual machines in the environment.
Note: Floating IP is not supported on a NIC secondary IP configuration in load-balancing scenarios. For details see Azure Load Balancer limitations in the Azure Documentation.
3. Configure Azure Load Balancer:
To enable the environment for using a virtual IP, you must create an Azure Load Balancer first. It is recommended that you create an Azure Standard Load Balancer SKU as described here: Quickstart: Create an internal load balancer - Azure portal - Azure Load Balancer | Microsoft Docs
Once the Load Balancer is created, perform the following steps to complete the configuration:
A. Create a front-end IP pool:
- Go to https://portal.azure.com
- In the Azure portal, click “Load balancers”, select the previously created Load Balancer.
- Click at “frontend IP pool”, and then select “Add”.
- Enter the name of the new front-end IP pool (for example, Db2-connection).
- Set the Assignment to “Static” and enter the IP address for the Virtual-IP to be used.
- Select "OK”.
- After the new front-end IP pool is created, make a note on the value of the pool IP address as you need it later in the process.
B. Create a back-end pool:
- In the Azure portal, click “Load balancers”, select the previously created Load Balancer.
- Open the Azure Load Balancer, select “backend pools” and then click ”Add”.
- Enter the name of the new back-end pool (for example, Db2-backend).
- Select “Add” to add a virtual machine.
- Select the availability set or the virtual machines hosting the primary and secondary IBM Db2 database from the available choices further down on the screen.
- Click “OK”.
C. Create a health probe:
- In the Azure portal, click “Load balancers”, select the previously created Load Balancer.
- Open the Azure Load Balancer, select “health probes” and then click “Add”.
- Enter the name of the new health probe (for example, Db2-hp).
- Select “TCP” as the protocol and port, for example “62500”. Keep the “Interval” value set to “5”
- Click “Add”.
Note: The health probe port must not be the same as the Db2 Database Manager Communication port.
D. Create the load-balancing rules:
- In the Azure portal, click “Load balancers”, select the previously created Load Balancer.
- Select “backend pools” and then click ”Add”.
- In the Azure portal, open the Azure Load Balancer, select “Load balancing rules”, and then select “Add”.
- Enter the name of the new Load Balancer rule (for example, Db2-lbr).
- Select the front-end IP address, the back-end pool, and the health probe that you created earlier from the drop-down menus.
- Keep the Protocol set to “TCP”, and enter port number of the Database Manager Communication port, for example "5912" in the field “Port”
- Use the command 'db2 get dbm config | grep SVCENAME' to get the port/port alias. Cross reference with the /etc/services file if a port alias is listed instead.
- Increase the “idle timeout” to 30 minutes by using the slider.
- Set the “Floating IP” checkbox to “Enabled”.
- Select “OK”.
4. Before creating the resources, open the firewall for the health probe port on both servers in the cluster if the firewall is enabled.
firewall-cmd --add-port=<port>/tcp --permanent
firewall-cmd --reload
5. Create the resources for the virtual IP and the Load Balancer.
The IP addresses for both Db2 Database Nodes and the Virtual IP address must belong to the same subnet. Replace the value for <IPAddress> and <lbPort> with the appropriate value for your environment, based on the load balancer configuration. For the <lbPort> use the previously assigned health probe port that is different from the Db2 Database Manager Communication port.
The virtual IP address and the Load Balancer resources both needs to be created and collocated with the primary database in the cluster. To do so, execute the following commands.
A. Create the virtual IP primitive on one of the nodes in the cluster.
To create a virtual IP for HADR Primary database.
db2cm -create -primaryVIP <IPAddress> -db <database name> -instance <instance name>
Alternatively, for read on standby, you can associate the virtual IP with the standby HADR database.
db2cm -create -standbyVIP <IPAddress> -db <database name> -instance <instance name>
Finally, for mutual failover clusters, the virtual IP must be associated with the instance rather than the database.
db2cm -create -primaryVIP <IPAddress> -partition <partition number> -instance <instance name>
B. Create the Load Balancer primitive on one of the nodes in the cluster.
To create a load balancer resource for HADR Primary database, use the following command.
db2cm -create -azure -primarylbl <lbPort> -db <database name> -instance <instance name>
Alternatively, for read on standby, you can associate the load balancer with the standby role.
db2cm -create -azure -standbylbl <lbPort> -db <database name> -instance <instance name>
Finally, for mutual failover clusters, the load balancer must be associated with the instance rather than the database.
db2cm -create -azure -primarylbl <lbPort> -partition <partition number> -instance <instance name>
For details on the db2cm command itself, refer to the IBM Documentation: db2cm - Db2 cluster manager utility
Remove Azure Load Balancer & Virtual IP resources from the cluster
To remove the Azure Load balancer resource, perform following steps:
1. Remove the load balancer and VIP resources using the db2cm command.
For a load balancer associated with a primary HADR database.
db2cm -delete -azure -primarylbl -db <database name> -instance <instance name>
db2cm -delete -azure -primaryVIP -db <database name> -instance <instance name>
Alternatively for a read on standby VIP, remove the standby load balancer.
db2cm -delete -azure -standbylbl -db <database name> -instance <instance name>
db2cm -delete -azure -standbyVIP -db <database name> -instance <instance name>
For mutual failover clusters, remove the load balancer and VIP associated with the instance partition.
db2cm -delete -azure -primarylbl -partition <partition number> -instance <instance name>
db2cm -delete -azure -primaryVIP -partition <partition number> -instance <instance name>
2. Confirm the load balancer resource has been removed using the db2cm –list command.
3. If the load balancer is no longer needed, delete the load balancer from the Azure portal.
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m3p0000006xc1AAA","label":"High Availability-\u003EPacemaker"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
19 October 2022
UID
ibm16830479