Отказоустойчивый кластер Angie с VRRP и Keepalived / forpes.ru

Главная
Отказоустойчивый кластер Angie с VRRP и Keepalived

Отказоустойчивый кластер Angie с VRRP и Keepalived +9

16.12.2025 08:53

Nickmob 0 2900 Источник

Ранее мы рассматривали различные варианты балансировки нагрузки (HTTP, L4) с помощью Angie. Однако мы обходили стороной вопрос отказоустойчивости. Балансировщик становится единой точкой отказа для системы, и эту проблему необходимо решать. Одним из решений является использование протокола VRRP для организации отказоустойчивого кластера — его мы и разберём в этой статье.

Навигация по циклу

Видеоверсия

Для вашего удобства подготовлена видеоверсия этой статьи, доступна на Rutube, VKVideo и YouTube.

Протокол VRRP

Начнём с принципов работы протокола VRRP (Virtual Router Redundancy Protocol). Как можно догадаться из названия, он предназначен для повышения доступности маршрутизаторов, то есть пришёл к нам из сетевой сферы. Основа работы протокола — выделение виртуального IP (Virtual IP — VIP), который будет мигрировать от одного устройства к другому при сбоях и переключениях.

Для работы протокола необходимо определить группу устройств (виртуальный роутер), которой и будет соответствовать виртуальный адрес (VIP). После запуска системы одно из устройств становится ведущим и владельцем VIP (роль master), остальные будут резервными (backup). Текущий master отправляет по сети пакеты VRRP‑объявлений (advertisement). Если другие узлы перестают получать эти объявления, запускается процесс переключения VIP на резервное устройство.

Разберём ещё несколько важных терминов VRRP, которые будут использоваться при настройке стенда. VRID — virtual router ID — это идентификатор виртуального роутера, все серверы в одной группе должны иметь одно значение VRID. Приоритет — значение от 0 до 255, на основании которого происходит выбор ведущего роутера (master). Выигрывает сервер с максимальным приоритетом. Также есть несколько временных параметров:

advertisement interval — временной интервал между отправкой объявлений;
master down interval — временной интервал, после которого backup router станет master router;
skew time — время (в секундах), которое используется для отклонения master down interval (чтобы избежать гонки при перевыборах).

Режим preempt контролирует, будет ли backup‑маршрутизатор с более высоким приоритетом пытаться перехватить на себя роль master у текущего master‑маршрутизатора с более низким приоритетом, когда восстановит свою функциональность.

Есть две основные версии протокола VRRP — 2 и 3. Основные различия — в третьей версии есть поддержка IPv6, более высокое разрешение таймеров (миллисекунды против секунд в v2) и в третьей версии отменили аутентификацию. В нашем решении мы будем использовать сервер Keepalived как популярную реализацию протокола VRRP в Linux.

Keepalived — реализация VRRP

Сервис Keepalived обладает разнообразной функциональностью по балансировке и отказоустойчивости серверов. Для своей работы он использует протоколы VRRP, BFD и компоненты IPVS (Linux Virtual Server). В этой статье мы будем использовать функциональность по переключению серверов для обеспечения отказоустойчивости на базе протокола VRRP.

В терминах Keepalived мы создадим виртуальный роутер с двумя серверами, использующими один виртуальный IP. На каждом из серверов будет работать сервер Angie, доступность которого мы будем проверять в Keepalived.

Принципиальная схема показана на картинке ниже.

Здесь показано, что пользователи подключаются к VIP, который принадлежит одному из серверов. Его роль называется Master. Второй сервер находится в состоянии запасного (Backup) сервера и в случае сбоя на первом сервере назначит себе VIP, чтобы обслуживать запросы пользователей. Серверы постоянно общаются между собой по протоколу VRRP, поэтому одним из вариантов сбоя будет отсутствие сообщений от Master‑сервера. Второй вариант сбоя — недоступность по результатам проверки сервера Angie на Master‑сервере; в таком случае Master понижает свой приоритет и отдаёт ведущую роль (и VIP) на другой сервер.

Настройка тестового стенда

Запускать тестовый стенд мы будем на базе двух виртуальных машин с Ubuntu 24.04, Keepalived 2.2.8 и Angie 1.10.2. По умолчанию все действия выполняем симметрично на двух машинах, а отличия в конфигурации будут подсвечены отдельно.

