Xen Orchestra: управление и бэкапы XCP-ng

MAATRIX

Поставили XCP-ng, разобрались с xe-командами из консоли — и упёрлись в очевидный вопрос: как это всё показывать коллегам, как смотреть на пул из десяти хостов одним взглядом и, главное, как делать бэкапы виртуалок, если сам XCP-ng из коробки резервного копирования не предоставляет. Ответ один — Xen Orchestra (XO). Это не опциональная приятность, а фактически обязательный компонент, без которого XCP-ng в продакшне превращается в набор разрозненных серверов, управляемых через SSH и обрывки памяти о том, где что настроено.

Что решает Xen Orchestra в связке с XCP-ng

XCP-ng сам по себе — это гипервизор: Xen-ядро плюс дистрибутив на основе CentOS с утилитой xe. Всё управление из коробки — командная строка на каждом хосте по отдельности. Если у вас один сервер — терпимо. Если пул из нескольких хостов с общим хранилищем — уже больно: нужно помнить, на каком хосте какая VM, руками синхронизировать сетевые настройки, вручную мигрировать нагрузку при обслуживании железа.

Xen Orchestra закрывает это одной веб-консолью:

• единый обзор пула — все хосты, все VM, всё хранилище на одном экране, без прыжков по SSH-сессиям;
• создание и настройка VM через мастер — диск, память, vCPU, сеть, ISO-образ, без ручного составления XML или вызовов xe vm-install;
• живая миграция VM между хостами пула (drag-and-drop в интерфейсе) — обслуживание железа без простоя сервисов;
• управление сетями — виртуальные коммутаторы, VLAN, привязка к физическим интерфейсам, всё визуально;
• управление хранилищем — подключение SR (Storage Repository: локальный LVM, NFS, iSCSI, Ceph через сторонние драйверы), мониторинг занятого места;
• графики нагрузки — CPU, память, диск, сеть по каждой VM и хосту в реальном времени и в истории;
• ролевой доступ (RBAC) — можно завести читателя-наблюдателя для мониторинга отдельно от администратора с правом создавать и удалять VM.

Пример: у вас пул из трёх хостов XCP-ng, общее хранилище — NFS-шара. Через XO вы видите все 20 виртуалок пула на одной панели, тянете VM с хоста, который нужно перезагрузить для обновления прошивки, на соседний — без выключения гостевой ОС. Через голый xe то же самое — это последовательность команд xe vm-migrate с правильными UUID хоста и VM, которые ещё нужно достать отдельными запросами.

Установка: два принципиально разных пути

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

Community edition (xo-server + xo-web из исходников). Это открытый код проекта, который можно собрать и запустить самостоятельно — например, через xo-builder (готовый скрипт сборки от сообщества) или вручную из репозитория vatesfr/xen-orchestra на GitHub. Плюс — бесплатно, никаких лицензионных ограничений на число хостов. Минусы ощутимы:

• обновления community-версии происходят "на свой страх и риск" — нет единой кнопки апдейта с гарантией отката, часто приходится пересобирать заново;
• никакой официальной поддержки — если что-то ломается, вы идёте на форум или в issues на GitHub;
• часть enterprise-функций (например, некоторые виды бэкапов, расширенный RBAC, плагины) в community-сборке могут отсутствовать или требовать доп. телодвижений — зависит от того, какую версию исходников вы взяли.

XOA (Xen Orchestra Appliance) — платная поддерживаемая версия. Готовая виртуальная машина от Vates (компании, которая и разрабатывает XCP-ng и XO), разворачивается импортом OVA-образа за несколько минут. В комплекте — веб-панель обновлений внутри самого XOA, официальная поддержка, гарантированная совместимость версий XO с версией XCP-ng, доступ к полному набору enterprise-функций бэкапа (в зависимости от выбранного тарифного плана). Точные цены на планы называть не буду — они меняются, актуальные смотрите на официальном сайте vates.tech на момент покупки, но сама модель — подписка с несколькими уровнями (обычно завязанными на число сокетов/хостов в пуле).

Практический совет: если у вас тестовый стенд или домашняя лаборатория — берите community, это разумно. Если XCP-ng держит боевую нагрузку, за которую вы отвечаете, — считайте XOA частью бюджета инфраструктуры так же, как считаете стоимость самих серверов. Час простоя из-за не найденного бага в самосборной community-версии почти всегда обходится дороже подписки.

Установка XOA: минимальный путь

Официальный путь — импорт готового OVA в существующий пул XCP-ng:

# Скачиваем XOA appliance (ссылку и файл берём с личного кабинета Vates
# после регистрации — free trial доступен для оценки)
# Импортируем через xe прямо на хосте:
xe vm-import filename=/root/xoa.xva

# Либо через веб-интерфейс XCP-ng Center / другой уже развёрнутый XO:
# Pool > Import VM > указать путь к .xva

После импорта — запуск VM, ожидание пары минут инициализации, и заход по HTTPS на IP виртуалки:

https://<IP-адрес-XOA>

Логин по умолчанию — admin@admin.net, пароль admin (обязательно смените при первом входе). Дальше в веб-панели самого XOA — регистрация лицензии (для триала — тоже через личный кабинет), выбор канала обновлений (stable/latest), и XOA сам подтягивает обновления одной кнопкой из интерфейса.

