Выбор регионов Azure для миграции

Статья
04/11/2024

При переносе существующей среды в Azure необходимо выбрать регион Azure или набор регионов для размещения перенесенных компонентов. Выбор региона включает в себя следующие высокоуровневые действия.

Ознакомьтесь с руководством по выбору основных регионов Azure, чтобы понять, как выбрать регионы Azure, соответствующие вашим требованиям.
Инвентаризация и документирование текущего состояния среды.
Реализуйте общий подход к миграции, включая запуск в одном регионе, использование нескольких зон доступности или использование нескольких регионов.
Оцените изменения процесса, которые могут потребоваться.
Планирование процесса миграции.
Оптимизация и повышение уровня изменений процесса.

В этой статье приводятся рекомендации по выбору регионов Azure, которые соответствуют вашим потребностям миграции. Если вы еще не сделали этого, возможно, потребуется расширить регионы целевой зоны для поддержки подходов с несколькими регионами.

Примечание.

В этой статье рассматриваются рекомендации, относящиеся к миграции рабочих нагрузок. Вы также должны понимать общие принципы выбора регионов Azure для любой организации или рабочей нагрузки. Дополнительные сведения см. в разделе "Выбор регионов Azure".

Документируйте сложность сценария

Определите, требуется ли в сценарии согласование документации и процесса. Следующий подход поможет оценить потенциальные проблемы и установить общий курс действий:

Рассмотрим более надежную реализацию готовности и управления.
Инвентаризация затронутых географических регионов. Скомпилируйте список затронутых стран или регионов.
Задокументируйте базу пользователей. Будет ли миграция в облако влиять на сотрудников, партнеров или клиентов в определенной стране или регионе?
Документируйте центры обработки данных и ресурсы. Включают ли усилия по миграции любые ресурсы в определенной стране или регионе?
Документируйте требования к доступности и отработки отказа регионального продукта.
Задокументируйте требования к устойчивости, чтобы определить, требуются ли зоны доступности. Как правило, необходимо учитывать требования к устойчивости для всего сценария, а не для отдельных регионов.
Задокументируйте требования к суверенитету и требования к месту размещения данных. Рабочие нагрузки, имеющие определенные требования к независимости или месту размещения данных, могут повлиять на выбор регионов Azure.

На протяжении всего процесса миграции рассмотрите возможность выравнивания изменений в различных сценариях и инвентаризациях. В следующей таблице показано, как документировать различные сценарии.

Область/регион	Страна/регион	Местные сотрудники	Местные внешние пользователи	Местные центры обработки данных или ресурсы	Требования к независимости данных
Северная Америка	США	Да	Партнеры и клиенты	Да	Нет
Северная Америка	Канада	No	Клиенты	Да	Да
Европа	Германия	Да	Партнеры и клиенты	Нет, только сеть	Да
Азиатско-Тихоокеанский регион	Южная Корея	Да	Участники	Да	Нет

Почему расположение пользователей актуально?

Организации, поддерживающие пользователей в нескольких странах или регионах, разрабатывают технические решения, которые обращаются к трафику пользователей. В некоторых случаях решения включают локализацию ресурсов. В других сценариях организация может выбрать реализацию решений глобальной сети глобальной сети (WAN) для решения разрозненных баз пользователей через сетевые решения. В любом случае профили использования разрозненных пользователей могут повлиять на стратегию миграции.

Например, если организация поддерживает сотрудников, партнеров и клиентов в Германии, но в настоящее время не имеет центров обработки данных в Германии, организация, вероятно, реализует арендованное решение. Этот тип решения направляет трафик в центры обработки данных в других странах или регионах. Эта маршрутизация представляет значительный риск для наблюдаемой производительности перенесенных приложений. Внедрение дополнительных прыжков в установленную и настроенную глобальную глобальную глобальную сеть может создать представление о недоработке приложений после миграции. Поиск и устранение этих проблем может значительно задержать завершение проекта.

Каждый из следующих разделов содержит рекомендации по устранению этой сложности в предварительных требованиях и процессах оценки, миграции и оптимизации. Понимание профилей пользователей в каждой стране или регионе крайне важно для правильного управления этой сложностью.

Почему важно расположение центров обработки данных?

