Не дать мастеру VRRP стать мастером после неудачи

12

У меня есть две машины (A и B, A - Master), на которых работает VRPP (из keepalived) для виртуального IP.

Как я могу помешать А снова стать Мастером, если он потерпел неудачу и вернулся (по какой-либо причине)?

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

linux keepalived vrrp

— MrMagu
источник

Я слишком нов, чтобы создать тег "VRRP"

— MrMagu

14

Согласно этому относительно старому потоку в списке разработчиков, поддерживающему поддержку, это можно сделать. Вы устанавливаете оба сервера равным приоритетом (или ни одного вообще) и не объявляете состояние для MASTER или BACKUP, а вместо этого устанавливаете состояние EQUAL для обоих.

РЕДАКТИРОВАТЬ (07-Dec-2017):

Похоже, что EQUAL на самом деле не является действительным состоянием, несмотря на то, что оно, по-видимому, обеспечивает желаемый эффект на момент публикации этого ответа. Пожалуйста, обратите внимание на комментарии ниже, в частности, ссылку на текущий список вопросов для keepalived, предоставленный @cristi.

— Джеймс Снерингер
источник

3

Спасибо. Также стоит отметить, что при использовании вышеуказанной конфигурации (с равным приоритетом и при использовании «EQUAL»), если ни один мастер не вступил во владение, экземпляр VRRP с самым низким IP станет MASTER.

— MrMagu

1

Это не правильно. Посмотрите это сообщение от разработчиков: github.com/acassen/keepalived/issues/707

— cristi

@cristi - это было рабочее решение на момент публикации (2009 г.), которое, в свою очередь, основывалось на информации, которую я четко признал, было старым даже в 2003 г. Я обновил ссылку в своем ответе на рабочую, поскольку на osdir.com, похоже, больше нет архивов keepalived-devel. Я полагаю, что в то время программа молча игнорировала недопустимую EQUALдирективу и воспринимала ее так, как если бы приоритет не был установлен (что, как оказалось, оказало желаемый эффект).

— Джеймс

8

Мы решили это, добавив nopreemptфлаг в наш конфигурационный файл keepalived. Больше ничего менять не пришлось (все равно оставалось одно как MASTERи одно как BACKUPи так далее). В основном это говорит о том, что не следует переключать мастеров только потому, что новый сервер подключен к сети, переключаться только при сбое текущего мастера.

— Davr
источник

4

from " article.gmane.org/gmane.linux.keepalived.devel/1537 " Если для "state" установлено значение MASTER, то "nopreempt" в основном игнорируется, поскольку при возврате машины с "state MASTER" он просто получает IP-адрес от машина с "State BACKUP" даже без проведения выборов. Я должен был установить обе мои машины в состояние BACKUP с одной, имеющей более высокий приоритет, чтобы "nopreempt" функционировал как предполагалось.

— MrMagu

Удалил приоритет и состояние и добавил nopreempt. У меня хорошо работает

— Рихард Новожилов

-1

Насколько я понимаю, когда появляется новый VRRP-сервер, он вызывает выборы, а текущий сервер не получает никакой выгоды, поэтому старый мастер подойдет и победит на выборах. Я сомневаюсь, что вы могли бы многое сделать, чтобы остановить это, за исключением довольно зверского Shoot The Other Node In The Head. Keepalive может иметь некоторую конфигурацию для управления процессом выборов. К сожалению, у меня нет времени, чтобы проверить сейчас, но я постараюсь посмотреть позже.

— Дэвид Пашли
источник

Для этого есть флаг конфигурации, поэтому этот ответ неверен.

— Давр

Голосованный ответ является правильным для общего развертывания vrrp, когда вы не хотите, чтобы мастер вступал во владение, когда он возвращается в службу. Как вы говорите, существует также поддерживающий способ сделать это, который, вероятно, более корректен, когда вы выполняете linux HA, вместо того, чтобы просто использовать vrrp для обеспечения избыточности L3 для маршрута по умолчанию (более традиционная причина использования vrrp).

— Крис