Миграция с legacy-инфраструктуры в облако без остановки бизнеса
Перенос критичной IT-инфраструктуры без потери данных
Международная FMGC-компания с многолетней историей и российским представительством
Бизнес напрямую зависит от стабильности IT-инфраструктуры: через неё проходят коммуникации с партнёрами, обработка заказов и внутренняя координация команд.
Что описано в кейсе
Исходная задача
На старте проекта IT-инфраструктура компании была развёрнута в облаке и находилась под управлением внешнего подрядчика. Бизнес оставался в классической зависимости, при которой управление инфраструктурой опирается на внешнюю экспертизу.
Компания приняла решение о переносе IT-инфраструктуры в другое облако. Для реализации проекта потребовалась независимая команда — в качестве партнёра была выбрана Aiston.
Ограничения и риски проекта
Ключевое требование в рамках проекта — перенос IT-инфраструктуры без потери данных и с минимальным влиянием на бизнес-процессы.
При этом исходные условия делали такую миграцию нетиповой и требовали тщательного планирования из-за ряда факторов:
Неполнота
данных
часть доступов и технической документации находилась у внешнего подрядчика,
усложняя анализ текущей конфигурации
Взаимодействие с двумя облачными провайдерами
часть критичных действий требовала дополнительной координации между техническими командами провайдеров
Риск неочевидных зависимостей
наличие сервисов, информация о которых отсутствовала на этапе планирования и которые могли повлиять на стабильность
работы после миграции
Допуск короткого технологического окна
почтовая инфраструктура и связанные с ней сервисы
влияли на операционные процессы, поэтому простой был допустим только в строго ограниченном временном окне
Особое значение приобретал не только технический, но и управленческий аспект проекта: координация всех участников, планирование этапов и регулярное информирование Заказчика о ходе работ.
Ход проекта по миграции
Учитывая все ограничения и критичность сервисов, команда Aiston на старте проекта сосредоточилась на выборе сценария миграции с минимальными рисками, чтобы обеспечить соответствие требованиям.
Рассматриваемые сценарии
После предварительного анализа и интервью с командой Заказчика мы зафиксировали фактический масштаб инфраструктуры и критичность сервисов.
В рамках проекта требовалось перенести несколько серверов Microsoft Exchange, объединённых в DAG-кластер, контроллеры доменами связанные с ними сервисы общим объёмом несколько терабайт данных
С учётом этих вводных предложили несколько сценариев миграции:
1.
Миграция без остановки бизнес-процессов
В этом сценарии предлагали развернуть
синхронизировать данные и постепенно
инфраструктуру в целевом облаке
параллельно с текущей средой, поэтапно
переключать сервисы без прерывания
работы пользователей.
2.
Миграция с кратковременным технологическим окном
Альтернативный сценарий предполагал
предварительную репликацию данных,
тестирование инфраструктуры и
переключение в согласованное
технологическое окно.
3.
Миграция с использованием VMware
Сценарий, который был предложен
совместно с командой Cloud.ru и
предполагал перенос инфраструктуры
с использованием инструментов
платформы VMware, поддерживающих
миграцию виртуальных машин между
облачными площадками.
Рассматриваемые сценарии
Критерий
Без остановки
бизнес-процессов
С технологическим
окном
С использованием
VMware
Влияние на бизнес
Отсутствие простоя
Кратковременный
простой
Кратковременный
простой
Влияние
на пользователей
Незаметно
Ограничения в согласованное время
Ограничения в согласованное
время
Сложность
реализации
Высокая
Умеренная
Умеренная
Управляемость
миграции
Требует постоянного
контроля
Контроль сосредоточен
в момент переключения
Чётко контролируемый
процесс
Требования
к координации сторон
Высокие
Средние
Высокие на этапе
подготовки
Зависимость
от внешних команд
Постоянная
Ограниченная
по времени
Критична на этапе
настройки инструмента
Сроки реализации
Наиболее длительные
Более короткие
Оптимальные
Стоимость
реализации
Наиболее высокая
Высокая
Сбалансированная
С учётом всех ограничений, для миграции был выбран сценарий с использованием VMware. Он сочетал преимущества сценария с технологическим окном и дополнительную предсказуемость за счёт автоматизации переноса.
Подготовка к миграции и управление процессом
Реализация миграции в выбранном сценарии требовала участия технических команд обоих облачных провайдеров: первоначальная настройка инструмента выполнялась на стороне каждой площадки, после чего команда Aiston могла использовать его для непосредственного переноса инфраструктуры.
В этих условиях мы взяли на себя координацию работ между сторонами.
Параллельно сформировали детальный план миграции с разбивкой по этапам. Отдельно подготовили план отката: заранее определили контрольные точки и временные границы, после которых принималось решение — продолжать переключение или вернуть инфраструктуру на исходную площадку и перенести миграцию на другой слот.
План миграции
1.
Репликация данных
и тестовый запуск инфраструктуры
2.
Подготовка к переключению и финальная синхронизация
3.
Финальное переключение
и ввод в эксплуатацию
До начала финальной миграции также проработали настройки, напрямую влияющие на доступность почтовых сервисов после переезда. В частности:
- Проверили и скорректировали DNS-настройки почтовых доменов — время обновления записей (TTL) снижено с 24 часов до 5 минут, чтобы избежать длительных задержек после переключения
- Заранее согласовали и запросили отдельные IP-адреса для почтовой инфраструктуры
- Подготовили PTR-записи, необходимые для корректной отправки и доставки почты после переезда
- Полностью настроили сетевую архитектуру целевой площадки: адресацию, VLAN-сегментацию, правила маршрутизации и фильтрации портов, чтобы перенесённые сервисы сразу работали в штатном режиме и соответствовали требованиям безопасности
Кроме того, заранее предупредили Заказчика о возможных задержках со стороны технической поддержки провайдеров и заложили этот фактор в план работ, чтобы он не повлиял на сроки и ход миграции.
Реализация миграции и финальное переключение
Техническая реализация миграции была выстроена поэтапно, с «репетицией» перехода до выхода в продакшн.
Шаг 1
Репликация данных и тестовый запуск инфраструктуры
Запустили репликацию данных и выполнили перенос виртуальных машин в целевое облако.
Перенесённая инфраструктура запущена в изолированном контуре без выхода в интернет — так мы проверили, что все виртуальные машины корректно стартуют, видят друг друга, доменная инфраструктура работает штатно, а почтовый сервис корректно взаимодействует с доменом и резервными компонентами.
Шаг 2
Подготовка к переключению и финальная синхронизация
После успешного тестового запуска уведомили заказчика о готовности инфраструктуры к переезду и согласовали технологическое окно на выходной день.
Непосредственно перед переключением выполнили финальную синхронизацию данных, чтобы в новой среде оказалось актуальное состояние сервисов на момент переезда.
Шаг 3
Финальное переключение и ввод в эксплуатацию
В согласованное время исходная инфраструктура была остановлена, а перенесённые сервисы запущены в целевом облаке. Мы переключили IP-адреса и обновили доменные записи, после чего входящий трафик и почта начали поступать на новую площадку.
Финальное переключение заняло около 30 минут, после чего инфраструктура начала работать в продуктивном режиме.
Результаты
На протяжении всего проекта команда Aiston находилась в постоянном контакте с Заказчиком, чтобы снять операционные риски и переживания, связанные с переездом критичной инфраструктуры.
Миграция IT-инфраструктуры выполнена:
без потери данных
с минимальным влиянием на бизнес-процессы
в рамках согласованного технологического окна
без потери данных
с минимальным влиянием на бизнес-процессы
в рамках согласованного технологического окна
После завершения миграции команда оставалась на связи по вопросам, связанным с переездом и его последствиями, обеспечивая стабильную работу сервисов и поддержку Заказчика на этапе адаптации к новой инфраструктуре.
Обсудить идею или проект
Шаг 1 из 6
Выберите тип вашего проекта