Рынок в поисках новой опоры

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

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

Перейти к обзору рынка «Платформы виртуализации»

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

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

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

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

Ключевой элемент — не гипервизор, а платформа управления

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

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

Подлинная граница пролегает выше — на уровне платформы управления виртуализацией.

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

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

• единый интерфейс для администрирования ВМ и физических хостов;
• мониторинг работоспособности и загрузки ресурсов;
• инструменты для обеспечения высокой доступности;
• функции резервного копирования и аварийного восстановления;
• гибкую систему ролей и полномочий с журналированием действий;
• интеграцию с системами хранения данных, backup и информационной безопасности;
• в некоторых случаях — поддержку нескольких типов гипервизоров.

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

Некоторые поставщики берут за основу проекты с открытым кодом — такие как oVirt, OpenNebula, OpenStack, Proxmox — и дорабатывают их, внедряя собственные модули и интерфейсы. Другие предпочитают полностью собственную разработку системы управления, контролируя всю её архитектуру.

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

Первый вариант — собственная платформа

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

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

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

Как он отмечает, разница между моделями заключается не столько в качестве ПО, сколько в природе рисков. Использование внешних 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 как такового. Технологии с открытым исходным кодом служат фундаментом для множества современных IT-решений. Однако пример oVirt раскрывает другую грань этой модели — то, как скорость развития и выпуска обновлений зависит от вовлеченности основных разработчиков.

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

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

Баланс между адаптивностью и управляемостью

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

Ключевое различие — в уровне зависимости от внешних разработок и в том, кто владеет контролем над критически важными частями системы.

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

Карта CNewsMarket не оценивает продукты по принципу «лучше-хуже». Она отображает архитектурные особенности каждого решения, давая понять, какая концепция лежит в его основе.

В период трансформации рынка именно этот выбор во многом предопределяет будущее ИТ-инфраструктуры.

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