Перемещение служб приложений Azure в другой регион

В этой статье описывается, как перенести ресурсы Службы приложений в другой регион Azure.

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

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

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

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

Предпосылки

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

Подготовьте

Определите все ресурсы Службы приложений, которые вы используете в настоящее время. Рассмотрим пример.

• Приложения службы приложений
• Планы службы приложений
• Слоты развертывания
• Личные домены, приобретенные в Azure
• TLS/SSL-сертификаты
• Интеграция виртуальной сети Azure
• Гибридные подключения.
• управляемые идентичности
• Параметры резервного копирования

Некоторые ресурсы, например импортированные сертификаты или гибридные подключения, содержат интеграцию с другими службами Azure. Сведения о том, как перемещать эти ресурсы по регионам, см. в документации по соответствующим службам.

Планирование

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

• Состояние, хранилище и зависимые зависимости
• Сертификаты
• Конфигурация
• Подключение к виртуальной сети / пользовательские имена / DNS
• Удостоверения
• Конечные точки службы

Состояние, хранилище и зависимости последующих процессов

• Определите, имеет ли ваше приложение App Service состояние или является без состояния. Хотя мы рекомендуем, чтобы приложения службы приложений были без сохранения состояния, а файлы на %HOME%\site диске содержали только необходимые для запуска развернутого приложения временные файлы, все же возможно хранить состояние во время выполнения приложения на виртуальном %HOME%\site диске. Если приложение записывает состояние в пути к общему хранилищу приложений, обязательно запланируйте способ управления этим состоянием во время перемещения ресурсов.

  Подсказка

  Вы можете использовать Kudu наряду с доступом к порталу, чтобы предоставить API для доступа к файлам (виртуальная файловая система (VFS)), который может читать и записывать файлы в каталоге %HOME%\site. Дополнительные сведения см. вики-сайте Kudu.

• Проверьте наличие внутреннего кэширования и состояния в коде приложения.

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

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

• Анализ внешнего кэширования (например, Redis). Кэши приложений следует развертывать как можно ближе к приложению. Проанализируйте способы заполнения кэшей, политики истечения срока действия и вытеснения, а также влияние холодного кэша на первых пользователей, получающих доступ к рабочей нагрузке после переключения.

• Анализ и планирование зависимостей API (или приложения) Взаимодействие между регионами менее эффективно, если приложение в целевом регионе обращается к зависимостям, которые по-прежнему находятся в исходном регионе. Рекомендуется переместить все подчиненные зависимости в рамках перемещений рабочей нагрузки. Однако *локальные* ресурсы являются исключением, в частности, те ресурсы, которые географически ближе к целевому региону (как это может быть в случае сценариев репатриации).

  Реестр контейнеров Azure (ACR) может служить зависимостью, используемой в процессе выполнения, для App Service, когда он настроен на использование настраиваемых образов контейнеров. Для реестра контейнеров больше смысла находиться в том же регионе, что и само приложение. Рассмотрите возможность загрузки необходимых образов в новый реестр контейнеров в целевом регионе. В противном случае рекомендуется использовать функцию георепликации, если планируется сохранить изображения в исходном регионе.

• Анализ и планирование региональных служб. Данные Application Insights и Log Analytics являются региональными службами. Рассмотрите возможность создания нового хранилища Application Insights и Log Analytics в целевом регионе. Для App Insights новый ресурс также влияет на строку подключения, которую необходимо обновить в рамках изменений в Конфигурации приложений.

Сертификаты

Ресурсы сертификатов в службе приложений можно переместить в новую группу ресурсов или подписку, но не между регионами. Сертификаты, которые можно экспортировать, также можно импортировать в приложение или в Key Vault в новом регионе. Этот процесс экспорта и импорта эквивалентен перемещению между регионами.

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

Некоторые дополнительные моменты, которые следует рассмотреть:

