Это действительно странно на моем РЕЗЕРВНОМ устройстве всегда переключается на МАСТЕР несколько секунд.
Я уже искал, что оба мастера имеют виртуальные IP одновременно, и все решения, которые я пробовал, но все еще не работают.
Вероятно, есть два способа решить эту проблему.
Установка приоритета в keepalived.conf
Пакет VRRP отбрасывает межсетевой экран, чтобы устройство BACKUP считало, что оно должно перейти на MASTER
BACKUP.conf
global_defs {
router_id ThinkPad
}
vrrp_instance VRRP3 {
state BACKUP
interface eth0
virtual_router_id 41
priority 1
advert_int 5
authentication {
auth_type PASS
auth_pass 1066
}
virtual_ipaddress {
172.16.100.1/16 dev eth0
#172.16.10.1/16 dev eth0 label eth0:1
#172.16.20.1/16 dev eth0 label eth0:2
#172.16.30.1/16 dev eth0 label eth0:3
}
# unicast_src_ip 172.16.100.2 ##source ip
# unicast_peer {
# 172.16.100.1 ##dest ip
# }
notify_master /etc/keepalived/ICS2.sh
notify_backup /etc/keepalived/ICS.sh
}
MASTER.conf
global_defs {
router_id NvidiaTx2
}
vrrp_instance VRRP1 {
state MASTER
interface eth0
virtual_router_id 41
priority 200
advert_int 1
authentication {
auth_type PASS
auth_pass 1066
}
virtual_ipaddress {
172.16.100.1/16 dev eth0
#172.16.10.1/16 dev eth0 label eth0:1
#172.16.20.1/16 dev eth0 label eth0:2
#172.16.30.1/16 dev eth0 label eth0:3
}
# unicast_src_ip 172.16.100.1 ##source ip
# unicast_peer {
# 172.16.100.2 ##dest ip
# }
}
настройка iptables (и ufw уже отключен)
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 112 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 112 -- 0.0.0.0/0 224.0.0.18
ACCEPT 112 -- 0.0.0.0/0 224.0.0.18
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 112 -- 0.0.0.0/0 224.0.0.18
ACCEPT 112 -- 0.0.0.0/0 224.0.0.18
tcpdump Resault
root@ThinkPad:/etc/keepalived# tcpdump -i eth0 -n vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:41:38.864030 IP 172.16.100.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 200, authtype simple, intvl 1s, length 20
15:41:39.859616 IP 172.16.100.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 1, authtype simple, intvl 5s, length 20
15:41:40.862070 IP 172.16.100.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 200, authtype simple, intvl 1s, length 20
15:41:41.863060 IP 172.16.100.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 200, authtype simple, intvl 1s, length 20
15:41:42.863939 IP 172.16.100.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 200, authtype simple, intvl 1s, length 20
15:41:43.864744 IP 172.16.100.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 200, authtype simple, intvl 1s, length 20
15:41:44.859805 IP 172.16.100.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 1, authtype simple, intvl 5s, length 20
статус keepalived
6月 13 16:11:02 ycshen-ThinkPad-E470 systemd[1]: Started LVS and VRRP High Availability Monitor.
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Registering Kernel netlink command channel
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Opening file '/etc/keepalived/keepalived.conf'.
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: WARNING - default user 'keepalived_script' for script execution does not exist - please create.
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Assigned address 172.16.100.2 for interface eth0
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Registering gratuitous ARP shared channel
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: (VRRP1) removing VIPs.
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: (VRRP1) Entering BACKUP STATE (init)
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: VRRP sockpool: [ifindex(2), family(IPv4), proto(112), unicast(0), fd(11,12)]
6月 13 16:11:02 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: VRRP sockpool: [ifindex(2), family(IPv4), proto(112), unicast(0), fd(11,12)]
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: (VRRP1) Receive advertisement timeout
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: (VRRP1) Entering MASTER STATE
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: (VRRP1) setting VIPs.
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Sending gratuitous ARP on eth0 for 172.16.100.1
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: (VRRP1) Sending/queueing gratuitous ARPs on eth0 for 172.16.100.1
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Sending gratuitous ARP on eth0 for 172.16.100.1
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Sending gratuitous ARP on eth0 for 172.16.100.1
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Sending gratuitous ARP on eth0 for 172.16.100.1
6月 13 16:11:18 ycshen-ThinkPad-E470 Keepalived_vrrp[4454]: Sending gratuitous ARP on eth0 for 172.16.100.1
В vrrp_instance
имя должно быть одинаковым для обоих экземпляров. У вас есть один по имени VRRP3
и один назван VRRP1
.
Этого вопроса можно избежать, если я сменил устройство резервного копирования с Ubuntu 18.04 на другой ноутбук с Ubuntu 16.04 (главное устройство тоже 16.04).
Обе конфигурации одинаковы, и я действительно не могу найти причину, по которой возникла эта проблема, может быть, я попробую две версии 18.04, надеюсь, это сработает.