Keepalived: почему отказ одного узла роняет сервис
Типовая схема обычно выглядит отказоустойчивой: приложение развёрнуто в нескольких экземплярах, база реплицируется, под резерв выделены мощности. Но вход в сервис — балансировщик, обратный прокси или шлюз — закреплён за одним узлом, и он же оказывается единой точкой отказа. Вся избыточность за ним обнуляется первым же падением.
Ломается при этом не приложение, а адрес. Узел уходит по питанию, ядру или неудачному обновлению — и точка входа, по которой ходят клиенты, перестаёт отвечать. DNS-запись переключается не мгновенно: мешают время жизни записи и кеши резолверов, а ручной перевод трафика занимает минуты и делается ночью по инструкции. Простой при отказе узла измеряется десятками минут: у пользователей — ошибки и таймауты, у дежурной смены — разбор инцидента и правка конфигурации под давлением.
Цена такой схемы не только в часах недоступности. Каждое ручное переключение — это риск ошибиться: не тот узел, забытый маршрут, потерянные сессии. Пока ручной сценарий остаётся единственным, отказоустойчивость сервиса держится на скорости дежурного, а не на архитектуре.
Разбираем, как это закрывается. Keepalived держит плавающий адрес на паре узлов по протоколу VRRP, проверяет их состояние скриптами и переводит трафик без участия человека — с предсказуемым временем переключения и без ночных ручных правок.
Что даёт отказоустойчивость: измеримый эффект
Эффект отказоустойчивости измеряется тремя величинами: сколько сервис недоступен при отказе узла, какая доля инцидентов вообще доходит до пользователя и можно ли обслуживать серверы, не останавливая работу.
Автоматическое переключение вместо ручного вмешательства
Раньше упавший узел замечал дежурный — по уведомлению мониторинга, иногда по жалобе. Пока он подключался и переносил адрес руками, сервис лежал десятки минут, и каждая минута простоя приходилась на рабочее время. Переключение выполняет Keepalived: резервный узел забирает адрес за секунды, без человека в контуре. Время восстановления сервиса сжимается с десятков минут до 1-3 секунд, а дежурный узнаёт о событии из журнала, когда сервис уже принимает трафик.
Класс отказов «узел недоступен» уходит из статистики
Пока один узел перезагружается или ремонтируется, второй держит трафик — отказ оборудования перестаёт быть отказом сервиса. Важно, чем проверяется живость: отклик на сетевом уровне подтверждает, что машина включена, но не что приложение отвечает. Проверка запросом к приложению отсеивает узлы, формально живые, но отдающие ошибки. Полный отказ сервиса тогда требует одновременного падения всех узлов, то есть общей причины — сети, питания или неудачного релиза. Доступность сервиса растёт не «в среднем», а за счёт исчезновения целого класса инцидентов.
Плановые работы без простоя
Обслуживание идёт по одному узлу: его выводят из обработки трафика, обновляют, возвращают в строй, затем переходят к следующему. Доступность при этом не проваливается, согласовывать ночное окно и торопиться не нужно — работы переносятся в удобные часы. Такая схема окупается и на редких операциях: замена железа или смена конфигурации больше не превращается в плановый простой для пользователей.
Режимы работы Keepalived: сравнение вариантов
Схему резервирования выбирают до настройки: от неё зависят приоритеты узлов, количество виртуальных адресов и то, как кластер поведёт себя при возврате вышедшего из строя сервера в строй. VRRP допускает несколько рабочих раскладок, и разница между ними — в том, сколько узлов реально несут нагрузку и насколько предсказуемо переключение.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Активный и резервный узел | Один сервис, простой разбор инцидентов, простой резерва допустим | Резервный узел простаивает; после восстановления основного адрес вернётся к нему только при разрешённом возврате владения |
| Равноправные узлы с разными приоритетами | Пара серверов, где важно быстро вернуть адрес на штатный узел | Приоритет задаётся статически — при добавлении третьего узла схему пересчитывают вручную |
| Разделение виртуальных адресов по узлам | Несколько сервисов, нужно задействовать оба сервера | Каждый узел становится основным для своей группы адресов: конфигураций и проверок доступности вдвое больше |
В любом режиме работоспособность узла определяет не только обмен служебными пакетами, но и проверка доступности приложения. Скрипт-проверка снижает приоритет узла, если сервис не отвечает, — виртуальный адрес уходит на живой сервер. Без неё Keepalived продолжает держать адрес там, где процесс уже упал, и переключения не происходит.
Этапы внедрения отказоустойчивого кластера
Работы идут от инвентаризации к передаче: сначала фиксируем, что реально работает в контуре, затем проектируем схему с резервом для каждого критичного сервиса и только потом трогаем боевые узлы. Такой порядок исключает ситуацию, когда отказоустойчивость включают на сервисы, чьи сетевые зависимости к резервированию не готовы.
- Аудит инфраструктуры — собираем карту узлов, сетевых сегментов и сервисов, отмечаем единые точки отказа и связи, которые переживут перенос виртуального адреса, а какие нет.
- Схема резервирования — определяем пары узлов и роли, распределяем приоритеты в Keepalived, выбираем режим возврата роли и интервалы объявлений VRRP, чтобы переключение не срабатывало на коротких сетевых всплесках.
- Настройка и проверки доступности — пишем конфигурацию и скрипты, которые оценивают состояние самого сервиса, а не только живость хоста: иначе узел с упавшим приложением продолжит удерживать виртуальный адрес.
- Проверка переключения на стенде — воспроизводим отказы: остановка демона, разрыв линка, перезагрузка узла, зависание сервиса. Замеряем время, за которое резерв принимает адрес, и убеждаемся, что сессии и очереди не теряются.
- Вывод в боевой контур — включаем по одному сегменту с окном наблюдения, держим прежний вариант конфигурации для быстрого отката и отслеживаем состояние таблиц соседних устройств.
- Передача регламентов — отдаём схему адресации, конфигурации, сценарии ручного переключения и порядок действий дежурного при разделении узлов, чтобы команда эксплуатации управляла кластером без нас.
Конфигурации, схемы и регламенты переключения
Инженерная часть услуги заканчивается не запуском сервиса, а пакетом документов, по которому кластером можно управлять без нас. Мы передаём заказчику конфигурации Keepalived, схему сети и регламенты — так дежурная смена понимает, что происходит, а новый инженер входит в проект за часы, а не за недели.
- Конфигурация кластера: файлы обеих нод с ролями «основная/резервная», идентификатором виртуального маршрутизатора, приоритетами и интервалами объявления — с комментариями, почему выставлено именно так.
- Схема сети: адреса узлов и виртуального адреса, подсети, имена интерфейсов, точки отказа и таблица приоритетов — на одном листе, а не собранная по кускам.
- Проверки живости сервиса: скрипты, параметры запуска, пороги срабатывания и поведение при деградации узла и при его полном отказе.
- Регламент переключения: штатный сценарий, аварийный, ручное переключение и возврат роли обратно — с указанием, кто принимает решение.
- Инструкция для дежурного: пошаговые действия при потере виртуального адреса, снятие состояния, сбор логов и критерии, когда звать нас.
- Настройка мониторинга: метрики состояния узлов, оповещения на смену роли и внешняя проверка доступности сервиса — чтобы отказ видели до звонка пользователей.
- Протокол приёмочных испытаний: сценарии отказов, которые мы воспроизвели, и время восстановления по каждому — как доказательство, что переключение работает.
Отдельным пунктом идёт чек-лист изменений: как править конфигурацию, чтобы не вывести обе ноды из строя одним действием.
Кейс: переключение без потери трафика на боевом контуре
Боевой контур сервиса держался на двух узлах: точка входа жила на одном сервере, второй стоял горячим резервом. При отказе активного узла виртуальный адрес поднимали вручную — дежурный инженер получал алерт, подключался к серверу и перенастраивал адрес, пока клиенты видели ошибки.
Точка отсчёта: замеры до внедрения
Сначала мы зафиксировали исходное состояние — разобрали статистику инцидентов и воспроизвели отказ на стенде с боевыми настройками. Замеряли три величины: время переключения, долю потерянных соединений и число ручных вмешательств. Стенд дал те же цифры, что и боевой контур: 8–14 минут на переключение, до 6% оборванных соединений, 4–6 ночных вызовов инженера в месяц.
Что изменили и что получили
На оба узла поставили Keepalived в режиме VRRP: виртуальный адрес закреплён за активным узлом, резервный отслеживает сигналы и забирает адрес при их пропаже. Приоритеты выставили так, чтобы возврат после восстановления был управляемым — без «дёрганья» трафика туда-обратно. Отдельно добавили проверку здоровья приложения: если сервис жив, но не отвечает, адрес переезжает, не дожидаясь отказа железа.
На приёмочных испытаниях переключение уложилось в 1–2 секунды, доля потерянных соединений упала до долей процента, ручные вмешательства в смене исчезли. На боевом контуре сначала прогнали отказ каждого узла по отдельности, затем — отказ обоих с возвратом в строй.
Чем Keepalived отличается от кластерного менеджера
Keepalived — это демон протокола VRRP: он держит виртуальный адрес на активном узле и переносит его на резервный, когда основной перестал отвечать. Проверки доступности настраиваются под конкретный сервис — проверка TCP-порта, HTTP-ответ или наличие процесса. Пока проверка проходит, адрес остаётся на текущем узле; перестала проходить — адрес уходит резервному узлу, и клиенты продолжают работать по тому же адресу без правки конфигов.
Кластерный менеджер работает на другом уровне. Он управляет ресурсами: запускает и останавливает службы в заданном порядке, подключает общие диски, следит за кворумом и изолирует узел, потерявший связь с остальными. Резервирование адреса для него — лишь один из ресурсов, а не основная задача.
Отсюда и критерий выбора. Если приложение уже умеет реплицироваться и стартует самостоятельно, а критично только одно — чтобы трафик шёл на живой узел, достаточно резервирования адреса и проверок доступности. Если нужен управляемый жизненный цикл — поднять базу, дождаться синхронизации, подключить общий диск и только потом открыть адрес, — без кластерного менеджера не обойтись.
На практике их не противопоставляют. Демон VRRP отвечает за адрес и распределение трафика, кластерный менеджер — за ресурсы; связка даёт быстрый переход трафика и корректный порядок запуска служб после переключения.
Поэтому на этапе подбора инструмента мы смотрим на само приложение: сколько у него состояний, нужен ли кворум, есть ли общий диск и обязателен ли строгий порядок старта. От ответов зависит, обойдёмся ли одним демоном VRRP или собираем полный кластер с управлением ресурсами.
Проверки доступности, задержки и разделение сети
Проверка доступности сервиса в Keepalived — это не пинг адреса, а проверка самой службы: локальный скрипт обращается к своему порту или отдаёт пробный запрос и по ответу решает, жив ли узел. Пока проверка проходит, узел держит адрес; при провале — снимает и отдаёт партнёру. Порог срабатывания и интервал подбирают так, чтобы одиночная заминка приложения не вызывала переключение, иначе адрес будет «прыгать» на ровном месте.
Два активных узла появляются там, где служебные сообщения теряются в одну сторону: каждый считает партнёра мёртвым и забирает адрес себе. Защита — приоритеты, обязательное подтверждение связи перед захватом адреса и разделение сети: служебный обмен идёт по отдельному сегменту или адресной доставкой, а не широковещательно через прод-трафик.
Что происходит с уже открытыми соединениями при переключении?
Состояние соединений живёт на узле и не переезжает вместе с адресом. Клиент получает короткий сбой и повторяет запрос, поэтому переключение проектируют там, где повторы безопасны: идемпотентные операции, балансировщик с общей таблицей состояний. Для длинных сессий заранее описывают повторный вход пользователя.
Как гарантированно не получить два активных узла?
Одних приоритетов мало: узел с большим весом должен ещё убедиться, что партнёра действительно нет. Поэтому добавляют задержку включения после старта, проверку связанности и отдельный канал для служебных сообщений. В разделённых сегментах это единственный способ отличить потерю связи от отказа узла.
Как быстро узел возвращается в строй?
Узел поднимается сам, но адрес забирает не сразу — сначала проверки должны стабилизироваться, затем выдерживается пауза, чтобы сервис не дёргался. Возврат по приоритету можно отложить до окна работ или отключить: тогда роль остаётся у текущего активного узла, а восстановленный работает как резерв.
Обсудим задачу: внедрение Keepalived под ваш контур
Первый разговор — это разбор вашего контура, а не презентация. Выясняем, сколько узлов участвует в отказоустойчивой паре, какие сервисы держат виртуальный адрес, как распределяется трафик и есть ли вышестоящий балансировщик. Отдельно проговариваем окна на изменения: можно ли перезапускать узлы днём, есть ли доступ к управлению сетью и журналам.
Чтобы оценка была предметной, от вас нужны вводные: схема сети, список сервисов за виртуальным адресом, требования по времени переключения и режим обслуживания. Если документации нет — соберём картину на созвоне с вашими инженерами.
После разбора присылаем:
- схему контура с отмеченными точками отказа и местом, где встаёт Keepalived;
- план внедрения по этапам, с окнами работ и порядком отката;
- состав работ: настройка VRRP, проверки доступности сервисов, скрипты переключения;
- перечень изменений в конфигурациях и того, что потребуется от вашей стороны;
- сценарии проверки: как убедимся, что узел действительно перехватывает адрес;
- роли и точки согласования на время работ;
- оценку по этапам — трудоёмкость и зависимости, без привязки к календарным датам.
Опишите задачу в двух абзацах — вернёмся с оценкой и планом внедрения под ваш контур.
