What is failover; when does it happen in TR7?
Short answer
Failover is the automatic transfer of the work to a backup component, mostly without human intervention, when the active component fails or stops unexpectedly (NIST · failover). In a TR7 cluster, what is transferred to the peer device is the VIP; the Interface IPs that belong to each device do not move. The VIP moves according to the method in the VIP Transition Method field: if Only VRRP (default) is selected, when the VRRP advertisements from the Master device stop for VIP Transition Duration (s) (default 3 seconds); if TR7 link check, TR7 GW check or TR7 link and GW check is selected, additionally when the interface link or default gateway check fails on the Master device only. The failover is visible in the interface list with the VIP statuses (Master VIP is absent on the Master side, Slave VIP is active on the peer side), and a VIP Status notification is generated; when the Master device becomes healthy, the VIP returns to it. In TR7, the health check and Backup Service (on HTTP and L7 TCP vServices) at the server level, and Bond and LACP at the link level, also perform their own failovers.
Where It Is Used in TR7
| Where | Field / label | What for |
|---|---|---|
| Network → Interfaces → Edit Interface (in a cluster) | VIP Transition Method, VIP Transition Duration (s) (default 3, 1–1000) | The condition and the time that trigger the failover |
| Network → Interfaces | VIP statuses: Master VIP is active / Slave VIP (stable), Master VIP is absent / Slave VIP is active (VIP on the peer device) (Interface and IP statuses) | Seeing on which device the VIP is active |
| Load Balancer vService list | Status circle split in two; the VIP … is on slave message in the vService preview | Seeing that the vService's VIP is on the peer device (What does a status circle split in two mean in the vService list in a cluster?) |
| Settings → General Settings → Notification Management / Settings → System Logs → Notification Logs | Notification Type = VIP status; Notification Logs | Receiving a notification at the moment of failover and viewing the history |
| Backend Service form | Health Check, Backup Service | Server-level failover; Backup Service applies only on HTTP and L7 TCP vServices |
| WEB-CLI | network cluster-ip-service status list (network cluster-ip-service) | Querying the status of the VIP service |
The Failover Flow in TR7
The detailed operation is in the LB FAQs; this page summarizes only the term and its equivalent in TR7:
- The two mechanisms of the cluster (configuration synchronization and VIP failover): How does a cluster work?
- Selecting the device on which the VIP will run: What is the Master/Slave role on a VIP?
- The return of the VIP when the failed device comes back: When a failed device comes back, does the VIP automatically move back to it?
- Moving the VIP manually to the peer device for planned maintenance: What should I watch out for when taking a device in the cluster into maintenance?
Common Misconceptions
- "In failover, all IPs move to the peer device." Only the VIPs move; the Interface IPs stay on the device. For the vService to be able to fail over, its Frontend IP must be a VIP.
- "If the Sync link goes down, the VIP moves." VIP failover depends on the VRRP advertisements and the selected check; the Sync interface is for configuration synchronization (What is a heartbeat; which links serve this role in a TR7 cluster?).
- "After failover, the VIP stays on the peer device." When the device given the Master role becomes healthy, the VIP returns to it; if the VIP should stay on the peer device, the Master/slave role is changed with Edit IP.
How it is done in the documentation
