Миграция с VMware на российские платформы: на что переходить и как

Уход VMware с российского рынка превратил привычную инфраструктуру в зону риска: лицензии не продлеваются, критические обновления безопасности недоступны, а поддержки больше нет. Для компаний, у которых вся виртуализация построена на vSphere, это не абстрактная новость, а конкретная задача — на что и как мигрировать, чтобы не потерять данные и не остановить бизнес. В этой статье разберём, какие российские платформы заменяют VMware, как выбрать подходящую и как пройти миграцию без простоя.

Материал подготовлен специалистами КРЕДО-С — системного интегратора с лицензиями ФСТЭК России и опытом построения виртуальной инфраструктуры с 1993 года. Мы внедряем российские платформы виртуализации и ведём миграцию с VMware, поэтому делимся практикой, а не теорией.

Почему пришлось уходить с VMware

VMware десятилетиями была отраслевым стандартом виртуализации, и большинство российских компаний строили инфраструктуру именно на ней — vSphere, ESXi, vCenter. После ухода вендора с рынка ситуация изменилась радикально:

• Лицензии не продлеваются. Купить или продлить подписку легально невозможно, а работа на просроченных лицензиях — юридический и операционный риск.
• Обновления безопасности недоступны. Новые уязвимости гипервизора не закрываются. Каждый месяц без патчей увеличивает поверхность атаки — а гипервизор управляет всеми виртуальными машинами разом.
• Поддержка прекращена. При сбое или инциденте обращаться некуда. Компания остаётся один на один с критичной инфраструктурой.
• Требования импортозамещения. Для госзаказчиков и объектов критической информационной инфраструктуры (КИИ) переход на решения из реестра отечественного ПО закреплён законодательно.

Главная ошибка — откладывать миграцию «пока работает». Инфраструктура действительно продолжает работать, но риск накапливается: устаревший гипервизор без обновлений становится самым уязвимым звеном. А вынужденный экстренный переход после инцидента всегда дороже и болезненнее планового. Поэтому миграцию выгоднее провести заранее, в спокойном режиме.

Российские альтернативы VMware: на что переходить

Хорошая новость в том, что зрелые российские платформы виртуализации уже существуют и закрывают задачи корпоративного уровня. Разберём основные варианты из реестра отечественного ПО.

РЕД Виртуализация

Платформа от РЕД СОФТ корпоративного уровня. Поддерживает кластеры высокой доступности, централизованное управление виртуальными машинами, живую миграцию и резервное копирование. Ориентирована на госсектор и крупный бизнес, где важны сертификация и коммерческая поддержка. Входит в реестр отечественного ПО.

zVirt

Платформа от Orion soft, спроектированная как прямая замена VMware vSphere. Закрывает управление виртуальными машинами, отказоустойчивость, миграцию нагрузок. Удобна компаниям, которые ищут максимально близкий к vSphere функционал и сценарии работы.

Proxmox VE

Открытая платформа виртуализации. Подходит для гибких сценариев и проектов с ограниченным бюджетом, поддерживает кластеры, контейнеры и виртуальные машины. Не требует лицензии, но для бизнес-критичных систем рекомендуется коммерческая подписка на поддержку.

Альт Виртуализация

Решение на базе российской операционной системы Альт для виртуализации серверов. Логичный выбор, когда компания уже строит инфраструктуру на экосистеме Альт и хочет единый стек отечественного ПО.

Сравнение платформ

Универсального «лучшего» решения нет — выбор зависит от ваших систем, требований к сертификации и бюджета. Одной компании важнее максимальная близость к привычному vSphere, другой — сертификат ФСТЭК для объекта КИИ, третьей — экономия на лицензиях при гибком бюджете. Поэтому платформу подбирают не по популярности, а под конкретную инфраструктуру и задачи. Дальше разберём, как выбрать осознанно.

Как выбрать платформу под свои задачи

Подбор платформы — это инженерный анализ, а не выбор по названию. Что учитывать:

• Требования к сертификации. Для госзаказчиков и объектов КИИ платформа должна быть в реестре отечественного ПО, иногда с сертификатом ФСТЭК. Это сразу сужает выбор до сертифицированных решений.
• Близость к привычному vSphere. Если у администраторов большой опыт работы с VMware, платформа с похожей логикой управления сократит время на переобучение.
• Поддержка нужных функций. Отказоустойчивые кластеры, живая миграция, интеграция с системами резервного копирования и хранения — проверьте, что критичные для вас возможности есть.
• Бюджет. Коммерческие платформы лицензируются по хостам или процессорам; открытые решения экономят на лицензиях, но требуют более квалифицированной поддержки.
• Совместимость с оборудованием и СХД. Платформа должна работать с вашими серверами и системами хранения — это проверяется на этапе пилота.

На практике мы рекомендуем перед закупкой лицензий протестировать выбранную платформу на реальных нагрузках компании. Пилотное развёртывание показывает производительность и совместимость до того, как принято окончательное решение.

Этапы миграции с VMware без простоя

