Привет, Хабр! Представьте: десять лет вы строили инфраструктуру на VMware. Миграции проходили гладко, кластеры работали стабильно — красота. Но привычная опора оказалась менее надежной, чем казалось. Старые версии VMware больше не поддерживаются, обновления безопасности не выходят, а новые лицензии не купить даже через параллельный импорт. И главный вопрос — что будет завтра? Сегодня западные вендоры меняют ценовую политику, а через год могут и вовсе отозвать лицензии.
Именно в такой ситуации сейчас оказались сотни российских компаний. Им приходится выбирать из десятков доступных решений, и первый порыв — открыть сравнительную таблицу, где напротив каждой функции VMware стоит галочка. Хочется сохранить привычную функциональность, да и сами российские вендоры позиционируют свои продукты как полноценную замену VMware. Но такой подход не работает: простое сравнение по набору функций редко дает точное представление о реальной альтернативе. И у Lada, и у BMW есть руль, но дьявол, как известно, в деталях.
В этом руководстве, основанном на реальном опыте внедрений, мы разберем оптимальный алгоритм подбора системы виртуализации.
Идеальный шторм
Поначалу переход на отечественные решения происходил в относительно спокойном режиме: часть компаний подталкивал к импортозамещению регулятор, остальные же, кого требования не затронули, особо не торопились. Но потом VMware взяла и сама обрушила собственную экосистему.
С чем столкнулись компании в России? Доступ к некогда привычным решениям лидеров рынка сильно усложнился: поддержка возможна только через обходные пути, прибегать к которым весьма рискованно, доступ к обновлениям ограничен, а некоторые поставщики еще и меняют условия обслуживания. В результате критически важное инфраструктурное ПО остается без развития и исправления уязвимостей — а это прямой риск для работы всей инфраструктуры.
Яркий пример — компания VMware, которая отказалась от бессрочных лицензий — теперь только подписка. Вместе с этим прекратила поддержку старых версий ПО. Но главное — сейчас софт требует соединения с глобальными серверами лицензирования.
Изменились условия — изменились приоритеты. Руководство VMware сформировало VIP-клуб из 600 крупнейших мировых клиентов и теперь ориентируется на них. Интересы остальных компаний это решение просто не учитывает. В итоге множество российских пользователей vSphere вынуждены в спешке выбирать новую систему виртуализации.
Открываем реестр Минцифры — там в разделе «Средства виртуализации» больше 200 наименований, но если говорить чисто про серверную виртуализацию, то можно начитать 92 продукта. «Живых» из них, по нашей оценке, около 30. А таких, которые формируют костяк рынка и имеют референсы реальных внедрений — еще меньше. Однако информации по ним часто не хватает и выбрать достаточно сложно.
Технологическая основа российских решений
На рынке сейчас три основных подхода к созданию систем виртуализации.
Первый подход — взять open-source решение и продавать к нему коммерческую поддержку. Звучит логично, но есть две серьезные проблемы. Во-первых, непонятно, как будет развиваться такой продукт — дорожная карта туманна. Во-вторых, неясно, кто отвечает за доработки, исправление багов и закрытие уязвимостей. Развивать продукт своими силами сложно и дорого. Перспективы такой модели выглядят сомнительно даже на ближайшие пару лет.
Второй подход — создать форк популярного open-source проекта и развивать его самостоятельно. Компании нанимают команды разработчиков, выстраивают стратегию и дорабатывают продукт под нужды российского заказчика. В итоге получается вполне конкурентоспособное решение.
Наиболее часто встречающиеся open-source решения, применяемые в российских системах виртуализации:
Системы на основе oVirt (к ним относятся такие платформы, как: zVirt, ROSA Virtualization, HostVM, «РЕД Виртуализация») подходят для классической инфраструктуры. Архитектурно чем-то схожи с VMware, но далеко не всем. Главное преимущество oVirt-based систем — многие, часто востребованные функции, например: подключение блочных систем хранения данных, динамическая балансировка вычислительных ресурсов, — работают «из коробки». RedHat, самый активный участник проекта oVirt, вышел из него. Российские компании тоже вносят свой вклад в поддержку проекта, но развивают свои собственные форки. Интересный подход реализовали в компании Orion soft: там создали собственный backend, работающий поверх решений проекта oVirt. Получилось сохранить совместимость с уже существующими разработками в рамках проекта, при этом значительно упростив и улучшив функциональность по отношению к разработкам сообщества.
Proxmox Virtual Environment набирает популярность благодаря простоте установки и использования. Российские форки PVE (например, «Альт Виртуализация», Glovirt) позволяют работать с привычным интерфейсом независимо от выбора конкретного решения. Проект активно развивается и получает все большую популярность. Например, только за прошедший год проект анонсировал поддержку SDN и выпустил первую версию Datacenter Manager (интерфейса централизованного управления несколькими инсталляциями PVE). Проект собрал вокруг себя большое сообщество, в том числе и русскоязычное.
OpenNebula архитектурно больше подходит для построения облачных систем. Системы на ее базе пользуются сравнительно низкой популярностью из-за сложности архитектуры, а также слабой, неполной англоязычной документацией. Тем не менее российские форки OpenNebula, например, Горизонт-ВС, ПК СВ «Брест», SharxDC, также активно развиваются.
OpenStack — большое модульное решение для широкого спектра задач. Решение хорошо масштабируется от задач, связанных с виртуализацией, до организации частного облака с IaaS-сервисами. Актуально для крупных энтерпрайз-заказчиков и провайдеров услуг с собственной командой поддержки и разработки. Система управления виртуализацией на базе OpenStack достойно проявляет себя в «Кибер Инфраструктуре». Осенью 2025 года сертификат ФСТЭК получила платформа AccentOS CE — решение полностью построено на базе OpenStack.
На российском рынке представлен единственный продукт на основе xcp-ng — Numa vServer. Те, кто хорошо знаком с Xen, могут перейти на российский аналог с привычным для себя функционалом.
Гиперконвергентная платформа vStack — продукт на основе freeBSD и bhyve. Многие посчитают его излишне экзотическим, но разработчики постарались сделать так, чтобы администраторы платформы не задумывались о «подкапотных» решениях.
Третий подход — собственная разработка. Хотя и здесь в основе обычно лежит стек из open-source компонентов, но тем не менее компаниям удается создать системы управления (например,VMmanager, SpaceVM, Basis Dynamix), которые действительно отличаются от других и опираются на собственные наработки.
Такие решения отличаются глубокой интеграцией с отечественными ОС и средствами защиты, автоматизацией и API-first подходом. Но в то же время требуют значительных усилий по оптимизации и настройке.
Как выбрать и не пожалеть
Если на этапе выбора открыть Excel и внести информацию по функциональности существующих на рынке решений, то получится вполне себе объемная сравнительная таблица. Такой артефакт можно использовать как первичный фильтр, но для полноценного выбора нужно применять более глубокий подход: галочка напротив «Поддержка функции X» ничего не говорит о том, как это работает на практике.
Возьмем простой пример: создание виртуальной машины. Эта опция есть у всех платформ. В VMware — это отлаженный процесс с понятными настройками. А в другом продукте те же действия могут оказаться квестом с редактированием конфигурационных файлов и чтением километров документации. Галочки в таблице одинаковые, а опыт использования — принципиально разный.
Поэтому отложим таблицы в сторону и воспользуемся более надежным инструментом — здравым смыслом и системным подходом.
Первый фильтр: выбор архитектуры
Первый вопрос — про архитектуру. На российском рынке соседствуют два подхода к ее построению, каждый со своими плюсами и минусами.
Классическая архитектура
В классической архитектуре каждая подсистема — вычисления, хранение, сеть — существует отдельно, но вместе они образуют отказоустойчивый кластер. Каждый компонент можно выбрать, заменить или настроить независимо от других. Подход проверен десятилетиями и доведен до промышленного уровня.
Кому подходит классика?
Прежде всего тем, у кого уже развернута зрелая инфраструктура и сделаны значительные вложения в оборудование. Скажем, стоит дорогая и любимая СХД, от которой не хочется отказываться. Достаточно добавить поверх слой виртуализации.
Классика подходит для больших централизованных инфраструктур с квалифицированной командой администраторов. Когда есть отдельные специалисты по сетям, СХД и серверам, и каждый может заниматься своим участком работы.
Еще один сценарий — когда нужна гибкость в масштабировании. Допустим, требуется увеличить только дисковое пространство, не меняя вычислительные мощности. Классическая архитектура позволяет масштабировать каждый слой отдельно.
Какие решения работают по классической модели?
«Базис Dynamix Standard», «РЕД Виртуализация», zVirt, SpaceVM, Rosa Virtualization, VMmanager, Numa vServer. Эти платформы наиболее заточены под классическую схему и хорошо интегрируются с внешними СХД.
Риски классической архитектуры
Конечно, у этой архитектуры есть недостатки.
У нее высокий CAPEX за счет высокой стоимости отдельных элементов архитектуры и необходимости в дорогих узких специалистах. А еще она капризна в диагностике: когда что-то «падает», бывает непонятно, где искать причину.
Иногда развертывание может затягиваться. Сначала заказываешь железо и софт, потом ждешь поставку, затем настраиваешь каждый компонент, далее интегрируешь все это в единую систему. Классическая архитектура построена из разных блоков, но все они должны дружить между собой внутри одной платформы виртуализации. Крупные компании, ИТ-ландшафт которых складывался на протяжении десятков лет и сейчас представляет собой сложную паутину систем, не могут «в лоб» заменить один элемент на аналог от другого производителя. Начинать нужно с глубокого аудита — оценить степень интеграции ПО в процессы и совместимость с другими решениями.
Гиперконвергентная инфраструктура (HCI)
В HCI вычислительные ресурсы, хранилище и сеть объединены в блоки (узлы), управляемые через единый интерфейс. Система хранения строится на базе локальных дисков серверов, объединенных в отказоустойчивый пул. Такая система разворачивается проще и быстрее.
Кому подходит HCI?
HCI выбирают компании, которые строят инфраструктуру с нуля и не готовы покупать дорогое оборудование по частям. Гиперконвергенция отлично подходит для филиалов и удаленных офисов без своих ИT-специалистов. Интегратор или головной офис ставит оборудование, устанавливает базовые параметры — дальше все работает само. Правда, о тонкой настройке отдельных компонентов можно забыть.
Еще один важный плюс — удобное масштабирование. Нужно больше ресурсов? Добавляете в кластер новый узел, и система автоматически распределяет нагрузку.
Какие решения поддерживают гиперконвергенцию?
vStack, «Кибер Инфраструктура», Р-платформа, Горизонт-ВС. Все они изначально построены на гиперконвергентном подходе.
Существуют решения, которые могут работать как с классической архитектурой, так и гиперконвергентной:
Например: «Кибер Инфраструктура» и Горизонт-ВС хоть и являются HCI решениями, но одна из функциональных возможностей — поддержка подключения блочных систем хранения, что позволяет выйти за рамки HCI. Или наоборот, решения, которые изначально заточены под классическую инфраструктуру, могут работать в HCI режиме: «Базис Dynamix Standard» и zVirt — за счёт ПО MIND uStore, «РЕД Виртуализация» — за счёт GlusterFS, SpaceVM — с помощью GFS, Rosa Virtualization — GlusterFS, Ceph, ZFS, VMmanager — на Ceph.
Риски гиперконвергентной архитектуры
При построении HCI архитектуры потребуется грамотная стратегия внедрения. Если такой подход изначально не заложен в инфраструктуру, то велики риски того, что существующие аппаратные мощности окажутся неоптимальными. Поэтому в первую очередь необходимо привести аппаратную инфраструктуру к единообразию.
Потребность в ресурсах хранения и вычислений не возникает одновременно: вероятно, предприятию сначала понадобится увеличить объем памяти, а уже потом наращивать вычислительные мощности. И это может стать проблемой для дальнейшего вертикального масштабирования: придется наращивать ресурсы для всего кластера целиком, а не для единичного узла. В результате затраты на масштабирование могут существенно увеличиться.
При эксплуатации требуется более бдительно следить за состоянием элементов HCI инфраструктуры. Несмотря на то, что концепция HCI подразумевает предсказуемую отказоустойчивость, некорректная работа одного или нескольких элементов может существенно влиять на производительность всего кластера.
Второй фильтр: вопросы безопасности
Следующая развилка уже не техническая, а юридическая: нужна ли системе сертификация ФСТЭК или ФСБ?
Сертификат получают те решения, которые выполняют комплекс требований безопасности. Например, их гипервизор должен использовать аппаратную виртуализацию, а виртуальные машины могут работать по мандатной модели.
Если сертификация обязательна
Для компаний из госсектора, тех, кто обрабатывает персональные данные, или объектов критической информационной инфраструктуры, сертификация обязательна. Без нее систему просто не примут в эксплуатацию. Если это ваш случай, выбор резко сужается. Остаются только решения, которые прошли сложную процедуру получения сертификата. Мы делали подробный обзор российских платформ виртуализации с ��ертификатом ФСТЭК. В некоторых случаях можно использовать средства защиты информации (СЗИ), такие как Dallas lock ВИ от компании «Конфидент» или vGate от компании «Код Безопасности».
При выборе уточните требуемый уровень доверия: сертификаты различаются по классу защищенности. Например, Горизонт-ВС — ориентирован на объекты с высшими классами защиты — силовые ведомства, предприятия ОПК. На момент публикации статьи у продукта нет действующего сертификата ФСТЭК: вендор проходит сертификацию по новым требованиям и планирует получить обновлённый сертификат в начале 2026 года.
Numa vServer позиционируется как более открытая и гибкая альтернатива на базе модифицированного гипервизора Xen собвененной доработки. В рамках своей экосистемы хорошо интегрируется с СЗИ. Numa vServer применяется в банках, госкомпаниях, предприятиях ГИС (государственных информационных систем). Она будет наиболее близка тем, кто эксплуатирует Hyper-V, так как технологически платформы очень схожи.
ROSA Virtualization применяют для создания защищенных инфраструктур. Глубокая доработка по ИБ является сильной стороной решения.
В вашем распоряжении также будут Basis DynamiX, VMManager, zVirt Max с сертификацией третьего уровня доверия ФСТЭК.
Сертификация не нужна
В таком случае можно рассматривать все доступные решения, основываясь на технических и экономических характеристиках. Однако имейте в виду, что система виртуализации — это инвестиция минимум на 5–7 лет. За это время многое может измениться, например, компания подпадет под требования КИИ или ЗОКИИ, ужесточится законодательство или просто появятся новые задачи. Все это стоит учитывать уже на этапе проектирования, чтобы потом лишний раз не перепроектировать инфраструктуру.
Третий фильтр: гибкая инфраструктура
Если разработчики каждый день просят новые тестовые окружения, DevOps-команда автоматизирует развертывание через код, а в продакшене крутятся десятки микросервисов в контейнерах, то виртуализация должна стать фундаментом для этих практик. Потребуются API для автоматизации, интеграция с Kubernetes, гибкое управление сетями и хранилищами. В таком случае стоит присмотреться к платформам с расширенной функциональностью:
zVirt. Среди российских решений у zVirt на данный момент один из самых богатых наборов функций: распределенные виртуальные коммутаторы и SDN, миграция хранилищ на лету (Storage vMotion), автоматическое распределение ресурсов как в DRS, модули DR и миграции. Платформа подойдет как крупным предприятиям со сложной legacy-инфраструктурой на VMware, которым нужна максимально похожая замена, так и для организаций с динамической микросервисной инфраструктурой.
SpaceVM делает упор на производительность и функциональность. Платформа поддерживает виртуализацию GPU — это важно для графических рабочих станций. SpaceVM выбирают те, кому нужна максимально функциональная платформа, например: разработчики, инженеры-конструкторы, которые работают в САПР, а также компании с VDI-инфраструктурами.
Basis DynamiX — богатая функциональная платформа, которая может расширяться за счёт большого портфеля экосистемы «Базиса». Обновления, репозиторий, служба поддержки — все работает как единая система. Это идеальный вариант для полностью отечественных программно-аппаратных комплексов. Базис востребован в госсекторе и среди заказчиков с крупной инфраструктурой.
Deckhouse Virtualization Platform от вендора «Флант» построена на технологии KubeVirt (расширение для Kubernetes, которое позволяет запускать обычные виртуальные машины внутри кластера Kubernetes, используя те же механизмы оркестрации, что и для контейнеров). Платформа подойдёт и компаниям с гибридной архитектурой (классическая виртуализация и микросервисы), и тем, кто уже использует DevOps практики для управления инфраструктурой.
Четвертый фильтр: готовый ПАК
Последний вопрос перед финальным выбором: «Готовы ли вы самостоятельно подбирать и интегрировать компоненты или хотите получить готовое решение?»
Нужен готовый ПАК
При ограниченном времени и ресурсах больше подойдет готовый программно-аппаратный комплекс.
В этом случае обратите внимание на машины виртуализации «Скала^р МВ» от одного из самых известных на рынке производителей ПАК. ПАКи «Аквариус» тип Z/Z Max довольны просты в развертывании и эксплуатации. «Звезда» от Норбит ориентирована на госсектор с предустановленными средствами защиты информации.
ПАК дает предсказуемую совместимость всех компонентов. Он быстро разворачивается. Поддержку обеспечивает один вендор, а не десять разных. Часто в комплекте уже стоят операционная система и СЗИ.
В российских программно-аппаратных комплексах нет жесткой привязки к конкретному железу, какая была у западных вендоров. Там совместимость прошивалась на уровне отдельных компонентов — замени часть оборудования на модель другого производителя, и система может отказаться работать. У нас такой вендорлок практически отсутствует, что дает заказчикам больше свободы в выборе оборудования.
ПАК не нужен
Этот путь для команд с опытными инженерами, к тому же имеющими достаточно времени на интеграцию.
У вас уже есть оборудование или строгие требования к железу.
Хотите выжать максимум из каждого компонента под конкретные задачи.
Планируете нестандартную архитектуру — например, гибридную с разными типами хранилищ.
В таком случае берите любое решение из предыдущих категорий. Платформу виртуализации покупаете отдельно, железо отдельно, интегрируете своими силами или через партнера-интегратора. Но помните: разворачивать такое решение дольше и сложнее. Потребуется время на тестирование совместимости, настройку и отладку.
Часто возникающие проблемы при внедрении решений
Проблемы с сетями агрегации каналов. При переходе на российские решения приходится учитывать и возможности сетевой архитектуры. Агрегация сетевых интерфейсов на российских платформах виртуализации работает чуть иначе, чем на той же VMware.
Неоптимальный выбор архитектуры. При этом не учитываются ограничения решений: сетей, vlan-ов, количество подключений, ограничения при работе в СХД и т.п. — все, что связано с проектированием.
Проблемы при масштабировании на крупных инсталляциях решения могут вести себя иначе и выявляются дополнительные ограничения.
Сложности при интеграции со смежными системами — службами каталогов, системами мониторинга и резервного копирования: требуется корректная настройка защищенных протоколов, учет особенностей интеграции и нюансов работы СРК. При этом не нужно забывать, что специализированные плагины и appliance, ориентированные на VMware, на российских решениях работать не будут.
Иногда выявляются проблемы, которые не были выявлены на этапе пилотирования или самим вендором. Важным фактором остается скорость и качество реакции вендора на такие проблемы — оперативное решение под конкретного заказчика или внесение задачи в план развития продукта. Далеко не каждый вендор обладает обширной базой знаний по решению проблем.
Алгоритм принятия решения
После этих четырех фильтров у вас останется короткий список из нескольких кандидатов. Теперь можно углубляться в детали, но делать это нужно правильно.
Проанализируйте текущую инфраструктуру самостоятельно или с помощью интегратора. Составьте честный список того, что реально используете. DRS, vMotion, High Availability, репликация, распределенный коммутатор — обычно компании задействуют не больше половины возможностей купленной лицензии. Этот список станет основой для критичных требований к новому решению.
Теперь загляните в будущее. Собираетесь переходить на микросервисную архитектуру? Понадобятся контейнеры и Kubernetes? Насколько хорошо кандидат интегрируется с этими технологиями? Инфраструктура будет расти — как выглядит масштабирование у выбранного решения? Планируете гибридную инфраструктуру, которая свяжет частное облако с публичным? Ответы на эти вопросы помогут сделать правильный выбор в долгосрочной перспективе.
Сформулируйте критерии для сравнения оставшихся решений: функциональные и нефункциональные требования, потребности информационной безопасности. Оцените критичность каждого критерия.
Теперь можно пойти двумя путями. Первый — обратиться к интегратору со списком потребностей. Второй — выбрать платформу виртуализации самостоятельно на основе рекомендаций коллег или изучения доступной документации. Обратите внимание, что при интеграции любого решения всегда возникает ряд технических проблем, которые требуется быстро устранить.
Проверьте выбранные решения в деле. Тестировать можно своими силами, с помощью вендора, интегратора или совместно. Да, можно довериться чужому опыту и пропустить этап тестирования. Но гораздо надежнее попробовать самому и составить собственное мнение — так вы точно поймете, подходит ли вам продукт, и заодно оцените качество технической поддержки.
Оцените работу техподдержки и возможность быстрого устранения проблем (доработки — немаловажный критерий, когда техподдержка может подключиться оперативно и доработать код, не дожидаясь выхода нового релиза).
Изучите роадмап: оцените направление и скорость развития выбранных систем.
Посчитайте стоимость планируемых изменений и убедитесь, что инвестиция оправдана.
И наконец, ответьте на последний вопрос: внедрять своими силами или привлечь интегратора?
Небольшую инфраструктуру — до 50 виртуальных машин — можно поднять своими силами. Главное, чтобы у вас была крепкая команда системных администраторов с опытом в Linux, а выбранное решение имело понятную документацию и живое сообщество. Но с крупными проектами все сложнее — там без помощи партнера обычно не обойтись.
Интегратор понадобится, если у вас критичная инфраструктура, где простой бьет по бизнесу — банки, ритейл, производство. Или когда ваши администраторы по уши загружены текущими задачами и не могут неделями вникать в новую платформу. Еще одна частая ситуация — миграция с VMware: нужно перенести все с сохранением настроек и конфигураций, прикрутить к существующим системам мониторинга, бэкапа и СЗИ. А если сроки горят и внедрить нужно было вчера, а платформа выбрана сложная, с кучей компонентов, то вопрос о целесообразности ИТ-партнера вообще не стоит.
Хороший интегратор проектирует архитектуру под ваши конкретные задачи. Специалисты разберутся в инфраструктуре, поймут бизнес-процессы и спроектируют решение с учетом планов развития. Они знают, что драйвер вашей модели СХД конфликтует с этой версией гипервизора, что перед миграцией Windows-машин нужно обязательно снести VMware Tools, иначе все зависнет. Они составят детальный план с возможностью отката, проведут тестовые прогоны, организуют ночные окна для переноса критичных сервисов. Кроме того, в такие проекты, как правило, входит этап обучения и адаптации сотрудников и подготовки справочной документации.
Если что-то пойдет не так, ИТ-партнер берет на себя ответственность за все, что зафиксировано в договоре, в противном случае — риски и затраты лягут на компанию, которая решилась на самостоятельное внедрение, не убедившись в наличии должных ресурсов и компетенций.
Отечественные игроки активно стремятся заменить ушедшие с российского рынка зарубежные продукты, но получается у всех по-разному. На сегодняшний день выбор российского решения — это зачастую компромисс, но в ближайшие два-три года функциональность российских решений вырастет и сравняется с зарубежными аналогами. Тогда выбирать по функциональным возможностям станет сложнее.
Заказчики начнут опираться на накопившийся опыт уже внедренных решений и выбирать тех, кто хорошо зарекомендовал себя на рынке. На этом этапе список решений может сократиться с пятнадцати до пяти-семи наиболее эффективных. Если, конечно, экономика позволит.
Что подойдет именно вам, зависит от текущей архитектуры, от того, что требуют регуляторы, размера команды администраторов и, самое главное — планов на будущее. Но в любом случае миграция с одной платформы виртуализации на другую — сложный процесс, и выбирая платформу сегодня, вы определяете свою инфраструктуру на 5-7 лет вперед. Поэтому важно не промахнуться и не взять то, что через пару лет окажется не нужным. Мы уже сталкиваемся с компаниями, которые хотят мигрировать с одного российского решения на другое. Надеемся, эта статья поможет сделать правильный выбор.
А как у вас проходит переход? С какими сложностями и подводными камнями столкнулись при миграции с VMware? Делитесь опытом в комментариях.
