High Availability в Veeam Backup & Replication 13: как это работает и когда стоит выбрать альтернативу
Veeam Data Platform v13 принёс функцию, которую администраторы просили годами — встроенную высокую доступность сервера управления. До этого релиза единственным способом защитить сам VBR от простоя было либо восстановление из конфигурационного бэкапа после сбоя (с ощутимым RTO), либо самостоятельная сборка обходных решений.
В этой статье разберём, как устроена нативная HA-функция в 13 версии, какие у неё требования и ограничения, а также рассмотрим альтернативный подход.
Нативный HA-кластер в Veeam Backup & Replication 13
Архитектура предельно конкретна: два узла Veeam Software Appliance (Linux-based), один из которых активен, второй находится в режиме ожидания. Узлы используют общую внешнюю инфраструктуру репозиториев и представлены для внешнего мира единой конечной точкой кластера — DNS-именем с виртуальным IP-адресом.
Primary узел выполняет все операции — бэкап, репликацию, обслуживание заданий. Secondary узел ничего не делает, кроме постоянного получения реплицированной копии базы данных конфигурации с primary-узла. При отказе основного узла secondary повышается до роли primary, и работа продолжается с той же самой инфраструктурой репозиториев/прокси — перемещается только «активная роль» и виртуальный IP.
ВАЖНО: HA — это синхронизация, а не резервная копия: логическое повреждение конфигурации или данных на primary-узле реплицируется на secondary практически сразу. Это защита от отказа хоста/физического сервера, а не замена конфигурационных бэкапов.
Требования и архитектурные ограничения
- Только Linux-appliance. HA-кластер работает исключительно с версией Veeam Software Appliance на Linux. Смешанный кластер из Windows- и Linux-серверов бэкапа не поддерживается — если у вас классическая установка VBR на Windows, нативный HA вам недоступен без миграции на appliance.
- Лицензирование. Функция требует VDP Premium (пакет, включающий VBR, Veeam ONE и Veeam Recovery Orchestrator).
- DNS и сетевые требования. Кластер, primary- и secondary-узел должны быть прописаны в DNS как в прямой, так и в обратной зоне. Оба узла должны иметь статические IP-адреса в одной подсети и одинаковую версию Veeam.
- Репозитории. Локальные репозитории для HA-кластера использовать нельзя. Что логично, ведь данные репозиторием не реплицируются.
- Консоль управления. Для управления HA-кластером обязательно нужна классическая консоль VBR, установленная на Windows-машине. Хотя и так по опыту могу сказать, что управлять полноценно VBR из webUI не получится и для многих операций нужен классический клиент.
Switchover и Failover — два разных сценария
| Switchover | Failover | |
|---|---|---|
| Когда используется | Плановое обслуживание, тестирование | Реальный сбой primary-узла |
| Как инициируется | Вручную из консоли | Вручную из консоли или автоматически (через Veeam ONE) |
| Что происходит | Veeam проверяет состояние синхронизации, останавливает активные задания на текущем primary, переносит виртуальный IP и переводит standby в primary | Виртуальный IP немедленно переназначается secondary-узлу, работа возобновляется без ожидания завершения заданий на primary |
| Время выполнения | Около 10 минут | Зависит от скорости обнаружения сбоя и реакции |
| Рекомендация | Тестировать заранее, чтобы убедиться, что виртуальный IP переключается и консоль переподключается корректно | После восстановления упавшего узла он присоединяется как новый secondary |
Интеграция с Veeam ONE
Одно из главных преимуществ нативного HA — готовая интеграция с мониторингом и автоматизацией. Veeam ONE включает специальный набор алармов для HA-кластеров VBR, которые можно настроить не просто на уведомление, а на автоматическое действие. Например, аларм «состояние primary-узла HA-кластера VBR» при срабатывании может быть настроен на автоматический запуск failover — это особенно полезно, когда secondary-узел размещён на DR-площадке: при потере основной площадки восстановление запускается без участия администратора, а операции бэкапа могут быть немедленно возобновлены.
Альтернативный подход: репликация сервера VBR как виртуальной машины
До появления встроенного HA (и для тех, кто по разным причинам остаётся на Windows-инсталляции VBR или на более старых версиях продукта) способом защитить сервер бэкапа был другой подход, который не требует ни Linux-appliance, ни лицензии Premium. Я давно стараюсь максимально применять этот подход при построении инфраструктуры на Veeam у разных заказчиков.
Схема выглядит так:
- Сервер Veeam Backup & Replication (Windows, любая поддерживаемая версия) разворачивается как виртуальная машина.
- База данных конфигурации выносится на внешний сервер БД (Microsoft SQL Server или PostgreSQL) — то есть сам сервер VBR становится максимально stateless с точки зрения хранения конфигурации: вся критичная информация о заданиях, репозиториях, учётных данных лежит не локально, а на внешнем сервере.
- Средствами самого Veeam настраивается задание репликации этой VM на вторую площадку — точно так же, как реплицировался бы любой другой критичный сервер в инфраструктуре.
- При отказе основной площадки реплика VM на второй площадке включается, подключается к тому же внешнему серверу БД и продолжает работу с той же конфигурацией.
По сути, это применение репликации к самому серверу управления бэкапом. Не обязательно даже использовать сам Veeam для репликация на вторую площадку. Это можно делать средствами виртуализации на которой он развёрнут или сторонними средствами. Стоит не забывать так же о том, что необходимо обеспечить отказоустойчивость и внешней базы данных, например растянутый между площадками кластер из 2 нод.
Чем это похоже на нативный HA
- При потере основной площадки/хоста получить рабочий экземпляр сервера РК на второй площадки с минимальными ручными действиями.
- Конфигурация сохраняется, поскольку живёт на внешнем сервере БД, а не внутри VM — это концептуально близко к идее репликация базы, которая лежит в основе нативного HA.
- Данные бэкапов, как и в нативном HA, не входят в состав того, что реплицируется этим механизмом — репозитории должны быть по-прежнему доступны и отказоустойчивы сами по себе.
В чём принципиальные отличия от нативного HA
- Отсутствие интеграции и автоматизации через Veeam ONE. Нативный HA-кластер v13 «из коробки» интегрирован с Veeam ONE — под него есть специальные алармы и, что важнее, возможность настроить автоматический failover по этим алармам.
- Ручной или полуавтоматический failover. В нативном HA переключение виртуального IP и повышение роли узла — встроенная операция. В схеме VM репликации это ручная операция, либо автоматизация сторонними средствами.
- Более широкая совместимость. Обратная сторона всех этих ограничений — гибкость. Этот подход работает с любой версией VBR, с классической Windows-установкой, без обязательного перехода на Linux-appliance и без необходимости покупать издание VDP Premium.
Усиление схемы: отдельная инсталляция Veeam Community Edition
У описанной выше схемы есть слабое место, которое стоит проговорить отдельно: сам факт репликации VM с сервером VBR ничего не говорит о защищённости внешнего сервера БД. А ведь именно в нём хранится вся конфигурация — задания, репозитории, учётные данные, история сессий. Если база повреждена логически (неудачное обновление, ошибка администратора, повреждение на уровне файловой системы), то реплика VM сервера VBR подключится к той же самой повреждённой базе.
Ровно то же самое узкое место, и у нативного HA: там конфигурационная БД синхронизируется практически в реальном времени между узлами, а значит логическое повреждение или случайное удаление распространится на secondary-узел почти мгновенно. Точек восстановления конфигурационной БД нативная HA-логика не создаёт вообще — это механизм зеркалирования, а не резервного копирования.
Закрыть этот пробел можно относительно недорого: развернуть отдельную, независимую инсталляцию Veeam CE — единственная задача которой — делать application-aware бэкап виртуальной машины (или кластера) с внешней БД, на которой размещена конфигурационная база.
Что это даёт:
- Точки восстановления — полноценный бэкап даёт возможность откатиться на несколько часов или дней назад — то есть защищает именно от логического повреждения, а не только от отказа оборудования.
- Изоляция — отдельная инсталляция CE, разворачиваемая специально под эту задачу, должна быть физически и логически отделена от основной инфраструктуры VBR. Если основной сервер бэкапа скомпрометирован, например, шифровальщиком, отдельная изолированная копия конфигурационной БД с собственными учётными данными — дополнительный рубеж защиты.
При этом нас не пугают ограничения в 10 инстансов у CE версии — этого будет более чем достаточно для нашей задачи, даже если при помощи CE версии помимо резервного копирования БД будет настроена и репликация основного сервера Veeam.
Сравнительная таблица решений
| Критерий | Нативный HA | VM репликация сервера VBR |
|---|---|---|
| Версия/платформа VBR | Linux Software Appliance 13 | Любая версия |
| Лицензирование | Требует VDP Premium | Не требуется |
| Синхронизация конфигурации | Практически непрерывная | По расписанию задания репликации |
| Переключение (switchover/failover) | Встроенный мастер, автоматизируемый | Стандартный failover VM |
| Интеграция с Veeam ONE | Есть, включая автоматические действия по алармам | Отсутствует, нужна собственная автоматизация |
| Зависимость от внешней БД | Нет | Да — сервер БД должен быть защищён отдельно |
| Защита от логического повреждения конфигурации | Нет — только зеркалирование текущего состояния | Да, при добавлении отдельной CE-инсталляции с бэкапом БД |
| Сложность внедрения | Выше (миграция на appliance, новая лицензия) | Ниже для уже существующих Windows-инсталляций, но выше при добавлении отдельного контура CE |
Нативный HA в Veeam Backup & Replication 13 закрывает давний пробел — впервые сервер управления бэкапом можно сделать по-настоящему отказоустойчивым средствами самого продукта, с автоматизацией через Veeam ONE. Но это решение с чёткими рамками: только Linux-appliance, только Premium-лицензия.
Схема с VM-репликацией сервера VBR и внешней БД остаётся рабочей альтернативой там, где миграция на новую архитектуру пока нецелесообразна — но требует более осознанного подхода к автоматизации переключения и защите самого сервера БД, поскольку готовых инструментов мониторинга и оркестрации под эту схему нет.