Расположение существующих центров обработки данных может повлиять на стратегию миграции. Обратите внимание на следующие факторы:

Решения по архитектуре: одним из первых шагов в проектировании стратегии миграции является определение целевого региона. Расположение существующих активов часто влияет на это определение. Кроме того, доступность облачных служб и единицная стоимость этих служб могут различаться между регионами. Требования к месту размещения данных, включая требования к суверенитету, также могут повлиять на решение архитектуры. Понимание того, где находятся текущие и будущие ресурсы, влияет на решения о выборе архитектуры и может повлиять на оценку требуемого бюджета.

Зависимости центра обработки данных: в таблице в разделе "Документ" в разделе сложности сценария примеры показывают, что, вероятно, необходимо планировать зависимости между различными глобальными центрами обработки данных. Организации, работающие в этом масштабе, могут не документировать или четко понимать эти зависимости. Подход вашей организации к оценке профилей пользователей помогает определить некоторые из этих зависимостей в организации. Ваша команда также должна изучить дополнительные шаги оценки, которые могут помочь снизить риски и сложности, возникающие из зависимостей.

Реализация общего подхода

Следующий подход использует модель на основе данных для решения глобальных сложностей миграции. Если область миграции включает несколько регионов, команда по внедрению облака должна оценить следующие рекомендации по готовности:

Определите, можно ли соответствовать бизнес-требованиям: используйте несколько зон доступности, чтобы определить требования к высокой доступности, устойчивости, производительности и затратам. Если эти требования не выполнены, рассмотрите ли вам подход с несколькими регионами.
Оценка суверенитета данных: суверенитет данных может требовать локализации некоторых ресурсов, но многие ресурсы не управляются этими ограничениями соответствия. Такие службы, как ведение журнала, отчеты, маршрутизация сети, идентификация и другие центральные ИТ-службы, могут размещаться как общие службы в нескольких подписках или регионах. Оцените суверенитет данных с помощью модели общей службы для этих служб. Описание этого подхода см . в эталонной архитектуре для топологии концентратора с общими службами.
Убедитесь, что среда масштабируется: при развертывании нескольких экземпляров аналогичных сред можно создать выделенную команду для миграций среды, чтобы помочь создать согласованность, улучшить управление и ускорить развертывание. Благодаря руководству по организации системы управления для сложных предприятий вы сможете создать среду, которая охватывает несколько регионов.

Предварительные требования на основе данных

Если ваша команда комфортно с базовым подходом и готовностью согласованы, рассмотрите следующие предварительные требования, управляемые данными:

Полное обнаружение: выполните таблицу в документе , чтобы оценить сложность стратегии внедрения облака.
Анализ профилей пользователей для каждой затронутой страны или региона: важно понимать общую маршрутизацию пользователей в начале процесса миграции. Изменение глобальных линий аренды и добавление подключений, таких как Azure ExpressRoute к облачному центру обработки данных, может привести к задержкам в сети. Как можно раньше обращаться к маршрутизации пользователей.
Завершите начальную рационализацию цифровых активов: если вы вводите сложность в стратегию миграции, завершите начальную рационализацию цифровых активов. Дополнительные сведения см. в разделе "Что такое цифровое имущество?".
Используйте теги для требований к цифровым ресурсам: установите политики тегов для определения любой рабочей нагрузки, затронутой требованиями к суверенитету данных. Убедитесь, что необходимые теги начинаются в рационализации цифровых активов и переносятся в перенесенные ресурсы.
Оцените модель с концентраторами: распределенные системы часто используют общие зависимости. Часто можно устранять общие зависимости, реализуя модель с концентраторами. Несмотря на то, что реализация центральной модели не область для процесса миграции, пометите модель для рассмотрения во время будущих итерации готовых процессов.
Приоритет невыполненной работы по миграции. Если требуется изменение сети для поддержки рабочего развертывания рабочей нагрузки, поддерживающей несколько регионов, команда по стратегии облака должна отслеживать эскалации, которые приводят к изменениям сети. Этот более высокий уровень поддержки руководителей помогает ускорить изменение, освободив группу стратегий для повторения невыполненной работы и убедитесь, что изменения сети не блокируют глобальные рабочие нагрузки. Приоритет глобальных рабочих нагрузок только после завершения изменений сети.

