збережений VRRP_script не виходить з ладу


11

Тому я працюю на двох серверах, і я не можу домогтися переходу на інший.

Нижче у мене є конфігурація для одного з серверів. Єдине, що відрізняється між ними, - це головний номер пріоритету, який становить 110, а зворотній - 109.

Але коли я зупиняю свій процес із /etc/init.d/process stop keepalived не закінчується. Я просто отримую збій VRRP_Script (chk_script) і більше нічого. Ніяких відмов чи нічого.

vrrp_script chk_script {
script "/usr/local/bin/failover.sh"
interval 2
weight 2
}

vrrp_instance HAInstance {
state BACKUP
interface eth0
virtual_router_id 8
priority 109
advert_int 1
nopreempt
vrrp_unicast_bind 10.10.10.8
vrrp_unicast_peer 10.10.10.9
virtual_ipaddress {
  10.10.10.10/16 dev eth0
}
notify /usr/local/bin/keepalivednotify.sh
track_script {
  chk_script weight 20
}
}

Це мій chk_script нижче. Така ж проблема трапляється і тоді, коли я виконую процес killall -0, як і мій сценарій.

!/bin/bash
SERVICE='process'
STATUS=$(ps ax | grep -v grep | grep $SERVICE)

if [ "$STATUS" != "" ]
then
    exit 0
else
    exit 1
fi

Хтось знає виправлення на це? Дякую.


Чи помічає ваш екземпляр резервного копіювання зміни пріоритету чи щось записує? Журнали з обох були б корисними.
Джим Г.

Ні, це не є. Єдиний раз, коли він помічає зміни, - коли господар йде. Таких, як, коли я перестаю зберігати очі. Припинення процесу, за яким я монітору, показує, що VRRP_Script (chk_script) не вдався до майстра. З нічого на рабі.
Nvasion

Відповіді:


13

У мене була точно така ж проблема, проте моя проблема була не в брандмауері, ані в адаптері Ethernet, а в налаштуваннях "ваги" контрольного сценарію.

Це була моя конфігурація:

МАЙСТЕР:

vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1

НАЗАД:

vrrp_instance haproxy {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1

Контрольний сценарій:

vrrp_script chk_haproxy {
   script "python /root/ha_check.py"
   interval 2     # check every 2 seconds
   weight 2
   rise 2
   fall 2

}

Причина, від якої майстер відмовлявся випускати VIP, полягав у тому, що, незважаючи на те, що сценарій не вдався, він все ще мав більш високий пріоритет від сервера BACKUP. Це сталося тому, що налаштування "ваги" для check_script було недостатньо, щоб покрити "GAP" між номером пріоритету, тобто збільшив номер пріоритету на сервері BACKUP, більший за один з MASTER Server. Я поясню далі:

Згідно з посібником із збереженої ваги, позитивне число у налаштуваннях "вага" додасть це число до пріоритету, якщо перевірка буде успішною.
Відмовне число відніме це число від пріоритетного, якщо перевірка не вдасться.

Отже, відповідно до моєї конфігурації:

Пріоритети сервера Попередній збій сценарію:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER

Ip відключення правильно "схопили" головним сервером, оскільки Master має більш високий пріоритет порівняно з резервним сервером (152> 100)

Пріоритети сервера ПІСЛЯ відмови сценарію:
MASTER-сервер: 148
BACKUP-сервер: 102
Failover_IP: ВІДПОВІДЬ НА MASTER

Ip відключення все ще знаходиться на головному сервері, оскільки Master знову має більший пріоритет порівняно з BACKUP (148> 102). Сервер MASTER відмовився випускати IP-адресу, і це він зробив, оскільки його пріоритет був вищим, ніж у іншого сервера.

Вирішенням моєї ситуації було:

Рішення -1: Змініть номер пріоритету обох серверів, щоб у них не було багато "GAP".
Наприклад:
Основний пріоритет: 150
Пріоритет резервного копіювання: 149
Вага контрольної скрипту: Як є (2).

При наведеній вище конфігурації, коли сценарій успішний (мається на увазі все нормально), пріоритетами були б:
Master: 152
Резервне копіювання: 149
IP_Location: On Master (152> 149)

Якщо сценарій не працює:
Master: 150
Резервне копіювання: 151
IP_Location: У режимі резервного копіювання (151> 150)

Рішення - 2: Змініть кількість ваги сценарію з 2, на -60


Також здається, що взагалі не вказати вагу означає, що невдалий track_script спровокує стан несправності безпосередньо
Оскар

@Nvasion: Будь ласка, прийміть цю відповідь, оскільки я теж вирішив свою проблему.
Анкур Соні

4

У мене була та сама проблема - два сервери CentOS 7.1 з track_script, і якщо помилка vrrp_script на MASTER призведе до того, що повідомлення про одиночний журнал "VRRP_Script (chk_script) не вдалося", а не перелом. На сервері BACKUP, однак, я отримав багато повідомлень про збережене повідомлення про те, щоб захопити віртуальний IP протягом тих пір, поки у мене не вийшов трек-скрипт на сервері MASTER.

Рішення в моєму випадку: брандмауер (iptables) на сервері MASTER не був налаштований правильно для дозволу пакетів VRRP / багатоадресної передачі, в той же час брандмауер на іншому сервері, BACKUP, був налаштований правильно.

Я ввів однакові правила iptables на обидва сервери, як показано нижче:

iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

Це працювало на одному з серверів (BACKUP VRRP-сервер), але не на MASTER, тому що я забув, що інтерфейс не був названий 'eth0' на сервері MASTER, тому два правила взагалі не мали ніякого ефекту.

Це пояснило поведінку, яку я спостерігав:

Якщо keepalived не може бачити жодного іншого динаміка VRRP для певного virtual_router_id, він все ще вважає себе таким, що має найвищий пріоритет (таким чином, правомірний MASTER) навіть після зміни негативної ваги, оскільки він ніколи не отримує повідомлення VRRP з пріоритетом, вищим, ніж його власний ( оскільки реклама інших динаміків заблокована брандмауером і ніколи не може дістатись до невідповідного процесу, щоб дати їм знати про них). Тому ви не бачите, щоб він випустив VIP.

Сервер BACKUP, однак, зміг побачити рекламу (зараз невдалого) MASTER, знайшов пріоритет у цих пакетах, зменшених до значення, менших за його власне, і продовжував оголошувати себе MASTER та надсилати безоплатно ARP, щоб претендувати на VIP. Тож ми опинилися в ситуації, коли обидва сервери думали, що їм потрібно буде служити VIP як МАЙСТЕР.

Висновки: - Завжди перевіряйте конфігурацію брандмауера на всіх динаміках VRRP, якщо ви відчуваєте дивну поведінку (відсутність відмови, кілька MASTER). Захищений журнал не настільки корисний, як міг би бути (просте повідомлення "VIP не випущено, тому що я все ще є найвищим пріоритетом" після того, як "VRRP_Script (chk_script)" не вдалося ", це полегшило б усунення несправностей.

  • Track_script не є типом перемикання вмикання / вимкнення ("якщо сценарій ОК: придатний для проведення виборів VIP; якщо НЕ ОК: абсолютно непридатний для виборів VIP") - він просто збільшує / зменшує ймовірність перемоги на виборах, і якщо тільки буде збережено коли-небудь спостерігає за собою як єдиного спікера VRRP і ніколи не отримує жодних повідомлень інших спікерів, вибори насправді не багато - ви завжди виграєте.

0

Я просто зіткнувся з такою ж ситуацією, як і ви, і дещо вивчав тему про збереження. Давайте подумаємо, що відбувається на кожному сервері. Припускаючи, що ви хочете реалізувати архітектуру відмови вручну,

На 1-му вузлі BACKUP

Кожен раз, коли track_script відмовляється від кількості падінь, він надсилає рекламу на 2-й вузол BACKUP. Тут вказується пріоритет у рекламі. У вашому випадку,

129 (109 + 20)

надсилається на 2-й сервер BACKUP.

На 2-му сервері BACKUP

Далі йде 2-й вузол BACKUP.

За даними RFC ,

If the Priority in the ADVERTISEMENT is Zero, then:

  o  Set the Master_Down_Timer to Skew_Time
else:

  If Preempt_Mode is False, or If the Priority in the
  ADVERTISEMENT is greater than or equal to the local
  Priority, then:

    o Reset the Master_Down_Timer to Master_Down_Interval
  else:

    o Discard the ADVERTISEMENT
  endif
endif

Оскільки у вас не ввімкнено попередження, і ви отримаєте vrrp з пріоритетом, другий вузол BACKUP не перейде до фази переходу стану.

Рішення

Тож якщо ви хочете, щоб перехід стану відбувся на другому вузлі, ви можете,

  1. Набір ваги в 0 на 1 - му вузлі BACKUP. Це надішле рекламу з пріоритетом 0 на другий вузол BACKUP. doc описує більше про вагу 0.

  2. Вимкніть неприйняття на другому вузлі BACKUP.

  3. Встановіть вагу принаймні -2 на 1-му вузлі BACKUP.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.