Опция keepalived nopreempt не работает

Я хочу использовать параметр nopreempt с параметром keepalived vrrp для запуска резервного узла в качестве главного, когда мастер выйдет из строя и снова вернется в сеть.

Я установил параметр nopreempt на обоих серверах и установил состояние резервного копирования на обоих серверах, но из-за высокого приоритета nopreempt не работает.

Пожалуйста, руководство, чтобы решить это?

  Master Machine: 
  ! Configuration File for keepalived
   vrrp_instance VI_1 {
   state BACKUP
   nopreempt
   interface eth0
   virtual_router_id 1
   priority 250
   advert_int 1
   virtual_ipaddress {
    192.168.1.2/24
    } 
  }

  Backup Machine :
  ! Configuration File for keepalived
   vrrp_instance VI_1 {
   state BACKUP
   nopreempt
   interface eth0
   virtual_router_id 1
   priority 200
   advert_int 1
   virtual_ipaddress {
     192.168.1.2/24
   }

}

С уважением, Бен

Источник

6 ответов

Изменено состояние обоих серверов как BACKUP. Основной с более высоким приоритетом и с nopreempt, оба имеют одинаковый идентификатор маршрутизатора. Это работает для меня.

Источник

Прежде всего: я использую CentOS 6 и keepalived 1.2.7 (02/21,2013)

Я также попробовал nopreempt, и после некоторого тестирования он работает как ожидалось.

Запуск master и резервного копирования с одинаковым приоритетом vrrp - идеальная идея, поскольку существует ошибка (AFAICT), которая приводит к ситуации, когда сервер keepalived запускает VIP. согласно http://tools.ietf.org/html/rfc5798, оставшийся в живых с самым высоким IP должен остаться / стать хозяином. Я не мог наблюдать это поведение!

(Снова AFAICT) Вы должны удалить оператор "состояние" из файла конфигурации, если хотите увидеть работу nopreempt. Если keepalived с "состоянием MASTER" в файле конфигурации запускается, он запускается как мастер и объявляет себя как таковой = плохо. Если в файле конфигурации нет оператора "state", keepalived запускается в состоянии BACKUP и прослушивает vrrp. из-за "nopreempt" он не станет MASTER, даже если он работает с наивысшим приоритетом. это противоречит странице man 5 keepalived.conf, на которой состояние не имеет большого значения.

Keepalived с prio 255 всегда становится мастером - независимо от того, включена или отключена опция nopreempt.

Если вы тестируете keepalived, внимательно изучите правила брандмауэра /nat. всегда полезно запускать что-то вроде tcpdump, чтобы проверить, проходят ли рекламные объявления vrrp и имеют ли они правильный IP-адрес отправителя (один из других keepalived(s), а не стандартный gw!). Это особенно верно, если вы используете kvm/qemu guest, так как есть правила nat по умолчанию, которые меняют рекламу vrrp.

nopreempt работает только для keepalived в состоянии BACKUP. (RTFM), если keepalived работает (1.2.7), и сетевой канал отключается. Keepalived изменяет состояние FAULT. когда сетевое соединение возвращается, keepalived становится MASTER, если prio достаточно высок. Я не знаю, если это ошибка, но она делает nopreempt как-то бесполезным. Я отправлю вопрос в список рассылки.

Повеселись! С уважением

Стефан Керст

Источник

Я перепробовал множество конфигураций для достижения этой цели, и единственной, которая работала, была установка обоих серверов в состояние BACKUP, один сервер с приоритетом 51, другой с 50 и настройка nopreempt. Вот пример конфигурации:

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 51
    nopreempt
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass XXXXXXXX
    }
    virtual_ipaddress {
        192.168.69.100/28
    }
}

Просто установите приоритет 50 на втором сервере, и все должно работать.

Источник

Это может или не может быть правильным решением для вас, но у меня есть только два сервера поддержки активности.

Если вы не хотите, чтобы один сервер опережал другой, один сервер, имеющий более высокий приоритет, чем другой, на самом деле не имеет значения в сценарии с двумя серверами, как у меня. У меня работает если я включу nopreempt и установите для обоих серверов одинаковый приоритет.

ОБНОВИТЬ

Пример конфигурации по запросу:

vrrp_sync_group VRRP_SYNCS {
    group {
        public_http_ips
    }
}

vrrp_instance public_http_ips {
    state MASTER
    interface eth0
    virtual_router_id 18
    priority 100
    advert_int 1
    nopreempt
    virtual_ipaddress {
        192.168.0.254/24 dev eth0
    }
}

Резервная копия точно такая же, но в ней указано "состояние BACKUP".

Источник

Вы должны установить параметры "fall" и "rise" в скрипте vrrp. Пример работающей конфигурации:

vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 1
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    interface eth0

    track_interface {
        eth0
        eth1
    }

    state BACKUP # same as other node
    priority 101 # your choice
    virtual_router_id 53
    advert_int 1
    nopreempt

    authentication {
        auth_type PASS
        auth_pass 8CHARPASS
    }

    unicast_src_ip 172.31.10.11 # other node: 172.31.10.12
    unicast_peer {
        172.31.10.12 # other node: 172.31.10.11
    }

    virtual_ipaddress {
        172.31.20.20 dev eth1
    }

    track_script {
        chk_haproxy
    }
}
Источник

Я думаю, что один и тот же параметр «virtual_router_id» в двух конфигурациях является ключевым здесь, с разными значениями «virtual_router_id» nopreempt не работает. Попробуйте установить тот же «virtual_router_id».

Источник
Другие вопросы по тегам