Shulou(Shulou.com)06/01 Report--

1. Work scene

Keepalived provides the functions of Loadbalancing and High-Availability. This article refers to the scenario where it provides HA function for two Mycat nodes.

two。 The key configuration is as follows, for the active and standby non-preemptive mode.

! Mycat01, 192.168.4.196

Global_defs {

# one keepalived.conf, corresponding to one router_id

Router_id mycat01

}

Vrrp_instance VI_1 {

State BACKUP

Nopreempt

Interface eth0

# within a multicast, the value of each node is the same

Virtual_router_id 196

Priority 200

Advert_int 1

Authentication {

Auth_type PASS

Auth_pass Zf4aqy

}

Virtual_ipaddress {

192.168.4.200

}

}

! Mycat02, 192.168.4.195

Global_defs {

Router_id mycat02

}

Vrrp_instance VI_1 {

State BACKUP

Nopreempt

Interface eth0

Virtual_router_id 196

Priority 200

Advert_int 1

Authentication {

Auth_type PASS

Auth_pass Zf4aqy

}

Virtual_ipaddress {

192.168.4.200

}

}

3. Keepalived provides the working principle of HA

The HA function of Keepalived is realized by VRRP (Virtual Router Redundancy Protocol, Virtual routing redundancy Protocol). It uses IP Multicast (default Multicast address: 224.0.0.18) to realize the communication between service nodes and entrusts the routing task to a VRRP router through an election mechanism. When working, the master node sends the VRRP protocol message, and the standby node receives the message. If the standby node does not receive the message sent by the master node for a period of time (default 3 message sending time), it will start the takeover program to take over the resources of the master node. There can be multiple backup nodes through priority election.

4. Brain fissure occurred in Keepalived

4.1 according to the above working principle, when the standby node can not receive the message, if the network between the two is blocked, the standby node will start the takeover program to take over the resources of the primary node and provide services, which is represented by the appearance of a virtual IP on the standby node, and the primary node also holds the virtual IP.

The problem is repeated as follows: in this case, mycat01 is the primary node, mycat02 is the standby node, and drop drops multicast packets on mycat02.

# iptables-An INPUT-m pkttype-- pkt-type multicast-j DROP

Then look at the message log and you can see that it has also become the master node.

# tail-f / var/log/messages

Mar 17 00:13:58 mycat02 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team

Mar 17 00:14:00 mycat02 Keepalived_vrrp: VRRP_Instance (VI_1) Transition to MASTER STATE

Mar 17 00:14:01 mycat02 Keepalived_vrrp: VRRP_Instance (VI_1) Entering MASTER STATE

Mar 17 00:14:01 mycat02 Keepalived_vrrp: VRRP_Instance (VI_1) setting protocol VIPs.

Mar 17 00:14:01 mycat02 Keepalived_vrrp: VRRP_Instance (VI_1) Sending gratuitous ARPs on eth0 for 192.168.4.200

Mar 17 00:14:01 mycat02 Keepalived_healthcheckers: Netlink reflector reports IP 192.168.4.200 added

Mar 17 00:14:06 mycat02 Keepalived_vrrp: VRRP_Instance (VI_1) Sending gratuitous ARPs on eth0 for 192.168.4.200

Grab packets on mycat01 and see that mycat02 is also sending packets to multicast addresses.

# tcpdump-nnei eth0 | grep-I 'vrid 196'

Fa:16:3e:f4:18:40 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: 192.168.4.196 > 224.0.0.18: VRRPv2, Advertisement, vrid 196, prio 202, authtype simple, intvl 1s, length 20

00RV 13fa:16:3e:f4:18:40 59.736268 fa:16:3e:f4:18:40 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: 192.168.4.196 > 224.0.0.18: VRRPv2, Advertisement, vrid 196, prio 202, authtype simple, intvl 1s, length 20

00.736800 fa:16:3e:f4:18:40 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: 192.168.4.196 > 224.0.0.18: VRRPv2, Advertisement, vrid 196, prio 202, authtype simple, intvl 1s, length 20

00.955581 fa:16:3e:5d:23:10 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: 192.168.4.195 > 224.0.0.18: VRRPv2, Advertisement, vrid 196, prio 202, authtype simple, intvl 1s, length 20

01.956340 fa:16:3e:f4:18:40 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: 192.168.4.196 > 224.0.0.18: VRRPv2, Advertisement, vrid 196, prio 202, authtype simple, intvl 1s, length 20

When the iptables is stopped, mycat01 and mycat02 hold the virtual IP 192.168.4.200 respectively, which also shows a disadvantage of the active / standby non-preemptive mode, which is not the case. The following is the main configuration.

! Mycat01, 192.168.4.196

Global_defs {

Router_id mycat01

}

Vrrp_instance VI_1 {

State MASTER

Virtual_router_id 196

Priority 200

}

! Mycat02, 192.168.4.195

Global_defs {

Router_id mycat02

}

Vrrp_instance VI_1 {

State BACKUP

Virtual_router_id 196

Priority 150

}

4.2Cerebral fissure occurs when virtual_router_id configuration is different in the same multicast, so I won't repeat it here.

In the end, how to avoid brain fissure, we can see that as long as there is a virtual IP, it is impossible to avoid this problem completely. That is, if there is no virtual IP, there will be no brain fissure, so how can the node provide services to the outside world? Introducing Zookeeper or Consul's service discovery mechanism is another matter.

If you are interested, please follow Subscription account's Database Best practices (DBBestPractice).

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.