Попередити майстра VRRP не стати магістром, коли він не вдався

12

У мене є дві машини (A і B, A Master), які працюють VRPP (від keepalived) для віртуального IP.

Як я можу запобігти знову стати майстром, якщо він не вдався і повернувся (з будь-якої причини)?

Я роблю це для того, щоб у нас було одне відмовлення до другого поля, а для повернення до нормального знадобиться ручне втручання.

linux keepalived vrrp

— MrMagu
джерело

Я занадто новий, щоб створити тег "VRRP"

— MrMagu

14

Відповідно до цієї відносно старої нитки у списку розробників, що зберігається, це можна зробити. Ви встановлюєте обидва сервери з рівним пріоритетом (або взагалі відсутні), і не оголошуєте стан як для MASTER, ні BACKUP, а замість цього встановлюєте стан EQUAL для обох.

EDIT (07 грудня 2017 р.):

Виявляється, що EQUAL насправді не є дійсним станом, незважаючи на те, що, як видається, надає бажаний ефект під час опублікування цієї відповіді. Будь ласка, зверніть увагу на коментарі нижче, зокрема посилання на поточний перелік випусків для збереженої гри, надане @cristi.

— Джеймс Снірінгер
джерело

3

Дякую - Також варто звернути увагу, використовуючи вище конфігурацію (з рівним пріоритетом та використанням "EQUAL"), якщо жоден майстер не взяв на себе, екземпляр VRRP з найнижчим IP стане МАСТЕРНІМ.

— MrMagu

1

Це неправильно. Дивіться це повідомлення від розробників: github.com/acassen/keepalived/isissue/707

— cristi

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

— Джеймс Снерінгер

8

Ми вирішили це шляхом додавання nopreemptпрапора до нашого збереженого файлу конфігурації. Не потрібно було нічого іншого змінювати (все одно залишили як « MASTERі» як BACKUPі так далі). В основному це говорить про те, щоб не перемикати майстри лише тому, що новий сервер з’явився в Інтернеті, перемикаючись лише тоді, коли поточний майстер виходить з ладу.

— давр
джерело

4

з " Article.gmane.org/gmane.linux.keepalived.devel/1537 " Якщо "state" встановлено на MASTER, "nopreempt" в основному ігнорується, оскільки коли машина з "state MASTER" повертається, вона просто захопить IP з машина з "державним резервом", навіть не проводячи виборів. Мені довелося встановити обидві мої машини, щоб вони створили BACKUP, а одна - з більш високим пріоритетом, щоб "nopreempt" функціонував за призначенням.

— MrMagu

Видалено пріоритет та стан та додано без попередження. Для мене добре працює

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

-1

Як я розумію, коли з'являється новий сервер VRRP, він примушує вибори, і поточний сервер не отримує ніякої користі, тому старий майстер підійде і виграє вибори. Я сумніваюся, що ви можете багато чого зробити, щоб зупинити це, крім досить жорстокої стрільби Іншого вузла в голову. Keepalive може мати певну конфігурацію для контролю виборчого процесу. На жаль, зараз не встигаю перевірити, але спробую подивитися пізніше.

— Девід Пашлі
джерело

Для цього є прапор конфігурації, тому ця відповідь є неправильною.

— davr

Проголосована відповідь правильна для загального розгортання vrrp, де ви не хочете, щоб майстер взяв на себе, коли він повертається до служби. Як ви кажете, також існує чудовий спосіб зробити це, що, ймовірно, більш правильно для виконання файлів HA Linux, а не просто використання vrrp для забезпечення надмірності L3 для маршруту за замовчуванням (більш традиційна причина використання vrrp).

— chris