В облачной миграции нужно следовать чёткому плану и использовать правильные инструменты. В этой статье рассмотрим, как выполнить переезд от одного облачного провайдера к другому без потери данных.
В чём заключается облачная миграция
Миграция из облака в облако — это перенос файлов, приложений и рабочих нагрузок от одного облачного провайдера к другому. Во время переезда нужно передать большие объёмы данных, сохранить их целостность, обеспечить совместимость платформ и минимизировать простои. Это требует тщательного планирования.
Чтобы успешно провести миграцию, нужно:
- сформулировать цель миграции и требования к облачному провайдеру;
- тщательно спланировать каждый этап с учётом возможных с точки зрения бизнеса даунтаймов систем и сервисов или без таковых для Mission Critical систем;
- перед миграциями всех систем и сервисов убедиться в наличии бэкапов данных, а также иметь план отката для непредвиденных ситуаций;
- выбрать подходящие инструменты и сервисы;
- проводить миграцию поэтапно, иметь пошаговый план;
- постоянно оптимизировать и проверять новую среду;
- вовлекать всех заинтересованных лиц;
- обеспечить строгие меры безопасности;
- обеспечить инфраструктурный и бизнес-мониторинг систем, сервисов и приложений.
Для чего нужен переезд из одного облака в другое
Компании могут менять облачных провайдеров по разным причинам: кто-то ищет более выгодные цены или лучшую производительность, кому-то нужна более сильная ИБ-защита, а иногда текущий провайдер просто перестаёт соответствовать растущим требованиям компании.
Экономия. Ценообразование облачных услуг зависит от типа услуги (IaaS, PaaS, SaaS), используемых ресурсов (CPU, RAM, хранилище, трафик), модели оплаты (оплата по факту использования, подписка, долгосрочные контракты) и дополнительных услуг (резервное копирование, безопасность, мониторинг).
Производительность и надёжность. Среда, в которой развёрнуты ваши системы и приложения, может оказаться недостаточно производительной. Любые сервисы, к которым ваши клиенты имеют доступ, должны обеспечивать высокий уровень производительности и минимальное время простоя.
Расширенные возможности. Другой облачный провайдер может предлагать больше опций, улучшенное управление виртуальной инфраструктурой для совместной работы, усиленные меры безопасности или более эффективную интеграцию с приложениями.
Подготовка миграции из облака в облако
При переезде большую часть времени занимает подготовка, а сама миграция проходит обычно в один день, ночь или за пару часов. Время, необходимое для переноса, зависит от объёма вашей инфраструктуры, ландшафта приложений, скорости соединения и количества выполняемых запросов.
Инвентаризация текущей инфраструктуры
Переезд начинается с инвентаризации инфраструктуры. Это нужно для того, чтобы точно знать, что переносить, избежать потери данных и сбоев в процессе миграции.
Во время инвентаризации нужно определить:
- объём информации и её структуру;
- критически важные приложения и данные, которые должны быть перенесены в первую очередь;
- серверы и хранилища данных, которые используются в настоящее время;
- зависимость между данными, приложениями и сервисами;
- серверы, приложения, базы данных и другие компоненты, которые будут мигрировать;
- текущие сетевые настройки и конфигурации.
Не забудьте учесть, какие ресурсы нужны для каждого объекта инфраструктуры. Для некоторых сервисов полезно указать используемые версии программного обеспечения, чтобы в процессе миграции не возникло проблем.
Выбор стратегии переезда из облака в облако
Сценариев переезда может быть множество. Тем не менее, есть основные стратегии:
- Повторное размещение (Re-host), также известное как lift-and-shift, — перенос систем и файлов с текущей инфраструктуры на другие виртуальные машины без изменений. Полезно для компаний, которые хотят быстро сменить провайдера, сохранив текущую архитектуру и конфигурацию.
- Рефакторинг (Refactoring) — перепроектирование рабочих нагрузок и приложений. Этот подход более сложный и отнимает много времени, но может привести к созданию более эффективного решения.
- Перестройка (Rebuilding) — реорганизация архитектуры с нуля для использования всех преимуществ новой платформы. Оправданно, если текущая архитектура устарела или неэффективна.
- Гибридный подход — комбинация lift-and-shift и реорганизации архитектуры. Рабочие нагрузки и приложения переносятся как есть или перерабатываются. Подойдёт, если хотите свести к минимуму сбои и простои, но при этом оптимизировать рабочие нагрузки и сервисы на новой платформе.
Разработка плана и подготовка к миграции
После оценки инфраструктуры нужно разработать план миграции. На этом этапе необходимо подготовить вашу инфраструктуру и данные к переезду:
- Очистите и оптимизируйте данные перед переносом, чтобы уменьшить объём и улучшить производительность.
- Защитите информацию с помощью шифрования и других мер безопасности.
- Создайте резервные копии всех данных, чтобы избежать потерь в случае непредвиденных проблем.
Перед переносом обратитесь к новому провайдеру, узнайте, есть ли у них необходимые программные сервисы для успешного завершения облачной миграции. Убедитесь, что новый облачный сервис поддерживает форматы файлов, которые собираетесь перенести.
У провайдера МТС Web Services есть сервис миграции в облако. Он предназначен для безопасного и эффективного переноса отдельных сервисов или всей ИТ-инфраструктуры в облако MWS. Основные функции и этапы работы этого сервиса:
- Планирование: анализ существующей ИТ-инфраструктуры, оценка объёмов миграции и разработка плана переноса.
- Подготовка: создание тестовой площадки для переезда и проведение тестовой миграции.
- Перенос данных: окончательная репликация и перенос нагрузки в облако, корректировка сетевой архитектуры.
- Постмиграционные шаги: обновление документации, оптимизация и развитие инфраструктуры, обучение персонала.
Создание тестовой среды
Прежде чем приступать к переезду, проводят тестовую миграцию на небольшом объёме данных и приложений. Этот шаг позволит понять, как они будут функционировать в новой среде, и выявить основные проблемы на ранних этапах переезда. Для этого проводят следующие операции:
- функциональное тестирование — поможет убедиться, что приложения и основные службы запускаются корректно и нет критических ошибок в журналах;
- нагрузочное тестирование — заключается в моделировании условий интенсивного трафика и проверке, сможет ли приложение справиться с ожидаемой нагрузкой без снижения производительности;
- тестирование безопасности — проверка на общие проблемы безопасности: несанкционированный доступ, утечки данных и соответствие стандартам ИБ;
- приёмочное тестирование — для подтверждения соответствия инфраструктуры бизнес-требованиям и ожиданиям пользователей.
В процессе тестирования важно вести подробную документацию о тестовых примерах, результатах и проблемах. После устранения проблем можно переезжать к новому облачному провайдеру.
Переключение на другое облако
Заключительная фаза миграции — переключение всей среды на нового облачного провайдера. Выберите время для переключения в непиковые часы или во время технического обслуживания. Это сведёт к минимуму воздействие на пользователей и риск появления проблем с интенсивным трафиком во время перехода.
После переноса данных и сервисов нужно:
- обновить маршрутизацию и IP-адресацию, чтобы обеспечить доступность сервисов;
- перенастроить DNS для перенаправления трафика на новые IP-адреса;
- обеспечить безопасное соединение между офисами и новым облаком;
- убедиться в работоспособности мониторинга и алертинга.
После завершения миграции важно удалить ресурсы, которые больше не нужны, например старые учётные записи или неиспользуемые элементы. Также следует оптимизировать рабочие нагрузки и приложения на новой платформе.
Проверка после переезда на другое облако
После переезда на другое облако проводят несколько важных проверок, чтобы убедиться, что всё работает корректно.
- Проверить работоспособность перенесённых приложений и убедиться, что все функции работают штатно и в соответствии с требованиями к доступности и SLA, а системы мониторинга не выдают критичных уведомлений. Если данные переносились частично, то провести сравнительные тесты для определения, в каком облаке лучше производительность сервисов и приложений.
- Убедиться в целостности и полноте данных после миграции. Проверить, что они корректно перенесены и нет пропущенных или дублированных записей.
- Проверить сетевые соединения и доступность сервисов. Убедиться, что все сетевые настройки корректны и нет проблем с подключением.
- Оценить производительность приложений и сервисов в новом облаке. Сравнить с предыдущими показателями и убедиться, что производительность не ухудшилась.
- Проверить настройки безопасности и политики доступа. Убедиться, что данные и сервисы по-прежнему защищены от несанкционированного доступа.
- Получить обратную связь от пользователей, убедиться, что они не испытывают проблем при работе с сервисами.
- Исправить выявленные проблемы.
Заключение
Частичная или полная миграция систем и сервисов — всегда масштабный проект, особенно для Enterprise-бизнеса, к которому нужно подходить ответственно и понимать все возможные риски.
При миграции из облака в облако нужно разработать правильную стратегию. Если ваш бизнес не сталкивался ранее с масштабными миграциями, можно обратиться к профессионалам, которые помогут безопасно перенести данные и приложения. При этом работа сервисов для конечных пользователей не нарушится.