Для community-сборки процесс другой — вы разворачиваете отдельную VM (обычно на Debian/Ubuntu), ставите Node.js нужной версии, клонируете репозиторий, собираете xo-server и xo-web. Это описано в документации проекта на GitHub, но будьте готовы к тому, что версии зависимостей со временем расходятся с тем, что было актуально на момент написания любой инструкции — включая эту.

Бэкапы VM: то, чего XCP-ng сам не даёт

Это ключевой момент. XCP-ng "из коробки" не предоставляет полноценного механизма резервного копирования виртуальных машин — только снапшоты на уровне хранилища, которые не заменяют бэкап (снапшот живёт на том же диске и погибает вместе с ним при отказе SR). Тот функционал, который в мире Proxmox закрывает Proxmox Backup Server, в мире Xen Orchestra закрывает встроенный в саму XO механизм бэкапов. Разница в архитектуре: у Proxmox бэкап — отдельный продукт (PBS), у Xen Orchestra бэкап — модуль внутри той же панели управления, но по решаемой задаче и подходу (инкрементальность, дедупликация, расписание) это концептуально похожие вещи — если вы уже настраивали Proxmox Backup Server, логика покажется знакомой.

Что доступно в XO (объём функций зависит от community/XOA и конкретного плана):

• Full backup — полный образ VM в файл (обычно в формате, который потом можно импортировать назад через xe vm-import);
• Delta backup (инкрементальный) — после первого полного снимка последующие копии переносят только изменённые блоки, экономя место и время на бэкап;
• Continuous Replication (CR) — постоянная репликация VM на другой хост/пул, почти горячий резерв;
• Disaster Recovery (DR) — репликация по расписанию с ретеншном, для сценария "весь основной ЦОД недоступен";
• Backup через S3-совместимое хранилище — можно направить бэкапы во внешний S3-бакет (в том числе самостоятельно поднятый MinIO), не только на локальный NFS/SMB.

Настройка бэкап-джобы в веб-интерфейсе XO — через раздел Backup:

1. New backup job → выбор VM или тега (например, все VM с тегом prod попадают в одну задачу автоматически);
2. выбор режима — Full или Delta;
3. целевое хранилище (remote) — NFS-шара, SMB, локальная директория на самом XOA, или S3;
4. расписание — cron-подобный синтаксис, например 0 3 * * * для каждого дня в 3 ночи;
5. ретеншн — сколько последних копий хранить (например, 7 ежедневных + 4 еженедельных).

Пример типовой delta-задачи для тега prod с ежедневным запуском и хранением 7 копий на удалённом NFS-remote — всё настраивается кликами, без единой команды в консоли, что для команды из нескольких человек с разным уровнем linux-скилла критично важно.

Восстановление — обратная операция: Backup → History → выбор нужного снапшота по дате → Restore, с указанием, на какой хост и в какой SR разворачивать. Полезная деталь — restore можно направить не на исходную VM, а создать новую рядом, чтобы сверить данные перед тем как переключать продакшн-трафик.

Мониторинг и алерты

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

• email-отчёты по итогам каждой задачи (успех/ошибка);
• webhook в внешнюю систему мониторинга (Slack, Telegram-бот через промежуточный сервис, Zabbix через API);
• дашборд Health в самом XO, где красным подсвечиваются проваленные задачи.

Возьмите за правило: если бэкап-джоба не прислала подтверждение — это тревога того же уровня, что и падение продакшн-сервиса, а не "потом посмотрю".

Роли, доступ и мультитенантность

Для команды больше одного человека RBAC в XO — не роскошь. Модель прав строится на трёх уровнях: пользователь → роль (Viewer/Operator/Admin) → объект (пул, хост, конкретная VM или папка с VM). Можно, например, дать разработчику права Operator только на его собственную VM в тестовом пуле, не открывая доступ ко всей инфраструктуре. В XOA доступны более гибкие варианты группировки через self-service портал, где пользователи сами создают VM в рамках выделенной им квоты — удобно, если вы предоставляете виртуалки внутренним командам или клиентам.

Что важно понимать до того, как строить архитектуру

Несколько практических нюансов, которые экономят время:

• XO — не гипервизор и не замена XCP-ng, а панель управления и бэкапов поверх него; сама XO обычно разворачивается как отдельная VM внутри того же пула, который она администрирует (или отдельно, если нужна изоляция от управляемой инфраструктуры);
• потеря доступности самой VM с XO не роняет работающие виртуалки пула — они продолжают крутиться на хостах, просто временно недоступно управление и не идут бэкапы по расписанию, пока XO не поднимется обратно;
• имеет смысл делать бэкап самой конфигурации XO (metadata backup — есть отдельная опция в разделе Backup) отдельно от бэкапов пользовательских VM, чтобы не потерять все настроенные задачи при полном выходе из строя XOA;
• delta-бэкапы зависят от механизма changed block tracking на уровне Xen — для очень старых версий XCP-ng или нетипичных конфигураций хранилища стоит явно проверить, что дельта-режим реально работает, а не откатывается на полный бэкап каждый раз;
• при переезде между пулами или сменой железа полезно свериться с материалом про миграцию между гипервизорами — принципы экспорта/импорта VM во многом пересекаются с тем, что делает XO под капотом.

Частые вопросы