Привет, Хабр! В целом, про миграцию и импортозамещение высказался уже практически каждый утюг нашей необъятной родины. Почему мы вообще снова хотим подсветить эту тему? Потому что прошло уже достаточно времени, чтобы осознать: миграция — это не просто оперативное решение проблемы, а новый подход к созданию и поддержанию ИТ‑инфраструктуры. Мы в компании работаем в такой парадигме довольно давно, начали задолго до 2022 и роста популярности подобных решений, так что успели накопить достаточно опыта.
Сначала стоит представиться. Мы — это я, Евгений Шилкин, и Степан Татауров, эксперты дивизиона инфраструктуры Группы Rubytech. Наш отдел занимается платформенным программным обеспечением в высоконагруженных системах, в которое входят операционные системы, платформы виртуализации, почтовые сервисы и много чего еще.
Статья носит обзщепознавательный характер и будет полезна тем, кому в целом интересны механизмы миграции ИТ‑систем — и их ключевые отличия у разных вендоров в разных странах. В следующих статьях цикла мы разберем типы миграции, их алгоритмы и посмотрим на результаты тестирования, чтобы оценить их работу в реальных условиях. А пока…
Как так вышло, что все разом спохватились по поводу миграции?
Риторический вопрос? Почти, но нет. Ниже мы рассмотрим процесс миграции как в российских, так и в зарубежных организациях, разберем особенности, причины и сложившиеся практики миграции. Здесь не будет фокуса только на импортозамещении, поэтому, отвечая на вопрос в подзаголовке, мы придем к двум тезисам:
Спохватились не все и не сразу.
Это происходило по‑разному в России и за рубежом.
Принципиальная разница в подходах российских и иностранных вендоров заключается в скорости перехода, планомерности миграции с постепенной выработкой принципов с одной стороны, и в отчасти вынужденном характере миграции, при которой стандарты формируются параллельно с самим процессом — с другой.
Ближе к делу
Технологическая база современной ИТ‑инфраструктуры — это виртуализация. Она применяется в системах любого масштаба: от небольших корпоративных сред до крупных государственных и отраслевых платформ. За годы эксплуатации у многих компаний сформировались крупные среды виртуализации с сотнями узлов и тысячами виртуальных машин, на которых размещаются критически важные сервисы — например, когда в одной инсталляции работает больше 2000 ВМ. В таких условиях смена платформы виртуализации перестает быть исключением и становится прикладной инженерной задачей, напрямую влияющей на устойчивость и развитие ИТ‑ландшафта.
Посмотрим детальнее, из чего складывается внимание к процессу миграции в российских компаниях.
Вынужденный переход с зарубежных решений на отечественные продукты. В идеале еще и без остановки бизнес‑процессов. Миграция позволяет перенести существующие ВМ и сервисы на российские сертифицированные платформы без переработки архитектуры и с сохранением работоспособности систем (именно это и нужно почти каждой компании в нашей стране). При этом в масштабе современных виртуальных сред, включающих десятки и сотни взаимосвязанных ВМ, ручное развертывание на новой платформе будет очевидно ресурсоемким и рискованным. Использование механизмов миграции снижает объем ручных операций, позволяет сохранить структуру сервисов и обеспечить контролируемый перенос крупных инфраструктур.
Соответствие требованиям информационной безопасности и приказам регуляторов (например, приказу ФСТЭК России № 117). Во многих сферах, таких как государственное управление и банковский сектор, где сосредоточена существенная часть нашей экспертизы, применение платформ виртуализации допускается только при наличии действующей сертификации — без нее невозможно использовать отдельные решения. Вообще. Никак.
Спойлер — подробнее про это вам расскажут наши коллеги из ИБ‑департамента в одной из следующих статей, так что без них не будем углубляться в тему.Так вот, миграция в описанных выше условиях обеспечивает перенос виртуальных машин, их конфигураций и программного окружения на сертифицированную платформу без потери данных и с минимальным вмешательством в работу сервисов. В нашей практике был парк ВМ, где находилось около 700 машин с размером диска 20 ТБ и выше. В таких случаях потеря данных весьма печальна и ведет к очень затратным последствиям восстановления — восстановление ВМ с диском на 20 ТБ в идеальных условиях может занять минимум 30 часов.
Миграция — естественный процесс работы в виртуальной среде, а не временный тренд. Когда 10–15 лет назад в российских организациях массово внедрялись западные платформы, ИТ‑ландшафт развивался больше количественно, нежели качественно, при этом еще хаотично.
Тогда еще не было промышленной контейнеризации и гибридных облаков, что стало отличной почвой для создания разных зоопарков и накопления техдолга.
Сегодня организации стремятся к созданию единого ИТ‑ландшафта, который работает по понятным стандартам и поддерживает актуальные облачные модели. В такой парадигме проверенные механизмы миграции позволяют интегрировать устаревшие сегменты в новую архитектуру, снижая организационные риски и возвращая инфраструктуре прозрачность и управляемость. А как с миграцией у западных вендоров?
Там была своя атмосфера — подход формировался постепенно и отражал эволюцию самой виртуализации. VMware и Microsoft Hyper‑V выходили на рынок в период, когда виртуализация как явление только набирала популярность, и перенос между различными платформами не рассматривался как массовая задача. VMware как серверная виртуализация была представлена в 2001 году с релизом VMware GSX Server и VMware ESX Server. А Hyper‑V — в 2008 году с релизом Windows Server 2008. С ростом их распространенности ситуация изменилась: VMware и Microsoft фактически стали стандартами де‑факто, и именно на них начали переносить нагрузки с менее популярных решений.
В экосистеме VMware механизмы переноса изначально развивались как средство привлечения новых пользователей. Для переноса применялись специализированные утилиты, ориентированные на разовую конвертацию виртуальных машин. Пожалуй, самым известным инструментом стал VMware Converter, позволяющий переносить физические серверы и ВМ сторонних платформ в формат VMware. При этом конвертация выполнялась вне контекста целевой инфраструктуры, а полученная виртуальная машина требовала дополнительной настройки и проверки.
Схожий подход применялся и в Microsoft Hyper‑V. На ранних этапах основной упор делался на упрощение перехода с VMware за счет конвертации виртуальных дисков и адаптации конфигураций под Hyper‑V. Впоследствии развитие средств миграции было сосредоточено преимущественно внутри собственной экосистемы Microsoft.
Как итог — у западных вендоров исторически сложилась модель, при которой миграция рассматривалась как разовый этап перехода на платформу, а не как регулярный инженерный процесс. Это принципиально отличается от потребностей российских компаний, в которых миграция между платформами становится постоянной задачей, связанной с регуляторными, организационными и архитектурными изменениями ИТ‑инфраструктуры.
Глобальный рынок виртуализации тоже находится на грани перехода, только это вызвано не геополитическими и регуляторными нормами. Крупные вендоры, такие как VMware, выборочно переходят на подписочную модель лицензирования, что началось в индустрии с 2022 года. То, что начиналось как отдельные случаи, стало массовой тенденцией, и теперь все больше вендоров выбирают такой способ поставки своих продуктов. Как заказчикам, так и вендорам становится выгоднее переносить свои решения в облака. Помимо этого наблюдается массовый тренд на переписывание кода под контейнеры и перенос нагрузок в среду Kubernetes, которая превращается в технический стандарт для новых систем.
Ну и да, куда же тут без вездесущего ИИ: потребность в больших ресурсах для обучения и работы моделей заставляет компании мигрировать в облака, где доступ к GPU и специализированным ускорителям реализован более гибко, чем в рамках классических локальных ферм виртуализации.
Для реализации этого перехода гиперскейлеры предлагают специализированные инструменты автоматизации — например, AWS Application Migration Service (MGN) или Google Cloud Migrate to Virtual Machines. Но на практике даже при использовании поддерживаемых сервисов инженерам приходится решать вопросы несовместимости драйверов, перенастраивать сетевые связки и проводить ручную доводку политик безопасности уже внутри облачного контура.
Что делать и какие есть альтернативы
Для компаний, планирующих смену ИТ‑ландшафта, наличие эффективных инструментов перехода — ключевой критерий выбора. Сегодня российские платформы виртуализации стали достаточно зрелыми, чтобы покрывать до 80–90% функциональных возможностей западных аналогов и успешно решать сложные комплексные задачи. В ситуации, когда российские аналоги предлагают сопоставимый с западными аналогами и качественный функционал, именно надежность и предсказуемость механизмов миграции становятся решающими.
При этом важно понимать, что сам процесс миграции остается крайне трудоемким. Существует немало факторов, которые могут усложнить процесс миграции:
Разнородность оборудования — несовместимость инструкций разных поколений процессоров и настроек BIOS/UEFI.
Логика работы ВМ — необходимость пересоздания правил отказоустойчивости, лимитов ресурсов и политик автобалансировки.
Типы СХД — различия в протоколах доступа (FC, iSCSI, NFS) и способах хранения на них виртуальных дисков ВМ.
Сетевые интерфейсы — несовпадение конфигураций VLAN, параметров сетевых интерфейсов и аппаратных зависимостей.
Логика бэкапов — несовместимость систем: старый софт часто не поддерживает API новой платформы, требуя смены всей схемы бэкапа.
Чтобы обеспечить предсказуемость этого процесса, заказчики и вендоры все чаще полагаются на специализированные внешние решения. Такие инструменты годами совершенствовались узкопрофильными командами именно для того, чтобы максимально автоматизировать процесс миграции и гарантировать стабильную работу систем в новой целевой среде.
Отечественные платформы виртуализации, такие как «РЕД ВИРТ», BASIS, VMmanager и другие, предлагают штатные инструменты для переноса виртуальных машин. Поскольку замещение продуктов VMware — самый частый и востребованный сценарий из‑за большой распространенности на российском рынке, встроенные утилиты автоматизируют полный цикл: от экспорта и конвертации образа до итогового импорта в целевую платформу. Такой подход позволяет заново развернуть инфраструктуру на базе преобразованных данных и исключить ошибки ручной настройки. Важно — процесс требует временной остановки сервисов, так как является именно переносом, а не живой миграцией.
Кроме того, на рынке востребованы и универсальные решения: MIND Migrate, Hystax Acura, Carbonite Migrate. В отличие от штатных средств конкретных платформ, они обеспечивают полноценную миграцию виртуальных машин по принципу any‑to‑any. Здесь важна поддержка живой миграции: процесс перемещения ВМ проходит без ее остановки и с полным сохранением данных в оперативной памяти — то есть получается перенести нагрузку на целевую платформу в режиме реального времени, исключая простой критически важных бизнес‑процессов.
Один из показательных кейсов — миграция транзакционной платформы Газпромбанка. Задача стояла нетривиальная: сделать так, чтобы банк продолжал работать и обрабатывать тысячи клиентских операций в режиме, к которому привыкли пользователи — через единое технологическое окно, — при этом параллельно мы должны были создать независимую ИТ‑инфраструктуру на базе наших ПАК Скала^р, не допустив простоев. Наша команда справилась с этим менее чем за четыре часа в дневное время пиковой нагрузки благодаря предварительному моделированию, точной настройке более чем по 4 000 параметрам конфигурации и отработке сценариев на тестовом стенде.
Существенно сыграло на руку и сэкономило время на миграцию то, что ПАК доставили сразу под конкретный профиль нагрузки Газпромбанка. Это исключило этапы ручной интеграции и отладки — новая инфраструктура показала рост производительности на 18% при полном сохранении отказоустойчивости.
Современные отечественные инструменты универсального класса обеспечивают живую миграцию между любыми платформами виртуализации, реализуя принцип any‑to‑any без остановки сервисов. При этом вендоры сопровождают свои решения документацией, которая превращает процесс перемещения ВМ в стандартизированную процедуру. Технологические возможности таких систем позволяют автоматизировать перенос нагрузок не только внутри виртуальных сред, но и между физическими серверами (bare‑metal) и виртуальными машинами.
В следующей статье мы более подробно расскажем о типах миграции, их алгоритмах, а в конце поделимся результатами тестирования, чтобы продемонстрировать работу механизмов «в бою».
