HADR and network address translation (NAT) support

Network address translation (NAT) is usually used for firewall and security because it hides the server's real address. NAT is supported in HADR environments unless you are also using the Db2® pureScale® Feature.

With the release of version 11.5.6, there is a new method to support HADR in a NAT environment. This new method has a significant advantage over the use of the DB2_HADR_NO_IP_CHECK registry variable. Ensure DB2_HADR_NO_IP_CHECK is not set when using this method.

In a NAT environment, it is possible that a host is known to itself by an internal hostname (or IP address) <X>, but is known to the other hosts by a different external hostname (or IP address) <Y>. When such a host is used in an HADR setup, you can configure the HADR_LOCAL_HOST database configuration with both the internal and external address, such as:

<X> | <Y>

Similarly, if the HADR communication on the internal network is using port <port1> that is different from the port <port2> used for the external network, you can configure the HADR_LOCAL_SVC to include both ports, so that it looks like:

<port1> | <port2>

If the HADR_LOCAL_HOST is configured with two values and the HADR_LOCAL_SVC is configured with a single port, then the same port value will be used for both the internal and external network.

This method of configuring HADR for a NAT environment allows cross-checking the HADR communications to see if they are with the configured hosts (as specified in the HADR_TARGET_LIST or HADR_REMOTE_HOST database configuration parameter). This is a significant advantage over the old method of NAT support via the DB2_HADR_NO_IP_CHECK registry variable.

In addition, there is a known limitation in HADR when it has a multiple standby environment. The old method of setting the DB2_HADR_NO_IP_CHECK registry variable does not work well in all-NAT environment. Such limitations can be avoided by using the new method of configuring both the internal and external address in HADR_LOCAL_HOST.

Examples

Example 1

Two hosts with:

Internal addresses: host1, host2
External addresses: host1E, host2E
Same port used for both internal and external network on both hosts: 55001

Configuration on host1:

HADR_LOCAL_HOST: "host1 | host1E"
HADR_LOCAL_SVC: "55001"
HADR_TARGET_LIST: "host2E:55001"

Configuration on host2:

HADR_LOCAL_HOST: "host2 | host2E"
HADR_LOCAL_SVC: "55001"
HADR_TARGET_LIST: "host1E:55001"

Example 2

Three hosts with:

Internal addresses: host1, host2, host3
External addresses: host1E, host2E, host3E
On host1, internal communication uses port: 55001
On host1, external communication uses port: 55011
On host2, internal communication uses port: 55002
On host2, external communication uses port: 55012
On host3, internal communication uses port: 55003
On host3, external communication uses port: 55013

Configuration on host1:

HADR_LOCAL_HOST: "host1 | host1E"
HADR_LOCAL_SVC: "55001 | 55011"
HADR_TARGET_LIST: "host2E:55012 | host3E:55013"

Configuration on host2:

HADR_LOCAL_HOST: "host2 | host2E"
HADR_LOCAL_SVC: "55002 | 55012"
HADR_TARGET_LIST: "host1E:55011 | host3E:55013"

Configuration on host3:

HADR_LOCAL_HOST: "host3 | host3E"
HADR_LOCAL_SVC: "55003 | 55013"
HADR_TARGET_LIST: "host1E:55011 | host2E:55012"

Example 3

Four hosts with:

Internal addresses: host1, host2, host3, host4
External addresses: host1E, host2E, host3E, host4E
host1, host2 and host3 are in an internal network (and communications within them is preferred to be on the internal network), with host4 in an external network
On host1, internal communication uses port: 55001
On host1, external communication uses port: 55011
On host2, internal communication uses port: 55002
On host2, external communication uses port: 55012
On host3, internal communication uses port: 55003
On host3, external communication uses port: 55013
On host4, internal communication uses port: 55004
On host4, external communication uses port: 55014

Configuration on host1:

HADR_LOCAL_HOST: "host1 | host1E"
HADR_LOCAL_SVC: "55001 | 55011"
HADR_TARGET_LIST: "host2:55002 | host3:55003 | host4E:55014"

Configuration on host2:

HADR_LOCAL_HOST: "host2 | host2E"
HADR_LOCAL_SVC: "55002 | 55012"
HADR_TARGET_LIST: "host1:55001 | host3:55003 | host4E:55014"

Configuration on host3:

HADR_LOCAL_HOST: "host3 | host3E"
HADR_LOCAL_SVC: "55003 | 55013"
HADR_TARGET_LIST: "host1:55001 | host2:55002 | host4E:55014"

Configuration on host4:

HADR_LOCAL_HOST: "host4 | host4E"
HADR_LOCAL_SVC: "55004 | 55014"
HADR_TARGET_LIST: "host1E:55011 | host2E:55012 | host3E:55013"

Legacy support using DB2_HADR_NO_IP_CHECK

In an HADR setup, the local and remote host configurations on the primary and standby nodes are cross-checked to ensure that they are correct. In a NAT environment, a host is known to itself by a particular IP address but is known to the other hosts by a different IP address. This behavior causes the HADR host cross-check to fail unless you set the DB2_HADR_NO_IP_CHECK registry variable to ON. Using this setting causes the host cross-check to be bypassed, enabling the primary and standby to connect in a NAT environment.

If you are not running in a NAT environment, use the default setting of OFF for the DB2_HADR_NO_IP_CHECK registry variable. Disabling the cross-check weakens the HADR validation of your configuration.

Multiple HADR standby databases

Normally, with multiple standby databases, on startup, a standby checks that its settings for the hadr_remote_host and hadr_remote_svc configuration parameters are also used for its hadr_target_list parameter. This check is done to ensure that on role switch, the old primary can become a new standby. In NAT scenarios, that check fails unless you set the DB2_HADR_NO_IP_CHECK registry variable to ON. Because this check is bypassed when DB2_HADR_NO_IP_CHECK is set to ON, the standby waits until it connects to the primary to check that the values of the primary's hadr_local_host and hadr_local_svc configuration parameters are used for the standby's hadr_target_list configuration parameter. The check still ensures that role switch can succeed for the standby and primary pair.

Important: If you set the DB2_HADR_NO_IP_CHECK registry variable to ON, the values of the hadr_remote_host and hadr_remote_svc configuration parameters are not automatically updated.

In a multiple standby setup, you should set the DB2_HADR_NO_IP_CHECK registry variable for all databases that might connect to another database across a NAT boundary. If a database will never cross a NAT boundary to connect to another database (that is, if no such link is configured), you should not set this registry variable for that database. If you set the DB2_HADR_NO_IP_CHECK registry variable, it prevents a standby from automatically discovering the new primary after a takeover has occurred, and you must manually reconfigure the standby to have it connect to the new primary.