Tesco переносит с VMware около 40 тысяч серверных нагрузок. По материалам в изложении The Register, от них зависят серверы и системы данных магазинов, вплоть до касс в торговых залах. Платформу на замену ритейлер выбирал уже после того, как Broadcom отказался продлевать поддержку его инсталляций. Миграция идёт в режиме, который в опубликованных материалах назван «at exceptional pace», — в предельно возможном темпе. Выяснилось, что Veeam и Zerto, на которых у ритейлера построены резервное копирование и защита данных, не работают с выбранной платформой. Часть функциональности пришлось дописывать или докупать.
Совместимость бэкап-системы с целевой платформой можно проверить по документации за один рабочий день. В проекте миграции таких проверок набирается около десятка, и каждая занимает примерно столько же времени.
У всех, кто уходит с vSphere, задача одна: перенести парк виртуальных машин на другую платформу и сохранить всё, что за полтора десятка лет построено вокруг него, — резервное копирование, микросегментацию, план аварийного восстановления и регламенты службы ИБ. Сами машины переносятся инструментами конвертации почти без сюрпризов, но обвязку вокруг них предстоит собрать заново. Поэтому её состав нужно выяснить заранее.
Эта обвязка охватывает девять функциональных осей. Их можно разделить на три группы: что работает сразу после переноса, что команда собирает сама и что устроено иначе и требует новых регламентов. Для каждой группы разберём, что проверять и в каком порядке.
Речь пойдёт о версиях платформ от сообщества. Доработки конкретных вендоров поверх открытой базы разобраны ниже. Это вторая статья цикла: в первой разбирались класс решения, модель поддержки и расчёт совокупной стоимости владения.
Статья рассчитана на инженеров эксплуатации и архитекторов виртуализации, которые выбирают целевую платформу или уже ведут перенос. Специалистам по ИБ пригодятся разделы про доступ к коду и регуляторику. Тем, кто уходит с Hyper-V или Nutanix, таблица девяти осей и чек-лист тоже подойдут: они привязаны к слою оркестрации и не зависят от вендора исходной платформы.
Как устроена система виртуализации
Оркестрацию и виртуализацию часто путают между собой. Гипервизор запускает виртуальные машины. К этому слою относятся KVM, Xen, ESXi, Hyper-V и bhyve. Оркестратор распределяет ресурсы, предоставляет API и обеспечивает мультитенантность и самообслуживание. Примеры — OpenStack, oVirt и vCenter. В Proxmox VE оба слоя входят в одну поставку.
Путаница между слоями дорого обходится уже при выборе платформы. В требованиях нередко сравнивают KVM с vSphere, хотя KVM — модуль ядра, а vSphere — платформа с планировщиком, каталогом и ролевой моделью. В результате команда получает гипервизор без оркестрации и после подписания контракта вынуждена дописывать недостающий слой сама.
Помимо устройства двух слоёв, нужно выяснить, кому принадлежит код. От этого зависит, кто определяет развитие функций платформы. Вариантов три: чистый апстрим (основная ветка разработки открытого проекта, куда попадают изменения), форк с доработками и полностью собственная разработка.
В проприетарной системе развитие функций определяет вендор: код закрыт, патчи приходят по подписке, состав продукта меняется по решению владельца. В 2025 году Broadcom объявил об отказе от технологии vVols начиная с VCF и VVF 9.0. Вместе с ней закончились и Storage-интеграции, построенные на этой технологии. Голосования пользователей по этому вопросу не проводилось.
Открытый слой: кто на самом деле держит KVM
KVM разработали в стартапе Qumranet в 2006 году. Через два года компанию купила Red Hat. Сам гипервизор вошёл в ядро Linux, а созданные поверх него продукты остались у Red Hat. Ниже разберём, как это сказалось на oVirt.
KVM включили в основную ветку ядра Linux в релизе 2.6.20 от 5 февраля 2007 года. С тех пор его разрабатывают вместе с ядром. Над одним только релизом 6.18 осенью 2025 года работали 2 134 разработчика из 217 организаций. У подсистемы есть общий мейнтейнер Паоло Бонзини и отдельные со-мейнтейнеры по архитектурам. KVM используют Google Compute Engine, платформа AWS Nitro и практически все российские платформы виртуализации.
Это различие важно для судьбы проектов. Разработка KVM идёт в сообществе ядра Linux, поэтому решения Red Hat уже не определяют его будущее. Продукты компании зависят от её приоритетов: если они изменятся, компания может прекратить их развитие.
Собственные гипервизоры есть у немногих вендоров: ESXi у Broadcom, Hyper-V у Microsoft и AHV у Nutanix, выросший из KVM. Остальные строят оркестрацию поверх общего открытого гипервизора и конкурируют возможностями платформы. Замена ESXi на Hyper-V оставляет компанию с закрытым кодом иностранного вендора и теми же юрисдикционными рисками.
Среди российских вендоров выделяется vStack: платформа построена на bhyve, гипервизоре FreeBSD, а не на связке Linux и KVM. У неё другая кодовая база; набор кластерных функций и сроки их появления зависят от релизного цикла FreeBSD. Поэтому на пилоте стоит отдельно проверить живую миграцию между хостами с разными процессорами.
Большинство платформ использует один и тот же гипервизор, поэтому сравнивать стоит прежде всего их оркестрацию.
Что сохранится после переезда: три направления
При выборе платформы нужно понять, какие функции сохранятся после переноса, какие потребуют настройки и какие придётся организовать иначе. Для сравнения возьмём девять направлений. Больше всего работы дадут четыре из них: там возможности есть, но складываются из отдельных компонентов.
Направление первое: работает сразу после переезда
Живая миграция и HA доступны в зрелых открытых платформах, от Proxmox VE до OpenStack. Управлять инфраструктурой через код тоже можно: у таких платформ есть API и Terraform-провайдеры, хотя у части российских форков они собственной разработки.
С резервным копированием ситуация сложнее. За последние релизы оно перешло из категории «нет» в категорию «работает с оговорками». CBT (changed block tracking) позволяет бэкап-системе читать только изменённые блоки. Без CBT при создании инкрементальной копии приходится считывать диск целиком. Для терабайтной машины это часы вместо минут и полная загрузка дисковой подсистемы в окно бэкапа. В vSphere CBT работает вместе с VADP, на котором построены зрелые продукты резервного копирования для этой платформы.
В открытых платформах задача решается по-разному.
Proxmox VE официально поддерживается Veeam. CBT здесь использует dirty bitmaps QEMU — карты изменённых блоков. Согласно той же документации, для дисков RAW и VMDK карта сбрасывается при выключении или перезагрузке машины. Следующий бэкап снова прочитает диск целиком. Это нужно учитывать при планировании: после планового перезапуска сервиса ночная копия может оказаться полной.
В линейке oVirt, включая российские форки, Veeam использует контрольные точки oVirt. Здесь ограничение жёстче: для машин с RAW-дисками контрольные точки вообще не создаются, поэтому CBT не работает. Чтобы его использовать, диск придётся конвертировать в QCOW2.
Оговорка в обоих случаях связана с форматом диска, но проявляется по-разному. В Proxmox VE она влияет на расписание бэкапов, в oVirt — на выбор формата.
Отдельно нужно проверить целостность копии. CBT определяет, сколько данных читать; возможность восстановить приложение зависит от согласованности снимка. На новой платформе проверяют три уровня.
Crash-consistent — снимок состояния машины без подготовки, как после внезапного отключения питания. При запуске файловая система восстановится, но база данных может оказаться повреждена. Для СУБД этого уровня недостаточно.
Файловая целостность — перед снимком гостевой агент замораживает файловую систему: в Linux через системный вызов fsfreeze, в Windows через VSS. Ввод-вывод приостанавливается на секунды, чтобы получить согласованное состояние данных на диске.
Прикладная целостность — приложение до снимка сбрасывает буферы и фиксирует транзакции. Одного гостевого агента для этого недостаточно: нужна интеграция с конкретной СУБД.
Поэтому гостевой агент включают в золотой образ и проверяют на пилоте вместе с бэкап-системой, прежде чем переносить первую сотню машин.
Нужны и копии управляющего слоя. Виртуальные машины резервируют все, а состояние самой платформы — гораздо реже. После отказа площадки вместе с дисками придётся восстанавливать базу оркестратора, сети и политики, ролевую модель, привязку томов к машинам. Без этого из копий получится набор дисков, а рабочую среду придётся собирать вручную.
В vSphere состояние управляющего слоя сохраняют средствами резервного копирования vCenter. Для открытой платформы нужен отдельный регламент. У вендора стоит спросить прямо: чем и как часто копируется состояние управляющего слоя, сколько времени занимает его восстановление на чистом железе.
Мы тоже начинали со штатных механизмов. В OpenStack есть набор драйверов резервного копирования, но собственный драйвер выгрузки в S3 не поддерживал дифференциальные копии. Мы переписали его и ускорили создание копий в 10 раз. Целостность снимка обеспечивает гостевой агент QEMU: в Windows он использует теневое копирование, в Linux — fsfreeze. Остальные драйверы резервного копирования работают штатно; дорабатывать пришлось только выгрузку в S3.
OpenStack за это время заметно вырос. По данным OpenInfra Foundation за октябрь 2025 года, в продакшене по всему миру работало больше 55 млн ядер против 45 млн в апреле того же года.
Направление второе: что придётся собрать команде
Четыре из девяти направлений в открытых платформах закрываются набором компонентов. На их настройку и сопровождение нужно заложить время инженеров.
Автобалансировка уровня DRS пока догоняет vSphere. В OpenStack за неё отвечает Watcher. В релизе Epoxy 2025.1, вышедшем в апреле 2025 года, Watcher научился получать метрики из Prometheus.
Watcher решает, когда переносить машины, по загрузке хостов. Раньше данные поступали из телеметрии OpenStack, теперь источником может служить Prometheus. Если команда уже собирает туда метрики инфраструктуры, включая VMware-хосты, балансировщик целевой платформы и команда эксплуатации будут видеть одну картину нагрузки, в том числе по ещё не перенесённой части парка.
В Proxmox VE штатного балансировщика нет: машины распределяют внешними инструментами и скриптами. На кластере из десятка хостов с этим можно жить. Для нескольких сотен хостов инструменты придётся разрабатывать и сопровождать отдельно.
DRS в vSphere решает сразу четыре задачи. При переходе на открытую платформу их нужно разбирать по отдельности. Первичное размещение машины выполняет планировщик оркестратора — например, Nova scheduler с фильтрами и весами в OpenStack. За перебалансировку при перекосе нагрузки отвечает Watcher или внешний скрипт. Совместное и раздельное размещение машин задают группами афинности. Для режима обслуживания нужно явно настроить эвакуацию. Все четыре сценария проверяют на пилоте; они включены в чек-лист ниже.
Микросегментацию уровня NSX можно построить на OVN, штатном сетевом бэкенде OpenStack Neutron, или на SDN выбранной платформы. Политики придётся описать заново. Единой консоли для машин, правил и потоков может не быть.
OVN (Open Virtual Network) работает поверх Open vSwitch. Сети в нём описывают через логические коммутаторы, маршрутизаторы и ACL, а контроллер преобразует эти описания в потоки на хостах. Этого хватает для базовой микросегментации: правил для трафика между машинами, изоляции тенантов и распределённой маршрутизации. Идентификацию приложений на уровне L7, инвентаризацию потоков для построения политик по реальному трафику и единую консоль для нескольких площадок, привычные по зрелому NSX, придётся собирать из отдельных компонентов.
Матрицу разрешённых потоков составляют до пилота по фактическому трафику на старой платформе. Если перенести микросегментацию по принципу «пока откроем всё, потом настроим», временные разрешения рискуют остаться постоянными.
При росте инсталляции проявляются ограничения штатного Neutron. Мы столкнулись с четырьмя.
Агенты не хранят состояние и не сообщают о своих настройках. Если событие потеряно, нужна полная синхронизация, которая при большом числе сущностей занимает часы.
Слой передачи данных сложно разбирать: логика сети находится внутри Open vSwitch и его агента, среди десятков тысяч правил.
Обмен событиями идёт через RabbitMQ. Брокер становится узким местом, а его сбой делает недоступным весь SDN.
Рост числа функций увеличивает поток событий. Плоская сеть работает на тысяче гипервизоров, но с оверлеями и распределённой маршрутизацией трудности начинаются уже на сотне.
Поэтому в VK Cloud мы разработали SDN Sprut с совместимым Neutron API, чтобы клиентам не пришлось переписывать интеграции. Агенты получают от сервера целевое состояние и постоянно приводят сеть к нему. Вместо RabbitMQ используется HTTP REST API. Кодовая база Sprut насчитывает 15 тысяч строк против 250 тысяч у Neutron. При массовом удалении сетей операция заняла около 10 секунд вместо 66 — на 84% меньше по внутреннему замеру на нашем стенде.
При выборе платформы спросите у вендора, на каком количестве гипервизоров проверяли микросегментацию и как система восстанавливается после потери события агентом. По ответу будет понятнее, проверяли ли её под продакшен-нагрузкой или только на стенде.
vGPU и обновление кластера тоже потребуют отдельной проработки. NVIDIA официально поддерживает vGPU на Proxmox VE, но интеграций здесь меньше, чем у vSphere. В OpenStack релиз Caracal добавил в Nova живую миграцию машин с vGPU. Раньше для обслуживания хоста их приходилось выключать. В vSphere Lifecycle Manager обновляет хосты до заданного состояния; в открытых платформах эту работу выполняют пакетный менеджер с Ansible или инструменты вроде Kolla. Результат сопоставим, но команде нужны другие навыки — их стоит учесть в плане обучения.
Оркестрацию аварийного восстановления придётся проектировать заново. Логика SRM на новую платформу не переносится: порядок запуска машин, зависимости сервисов и тестовые прогоны нужно описать другими инструментами и закрепить в регламенте.
Направление третье: работает по другой схеме
Ещё в двух направлениях открытые платформы работают не так, как vSphere. Их стоит обсудить с командами хранения и безопасности до выбора платформы.
Storage-offload. В vSphere массив выполняет клонирование и зануление блоков через VAAI и VASA. На открытой платформе эти операции выполняют хосты, а массив используется как сетевое хранилище. Массовое клонирование машин и развёртывание из шаблонов сильнее нагружают хосты и сеть хранения, поэтому окна для таких операций нужно пересчитать.
Безагентная защита. В vSphere Guest Introspection позволяет проверять гостевую систему снаружи. На открытой платформе антивирусную защиту обычно обеспечивают агенты внутри гостевых систем.
Безагентная схема в vSphere помогала избежать одновременного запуска сканирования на сотне машин одного хоста и упрощала обслуживание агентов в VDI-клонах, которые живут до конца рабочего дня. Для открытых платформ существуют libvirt и проекты интроспекции памяти, но готовую связку гипервизора с сертифицированным средством безагентной защиты вендоры пока собирают. Расписания сканирования придётся разнести по времени, а плотность машин на хосте пересчитать с учётом нагрузки от агентов.
Оба пункта можно проверить по документации за день: поддерживает ли целевая платформа offload для вашего массива и есть ли у средства защиты агент для каждой гостевой ОС в парке. Эти ответы нужны до пилота.
По девяти направлениям получается такая картина.
Направление | Статус в открытых платформах | Комментарий |
Живая миграция, HA | Закрыто | Штатно во всех зрелых платформах |
Автобалансировка (класс DRS) | Догоняет | OpenStack Watcher; в Proxmox внешние инструменты |
Инкрементальные бэкапы (CBT) | Закрыто с оговорками | Veeam для Proxmox VE (RAW и VMDK) и линейки oVirt (RAW) |
Storage-интеграции (VAAI, VASA) | Другая схема | Массив работает как сетевое хранилище, операции на хостах |
Микросегментация (класс NSX) | Догоняет | OVN и SDN платформ, политики пересобираются |
API, Terraform, IaC | Закрыто | Провайдеры у всех зрелых платформ |
vGPU и обновление кластера | Догоняет | NVIDIA поддерживает Proxmox, живая миграция vGPU в OpenStack; обновления через Ansible или Kolla |
Безагентная защита (Guest Introspection) | Другая схема | Агенты внутри гостевых систем |
Оркестрация DR (класс SRM) | Догоняет | Пересборка другими инструментами |
Здесь описаны возможности версий от сообщества: OpenStack, oVirt и Proxmox VE без доработок конкретного вендора. Российские разработчики берут открытую основу и добавляют функции, которых нет в апстриме, поэтому возможности их продуктов нужно проверять отдельно.
Публичное и частное облака VK Tech построены на форке OpenStack от версии Ocata, который развивает собственная команда. Штатного управления политиками нам не хватило по гибкости, поэтому мы написали своё. Когда Neutron упёрся в ограничения по числу гипервизоров, разработали Sprut. Это не полный список доработок, но он показывает, насколько вендорская платформа может отличаться от апстрима.
Таблица показывает возможности апстрима, но не заменяет проверку конкретной платформы. По каждой строке со статусом «догоняет» или «другая схема» спросите у вендора, реализована ли функция в его продукте, с какой версии и на каком масштабе её проверяли.
Из девяти направлений три закрываются штатными средствами, четыре потребуют работы команды, ещё два меняют привычную схему эксплуатации. Все девять нужно проверить до ввода платформы в продакшен.
Lakehouse-платформа для аналитики и ML
Объединяйте данные из разных систем и снижайте расходы на хранение в 7–10 раз
Код: безопасность, доработки, право форка
Таблица показывает, какие функции есть у платформы сейчас. Но для эксплуатации важен и другой вопрос: кто решает, когда вы получите исправление и сможете ли установить его на свои хосты.
1. Кто управляет окном патча
4 марта 2025 года Broadcom выпустила бюллетень о трёх уязвимостях нулевого дня в ESXi, которые уже эксплуатировались. Цепочка уязвимостей позволяет атакующему перейти из скомпрометированной гостевой системы на гипервизор и получить доступ к другим машинам на хосте.
Часть клиентов с лицензиями, переведёнными на более низкий уровень, не смогла скачать патчи из-за сбоя на портале поддержки Broadcom. Исправления уже были выпущены, но получить их мешали работа портала и условия контракта.
На этом история не закончилась. В декабре 2025 года Huntress зафиксировала атаку с набором эксплойтов для той же тройки CVE. Набор охватывал 155 сборок ESXi версий от 5.1 до 8.0. Для сборок, вышедших из поддержки, патчей нет.
В январе 2026 года Shadowserver насчитывал больше 30 тысяч уязвимых хостов, доступных из интернета. Месяцем позже CISA подтвердила эксплуатацию CVE-2025-22225 в атаках с шифровальщиками.
В июле 2026 года бюллетень VMSA-2026-0006 закрыл обход аутентификации CVE-2026-59309 с оценкой 9.8 в VMware Directory Service и побег из виртуальной машины CVE-2026-47876 с оценкой 9.3 через сетевой адаптер VMXNET3.
В открытом коде уязвимости тоже находят. Но для установки патча не нужен доступ к порталу вендора по действующему контракту.
С закрытым кодом нельзя взять патч из апстрима и собрать его самостоятельно или передать исходники на аудит. Приходится ждать обновления от вендора и сохранять контракт, который даёт доступ к нему.
Ситуация | Закрытый код | Открытый код |
Вышел критический патч | Ждём сборку вендора; нужен действующий контракт | Патч доступен в апстриме, можно собрать самим |
Версия вышла из поддержки | Исправления не будет | Исходники остаются, патч можно перенести в свою ветку |
Нужна функция, которой нет | Подаём заявку в roadmap вендора | Дорабатываем своей командой или силами вендора форка |
Вендор снял технологию с поддержки | Интеграции на ней прекращаются | Код остаётся, ветку можно развивать дальше |
Аудит безопасности | По документации вендора | По исходникам, своей командой или лабораторией |
2. Право доработки
Открытый код можно менять под свои задачи. VK Cloud построен на сильно доработанном OpenStack: наряду со стандартными компонентами в платформе работают собственные модули резервного копирования, сети, хранения и безопасности. Когда их обновлять и развивать, решает команда платформы.
Похожим путём идут российские разработчики на базе oVirt. РЕД Софт развивает «РЕД Виртуализацию» вместе со своей операционной системой. Заказчик получает ОС и платформу виртуализации от одной команды, с общим циклом обновлений и одной точкой поддержки.
3. Ветка и её донор
Судьба oVirt показывает, что бывает, когда компания, от которой зависит ветка, меняет стратегию. Red Hat остановила разработку RHV и завершает его поддержку в 2026 году, сосредоточившись на OpenShift Virtualization поверх KubeVirt. На KVM это решение не влияет: компания получила его вместе с Qumranet, но гипервизор давно входит в ядро Linux и не зависит от продуктовой стратегии Red Hat.
Форк проекта крупного зарубежного вендора даёт хорошую стартовую позицию: зрелый код, готовую архитектуру и сообщество. Пока исходный проект развивается, команда форка может брать оттуда исправления и новые функции. Если разработка прекращается, ей самой придётся поддерживать код, закрывать уязвимости, следить за совместимостью с новыми ядрами и выполнять всю работу, которую раньше делали разработчики исходного проекта. Объём задач не сокращается — они переходят другой команде.
Поэтому у вендора стоит спросить, от какого проекта ответвилась его платформа и что он будет делать, если тот закроется. Содержательный ответ — сколько человек уже сопровождают ветку и какие изменения они выпустили самостоятельно.
Открытая лицензия не позволяет вендору отозвать уже доступный код письмом. Apache и GPL сохраняют право продолжить разработку, а у пользователей остаются исходники, даже если мейнтейнер уйдёт. Историю Tesco с такой базой технически не воспроизвести.
Это право, однако, ещё нужно суметь использовать. В феврале 2025 года MinIO убрала административный веб-интерфейс из Community Edition, оставив объектный браузер и предложив остальные функции в коммерческой версии. Лицензия AGPL позволяла сделать форк, и сообщество создало OpenMaxIO. Но затем разработка остановилась: к октябрю 2025 года с последнего коммита прошло четыре месяца. Код у пользователей остался, а команды для его развития не хватило.
Лицензия даёт возможность продолжить продукт, но не обеспечивает сопровождение. Оценивая форк, нужно смотреть, есть ли у вендора команда, способная поддерживать его самостоятельно.
4. Где платформа набирает зрелость
OpenStack используют уже полтора десятка лет. OVHcloud называет его фундаментом своего публичного облака, а у Walmart и Workday инсталляции превышают миллион ядер каждая. Масштаб внедрений показывает, что платформа способна работать под большой нагрузкой. Для выбора продукта важно также понять, где и на каких задачах проверяют код конкретного вендора.
Большие инсталляции сталкивают нагрузки, которые трудно совместить на стенде: база ночью упирается в диск, соседний тенант создаёт пики сетевого трафика, кластер Kubernetes поднимает сотню подов за минуту, а виртуальные рабочие места одновременно запускаются в девять утра. Когда платформой пользуются тысячи разных команд, такие сочетания возникают без сценария испытаний.
VMware набирала этот опыт двадцать лет на десятках тысяч инсталляций. Клиенты находили режимы работы, которых разработчики не предусмотрели, а подписка финансировала дальнейшее развитие продукта. У зрелой платформы за плечами много разных нагрузок и отказов, с которыми уже пришлось разобраться.
Если публичное облако и коробочная поставка вендора работают на одной кодовой базе, он сам круглосуточно эксплуатирует свой продукт под разнородной нагрузкой. Проблемы проявляются на его площадке, а исправления попадают в общую ветку. Вендор, который только поставляет платформу заказчикам, узнаёт о сбоях из обращений и получает такую обратную связь позже.
У нас публичное облако VK Cloud обслуживает тысячи клиентов с разными нагрузками: базы данных, кластеры Kubernetes, виртуальные рабочие места, сетевые пики у соседних тенантов. VK Private Cloud разворачивается on-premise на той же кодовой базе. Исправления, появившиеся после эксплуатации публичной площадки за последний год, уже входят в неё; дополнительно платформа поддерживает российские ОС и оборудование из реестра. Такая модель доступна любому вендору, который развивает публичное облако и коробочную поставку в одной ветке. Нас тоже стоит проверять по этому критерию.
Спросите у вендора on-premise платформы, эксплуатирует ли он её сам, в каком масштабе и под какой нагрузкой. Демостенд и десять внедрений дают другой опыт, чем публичное облако на той же кодовой базе.
Владение кодом позволяет выпускать свои патчи, дорабатывать платформу, передавать исходники на аудит и продолжать разработку, если вендор изменит планы. Но использовать эти возможности сможет только команда, которая поддерживает ветку и регулярно проверяет её под реальной нагрузкой.
Два способа получить открытую платформу
Сравнение по девяти направлениям показывает, что нужно проверить перед переездом. Теперь стоит решить, кто будет собирать и сопровождать платформу: ваша команда или вендор. От этого зависит работа инженеров в первый год.
Если собирать стек самостоятельно, придётся связывать компоненты, которые развиваются отдельно. KVM, Ceph и OVN выпускают релизы в разном темпе. Команда отвечает за их совместимость, обновления и сроки внедрения нужных функций. Семён Лапин, principal-архитектор виртуализации и инфраструктур, в статье «25 лет на игле VMware» пишет: «Когда не контролируешь upstream — не контролируешь roadmap».
Один из способов управлять сроками — вести собственный форк. Команда сама решает, когда добавлять в него функции из апстрима или свои доработки, но ей же приходится сопровождать ветку.
Готовую платформу поставляет вендор. Он интегрирует компоненты, ведёт свою ветку, обеспечивает совместимость с российскими ОС и оборудованием и отвечает за сроки выпуска функций. Команда заказчика занимается эксплуатацией.
Разницу во времени первого запуска я оценивал на практике. Proxmox VE можно установить и собрать в кластер с хранилищем и сетью за два-три часа при минимальной настройке. ESXi устанавливается на хост за полчаса, но подготовка vSphere с vCenter, ролевой моделью, распределёнными коммутаторами и политиками занимает пару дней. Стенд OpenStack можно поднять за день, если хватает квалификации. Подготовить его к продакшну намного сложнее. Во всех случаях речь только о первом запуске, без настройки под нагрузку и последующей эксплуатации.
Поэтому Proxmox VE удобен там, где хостов около десятка и разница между двумя часами и двумя днями заметна. vSphere выбирали по другой причине: после нескольких дней подготовки платформа годами работала по единым процедурам и документации, независимо от того, кто из администраторов дежурил. Через год после запуска разница во времени установки уже не важна. Важнее, кто восстановит работу платформы при ночном сбое.
Что сравниваем | Сборка из компонентов | Готовая платформа с поддержкой |
Кто поддерживает интеграцию KVM, хранилища и сети | Ваша команда | Вендор |
Сроки появления функций | Зависят от апстрима | Фиксируются договором |
Кто выпускает патч безопасности | Вы сами из апстрима | Вендор, с SLA |
Совместимость с российскими ОС и оборудованием | Проверяете и поддерживаете сами | Входит в поставку |
Какая команда нужна | Выделенные инженеры по платформе | Инженеры эксплуатации |
Если выделенных инженеров по платформе нет, самостоятельная сборка добавит к миграции ещё один проект. В статье «25 лет на игле VMware» приведён пример, когда связка Open vSwitch и OVN вместо NSX обходится дороже готового продукта: экономию на лицензиях съедает оплата труда инженеров, которые её сопровождают.
На трудоёмкость влияет и срок миграции. Переезд инфраструктуры занимает год-полтора, поэтому осторожный выбор понятен: переплата вендору выглядит менее рискованной, чем недоступность продакшна после переезда. Когда срок задаёт чужой контракт, действовать приходится быстрее. Tesco планирует завершить переход к концу 2027 года. Ритейлер называет целевую альтернативу «with reduced functionality» — с меньшей функциональностью, а сроки перехода связывает с «very significant risks to its business» — очень значительными рисками для бизнеса.
При выборе между самостоятельной сборкой и готовой платформой стоит считать не время установки, а работу по интеграции и сопровождению на всём сроке миграции. Если график перехода определяет сама команда, несовместимость бэкапов можно выявить до выбора платформы, а не после начала переезда.
Регуляторный слой
Для регулируемых отраслей выбор платформы начинается с проверки формальных требований. Если продукт им не соответствует, сравнивать его функции уже нет смысла.
С 1 января 2025 года органам государственной власти и заказчикам запрещено использовать иностранное ПО на принадлежащих им значимых объектах КИИ — это пункт 2 Указа Президента № 166 от 30.03.2022. С 1 марта 2026 года для государственных систем действуют требования приказа ФСТЭК России № 117 от 11.04.2025, заменившие приказ № 17. На системы с персональными данными распространяется 152-ФЗ в действующей редакции; их аттестуют с учётом необходимого уровня защищённости.
Для государственных систем и части закупок продукт должен входить в реестр отечественного ПО, а программно-аппаратные комплексы — ещё и в реестр Минпромторга. VMware ESXi в этих реестрах нет. Если включение в реестр обязательно, без замены платформы требование не выполнить.
ГОСТ Р 56939-2024 предусматривает оценку процесса разработки, в том числе процедуры, для которых испытательной лаборатории нужен доступ к исходному коду. У платформы на открытой базе такой доступ можно обеспечить. Он нужен и при сертификации ФСТЭК по уровням доверия. Например, РЕД ОС от РЕД Софт прошла испытания в том числе по требованиям к средствам виртуализации и получила сертификат № 4060 по 4 классу защиты.
Если аттестация требуется на уровне инфраструктуры, можно использовать аттестованное облако. VK Secure Cloud работает на кодовой базе VK Cloud и российском оборудовании. Аттестат № 3740.00024.2026 подтверждает готовность к размещению государственных систем класса К1, систем персональных данных уровня УЗ-1 и значимых объектов КИИ до первой категории. Инфраструктурную часть аттестации мы берём на себя; заказчику остаётся прикладной уровень.
Для своей площадки доступен VK Private Cloud на той же кодовой базе, что и публичное облако. У продукта есть сертификат ФСТЭК № 4857 от 24.09.2024 по 4 уровню доверия и 4 классу защиты, а также запись № 6092 в реестре отечественного ПО от 13.01.2020. Это позволяет использовать платформу в государственных системах, на объектах КИИ, в АСУ ТП и системах персональных данных с максимальным уровнем защищённости. Есть и пример действующего проекта в регулируемой отрасли: Россельхозбанк переводит центральный офис и 64 региональных отделения на «РЕД Виртуализацию», один из форков oVirt.
Сертификат платформы, запись в реестре и применимость документов к своему классу систем нужно проверить до пилота. На сверку по документам достаточно одного дня; если отложить её до аттестации, несоответствие может обнаружиться уже после переноса машин.
Технический чек-лист миграции
Ниже — шесть последовательных этапов. Юридические вопросы в них не входят. Отдельно пересчитайте физические ядра с учётом минимума в 16 ядер на процессор по действующим правилам лицензирования. Владельцам бессрочных лицензий Broadcom рассылает письма о проверке лицензий.
1. Инвентаризация
Сначала считают нагрузки: на одном физическом сервере их могут быть десятки, поэтому объём проекта оценивают по нагрузкам, а не по числу серверов или стоек. Данные о парке выгружают через RVTools, затем группируют нагрузки по критичности и составляют карту зависимостей между машинами.
Длинные цепочки снапшотов увеличивают объём переносимых данных и затрудняют оценку времени конвертации: вместе с диском приходится читать все дельты. Лишние снапшоты удаляют или схлопывают за несколько дней до начала переноса.
2. Гостевые системы
В гостевые Windows-системы до переноса или сразу после него устанавливают virtio-драйверы диска и сети. Без них система работает с эмулируемыми устройствами, а дисковые операции выполняются кратно медленнее.
Для перехода на KVM понадобятся ещё два компонента. qemu-guest-agent позволяет корректно завершать работу гостевой системы, замораживать файловую систему перед снимком, менять пароль и сетевые настройки. cloud-init выполняет первичную настройку при запуске; без него не заработает автоматическое развёртывание из шаблонов. Оба компонента лучше включить в золотой образ до массового переноса, чтобы потом не устанавливать их на весь парк по отдельности.
Проверьте режим загрузки каждой машины — UEFI или BIOS — и состояние Secure Boot. Если на новой платформе загрузчик не найдёт нужные параметры, машина не запустится. Инструменты живой миграции вроде Hystax Acura или MIND могут автоматически адаптировать загрузчик к целевой платформе. При ручной конвертации через virt-v2v его работу проверяют на первой машине каждого типа.
Устаревшие гостевые системы учитывают отдельно. Для Windows NT и старых сборок Linux virtio-драйверов нет. Такие машины оставляют на исходной площадке до вывода из эксплуатации либо переносят в изолированный сегмент с эмулируемыми устройствами, принимая потерю производительности.
3. Конвертация дисков
Если машину можно остановить, для переноса достаточно virt-v2v и qemu-img: VMDK конвертируют в QCOW2 или RAW. Для критичных машин без окна простоя есть платные инструменты живого переноса — Hystax Acura и MIND.
Типы дисков проверяют отдельно:
Thin-диски при конвертации в RAW могут занять полный номинальный объём. Место на целевом хранилище считайте по нему, иначе его может не хватить.
Thick-диски конвертируются предсказуемо, но переносятся дольше: нужно прочитать весь номинальный объём.
RDM — проброшенные тома массива — стандартными конвертерами не переносятся. Для них выбирают отдельный сценарий: перенос данных на уровне приложения или прямое подключение тома к новому гипервизору.
4. Сеть
Политики NSX на новую платформу не переносятся. Микросегментацию придётся заново настроить на OVN или SDN целевой платформы. Назначьте ответственного и выделите время на эту работу. Матрицу разрешённых потоков составьте до пилота по фактическому трафику старой площадки.
5. Бэкапы и восстановление
Проверьте, поддерживает ли ваша бэкап-система CBT на целевой платформе и для каких форматов дисков. Для СУБД отдельно проверьте согласованность копии на уровне приложения. Копия, снятая без согласования с базой, может восстановить её в повреждённом состоянии. Гостевой агент без интеграции с СУБД прикладную согласованность не обеспечивает.
План аварийного восстановления придётся составить заново, как описано выше. Назначьте ответственного и установите периодичность тестовых прогонов: без них регламент быстро устареет.
6. Пилот и перенос
Пилот проводят на некритичных машинах, одновременно обучая команду. До переноса продакшна инженеры должны научиться самостоятельно разбирать инциденты, обнаруженные на пилоте, без помощи вендора.
Автобалансировку проверяют по четырём сценариям: первичное размещение машин планировщиком, перебалансировка по метрикам, группы афинности и эвакуация при выводе хоста в обслуживание. Если в парке есть процессоры разных поколений, отдельно проверяют живую миграцию между такими хостами.
Затем машины переносят поэтапно: сначала тестовые контуры, потом внутренние сервисы и продакшн. Исходную площадку сохраняют ещё три-шесть месяцев после последнего этапа как вариант для отката.
Критерии выбора платформы здесь не повторяются: класс решения, модель поддержки, совокупная стоимость владения и матрица сценариев разобраны в первой статье цикла. Здесь предполагается, что платформа уже выбрана и соответствует требованиям для вашего регуляторного класса.
Что делать с этим на практике
Основные риски связаны с семью из девяти направлений сравнения и пятью пунктами чек-листа миграции. Живая миграция, HA и управление через код доступны штатно. Часть рисков можно проверить по документации за один рабочий день, остальные требуют пилота.
Риск | Как снизить | Когда |
Бэкап не заработает на новой платформе | Проверить по документации, поддерживает ли ваша бэкап-система CBT на целевой платформе | До выбора платформы |
Микросегментация не переедет | Составить матрицу разрешённых потоков по фактическому трафику старой площадки | До пилота |
План аварийного восстановления не сработает | Заново описать порядок запуска и зависимости сервисов, установить регламент тестовых прогонов | До первого этапа |
Безагентной защиты не будет | Перейти на агентскую схему, разнести сканирования по времени и пересчитать плотность машин на хост | До пилота, вместе с ИБ |
Клонирование и развёртывание из шаблонов замедлятся | Пересчитать окна массовых операций с учётом нагрузки на хосты и сеть хранения | На пилоте |
Платформа не пройдёт аттестацию | Проверить сертификат ФСТЭК, запись в реестре и применимость к вашему классу систем | До пилота, один день по документам |
Windows-машины будут кратно медленнее работать с диском | Установить virtio-драйверы до переноса, проверить режим загрузки и Secure Boot | На этапе подготовки гостевых систем |
На целевом хранилище не хватит места | Считать thin-диски по номинальному объёму, заранее схлопнуть снапшоты | При инвентаризации |
Команда не справится с инцидентами | Допускать к переносу продакшна после того, как команда сама устранит инциденты пилота, без помощи вендора | По итогам пилота |
Балансировка не заработает | Отдельно проверить планировщик, метрики, группы афинности и эвакуацию | На пилоте |
Машины с vGPU не смогут мигрировать без остановки | Проверить версию OpenStack и драйверы NVIDIA до переноса GPU-нагрузок | На пилоте |
Не останется возможности откатиться | Сохранять исходную площадку три-шесть месяцев после последнего этапа | На протяжении проекта |
Я бы начал с регуляторных требований: их быстро проверить по документам, а несоответствие может сразу исключить платформу. Затем разобрал бы резервное копирование и аварийное восстановление — проблемы здесь способны остановить миграцию даже при большом бюджете. После этого занялся бы сетью: матрицу разрешённых потоков лучше составить по фактическому трафику до переноса, чем годами исправлять политики. Остальное проверяется на пилоте.
По разговорам с командами эксплуатации, проекты чаще срываются из-за сроков, чем из-за технических ограничений. Когда дату диктует чужой контракт, первыми из плана исчезают однодневные проверки, которые могли бы предотвратить задержку всего переезда.
Переезд без аврала
Виртуализацию долго покупали как готовый продукт: развернули, настроили, продлили поддержку. Последние два года показали, насколько эксплуатация зависит от решений поставщика. Он может не продлить поддержку работающей инфраструктуры, ограничить доступ к патчам условиями контракта или изменить состав продукта.
Главный вопрос при переезде — какие функции сохранятся, а какие придётся восстанавливать своими силами. Девять направлений сравнения помогают разобрать это до переноса: часть ответов есть в документации, остальные даст пилот на некритичных машинах. Когда платформа выбрана, эти проверки можно провести по своему графику.
Авральным переезд становится, если срок назначает поставщик. Tesco пришлось планировать миграцию 40 тысяч нагрузок после того, как Broadcom отказалась продлевать поддержку её инсталляций. Набор проверок от этого не меняется, но на каждую остаётся меньше времени.
