Мы настроили 3 запущенных сервера оставайся живым . Мы начали замечать случайные перевыборы, которые мы не можем объяснить, поэтому я пришел сюда за советом.
Вот наша конфигурация:
МАСТЕР:
global_defs {
notification_email {
webops@example.com
}
notification_email_from keepalived@hostname
smtp_server example.com:587
smtp_connect_timeout 30
router_id some_rate
}
vrrp_script chk_nginx {
script "killall -0 nginx"
interval 2
weight 2
}
vrrp_instance VIP_61 {
interface bond0
virtual_router_id 61
state MASTER
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass PASSWORD
}
virtual_ipaddress {
X.X.X.X
X.X.X.X
X.X.X.X
}
track_script {
chk_nginx
}
}
РЕЗЕРВНОЕ КОПИРОВАНИЕ1:
global_defs {
notification_email {
webops@example.com
}
notification_email_from keepalived@hostname
smtp_server example.com:587
smtp_connect_timeout 30
router_id some_rate
}
vrrp_script chk_nginx {
script "killall -0 nginx"
interval 2
weight 2
}
vrrp_instance VIP_61 {
interface bond0
virtual_router_id 61
state MASTER
priority 99
advert_int 1
authentication {
auth_type PASS
auth_pass PASSWORD
}
virtual_ipaddress {
X.X.X.X
X.X.X.X
X.X.X.X
}
track_script {
chk_nginx
}
}
BACKUP2:
global_defs {
notification_email {
webops@example.com
}
notification_email_from keepalived@hostname
smtp_server example.com:587
smtp_connect_timeout 30
router_id some_rate
}
vrrp_script chk_nginx {
script "killall -0 nginx"
interval 2
weight 2
}
vrrp_instance VIP_61 {
interface bond0
virtual_router_id 61
state MASTER
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass PASSWORD
}
virtual_ipaddress {
X.X.X.X
X.X.X.X
X.X.X.X
}
track_script {
chk_nginx
}
}
Время от времени я вижу, как это происходит (в журналах):
МАСТЕР:
Jan 6 18:30:15 lb-public01 Keepalived_vrrp[24380]: VRRP_Instance(VIP_61) Received lower prio advert, forcing new election
Jan 6 18:30:16 lb-public01 Keepalived_vrrp[24380]: VRRP_Instance(VIP_61) Received lower prio advert, forcing new election
Jan 6 18:32:37 lb-public01 Keepalived_vrrp[24380]: VRRP_Instance(VIP_61) Received lower prio advert, forcing new election
РЕЗЕРВНОЕ КОПИРОВАНИЕ1:
Jan 6 18:30:16 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Transition to MASTER STATE
Jan 6 18:30:16 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Received higher prio advert
Jan 6 18:30:16 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Entering BACKUP STATE
Jan 6 18:32:37 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) forcing a new MASTER election
Jan 6 18:32:38 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Transition to MASTER STATE
Jan 6 18:32:38 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Received higher prio advert
Jan 6 18:32:38 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Entering BACKUP STATE
BACKUP2:
Jan 6 18:32:36 lb-public03 Keepalived_vrrp[14255]: VRRP_Script(chk_nginx) succeeded
Jan 6 18:32:37 lb-public03 Keepalived_vrrp[14255]: VRRP_Instance(VIP_61) Transition to MASTER STATE
Jan 6 18:32:37 lb-public03 Keepalived_vrrp[14255]: VRRP_Instance(VIP_61) Received higher prio advert
Jan 6 18:32:37 lb-public03 Keepalived_vrrp[14255]: VRRP_Instance(VIP_61) Entering BACKUP STATE
Таким образом, МАСТЕР получает рекламу НИЖНЕГО ПРИОМИНАЛА, и начинаются НОВЫЕ выборы. ЗАЧЕМ ? Похоже, что BACKUP переходит в состояние MASTER на короткий период времени (на основе журналов), а затем не возвращается в состояние BACKUP. Я совершенно не понимаю, почему это происходит на самом деле, поэтому любые подсказки будут более чем приветствоваться.
Кроме того, я обнаружил, что есть одноадресный патч в keepalived, однако мне не ясно, поддерживает ли он более 1 одноадресного узла - в нашем случае у нас есть кластер из 3 машин, поэтому нам нужно более 1 одноадресного узла.
Любые подсказки по этим вопросам были бы чрезвычайно признательны!
Проблема в том, что вы используете состояние по умолчанию MASTER для узлов резервного копирования. Они должны указать BACKUP.
vrrp_instance VIP_61 {
interface bond0
virtual_router_id 61
state BACKUP
priority 98
...
Надеюсь, это решит вашу загадку.