Настройка автоматического Failover для критических сервисов: пошаговое руководство

Автоматический failover решает задачу непрерывной работы сервисов при отказе оборудования, сетевой изоляции или деградации приложения. В этой статье разобран проверенный на практике сценарий построения Active/Passive кластера из двух узлов на базе Keepalived, Pacemaker и Corosync. Вы получите готовые конфигурации, команды настройки и процедуры тестирования, которые можно адаптировать под RHEL 8/9, CentOS Stream, AlmaLinux или Rocky Linux.

Ключевая идея проста: виртуальный IP-адрес всегда следует за работоспособным узлом, а Pacemaker следит за тем, чтобы сервис был запущен именно там, где этот адрес активен. Если основной узел выходит из строя, резервный принимает нагрузку автоматически. Время переключения зависит от таймаутов и обычно укладывается в несколько секунд.

Материал ориентирован на системных администраторов и DevOps-инженеров, которые уже работали с Linux, но хотят внедрить отказоустойчивость без погружения в объёмную официальную документацию. Все команды проверены в тестовой среде, возможные ошибки и способы их устранения описаны по ходу изложения.

Введение в отказоустойчивость и компоненты кластера

Высокая доступность строится на избыточности: два или более узлов, общий механизм принятия решений и ресурсы, которые могут перемещаться между узлами. Для критических сервисов чаще всего выбирают схему Active/Passive, потому что она предсказуема и исключает конфликты за общие данные.

Что такое Active/Passive кластер и когда он нужен

Active/Passive кластер подразумевает, что в каждый момент времени сервис работает только на одном узле. Второй узел находится в режиме ожидания и готов принять нагрузку. Такая схема подходит для сервисов, которые не поддерживают одновременную работу нескольких экземпляров с общим состоянием: классические СУБД без шардирования, почтовые серверы, NFS, некоторые веб-приложения с локальными файлами.

Преимущества Active/Passive: простота отладки, отсутствие гонок за ресурсы, целостность данных при корректной настройке fencing. Недостаток: резервный узел простаивает, поэтому вычислительные ресурсы используются не полностью. Если приложение умеет работать в режиме Active/Active, стоит рассмотреть балансировку нагрузки, но это отдельная архитектурная задача.

Типовые кандидаты на Active/Passive: веб-сервер с локальными сессиями, база данных PostgreSQL или MariaDB без репликации на запись, почтовый сервер, файловый сервер NFS. Если ваш сервис хранит состояние на общем диске, потребуется дополнительная настройка репликации или общего хранилища.

Обзор компонентов: Keepalived, Pacemaker, Corosync

Три компонента решают разные задачи, и их нельзя путать.

Keepalived реализует протокол VRRP и управляет виртуальным IP-адресом. Он быстро переключает адрес между узлами при отказе активного.
Corosync обеспечивает транспортный уровень кластера: членство узлов, кворум, надёжную доставку сообщений между узлами.
Pacemaker работает поверх Corosync и управляет ресурсами: запускает и останавливает сервисы, монтирует файловые системы, перемещает ресурсы при сбоях.

Взаимодействие выглядит так: Corosync держит связь между узлами и определяет, кто в кластере. Pacemaker получает эту информацию и решает, где должен работать каждый ресурс. Keepalived может быть настроен отдельно для VIP или как ресурс Pacemaker. В этом руководстве Keepalived используется отдельно для управления виртуальным IP, а Pacemaker управляет сервисами. Такой подход проще для отладки и позволяет быстро проверить переключение IP независимо от остальных ресурсов.

Если вы ещё выбираете между подходами, полезно изучить сравнительный обзор решений для Linux и Kubernetes, где разобраны сильные стороны каждого стека.

Подготовка среды и установка необходимых пакетов

Перед установкой кластерного ПО приведите оба узла к единому состоянию. Различия в версиях пакетов или рассинхронизация времени приводят к трудно диагностируемым сбоям.

Настройка сети и синхронизации времени

На каждом узле настройте статический IP-адрес и пропишите оба хоста в /etc/hosts. Пример для двух узлов:

192.168.1.10 node1.example.com node1
192.168.1.11 node2.example.com node2

Проверьте доступность по имени: ping node2 с первого узла и ping node1 со второго. Настройте синхронизацию времени через chrony:

dnf install -y chrony
systemctl enable --now chronyd
chronyc sources

Расхождение времени более чем на несколько секунд может вызвать ложные срабатывания мониторинга и проблемы с логами. Убедитесь, что оба узла получают время от одного источника.

Установка и базовая настройка кластерного ПО

Установите пакеты на обоих узлах:

dnf install -y pacemaker corosync pcs keepalived

Включите службу pcsd и задайте пароль пользователю hacluster. Пароль должен быть одинаковым на обоих узлах.

systemctl enable --now pcsd
echo 'StrongPassword' | passwd --stdin hacluster