• Назначенные приложения адреса, в которых SSL-подключение приложения службы приложений привязано к определенному IP-адресу приложения, можно использовать для вызовов разрешений из сторонних сетей в службу приложений. Например, администратор сети или ИТ-администратор может заблокировать исходящие вызовы из локальной сети или виртуальной сети для использования статического, хорошо известного адреса. Таким образом, если используется функция назначения адреса приложения, входящие правила брандмауэра, такие как внутренние, внешние или сторонние, для вызывающих лиц в приложении должны быть проверены и должны быть информированы о новом адресе. Правила брандмауэра могут быть внутренними, внешними или относиться к третьим сторонам, например, партнерам или известным клиентам.
• Рассмотрим любой расположенный выше по потоку виртуальный сетевой модуль (NVA) или обратный прокси-сервер. Может потребоваться изменить конфигурацию NVA, если вы перезаписываете заголовок хоста или завершаете SSL-соединение.

Конфигурация

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

• Существующие ссылки Key Vault нельзя экспортировать через географические границы Azure. Необходимо повторно создать все необходимые ссылки в новом регионе.

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

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

Подключение к виртуальной сети / пользовательские имена / DNS

• Среда службы приложений — это служба единого клиента, внедренная в виртуальную сеть. Сеть среды службы приложений отличается от мультитенантной службы приложений, для которой требуется одна или обе "частные конечные точки" или "Интеграция региональной виртуальной сети". Другие варианты, которые могут играть, включают устаревшую интеграцию vpn-сети на основе P2S и гибридные подключения (службу Ретранслятора Azure).

  Примечание.

  Сеть ASEv3 упрощена. Трафик управления Azure и среды служб приложений, имеющие нижестоящие зависимости, не видны виртуальной сети клиента, что значительно упрощает настройку, необходимую для использования принудительного туннеля для всего трафика или отправки подмножества исходящего трафика через сетевое виртуальное устройство/брандмауэр.

  Гибридные подключения (Azure Relay) являются региональными. Если вы используете гибридные подключения, их часто проще повторно развернуть, а не переместить пространство имен Ретранслятора Azure в другой регион, даже если перемещение возможно. Убедитесь, что гибридное подключение настроено в новом регионе при развертывании целевых ресурсов и переподключите его к диспетчеру гибридных подключений. Внимательно рассмотрим расположение диспетчера гибридных подключений.

• Следуйте стратегии для теплого резервного региона. Убедитесь, что основные сети и подключения, сеть концентратора, контроллеры домена, DNS, VPN или Express Route и т. д., присутствуют и проверяются до перемещения ресурсов.

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

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

  • Частная зона DNS
  • Любая жестко закодированная или внешняя конфигурация, ссылающаяся на ресурсы по IP-адресу (без имени узла)
  • Сетевые списки управления доступом, включая группы сетевой безопасности и конфигурацию брандмауэра (также учитывайте влияние на локальные виртуальные сетевые устройства).
  • Все правила маршрутизации, пользовательские таблицы маршрутов

  Кроме того, убедитесь, что проверили конфигурацию, включая диапазоны IP-адресов и сервисные теги для региона, при использовании существующих ресурсов развертывания DevOps.

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

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

  • DNS для среды App Service обычно осуществляется через частное пользовательское решение DNS клиентов (доступна возможность изменения настроек вручную на уровне каждого приложения). App Service Environment предоставляет балансировщик нагрузки для входящего и исходящего трафика, а App Service фильтрует по заголовкам хоста. Таким образом, несколько пользовательских имен можно указать на одну и ту же конечную точку входа среды служб приложений. Среда службы приложений не требует проверки домена.

  Примечание.

  Конечная точка Kudu для среды служб приложений v3 доступна только в {resourcename}.scm.{asename}.appserviceenvironment.net. Дополнительные сведения о среде службы приложений версии 3 DNS и сети и т. д. см. в разделе "Сеть службы приложений".

  Для службы приложений клиент отвечает за маршрутизацию и, следовательно, за ресурсы, используемые для перехода. Где доступ к Среде службы приложений включен для внешнего доступа, обычно через NVA уровня 7 или обратный прокси-сервер — можно использовать Диспетчер трафика, Azure Front Door или другие службы глобальной балансировки нагрузки уровня 7.

