How does GTM behave in a cluster?

Short answer

In a cluster, the GTM configuration (DNS Service, domain, record, health check, health scenario, trigger action, profiles and remote device definitions) is synchronized to the peer device like the other settings; if Manual Sync Mode is on, it stays only on the device where the change was made until it is sent with Synchronize. At run time, however, each device is independent: it runs its own DNS Service, performs the health checks itself, evaluates the scenarios with its own results and calculates the DNS answer itself; this is why the status circle in the lists is split in two and the decisions of the two devices can differ. Trigger Actions and zone transfer (Zone Transfer and Express synchronization) are run only by the device whose Cluster ID value is 1; if the peer device cannot reach this device for longer than one hour, it takes over the tasks. In DNSSEC, each device signs the zone with its own key.

How Does It Work?

Topic	Behavior in a cluster
Configuration	Synchronized to the peer device (automatically by default; with Synchronize in Manual Sync Mode)
DNS Service	Runs separately on each device. If a VIP is selected as the Frontend IP, the queries are answered by the device on which the VIP is located at that moment; with INT addresses, each device answers from its own address. Restart Service restarts the service only on the device the interface is connected to
Health check and health scenario	Each device performs and evaluates them itself; each half of the status circle is the result of one device
DNS answer and record status	Each device calculates them with its own scenario decisions; two Summary columns are seen in the Records list and two Active Records columns in the preview
Trigger Action	Run only by the device whose Cluster ID is 1
Zone transfer	Only the device whose Cluster ID is 1 pulls the records; on the other device, Zone Transfer and Sync via Express give the "device name is not master of GTM" error. The pulled records go to the peer device with the configuration
DNSSEC	Each device generates its own key; the DNSSEC Info for window has a separate DS table per device
GTM Logs	The device on which the event was generated is written in the Source column

In TR7

• Different decisions: When the devices perform the health checks over different network paths, the scenario decisions, and therefore the answers, can differ; the results of the two devices are compared from the two halves of the status circle and from the device columns in the previews.
• DNS Service: For the definition of the service and its Frontend IPs: What is a DNS Service in GTM?
• It is not a remote device: Remote Devices represents a TR7 in another data center and does not share the configuration; the cluster peer is a second device that runs the same configuration.
• Cluster settings: Settings → Device Management → HA Clustering & Sync.

Common Misconceptions

• "In a cluster, the active device runs GTM and the passive device waits." Both devices run their DNS Service; which device answers a query depends on the Frontend IP selection (VIP or INT). Only trigger action and zone transfer run on a single device.
• "The main device of GTM is the device that holds the VIP." For trigger action and zone transfer, the main device is the device whose Cluster ID value is 1.
• "The status of the two devices is always the same." Since the health checks are performed separately on each device, the statuses and the answers can differ.

How it is done in the documentation

• Service Management · Frontend IP
• Health Scenarios · Operating Mechanism
• Trigger Actions · Operating Mechanism
• Records · Operating Mechanism
• HA Clustering & Sync · Manual Sync Mode

Related questions

• What is a health check in GTM; how does it differ from a Load Balancer health check?
• What is a Trigger Action; what does it do in which situations?
• How does DNSSEC work in GTM?
• What is a Remote Device; how does GTM monitor a remote data center?