Нежелательный переход Keepalived к мастеру

Я запускаю 2 инстанса EC2 в Amazon с Cloudformation, второй инстанс запускается примерно через 30 секунд после первого.

Конфигурация выглядит так:

Экземпляр 2

    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    unicast_peer {
        172.17.16.10
    }

Экземпляр 1

    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    unicast_peer {
        172.17.16.11
    }

Оба настроены с одинаковой успешной проверкой работоспособности.

Я установил тот же приоритет, чтобы у меня не возникало проблем с колебаниями (если МАСТЕР выходит из строя, переходите РЕЗЕРВНОЕ КОПИРОВАНИЕ как новый МАСТЕР, но если СТАРЫЙ МАСТЕР возвращается, оставайтесь как есть).

Проблема возникает при первоначальном запуске:

• Первый экземпляр загружается и входит в МАСТЕР-СОСТОЯНИЕ
• Второй экземпляр запускается примерно через 30 секунд, сначала переходит в состояние РЕЗЕРВНОЕ КОПИРОВАНИЕ, но по какой-то причине после этого переходит в состояние МАСТЕР.

Оба должны иметь одинаковый приоритет, так почему?

Я заметил, что сообщения журнала о IPVS ядра и вычислении отпечатка хоста печатаются только после запуска keepalived. Это заставляет меня думать, что keepalived - первое программное обеспечение в системе, которое заставляет систему обмениваться пакетами через сетевой интерфейс и каким-то образом запускать нежелательное переключение при отказе.

Кроме того, Экземпляр 2 переходит в СОСТОЯНИЕ РЕЗЕРВНОГО КОПИРОВАНИЯ сразу после запуска поддержки активности:

Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: Using LinkWatch kernel netlink reflector...
Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: VRRP_Instance(VI_1) Entering BACKUP STATE
Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(15,16)]

тогда как экземпляр 1 становится ГЛАВНЫМ только после сообщений ядра IPVS и отпечатков пальцев:

Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.650360] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.654035] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.658356] IPVS: Creating netns size=2048 id=0
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.661163] IPVS: ipvs loaded.
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Opening file '/etc/keepalived/keepalived.conf'.
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Configuration is using : 5174 Bytes
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Using LinkWatch kernel netlink reflector...
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_vrrp[2392]: VRRP_Script(chk_haproxy) succeeded
Nov 17 17:44:29 ip-172-17-16-10 ec2:
Nov 17 17:44:29 ip-172-17-16-10 ec2: #############################################################
Nov 17 17:44:29 ip-172-17-16-10 ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----

Nov 17 17:44:29 ip-172-17-16-10 ec2: -----END SSH HOST KEY FINGERPRINTS-----
Nov 17 17:44:29 ip-172-17-16-10 ec2: #############################################################
Nov 17 17:44:29 ip-172-17-16-10 Keepalived_vrrp[2392]: VRRP_Instance(VI_1) Transition to MASTER STATE

- Чтобы проверить конфигурацию:

• Я прекращаю поддерживать жизнь
• Я запускаю keepalived на экземпляре 1, он переходит в МАСТЕР.
• Я запускаю keepalived на экземпляре 2, он переходит в РЕЗЕРВНОЕ КОПИРОВАНИЕ и не запускает аварийное переключение.

Так что все выглядит нормально.