Рынок без прежнего центра тяжести

Еще несколько лет назад выбор платформы виртуализации для корпоративной инфраструктуры был предсказуем. На рынке доминировали зарубежные решения, экосистемы были выстроены, специалисты обучены, процессы эксплуатации отлажены. Система управления виртуализацией воспринималась как зрелый и стабильный элемент ИТ-ландшафта — инструмент, который должен работать безотказно.

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

Перейти к карте рынка «Системы управления виртуализацией»

Российский рынок отреагировал быстро. В короткий срок сформировались десятки решений, включенных в реестр отечественного ПО. При внешнем сходстве — поддержка виртуальных машин, кластеры высокой доступности (High Availability, HA), миграции, ролевые модели — между ними проходит принципиальная граница.

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

Эту развилку и визуализирует карта CNewsMarket. Российские решения сгруппированы не по масштабу бизнеса или набору функций, а по архитектурному подходу: одни платформы опираются на open source-проекты, другие развивают собственную систему управления.

Выбор начинается не с перечня возможностей, а с ответа на вопрос — кто и каким образом контролирует развитие ядра платформы.

Не гипервизор, а система управления

Когда речь заходит о виртуализации, в профессиональной среде часто вспоминают гипервизор — KVM, Xen, bhyve. Однако для большинства заказчиков это лишь нижний технологический уровень. Он важен, но редко становится предметом стратегического выбора.

Большинство российских решений построены на базе open source-гипервизоров, прежде всего стэка QEMU/KVM. Их возможности хорошо известны, механизмы изоляции и распределения ресурсов стандартизированы, а производительность сопоставима. На этом уровне различия минимальны.

Настоящая граница проходит выше — в системе управления виртуализацией.

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

Современная система управления должна обеспечивать:

• централизованное администрирование виртуальных машин и хостов;
• мониторинг состояния и производительности;
• механизмы высокой доступности;
• резервное копирование и восстановление;
• ролевую модель доступа и аудит действий;
• интеграцию с системами хранения, резервного копирования и ИБ;
• в ряде случаев — управление другими гипервизорами.

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

Одни вендоры используют open source-проекты — oVirt, OpenNebula, OpenStack, Proxmox — и развивают их, добавляя собственные модули и интерфейсы. Другие создают собственную систему управления и контролируют архитектуру целиком.

Этот выбор определяет модель развития продукта, степень управляемости и долгосрочные риски.

Первый путь — собственная разработка

Для значительной части российского рынка принято использование собственной системы управления виртуализацией. В этом случае архитектура платформы формируется и развивается внутри компании-разработчика.

Ключевым аргументом сторонников подхода становится управляемость. Если продукт создается одной командой, именно она отвечает за изменения, обновления, безопасность и совместимость. Дорожная карта определяется стратегией разработчика и требованиями заказчиков.

Давид Мартиросов, генеральный директор «Базис», отмечает, что продукты компании разрабатываются на собственной технологической основе, что обеспечивает технологическую и юридическую импортонезависимость. Исключительные права на исходный код находятся в российской юрисдикции.

По его словам, различие моделей связано не столько с качеством программного обеспечения, сколько с характером рисков. Использование внешних open source-проектов в качестве основы для сертифицируемых решений может создавать зависимость от сторонних разработчиков и их приоритетов. Это особенно чувствительно в сегменте критической информационной инфраструктуры (КИИ).

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

В этой модели акцент делается на предсказуемость и понятную схему ответственности.

Второй путь — опора на open source

Альтернативная модель строится на основе open source подхода. Важны не только вопросы лицензирования, но и зрелость существующих проектов и накопленная экспертиза.

Проекты вроде oVirt, OpenNebula, OpenStack или Proxmox развиваются много лет. Их архитектура известна, документация доступна, специалисты знакомы с принципами работы. Для вендора это возможность быстрее вывести продукт на рынок, сосредоточившись на доработках и интеграциях.

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

Максим Березин, директор по развитию бизнеса Orion soft, отмечает, что преимуществом разработки на базе open source является высокая контролируемость кода. По его словам, в России много специалистов знакомы с oVirt и Proxmox, а продукт на базе известного проекта легче в освоении и администрировании.

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

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

Сторонники модели также указывают на гибкость и возможность адаптации под специфические требования. Однако такая архитектура предполагает зависимость от состояния базового проекта и его сообщества.

Контроль и ответственность как стратегический фактор

Архитектурные различия напрямую связаны с управлением рисками. От стабильности платформы виртуализации зависит работа корпоративных сервисов.

В проприетарной модели разработчик централизованно контролирует изменения: выпуск новых версий, аудит кода, тестирование обновлений, устранение уязвимостей и обеспечение совместимости.

Павел Гуральник, генеральный директор ISPsystem, считает выбор платформы стратегическим решением для бизнеса. По его словам, в критически важных системах контроль над изменениями в программном обеспечении является определяющим фактором, а ответственность вендора важнее формальной гибкости open source.

Он подчеркивает, что заказчик получает не только функциональность, но и выстроенную систему ответственности: внутренний аудит кода, контроль изменений, регламентированный выпуск обновлений и сопровождение через экосистему продуктов. Важным элементом модели является профессиональная техническая поддержка с формализованными соглашениями об уровне сервиса (Service Level Agreement, SLA), а также гарантированная совместимость с программным и аппаратным окружением.

В этой точке технологическая дискуссия превращается в управленческую.

Кейс oVirt как индикатор архитектурного риска

Дискуссия о контроле над развитием платформы перестает быть теоретической, когда меняется статус базового проекта.

В 2024 г. Red Hat свернула участие в развитии проекта oVirt. После ухода ключевого индустриального участника платформа осталась без регулярной централизованной поддержки и обновлений безопасности.

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

Важно подчеркнуть: речь не идет о качестве open source как такового. Проекты с открытым кодом лежат в основе большинства современных ИТ-решений. Однако кейс oVirt демонстрирует иную сторону модели — зависимость темпов развития и обновлений от статуса ключевых участников проекта.

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

Именно поэтому архитектурный выбор — опора на внешний open source-проект или развитие собственной системы управления — становится вопросом стратегии.

Рынок между гибкостью и контролем

Российский рынок виртуализации не делится строго на два лагеря. Многие решения используют смешанный подход: open source-компоненты применяются как технологическая основа, а поверх них выстраивается собственная логика управления и механизмы безопасности.

Различие заключается в степени зависимости от внешнего проекта и в том, кто контролирует ключевые элементы системы.

Для части заказчиков приоритетом становится прозрачность архитектуры и гибкость. Для других — сертификация, управляемость и предсказуемость жизненного цикла.

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

В условиях перестройки рынка именно этот выбор во многом определяет дальнейшее развитие инфраструктуры.

Перейти к карте рынка «Системы управления виртуализацией»