Настраиваем репозиторий Angie и устанавливаем все необходимые пакеты (все следующие команды выполняем от имени суперпользователя):

apt install -y angie angie-console-light keepalived

Внесём изменения в конфигурацию сервера по умолчанию в Angie (/etc/angie/http.d/default.conf). Добавим локацию для базовой проверки доступности сервера и заголовок в корневую локацию:

    location / {
	   add_header X-Front "Angie-1";
        root   /usr/share/angie/html;
        index  index.html index.htm;
    }

   
    location /health_check/ {
	   return 200 "OK";
        allow   127.0.0.1;
        deny    all;
    }

По адресу http://127.1/health_check/ будет происходить проверка работоспособности сервера Angie. Ответ реализован простейшей директивой return и не будет требовать значительных ресурсов для обработки.

Проверяем и обновляем конфигурацию Angie:

angie -t && systemctl reload angie

Теперь переходим к конфигурации Keepalived. Его конфиг по умолчанию находится в шаблоне (/etc/keepalived/keepalived.conf.sample). Там можно подсмотреть некоторые конфигурационные директивы, но для наших задач проще создать конфиг с нуля. В конфигурации Keepalived появится единственное различие между серверами (state MASTER или BACKUP). Итак, создаём файл /etc/keepalived/keepalived.conf со следующим содержимым:

global_defs {
  enable_script_security
}

vrrp_script chk_angie { 
  script "/etc/keepalived/check_angie.sh"
  user angie
  interval 1
  rise 2
  fall 2
  timeout 1
  weight 2
}

vrrp_instance VI_1 { 
  interface enp1s0
  state MASTER
  virtual_router_id 1 
  priority 101 

  virtual_ipaddress {
    192.168.122.81 
  }

  track_script { 
    chk_angie
  } 

  authentication {
    auth_type PASS
    auth_pass spass
  } 
}

Разберём основные элементы этого конфига Keepalived.

Первая секция (global_defs) содержит общие настройки для всего сервера. В данном случае мы запрещаем выполнять проверочные скрипты от лица пользователя root, если файл доступен для записи обычным пользователям.

Секция vrrp_script определяет способ проверки сервера Angie на доступность. Скрипт находится во внешнем файле, запускается от лица пользователя Angie с интервалом в одну секунду. Для работы скрипта задан таймаут (1 секунда) и количество попыток (2) для признания сервера рабочим (rise) или упавшим (fall). Параметр веса (weight 2) определяет, насколько будет увеличен приоритет при успешном выполнении скрипта.

Следующая секция (vrrp_instance) описывает самое главное — экземпляр нашего сервера в виртуальном роутере. Указан интерфейс, на который будет привязан VIP (enp1s0), статус по умолчанию (MASTER), ID виртуального роутера (virtual_router_id) и начальный приоритет (priority). Также в секции есть блоки конфигурации виртуального адреса (virtual_ipaddress), скрипта проверки (track_script) и аутентификации (authentication). Секция скрипта проверки ссылается на ранее определённый блок vrrp_script по имени. Напомню, что аутентификация необязательна и поддерживается только для второй версии протокола. При использовании IPv6-адресов Keepalived будет использовать VRRPv3.

Конфигурация второй машины полностью аналогична, за исключением нескольких директив в секции vrrp_instance. Здесь можно задать другой приоритет и начальную роль для сервера:

vrrp_instance VI_1 { 
  ...
  state BACKUP
  priority 100
  ...

Также для отслеживания активного сервера в конфигурации Angie можно изменить директиву add_header на другое значение (Angie-2).

После настройки всех компонентов на обеих машинах проверяем работоспособность конфигурации Keepalived.

systemctl reload keepalived
systemctl status keepalived

В выводе статуса Keepalived можно увидеть последние сообщения лога. Если этого недостаточно, то можно посмотреть лог отдельно:

journalctl -u keepalived -n 20 --no-pager

Там мы можем увидеть статус выполнения проверочного скрипта и переход сервера в роль MASTER или BACKUP.

Oct 30 13:01:15 angie-vrrp1 Keepalived_vrrp[32351]: (VI_1) Entering BACKUP STATE (init)
Oct 30 13:01:15 angie-vrrp1 Keepalived_vrrp[32351]: VRRP_Script(chk_angie) succeeded

Если все сервисы работают на обеих машинах, можно приступать к тестированию переключения в нашем кластере.

Тестируем переключение

Чтобы убедиться в корректной работе схемы переключения, нужно проверить несколько сценариев.

В первом сценарии MASTER‑машина пропадает из сети (можно выключить машину или остановить сетевой интерфейс). VIP должен перейти на вторую машину. Для оценки времени переключения (недоступности VIP) можно использовать высокочастотный ping (с флагом ‑f). Тестировать будем с хостовой системы машины (кластер работает в виртуальных машинах). Запускаем ping и выключаем MASTER‑машину.

host> sudo ping -f 192.168.122.81

PING 192.168.122.81 (192.168.122.81) 56(84) bytes of data.
........................................................
--- 192.168.122.81 ping statistics ---
838608 packets transmitted, 838552 received, 0.00667773% packet loss, time 26040ms
rtt min/avg/max/mdev = 0.014/0.019/2.007/0.005 ms, ipg/ewma 0.031/0.023 ms

Как видно, при выключении MASTER‑системы мы потеряли около 50 пакетов; это задержка при переключении. При этом частота отправки составила около 32 kPps.

Запускаем первую машину обратно, она снова получает MASTER‑роль.

Во втором сценарии мы остановим сервис Angie, таким образом сымитируем сбой веб‑сервера. Для тестирования доступности запустим поток HTTP‑запросов с хостовой системы на VIP с помощью ab, а в это время остановим Angie на MASTER‑машине:

host> ab -n 10000000 -l -c 10 -r http://192.168.122.81/
...
Complete requests:      316002
Failed requests:        62179
   (Connect: 0, Receive: 31091, Length: 0, Exceptions: 31088)
Total transferred:      227074067 bytes
HTML transferred:       155561406 bytes
Requests per second:    22440.70 [#/sec] (mean)
...

Из результатов теста видно, что около 62 тыс. запросов завершились с ошибкой. При этом средняя частота составила 22 KRps, то есть сервис был недоступен около трёх секунд. Если посмотреть на настройки проверочного скрипта для Angie, то он признаётся недоступным после двух проваленных проверок с периодом проверки раз в секунду.

В логах Keepalived MASTER-машины можно увидеть хронологию событий — около четырёх секунд от проверки до переключения:

Oct 30 16:03:01 angie-vrrp1 Keepalived_vrrp[859]: Script `chk_angie` now returning 7
Oct 30 16:03:02 angie-vrrp1 Keepalived_vrrp[859]: VRRP_Script(chk_angie) failed (exited with status 7)
Oct 30 16:03:02 angie-vrrp1 Keepalived_vrrp[859]: (VI_1) Changing effective priority from 103 to 101
Oct 30 16:03:05 angie-vrrp1 Keepalived_vrrp[859]: (VI_1) Master received advert from 192.168.122.26 with higher priority 102, ours 101
Oct 30 16:03:05 angie-vrrp1 Keepalived_vrrp[859]: (VI_1) Entering BACKUP STATE

Ещё один сценарий — падение самого сервиса Keepalived не будет приводить к заметному простою, так как обе системы доступны и могут обслуживать запросы. Переход VIP на BACKUP‑сервер будет происходить с минимальными потерями.

Таким образом, мы оценили возможный простой сервиса для нескольких сценариев. Конечно, нужно учитывать, что в реальных условиях переход трафика с одного балансировщика на другой приведёт к разрыву TCP‑соединений, сбросу состояния проксируемых серверов, привязки сессий, кэша и других элементов состояния сервера, которые локальны для каждого балансировщика. Однако при корректной архитектуре приложения и тестировании различных сценариев сбоя такое решение вполне жизнеспособно.

Синхронизация конфигурации узлов кластера

Для Angie разработан специальный пакет для автоматизации задачи синхронизации конфигурационных файлов. Для этого можно использовать пакет angie‑ha‑sync. Он позволяет поддерживать актуальную версию конфигов на всех узлах. Также на официальной странице документации решения описана настройка узлов для работы с VRRP.

Итоги

Мы кратко разобрали основы работы протокола VRRP и его применение для реализации отказоустойчивого кластера на базе Keepalived и Angie. В нашей конфигурации применялась архитектура с одним активным и одним запасным сервером. После успешной конфигурации было показано тестирование нескольких вариантов сбоев и их последствия для доступности сервиса.