Эти предварительные требования помогают установить процессы, которые могут устранить сложность во время выполнения стратегии миграции.

Изменения в процессе оценки

Если сценарий миграции включает глобальные сложности активов и базовых пользователей, добавьте ключевые действия для оценки кандидатов миграции. Эти действия создают данные для уточнения препятствий и результатов для глобальных пользователей и ресурсов.

Предлагаемые действия во время процесса оценки

Оценка зависимостей между центрами обработки данных. Средства анализа зависимостей в службе "Миграция Azure" помогут определить зависимости. Используйте эти средства перед началом миграции. Если сценарий связан с глобальной сложностью, оценка зависимостей является необходимым шагом в процессе оценки. Можно использовать группирование зависимостей для визуализации зависимостей и определения IP-адресов и портов всех ресурсов, необходимых для поддержки рабочей нагрузки.

Внимание

Вам нужен эксперт по теме (SME), который понимает схемы размещения активов и IP-адресов, чтобы определить ресурсы, расположенные в дополнительном центре обработки данных.
Оцените подчиненные зависимости и клиенты в визуализации, чтобы понять двунаправленные зависимости.

Определение влияния глобального пользователя: выходные данные из анализа профиля необходимых пользователей должны определять любую рабочую нагрузку, затронутую глобальными профилями пользователей. Если кандидат на миграцию находится в списке затронутых рабочих нагрузок, архитектор миграции должен обратиться к сетевым и операционным предприятиям. Эти эксперты помогают проверить ожидания маршрутизации сети и производительности. Как минимум, архитектура должна включать в себя подключение ExpressRoute между ближайшим сетевым операционным центром и Azure. Эталонная архитектура подключений ExpressRoute помогает настроить необходимые сетевые подключения.

Проектирование соответствия. Выходные данные из анализа предварительного профиля пользователя также должны определять любую рабочую нагрузку, затронутую требованиями к суверенитету данных. Во время действий по архитектуре процесса оценки назначенный архитектор должен обратиться к СПЕЦИАЛИСТАМ по соответствию требованиям. Эти эксперты могут помочь архитектору понять любые требования к миграции и развертыванию в нескольких регионах. Эти требования существенно повлияют на стратегии проектирования. Следующие эталонные архитектуры могут помочь в проектировании:

Предупреждение

Если вы используете эталонную архитектуру для ExpressRoute или эталонных архитектур для приложений, может потребоваться исключить определенные элементы данных из процессов реплика tion для удовлетворения требований к суверенитету данных. Задача исключения определенных элементов данных добавляет шаг в процесс продвижения.

Изменения процесса миграции

При переносе приложения, которое должно быть развернуто в нескольких регионах, команда по внедрению облака должна учитывать несколько дополнительных аспектов. Проектирование хранилищ Azure Site Recovery и серверов конфигурации и процессов является двумя из этих аспектов. Двумя другими соображениями являются проекты пропускной способности сети и синхронизация данных.

Предлагаемые действия во время процесса миграции

Проектирование хранилища Site Recovery: Site Recovery — это рекомендуемый инструмент для облачной реплика и синхронизации цифровых ресурсов с Azure. Site Recovery реплика tes данные о каждом ресурсе в хранилище Site Recovery. Это хранилище привязано к определенной подписке в определенном регионе и центре обработки данных Azure. Если вы реплика ресурсы во второй регион, вам также может потребоваться второе хранилище Site Recovery.

Проектирование конфигурации и сервера обработки. Site Recovery работает с локальным экземпляром сервера конфигурации и обработки, привязанного к одному хранилищу Site Recovery. При использовании этой конфигурации может потребоваться установить второй экземпляр этих серверов в исходном центре обработки данных, чтобы упростить реплика.

Структура пропускной способности сети. Во время реплика и текущей синхронизации вы перемещаете двоичные данные по сети из исходного центра обработки данных в хранилище Site Recovery в целевом центре обработки данных Azure. Процесс реплика и синхронизации потребляет пропускную способность. Дедупликация рабочей нагрузки во второй регион увеличивает объем потребляемой пропускной способности.