Выполните аутентификацию узлов. Команда выполняется с одного узла:

pcs cluster auth node1 node2 -u hacluster -p StrongPassword

Создайте кластер и запустите его:

pcs cluster setup --name ha-cluster node1 node2
pcs cluster start --all
pcs cluster enable --all

Проверьте статус:

pcs status

Вывод должен показывать оба узла в состоянии Online. Если узел не присоединяется, проверьте порты 5405 UDP для Corosync и 2224 TCP для pcsd. SELinux можно временно перевести в permissive для отладки, но в production лучше настроить политики.

Для ускорения развёртывания можно использовать готовые Ansible playbook для Pacemaker, которые автоматизируют установку и базовую конфигурацию.

Настройка виртуального IP-адреса с помощью Keepalived

Виртуальный IP - это адрес, по которому клиенты обращаются к сервису. Он не привязан к конкретному физическому интерфейсу и переходит на резервный узел при отказе активного.

Конфигурация VRRP на активном и резервном узлах

Создайте файл /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 {
        192.168.1.100/24
    }
}

На втором узле конфигурация отличается только state и priority:

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 {
        192.168.1.100/24
    }
}

Параметр virtual_router_id должен совпадать на обоих узлах. priority определяет, кто станет MASTER при старте. advert_int задаёт интервал отправки VRRP-объявлений в секундах. Запустите службу на обоих узлах:

systemctl enable --now keepalived

Проверка переключения виртуального IP

На активном узле выполните:

ip addr show eth0

Вы должны увидеть адрес 192.168.1.100. Остановите Keepalived на активном узле:

systemctl stop keepalived

В течение нескольких секунд адрес появится на резервном узле. Проверьте логи:

journalctl -u keepalived -f

В логах резервного узла появится запись о переходе в состояние MASTER. Запустите Keepalived обратно. Если параметр nopreempt не задан, адрес вернётся на исходный узел автоматически. Для production часто настраивают nopreempt, чтобы избежать лишних переключений после восстановления.

Кластеризация ресурсов с помощью Pacemaker и Corosync

Keepalived управляет IP, но не знает о состоянии сервиса. Pacemaker берёт на себя запуск, остановку и мониторинг приложений. Он же перемещает сервис на другой узел, если текущий стал непригоден.

Создание ресурсов и групп ресурсов

Создайте ресурс для виртуального IP в Pacemaker. Это позволит управлять адресом из единого интерфейса:

pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

Добавьте ресурс для веб-сервера Apache:

pcs resource create httpd systemd:httpd op monitor interval=30s

Сгруппируйте ресурсы, чтобы они всегда работали на одном узле и запускались в правильном порядке:

pcs resource group add webgroup vip httpd

Группа гарантирует совместное размещение: если vip перемещается, httpd перемещается вместе с ним.

Настройка ограничений размещения и порядка

Ограничения colocation и order задают жёсткие правила. Colocation привязывает ресурсы к одному узлу, order определяет последовательность запуска:

pcs constraint colocation add httpd with vip INFINITY
pcs constraint order vip then httpd

INFINITY означает обязательное совместное размещение. Порядок запуска важен: сначала назначается IP, затем стартует сервис. Проверьте статус:

pcs status

Вывод покажет, на каком узле работает группа webgroup и в каком состоянии находятся ресурсы.

Типовые сценарии срабатывания переключения

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

Отказ ноды

При полном отказе узла, например из-за kernel panic или отключения питания, Corosync перестаёт получать heartbeat-сообщения. Через заданный таймаут выживший узел объявляет отказавший узел мёртвым. Pacemaker запускает fencing, если настроен STONITH, и перемещает ресурсы на выживший узел.

Время переключения складывается из таймаута обнаружения отказа и времени запуска сервиса на резервном узле. Для типовой конфигурации это 5-15 секунд. Пользователи в этот момент получают ошибки подключения, но после переключения работа восстанавливается автоматически.

Потеря сети

Ситуация сложнее: узел жив, но изолирован от остального кластера. Оба узла могут считать себя активными, что приводит к split-brain. Если оба узла начнут писать в общее хранилище, данные будут повреждены.

Решение - fencing. Узел, который потерял связь с кластером, должен быть принудительно остановлен или перезагружен. Только после этого ресурсы могут быть безопасно перемещены. Без настроенного STONITH кластер в такой ситуации может зависнуть в неопределённом состоянии.

Деградация сервиса

Сервис запущен, но не отвечает на запросы. Pacemaker обнаруживает это через мониторинг ресурсов. Например, OCF-агент для Apache может проверять HTTP-ответ на заданный URL. Если проверка не проходит, ресурс перезапускается на том же узле. При повторных сбоях в течение заданного интервала ресурс перемещается на другой узел.

Настройка мониторинга критична для быстрого обнаружения деградации. Без неё кластер узнает о проблеме только когда сервис полностью упадёт.