• Для общедоступной мультитенантной версии службы имя {resourcename}.azurewebsites.net по умолчанию подготавливается для конечных точек плоскости данных, а также имя по умолчанию для конечной точки Kudu (SCM). Так как служба предоставляет общедоступную конечную точку по умолчанию, привязка должна быть проверена, чтобы подтвердить владение доменом. Однако, после выполнения привязки, повторная проверка не требуется, и это также не требуется для публичных записей DNS, указывающих на endpoint службы приложений.

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

Удостоверения

• Необходимо повторно создать все назначенные системой управляемые удостоверения вместе с приложением в новом целевом регионе. Как правило, автоматически созданное приложение Microsoft Entra ID, используемое в EasyAuth, по умолчанию использует имя ресурса приложения.

• Управляемые удостоверения, назначаемые пользователем, также не могут быть перемещены между регионами. Чтобы сохранить назначаемые пользователем управляемые удостоверения в одной группе ресурсов с приложением, необходимо повторно создать их в новом регионе. Дополнительные сведения см. в статье "Перемещение управляемых удостоверений для ресурсов Azure в другой регион".

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

• Запланируйте перемещение поставщика удостоверений (IDP) в целевой регион. Хотя Microsoft Entra ID является глобальной службой, некоторые решения зависят от локального (или внутренней инфраструктуры) поставщика идентификационных услуг.
• Обновите все ресурсы на Служба приложений, которые могут полагаться на учетные данные FTP Kudu.

Конечные точки службы

Конечные точки службы виртуальной сети для службы приложение Azure ограничивают доступ к указанной виртуальной сети. Конечные точки также могут ограничить доступ к списку диапазонов адресов IPv4 (интернет-протокол версии 4). Любой пользователь, подключающийся к центрам событий за пределами этих источников, запрещен доступ. Если конечные точки службы были настроены в исходном регионе для ресурса Центров событий, то же самое необходимо сделать в целевом.

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

Перемещайте

Для перемещения ресурсов службы приложений можно использовать портал Azure или Инфраструктура как код (IaC).

Перемещение с помощью портала Azure

Самым большим преимуществом использования портал Azure для перемещения является его простота. Приложение, план и содержимое, а также множество параметров клонируются в новый ресурс и план App Service.

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

Чтобы переместить ресурсы службы приложений в новый регион с помощью портала Azure:

1. Создайте резервную копию исходного приложения.
2. Создайте приложение в новом плане Службы приложений в целевом регионе.
3. Восстановите резервную копию в целевом приложении
4. Если вы используете личный домен, своевременно привяжите его к целевому приложению с помощью asuid. и активируйте домен в целевом приложении.
5. Настройте все остальные параметры в целевом приложении так, чтобы они совпадали с параметрами исходного приложения, и проверьте конфигурацию.
6. Когда личный домен будет готов к переносу в целевое приложение, перераспределите доменное имя.

Перемещение с помощью IaC

Используйте IaC, если существует существующий конвейер непрерывной интеграции и непрерывной доставки и развертывания (CI/CD) или может быть создан. С помощью конвейера CI/CD ресурс службы приложений можно создать в целевом регионе с действием развертывания или развертыванием Zip-файла Kudu.

Требования соглашения об уровне обслуживания должны определить, сколько дополнительных усилий требуется. Например: это повторное развертывание с ограниченным временем простоя или требуется ли переключение почти в режиме реального времени с минимальным или совсем без времени простоя?

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

Подтвердить

После завершения перемещения протестируйте и подтвердите службу приложений Azure в соответствии с рекомендуемыми рекомендациями.

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

Очистка

Удалите исходное приложение и план Службы приложений. План службы приложений на нефроплатном уровне несет плату, даже если в нем нет приложения.

Дальнейшие действия

Клонирование приложений службы приложений Azure с помощью PowerShell