1, split brain problem
1. Definition:
In a high-availability (HA) system, when the association of two disconnected nodes communicate with one another, the system would have to provide services to a separate split into two separate nodes, the two nodes at this time They will compete for resources. (KeepAlived in the performance of two nodes also has VIP)
keepalived points based backup both machines, but only outside a VIP access, VIP only the host machine will drift down to the standby machine to provide services. Split brain will lead to the two machines have both master and slave VIP competition problems arise.
2 reasons:
The reason is that the communication is disconnected between the master and slave machines, for example:
If iptables is enabled, do not set "system receives the VRRP" rule, will be split brain, backup machine keepAlived not receive broadcast information from the host program, showing the presence of VIP was on the backup machine.
However, when the capture command (tcpdump -i eth0 | grep VRRP) able to crawl to the host sent over VRRP broadcasting, data described later can catch tcpdump inbound packets before intercepting iptables iptables intercepted, the receiving program keepAlived less than the packet.
3, the solution:
1) Add a rule is limited to iptables:
vim /etc/sysconfig/iptables
Add: -A INPUT -s 192.168.244 24 -d 224.0.0.18 -p vrrp -j ACCEPT /
2) restart iptables: service iptables restart
3) Preparation of the VIP aircraft disappeared, the problem is solved:
2, a multi-group LAN (keepAlived of) conflict
1. Description of the problem:
When deployed in the same local area network multi-level service keepalived pair, dedicated heartbeat communication but not used, the serious problem of high availability fault takeover may occur. keepalived high availability functionality is implemented by the VRRP, VRRP default communication protocol between achieving high availability through IP multicast form, if the memory in the same local area network to multiple groups keepalived servers, IP multicast address will cause conflict , leading to confusion took over, keepalived will use a different set of default 224.0.0.18 as a multicast address.
2, problem solving:
In all of the same group keepalived server configuration file to specify a unique multicast address configuration is as follows:
global_defs{
router_id LVS_19
vrrp_mcast_group4 224.0.0.19 # This is the configuration specified multicast address
}
Communication authentication passwords for different instances of different best to ensure the normal takeover