Почему импортозамещение виртуализации в филиалах стоит дороже, чем кажется

С 2022 года мы тестируем отечественные платформы виртуализации, на которые переходит бизнес после ухода VMware из России. К весне 2026 года в нашем портфеле 29 задокументированных инсталляций и семь инфраструктур на постоянной поддержке.

И вот что повторяется снова и снова: головной офис недооценивает масштаб работ в филиалах. Кажется, что филиал — это просто уменьшенная копия «большого» кластера. На практике филиал — это площадка, где те же решения стоят дороже, внедряются дольше и ломаются в самый неподходящий момент.

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

Почему замена гипервизора — это только начало

Рынок российских решений выглядит зрелым. zVirt и SpaceVM зарегистрированы в реестре российского ПО, умеют импортировать виртуальные машины (ВМ) из VMware, имеют документацию и матрицы совместимости. На бумаге этого достаточно, чтобы сказать: «Переезжаем». Но реальная работа начинается после первого экрана установки.

Возьмём zVirt: менеджер платформы действительно управляет несколькими площадками из одной точки — это удобно. Но живая миграция ВМ штатно работает только внутри одного кластера. Перевод хоста в режим обслуживания завершится ошибкой, если машинам некуда уйти или не хватает мощности. А за этим — отдельные требования к хостам, хранилищам, сети и протоколам подключения. Каждый из этих слоёв требует экспертизы и времени.

Поэтому правильный вопрос для распределённой инфраструктуры: «Кто будет разбираться с этой операционной сложностью в каждом городе?».

Что именно делает филиал сложной площадкой

Математика резерва
Чтобы кластер пережил обслуживание или потерю одного узла без остановки сервисов, нужен запас мощности N+1. В кластере из четырёх хостов это минус 25% полезной ёмкости. В кластере из 12 хостов — минус 8,3%. В кластере из 40 хостов — минус 2,5%.

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

zVirt прямо предупреждает: режим обслуживания хоста завязан на автоматическую миграцию ВМ и ломается, если миграция невозможна или мощности не хватает.

Инфраструктурный «налог филиала»
В маленьком филиале соблазн сэкономить самый сильный: подключить хосты напрямую к СХД без FC-коммутаторов, отложить второй контур связи, не держать запас по портам. На старте это выглядит как разумный компромисс. Через год выясняется, что это была не экономия, а отложенная дорогая переделка на проде.

Сетевые ограничения и люди
Централизация хороша ровно до тех пор, пока не начинаются операции, чувствительные к задержкам: миграция ВМ, репликация, резервирование, тяжёлые пользовательские сессии, работа критичных приложений. У типичного филиала нет полосы и латентности WAN, которые нужны для нормальной работы.

Мы сами проходили этот сценарий: прямые каналы между удалёнными площадками давали межсетевые задержки из-за расстояния, и пришлось проектировать архитектуру ближе к месту потребления нагрузки.

Отдельная история — люди. В филиале почти никогда нет полноценной команды виртуализации и ИБ одновременно. Поэтому особенно болезненно всё то, что в головном офисе считается мелочью: замена диска, ручное изменение конфигурации сети, запуск ISO через BMC, сбор логов, откат прошивки, локальные работы и т.д. Каждая такая задача либо висит, либо требует командировки.

Как это выглядит на реальных ситуациях

История 1. Малый филиал, который стабилен, пока его не трогают

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

Но в этом же проекте был заложен типичный компромисс: для экономии хосты подключили к СХД напрямую по FC. На старте это решило задачу. Но четыре хоста заняли все порты хранения. Как только понадобился пятый узел и расширение кластера, пришлось планировать дорогую переделку коммутации на боевой среде. Вот так «удачное внедрение» превратилось в технический долг. 

История 2. Филиал, где сервисная модель оказалась честнее покупки

Другой заказчик с самого начала отказался от схемы «купить железо и лицензии». Вместо этого он получал готовый сервис виртуализации на своей же площадке: мы отвечали за оборудование, платформу и мониторинг, он — за гостевые ОС и прикладной уровень. При этой схеме ИТ‑служба филиала перестаёт героически поддерживать всё подряд и начинает управлять тем, что относится к бизнес‑сервисам. 

