Is TR7 itself a single point of failure; how do I set up Load Balancer redundantly?
Short answer
In a single-device (Standalone) installation, the device itself is a single point of failure. To prevent this, two TR7 devices are made a cluster with HA Clustering & Sync; the configuration is synchronized automatically between the two devices by default. Setup order: the number and names of the interfaces of the two devices must be the same; Sync Interface is selected on both devices; Clustering Enabled is turned on and the devices are given Cluster ID 1 and 2; on the ID 1 device, the management IP of the ID 2 device is written into the Edit IP form of the management (MGMT) IP; on the Local Services screen, the configuration service of both devices is restarted; after Sync. Summary is Synced, Synchronize is run. For the vServices to be served from the peer device when a device fails, a VIP is defined after the cluster (How is a VIP defined after the cluster is set up?).
Problem: When a Single TR7 Device Goes Out of Service, All Services Are Affected
If all applications are behind a single TR7 device, a failure, update or restart of the device affects all services. When a cluster is set up with a second TR7 device, the configuration is kept the same on both devices, and the VIPs move to the peer device when one device goes out of service.
Solution: Two Methods
One of the methods is followed depending on the environment to be set up; both only set up the cluster. The VIPs on which the vServices will be published are defined separately after the cluster is set up.
| Your situation | Suitable method |
|---|---|
| Physical device or a virtual machine on a virtualization platform | Method 1: Cluster setup with the web interface |
| Two TR7 virtual machines on Azure | Method 2: Azure cluster setup |
| The cluster is set up, a VIP is to be defined | How is a VIP defined after the cluster is set up? |
Method 1: Cluster Setup with the Web Interface Recommended
- How it works The two devices pair over a dedicated Sync Interface; a change made on one device is transferred automatically to the other device.
- Where it is openedSettings → Device Management → Hardware Management · HA Clustering & Sync · Local Services and Network → Interfaces
- Requirement Two TR7 devices with exactly the same number and names of network interfaces; one interface on each of the two devices dedicated to synchronization, and a link between these interfaces used only by the two devices
- Scope The entire configuration of the device (Load Balancer, network, firewall, users, GTM and other settings)
Step-by-Step Configuration
As a best practice, the two devices are set up with the same number of CPU cores and the same RAM; TR7 also compares the cores and the memory during pairing, and if there is a difference, it does not establish the connection and shows an error in the Cluster Status row. The number and names of the network interfaces, on the other hand, must be exactly the same on the two devices. The names are compared on both devices from the Name column of the Settings → Device Management → Hardware Management screen; an interface that differs is renamed in the Edit ON position.
On each of the two devices, one interface is dedicated to synchronization; no IP address is added to this interface.
- On physical devices: the sync interfaces of the two devices are connected directly to each other with a back-to-back cable.
- In virtualization environments: a distributed switch without an uplink is created; the interfaces of the 1st and 2nd devices that will be selected as sync are connected to this switch. No other virtual machine is connected to this switch.
On the Settings → Device Management → Hardware Management screen, the Edit OFF switch in the toolbar is clicked to bring it to the Edit ON position. The Sync Interface selector below the table can be changed only in this position.
The interface connected in step 2 is selected from the Sync Interface selector below the table (default None).
The Save button is clicked. This setting is device-specific and is not synchronized; steps 3–5 are repeated on the second device by selecting the same interface. Sync interface: 1 appears in the Usage cell of the selected interface.
On the Settings → Device Management → HA Clustering & Sync screen, the Edit button is clicked. If no Sync Interface is selected on the device, the button is inactive.
Clustering Enabled is turned on (off by default); when it is turned on, the Cluster ID and Manual Sync Mode fields appear. Cluster ID is selected as 1 on the first device and 2 on the second device (default 1). When the devices are set up with IDs 1 and 2, synchronization runs automatically (auto sync) by default: a change made on one device is transferred to the other device on its own. If the changes are to be sent manually, manual sync mode is also supported (Is the configuration automatically synchronized between cluster members?).
The Submit button is clicked; steps 6–8 are repeated on the second device with ID 2. The device with Cluster ID 1 initiates the connection, and the one with 2 waits. After both devices are saved, Cluster connection is OK is seen in the Cluster Status row and Sync. interface (<interface-name>) is up in the Sync Interface row.
As a best practice, this and the following steps are performed on the device whose ID is 1. On the Network → Interfaces screen, the IP address on the MGMT interface through which the web interface is accessed is right-clicked and Edit IP is selected (Right-clicking an IP address).
The IP table of the form that opens has two address columns; the column headers show the host names of the devices: the left one is the address of the ID 1 device (this device), and the right one is the address of the ID 2 device. The ID 2 column is empty by default; the MGMT IP address through which the web interface of the ID 2 device is accessed is written here. The two addresses must be of the same IP version and in the same subnet with the CIDR; otherwise, the record is rejected with Subnet error (IP).
The Edit IP button at the bottom of the form is clicked.
The Settings → Device Management → Local Services screen opens in two columns: the left column shows the device logged in to (ID 1), and the right column shows the peer device (ID 2). First, the Restart Configuration Service button in the right column is clicked and confirmed. Traffic continues to flow; management and monitoring pause for a few seconds.
Then the Restart Configuration Service button in the left column is clicked and confirmed. The system automatically returns to the login screen; the ID 1 device is logged in to again.
On the Settings → Device Management → HA Clustering & Sync screen, it is verified that the Sync. Summary row is Synced. If synchronization is in progress, the row shows Syncing; its completion is awaited.
The Synchronize button on the same screen is clicked and confirmed; the entire configuration of this device (ID 1) is sent to the peer device. While a field is being synchronized, or before 30 seconds have passed since the last run, the button cannot be run again.
A sample profile is added on the ID 1 device, e.g. a Timeouts profile with Load Balancer → Profiles → Timeouts → Add. That the profile was created automatically on the ID 2 device is seen on the same screen in the web interface opened through the MGMT IP of the ID 2 device. After the check, the test profile can be deleted; the deletion is also transferred to the peer device.
Verification
On the HA Clustering & Sync screen, the Cluster Status, Sync Interface and Sync. Summary rows are checked.
Cluster connection is OK · Sync. interface (...) is up · SyncedThe profile added on the ID 1 device is looked for in the Load Balancer → Profiles → Timeouts list in the web interface of the ID 2 device.
The profile is also listed on the ID 2 deviceMethod 2: Azure Cluster Setup
- How it works Two TR7 virtual machines pair over their sync NICs in a separate subnet; the configuration is synchronized automatically. For the VIP to be able to move to the peer device during failover, each virtual machine is given an identity and a role in Azure.
- Where it is opened Azure portal · Settings → Device Management · Network → Interfaces
- Requirement Two TR7 virtual machines in the same VNet; one sync NIC each in a subnet different from the management subnet; the Reader and Network Contributor roles for each virtual machine
- Scope The entire configuration of the device; the VIP is defined afterwards
Step-by-Step Configuration
(Azure) Two TR7 virtual machines are deployed in the same VNet; the management interfaces of the two machines must be on the same network (cluster setup).
(Azure) The two virtual machines are stopped and a new network interface (NIC) is added to each of them. These NICs must be in a subnet different from the management subnet and on the same network as each other. The machines are restarted and the web interface is logged in to.
On the first device, on the Settings → Device Management → Hardware Management screen, the Edit OFF switch is clicked to bring it to the Edit ON position.
The added NIC is selected as the Sync Interface. The interface is recognized from its MAC address or from having no IP in the Usage column.
The Save button is clicked; when a new login is requested, the device is logged in to. Steps 3–5 are repeated on the second device.
On the first device, on the Settings → Device Management → HA Clustering & Sync screen, the Edit button is clicked.
Clustering Enabled is turned on, and Cluster ID 1 is selected. In the Peer Device Private IP (Cloud) field, which additionally appears in the form on Azure, the management (primary) private IP of the second device on Azure is entered; the sync NIC address is not entered. The address must be in the primary subnet of this device; otherwise, the form does not accept the save. Synchronization runs automatically by default; manual sync mode is also supported (Manual Sync Mode).
The Submit button is clicked. Steps 6–8 are repeated on the second device with Cluster ID 2 and Peer Device Private IP (Cloud) = the management private IP of the first device.
On the first device, on the Network → Interfaces screen, the IP of the management interface is right-clicked and Edit IP is selected.
The management interface IP of the second device is written into the column that carries the host name of the second device. Both addresses are private IP addresses on Azure. No operation is performed on the second device for this step.
The Edit IP button is clicked. The save may return an error at this stage; the error disappears when the next steps are completed.
On the first device, on the Settings → Device Management → Local Services screen, the Restart Configuration Service button on the left is clicked and confirmed.
On the second device, on the same screen (Local Services), the Restart Configuration Service button on the left is clicked and confirmed.
(Azure) On the page of each virtual machine, Security → Identity → Status is set to On and saved. With Azure Role Assignments → Add Role Assignment, Scope = Resource Group is selected, and the Reader and Network Contributor roles are assigned separately. The step is performed for both virtual machines (failover permissions).
(Azure) To move the VIP, TR7 makes a call to the management.azure.com address over 443/TCP from the management interface. If outbound traffic passes through a firewall that denies by default, an outbound allow rule for 443/TCP is added from the management private IPs of the two devices (or from the management subnet) to the management.azure.com FQDN or to the AzureResourceManager service tag.
Verification
On the HA Clustering & Sync screen, the Cluster Status and Sync. Summary rows are checked.
Cluster connection is OK · SyncedA Timeouts profile is added on the first device; the Load Balancer → Profiles → Timeouts list is checked in the web interface of the second device.
The profile is also listed on the second deviceCommon Mistakes
- Giving both devices the same Cluster ID. The connection is not established; one device must be
1and the other2. - Pairing devices whose interface names or number differ. TR7 compares the interface list and does not establish the connection if it differs; a difference in the number of CPU cores or RAM also prevents the connection.
- Connecting the sync interface to a network open to other traffic. In a virtualization environment, the distributed switch to which the sync interfaces are connected must not have an uplink, and no other virtual machine must be connected to this switch.
- Finishing the setup without entering the MGMT IP of the ID 2 device. If the ID 2 column is left empty in the Edit IP form of the MGMT IP on the ID 1 device, the management address of the ID 2 device is not defined in the cluster configuration.
- Thinking that the vServices become redundant on their own once the cluster is set up. The Interface IP is specific to each device and does not move to the peer device; for failover, the Frontend IP of the vService must be a VIP (How is a VIP defined after the cluster is set up?).
How it is done in the documentation
