Оба сервера, на которых запущен keepalived, становятся главными

После сбоя сети оба сервера, на которых запущена поддержка активности, становятся главными.

Когда сеть восстанавливается, оба сохраняют состояние MASTER.

Что могло быть причиной этого?

Отредактировано: Другая информация, которая может быть актуальной, у каждого сервера есть два сетевых адаптера.

Вот конфигурация виртуального экземпляра:

vrrp_instance VGAPP {
    interface eth0
    virtual_router_id 61
    state BACKUP
    nopreempt
    priority 50
    advert_int 3
    virtual_ipaddress {
        10.26.57.61/24
    }
    track_interface {
       eth0
    }
    track_script {
        jboss_check
        #tomcat_check
        #interface_check
        #interface_check02
    }
    notify_master "/opt/keepalived/scripts/set_state.sh MASTER"
    notify_backup "/opt/keepalived/scripts/set_state.sh BACKUP"
    notify_fault  "/opt/keepalived/scripts/set_state.sh FAULT"
    notify_stop   "/opt/keepalived/scripts/set_state.sh STOPPED"}

keepalived

На самом деле это может быть ошибкой. Я знаю, потому что мне пришлось исправить это самому.

Согласно RFC, когда приоритеты равны на обоих узлах;

        If the Priority in the ADVERTISEMENT is equal to the local
        Priority and the primary IP Address of the sender is greater
        than the local primary IP Address, then:

         o Cancel Adver_Timer
         o Set Master_Down_Timer to Master_Down_Interval
         o Transition to the {Backup} state

Значит, выиграет тот, у кого самый большой IP-адрес.

В keepalived это в основном неверно. При этом сравнении порядок байтов не учитывается должным образом.

Представим, что у нас есть два маршрутизатора: (A) 10.1.1.200 и (B) 10.1.1.201.

Код должен выполните следующее сравнение.

На:

if (10.1.1.201 > 10.1.1.200) // True
   be_backup();

На B:

if (10.1.1.200 > 10.1.1.201) // False
  be_master();

Однако, поскольку порядок байтов не обрабатывается неправильно, вместо этого выполняется следующее сравнение.

На:

if (10.1.1.201 > 200.1.1.10) // False
  be_master();

На B:

if (10.1.1.200 > 201.1.1.10) // False
  be_master();

Этот патч должен работает, но я переделал его из своего исходного патча и не протестировал это. Даже не проверял компилирует! Так что никаких возвратов!

--- vrrp/vrrp.c.old 2013-10-13 17:39:29.421000176 +0100
+++ vrrp/vrrp.c 2013-10-13 18:07:57.360000966 +0100
@@ -923,7 +923,7 @@
    } else if (vrrp->family == AF_INET) {
        if (hd->priority > vrrp->effective_priority ||
            (hd->priority == vrrp->effective_priority &&
-            ntohl(saddr) > ntohl(VRRP_PKT_SADDR(vrrp)))) {
+            ntohl(saddr) > VRRP_PKT_SADDR(vrrp))) {
            log_message(LOG_INFO, "VRRP_Instance(%s) Received higher prio advert"
                        , vrrp->iname);
            if (proto == IPPROTO_IPSEC_AH) {

Попробуйте решение, опубликованное здесь.

Предотвратить превращение Мастера VRRP в Мастера после его сбоя