Миграция приложений в облачную инфраструктуру
Опыт и экспертиза, накопленные Cloud.ru в миграции большого количества клиентских решений в облако, определили четыре основных этапа успешной миграции. Понимание специфики каждого из них помогает обеспечить плавную миграцию в облако Cloud.ru.
- Этап 1.
Анализ приложений. Необходимо точно определить все сервисы и функции приложений, используемые стеки технологий, схемы развертывания, соглашения об уровне обслуживания (SLA) и зависимости от других систем. Помимо этого важно понимать эксплуатационные особенности, требования по безопасности, требования соответствия различным стандартам или ограничениям и другие нефункциональные требования.
Анализ приложений включает, но не ограничивается следующим :
Архитектура приложений.
Модули приложений, внутренние и внешние зависимости, а также используемые языки и средства разработки.
Вычислительные ресурсы, на которые установлены приложения, в том числе данные о конфигурациях, технических характеристиках серверов, операционные системы, общие объемы хранящихся данных, сетевые параметры, требования к развертыванию систем высокой доступности (HA), а также средств аварийного восстановления и резервного копирования.
Базы данных, в том числе типы и версии, каким объемом данных придется оперировать, производительность и требования к конфигурациям высокой доступности (HA).
Промежуточное ПО, включая сведения о его типах (такие как ПО для передачи сообщений, кеширования, интеграционная шина), версиях, а также производительности и требуемой емкости.
- Этап 2.
Планирование миграции. На основе информации, собранной на этапе 1, выполняется оценка приложений по модели шести R (R6)* и общим принципам, описанным ниже. Далее проводится анализ готовности приложения и бизнес преимуществ от перехода в облако и определяются оптимальные пути миграции.
Модель шести R (R6)
Модель шести R или R6 образуется от первых букв английских слов:
Rehost — это перенос приложения, включая данные в облако, без каких-либо существенных изменений в приложении. Это самый простой и менее затратный с точки зрения финансов и времени процесс миграции в облако.
Replatform — предполагает модификацию решения для оптимальной работы в облаке, но без изменения его архитектуры. Например, для автоматического масштабирования отдельных компонентов решения.
Refactor/Rearchitect — рефакторинг и смена архитектуры системы, по сути переписывание решения для соответствия облачным принципам, механизмам и путям использования.
Repurchase — или замена решения, заключается в выборе и адаптации аналогичного уже готового облачного решения с переносом в него данных текущего решения.
Retire — вывод текущего решения из эксплуатации по разным причинам. Например, после модернизации решений и перевода в облако функции данного решения уже не нужны.
Retain — сохранение приложения без изменений, когда переход в облако невозможен по регуляторным или другим причинам. Например, если стоимость миграции превышает потенциальные выгоды модернизации приложения.
Общие принципы миграции приложений:
Сторонние SaaS сервисы, если они так же развиваются, как и основное решение, продолжают использоваться, как и до миграции.
Для коммерческого ПО, если не существует альтернативная облачная версия того же продукта от вендора, применяется Rehost или Replatform, то есть перенос приложения как есть или с минимальными изменениями под облачную ОС.
Приложения, не готовые для работы в облаке, например, приложения с несовместимыми операционными системами, устаревшими, недоступными или неподдерживаемыми компонентами, или приложения, преимущества от миграции которых неочевидны, стоит оставить работать на локальных вычислительных ресурсах, т.е. Retain или даже Retire впоследствии.
Для миграции приложений собственной разработки в зависимости от требований заказчиков к стеку технологий применяют подходы Rehost, Replatform или Rearchitect.
Миграция таких компонентов, как базы данных и промежуточное ПО, при наличии аналогичных облачных сервисов осуществляется путем Replatform и переходом на оплату за облачные сервисы по мере их использования (Pay-As-You-Go). Использование готовых облачных сервисов позволит не беспокоиться об эксплуатации и сопровождении компонентов, а также достичь большей эффективности использования компонентов решения.
Принципы приоритезации приложений:
Какое приложение следует мигрировать первым, а какое в последнюю очередь, решается с учетом степени их готовности и ожидаемых преимуществ от миграции. Квадрант приоритезации показан на следующем рисунке. Начинать лучше с тех приложений, миграция которых пройдет проще и даст значительные бизнес-преимущества.. Низкий приоритет следует назначить приложениям, миграция которых сопряжена с трудностями или не позволит быстро получить заметные преимущества от миграции.
При определении бизнес преимуществ учитываются, но не ограничиваются этим списком следующие факторы:
Повышение производительности/эффективности работников и снижение затрат для бизнеса.
Повышение требований к качеству предоставления сервиса.
Улучшение пользовательского опыта.
Серьезные проблемы с архитектурой решения.
Требования к автоматическому масштабированию.
Соответствие нормативно-правовому регулированию.
При определении степени готовности к работе в облачной инфраструктуре учитываются, но не ограничиваются этим списком следующие факторы:
Сложность сервисов.
Зрелость бизнеса и IT-проекта.
Взаимозависимости внутри и вне решения.
Организационная структура и ее возможности.
- Этап 3.
Разработка плана пилотных миграций. Выбор приложений для пилотных миграций осуществляется согласно общему плану, сформированному на этапе 2. Затем разрабатывается план для пилота и оцениваются соответствующие затраты. Надлежащее планирование поможет упростить процесс и обеспечить успешность будущих миграций.
- Этап 4.
Реализация и подведение итогов. После разработки плана миграции и утверждения бюджета выполняется миграция пилотных приложений. Ее цель — определить, на чем должна сосредоточиться компания с точки зрения технологических и организационных вопросов, процесса, компетенций и затрат. Данный этап имеет важнейшее значение для накопления практического опыта. Он помогает компаниям более уверенно осуществлять миграцию приложений в облачные инфраструктуры и получать больше преимуществ от миграции.
При использовании методологии R6 возможны следующие пути миграции:
В следующих разделах рассматриваются пути миграции, задействующие простое перемещение (Rehosting), смену платформы (Replatform) и смену архитектуры (Rearchitect).
Простое перемещение или рехостинг (Rehosting)
Рехостинг, известный также как простое перемещение или “lift and shift”, является самым распространенным способом миграции приложений в облако, не требующим изменения самих приложений и их сред исполнения. Обычно он используется в сценариях перемещения из физической среды в виртуальную (P2V) или из виртуальной среды в виртуальную (V2V). Посредством рехостинга можно быстро выполнять миграцию в облачные инфраструктуры таких коммерческих решений, как SAP EPR, CRM и др.
Cloud.ru предлагает три решения для рехостинга:
- Повторное развертывание приложений
Этот вариант предусматривает возможность заново развернуть приложения на виртуальных машинах (ECS). Такое решение идеально подходит для миграции приложений, которые не требуют переноса данных. При этом на облачных серверах можно будет установить необходимую ОС, например, когда старая ОС уже не поддерживается. Но нужно учитывать, что такой подход приведет к временной недоступности сервисов.
- Экспорт и импорт образов
Экспорт системного образа сервера и последующий его импорт в облако, поможет вам быстро создать облачные системы с той же ОС, конфигурацией, приложениями и другими деталями, что и ваши исходные системы. Это решение целесообразно выбирать, когда речь идет о миграции серверов с небольшим объемом данных. ОС серверов при таком способе миграции останется прежней, но при переносе будет некоторый перерыв в их работе.
- Служба миграции серверов (SMS)
SMS позволяет выполнять миграцию приложений в облако и синхронизирует инкрементные изменения данных, чтобы свести время простоев к минимуму. Однако обновить ОС в процессе такой миграции невозможно.
Ниже приведена таблица с указанием преимуществ и недостатков решений рехостинга для виртуальных и физических серверов:
Метод миграции |
Преимущества и недостатки |
|---|---|
Повторное развертывание |
|
Экспорт и импорт образов |
|
Server Migration Service (SMS) |
|
Рассмотрим в качестве примера типовую трехуровневую архитектуру приложения. На следующем рисунке показано, как изменится его архитектура после миграции.
Рехостинг (Rehosting) обеспечивает следующие преимущества:
После миграции архитектура приложения остается неизменной, поэтому можно быть уверенным, что система будет по-прежнему функционировать. Данный подход гарантирует высокую вероятность того, что миграция приложений пройдет без проблем.
Если базы данных создавались с использованием машин ECS, то для случая коммерческих БД, их лицензии можно переиспользовать, что позволит сэкономить средства.
Поскольку приложения одновременно развертываются в нескольких зонах доступности (Availability Zone или AZ), то возможно создание конфигураций высокой доступности на уровне ЦОДа.
С помощью сервисов ELB и Auto Scaling приложения можно автоматически масштабировать, адаптируя к изменениям текущей нагрузки как в большую, так и в меньшую сторону.
ELB заменяет собой традиционные аппаратные балансировщики, а вместо межсетевых экранов используются списки контроля доступа (ACL). Это позволяет дополнительно сократить инвестиции в оборудование.
CES обеспечивает комплексный мониторинг приложений и облачной инфраструктуры, а LTS позволяет быстро собирать и анализировать журналы событий приложений. Это упрощает процессы эксплуатации и обслуживания решений, а значит уменьшает трудозатраты команд сопровождения.
Сервис CBR обеспечивает резервное копирование облачных серверов на случай необходимости восстановления или возникновения других проблем. Тем самым повышает уровень надежности решения и скорость его восстановления после сбоя.
HSS обеспечивает защиту облачных серверов, WAF — фильтрацию трафика веб-приложений, а DBSS усиливает безопасность облачных баз данных. В комплексе они позволяют выстроить контроль безопасности на всех уровнях функционирования приложения.
Смена платформы или Replatform
Replatform — это компромисс между простым переносом (Rehost) и рефакторингом (Refactoring). Смена платформы подразумевает переход приложения с существующей традиционной на более современную облачную платформу. Для этого необходимо заменить компоненты приложений (такие как базы данных и промежуточное ПО) облачными сервисами, не меняя при этом базовой архитектуры этих предложений. Например, реляционные базы данных можно заменить на RDS, промежуточное ПО для обработки сообщений — сервисами очередей сообщений DMS, а кеширующие компоненты на DCS. Это позволит снизить затраты на управление инфраструктурой и повысить эффективность и масштабируемость приложений.
Cloud.ru предоставляет следующие решения для переноса баз данных и промежуточного ПО, созданных самостоятельно или на сторонних облачных платформах:
Объект |
Тип |
Исходная система |
Целевая система |
Метод миграции |
Преимущества и недостатки |
|---|---|---|---|---|---|
База данных |
Сервер MS SQL |
Собственной разработки / DBaaS |
Сервис реляционных БД Cloud.ru RDS for SQL-Сервер |
Data Replication Service |
|
MySQL |
Сервис реляционных БД Cloud.ru RDS for MySQL |
||||
PostgreSQL |
Сервис реляционных БД Cloud.ru RDS for PostgreSQL |
||||
MongoDB |
Сервис БД документов Cloud.ru Document Database Service |
||||
Промежуточное ПО |
Redis |
Собственной разработки / облачные сервисы |
Сервис распределенного кеширования Cloud.ru Distributed Cache Service (DCS) for Redis |
Миграция в DCS |
Целевой объект — DCS |
Kafka |
Собственной разработки |
Сервис распределенных сообщений Cloud.ru Distributed Message Service (DMS) for Kafka |
MirrorMaker |
Позволяет синхронизировать данные только в кластерах Kafka. Прогресс групп потребителей синхронизировать невозможно. |
Рассмотрим следующую типовую архитектуру. Компания использует брокер сообщений Kafka, чтобы разделить frontend и backend приложения, и сгладить несогласованность их производительностей. Для горячих данных используется кеш Redis, а для основных данных — база данных MySQL.
Чтобы обеспечить требования бизнеса по качеству обслуживания клиентов, данным решением реализованы схемы высокой доступности сервисов, резервирования и восстановления, а также осуществляется постоянная поддержка компонентов в актуальном состоянии и в соответствии с текущими требованиями безопасности. При этом эксплуатация и техническое обслуживание требуют больших затрат, а наращивание вычислительной мощности сопряжено со значительными трудностями.
Cloud.ru предоставляет облачные сервисы для развертывания решений в облаке. Это значительно упрощает развертывание, эксплуатацию и сопровождение решения, обеспечивая компаниям следующие преимущества:
Экземпляры сервисов можно развернуть за считаные минуты, что сокращает время, трудозатраты и затраты при оплате по мере использования (Pay-As-You-Go).
Облачные сервисы могут разворачиваться с учетом требований высокой доступности (HA). Компании могут сконфигурировать активный и резервный экземпляры MySQL и кластеры Kafka/Redis, а также использовать возможность развертывания сервисов в нескольких зонах доступности, чтобы обеспечить высокую доступность на уровне всего ЦОДа.
Облако предлагает вариант оплаты сервисов по мере использования (Pay-As-You-Go) для различных типов используемых сервисов, а также обеспечивает простоту масштабирования сервисов. Это позволяет компаниям начать работу с конфигураций малого размера и увеличить решение до больших размеров по мере необходимости.
Облачные сервисы позволяют экономить затраты на эксплуатацию и сопровождение сервисов.
Смена архитектуры (Rearchitect)
Смена архитектуры, называемая также «рефакторингом приложения», подразумевает переосмысление подхода к проектированию и разработке приложения и, как правило, предусматривает использование Cloud-Native подходов, таких как переход от монолитных приложений к микросервисам. Обычно это вызвано острой потребностью в расширении функций, масштабировании или повышении производительности, которую было бы трудно удовлетворить в существующей рабочей среде приложения. Эта стратегия обычно оказывается самой затратной, но в перспективе сможет лучше удовлетворить растущие потребности компании. Разделение монолитных приложений на микросервисы требует глубокой вовлеченности специалистов бизнес-направлений.
Проблемы традиционных архитектур приложений
Для традиционных монолитных приложений характерны в частности следующие распространенные проблемы:
Низкая утилизация ресурсов, сложность развертывания, эксплуатации и обслуживания:
Низкая модульность системы, сложное планирование и недостаточная масштабируемость.
Недостаточная стандартизация приложений, «серверы-снежинки» (серверы, недостаточно надежные и сложные для повторного создания из-за необходимости обновлений среды или компонентов во время их работы).
Отсутствие унифицированных или комплексных процедур мониторинга, эксплуатации и обслуживания, поскольку персонал занят поддержкой нижележащей инфраструктуры.
Сложность архитектуры приложений
Слишком большое количество функциональных модулей, чрезмерно сложная архитектура.
Высокая связность приложений и состояний, усложняющая масштабирование решения.
- Длинный цикл создания и изменения приложений
Сложный процесс разработки, при котором разработчики должны отслеживать все детали архитектуры — от управления сервисом (ограничение скорости, автоматическое выключение, переход на более раннюю версию) и доступа к данным до передачи сообщений.
Выполнение тестирования вручную, замедляющее выпуск приложений.
Слишком длинные этапы разработки приложений, не позволяющие достаточно быстро создавать новые сервисы.
Облачно-ориентированная (Cloud-Native) архитектура приложений
Согласно принципам организации CNCF технологии облачных вычислений открывают для компаний возможность создавать и эксплуатировать масштабируемые приложения в общедоступных, частных и гибридных облачных инфраструктурах. Эти подходы характеризуются использованием технологий контейнеров, микросервисов, service mesh, декларативных API, неизменяемых инфраструктур и др.
Облачно-ориентированная (Cloud-Native) архитектура приложений включает следующие компоненты:
Микросервисы
Микросервисная архитектура предусматривает разделение приложения на набор небольших сервисов. Это позволяет упростить сложные архитектуры приложений.
Контейнеры
Применение контейнеров облегчает реализацию микросервисных подходов и помогает решить проблему неэффективного использования ресурсов.
DevOps
Использование технологий контейнеризации повышает эффективность разработки программного обеспечения, эксплуатации и обслуживания систем, а также способствует развитию практик DevOps и помогает сокращать длительность этапов разработки, сложность развертывания, эксплуатации и обслуживания приложений.
Реорганизация приложений
Для реорганизации приложений применяются микросервисы, контейнеры и инструменты DevOps:
Реорганизация приложений на базе микросервисов предусматривает в частности анализ имеющейся архитектуры, глубокое исследование бизнес-процессов различных подразделений, разделение микросервисов в зависимости от требуемых функциональных возможностей, определение интерфейсов взаимодействия между сервисами, составление спецификаций разработки для реорганизации микросервисов и управление микросервисами.
Реорганизация на базе контейнеров требует в частности определения масштабов реорганизации, выявления зависимостей приложений, создания образов контейнеров, координирования контейнеров и управления ими.
Реорганизация на базе DevOps включает в частности анализ процессов разработки решений, средств разработки и внешних зависимостей, выявления узких мест, выбор пилотных приложений, обучение принципам гибкой разработки и их внедрение.
На следующем рисунке представлена типовая архитектура, в которой для выполнения отдельных сервисных приложений используются виртуальные машины и отсутствует средство унифицированного управления сервисами и платформа конвейера (pipelines). В результате это приводит к низкому уровню утилизации ресурсов, сложностям при наращивании вычислительных мощностей, низкой эффективности разработки, медленному внедрению сервисов и высоким затратам на их эксплуатацию и обслуживание.
Реорганизация приложений может обеспечить следующие преимущества:
Реорганизация на базе микросервисов. Монолитные приложения можно разбить на небольшие, независимые, легкие и слабо связанные группы микросервисов с использованием модели масштабируемости AKF Scalability Cube, при этом разделяя frontend и backend приложения, а также отделяя исполнение приложений от состояния. Для управления микросервисами, написанными на разных языках программирования, можно использовать технологии service mesh, такие как Istio. Развертывание приложений, баз данных и промежуточного ПО осуществляется в нескольких зонах доступности с балансировкой запросов с помощью сервиса ELB. При этом производится репликация или синхронизация данных и состояний для обеспечения высокой доступности приложений в режиме «активный-активный» (active-active).
Реорганизация на базе контейнеров. Приложения размещаются в быстродействующих контейнерах, применение которых обеспечивает высокую эффективность использования ресурсов. CCE, построенный на базе Kubernetes, обеспечивает гибкое автоматическое планирование и самовосстановление, а также адаптивное масштабирование мощности по требованию, что позволяет достичь бесперебойной работы сервисов и рационального использования ресурсов.
Реорганизация на базе DevOps. Автоматизации в виде конвейеров развертывания и оркестрации средами позволяют за несколько секунд подключить вычислительные ресурсы и развернуть приложение. Подход обеспечивает подключение сервисов логирования, мониторинга, обработку тревожных событий и информацию о функционировании системы в целом.
Само-организованные группы. Небольшие группы специалистов, которые занимаются анализом, разработкой, тестированием, развертыванием, эксплуатацией и сопровождением приложений. Они выявляют узкие места во время предоставления сервисов и быстро оптимизируют их, руководствуясь принципами бережливого производства.
Процесс миграции
Масштабный проект миграции обычно предусматривает перенос большого количества приложений за короткий период времени, а также последующую комплексную диагностику и устранение проблем в работе приложений. Офис управления проектами (Project Management Office или PMO) берет на себя инициативу по организации рабочего процесса и распределению специалистов с обеих сторон для выполнения соответствующей работы упорядоченным и эффективным образом в соответствии с целями проекта.
Формирование групп специалистов
Заказчик и Cloud.ru должны сформировать собственные проектные группы. В процессе миграции эти две группы специалистов будут работать совместно. На следующем рисунке представлена структура рекомендуемой группы специалистов по миграции.
Руководитель проекта (РП) формирует проектный офис для управления проектом, выявления и контроля рисков и других проблем, а также для продвижения проекта в организации заказчика.
Группа архитектуры и миграции проектирует решения для миграции в облако, производит миграцию и контролирует технические риски в процессе ее реализации.
Группа тестирования проверяет решение, выполняя функциональные тесты, тесты производительности и совместные пуско-наладочные испытания.
Группа эксплуатации и сопровождения занимается созданием, управлением и мониторингом облачных ресурсов.
Группа поддержки миграции и исследований (Cloud.ru) обеспечивает решение переданных на ее уровень технических проблем.
Группа разработки (заказчик) отвечает за разработку, развертывание и миграцию приложений.
Обеспечение эффективности миграции
Совещание по запуску проекта, чтобы определить объем работ, цели, сроки и обязанности при реализации проекта.
Управление взаимодействием по проекту. Важно поддерживать регулярное взаимодействие между участниками проекта и заинтересованными сторонами. Это быстрее выявляет потенциальные проблемы и помогает их решить.
Управление ходом реализации проекта. Чтобы обеспечить реализацию проекта в соответствии с планом, осуществляется контроль выполнения проектных работ и ключевых задач. В случае отклонения от графика принимаются корректирующие меры, о которых посредством еженедельных или ежедневных отчетов информируются участники проекта и заинтересованные стороны.
Управление рисками. Для количественной оценки рисков осуществляется непрерывный контроль допущений и рисков проекта. Периодически требуется обновлять план контроля рисков, а также обеспечивать реализацию мер, направленных на снижение рисков. Все проблемы и риски регистрируются и отслеживаются, включая сведения о времени их выявления и об ответственных за поиск решения. Затем эту информацию посредством еженедельных или ежедневных отчетов необходимо доводить до сведения участников проекта и других заинтересованных лиц.
Матрица реализации. Предполагается разработать матрицу совместной реализации проекта, которая включает работы, выполняемые Cloud.ru и заказчиком.
Тестирование и верификация
Прежде чем окончательно перенести сервисы в облако, участники проекта проводят функциональное тестирование и тестирование производительности, чтобы убедиться в стабильности работы приложения в облаке.
Функциональное тестирование сервисов
Участники проекта со стороны Cloud.ru проверяют готовность всех облачных ресурсов Cloud.ru, конфигурируют инфраструктуру, развертывают приложения и переносят часть данных для совместного приемочного тестирования. После подготовки среды заказчики могут использовать собственные сценарии тестирования, чтобы проверить работоспособность приложений и убедиться в том, что сервисы в облаке функционируют надлежащим образом.
Тестирование производительности
Такое тестирование не ограничивается только оценкой производительности. Оно включает также нагрузочное тестирование, стресс тестирование и тестирование на стабильность или надежность. Тестирование производительности предусматривает постоянное повышение интенсивности запросов к системе (постоянное увеличение количества одновременных запросов к системе) с целью определить KPI системы по производительности и максимальную допустимую нагрузку.
Для тестирования производительности можно воспользоваться сервисом CPTS, который поддерживает тестовые проекты CPTS и JMeter, либо использовать инструменты нагрузочного тестирования от сторонних разработчиков.
Инструменты CPTS или JMeter используются для создания синтетического трафика пользователей, а TCPCopy или GoReplay для записи реального трафика пользователей. Это позволяет проверить, соответствуют ли функции и производительность приложений заявленным требованиям.
В процессе тестирования формируются отчеты на базе показаний инструментов тестирования, систем мониторинга облака Cloud.ru (таких как CES, AOM, APM), систем мониторинга заказчика и логов приложений.
После завершения нагрузочных тестов сгенерированные данные удаляются как ненужные и выполняется полная или инкрементная миграция данных. По окончании миграции трафик сервиса в подходящий момент переключается на приложение в облаке.
Перенос сервисов в облако
Развертывание и перенос сервисов в облако являются наиболее важными этапами миграции. Любые проблемы на этом этапе могут привести к масштабным сбоям. Чтобы процесс прошел гладко, необходимо составить подробный чек-лист предварительных мероприятий.
В течение некоторого времени после переноса сервиса в облако осуществляется постоянный контроль за его работой и его данными.
После удаления данных, сгенерированных во время тестирования, и окончательной синхронизации в целевую облачную инфраструктуру, в часы минимальной нагрузки начинают переключать трафик сервисов. Переключение можно выполнить одновременно для всех сервисов, либо последовательно по архитектурным слоям приложения.
Одновременно
Для простых или небольших систем при условии, что сначала будет проведено полное тестирование системы, переключение можно выполнить для всех сервисов одновременно. При таком способе переключение осуществляется быстро и почти не влияет на работу текущих сервисов.
Процесс одновременного переключения осуществляется следующим образом:
Прекращение тестирования в целевой системе и удаление тестовых данных.
Остановка сервисов в исходной системе.
Выполнение инкрементной синхронизации данных в целевую систему.
Опционально: конфигурирование обратной синхронизации данных для подготовки к откату в случае неудачного переключения.
Изменение конфигурации DNS, переключение публичного IP-адреса на облачную среду и переключение трафика на целевую систему.
Наблюдение за стабильностью сервисов в целевой системе.
Обеспечение непрерывной работы сервисов.
Последовательно по слоям
В случае комплексных сервисов или крупномасштабных систем сервисы можно разделить и переключать каждый слой по отдельности. При возникновении каких-либо проблем можно будет выполнить откат для переключенного слоя — это позволит снизить риск влияния проблем на сервисы. Однако такой иерархический подход переключения потребует нескольких операций переключения, которые отнимают много времени и несут серьезные трудозатраты.
Последовательная миграция по слоям выполняется в два этапа. Сначала в облако переносится слой приложений, но при этом работа сервисов с данными производится из исходной системы. Когда переключение слоя приложений завершено, выполняется миграция данных, или в приложении настраивается двойная запись в реальном времени для синхронизации данных в исходной системе и целевой в облаке. После инкрементальной миграции данных выполняется следующий этап — переключение слоя данных.
Для последовательной послойной миграции требуется доступ к базе данных, находящейся в удаленной от приложения локации. Например, приложение в облаке, а база данных в дата-центре заказчика. Поэтому важно определить сетевую задержку, чтобы оценить, удовлетворяет ли она требованиям приложения.
Процесс последовательного переноса осуществляется следующим образом:
Этап 1. Перенос слоя приложений
Прекращение тестирования в целевой системе и удаление тестовых данных.
Изменение конфигурации слоя промежуточного ПО (Enterprise Service Bus, Message-oriented Middleware, и т.п.) в целевой системе таким образом, чтобы обращение от слоя приложений из целевой системы маршрутизировались к слою данных находящемуся в исходной системе (с помощью Direct Connect или VPN-подключений).
Изменение конфигурации DNS, переключение публичного IP-адреса и переключение трафика на целевую систему.
Наблюдение за стабильностью сервисов в целевой системе.
Этап 2. Перенос слоя баз данных
Остановка сервисов в целевой системе.
Выполнение инкрементальной синхронизации данных.
Опционально: конфигурирование обратной синхронизации данных для подготовки к откату в случае неудачной миграции.
Изменение конфигурации слоя промежуточного ПО в исходной системе таким образом, чтобы обращение от слоя приложений из исходной системы маршрутизировались к слою данных находящемуся в целевой системе.
Запуск сервисов в целевой системе.
Наблюдение за стабильностью работы сервисов в целевой системе.
Обеспечение непрерывной работы сервисов.
Риски, связанные с переносом, и откат сервисов
Процедура отката в сценарии одновременного переноса довольно проста. В этом разделе рассматривается решение для отката в сценарии последовательного послойного переноса.
Решения для отката в сценарии последовательного послойного переноса отличаются, если:
Слой данных не был перенесен:
Можно непосредственно перенастроить DNS так, чтобы переключить трафик обратно на исходную систему.
Слой данных перенесен в облако:
Откат слоя данных в исходное состояние. Для этого используется следующая процедура:
Остановка сервисов в целевой системе.
Выполнение обратной синхронизации данных.
Изменение конфигурации слоя промежуточного ПО в целевой системе таким образом, чтобы она маршрутизировала запросы в слой данных, созданный после обратной синхронизации в исходной системе.
Запуск сервисов в целевой системе.
Наблюдение за стабильностью работы сервисов.
Откат слоя приложений в исходное состояние. Для этого используется следующая процедура:
Изменение конфигурации уровня промежуточного ПО в исходной системе таким образом, чтобы она маршрутизировала запросы в слой данных, созданный после обратной синхронизации в исходной системе.
Изменение конфигурации DNS, переключение публичного IP-адреса и переключение трафика на исходную систему.
Запуск сервисов в исходной системе.
Наблюдение за стабильностью работы сервисов.
Решение, обеспечивающее быстрое переключение DNS
После изменения записи в DNS необходимо распространить новое имя на все серверы DNS в интернете. Это может занять до 72 часов, но в большинстве случаев запись обновится менее чем за 24 часа. В течение этого времени имя домена может разрешаться в старый IP-адрес, что приведет к ошибкам при попытках доступа.
Если имя домена разрешается в старый IP-адрес из-за того, что изменения записи о доменном имени еще не вступили в силу, в исходной системе можно установить Nginx или iptables и использовать HTTP Nginx proxy или iptables NAT для перенаправления трафика в облако Cloud.ru, обеспечив тем самым быстрое переключение на новую запись о доменном имени.
Ниже в качестве примера используется HTTP Nginx proxy для настройки переадресации трафика:
Перед переключением установите Nginx reverse-proxy за балансировщиком в исходной системе, чтобы перенаправлять трафик на балансировщик в облаке Cloud.ru.
После переключения имени домена привяжите доменное имя и IP-адрес исходной системы к балансировщику нагрузки. Балансировщик перенаправит трафик на Nginx, а он в свою очередь перенаправит на публичный IP-адрес балансировщика в облаке Cloud.ru.
(Опционально) Установите на исходном сервере Nginx модуль для мониторинга трафика (например, ntop) и проверьте логи доступа Nginx. Если никакой трафик не генерируется и логи доступа не обновляются, это значит, что разрешение имен DNS переключено в облако Cloud.ru.
Удалите установленный Nginx proxy в исходной системе.
для Dev & Test