У меня есть настройка ведущего / ведомого устройства Keepalived в AWS для Haproxy, а EIP используется как VIP. Время от времени резервный сервер запускает аварийное переключение, но ГЛАВНЫЙ узел исправен. Ниже приведены соответствующие журналы.
Сервер резервного копирования
Oct 10 04:14:32 Prod-WebAccessLb2 Keepalived_vrrp[2271]: VRRP_Instance(ProdWebCluster) Transition to MASTER STATE
Oct 10 04:14:33 Prod-WebAccessLb2 Keepalived_vrrp[2271]: VRRP_Instance(ProdWebCluster) Entering MASTER STATE
Oct 10 04:14:33 Prod-WebAccessLb2 Keepalived_vrrp[2271]: Opening script file /etc/keepalived/master.sh
Oct 10 04:14:34 Prod-WebAccessLb2 Keepalived_vrrp[2271]: VRRP_Instance(ProdWebCluster) Received advert with higher priority 200, ours 100
Oct 10 04:14:34 Prod-WebAccessLb2 Keepalived_vrrp[2271]: VRRP_Instance(ProdWebCluster) Entering BACKUP STATE
Главный Сервер
Oct 10 04:14:35 Prod-WebAccessLb1 Keepalived_vrrp[1311]: VRRP_Instance(ProdWebCluster) Received advert with lower priority 100, ours 200, forcing new election
Oct 10 04:14:35 Prod-WebAccessLb1 Keepalived_vrrp[1311]: VRRP_Instance(ProdWebCluster) Received advert with lower priority 100, ours 200, forcing new election
Итак, посмотрев журналы, мы можем сказать, что сразу после отработки отказа узел MASTER запускает восстановление после отказа, но не запускает master.sh, а VIP остается в воздухе.
Ниже приведены МАСТЕР-конфигурации.
vrrp_script chk_haproxy {
script "/bin/pidof haproxy"
interval 1
}
vrrp_instance ProdWebCluster {
debug 2
interface eth0
state MASTER
virtual_router_id 33
priority 151
unicast_src_ip 10.186.2.10
unicast_peer {
10.186.6.10
}
authentication {
auth_type PASS
auth_pass xxx
}
track_script {
chk_haproxy
}
Конфигурации резервного сервера
vrrp_instance ProdWebCluster {
debug 2
interface eth0
state BACKUP
virtual_router_id 33
priority 100
unicast_src_ip 10.186.6.10
unicast_peer {
10.186.2.10
}
authentication {
auth_type PASS
auth_pass xxxx
}
track_script {
chk_haproxy
}
Кто-нибудь может сказать, почему он в первую очередь запускает аварийное переключение? и почему во время восстановления не запускается master.sh?
Примечание: когда я запускаю скрипты master.sh вручную из Backup / Master, он работает так, как должен работать.