Как перейти с LXD на Incus с минимальным простоем
Переход с LXD на Incus можно подготовить заранее и выполнить с минимальным временем недоступности. Большинство подготовительных операций: сбор конфигурации, создание резервных копий, проверка дисков и установка пакетов, выполняются онлайн, не затрагивая запущенные контейнеры и виртуальные машины. Окно обслуживания потребуется только для финального переключения демона и переноса состояния отдельных экземпляров.
Incus создан как форк LXD группой бывших разработчиков после изменения политики Canonical. Он сохранил совместимость с большинством команд и форматов данных LXD, но требует отдельной установки и миграции. Для действующего production-хоста важно спланировать порядок: инвентаризация, резервное копирование, тестовый перенос, миграция, проверка, период наблюдения и rollback.
Когда возможен почти нулевой простой, а когда нужна остановка
Операции чтения конфигурации, создания snapshots, экспорта образов и подготовки целевого хоста не влияют на работу сервисов. Остановка нужна при переключении управляющего демона, переносе состояния виртуальных машин, изменении сетевых настроек или storage-пулов, а также для согласованного бэкапа баз данных и других stateful-сервисов.
Для контейнеров с базами данных или очередями используйте application-consistent backup: остановите сервис, выполните flush или штатный дамп, затем создайте snapshot. Для виртуальных машин проверьте возможность live migration, но при сомнениях выполните согласованную остановку и перенос.
Какие способы миграции рассмотреть
- Локальная миграция LXD в Incus через штатный инструмент перехода, если он поддерживается вашей версией. Сохраняет конфигурацию и данные, но требует остановки LXD.
- Перенос экземпляров через экспорт и импорт: создание backup-архивов в LXD и импорт в Incus. Гибко, но занимает больше времени и дискового пространства.
- Удаленная миграция между хостами: перенос контейнеров и VM с исходного LXD на целевой Incus по сети. Подходит для распределенных сред, но зависит от совместимости версий и сетевой доступности.
Перед выбором метода изучите документацию ваших версий LXD и Incus, так как процедуры могут отличаться. Для критичных систем предпочтителен поэтапный перенос с тестовым экземпляром.
Предварительная проверка LXD-хоста перед переходом
Перед миграцией соберите полную информацию о текущем состоянии LXD. Это позволит сравнить окружение после перехода и выявить потери. Выполните команды lxc list, lxc profile list, lxc storage list, lxc network list и сохраните вывод.
Инвентаризация контейнеров, VM и проектов
Проверьте список контейнеров и виртуальных машин, их состояние, profiles, project, snapshots, размеры root-дисков, дополнительные диски, GPU, USB, Unix sockets, proxy и cloud-init. Зафиксируйте IP-адреса, MAC-адреса, hostname и критичность каждой нагрузки. Для каждого экземпляра определите, какие сервисы он предоставляет и какие зависимости имеют.
Проверка версий и способа установки
Сверьте поддерживаемые версии LXD и Incus для вашего дистрибутива. Проверьте, установлен LXD из snap, deb или собран вручную. От этого зависит процедура миграции и совместимость базы данных. Узнайте версию ядра и наличие необходимых модулей для storage-драйверов (ZFS, LVM, btrfs).
Проверка storage pools, сетей и ACL
Соберите сведения о storage pools и драйверах, dataset или logical volume, bridge, OVN, DNS-зонах, firewall, сетевых ACL, projects, certificates и локальных группах. Проверьте свободное место для snapshots, экспорта и временных файлов. Убедитесь, что все используемые ресурсы доступны и не имеют ошибок.
Критерии остановки подготовки
Остановите процесс миграции, если отсутствует проверяемая резервная копия, не хватает места, неизвестно происхождение пакетов, поврежден storage pool, есть незадокументированные ручные изменения сети, не работает мониторинг или невозможно выделить окно для финального переключения.
Резервное копирование перед миграцией с LXD на Incus
Резервная копия должна включать данные экземпляров, конфигурацию LXD и внешние зависимости. Snapshot удобен для быстрого возврата, но не заменяет копию на отдельный носитель или другой хост.
Что сохранить из конфигурации LXD
Сохраните конфигурацию экземпляров, profiles, projects, networks, storage pools, сертификаты, ACL, snapshots, identities и настройки удаленных endpoints. Зафиксируйте выводы диагностических команд и версии компонентов. Экспортируйте конфигурацию в текстовые файлы для последующего сравнения.
Резервные копии контейнеров и виртуальных машин
Для контейнеров создайте согласованные snapshots и экспорты. Для баз данных и других stateful-сервисов предусмотрите application-consistent backup: остановите сервис, выполните flush или штатный дамп, затем snapshot. Проверьте, что в копию попали дополнительные диски и необходимые устройства.
Для виртуальных машин используйте lxc export с включением всех дисков и метаданных. Убедитесь, что резервная копия содержит firmware, UEFI/BIOS, TPM, cloud-init и MAC-адреса.
Проверка резервной копии
Проверьте размер, целостность, доступность копии с отдельного пути и наличие свободного места для восстановления. Выполните тестовый импорт хотя бы одного некритичного контейнера или восстановление на отдельном хосте. Это подтвердит работоспособность процедуры восстановления.
Перенос контейнеров LXD и виртуальных машин в Incus
Переносите нагрузки волнами по критичности. Сначала тестовый экземпляр, затем второстепенные контейнеры, stateless-сервисы, stateful-сервисы, виртуальные машины. Перед каждой волной проверяйте резервную копию, доступность ресурсов и готовность rollback.
Подготовка Incus на целевом хосте
Проверьте установку Incus, инициализацию хранилища, доступность локального или удаленного storage, сетевые мосты, DNS, firewall, сертификаты и права администратора. Сверите имена ресурсов и параметры с исходным хостом. Создайте необходимые profiles, networks и storage pools до переноса экземпляров.
Тестовая миграция некритичного контейнера
Выберите контейнер с типовым профилем и без критичных зависимостей. Перенесите его выбранным способом, сравните конфигурацию, snapshots, диски, MAC и IP, проверьте запуск, консоль, DNS, исходящие и входящие соединения. Это выявит несовместимости до затрагивания production.
Миграция рабочих контейнеров
Перед финальным переносом остановите или корректно заморозьте сервисы, создайте последний snapshot или экспорт, перенесите экземпляр, запустите его в Incus и проверьте сервисы. Ведите журнал команд, времени и результатов проверок.
Перенос виртуальных машин
Проверьте образы и диски VM, firmware, UEFI или BIOS, TPM, cloud-init, MAC-адреса и порядок загрузки. Live migration зависит от версий, драйверов, типа storage и сетевой схемы; при сомнениях используйте согласованную остановку и перенос.
Порядок переноса для минимизации простоя
Рекомендуемый порядок: тестовый экземпляр, второстепенные контейнеры, stateless-сервисы, stateful-сервисы, VM. Перед каждой волной проверяйте резервную копию, доступность ресурсов и готовность rollback. Это позволит изолировать проблемы и сократить общее время недоступности.
Миграция профилей, сетей, storage pools и ACL
Сначала переносятся или воссоздаются общие зависимости, затем экземпляры. Каждую группу настроек нужно сравнить с исходным состоянием и проверить на реальной нагрузке.
Профили и устройства экземпляров
Сверьте порядок применения profiles, параметры limits, security-настройки, raw-конфигурацию, disk, nic, proxy, GPU, USB и Unix-char устройства. Проверьте, что локальные overrides экземпляра не потерялись при переносе.
Сети, bridge, OVN и DNS
Проверьте имена и параметры managed networks, bridge, DHCP, DNS, MTU, VLAN, маршруты, firewall и ACL. Для OVN отдельно проверьте logical switches, uplinks и внешнюю доступность. Зафиксируйте статические IP и MAC, если на них завязаны DNS или allowlist.
Storage pools и дополнительные диски
Сопоставьте драйверы storage, имена пулов, source, dataset, volume, content type и настройки размещения. Проверьте root-диски, custom volumes, snapshots, quotas, discard, block или filesystem-режим и права на точки монтирования.
ACL, certificates, projects и права доступа
Проверьте projects, identities, groups, certificates, trusted clients, API-доступ, ACL и интеграции с внешней аутентификацией. После переноса протестируйте доступ от имени обычной учетной записи и сервисной автоматизации.
Проверка Incus после переноса
Проводите проверку в несколько уровней: сам демон, ресурсы, экземпляры, сеть, хранилище, приложения и внешние зависимости. Результаты сравнивайте с зафиксированным состоянием LXD.
Проверка состояния демона и экземпляров
Проверьте состояние Incus, список контейнеров и VM, autostart, profiles, snapshots, ресурсы CPU и памяти, ошибки конфигурации и события. Убедитесь, что после перезагрузки хоста экземпляры поднимаются в ожидаемом порядке.
Проверка сети и доступности сервисов
Проверьте адреса, DNS, маршрутизацию, MTU, доступ между экземплярами, выход в интернет или корпоративную сеть, входящие порты, reverse proxy и firewall. Выполните проверки снаружи хоста и изнутри экземпляров.
Проверка storage и целостности данных
Проверьте подключение всех дисков и volumes, свободное место, quotas, snapshots, ошибки ZFS, LVM или другого backend, права доступа и тестовую запись. Для баз данных и файловых сервисов выполните прикладную проверку.
Проверка приложений, VM и мониторинга
Проверьте systemd-сервисы, healthchecks, логи приложений, консоль VM, cloud-init, backup jobs, мониторинг, алерты и автоматизацию. Сравните latency, сетевые ошибки и потребление ресурсов с показателями до миграции.
Что делать при обнаружении проблем после миграции
Разделите проблемы по уровням: пакет или демон, конфигурация, storage, сеть, гостевая ОС, приложение. До исправлений сохраните логи, конфигурацию и состояние экземпляра. Не удаляйте исходные snapshots и резервные копии до завершения периода наблюдения.
Проблемы запуска контейнера или VM
Проверьте логи демона, события, профиль, devices, root-диск, firmware VM, доступность storage и права. Сравните конфигурацию с исходным экспортом и запустите экземпляр в диагностическом режиме, если это поддерживается.
Сетевые ошибки и недоступность сервисов
Проверьте link и bridge на хосте, DHCP и DNS, MAC, VLAN, MTU, firewall, ACL, маршруты и настройки внутри гостевой ОС. Зафиксируйте, на каком участке исчезает трафик: хост, виртуальный интерфейс, bridge, шлюз или приложение.
Ошибки storage и потеря томов
Проверьте состояние backend, source volume, dataset, mountpoint, quotas и права. При подозрении на потерю данных остановите запись, сохраните логи и перейдите к восстановлению из проверенной копии.
Когда прекращать диагностику и запускать rollback
Определите заранее критерии abort: повреждение данных, недоступность критичных сервисов сверх согласованного окна, потеря сетевой связности, невозможность запустить VM, ошибки storage или отсутствие достоверного состояния системы.
План отката с Incus обратно на LXD
Rollback должен быть подготовлен до миграции. Сначала зафиксируйте решение об откате и остановите изменения, затем сохраните диагностическое состояние Incus, остановите перенесенные экземпляры, восстановите LXD и верните нагрузки из исходной конфигурации или проверенных копий.
Условия запуска rollback
Перечислите заранее согласованные критерии: нарушение SLA, потеря данных, невозможность восстановить сеть или storage, неработающие критичные VM, ошибки ACL или невозможность подтвердить корректность резервной копии.
Сохранение состояния Incus перед откатом
Сохраните логи, конфигурации, список экземпляров, события, snapshots и сведения о действиях пользователей. Не удаляйте Incus до фиксации причин сбоя и проверки доступности исходных данных.
Восстановление LXD и исходной конфигурации
Остановите Incus по утвержденной процедуре, восстановите LXD и его конфигурацию из резервной копии, верните исходные пакеты или snap revision, подключите исходные storage pools и сети. Проверьте certificates, ACL, projects и автозапуск.
Возврат контейнеров и VM
Запускайте экземпляры по приоритету после подтверждения состояния дисков и сети. Для stateful-сервисов используйте согласованную копию или последний подтвержденный snapshot. Проверьте hostname, IP, DNS, доступ к данным и прикладные healthchecks.
Контрольные проверки после rollback
Проверьте статус LXD, контейнеров и VM, storage, сети, ACL, мониторинг, резервное копирование и внешние подключения. Сравните контрольные значения с pre-migration инвентаризацией и задокументируйте расхождения.
Финальный чек-лист перехода с LXD на Incus
Чек-лист до начала работ
- Версии LXD и Incus совместимы, дистрибутив поддерживается.
- Инвентаризация всех экземпляров, profiles, networks, storage pools, ACL завершена.
- Резервные копии контейнеров и VM созданы и проверены.
- Конфигурация LXD экспортирована и сохранена отдельно.
- Целевой хост Incus подготовлен: storage, сети, profiles созданы.
- Тестовый контейнер успешно перенесен и проверен.
- План коммуникаций согласован, ответственные назначены, критерии abort определены.
Чек-лист после перехода
- Все экземпляры запущены и находятся в состоянии Running.
- Сервисы доступны по ожидаемым IP и DNS.
- Volumes подключены, данные целы, тестовая запись успешна.
- VM загружаются, консоль работает, cloud-init выполнен.
- Логи Incus и приложений не содержат критических ошибок.
- Backup и monitoring работают, алерты поступают.
- Rollback-точка сохранена и проверена, исходные snapshots не удалены.
Для дополнительной информации по общим принципам миграции серверов изучите полное пошаговое руководство по миграции серверов в 2026 году. Если вы планируете переход с устаревших систем, обратите внимание на практическое руководство по вынужденной миграции инфраструктуры. Для понимания рисков и скрытых сложностей при миграции ИТ-инфраструктуры ознакомьтесь с ключевыми рисками и скрытыми сложностями.