Переход с vSphere пугает компании больше всего: на нём работают боевые системы, остановить которые нельзя. Поэтому миграцию с VMware мы ведём как управляемый проект с обратимыми шагами, а не «в одну ночь».

1. Инвентаризация виртуальной среды. Фиксируем все виртуальные машины, их ресурсы, зависимости и сетевые связи. Определяем, что критично, а что можно перенести в первую очередь без риска для бизнеса. 2. Развёртывание целевой платформы. Поднимаем РЕД Виртуализацию, zVirt или другую выбранную платформу параллельно с действующей VMware. Старая среда продолжает работать, пока новая готовится и проверяется. 3. Пилотная миграция. Переносим несколько некритичных виртуальных машин, проверяем производительность, сеть, резервное копирование. Убеждаемся, что всё работает корректно, до переноса боевых систем. 4. Перенос виртуальных машин (V2V). Конвертируем виртуальные машины из формата VMware в формат новой платформы с сохранением операционной системы, настроек и данных. Боевые системы переносим в согласованные технологические окна с минимальным простоем. 5. Проверка и переключение. После переноса проверяем целостность данных и работу приложений, переключаем пользователей. Оставляем возможность отката, пока новая среда не стабилизируется. 6. Вывод VMware и обучение. Освобождаем лицензии и оборудование vSphere, обучаем администраторов работе с новой платформой, передаём документацию.

Ключевой принцип — параллельная работа старой и новой среды. Пока боевые системы крутятся на VMware, новая платформа разворачивается и обкатывается рядом. Это исключает сценарий «перенесли и всё сломалось»: на каждом этапе есть точка проверки и возможность вернуться назад.

Спланируем миграцию без простоя. Проведём аудит вашей VMware-инфраструктуры, подберём российскую платформу и составим план переноса с понятными сроками. Заказать аудит готовности к миграции — бесплатно.

Что такое V2V и почему миграция не «копирование»

V2V (Virtual-to-Virtual) — это перенос виртуальной машины из одного формата виртуализации в другой. VMware хранит виртуальные машины в своих форматах дисков и конфигураций, и просто скопировать файлы на другую платформу не получится — их нужно конвертировать.

При конвертации важно сохранить три вещи: операционную систему со всеми настройками, данные приложений и сетевую конфигурацию. Отдельное внимание — драйверам и агентам гостевой ОС: после переноса на новую платформу часть из них нужно заменить, чтобы виртуальная машина корректно работала с новым гипервизором. Именно поэтому миграцию проходят с проверкой каждой системы, а не пакетным копированием всех машин разом.

Риски миграции и как их избежать

Миграция инфраструктуры — ответственный процесс, но предсказуемые риски снимаются правильной подготовкой:

• Потеря данных при переносе. Снимается резервным копированием перед миграцией каждой машины и проверкой целостности после конвертации. Если что-то пошло не так — откатываемся к копии.
• Простой критичных систем. Снимается параллельной работой сред и переносом в технологические окна. Бизнес-критичные системы мигрируют в последнюю очередь, когда платформа уже обкатана.
• Несовместимость приложений. Снимается пилотной миграцией: проблемы выявляются на некритичных машинах до переноса боевых.
• Падение производительности. Снимается правильным расчётом ресурсов новой платформы и тестированием на реальных нагрузках до закупки лицензий.
• Нехватка компетенций у команды. Снимается обучением администраторов и сопровождением на старте — мы передаём знания, а не оставляем заказчика один на один с новой платформой.

Отдельно стоит спланировать порядок миграции. Сначала переносят тестовые и некритичные системы, убеждаются в стабильности, и только потом — бизнес-критичные. Такой поэтапный подход даёт команде время освоить новую платформу и снижает риск до минимума.

Чек-лист подготовки к миграции

Прежде чем начинать перенос, стоит подготовиться. Этот чек-лист помогает не упустить важное:

• Инвентаризация виртуальных машин. Полный список ВМ с их ресурсами (процессор, память, диск), ролями и критичностью для бизнеса.
• Карта зависимостей. Какие системы связаны между собой — чтобы не перенести базу данных отдельно от приложения, которое к ней обращается.
• Резервные копии. Актуальные и проверенные резервные копии всех машин перед стартом миграции — это страховка на случай отката.
• Окна для переноса. Согласованное с бизнесом время, когда критичные системы можно переключать с минимальным влиянием на работу.
• Целевая платформа выбрана и протестирована. Решение о платформе принято, пилот пройден, производительность подтверждена на реальных нагрузках.
• План отката. Понятный порядок действий, если перенос конкретной системы пошёл не так — куда и как возвращаемся.
• Готовность команды. Администраторы знакомы с новой платформой или есть сопровождение от подрядчика на переходный период.

Чем тщательнее подготовка, тем спокойнее проходит сама миграция. Большинство проблем переноса — это не технические сбои, а недостаток подготовки: незамеченная зависимость, отсутствие свежей копии, неверно оценённые ресурсы.

Частые ошибки при миграции с VMware

