Zabbix 6.2 HA: переводим монолитный сервер на нативный кластер без Keepalived

Zabbix 6.2 вышел в июле, и одна из его фич - нативная HA-кластеризация сервера - прошла в анонсах как-то незаметно за рассказами про новый виджет и улучшения в Low Level Discovery. А зря, потому что это, пожалуй, самое значимое архитектурное изменение в Zabbix за несколько лет.

У нас есть клиент с production-установкой Zabbix 6.0 LTS на одном сервере. Типичная ситуация: мониторинг больше тысячи хостов, CI/CD, несколько баз, внешние скрипты. Всё это - на монолитном Zabbix-сервере, без какой-либо отказоустойчивости. Упадёт нода - мониторинг молчит, алерты не идут, никто не знает что происходит в инфраструктуре. Мы несколько раз поднимали вопрос про failover, и каждый раз упирались в сложность: реализовать HA для Zabbix сервера - это Keepalived, shared storage или репликация, ручной скрипт переключения, тестирование всего этого хозяйства. Овчинка выделки стоила, но инициатива откладывалась.

Выход Zabbix 6.2 с нативным HA изменил уравнение.

Как работает нативный HA в Zabbix 6.2

Схема прямолинейная: несколько Zabbix-серверов объявляют себя частью одного кластера через параметр HANodeName в zabbix_server.conf. Один из них становится активным (active), остальные - резервными (standby). Координация через базу данных - те же таблицы, что использует сам Zabbix, никаких дополнительных сервисов.

При падении активной ноды резервная обнаруживает это по таймауту (задаётся параметром HAFailoverDelay, по умолчанию - одна минута) и берёт управление на себя. Агенты и прокси подключаются к кластеру через виртуальный адрес - его по-прежнему надо организовывать внешними средствами, но это уже только для VIP, а не для всей логики переключения.

Фронтенд - отдельная история. Zabbix Web GUI умеет отображать статус нод и подключаться к активной, но сам frontend failover не делает. Это честно: frontend - stateless, его всегда можно за балансировщик посадить или просто запустить на обеих нодах.

Что делали на практике

Клиент согласился на апгрейд с 6.0 до 6.2 - LTS у него заканчивается не скоро, но фича стоила того чтобы перейти на non-LTS ветку под контракт сопровождения.

Развернули вторую ноду на таком же железе. База данных у клиента уже была на отдельном сервере с репликацией - это обязательное условие, нативный HA Zabbix не берёт на себя отказоустойчивость БД. Если база упала - оба Zabbix-сервера падают вместе с ней, так что PostgreSQL с Patroni или хотя бы streaming replication плюс ручной failover на уровне БД - это ваша ответственность.

Конфиг на обеих нодах отличается минимально:

• HANodeName=zabbix-node-1 на первой, HANodeName=zabbix-node-2 на второй.
• NodeAddress - адрес конкретной ноды, по которому к ней будет обращаться frontend.
• Всё остальное - одинаково, включая DBHost, DBName, credentials.

После запуска обоих серверов первый стал active, второй - standby. Команда zabbix_server -R ha_status показывает состояние кластера в любой момент.

Тестировали failover просто: systemctl stop zabbix-server на активной ноде. Через минуту (HAFailoverDelay по умолчанию) резервная нода подхватила роль active. Мониторинг прервался ровно на это время - минута без алертов, потом всё восстановилось само. Для большинства применений это приемлемо; если нужно 30 секунд - параметр уменьшается.

Что требует отдельного внимания:

• Виртуальный IP. Keepalived или любой другой механизм VIP всё равно нужен - чтобы агенты и прокси ходили на один адрес независимо от того, какая нода сейчас активна. Это несколько строк конфига Keepalived, что на порядок проще, чем делать на нём весь failover Zabbix целиком.
• External checks и скрипты. Если на Zabbix-сервере крутятся внешние скрипты мониторинга - их нужно развернуть на обеих нодах. Нативный HA не синхронизирует файловую систему.
• Zabbix proxy. Прокси указывают адрес сервера явно. С VIP всё работает прозрачно; без VIP нужно прописывать оба адреса - в 6.2 прокси поддерживает несколько адресов через запятую.

Что не так в текущей реализации

Честно говоря, схема с координацией через БД - это не классический HA, а скорее active-standby с ручками в базе данных. Минута failover по умолчанию - это не катастрофа, но и не быстро. Конфигурация в файлах не синхронизируется между нодами автоматически - Ansible или любой другой configuration management обязателен, иначе ноды разъедутся.

Zabbix-агенты по умолчанию соединяются с одним адресом сервера. Если не сделать VIP, при переключении нод агенты начнут копить данные локально (буффер на стороне агента) и отправят их при восстановлении соединения - это работает, но нужно понимать задержку.

Итог

По сравнению с тем, что было раньше - Keepalived + общее хранилище + ручной скрипт переключения + тестирование всего этого вручную - нативный HA в 6.2 это большой шаг вперёд. Настройка двухнодового кластера заняла у нас меньше дня включая тестирование failover. Результат предсказуем и воспроизводим.

Клиент теперь имеет мониторинг, который переживает падение одной ноды автоматически. Это лучше, чем было. Задачу про отказоустойчивость Zabbix больше не откладываем - она закрыта.

Такие вещи мы делаем в рамках инфраструктурного сопровождения.