По оценкам iKS-Consulting, в 2018 году платформу VMware использовали 78,8% компаний, которые применяют виртуализацию. Весной 2025 года в аналогичном исследовании указано, что доля отечественных решений в ПО виртуализации достигла 60,2%, а доля VMware оценивается в ~39% (оценка по данным анализа 19 крупнейших российских облачных провайдеров). То есть VMware-решения все еще заметны, но уже не доминируют так, как несколькими годами ранее
За несколько лет VMware в России прошла путь от «платформы по умолчанию» среди тех, кто виртуализирует, до одной из заметных, но уже не ведущих опций. Рынок быстро перераспределяется в пользу отечественных платформ — ради доступности поддержки и обновлений, управляемости процессов и соответствия требованиям в российских контурах.
В этой статье разберемся, как выбрать платформу виртуализации. Для этого вспомним краткую историю VMware и сравним подходы и классы платформ (On-Prem и у провайдера) с точки зрения эксплуатации, безопасности и миграции. В конце вас ждет чек-лист требований (включая ИБ/комплаенс) и таблица выбора по сценариям, чтобы быстро отсеять неподходящие варианты и собрать план перехода без сюрпризов на согласованиях с ИБ.
Скрытый текст
Как VMware стал стандартом виртуализации
В 2001 году VMware выпустила ESX Server — один из первых коммерческих гипервизоров топ-1 для x86. Это позволило компаниям консолидировать с��рверы и повысить утилизацию инфраструктуры без переписывания приложений. К середине 2010-х VMware была лидером серверной виртуализации, а vSphere стала привычной основой для корпоративных дата-центров.
Доминирование обеспечили три фактора:
Единая платформа и единая модель управления: ESXi/vSphere для вычислений, vCenter для централизованного контроля, NSX для сетевых функций, vSAN для виртуализации хранения и HCI-подхода плюс зрелый набор механизмов вокруг: миграции, высокая доступность, автоматизация и интеграции с экосистемой. Конкурентам чаще приходилось собирать сопоставимый стек из разных продуктов, что усложняло внедрение и эксплуатацию.
Экосистема. Производители серверов массово сертифицировали оборудование и конфигурации под VMware через HCL, а вендоры бэкапа и мониторинга выстраивали интеграции вокруг API vSphere. Для многих Enterprise-систем поддержка VMware была по умолчанию, тогда как с KVM или OpenStack интеграцию нередко приходилось дорабатывать и стандартизировать процессы.
Кадровая база: за два десятилетия сформировалось большое сообщество администраторов и архитекторов с сертификациями VCP/VCAP. Переучивание команд на альтернативы означало дополнительные затраты, поэтому даже при росте стоимости лицензий компании долго оставались на VMware.
Что изменилось после покупки Broadcom
22 ноября 2023 года Broadcom закрыла сделку по приобретению VMware: в публичных оценках она фигурирует как транзакция на ~69 млрд $ (часто поясняется как ~61 млрд $ стоимости капитала и принятие ~8 млрд $ долга).
После закрытия Broadcom быстро зафиксировала новый фокус: VMware Cloud Foundation стала центральным продуктом для Enterprise-сценариев, а портфель начали упрощать вокруг меньшего числа наборов и более жесткой модели потребления. Это был не «маркетинговый ребрендинг», а перестройка способа продажи и поддержки платформы.
Ключевое изменение в лицензировании объявили уже в декабре 2023 года: прекращение продаж бессрочных лицензий и прекращение продления SnS (Support & Subscription) для Perpetual-инсталляций — дальше только подписочная модель. Для части клиентов это вылилось в ощутимый рост затрат именно из-за перехода на обязательные бандл�� и новой структуры контрактов.
По ценам есть публичные претензии со стороны европейских облачных провайдеров: в материалах CISPE/ECCO и в публикациях по их выводам упоминаются кейсы, где рост оценивался в 800 – 1 500% относительно прежних условий.
Параллельно Broadcom перезапустила партнерские и облачные программы. Для облачных провайдеров ключевым стало закрытие программы VMware Cloud Service Provider (VCSP) и переход к модели, при которой использование лицензий VMware в облаках привязано к VMware Cloud Foundation и механизму переноса лицензий (License Portability) через ограниченный список сертифицированных провайдеров.
Почему VMWare теперь нельзя использовать как раньше
С ноября 2025 года VMware работает по новой схеме с VCF 9. Broadcom вводит модель License Portability (BYOL — Bring Your Own License):
Клиент покупает VCF-подписку напрямую у Broadcom (On-Premise-лицензия).
Эта лицензия Portable — ее можно использовать либо On-Premise у себя, либо перенести в облако.
НО: право принимать клиентские лицензии в своем облаке есть только у сертифицированных провайдеров из списка Certified Cloud Services.
Certified Cloud Services — это Invite-only-список из ~40 компаний глобально:
Google Cloud (GCVE);
Microsoft Azure (AVS);
Oracle Cloud (OCVS);
Rackspace, Lumen, DXC Technology.
В России таких провайдеров нет. Для нас это означает следующее:
Мелкие и средние облачные провайдеры. Не могут покупать лицензии по модели VCPP (программа закрыта). Не могут принимать клиентские лицензии VCF 9 (нет в списке Certified Cloud Services). Могут только обслуживать существующие контракты до их окончания. После истечения контрактов потребуется либо миграция клиентов к сертифицированным провайдерам, либо переход на альтернативные платформы виртуализации.
Клиенты облачных провайдеров. Даже если клиент купил подписку VCF 9 у Broadcom, он может использовать ее в облаке только у ~40 избранных провайдеров. Если провайдер не в списке Certified, нельзя продлить VMware-услуги после окончания контракта. Для российских компаний все просто: ни один российский провайдер не входит в Certified Cloud Services, а западные гиперскейлеры недоступны.
Крупные облачные провайдеры (гиперскейлеры). С 1 ноября 2025 года они больше не продают VMware-лицензии в составе своих услуг. Им придется требовать от клиентов прямой покупки VCF-подписки у Broadcom и предоставлять только инфраструктуру (BYOL-модель). Это увеличит барьеры входа для клиентов: нужно самостоятельно покупать подписку у Broadcom и договариваться с гиперскейлером отдельно.
Broadcom создает олигополию: вместо тысяч облачных провайдеров, которые могли строить VMware-облака по модели VCPP, остается ~40 компаний в мире с правом принимать клиентские лицензии. Для российского рынка это означает полное отсечение от возможности использовать VMware в облаках.
License Portability — не новая идея VMware
Модель License Portability от Broadcom может показаться революционной, но Microsoft использует похожий подход уже больше 10 лет.
License Mobility через Software Assurance от Microsoft работает так:
Клиент покупает On-Premise-лицензии Windows Server, SQL Server и т. д. с Software Assurance.
Он может переносить их в облако, но преимущественно в Azure (собственное облако Microsoft) или к партнерам с Azure Stack — локальная версия Azure, развернутая у провайдера (требует сертификации и дорогого железа). Список Authorized Mobility Partners ограничен (~500 компаний глобально, но основной фокус — Azure).
Правда, Microsoft хотя бы оставила SPLA для региональных провайдеров (месячная подписка, Pay-as-you-go). Broadcom же полностью закрыла VCPP — теперь только дорогие подписки VCF 9 на три-пять лет и строго контролируемый список облаков.
Четыре проблемы для российского рынка
1. Ограниченный доступ к официальной поставке и поддержке. Официальный контур продаж/поддержки VMware для РФ фактически недоступен: сложно легально купить новые лицензии, продлить поддержку и гарантированно получать обновления. Параллельно после сделки Broadcom усилила переход на подписку и привязку к контрактам/порталам. Патчи и техподдержка становятся условной привилегией. Любые «серые» схемы добавляют юридические риски и риск потери поддержки/обновлений в критичный момент (инцидент, аудит, расследование).
2. Накопление уязвимостей. В 2024–2025 годах выходили критические уязвимости в vCenter/VCF и ESXi, часть — с подтвержденной эксплуатацией в поле. В реальности это означает не «очередной CVE», а риск захвата плоскости управления (vCenter) или побега из VM на хост. При компрометации vCenter/гипервизора атакующий сразу получает рычаги над большим количеством ВМ и может остановить/зашифровать инфраструктуру «пакетом», а не по одной машине. Если окно патчинга удлиняется из-за поддержки/доступа к обновлениям, риск становится системным.
3. Регуляторика. С 1 января 2025 года в России действует запрет иностранного ПО на объектах КИИ. С 1 сентября 2025-го — усиленные требования по персональным данным. С 1 марта 2026-го — Приказ ФСТЭК №117 для ГИС. Продолжение эксплуатации VMware — это буквально нарушение регуляторных требований для объектов КИИ, госсектора, компаний с персональными данными.
4. Облачные провайдеры отрезаны от VMware. Российские провайдеры просто не могут строить и масштабировать облака на VMware. Клиенты вынуждены мигрировать на альтернативные платформы.
Здесь важно отдельно поговорить о суверенитете облаков. Цифровой суверенитет — способность государства контролировать данные, инфраструктуру и цепочки поставок на своей территории без влияния иностранных юрисдикций. Например, AWS строит European Sovereign Cloud (ESC) — физически отделенные ЦОДы в Германии, управляемые только резидентами ЕС, с отдельными юридическими лицами по немецкому праву. Цель этого — обойти американский Cloud Act. Вот как это устроено в разных странах:
Критерий | США | Европейский союз | Россия |
Законодательство | Cloud Act: американские провайдеры обязаны передавать данные властям США независимо от местоположения серверов | GDPR: запрет передачи данных граждан ЕС в страны без уровня защиты DMA/DSA | 152-ФЗ: локализация персональных данных граждан РФ на территории РФ 187-ФЗ (КИИ): запрет иностранного ПО на объектах критической инфраструктуры |
Провайдеры | AWS, Google Cloud, Microsoft Azure (глобальные) | AWS ESC (суверенное облако в ЕС), Gaia-X (европейская инициатива), OVHcloud | VK Cloud, Cloud.ru, «Ростелеком», «Яндекс CLOUD» и прочие российские провайдеры с ЦОДами в РФ |
Физическое расположение | ЦОДы глобально, включая США | ЦОДы в ЕС (для AWS ESC, OVHcloud) | ЦОДы только на территории РФ для объектов КИИ и ПДн |
Юридическая защита | Данные подпадают под Cloud Act, даже если сервер в ЕС | AWS ESC: отдельные европейские юридические лица, управление EU-резидентами | Российские провайдеры не подпадают под юрисдикцию США Данные защищены от Cloud Act |
Контроль над инфраструктурой | Американские вендоры (Broadcom, Microsoft) контролируют лицензии глобально | То же — американские вендоры, даже в суверенных облаках | Российские платформы (VK Cloud, zVirt, «РЕД ОС») — лицензии контролируют российские компании |
Сертификация | Нет требований к локализации | Европейские компании требуют суверенных облаков для соблюдения GDPR | ФСТЭК/ФСБ-сертификация обязательна для госсектора, КИИ, ПДн |
Трансграничная передача данных | Разрешена без ограничений | Требуется защиты (Adequacy Decision) или SCC (Standard Contractual Clauses) | Полный запрет, особенно для ПДн |
В итоге получается так:
США: Cloud Act — доступ без границ. Clarifying Lawful Overseas Use of Data Act (2018) обязывает американские компании предоставлять правоохранительным органам доступ к данным независимо от местоположения серверов. Broadcom как американская корпорация может отключить лицензии VMware по федеральному запросу — даже если вся инфраструктура расположена в Европе или Азии. Это системный риск для любых компаний, работающих на американском софте.
Поскольку Broadcom — американская компания, зарегистрированная в США, модель License Portability означает, что Broadcom:
знает, какой объем ресурсов вы потребляете (Per-core Licensing, отчетность провайдеров);
контролирует активацию и деактивацию лицензий;
может отозвать лицензии по требованию американских властей.
Большинство Certified Cloud Services — американские или европейские компании: Google Cloud, Microsoft Azure, Oracle Cloud, Rackspace, Lumen (все — США) плюс несколько европейских (Atos, OVHcloud). Даже если физические серверы в ЕС, юридический контроль остается у американской компании.
Использование VMware VCF 9 в облаках Certified Cloud Services означает зависимость от американской юрисдикции. Для организаций с требованиями к суверенитету данных (КИИ, госсектор, банки, персональные данные) это юридический риск, независимо от физического расположения серверов.
Европа — суверенитет через регуляцию и отделение. ЕС штрафует американские компании за нарушения GDPR (до 20 млн € или 4% выручки), DMA и DSA. В ответ AWS в 2026 году запустила European Sovereign Cloud — инфраструктура физически и юридически отделена от США. Европейские компании могут выбрать хранение данных на территории ЕС с гарантией, что к ним не применяется американское законодательство.
Россия — импортозамещение как решение. Российские провайдеры (VK Cloud, zVirt, ROSA, Tensor Cloud) не подпадают под Cloud Act. Данные остаются на территории РФ, лицензии и контроль над инфраструктурой — в руках российских компаний.
Рынок отечественных платформ виртуализации существенно вырос к настоящему году. Это не следствие импортозамещения — это экономический результат. Компании уходят с VMware не потому, что так нужно по закону, а потому, что стоимость миграции ниже, чем риск блокировки лицензий.
Облачные сервис�� в России: выбор платформы виртуализации
Компаниям нужны разрешенные решения. Согласно требованиям ФСТЭК, размещение ПДн и/или ГИС требует использования решений исключительно из утвержденных реестров Минцифры и Минпромторга. VMware ESXi не внесен в указанные реестры ни в каком виде.
В итоге есть два варианта: DIY (Do It Yourself) и Managed Cloud.
Критерий | DIY (собственный ЦОД) | Облако (провайдер в РФ) |
Первоначальные вложения (CAPEX) | Серверы, СХД, сети, лицензии, СЗИ, ремонт ЦОДов — от 20–100 млн рублей. | CAPEX ≈ 0. Пилот запускается за дни, без закупки железа |
Эксплуатация (OPEX) | Гарантия, продление лицензий, техподдержка, замена узлов, DR-площадка. Планирование на 3–5 лет | Оплата по тарифам (vCPU/RAM/storage). Обновления, отказоустойчивость, часть резервирования включена |
Команда | Нужны админы по виртуализации, сети, Storage, ИБ, DevOps, 24×7 L1/L2. Риск — наем, текучка, обучение | Гипервизор, железо, DR на стороне провайдера. Вашей команде остаются архитектура, безопасность, эксплуатация ВМ |
Скорость запуска | Закупки, тендеры, поставка, монтаж — от месяцев до года | Новый проект за дни. Масштабирование через API, без новых закупок |
Контроль и комплаенс | Максимальный контроль: вы управляете всем — от стоек до СКЗИ. Проще обосновать для КИИ/ГИС, если есть ресурсы | Контроль делится: железо у провайдера, доступы/данные у вас. Нужен провайдер с ФСТЭК/ФСБ-аттестацией и понятными SLA |
Гибкость архитектуры | Можно строить «как удобно»: экзотические топологии, специфические СКЗИ. Но вся сложность на вашей команде | Ограничены каталогом сервисов провайдера. Зато многие вещи (HA, бэкапы, DR, сети) уже «упакованы» |
Масштаб и утилизация | Для стабильной предсказуемой нагрузки (утилизация 80–90%) и долгого горизонта (5+ лет) может быть выгоднее | Для переменных и непредсказуемых нагрузок (проекты, dev/test, сезонные пики) облако почти всегда дешевле |
Vendor Lock-in | Вы сами выбираете гипервизор, СЗИ, СХД. Смена платформы — отдельный проект с миграцией | Зависите от провайдера и его платформы. Проверяйте сценарии выхода: экспорт ВМ, миграция |
DIY стоит выбирать, когда есть деньги, команда, долгий горизонт и очень строгая регуляторика.
Облако — когда важны скорость, гибкость, снижение операционных рисков и дефицит кадров.
Реальная стоимость владения виртуальными машинами
Полная стоимость владения (TCO) — это не только цена железа и лицензий. Реальные затраты складываются из шести уровней:
Статья TCO | DIY (собственный ЦОД) | Облако (провайдер) |
1. Инфраструктура и лицензии | Серверы: 8–16 хостов с 2×CPU, 256–512 Гб RAM — десятки миллионов рублей СХД/HCI: дисковые полки, контроллеры, кэш, лицензии Сети: TOR-коммутаторы, Core, межплощадочные каналы, NGFW Лицензии гипервизора, SDN, SDS СЗИ: МЭ, СКЗИ, средства защиты ВИ, SIEM-агенты | CAPEX ≈ 0 Все включено в тариф: vCPU/RAM/storage, лицензии, обновления |
2. Эксплуатация и поддержка | 24×7 дежурные инженеры, On-call, ротации, обучение Мониторинг: Zabbix/Prometheus, алерты, дашборды Патчи и обновления: планирование окон, тестирование, откаты Управление инцидентами: реагирование, постмортемы DR-сайт: репликация, тестирование планов | Гипервизор, железо, часть резервирования — на стороне провайдера Вы фокусируетесь на уровне ВМ/сервисов |
3. Энергопотребление и ЦОД | Электроэнергия: мощность оборудования × 24 × 365 × тариф + 40–50% на охлаждение Аренда стойко-мест в ЦОДе (если не свой) Ремонт и модернизация помещений | Электроэнергия = 0 (включена в тариф) Охлаждение и ЦОД — на стороне провайдера |
4. Безопасность и комплаенс | Категорирование КИИ, модели угроз, ТЗ на СЗИ, закупки, внедрение, аттестация Поддержание соответствия ФЗ-152, 187-ФЗ, приказам ФСТЭК/ФСБ Регулярные аудиты, проверки, внутренняя и внешняя аттестация SIEM, корреляция событий, реагирование на ИБ-инциденты | Провайдер предоставляет аттестованный сегмент и часть отчетности Ответственность за данные и процессы — на вас Затраты на аттестацию заметно ниже |
5. Кадры и экспертиза | Наем и удержание специалистов: виртуализация, Linux/Windows, сети, ИБ, DevOps Зарплаты за три года многократно превышают стоимость железа Обучение под новые платформы (миграция с VMware) | Часть экспертизы объединена у провайдера Экономия на редких ролях: архитекторы виртуализации, специалисты по СХД |
6. Риски и стоимость простоя | Вероятность и стоимость инцидентов: простои, шифрование, утечка данных Регуляторные риски: штрафы, предписания Vendor Lock-in: стоимость выхода из платформы | Часть рисков перекладывается на провайдера (SLA, ответственность) Зависимость от финансовой устойчивости провайдера |
Собственная виртуализация: что выбрать в 2026 году
Свой слой виртуализации имеет смысл, когда важнее контроль, чем скорость запуска: вы сами выбираете стек, темп обновлений и правила эксплуатации. Вы не экономите на лицензиях, а берете на себя инженерную ответственность.
Так живут не только энтузиасты. Например, Google Compute Engine прямо пишет, что его ВМ работают на KVM-гипервизоре. А OVHcloud открыто говорит, что их Public Cloud построен на OpenStack и они в него контрибьютят.
KVM + Libvirt — базовый слой, если вы любите контроль. KVM — это «чистая механика» виртуализации в Linux, а Libvirt — стандартный API, через который этим управляют. Такой вариант выбирают, когда нужна предсказуемая база без привязки к платформе «все в одном» и есть кому собрать обвязку (сеть, Storage, HA, мониторинг, обновления).
В OpenStack KVM считается основным направлением, и документация прямо говорит, что для Compute-узлов KVM используется по умолчанию.
Proxmox VE — упакованный KVM, когда нужен кластер без тяжелой IaaS. Proxmox VE — это KVM для VM и LXC для контейнеров, но с нормальным веб-управлением и встроенными инструментами под кластер и отказоустойчивость. Если нужен быстрый старт частной виртуализации и понятная эксплуатация, это часто самый короткий путь из Open Source.
Для продакшена есть важный нюанс: подписка дает доступ к Enterprise-репозиторию (самые стабильные пакеты) и поддержке с SLA. Без нее обновления и риск-менеджмент остаются полностью на вашей стороне.
OpenStack — когда нужны IaaS-модель и самообслуживание для многих команд. OpenStack — это уже не гипервизор, а IaaS-платформа: отдельные сервисы под вычисления, сеть, хранилище, образы и контроль доступа. Его берут провайдеры и большие организации, где нужна многопользовательская модель (квоты, проекты, роли, изоляция), а не просто кластер виртуализации.
OVHcloud прямо называет OpenStack фундаментом своего Public Cloud.
OpenNebula — проще, чем OpenStack, но ближе к «частной IaaS», чем Proxmox. OpenNebula строит частное/гибридное облако на KVM (и поддерживает LXC), дает федерацию и сценарии для распределенных площадок и Edge. В их документации заявлена масштабируемость до тысяч гипервизорных узлов в одном инстансе — это хороший сигнал, что проект рассчитан не только на малый кластер.
Российские коммерческие платформы
Open Source дает свободу, но требует зрелой эксплуатации: обновления, мониторинг, безопасность и регламенты вы держите своими силами. Российские коммерческие платформы берут часть этой нагрузки на себя: у них есть поддержка, понятный цикл обновлений и интеграции с отечественными ИБ-системами. В контурах с требованиями ФСТЭК и в задачах вокруг 152-ФЗ/187-ФЗ это часто решает быстрее любых фичей.
Условно их можно разделить по назначению. Для защищенных контуров и аттестации обычно выбирают решения с упором на безопасность и совместимость с российской экосистемой — например, «РЕД Виртуализация», VK Cloud или zVirt и прочее. Также это применимо и для частного облака и автоматизации — платформы, где важнее API, инфраструктурный код, интеграция с Kubernetes и быстрые миграционные сценарии.
Отдельный путь — не собирать частное облако самостоятельно, а получать его как готовую поставку/сервис от провайдера. На российском рынке такие сценарии встречаются у разных провайдеров, и VK Cloud как раз один из них.
Как выбрать: матрица решений
Сценарий | Масштаб | Рекомендация | Почему |
Стартап, пилоты, dev/test | 5–50 ВМ | Публичное облако | Pay-as-you-go без CAPEX. Запуск за дни, масштабирование через API. Переменная нагрузка — платите только за факт |
Малый и средний бизнес | 50–200 ВМ | Proxmox VE (Community) или облако | Proxmox дает контроль, и не надо платить за лицензии, но нужен админ с экспертизой. Облако — если дефицит кадров, нужна быстрая масштабируемость или техподдержка 24×7 |
Средний бизнес с предсказуемой нагрузкой | 200–500 ВМ | Российские платформы как частное облако или облако, если проходит по TCO | Стабильная утилизация 70–90% окупает Bare Metal за три-четыре года. Гипервизор на собственном железе — контроль и экономика; публичное облако — масштабируемость при пиках |
Крупный бизнес, Enterprise | 1 000+ ВМ | OpenStack (DIY или Managed) + Multi-AZ | Нужны Multi-tenancy, Self-service, автоматизация. Managed OpenStack у провайдера снижает операционные риски. DIY — если есть команда 24×7 и долгий горизонт |
Регулируемые отрасли (КИИ 1–2, ГИС, банки) | 500+ ВМ | Российские платформы с сертификацией ФСТЭК в реализации как частное облако | Аттестация критична. On-Premise или частное облако у аттестованного провайдера. Multi-AZ для отказоустойчивости. Проверяйте сертификаты ФСТЭК перед закупкой |
AI/ML, GPU-нагрузки (рендеринг, CAD, обучение моделей) | Любой | Решение с FreeGRID или облако с GPU | GPU-виртуализация через FreeGRID делит физическую GPU между ВМ (аналог NVIDIA GRID). В облаке — готовые GPU-инстансы без управления железом |
DevOps-команды, микросервисы, IaC | Любой | OpenStack + Kubernetes или облако с Managed Kubernetes | IaC через Terraform/Ansible. OpenStack API совместим с AWS/Azure. Managed Kubernetes (VK Cloud, Yandex Cloud) — если нет экспертизы по K8s |
Гибридные сценарии (On-Premise + облако) | Любой | OpenStack On-Premise + российское облако на OpenStack | Единый API упрощает Burst to Cloud и миграцию Workload. Проверяйте совместимость версий OpenStack (Ocata, Train и т. д.) |
Миграция с VMware (срочно, минимум доработок) | Любой | Hystax Acura (Live Migration), а также MIND | Hystax переносит ВМ без Downtime через CDP |
Пример роадмапа миграции с VMware
Для миграции нельзя просто выключить старое и включить новое. Это всегда проект на 6–18 месяцев с аудитом, пилотами, переносом Workload волнами и параллельным обучением команды. Ниже — роадмап, который уже прошли десятки российских компаний.
Фаза | Сроки | Что делаем | Результат |
1. Аудит и оценка | 2–4 недели | Инвентаризация ВМ в vCenter (RVTools). Группировка по критичности: production/staging/dev/test. Проверка зависимостей между ВМ | Excel-таблица приоритетов. Разделение на три волны миграции |
2. Выбор стратегии | 1–2 недели | Выбираете подход: Lift-and-shift (70%, переносите как есть), Replatforming (30%, переносите с минимальными изменениями), Refactoring (редко, переписываете под облако) | Определены инструменты миграции (Hystax Acura, qemu-img или импорт через платформу) |
3. Пилот | 4–8 недель | Тестируете миграцию на 5–10 некритичных ВМ (dev/test). Устанавливаете Virtio-драйверы в Windows. Настраиваете резервное копирование | Рабочая среда на новой платформе с проверенными процедурами |
4. Обучение команды | Параллельно с пилотом | Обучение админов: CLI (Virsh, OpenStack), веб-интерфейсы, API. DevOps-практики (IaC, Terraform, Ansible). Сертификация (OpenStack COA) | Команда готова реагировать на инциденты ДО переноса Production |
5. Поэтапная миграция | 6–18 месяцев | Волна 1 (1–3 мес): Dev/test. Волна 2 (4–9 мес): CRM, ERP, внутренние сервисы. Волна 3 (10–18 мес): Production и критичные системы | Production мигрирован, параллельная работа VMware исключена |
6. Вывод VMware | После 3–6 месяцев стабильности | Отключаете интеграции (vCenter API, мониторинг, backup). Финальный бэкап VMware. Освобождаете лицензии | VMware снята с эксплуатации. Миграция завершена |
В миграции вам могут помочь следующие инструменты:
Инструмент | Сценарий | Преимущества | Ограничения |
Hystax Acura или MIND | Live Migration критичных ВМ без Downtime | Continuous Data Protection (CDP), переносит ВМ VMware → KVM/OpenStack без остановки | Платная лицензия |
qemu-img / virt-v2v (бесплатно) | Некритичные ВМ, где можно остановить на время | Бесплатно, поддержка VMDK → QCOW2/RAW, встроено в Linux | Требует остановки ВМ во время конвертации |
Типичные ошибки при миграции:
Ошибка | Последствия | Как избежать |
Перенос всех ВМ одновременно | Полный отказ инфраструктуры при проблемах | Миграция волнами: dev/test → Staging → Production |
Отсутствие обучения команды | Инженеры не знают, как реагировать на новой платформе | Обучение параллельно с пилотом, сертификация ключевых ролей |
Игнорирование зависимостей между ВМ | Приложение ломается, потому что база осталась на VMware | Аудит зависимостей, миграция связанных ВМ пакетом |
Отсутствие плана отката | Нет способа вернуться на VMware при проблемах | Держите VMware-инфраструктуру 3–6 месяцев после миграции |
Забыли Virtio-драйверы в Windows | Сеть и диски медленнее в 10 раз | Установите Virtio до миграции или сразу после |
Выводы
За несколько лет рынок сформировал зрелые альтернативы VMware:
бесплатные (KVM, Proxmox, OpenStack) — для компаний с экспертизой;
коммерческие российские — с сертификацией ФСТЭК для регулируемых отраслей;
облачные — с готовой аттестацией и моделью Pay-as-you-go.
Вам остается только выбрать их, и, к счастью, варианты теперь есть для любого сценария — от стартапа до объектов с грифом «совершенно секретно». А таблицы и инструкции из этой статьи помогут вам с этим выбором.