На практике компании, которые мигрируют самостоятельно и впервые, наступают на одни и те же грабли:

• Миграция «в одну ночь». Попытка перенести всё разом без пилота и параллельной работы сред. При первой же проблеме остановить нечего, а откатываться некуда.
• Перенос без свежих копий. «Машина небольшая, и так перенесётся» — пока не повредятся данные при конвертации. Резервная копия перед переносом обязательна для каждой системы.
• Игнор зависимостей. Перенесли приложение, а база осталась на старой платформе — или наоборот. Системы перестают видеть друг друга.
• Недооценка ресурсов. Новую платформу развернули «впритык», и под нагрузкой производительность просела. Ресурсы рассчитываются с запасом по реальной загрузке.
• Забытые драйверы и агенты. После V2V гостевая ОС работает нестабильно, потому что не заменены драйверы под новый гипервизор.
• Нет обучения команды. Платформу внедрили, а администраторы не умеют её обслуживать — и при первом сбое теряются.

Каждую из этих ошибок снимает грамотное планирование и поэтапный подход. Поэтому компании, для которых инфраструктура критична, чаще доверяют миграцию интегратору с опытом таких переходов, а не проходят её методом проб и ошибок на боевых системах.

Лицензирование и реестр отечественного ПО

Для государственных заказчиков и компаний с объектами КИИ важен не сам факт перехода, а соответствие требованиям. Платформа виртуализации должна входить в реестр российского ПО Минпромторга, а для ряда систем — иметь сертификат ФСТЭК.

РЕД Виртуализация и zVirt входят в реестр отечественного ПО, что закрывает формальные требования импортозамещения для госзакупок по 44-ФЗ и 223-ФЗ. При подготовке спецификации мы помогаем подобрать платформу так, чтобы она проходила по требованиям регуляторов, а не только по техническим параметрам.

Модель лицензирования зависит от платформы. Коммерческие решения лицензируются по числу хостов или физических процессоров — стоимость растёт с размером кластера. Открытые платформы вроде Proxmox не требуют лицензий, но для бизнес-критичной инфраструктуры мы рекомендуем коммерческую подписку на поддержку: при сбое важно иметь, к кому обратиться.

Сколько стоит и сколько занимает переход

Стоимость миграции складывается из лицензий новой платформы, работ по проектированию и переносу, а при необходимости — нового оборудования. Она зависит от числа физических серверов и виртуальных машин, выбранной платформы и модели лицензирования, требований к отказоустойчивости и объёма миграции.

Сроки зависят от масштаба. Аудит и проектирование занимают от двух недель, развёртывание платформы и пилот — ещё несколько недель, перенос боевых систем — в согласованные окна, чтобы не останавливать работу. Критичные объекты мигрируют поэтапно: базовая инфраструктура запускается раньше, а перенос остальных систем идёт по графику.

Точную оценку даём после аудита текущей инфраструктуры — он показывает реальный объём виртуальных машин, их зависимости и требования к ресурсам. На основе аудита формируем план миграции с понятными сроками и стоимостью.

Миграция как часть импортозамещения

Виртуализация редко мигрирует в одиночку. Чаще это часть более широкого перехода на отечественные технологии — операционные системы, базы данных, почтовые и офисные сервисы. Если компания замещает не только гипервизор, имеет смысл планировать переход комплексно, чтобы платформы были совместимы между собой.

Виртуализация при этом — фундамент, на котором работает остальная инфраструктура. Поэтому миграцию гипервизора логично увязать с резервным копированием виртуальных машин, системами хранения данных и сетью. Если замещаете и другое программное обеспечение, рассмотрите импортозамещение ПО комплексно. Когда всё спроектировано вместе, новая инфраструктура работает предсказуемо, без узких мест и несовместимостей. А сопровождение новой платформы можно передать на ИТ-аутсорсинг, чтобы за инфраструктуру отвечала одна команда.

Что в итоге

Уход VMware — это не катастрофа, а управляемая задача. Российские платформы виртуализации уже закрывают корпоративные сценарии, а грамотно спланированная миграция проходит без потери данных и с минимальным простоем. Главное — не откладывать переход «на потом»: плановая миграция в спокойном режиме всегда дешевле и безопаснее экстренной.

Если перед вами стоит задача уйти с VMware, начните с аудита: он покажет, что и в каком порядке переносить, какая платформа подойдёт под ваши системы и бюджет. Дальше — пилот, поэтапный перенос и вывод старой инфраструктуры.

Миграция — хороший момент, чтобы пересмотреть инфраструктуру целиком: часто вместе с заменой гипервизора компании обновляют серверы и хранение, закладывают отказоустойчивость, которой не было раньше. Если планируете не просто перенос, а развитие инфраструктуры, имеет смысл рассмотреть проектирование ИТ-инфраструктуры под ключ — тогда новая виртуальная среда строится не «как было», а с запасом на рост и с продуманной отказоустойчивостью. А чтобы новая платформа стабильно работала после запуска, её обслуживание можно передать на техническую поддержку или полный ИТ-аутсорсинг.