От скепсиса к прагматике: виртуализация 360° в России

21.04.26 02:16

Как создать устойчивую и безопасную ИТ-структуру обсуждали на сессии РЕД СОФТ «Виртуализация 360°» в рамках третьей кросс-отраслевой конференции, которая состоялась 20 апреля в Москве, на площадке АКПО-конф в ИНТЦ МГУ «Воробьевы горы».

 

Денис Савенков, генеральный директор «Интер РАО – ИТ» поделился своим взглядом на Виртуализацию 360° в России-2026.

 

 — Как, на ваш взгляд, поменялось отношение к российским решениям по виртуализации?

 

 — За эти 4+ года отношение к российской виртуализации заметно эволюционировало от скепсиса к прагматике. В 2022–2023 многие смотрели на отечественные платформы как на «эксперименты»: рынок был в режиме пилотов, заказчики, в основном, делали акценты функциональных разрывах и рисках эксплуатации. Сейчас фокус сместился: обсуждают уже не “сможет ли”, а “как правильно мигрировать и как с этим жить в эксплуатации” — обновления, миграции, отказоустойчивость, автоматизация и поддержка. Это хорошо видно по развитию функциональности продуктов: российские решения подтянули ряд функций до уровня VMware, при этом остались зоны, где отставание ещё заметно (например, SDS/программно-определяемые хранилища).

 

Вторая причина смены отношения — экономика и масштаб. Рынок растет, появляются референсы и вендорские экосистемы: по оценкам cnews, объем российского рынка виртуализации в 2024 году достиг 14,4 млрд рублей, и доля серверной виртуализации — крупнейшая. Рост рынка, конечно же, означает зрелость внедрений: от “лабораторий” мы перешли к промышленным контурам.

 

И третье — кибер-и регуляторное давление. Когда у зарубежных платформ возникают ограничения с обновлениями/поддержкой, у заказчиков накапливаются риски уязвимостей и комплаенса — и это ускоряет переход от “давайте подождем” к “нужно планово мигрировать”. При этом по ряду заказчиков видно, что массовая миграция на российские платформы стартует именно сейчас, после периода тестирований и выбора целевых платформ.

 

В общем, раньше российскую виртуализацию “оценивали”, теперь её “встраивают в целевую архитектуру” — как основу устойчивости и ИБ, а не как замену по названию, и чтобы регуляторы «отстали».

 

 — Как определялись с виртуализацией в “ИНТЕР-РАО”? На что обращали внимание в рамках тестирования различных решений?

 

 — Мы целенаправленно выбирали виртуализацию не как “срочно-обморочную замену VMware”, а как базовую платформу устойчивости: чтобы платформа могла держать большие продуктивы, безопасно обновляться и мигрировать без простоев. Сначала сделали формализованную матрицу критериев: оценка функций 0–5 с весами и обязательными “стоп-факторами”. Дальше — стендовые испытания в изолированной среде («Лаборатории импортозамещения»). Критически проверяли: High Avalaibility и отказоустойчивость с резервированием ресурсов под HA, балансировку и “живые” миграции, работу со стораджем FC/iSCSI и бэкапом (включая механизмы для инкрементальных копий), сетевые функции и сегментацию, интеграцию с AD, API для автоматизации, а также безопасность — совместимость со средствами ИБ, управление сертификатами, аудит, результаты сканирования уязвимостей и реакцию вендора. По итогу выбрали решение, которое закрывает все блокирующие требования и дает управляемую эксплуатацию на масштабе, потому что для нас важнее всего предсказуемость и устойчивость, а не “набор галочек”.

 

 — Какой совет дадите коллегам, которые только начинают свои проекты по импортозамещению виртуализации? На что точно стоит обратить внимание?

 

 — Начинать стоит не с выбора продукта, а с выбора целевого режима эксплуатации. Далее:

 

1. Зафиксируйте must-have и стоп-факторы: High Avalaibility с гарантией ресурсов (аналог Admission Control), “живые” миграции, совместимость со стораджем (FC/iSCSI), бэкап/восстановление (RPO/RTO), интеграция с каталогами и ролями, аудит и логирование.

 

2. Делайте пилот на реальных нагрузках, а не на синтетике: 1С/БД/VDI, реальные профили I/O и сеть.

 

3. Проверьте обслуживание без простоя: обновления, вывод хоста в ремонт, плановые работы — это то, чем вы будете жить каждый месяц. То есть проверьте, КАК Виртуальные машины “переезжают” на другие хосты (live migration) (автоматически ли ?), после чего хост можно безопасно перезагрузить/обновить/заменить компоненты. 

 

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

 

5. Работы со сториджем и сетью без остановки ВМ. Например, расширение датастора, миграция дисков между хранилищами, переключение линков, обновление сетевого оборудования — без “выключите все ВМ на ночь”. 

 

6. Плановые изменения с планом отката и если что-то пошло не так — есть штатный rollback, а не ручной “пожар”.

 

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

 

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

 

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

 

9. Критично важна скорость реакции вендора.

 

Если коротко: выбирайте не “гипервизор”, а платформу, которая выдержит аварии, обновления и рост — и только потом смотрите на цену.

Читайте также: