Linux Labs
С чего начать Первые шаги трек · 15 ступеней
Linux Labs
RU

keepalived — отказоустойчивость через VRRP

3 мин Ubuntu 24.04 · keepalived

Высокая доступность через виртуальный IP — failover между узлами по VRRP.

Шпаргалка

2 команды Версия для печати
  • ip a | grep VIP кто сейчас MASTER
  • journalctl -u keepalived -f переходы состояний
  • conf: state MASTER/BACKUP · virtual_router_id (одинаков) · priority · virtual_ipaddress
  • проверка сервиса: vrrp_script + track_script (weight -N)
  • split-brain → firewall на VRRP (proto 112, 224.0.0.18) или unicast_peer

Обзор

keepalived обеспечивает отказоустойчивость: два+ узла делят виртуальный IP (VIP) по протоколу VRRP. В норме VIP «висит» на MASTER; если он падает — VIP автоматически переезжает на BACKUP. Часто в паре с haproxy/nginx.

bash 
systemctl status keepalived
ip a | grep <VIP>                 # на каком узле сейчас VIP (см. ip)
journalctl -u keepalived -f       # переходы MASTER/BACKUP в реальном времени

Конфигурация

4

/etc/keepalived/keepalived.conf (на MASTER):

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51        # ОДИНАКОВЫЙ на всех узлах группы, уникальный в L2
    priority 100                # выше = предпочтительный MASTER
    advert_int 1
    authentication { auth_type PASS; auth_pass secret }
    virtual_ipaddress { 10.0.0.10/24 }
}

На BACKUP — то же, но state BACKUP и priority 90.

Директива Смысл
priority вес в выборах MASTER (выше побеждает)
nopreempt не отбирать VIP обратно при возврате (избежать лишних переездов)
unicast_peer VRRP по unicast (облака/сети без мультикаста)
vrrp_script + track_script проверка сервиса → снижение priority при падении

Ничего не найдено. Попробуй запрос короче.

Рецепты

1

Проверка сервиса

Чтобы VIP уезжал при падении приложения (а не только всего узла):

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"   # 0 = жив
    interval 2
    weight -20                              # упал → priority -20 → BACKUP выигрывает
}
vrrp_instance VI_1 {
    ...
    track_script { chk_haproxy }
}

Неполадки

5

VIP на обоих узлах одновременно (split-brain)

Узлы не видят VRRP-объявления друг друга. Причина — firewall блокирует VRRP (протокол 112, мультикаст 224.0.0.18) или разные virtual_router_id. Разреши VRRP между узлами; в облаке без мультикаста — unicast_peer.

VIP не переезжает при падении приложения

Нет track_script — VIP держится, пока жив узел, даже если сервис умер. Добавь vrrp_script/track_script с weight.

VIP «скачет» туда-сюда (flapping)

Слишком чувствительный vrrp_script или восстановившийся MASTER отбирает VIP. Ставь nopreempt на BACKUP-узлах или увеличь interval/fall/rise.

Конфликт virtual_router_id

В одном L2-сегменте virtual_router_id уникален на группу; совпадение с чужой группой ломает выборы.

Где сейчас VIP / что происходит

ip a на каждом узле (VIP виден только на MASTER), journalctl -u keepalived — переходы состояний (см. ip).

См. также

  • haproxy — Балансировка нагрузки и проксирование TCP/HTTP — бэкенды, health-check, статистика.
  • ip — Управление интерфейсами, адресами и маршрутами (iproute2) — замена ifconfig/route.
  • firewall — Фильтрация трафика — простой ufw и низкоуровневый nftables.

Есть неточность? Сообщить об ошибке в статье

Темы
Загрузка…