keepalived VIP Drift fundamentals and election algorithms

Keepalived can build a high-availability service using multiple stateless single points, such as Keepalived+nginx,lvs,haproxy and memcached, through virtual IP (hereinafter referred to as VIP) drift. Its implementation is based on the VRRP protocol, including the core of the master campaign mechanism is agreed in the VRRP agreement.

First, configuration instructions:
The configuration of keepalived is located in/etc/keepalived/keepalived.conf, and the configuration file format contains several required/optional configuration segments, some of which have the following meanings:
Global_defs: A global definition block that defines the SMTP configuration for notification messages when master-slave switching occurs.
VRRP_INSTANCE:VRRP instance configuration.
Vrrp_script: Health Check script configuration.

Subdivision, the Vrrp_instance configuration section includes:
State: Instance role. is divided into one master and one (multiple) backup.
VIRTUAL_ROUTER_ID: Identifies the ID of the virtual router with a valid range of 0-255.
Priority: initial value, campaign master, valid range is 0-255.
ADVERT_INT:VRRP the protocol notification interval.
INTERFACE:VIP the network adapter that is bound, specifies the network card that handles the VRRP multicast protocol package.
MCAST_SRC_IP: Specifies the native IP address where the VRRP protocol advertisement is sent.
Authentication: Authentication method.
Virtual_ipaddress:vip.
Track_script: Health Check script.

Vrrp_script configuration segments include:
Script: A command or a script file that needs to return 0 (success) or 0 (failure), keepalived to determine the status of its monitoring service.
Interval: Health check cycle.
Weight: Priority change amplitude.
Fall: Determines the number of times a service exception is checked.
Rise: Determine the number of times the service is healthy.

Here is the reference configuration for master and backup.

Second, the election algorithm
The node with high priority in Keepalived is master. Master one of the duties is to respond to the VIP ARP packet, the VIP and MAC address mapping relationship to other hosts in the LAN, and it will be in the form of multicast (destination address 224.0.0.18) to the LAN to send VRRP notification, inform their priority. All backup nodes in the network are only responsible for processing the multicast packets sent by master, and when the priority of Master is found not to be high, or if it is forfeited to Master's VRRP notification, backup switches itself to the master state. Then do what master should do: 1. Respond to ARP packets, 2. Send a VRRP notification.

How is the priority of master and backup nodes adjusted?
First, each node has an initial priority, which is specified by the precedence configuration item in the configuration file, and the master node should be higher than bakcup. During the run keepalived the node priority is increased or decreased according to the Vrrp_script weight setting. The rules are as follows:

1. When weight > 0 o'clock, the Vrrp_script script execution returns 0 (success) with priority + weight, otherwise it is precedence. When backup discovers that its priority is greater than the priority of the master notification, the master-slave switch is performed.
2. When weight < 0 o'clock, Vrrp_script script execution returns non 0 (failed) with priority + weight, otherwise precedence. When backup discovers that its priority is greater than the priority of the master notification, the master-slave switch is performed. 3. When the priority of two nodes is the same, the IP with the node sending VRRP advertisement as the comparison object, the larger IP is master. For example, the configuration in the above article: host1:10.15.8.100, priority=91, MASTER (default) host2:10.15.8.101, priority=90, BACKUPVIP: 10.15.8.102weight = 2 Grab Package command: Tcpdump-nn VRRP example one: keepalived and Nginx are normal on HOST1 and HOST2.

1234	16:33:07.697281 IP 10.15.8.100 > 224.0.0.18:vrrpv2, advertisement, Vrid 102, Prio, authtype simple, intvl 1s, lengt H 2016:33:08.697588 IP 10.15.8.100 > 224.0.0.18:vrrpv2, advertisement, Vrid 102, Prio, authtype simple, intvl 1s, l Ength 20

At this point, the HOST1 priority is precedence + weight = 93,host2 priority is precedence + weight = 92,host1 is still master.

Example two: Turn off Nginx on the HOST1.

12345678

16:33:09.697928 IP 10.15.8.100 > 224.0.0.18:vrrpv2, advertisement, Vrid 102, Prio, authtype simple, intvl 1s, lengt H 2016:33:10.698285 IP 10.15.8.100 > 224.0.0.18:vrrpv2, advertisement, Vrid 102, Prio, authtype simple, intvl 1s, l Ength 2016:33:10.698482 IP 10.15.8.101 > 224.0.0.18:vrrpv2, advertisement, Vrid 102, Prio, AuthType simple, INTVL 1 s, length 2016:33:11.699441 IP 10.15.8.101 > 224.0.0.18:vrrpv2, advertisement, Vrid 102, Prio, authtype simple, int VL 1s, length 20

HOST1 on the Nginx closed, killall-0 nginx return to non-0,HOST1 notification priority of precedence = 91,host2 priority for the first + weight = 92,host2 preemption success, was elected as master. Related logs can be tail/var/log/messages.

Thus, the master-slave priority initial value and the change amount of weight setting is very critical, matching the wrong words will lead to the master-slave switch. For example, when the master initial value is set too high, even if the script execution fails, it is larger than the priority + weight of the backup, it will not be able to perform VIP drift. So the priority and weight values should be set according to: ABS (MASTER Priority-bakcup) < ABS (weight). In addition, when multicast is not supported in the network (for example, some cloud environments), or if there is a network partition, the keepalived backup node cannot receive the VRRP notification from master, and there will be a split brain phenomenon, where multiple master nodes are present in the cluster.

Reprint: http://fengchj.com/?p=2156

keepalived VIP Drift fundamentals and election algorithms