Zabbix 6.4: апгрейд с 6.2 и нативная HA без Pacemaker на 5000+ хостах

Zabbix 6.4 вышел, и мы его ждали по конкретной причине: у одного из клиентов с инсталляцией на 5000+ хостов отказоустойчивость на уровне Zabbix-сервера до сих пор не закрыта. В октябре мы писали, как переводили другого клиента на нативный HA в 6.2, - тогда это был переход с 6.0. Здесь история другая: клиент уже на 6.2, хочет 6.4 LTS, и заодно наконец делаем HA нормально, без Pacemaker и Corosync, которые в прошлый раз даже обсуждать не стали.

Что изменилось в 6.4

Главные изменения касаются двух областей.

HA-кластеризация - механика та же, что появилась в 6.2: HANodeName в конфиге, координация через БД, failover по таймауту. Но в 6.4 добавили то, чего не хватало: статус нод теперь виден прямо во фронтенде, в Administration - High availability. Не надо бежать на сервер и запускать zabbix_server -R ha_status - видно из браузера кто active, кто standby, когда последний раз нода отвечала. Мелочь, но мониторить состояние кластера стало просто удобнее.

Ещё одно улучшение - HAFailoverDelay теперь конфигурируется из фронтенда, не только через конфиг. Для крупных инсталляций это важно: менять таймаут без рестарта сервера - другой уровень операционного комфорта.

Веб-интерфейс существенно переработан. Новый дашборд с виджетами стал значительно быстрее на больших инсталляциях - это мы заметили сразу при первом запуске после апгрейда. На 5000+ хостах старый дашборд с несколькими виджетами «Проблемы» открывался секунды три-четыре; новый - заметно живее. Точных замеров не делали, но разница ощутима.

Апгрейд с 6.2 до 6.4

Стандартная процедура, ничего экзотического.

Первое - база данных. Zabbix 6.4 требует запустить скрипт миграции схемы. У клиента PostgreSQL 14 с Patroni - схему гоним на primary, реплики подхватывают через streaming replication. Миграция заняла минут двадцать на базе с историей за три года. Это время простоя - его заранее согласовали с клиентом как техническое окно.

Второе - пакеты. Репозиторий Zabbix переключается на 6.4, пакеты обновляются: zabbix-server-pgsql, zabbix-frontend-php, zabbix-agent2. На агентах пока оставили 6.2 - обратная совместимость работает, массовое обновление агентов по 5000+ хостам - отдельная задача, на следующую неделю.

Третье - конфиг. Параметры 6.2 в 6.4 работают без изменений - deprecated ничего критичного не стало. Добавили только HANodeName и NodeAddress - именно для настройки HA, которую делали параллельно с апгрейдом.

Настройка HA

На клиентской инсталляции Zabbix-сервер всегда стоял на одной машине. Для HA нужна вторая - с той же схемой, тем же конфигом, теми же внешними скриптами мониторинга.

Развернули вторую ноду на идентичном железе. Скрипты и кастомные check-ы синхронизированы через Ansible - это обязательно, нативный HA не занимается синхронизацией файловой системы между нодами. Если что-то лежит только на первой машине, после failover это «что-то» не заработает на второй.

VIP по-прежнему нужен - для агентов и прокси, которые обращаются к серверу по адресу. Сделали через Keepalived: конфиг минимальный, VRRP на два хоста. Без VIP при переключении нод агенты начнут буферизовать данные локально и отправят их при восстановлении - это работает, но пауза в алертах неприятна.

Failover тестировали классически: systemctl stop zabbix-server на активной ноде. Резервная подхватила роль через одну минуту (HAFailoverDelay по умолчанию). Мониторинг прервался ровно на этот период - алерты встали, потом возобновились сами. Для инсталляции такого размера минута - приемлемо. Если нужно быстрее, параметр уменьшается, но нужно учитывать что при нестабильном сетевом канале более агрессивный таймаут даст ложные срабатывания.

Что важно понимать про базу данных: нативный HA Zabbix не решает отказоустойчивость на уровне БД. Если PostgreSQL упал - оба Zabbix-сервера встанут вместе с ним. Patroni у клиента стоит, это закрыто. Но если у кого-то база на одном сервере - HA Zabbix даёт лишь защиту от падения самого Zabbix-процесса, не от падения сервера с БД.

Что в результате

Апгрейд прошёл без сюрпризов. Окно простоя - 35 минут, из которых 20 ушло на миграцию схемы, остальное на переключение и проверку. HA работает, failover проверен, статус нод виден во фронтенде. Клиент наконец имеет отказоустойчивый мониторинг без Pacemaker, Corosync и прочего зоопарка, который мы обходили стороной именно потому что его сложность не соответствовала задаче.

Из незакрытого: массовое обновление агентов с 6.2 до 6.4 - планируем на следующей неделе через Ansible. Агенты 6.2 с сервером 6.4 работают корректно, спешить некуда, но актуальные версии агентов дают доступ к новым метрикам.

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