Ловушка VMware Exit: почему миграция рушит безопасность данных

Покупка VMware гигантом Broadcom спровоцировала крупнейшую в истории миграцию корпоративных дата-центров. По данным обзоров ИТ-рынка, более 60% крупных предприятий уже запланировали или запустили процесс перехода на альтернативные гипервизоры (Proxmox VE, OpenStack, VergeOS или платформы на базе KVM). Однако ИТ-директора совершают критическую ошибку, воспринимая «VMware Exit» как простую замену программного слоя compute.

Инфраструктура резервного копирования и катастрофоустойчивости последних 15 лет создавалась строго под vSphere и её закрытые API. Попытка перенести старые бэкап-скрипты и логику репликации в новую среду без изменения архитектуры превращает ИТ-контур в бомбу замедленного действия.

Как vSphere разбаловала индустрию бэкапов

Резервное копирование виртуальных машин в среде VMware десятилетиями работало по принципу «нажал и забыл» благодаря двум технологиям: CBT (Changed Block Tracking) и глубоко оптимизированным снапшотам хранилищ. CBT мгновенно передавал бэкап-софту (например, Veeam) карту изменившихся блоков данных с момента последней копии. Это сокращало «окно бэкапа» для терабайтных серверов до нескольких минут.

При переходе на KVM-системы ИТ-команды сталкиваются с суровой реальностью:

• Проблема «шторма снапшотов»: В VMware удаление снапшота тяжелой виртуалки с базой данных проходит почти бесследно для дисковой полки. В стандартном KVM во время коммита (слияния) снапшота нагрузка на IOPS возрастает в 3–5 раз, что может намертво заморозить продуктивные сервисы на 20–40 секунд.
• Нестабильный инкремент: Далеко не все альтернативные платформы имеют нативный аналог CBT. Использование открытых механизмов вроде QEMU dirty bitmaps требует тонкой настройки. Если отслеживание блоков сбоит, система падает в full backup — вместо 50 ГБ инкремента она начинает качать все 5 ТБ диска, парализуя сеть дата-центра.
• Закрытие SDK: Ситуация усугубляется тем, что Broadcom ограничила доступ к VDDK (Virtual Disk Development Kit). Разработчикам стороннего бэкап-софта стало сложнее легально и быстро извлекать данные из vSphere для прямой миграции.

Архитектурный пирог против единого кода (Single Code Base)

В классической инфраструктуре VMware стек технологий напоминает слоеный пирог: вычисления управляются через vCenter, сеть — через NSX, диски — через vSAN, а бэкапом занимается сторонний софт. Во время создания резервной копии СУБД или векторной базы данных для ИИ-моделей происходит сложная цепочка согласований (Quiescing) между четырьмя разными API. В гетерогенной среде (когда часть инфраструктуры уже ушла на KVM, а часть осталась на vSphere) эта цепочка рвется. Векторные базы данных объемом более 10 ТБ при такой архитектуре восстановить со 100% консистентностью становится практически невозможно.

В качестве альтернативы на рынке вырос подход Single Code Base (яркий пример — VergeOS, упомянутый в партнерских материалах The Register). Здесь compute, storage, network и data protection объединены внутри одного программного ядра. Вместо разрозненных API-запросов между виртуализацией и бэкап-сервером, система делает мгновенные глобальные снимки на уровне хранилища каждые 5–10 минут без деградации производительности дисков. Это исключает микро-сбои синхронизации и гарантирует, что при аварии данные не откатятся на сутки назад.

Экономика «In-Place» миграции в эпоху дефицита железа

Попытка построить рядом новый дата-центр на альтернативном гипервизоре и перелить туда данные упирается в жесткий финансовый тупик. Рост цен на серверные комплектующие (особенно на оперативную память DDR5 и корпоративные NAND-флэш накопители) увеличил стоимость модернизации инфраструктуры в среднем на 45–60%. Закупать новые стойки серверов только ради смены софта VMware на Proxmox или OpenStack экономически нецелесообразно.

ИТ-архитекторы вынуждены переходить к стратегии In-Place Exit (миграция на существующем железе). Для этого используются софтверно-определяемые хранилища (SDS) с поддержкой вложенной избыточности (например, аналогов RAID на уровне узлов или технологий ioGuardian):

1. Из существующего кластера VMware выводится один сервер (нода).
2. На него устанавливается целевая ОС гипервизора.
3. Туда мигрирует первая группа виртуальных машин со сжатием данных (inline deduplication), что освобождает место на остальных узлах.
4. Процесс повторяется циклически (Node-at-a-time refresh).

Такой подход требует, чтобы новая платформа виртуализации умела на лету «переваривать» разнородные диски и процессоры прошлых поколений, обеспечивая при этом сквозное шифрование резервных копий для защиты от вирусов-вымогателей (Ransomware Resiliency).

Аудит безопасности перед VMware Exit

Прежде чем инициировать миграцию и подписывать отказ от лицензий VMware, инфраструктура должна быть проверена по трем жестким метрикам:

• Тест на RTO/RPO под пиковой нагрузкой: Какова реальная скорость восстановления виртуальной машины объемом 2 ТБ из бэкапа в новом гипервизоре? Если в vSphere это занимало 12 минут, то на KVM без оптимизации драйверов VirtIO процесс может растянуться на 2,5 часа.
• Изоляция Control Plane: Имеет ли новая система резервного копирования выделенный сетевой контур, недоступный из основной панели управления виртуализацией? При компрометации административного пароля к новому гипервизору злоумышленники не должны иметь возможности удалить бэкапы.
• Аппаратная утилизация: Сколько процессорного времени (CPU циклов) и оперативной памяти будет забирать бэкап-агент на новой платформе? В vSphere этот показатель редко превышал 3-5%, в то время как open-source агенты без тонкой настройки могут утилизировать до 25% мощности хоста в момент сжатия данных.