Такой подход особенно полезен там, где филиалы разные по размеру и зрелости. При сервисной модели всё закладывается заранее: защищённая связность, регламент «удалённых рук», мониторинг, обновления, масштабирование, SLA. В распределённой инфраструктуре это часто единственный способ не превратить каждую филиальную площадку в плохо поддерживаемый парк оборудования. 

История 3. «Мы уже всё согласовали»

Эта история началась со слов: «Мы уже всё согласовали, железо российское, виртуализация отечественная, в матрицах совместимости всё есть». 

На сайтах производителей оборудования можно увидеть формулировки уровня «совместимость оборудования и ПО протестирована и гарантирована». А потом выясняется, что проблема живёт «ниже»: в BMC, прошивке, адаптерах, путях к хранилищу, последовательности обновлений, нестабильности консолей или неожиданном поведении драйверов. 

В крупном проекте на филиалах цена такой ошибки уже другая: вместо пилота на 3–4 узлах вы упираетесь в большую закупку и месяцы переписки между вендором железа, вендором виртуализации, интегратором и собственной ИТ‑службой. 

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

Где теряются деньги и затягиваются сроки

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

Реальная формула длиннее:

TCO на 3 года = CAPEX + внедрение + эксплуатация + стоимость изменений + риск простоя

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

Вот как выглядит примерная модель для филиала на 100–120 ВМ:

Разница — более 11% уже на базовой модели. Настоящий эффект проявляется позже. Стоит филиалу через год запросить пятый узел, новую FC-фабрику или вторую защищённую связность — разрыв между моделями уходит за 20%. Но именно этот момент почти никогда не включают в исходный бизнес-кейс. 

Есть и совсем простая арифметика для бизнеса. Пять одинаковых филиалов, в каждом — 4-хостовый кластер с резервом N+1. Куплено 20 хостов, полезной мощности — как от 15: в каждом филиале один узел в резерве. Если вместо этого построить две региональные площадки по 10 хостов с тем же N+1, те же 20 хостов дают уже 18 полезных. Те же закупки, но на 20% больше мощности. Это и есть налог распределённой архитектуры.

Как строить программу филиального импортозамещения

Планировать по эксплуатационным моделям. Обычно хватает четырёх типов площадок: 

• статичный малый филиал, 
• растущий филиал, 
• площадка с чувствительностью к задержкам,
• изолированный или регулируемый контур. 

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

Пилотировать связку. Конкретное железо + конкретные прошивки + конкретная СХД + конкретные HBA + конкретный стек ИБ + конкретные процедуры обновления. Реальная проблемы живут на стыках, а не внутри компонентов.

Прописать границы ответственности подрядчика заранее. На распределённых площадках спор «Это у вас гипервизор или у нас ОС» сжигает не только время, но и доверие. Зрелая модель выглядит так: подрядчик отвечает за оборудование, платформу виртуализации, мониторинг и канал управления; ИТ-служба заказчика — за гостевые системы, приложения, роли, данные и прикладной уровень. Когда это не проговорено заранее, каждая авария в филиале превращается в бесполезный созвон на десять человек.

Принимать проект только после отработки аварийных сценариев. Иначе вы покупаете неизвестность в рассрочку. 

Чек-лист приёмки:

• Один хост уходит в обслуживание и возвращается без потери сервиса
• Потеря одного SAN-элемента не превращается в аварию
• Резервное копирование и восстановление проверены на том стеке, который пойдёт в прод
• Добавление нового узла не требует архитектурной переделки всего кластера
• Защищённый канал управления, план аварийного восстановления для локальных действий и сценарий «удалённых рук» готовы заранее
• Зоны ответственности по слоям зафиксированы в договоре и понятны всем.

Почему путь в частное облако часто оказывается короче

Частное облако — это не обязательно «вынести всё в чужой ЦОД». Это изолированная облачная инфраструктура для одной организации — на площадке провайдера, на собственном оборудовании компании или на арендованном железе.

Отличие от «просто виртуализации» — в сервисной обвязке: 24/7-поддержка, масштабирование, мониторинг, управление ресурсами, понятный SLA. Для филиалов это и есть та недостающая часть конструкции, которую головной офис обычно так тяжело закрывает вручную.

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

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