В очень хорошей статье от команды инженеров Intuit от 2020г рассказывается о так называемом “двойном пузыре” при миграции данных. С точки зрения облаков это состояние во время облачной миграции или цифровой трансформации, когда вы платите как за облака, так и за исходные и целевые сайты. Насколько это распространено?
Введение в понятие облачной миграции
В современном цифровом мире, поскольку предприятия постоянно прилагают усилия для расширения и улучшения своей ИТ-инфраструктуры, мы все сталкиваемся с растущими потребностями и большим объемом информации, что вызывает скачки трафика.
Это приводит к многочисленным попыткам найти разумный способ масштабирования ИТ-инфраструктуры бизнеса и сокращения бюджета компании и совокупной стоимости владения.
И когда возникают такие вопросы, как «Как обеспечить масштабируемость и эластичность?», «Можно ли найти решение для обеспечения безопасности данных?», «Существует ли какая-либо платформа управления, позволяющая быстро выделить ресурсы и снизить затраты?» важно учитывать три наиболее важных начальных компонента быстро меняющейся среды — вычислительные ресурсы, сеть и хранилище. Повышение производительности вынуждает клиентов искать более эффективную платформу. В мире сложной модернизированной ИТ-инфраструктуры миграция в облако стала одним из основных процессов, позволяющих перемещать все данные и приложения из локальной среды в виртуализированный структурированный пул, называемый «облаком».
Стратегия миграции в облако
Миграция в облако кажется очевидной, но ее необходимо тщательно спланировать
- отсутствие внутренней экспертизы и они не знают, что им нужно сделать для перехода в облако, сколько это будет стоить и как это повлияет на время простоя их бизнеса; какие последствия будет иметь этот пробел в знаниях;
- как только компании определяют способ перехода в облако, у них отсутствует стратегия и сценарий, как откатиться, если что-то пойдет не так;
- «Переход в облако» означает, что компаниям необходимо тщательно пересмотреть свою стратегию обеспечения непрерывности бизнеса, поскольку отказоустойчивость ИТ в частных и общедоступных облаках по своей природе различна.
Поэтому, чтобы избавиться от потенциальных подводных камней, было бы выгодно обратиться за помощью к обученным специалистам в этой области.
Этапы миграции в облако
Стратегия миграции в облако — это четко разработанный сценарий, включающий алгоритм его реализации или пошаговое руководство.
Шаг 1. Определите рабочие нагрузки для переноса
Сначала необходимо определить, что будет мигрировать. Другими словами, клиента просят определить, какие рабочие нагрузки и бизнес-приложения необходимо перенести на целевую платформу. Этот компонент состоит не только из виртуальных машин с исходной платформы, но и из определенных сетевых настроек, хранилища, дисков, маршрутов, правил брандмауэра и т. д.
Шаг 2. Определите топологию компонентов бизнес-приложения
Следующим шагом является определение зависимостей между компонентами бизнес-приложений, поскольку это будет эффективной поддержкой миграции в облако во время ее выполнения. Следует отметить, что все ВМ должны запускаться в целевом облаке в соответствии с их предварительно зафиксированным порядком загрузки, планом миграции и топологией, чтобы не нарушать зависимости между всеми рабочими компонентами.
Шаг 3. Воссоздайте сетевую инфраструктуру на целевой платформе
В дальнейшем сетевая инфраструктура на целевой платформе должна быть воссоздана. Итак, сначала заказчику необходимо определить текущую сетевую инфраструктуру, настроить схему топологии с определенными параметрами сети, группами безопасности и межсетевыми экранами. Затем заказчик создает ту же сетевую инфраструктуру на целевой платформе с учетом возможностей целевого облака. Важным фактом является то, что сетевая инфраструктура на исходной и целевой площадках может различаться, поскольку сетевые компоненты и ресурсы, доступные в разных облаках, в основном различаются между собой. Это необходимо делать с высоким уровнем контроля и ответственности, потому что впоследствии это напрямую повлияет на миграцию данных.
Шаг 4. Репликация бизнес-приложений — полная и инкрементальная репликация
Далее заказчик должен быть проинформирован о том, что репликации готовы к выполнению. Эту процедуру можно выполнить вручную, когда все исходные диски перемещаются в автономном режиме в целевое облако. Но это рискованное и проблематичное решение. Другим способом является автоматизированное решение с полной оркестрацией и должным образом определенной безопасностью процесса, которое сделает все репликации плавными и беспрепятственными с помощью специального агента репликации с исходной платформы на целевую. Первая отправка данных будет полной репликацией, а последующие репликации (называемые инкрементальными) будут захватывать только дельты со времени предыдущей репликации, то есть будет пересылаться только разница между предыдущим и текущим состояниями.
Шаг 5. Настройте и проведите серию тестовых миграций
Когда полная репликация (и некоторые инкрементальные) будут готовы к работе, заказчик может приступить к тестированию всех рабочих нагрузок и запуску бизнес-приложений в целевом облаке; тем временем его исходные машины все еще работают и не затронуты тестовыми миграциями.
Лучшее в своем классе решение — использовать полностью автоматизированную функциональность, предназначенную для контроля миграции в облако. Это позволяет определить правильный порядок запуска приложений и провести серию тестовых миграций без прерывания работы исходной площадки (обычно от 3 до 5 тестовых миграций), которые помогают проверить, что все рабочие нагрузки были успешно перенесены в целевое облако, чтобы убедиться, что между отдельными элементами нет разъединений, что все сетевые настройки работают и нет проблем с производительностью между мигрированными ВМ.
Шаг 6. Выполните окончательный переход и удалите внутренних репликационных агентов
Последними шагами являются окончательный переход, который выполняется в выбранный период времени, а затем удаление внутренних репликационных агентов. После завершения всех тестовых миграций выполняется переход, когда все рабочие нагрузки и бизнес-приложения переключаются на целевую облачную платформу, а установленные агенты репликации могут быть удалены.
Преимущества миграции в облако Хайстекс Акура
Чтобы обеспечить успешное завершение вашего проекта миграции в облако без остановки продуктива в режиме реального времени, компания Хайстекс разработала узкоспециализированное и полностью автоматизированное решение, не зависящее от облака, — Хайстекс Акура. Это лидирующее на рынке решение для миграции в облако в режиме реального времени, позволяет упростить, автоматизировать и ускорить безопасный крупномасштабный перенос с любой исходной платформы в любое целевое облако. Неважно, задействованы частные или общедоступные облака. Кроме того, у него есть отличительное преимущество высокоавтоматизированной оркестрации и обеспечения непрерывности бизнеса и устойчивости ИТ — одним щелчком мыши. Более того, даже самые сложные приложения работают плавно, быстро и эффективно, сохраняя при этом свои надежные, безопасные и надежные характеристики.
Заключение
Миграция в облако как часть цифровой трансформации — сложный процесс, состоящий из ряда шагов. В постоянно меняющемся мире миграция в облако стала одним из важнейших аспектов эффективного современного бизнеса. Чтобы в полной мере использовать потенциал миграции в облако и сделать свой бизнес более гибким и конкурентоспособным, вам необходимо разработать сценарий и найти опытных поставщиков услуг, которые помогут плавно перейти в облако в течение небольшого периода обслуживания. Кроме того, используйте программное обеспечение для автоматизированной миграции в реальном времени в облако, которое упрощает перенос рабочих нагрузок с любой платформы на любую на целевую площадку и обеспечивает устойчивость и непрерывность бизнеса. При выборе подходящего программного обеспечения для миграции следует учитывать такие возможности, как:
1. Планы миграции и аварийного восстановления с оркестрацией
2. Поддержка целевого облака, в которое вы хотите перейти, и внешняя репликация
3. Способ протестировать миграцию перед переключением
4. Простой в использовании пользовательский интерфейс самообслуживания
👆🏻 Узнайте больше о ключевых характеристиках программного решения Хайстекс Акура по облачной миграции, backup и аварийному восстановлению →
