Российские платформы виртуализации 2026
Заказчики пересматривают выбор платформ виртуализации
Срочный поиск замены VMware на российском рынке постепенно уступает сравнению зрелости отечественных платформ. Заказчики оценивают управление виртуальными машинами, сетями и хранилищами, отказоустойчивость, миграцию, безопасность, совместимость с контейнерными средами и качество сопровождения. Новый выбор нередко становится проверкой результатов первой волны импортозамещения и заделом для развития инфраструктуры на несколько лет.
Компании оценивают результаты первой волны импортозамещения
К 2026 г. внедрения российских платформ серверной виртуализации вышли за рамки единичных пилотов. Аналитический центр АНО «ЦКИТ» оценил объем российского рынка по итогам 2025 г. в ₽14–16 млрд, а долю отечественных разработчиков — примерно в 80%. Однако в корпоративной инфраструктуре сохраняется значительная установленная база зарубежных платформ, поэтому переход на российские продукты идет неравномерно и во многих компаниях еще далек от завершения.
Переход на российские платформы все чаще затрагивает компании, для которых импортозамещение не является обязательным требованием. По наблюдениям Максима Березина, директора по развитию бизнеса Orion soft, они учитывают риски дальнейшей эксплуатации зарубежных систем без полноценной поддержки, обновлений и исправлений уязвимостей. Одновременно начинается «замещение импортозамещения»: после опыта промышленной эксплуатации заказчики в ряде случаев меняют одну российскую платформу на другую.
В ходе первой волны компании часто выбирали продукт в сжатые сроки и проверяли на пилоте перенос нескольких виртуальных машин. Теперь решение оценивают по результатам эксплуатации: поведению под реальной нагрузкой, качеству обновлений, работе сети и хранилищ, резервному копированию и скорости реакции службы поддержки. Повторный выбор оказывается строже, поскольку последствия ошибки уже видны на действующей инфраструктуре.
Гипервизор становится нижним уровнем платформы
Гипервизор распределяет вычислительные ресурсы между виртуальными машинами, однако крупной инфраструктуре требуется целостное управление кластерами, сетью и хранилищами, резервным копированием, отказоустойчивостью, мониторингом и аудитом действий. Это требование Денис Агеев, председатель совета директоров «Даком М» (бренд Space), формулирует так: «Для крупной инфраструктуры недостаточно самого гипервизора и возможности запускать виртуальные машины. Нужна целостная система управления вычислительными ресурсами, сетью, хранилищем, отказоустойчивостью, резервным копированием, мониторингом, аудитом и интеграциями».
Топ-10 российских платформ виртуализации 2026. Структура баллов
Подробнее: Обзор «Российские платформы виртуализации 2026»
По мере роста среды сеть и хранение перестают быть отдельными вспомогательными системами. Программно определяемые сети (SDN) переносят настройки отдельных устройств в централизованные политики, а микросегментация ограничивает связи между группами виртуальных машин. Программно определяемые хранилища (SDS) объединяют ресурсы и упрощают их наращивание. По словам Максима Березина, к таким проектам компании обычно переходят после базовой серверной виртуализации, когда ручное управление уже мешает видеть состояние инфраструктуры и контролировать изменения.
В ответ на этот запрос отечественные разработчики развивают управление сетями и хранилищами, перенос нагрузки между площадками, автоматическую балансировку, правила высокой доступности и работу с контейнерными средами. Конкуренция тем самым смещается от способности запустить виртуальную машину к предсказуемой эксплуатации всего контура.
Та же логика распространяется и на набор функций платформы. Дмитрий Сорокин, технический директор компании «Базис», отмечает рост спроса на единое управление виртуальными машинами и контейнерами, интеграцию с программно определяемыми сетями и хранилищами, резервное копирование, автоматизацию, мониторинг и встроенные средства защиты. Для заказчика при этом важна не только доступность отдельных компонентов, но и их совместная работа в составе одной системы.
Компании рассматривают частное облако не только как способ упростить выдачу инфраструктуры, но и как инструмент более эффективного использования уже имеющихся мощностей. Максим Березин отмечает, что в крупной разнородной инфраструктуре часть ресурсов может простаивать или вообще выпадать из поля зрения ИТ-службы. Автоматизация, самообслуживание, аналитика и учет потребления позволяют находить такие «забытые» ресурсы, перераспределять их между командами и быстрее предоставлять инфраструктурные среды для новых проектов.
При этом ИТ-служба сохраняет контроль над выделением ресурсов с помощью шаблонов и квот. Такая модель дает эффект только при стабильной работе сети, систем хранения и резервного копирования: иначе слой самообслуживания не упрощает эксплуатацию, а добавляет еще один уровень управления.
Виртуальные машины не исчезают рядом с контейнерами
Контейнеры подходят для новых приложений, разбитых на сервисы и рассчитанных на регулярные обновления, тогда как корпоративная инфраструктура сохраняет базы данных, отраслевые системы и старые приложения, которым нужна обычная операционная система внутри виртуальной машины. Их переписывание может стоить дороже переноса, а в некоторых случаях невозможно из-за закрытого кода или требований сертификации.
Мировой рынок отвечает на сосуществование двух типов нагрузки средствами совместного управления: технологии на основе Kubernetes позволяют описывать виртуальные машины как управляемые объекты и запускать их рядом с контейнерными приложениями. Алексей Шабалин, начальник отдела систем виртуализации и облачных технологий «Базальт СПО», считает этот подход проявлением более общего перехода от классических средств виртуализации к инструментам Kubernetes, которые постепенно берут на себя сопровождение унаследованных нагрузок.
Общий контур управления может уменьшить разрозненность среды, но одновременно повышает требования к архитектуре и квалификации команды. По оценке Алексея Шабалина, гибридные облака остаются нишевым сценарием из-за сложности и дефицита специалистов. Перед внедрением такой модели заказчику стоит определить, какие виртуальные машины и контейнеры действительно нужно сопровождать вместе и какие процессы имеет смысл автоматизировать.
Открытый код не снимает ответственности с разработчика
Большинство российских платформ используют открытые компоненты, в том числе KVM, QEMU и libvirt. Общий фундамент не делает готовые системы взаимозаменяемыми: различаются ядро и набор пакетов, средства управления, сетевой и дисковый стек, цикл обновлений, документация, испытания и модель поддержки.
Публичная разработка расширяет круг тех, кто проверяет код и сообщает об ошибках, но корпоративный продукт требует отдельной работы по усилению защиты, контролируемому выпуску обновлений и сокращению числа лишних компонентов. Березин подчеркивает, что открытость облегчает аудит, однако сама по себе не подтверждает безопасность конкретной сборки и скорость устранения уязвимостей.
Еще один риск связан с условиями использования открытых проектов: лицензия или доступ к следующим версиям могут измениться. Как отмечает Алексей Шабалин, заказчику важно понимать состав продукта, степень контроля российского разработчика над его компонентами и возможность продолжать поддержку при изменениях во внешнем проекте.
В проприетарной модели ответственность за весь продукт сосредоточена у одного разработчика — от архитектуры до сервисного сопровождения. Денис Агеев, считает это важным для крупной инфраструктуры, где виртуализация включает не только гипервизор, но и управление сетью, хранилищами, резервным копированием, мониторингом и другими компонентами.
Преимущество проприетарной модели Денис Агеев видит в том, что один поставщик отвечает за архитектуру, развитие и сопровождение продукта. Дмитрий Сорокин обращает внимание не столько на тип лицензии, сколько на степень контроля разработчика над ключевыми компонентами платформы. Зависимость от компонентов с открытым исходным кодом, которые развиваются вне компании, может влиять на сроки поддержки и устранения уязвимостей, поскольку российский вендор не контролирует их развитие. Поэтому независимо от модели лицензирования заказчику важно оценивать состав продукта, степень контроля разработчика над его компонентами, регламент выпуска исправлений и обязательства по поддержке.
Миграцию начинают с карты зависимостей
После выбора новой платформы нужно определить, какие системы можно переносить отдельно, а какие — только вместе со связанными сервисами. Для этого составляют карту зависимостей: для каждой виртуальной машины фиксируют гостевую операционную систему, конфигурацию виртуального оборудования, подключения к сетям и хранилищам, настройки резервного копирования, лицензии приложений и интеграции. По этой карте определяют последовательность остановки, переноса и запуска систем.
До составления последовательности переноса нужно провести аудит исходной виртуальной инфраструктуры. Важно определить, какие инфраструктурные сервисы на ней работают, какие информационные системы используют ее ресурсы и от каких компонентов они зависят. Дмитрий Сорокин считает такой аудит первым этапом проекта миграции: его результаты позволяют определить требования к целевой инфраструктуре и только затем планировать перенос. Для каждой виртуальной машины при этом фиксируют гостевую операционную систему, виртуальное оборудование, подключения к сетям и хранилищам, настройки резервного копирования, лицензии приложений и интеграции. На основе этих данных составляют карту зависимостей и определяют последовательность остановки, переноса и запуска систем.
Сервисы также распределяют по критичности и устанавливают для них допустимое время восстановления (RTO) и допустимый объем потери данных (RPO). Максим Березин рекомендует на основе этой классификации выбирать окно и способ миграции, а также заранее готовить сценарий возврата на прежнюю платформу. Если сервис нельзя останавливать, его непрерывную работу обеспечивают на уровне приложения — например, с помощью кластера или репликации данных; средства виртуализации сами по себе могут лишь сократить время простоя.
При переходе с прежней платформы виртуализации на новую отдельно проверяют совместимость виртуального оборудования и драйверов. Алексей Шабалин предупреждает, что эмуляция устройств прежней платформы может снизить производительность, а установка драйверов новой системы — потребовать изменений в гостевой операционной системе. Выбранную конфигурацию нужно испытать под нагрузкой, близкой к рабочей, затем закрепить порядок переноса в инструкции и по возможности автоматизировать повторяющиеся операции.
Сценарий сначала проверяют на некритичной виртуальной машине: оценивают работу приложения, сети, резервного копирования, мониторинга и восстановления. Затем миграцию повторяют на небольшой группе однотипных систем. На весь контур ее распространяют только после оценки фактического времени простоя и изменения производительности.
Выбирать надо эксплуатацию на несколько лет вперед
Таблица возможностей дает исходный список для сравнения, а реальную разницу показывают регулярные эксплуатационные сценарии: добавление узла, обновление кластера, перенос нагрузки между площадками, восстановление из резервной копии, изменение сетевой политики и расследование инцидента. На пилоте стоит использовать собственные образы, драйверы, системы хранения и приложения, фиксируя результаты в измеримых критериях.
Сопровождение нужно проверять вместе с техническими возможностями продукта, причем, как подчеркивает Денис Агеев, сервисный центр должен работать в связке с командой разработки, а обратная связь заказчиков — влиять на продукт, документацию и средства администрирования. До заключения долгосрочного договора заказчику полезно проверить путь эскалации, сроки исправлений, доступность специалистов, качество базы знаний и предсказуемость обновлений.
Зрелость российской платформы виртуализации проявляется в том, насколько предсказуемо она переживает обновления и отказы, управляет сетью и хранением, поддерживает контейнерные сценарии, восстанавливает сервисы и дает команде эксплуатации понятные инструменты. Первая волна импортозамещения показала, что отечественные гипервизоры способны занять место зарубежных систем. На следующем этапе заказчики будут определять, какие платформы могут стать устойчивой основой инфраструктуры на несколько лет.