В некоторых сценариях пропускная способность ограничена. В других случаев рабочая нагрузка включает в себя значительную конфигурацию или смещение данных. В таких случаях реплика реплика данные во второй регион могут повлиять на время завершения миграции. Более важно, что эти ограничения могут повлиять на взаимодействие пользователей или приложений, которые по-прежнему зависят от пропускной способности, доступной в исходном центре обработки данных.

Синхронизация данных: самый большой поток пропускной способности часто происходит от синхронизации платформы данных. При развертывании в нескольких зонах доступности можно использовать службы данных, избыточные между зонами, которые автоматически синхронизируют данные между несколькими зонами доступности. Для развертывания в нескольких регионах часто требуется синхронизация данных для выравнивания приложений. Этот подход определяется в эталонных архитектурах для веб-приложений с несколькими регионами и многорегионными n-уровнями приложений.

Если сохранение синхронизации приложений — это рабочее состояние, которое требуется для приложений, может потребоваться синхронизировать исходную платформу данных с каждой облачной платформой. Выполните эту синхронизацию перед переносом ресурсов приложения и среднего уровня.

Аварийное восстановление Azure в Azure. Альтернативный вариант может снизить сложность. Если вы используете двухфакторное развертывание для удовлетворения потребностей временная шкала и синхронизации данных, аварийное восстановление Azure в Azure может быть приемлемым решением. В этом сценарии вы переносите рабочую нагрузку в первый центр обработки данных Azure с помощью одного хранилища Site Recovery и конфигурации и проектирования сервера обработки. После тестирования рабочей нагрузки можно восстановить рабочую нагрузку во второй центр обработки данных Azure из перенесенных ресурсов.

Этот подход снижает влияние на ресурсы в исходном центре обработки данных. Аварийное восстановление Azure в Azure также использует преимущества скорости передачи и ограничения высокой пропускной способности между центрами обработки данных Azure.

Примечание.

Подход к аварийному восстановлению Azure в Azure может увеличить краткосрочные затраты на миграцию с помощью более высоких затрат на пропускную способность исходящего трафика.

Изменения процесса выпуска

При устранении глобальной сложности во время оптимизации и продвижения может потребоваться одинаковые усилия в каждом регионе, в который вы развертываете. Если вы используете один регион, вам может потребоваться реплика планы бизнес-тестирования и бизнес-изменений.

Предлагаемые действия во время процесса выпуска

Оптимизация перед тестированием. Первоначальное тестирование автоматизации позволяет выявить потенциальные возможности для оптимизации, как и при любых процессах миграции. Для глобальных рабочих нагрузок независимо тестируйте рабочую нагрузку в каждом регионе. Незначительные изменения конфигурации в сети или в выбранном центре обработки данных Azure могут повлиять на производительность.

Планы бизнес-изменений: создайте план бизнес-изменений для любого сложного сценария миграции. План изменения бизнеса помогает обеспечить четкое взаимодействие с изменениями бизнес-процессов и взаимодействия с пользователями. План также помогает обеспечить четкое взаимодействие о времени выполнения усилий, необходимых для интеграции изменений. В рамках глобальной миграции план должен включать рекомендации для пользователей в каждой затронутой географической области.

Бизнес-тестирование. Для каждого региона также может потребоваться бизнес-тестирование. Бизнес-тестирование помогает обеспечить достаточную производительность и соблюдение измененных шаблонов маршрутизации сети.

Рейсы по продвижению: продвижение часто происходит как одно действие, и рабочий трафик немедленно перенаправляется на перенесенные рабочие нагрузки. В рамках глобальных усилий по выпуску необходимо обеспечить продвижение в предопределенных коллекциях пользователей, которые называются рейсами. Рейсы по продвижению дают команде облачной стратегии и команде по внедрению облака возможность наблюдать за производительностью и повысить поддержку пользователей в каждом регионе. Вы можете контролировать рекламные рейсы на уровне сети. В частности, можно изменить маршрутизацию определенных диапазонов IP-адресов из ресурсов исходной рабочей нагрузки на недавно перенесенные ресурсы. После переноса указанной коллекции пользователей можно перенаправить следующую группу.

Оптимизация полетов: одно из преимуществ рекламных полетов заключается в том, что они дают более глубокие наблюдения и возможность оптимизировать развернутые ресурсы. После того как первый полет успешно использует рабочую среду в течение короткого времени, можно уточнить перенесенные ресурсы при поддержке ИТ-операций.