В этом руководстве я опишу установку и настройку Keepalived для организации отказоустойчивого виртуального IP-адреса (VIP) на серверах lb-host-1 и lb-host-2.
1
Установка Keepalived
На обоих
серверах lb-host-1 и lb-host-2 выполните:
sudo
apt update && sudo apt install keepalived -y
Или на CentOS/RHEL:
sudo
yum install keepalived -y
2 Настройка Keepalived
На основном сервере lb-host-1 (Master)
Редактируем
конфиг:
sudo nano /etc/keepalived/keepalived.conf
Добавляем
конфигурацию:
vrrp_instance VI_1 {
state
MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
10.10.10.50
}
}
Сохраните файл Ctrl+X, затем Y, Enter.
На резервном сервере lb-host-2 (Backup)
Открываем
конфигурационный файл:
sudo nano /etc/keepalived/keepalived.conf
Добавляем
следующий код:
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
10.10.10.50
}
}
Сохраните файл.
3 Запуск и включение Keepalived
На обоих
серверах выполняем:
sudo
systemctl enable keepalived --now
sudo
systemctl status keepalived
4 Проверка работы
На Master (lb-host-1) выполните:
ip a | grep 10.10.10.50
Вы должны
увидеть, что VIP-адрес 10.10.10.50 привязан к интерфейсу.
Затем отключите lb-host-1 командой:
bash
CopyEdit
sudo
systemctl stop keepalived
Теперь
выполните команду на Backup (lb-host-2):
ip
a | grep 10.10.10.50
Если Keepalived работает правильно, VIP-адрес должен автоматически
переключиться на резервный сервер.
Для возврата
обратно запустите Keepalived на Master:
sudo
systemctl start keepalived
5 Диагностика
Если что-то не
работает:
- Проверить логи:
bash
CopyEdit
sudo
journalctl -u keepalived --no-pager | tail -20
- Проверить, есть ли VIP:
bash
CopyEdit
ip
a | grep 10.10.10.50
- Проверить работу службы:
bash
CopyEdit
sudo
systemctl status keepalived
После всех
проверок ваш Keepalived + VIP должен работать! 🚀
Распиши все
параметры в конфиге объясни как работает согласование между серверами keepalived
Подробное руководство по Keepalived и объяснение параметров
1 Как работает Keepalived и согласование между серверами
Keepalived использует VRRP (Virtual Router Redundancy Protocol), который обеспечивает автоматическое
переключение виртуального IP (VIP) между узлами.
🔹 VRRP назначает один сервер как MASTER, а другой как BACKUP.
🔹 Сервер MASTER постоянно отправляет advertisement-пакеты (анонсы) на BACKUP.
🔹 Если BACKUP перестает получать пакеты от MASTER (например, сервер выключился), он становится MASTER и берет на себя VIP-адрес.
🔹 При возвращении MASTER в строй, если его приоритет выше, он снова забирает VIP-адрес.
2
Разбор конфигурации Keepalived
Пример
конфигурации Master-сервера (lb-host-1):
vrrp_instance
VI_1 {
state MASTER # Состояние сервера
(MASTER или BACKUP)
interface eth0 # Сетевой интерфейс, на
котором будет работать Keepalived
virtual_router_id 51 #
Уникальный ID виртуального роутера (должен быть одинаковый на всех
узлах)
priority 100
# Приоритет сервера (чем выше, тем главнее)
advert_int 1
# Интервал в секундах, с которым MASTER отправляет пакеты VRRP
authentication {
auth_type PASS #
Тип аутентификации (PASS - простой пароль)
auth_pass secret #
Пароль для защиты VRRP-сообщений
}
virtual_ipaddress {
10.10.10.50 #
Виртуальный IP, который будет переходить между серверами
}
}
📌 Как работает этот конфиг:
- Master отправляет
VRRP-пакеты раз в 1 секунду (advert_int 1).
- Если Backup не получает их в течение 3 секунд (обычно 3
интервала), он становится новым Master.
- Backup имеет
более низкий priority, поэтому он берет на себя VIP только при сбое Master.
Пример конфигурации Backup-сервера (lb-host-2):
vrrp_instance
VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
10.10.10.50
}
}
📌 Отличие от Master:
- state BACKUP — сервер работает в режиме ожидания.
- priority 90 — ниже,
чем у MASTER, поэтому он не будет назначать себе VIP, пока MASTER жив.
- Все
остальные параметры должны совпадать.
3
Подробное объяснение параметров
|
Параметр |
Описание |
|
vrrp_instance VI_1 |
Определяет
группу VRRP. VI_1 – уникальное имя группы. |
|
state MASTER/BACKUP |
Указывает
роль узла в VRRP-кластере. MASTER – активный, BACKUP – резервный. |
|
interface eth0 |
Указывает
сетевой интерфейс, к которому привязывается виртуальный IP. |
|
virtual_router_id 51 |
Уникальный ID VRRP-группы (от 1 до 255). Должен быть одинаковым на всех
серверах. |
|
priority 100 |
Приоритет. Чем выше, тем главнее. MASTER должен иметь
более высокий приоритет, чем BACKUP. |
|
advert_int 1 |
Время (в
секундах) между отправкой VRRP-анонсов. Чем
меньше, тем быстрее происходит переключение. |
|
authentication |
Блок
аутентификации VRRP (для защиты от поддельных пакетов). |
|
auth_type PASS |
Используется парольная
аутентификация. |
|
auth_pass secret |
Пароль для
аутентификации VRRP-сообщений. |
|
virtual_ipaddress |
Список
виртуальных IP, которые будут назначаться MASTER и переходить к BACKUP. |
4
Сценарии переключения VIP
🔴 Сбой MASTER-сервера (lb-host-1)
- MASTER отправляет
VRRP-анонсы каждые 1 секунду.
- BACKUP ждет 3
секунды без VRRP-пакетов.
- После 3
секунд BACKUP становится MASTER и забирает VIP 10.10.10.50.
🟢 Возвращение
MASTER-сервера
- При
запуске MASTER проверяет,
есть ли уже MASTER с таким же virtual_router_id.
- Если его priority выше, он отбирает VIP обратно.
- BACKUP снова
становится резервным.
5 Проверка работы
После настройки
Keepalived выполните на Master:
ip
a | grep 10.10.10.50
Если всё
работает, VIP будет привязан к интерфейсу eth0.
Остановите Master:
sudo
systemctl stop keepalived
Теперь на Backup:
ip
a | grep 10.10.10.50
VIP должен появиться на lb-host-2.
Запустите Master обратно:
sudo
systemctl start keepalived
VIP вернется на lb-host-1.
6 Логирование и диагностика
Проверка состояния
Keepalived:
sudo
systemctl status keepalived
Просмотр логов работы:
sudo
journalctl -u keepalived --no-pager | tail -20
Проверка VRRP-состояния:
watch
-n 1 "ip a | grep 10.10.10.50"
Эта команда
будет обновлять состояние VIP каждую секунду.
7️ Дополнительные настройки
1. Автостарт Keepalived
Чтобы Keepalived запускался при перезагрузке, выполните:
sudo
systemctl enable keepalived
2. Отправка уведомлений при переключении
Добавьте в keepalived.conf:
notify_master
"/usr/local/bin/master.sh"
notify_backup
"/usr/local/bin/backup.sh"
notify_fault
"/usr/local/bin/fault.sh"
Создайте скрипты /usr/local/bin/master.sh:
#!/bin/bash
echo
"Switched to MASTER on $(hostname)" | mail -s "Keepalived MASTER
Alert" admin@example.com
Аналогично
создайте backup.sh и fault.sh.
Сделайте их
исполняемыми:
chmod
+x /usr/local/bin/*.sh
Заключение
Теперь у вас
настроен отказоустойчивый VIP с Keepalived. 🎯
Что в итоге мы
сделали?
✅ Установили Keepalived.
✅ Настроили VRRP и виртуальный IP-адрес.
✅ Объяснили все параметры.
✅ Проверили и протестировали отказоустойчивость.
Теперь, если
один сервер выходит из строя, другой автоматически забирает VIP. 🚀
Как сервер keepalived находит другой сервер и отправляет на него VRRP трафик?
Как Keepalived находит другой сервер и отправляет VRRP-трафик?
Keepalived использует VRRP (Virtual Router Redundancy Protocol) для обмена информацией между MASTER и BACKUP-серверами. Давайте разберем, как это работает на уровне сети.
1 Как сервера находят друг друга?
Когда Keepalived запускается, он использует многоадресную (multicast) рассылку на VRRP-группу 224.0.0.18 с протоколом IP/VRRP (протокол 112).
🔹 Каждый сервер слушает пакеты на этом мультикасте
🔹 MASTER-сервер отправляет VRRP-анонсы (advertisement packets), сообщая о своем существовании
🔹 BACKUP-сервер слушает эти пакеты, ожидая сбоя MASTER
2 Как работает передача VRRP-пакетов?
VRRP-пакеты идут только в локальной сети (L2, Broadcast domain), так как 224.0.0.18 не
маршрутизируется!
📌 Что происходит в сети?
- MASTER каждые advert_int секунд (обычно 1 секунда) отправляет VRRP-анонсы на 224.0.0.18
- BACKUP получает
эти пакеты и понимает, что MASTER жив
- Если BACKUP не получает пакеты advert_int * 3 секунд, он переходит в MASTER и
назначает себе VIP
📌 Пример VRRP-пакета:
Source
IP: 10.10.10.51 (lb-host-1, MASTER)
Destination
IP: 224.0.0.18 (VRRP Multicast Group)
Protocol:
VRRP (112)
Payload:
[VRRP Advertisement, priority=100, Virtual IP=10.10.10.50]
3 Проверка VRRP-трафика
🔍 Как проверить, что идут VRRP-пакеты?
На BACKUP-сервере запустите команду:
sudo
tcpdump -i eth0 -n -vv proto 112
Пример вывода:
makefile
CopyEdit
15:43:10.123456
IP 10.10.10.51 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100,
interval 1s
15:43:11.123457
IP 10.10.10.51 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100,
interval 1s
Это означает,
что MASTER отправляет VRRP-анонсы каждые 1 секунду.
Если в логах нет VRRP-анонсов, BACKUP не видит MASTER и активирует VIP.
4 Почему VRRP-пакеты могут не доходить?
1 Мультикаст-фильтрация
🔹 Если сеть блокирует мультикаст (224.0.0.18), VRRP не работает.
🔹 Проверьте, разрешен ли IGMP и мультикаст в настройках коммутатора.
🔹 Откройте iptables и проверьте блокировку:
sudo
iptables -L -nv | grep 112
🔹 Если VRRP заблокирован, добавьте правило:
sudo
iptables -A INPUT -p vrrp -j ACCEPT
2 Ошибки с интерфейсом
🔹 Убедитесь, что в конфиге interface eth0 указан правильный интерфейс.
🔹 Посмотрите доступные интерфейсы
командой:
ip link show
3 Разные virtual_router_id
🔹 Оба сервера должны иметь одинаковый virtual_router_id.
🔹 Проверьте конфиг /etc/keepalived/keepalived.conf на обоих серверах.
5
Итог
✅ Keepalived использует VRRP (протокол 112) и
мультикаст 224.0.0.18
✅ MASTER отправляет VRRP-анонсы раз
в advert_int секунд
✅ BACKUP получает
пакеты и ждет advert_int
* 3 секунд
✅ Если пакеты не приходят, BACKUP становится MASTER и берет VIP
✅ Проверить VRRP можно через tcpdump
✅ Ошибки чаще всего связаны с фильтрацией мультикаста
или разными virtual_router_id
Теперь Keepalived будет переключать VIP мгновенно при сбоях! 🚀
Что произойдет
если в сети будет несколько одинаковых virtual_router_id от разных кластеров?
Что произойдет, если в сети будет несколько одинаковых virtual_router_id от разных кластеров?
🔍 1. Как работает virtual_router_id?
virtual_router_id (VRID) — это идентификатор виртуального
маршрутизатора в VRRP.
- Один VRID = одна
VRRP-группа
- Все
серверы в одной VRRP-группе должны иметь одинаковый VRID
- Разные VRRP-кластеры должны использовать разные VRID, иначе возможны конфликты
🔥 2. Возможные проблемы при одинаковых virtual_router_id у разных кластеров
Если в сети
работают несколько независимых VRRP-кластеров с одинаковым virtual_router_id, они начнут видеть друг друга как часть
одной группы. Это приведет
к конфликтам и неожиданным переключениям VIP.
📌 Возможные сценарии проблем:
1 Перехват VIP-адресов между кластерами
- Один
кластер неожиданно станет MASTER для другого
- VIP может перемещаться
между кластерами случайным образом
2 Флуктуация VRRP-состояний
(flapping)
- Серверы
будут постоянно переизбирать MASTER, так как
видят "чужие" VRRP-пакеты
- В логах
появятся частые переходы MASTER → BACKUP → MASTER
3 Конфликт с разными VIP-адресами
- Если два
кластера с одинаковым VRID
используют разные виртуальные IP-адреса, Keepalived может
случайно удалить/перезаписать VIP одного
кластера
⚠ 3. Как избежать проблемы?
1 Используйте
уникальный virtual_router_id для каждого VRRP-кластера
- Например:
- VRRP для балансировщиков: virtual_router_id
51
- VRRP для баз данных: virtual_router_id 52
- VRRP для веб-серверов: virtual_router_id
53
2 Ограничьте VRRP-пакеты на уровне сети
Если ваши VRRP-кластеры не должны взаимодействовать, настройте VLAN'ы или используйте iptables, чтобы пакеты VRRP одного кластера не доходили до другого.
Пример правила
для блокировки "чужих" VRRP-пакетов:
sudo
iptables -A INPUT -p vrrp -s ! 10.10.10.0/24 -j DROP
Это правило
блокирует VRRP-трафик, который не пришел из локальной сети.
✅ Вывод
Если несколько VRRP-кластеров в
одной сети используют одинаковый virtual_router_id, это может вызвать:
🚨 Перехват VIP между кластерами
🚨 Нестабильную работу Keepalived (flapping)
🚨 Непредсказуемые конфликты IP
🛠 Решение:
✔ Используйте уникальный virtual_router_id для каждого кластера
✔ Ограничьте VRRP-трафик на уровне сети
Теперь ваши VRRP-кластеры будут работать стабильно! 🚀
-- Logs begin at Thu 2025-03-27
09:46:16 MSK, end at Fri 2025-03-28 12:30:38 MSK. -- Mar 28 12:30:24 lb-host-1
systemd[1]: Starting Keepalive Daemon (LVS and VRRP)... Mar 28 12:30:24 lb-host-1
Keepalived[3966]: Starting Keepalived v1.2.24 (02/14,2019) Mar 28 12:30:24 lb-host-1
Keepalived[3966]: Opening file '/etc/keepalived/keepalived.conf'. Mar 28
12:30:24 lb-host-1 Keepalived[3968]: Starting Healthcheck child process,
pid=3969 Mar 28 12:30:24 lb-host-1 Keepalived_healthcheckers[3969]:
Initializing ipvs Mar 28 12:30:24 lb-host-1 Keepalived[3968]: Starting VRRP
child process, pid=3970 Mar 28 12:30:24 lb-host-1 Keepalived_vrrp[3970]:
Registering Kernel netlink reflector Mar 28 12:30:24 lb-host-1
Keepalived_vrrp[3970]: Registering Kernel netlink command channel Mar 28
12:30:24 lb-host-1 Keepalived_vrrp[3970]: Registering gratuitous ARP shared
channel Mar 28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: Unable to load ipset
library Mar 28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: Unable to initialise
ipsets Mar 28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: Opening file
'/etc/keepalived/keepalived.conf'. Mar 28 12:30:24 lb-host-1
Keepalived_vrrp[3970]: VRRP Error : VRID not valid ! Mar 28 12:30:24 lb-host-1
Keepalived_vrrp[3970]: must be between 1 & 255. reconfigure ! Mar 28
12:30:24 lb-host-1 Keepalived_vrrp[3970]: Truncating auth_pass to 8 characters
Mar 28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: VRRP_Instance(VI_1) the
virtual id must be set! Mar 28 12:30:24 lb-host-1
Keepalived_healthcheckers[3969]: Registering Kernel netlink reflector Mar 28
12:30:24 lb-host-1 Keepalived_healthcheckers[3969]: Registering Kernel netlink
command channel Mar 28 12:30:24 lb-host-1 Keepalived_healthcheckers[3969]:
Opening file '/etc/keepalived/keepalived.conf'. Mar 28 12:30:24 lb-host-1
Keepalived_healthcheckers[3969]: Using LinkWatch kernel netlink reflector...
Mar 28 12:30:24 lb-host-1 systemd[1]: Started Keepalive Daemon (LVS and VRRP).
Mar 28 12:30:25 lb-host-1 Keepalived_vrrp[3970]: Stopped Mar 28 12:30:25 lb-host-1
Keepalived[3968]: pid 3970 exited with permanent error CONFIG. Terminating Mar
28 12:30:25 lb-host-1 Keepalived[3968]: Stopping Mar 28 12:30:30 lb-host-1
Keepalived[3968]: Stopped Keepalived v1.2.24 (02/14,2019)
Анализ логов Keepalived и исправление ошибок
В вашем логе
есть несколько ключевых ошибок, из-за которых Keepalived не запускается корректно:
1
Ошибка: VRRP Error : VRID not valid !
Mar
28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: VRRP Error : VRID not valid !
Mar
28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: must be between 1 & 255.
reconfigure !
🔍 Проблема: В конфигурации /etc/keepalived/keepalived.conf неправильно указан virtual_router_id или он отсутствует.
VRRP требует, чтобы virtual_router_id был в диапазоне от 1 до 255.
🔧 Решение:
- Проверьте ваш конфиг:
sudo
nano /etc/keepalived/keepalived.conf
- Найдите
строку с virtual_router_id и
убедитесь, что там стоит корректное значение.
Пример исправленного конфига:
vrrp_instance
VI_1 {
state MASTER
interface eth0
virtual_router_id 51 # ✅
Убедитесь, что это значение от 1 до 255
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
10.10.10.50
}
}
- Сохраните
конфиг и перезапустите Keepalived:
sudo
systemctl restart keepalived
2
Ошибка: Truncating auth_pass to 8 characters
Mar
28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: Truncating auth_pass to 8
characters
🔍 Проблема: Пароль в блоке authentication длиннее 8 символов, а Keepalived обрезает его.
🔧 Решение:
Используйте пароль не длиннее 8 символов. Например:
authentication
{
auth_type PASS
auth_pass mypass12 # ✅
8 символов или меньше
}
После изменения
перезапустите Keepalived:
sudo
systemctl restart keepalived
3
Ошибка: Unable to load ipset library / Unable to
initialise ipsets
Mar
28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: Unable to load ipset library
Mar
28 12:30:24 lb-host-1 Keepalived_vrrp[3970]: Unable to initialise ipsets
🔍 Проблема: Keepalived не может загрузить библиотеку ipset, которая используется для управления IP-наборами в Linux.
🔧 Решение:
- Установите ipset:
sudo
apt install ipset -y # Для Debian/Ubuntu
sudo
yum install ipset -y # Для CentOS/RHEL
- Перезапустите Keepalived:
sudo
systemctl restart keepalived
4
Ошибка: pid 3970 exited with permanent error
CONFIG. Terminating
Mar
28 12:30:25 lb-host-1 Keepalived[3968]: pid 3970 exited with permanent error
CONFIG. Terminating
🔍 Проблема: Keepalived не смог загрузить конфигурацию, из-за
чего процесс остановился.
🔧 Решение:
- Проверьте конфигурацию на ошибки:
sudo
keepalived -t -f /etc/keepalived/keepalived.conf
- Если есть
ошибки, исправьте их и перезапустите сервис:
sudo
systemctl restart keepalived
Заключение
🔹 Исправьте virtual_router_id (от 1 до 255)
🔹 Используйте auth_pass не длиннее 8 символов
🔹 Установите ipset, если его нет
🔹 Проверяйте конфиг перед запуском (keepalived
-t)
После этих
исправлений Keepalived должен запуститься без ошибок! 🚀
Mar 28 12:33:55 lb-host-1
Keepalived_vrrp[3991]: bogus VRRP packet received on ens192 !!! Mar 28 12:33:55
lb-host-1 Keepalived_vrrp[3991]: VRRP_Instance(VI_1) Dropping received VRRP
packet... Mar 28 12:33:56 lb-host-1 Keepalived_vrrp[3991]: (VI_1): received a 0
auth, expecting 1! Mar 28 12:33:56 lb-host-1 Keepalived_vrrp[3991]: bogus VRRP
packet received on ens192 !!! Mar 28 12:33:56 lb-host-1 Keepalived_vrrp[3991]:
VRRP_Instance(VI_1) Dropping received VRRP packet... Mar 28 12:33:57 lb-host-1
Keepalived_vrrp[3991]: (VI_1): received a 0 auth, expecting 1! Mar 28 12:33:57 lb-host-1
Keepalived_vrrp[3991]: bogus VRRP packet received on ens192 !!! Mar 28 12:33:57
lb-host-1 Keepalived_vrrp[3991]: VRRP_Instance(VI_1) Dropping received VRRP
packet... Mar 28 12:33:58 lb-host-1 Keepalived_vrrp[3991]: (VI_1): received a 0
auth, expecting 1! Mar 28 12:33:58 lb-host-1 Keepalived_vrrp[3991]: bogus VRRP
packet received on ens192 !!! Mar 28 12:33:58 lb-host-1 Keepalived_vrrp[3991]:
VRRP_Instance(VI_1) Dropping received VRRP packet... Mar 28 12:33:59 lb-host-1
Keepalived_vrrp[3991]: (VI_1): received a 0 auth, expecting 1! Mar 28 12:33:59 lb-host-1
Keepalived_vrrp[3991]: bogus VRRP packet received on ens192 !!! Mar 28 12:33:59
lb-host-1 Keepalived_vrrp[3991]: VRRP_Instance(VI_1) Dropping received VRRP
packet... Mar 28 12:34:00 lb-host-1 Keepalived_vrrp[3991]: (VI_1): received a 0
auth, expecting 1! Mar 28 12:34:00 lb-host-1 Keepalived_vrrp[3991]: bogus VRRP
packet received on ens192 !!! Mar 28 12:34:00 lb-host-1 Keepalived_vrrp[3991]:
VRRP_Instance(VI_1) Dropping received VRRP packet... Mar 28 12:34:01 lb-host-1
Keepalived_vrrp[3991]: (VI_1): received a 0 auth, expecting 1! Mar 28 12:34:01 lb-host-1
Keepalived_vrrp[3991]: bogus VRRP packet received on ens192 !!! Mar 28 12:34:01
lb-host-1 Keepalived_vrrp[3991]: VRRP_Instance(VI_1) Dropping received VRRP
packet... Mar 28 12:34:02 lb-host-1 Keepalived_vrrp[3991]: (VI_1): received a 0
auth, expecting 1! Mar 28 12:34:02 lb-host-1 Keepalived_vrrp[3991]: bogus VRRP
packet received on ens192 !!! Mar 28 12:34:02 lb-host-1 Keepalived_vrrp[3991]:
VRRP_Instance(VI_1) Dropping received VRRP packet...
Анализ ошибок Keepalived и их исправление
В логах Keepalived на интерфейсе ens192 видны ошибки:
- bogus VRRP packet received on ens192 !!!
- VRRP_Instance(VI_1) Dropping received VRRP packet...
- (VI_1): received a 0 auth, expecting 1!
Это указывает
на проблемы с аутентификацией VRRP-пакетов между MASTER и BACKUP.
🔍 Причины ошибки и их решения
1
Ошибка: received a 0 auth, expecting 1!
🔍 Проблема:
Один сервер отправляет VRRP-пакеты без аутентификации, а другой ожидает аутентификацию.
🔧 Решение:
- Проверьте файл конфигурации /etc/keepalived/keepalived.conf на обоих серверах и убедитесь, что секция authentication одинаковая.
✅ Должно быть так (одинаково на обоих
серверах!):
authentication
{
auth_type PASS
auth_pass secret123 # Убедитесь,
что пароль не длиннее 8 символов!
}
- Перезапустите
Keepalived на обоих серверах:
sudo
systemctl restart keepalived
- Проверьте логи после перезапуска:
sudo
journalctl -u keepalived --since "5 minutes ago"
2
Ошибка: bogus VRRP packet received on ens192
!!!
🔍 Проблема:
Keepalived получает VRRP-пакеты с неверными параметрами. Возможные
причины:
- Несовпадающие virtual_router_id на
MASTER и BACKUP
- VRRP-пакеты приходят от сервера, который не настроен в
кластере
- Проблемы с мультикастом в сети
🔧 Решение:
- Проверьте,
что virtual_router_id одинаковый на обоих серверах:
vrrp_instance
VI_1 {
virtual_router_id 51 # Должно быть
одинаковым везде!
}
- Проверьте,
что оба сервера находятся в одной сети и получают VRRP-пакеты. Запустите
команду на BACKUP:
sudo
tcpdump -i ens192 -n -vv proto 112
Если пакеты
приходят, но их структура неправильная — значит, проблема в конфигурации VRRP.
- Проверьте,
нет ли других серверов с таким же virtual_router_id, но не
относящихся к вашему кластеру. Используйте tcpdump, чтобы
посмотреть отправителей:
sudo
tcpdump -i ens192 -n -vvv
Если VRRP-пакеты приходят от неизвестного сервера, он может мешать работе.
- Проверьте
настройки мультикаста, так как VRRP
использует 224.0.0.18:
sudo
ip route show | grep 224.0.0.0
Если
мультикаст-фильтрация включена, попробуйте отключить:
sudo
sysctl -w net.ipv4.conf.all.mc_forwarding=1
sudo
sysctl -w net.ipv4.conf.ens192.rp_filter=0
✅ Итоговое исправление
1 Убедитесь,
что auth_pass совпадает на обоих серверах1
2 Убедитесь, что virtual_router_id одинаковый
3 Проверьте VRRP-трафик с tcpdump, чтобы убедиться, что пакеты приходят
от нужных серверов
4 Отключите фильтрацию мультикаста, если она мешает VRRP
После
исправлений перезапустите Keepalived:
sudo systemctl restart keepalived
После этого VRRP должен работать без ошибок! 🚀
Комментарии
Отправить комментарий