How xHA works - BlueCat Integrity - 9.3.0

Address Manager Administration Guide

Locale
English
Product name
BlueCat Integrity
Version
9.3.0

An xHA pair is a set of two DNS/DHCP Servers (an Active node and a Passive node) that Address Manager controls as a single virtual server. Like any managed server, the pair can have both deployment roles and deployment schedules.

The IP address of the Active node is removed from the active node’s physical interface and is assigned to a virtual interface to act as the Virtual IP address (VIP). This eliminates the need to reconfigure any DNS clients already set to contact the IP address of the active node. A new physical IP address is provided for the Active node while it's part of an xHA pair. This new IP address is known as the Private IP address (PIP). The PIP also refers to the IPv4 address configured on the Service interface (or Management interface if Dedicated Management is enabled) of the Passive node.

For DNS/DHCP Servers with dedicated management enabled, the IPv4 address of the Management interface will be assigned to a virtual interface.

xHA uses an passive primary server as a passive node, meaning that it always has up-to-date data, making failover between the two seamless and almost instantaneous. The Passive node monitors the Active node and becomes the Active primary if it determines that the Active node isn't responding. When updates are sent to the Active node, DNS updates are automatically propagated to the Passive node as standard incremental zone transfers. Also, use of xHA allows DHCP services to operate in a high availability configuration without scope-splitting because active leases are always up-to-date on both servers.

xHA performs data replication between the two nodes to ensure that the passive node always has up-to-date data and that failover occurs seamlessly. Data replication can be performed through the servers’ standard network connections, or through an optional xHA Backbone Communication connection operating on the xHA interface (eth1) of each server.

  • xHA replicates DNS/DHCP from the Active node to the Passive node.
  • If you have configured DHCP service with xHA in DNS/DHCP Server v8.0.0 or later, you must set the Server Identifier DHCP Service option for any interface that's serving DHCP (such as eth0, bond0, or a VLAN interface) to ensure that the IP address sent to clients from this interface properly indicates the Virtual IP address of the xHA pair as the DHCP server.
    Note: Setting the Server Identifier DHCP Service option is necessary due to the behavior of DHCP on interfaces with multiple IP addresses. If using xHA with VLANs, you must also set the Server Identifier DHCP Service option. For more information, refer to Configuring VLAN interfaces with xHA.
  • xHA synchronizes NTP, SSH, syslog, database files, SNMP configuration files, and additional IP addresses.
    Attention:
    • To avoid split-brain scenarios (where both servers are active or passive at the same time), the use of xHA backbone communication is mandatory.
    • When configuring the xHA backbone on DNS/DHCP Servers, ensure that the IP addresses of the xHA interfaces (eth1) are on a different subnet than any other interfaces (such as services/management interfaces) and non-routable IPs. In addition, if the DNS/DHCP Servers are not connected by a direct ethernet xHA backbone connection, the xHA interfaces should be separated onto a different LAN segment to prevent the xHA interfaces from receiving layer-2 broadcast traffic intended for other interfaces. This can be achieved by separate VLANs for each interface, private networks (for virtual appliances), or separate physical switches.
    • If you are currently using the xHA/eth1 ports for another purpose, you can reset and then reconfigure them for xHA communication, but you can't use the eth1 ports for xHA communication and for their previous purpose.
    • If you are upgrading from an earlier version of DNS/DHCP Server software, you must delete each eth1 port to reset it. Previous versions of DNS/DHCP Server software didn't support eth1, and eth1 isn't reset automatically.