Предотвращение split-brain и настройка fencing (STONITH)

Fencing - это механизм принудительной изоляции узла. Без него кластер не может гарантировать целостность данных. В production настройка STONITH обязательна.

Настройка устройства fencing для каждого узла

Для физических серверов с IPMI выполните:

pcs stonith create ipmi-node1 fence_ipmilan pcmk_host_list=node1 ipaddr=192.168.1.20 login=admin passwd=secret lanplus=1 op monitor interval=60s
pcs stonith create ipmi-node2 fence_ipmilan pcmk_host_list=node2 ipaddr=192.168.1.21 login=admin passwd=secret lanplus=1 op monitor interval=60s

Для виртуальных машин на KVM используйте fence_virsh, для VMware - fence_vmware_soap. Проверьте, что fencing включён:

pcs property set stonith-enabled=true
pcs stonith show

Тестировать fencing нужно осторожно: команда pcs stonith fence node1 принудительно перезагрузит узел. Выполняйте проверку только в тестовой среде.

Тестирование сценария split-brain

Симулируйте потерю связи, заблокировав порты Corosync на одном узле:

iptables -A INPUT -p udp --dport 5405 -j DROP
iptables -A OUTPUT -p udp --dport 5405 -j DROP

Наблюдайте за поведением: один узел должен быть изолирован через fencing, ресурсы останутся на другом. После теста удалите правила iptables и восстановите узел. Подробный разбор сценариев split-brain и готовые конфигурации для разных платформ есть в руководстве по предотвращению split-brain.

Мониторинг и проверка работоспособности кластера

Постоянный мониторинг позволяет обнаружить проблему до того, как она приведёт к простою. Базовые команды дают мгновенный снимок состояния, а оповещения информируют о событиях автоматически.

Основные команды для проверки состояния

Ежедневный набор команд администратора:

pcs status

Показывает общий статус кластера, узлов и ресурсов. Однократный вывод без интерактивного режима:

crm_mon -1

Детали по ресурсам:

pcs resource show

Статус fencing-устройств:

pcs stonith show

Логи кластера находятся в /var/log/messages и /var/log/cluster/corosync.log. При разборе инцидента начинайте с этих файлов.

Настройка оповещений и интеграция с системами мониторинга

Pacemaker поддерживает alert-агенты, которые выполняют скрипты при событиях. Настройка email-оповещения:

pcs alert create email_alert \
  path=/usr/share/pacemaker/alerts/alert_smtp.sh \
  meta options=... \
  recipient=admin@example.com

Для интеграции с Prometheus используйте node_exporter с текстовым коллектором, который собирает метрики кластера. Zabbix может опрашивать статус через пользовательские скрипты. Главное - чтобы оповещение приходило в течение минуты после события, а не post factum из логов.

Восстановление после сбоя и минимизация времени простоя

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

Процедура возвращения узла в кластер

После ремонта или перезагрузки узла выполните:

pcs cluster start nodeX
pcs status

Убедитесь, что узел в состоянии Online. Если ресурсы были в состоянии failed, очистите счётчики ошибок:

pcs resource cleanup

Проверьте, что ресурсы распределены корректно. Если настроен автоматический возврат, ресурсы вернутся на восстановленный узел. Если нет - переместите их вручную:

pcs resource move webgroup nodeX

После ручного перемещения не забудьте снять ограничение:

pcs resource clear webgroup

Оптимизация таймаутов и параметров для быстрого переключения

Скорость переключения зависит от нескольких параметров. monitor interval определяет частоту проверок ресурса. Для критичных сервисов ставьте 10-30 секунд. failure-timeout задаёт время, через которое счётчик ошибок сбрасывается. migration-threshold - количество ошибок до перемещения ресурса на другой узел.

Слишком агрессивные настройки опасны: частые проверки нагружают систему, а низкий порог ошибок вызывает ложные переключения. Начните с monitor interval 30s, migration-threshold 3, failure-timeout 300s и корректируйте по результатам тестов.

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

Заключение и дополнительные ресурсы

Настройка автоматического failover сводится к четырём шагам: установка и базовая конфигурация кластерного ПО, настройка виртуального IP через Keepalived, создание ресурсов и ограничений в Pacemaker, настройка fencing и мониторинга. Каждый шаг проверяется отдельно, прежде чем переходить к следующему.

Тестируйте все сценарии отказа: выключение узла, обрыв сети, остановку сервиса. Только так вы убедитесь, что кластер поведёт себя предсказуемо в реальной аварии. Официальная документация ClusterLabs и man-страницы Keepalived содержат дополнительные детали по параметрам, которые здесь рассмотрены кратко.

Если вы проектируете отказоустойчивую систему управления или хранилище, обратите внимание на архитектурные схемы резервирования и failover. Для более глубокого погружения в Corosync и Pacemaker изучите практическое руководство по построению кластера на Linux.