Searching ALOHA 12.5
Setting VRRP Priority
Setting VRRP Priority
When configuring VRRP, priority is the parameter which decides which peer is the Master or the Slave.
A few parameters can influence a peer's priority:
Peer's
vrrp priority
value-
VRRP daemon parameters that modify the priority based on the presence of some elements in the ALOHA:
A connected network interface: remove 6 points from priority for each DOWN interface belonging to the
group
A load-balancing or high availability service: add
track_weight_svc
(default 8) points to the priority for eachtrack_svc
service upA management service: add
track_weight_mgt
points to the priority for eachtrack_mgmt
service up
Warning
VRRP priority is very important. If improperly set up (too big gap between Slave and Master), it may prevent a failover to occur.
Use case: ALOHA cluster with default configuration
Consider an ALOHA cluster with the factory configuration as described below:
Master
vrrp priority
set to101
Slave
vrrp priority
set to100
track_svc
monitors haproxy andtrack_weight_svc
set to8
track_mgt
monitors wui and sshd andtrack_weight_mgt
set to2
All interfaces are UP
Default VRRP priority
Master priority computation: 101 + 8 (haproxy) + 2 (sshd) + 2 (wui) = 113
Slave priority computation: 100 + 8 (haproxy) + 2 (sshd) + 2 (wui) = 112
When the Slave fails
When the Slave node of a VRRP cluster fails (power off, unreachable through the network, etc.), nothing happens.
Result: The Master node carries on handling the traffic.
When the Master fails
When Master node of a VRRP cluster fails (power off, unreachable through the network, etc.), then:
No other VRRP heartbeat is emitted
The Slave node waits for 3s before considering the Master as definitively unavailable
The Slave node becomes the Master and emits VRRP heartbeat packets with priority set to 112
In the meantime, the new Master sends gratuitous ARP to announce the new MAC address associated to the VIPs
Result: The traffic fails over to the Slave node.
When HAProxy fails on the Slave
Slave priority computation becomes: 100 + 2 (sshd) + 2 (wui) = 104
104 is lower than 113 (current Master priority), hence the Slave remains slave
Result: The Master node carries on handling the traffic.
When HAProxy fails on the Master
Master priority computation becomes: 101 + 2 (sshd) + 2 (wui) = 105
105 is lower than 112 (current Slave priority), so the Slave becomes the new master
The new Master emits VRRP heartbeat packets with priority set to 112
In the meantime, the new Master sends gratuitous ARP to announce the new MAC address associated to the VIPs
Result: The traffic fails over to the Slave node.
When SSHD or WUI fails on the Slave
If SSHD crashes:
Slave priority computation becomes: 100 + 8 (haproxy) + 2 (wui) = 110
110 is lower than 113 (current Master priority), so the Slave remains slave
Result: The Master node carry on handling the traffic.
When SSHD or WUI fails on the Master
If SSHD crashes:
Master priority computation becomes: 101 + 8 (haproxy) + 2 (wui) = 111
105 is lower than 112 (current Slave priority), hence the Slave becomes the new Master
The new Master emits VRRP heartbeat packets with priority set to 112
In the meantime, the new Master sends gratuitous ARP to announce the new MAC address associated to the VIPs
Result: The traffic fails over to the Slave node.
Note
It is possible to trigger a failover only when both SSHD and WUI crash. To do this, you set up a difference of 3 points between the VRRP priority of the Slave and the Master (for example, 100 and 103, respectively.)