Conditions and factors for keepalived status Switching

1. keepalived application scenarios

Keepalived is developed for LVS and features lightweight and simple configuration. Because of this feature, I personally think it is suitable for applications in environments with relatively few resources and no shared storage, especially for Server Load balancer, such as LVS, haproxy, and nginx, it can also be used in a lightweight HTTP environment as its high-availability component. Of course, in theory, many high-availability scenarios can be implemented, but the resource switching method based on keepalived itself is not recommended.

Ii. Factors affecting keepalived status Switching

Keepalived status switching is mainly implemented by combining the weight value in the vrrp protocol with the Health script. The Node priority is also dynamically adjusted according to the script Detection Status. In fact, the keepalived implementation will switch freely Based on the Resource Health status according to the running business type. In some cases, when the resources on the master node are switched to the backup due to a fault, if you want to switch back, you need to disable the keepalived service.

 

1. Master, backup, priority (priority)

Set the master and backup values of keepalived to make sense only when the priority (priority) is the same. If the priority is different, the master should be given the highest priority, whether it is set to master or backup, we usually have to specify different priorities for the two nodes.

 

2. Weight Value of vrrp_script

This weight value must be specified. Otherwise, the node is displayed as fault after the service is restarted.

The weight value is divided into positive and negative values. Assume that the weight value is W, and the initial priority is P,

 

When the weight value is <0:

• If the returned value of the detection script is 0, the final priority of the node is not changed.
• If the detection script return value is less than 0, the node final priority = P-W, the priority is reduced

 

When the weight value is greater than 0

• If the returned value of the detection script is 0, the final priority of the node is P + W, and the priority is increased.
• If the returned value of the detection script is less than 0, the final priority of the node does not change.

 

The changes in node priority are closely related to the business status of the node.See the following two tables:

• 1. When the business services on both nodes are in the starting state, such as httpd, the priority changes as follows:

Node	Set priority	Weight Value	Node normal operation Priority (Both nodes start httpd)	Node A: Service detection failed	A is restored and not preemptible
A	100	-2	100	100-2 = 98	100
B	99	-2	99	99	99
Status	A is the master	A is the master	A is the master	Switch to Master B	Switch to master

 

• 2. When the business of the master node is started, the business of the backup node is stopped, for example, haproxy (because haproxy cannot be started because it does not have a listening address, in fact, many businesses start and stop on two nodes)

Node	Set priority	Weight Value	Priority of a node during normal operation	Priority of node A when the business fails	Priority after keepalived of A is stopped	Enable keepalived priority of a again	Priority after keepalived of B is stopped
A	100	-2	100	100-2 = 98	None	100-2 = 98	98
B	99	-2	99-2 = 97 (because haproxy stops)	97	97	99	None
Status	A is the master	A is the master	A is the master	A> B. Do not switch	Switch to Master B	A <B, do not switch back	Switch back to master

 

 

It can be seen from the above that, in the second case, the keepalived service can be switched only when it is disabled. This is why many experiments have found that the service is stopped but cannot be switched, in this case, we can adapt the initial priority and Weight Values to switch A to B, but if we want to switch back, We can manually stop keepalived. This is also why keepalived is not suitable for large business clusters. It is more suitable if it is only for high availability of the scheduler.

Conditions and factors for keepalived status Switching