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

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

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

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

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

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

Необходимые компоненты

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

Подготовить

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

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

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

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

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

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

Зависимости состояния, хранилища и подчиненных зависимостей

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

  Совет

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

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

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

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

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

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

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

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

Сертификаты

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

• Бесплатный управляемый сертификат из Служба приложений не экспортируемый.
• Сертификат Служба приложений через Azure Key Vault можно экспортировать с помощью PS1/CLI.
• Сертификат, управляемый за пределами Служба приложений.
• Сертификат Служба приложений, не управляемый с помощью Azure Key Vault, можно экспортировать.
• Служба приложений ресурсы сертификатов можно переместить в новую группу ресурсов или подписку, но не между регионами. Перемещение между регионами не поддерживается сертификатами Служба приложений.
• Для управления и хранения сертификатов в Azure Key Vault сначала необходимо экспортировать из исходного хранилища ключей и повторно импортировать их в Целевое хранилище ключей, связанное с целевым приложением.

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

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

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

Примечание.

Среда службы приложений является единственным предложением Служба приложений позволяет нижестоящим вызовам подчиненных зависимостей приложений по протоколу SSL, где SSL использует самозаверяющий или PKI с встроенными сертификатами корневого ЦС нестандартного типа. Мультитенантная служба не предоставляет доступ клиентам для отправки в хранилище доверенных сертификатов.

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

Настройка

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

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

• Повторно создайте ссылки Служба приложений Key Vault. Ссылки На Key Vault связаны с уникальным MSI, назначенным ресурсу (который имеет доступ к плоскости данных KV), и сам Key Vault, скорее всего, должен находиться в одном исходном регионе. Содержимое Az Key Vault нельзя экспортировать по географической границе 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 для Среда службы приложений обычно управляется через частное пользовательское решение DNS клиентов (существует переопределение параметров вручную для каждого приложения. Среда службы приложений предоставляет подсистему балансировки нагрузки для входящего или исходящего трафика, а Служба приложений себя фильтрует заголовки узла. Таким образом, несколько пользовательских имен можно указать на одну и ту же Среда службы приложений конечной точке входящего трафика. Среда службы приложений не требует проверки домена.

  Примечание.

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

  Для Среда службы приложений клиент владеет маршрутизацией и, следовательно, ресурсами, используемыми для сокращения. Где бы ни был включен доступ к Среда службы приложений внешним образом, обычно через NVA уровня 7 или обратный прокси-сервер — Диспетчер трафика, или Azure Front Door/Other L7 Global Load Balanceing Service можно использовать.

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

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

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

• Повторно создайте Служба приложений управляемых удостоверений службы в новом целевом регионе.

• Назначьте новый доступ к нижестоящей службе учетных данных MSI (RBAC). Как правило, автоматически созданное приложение идентификатора Microsoft Entra (которое используется EasyAuth) по умолчанию используется для имени ресурса приложения. Здесь может потребоваться рассмотреть вопрос о повторном создании нового ресурса в целевом регионе. Определяемый пользователем субъект-служба будет полезен, так как он может применяться как к источнику, так и к целевому объекту с дополнительными разрешениями на доступ к целевым ресурсам развертывания.

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

• Обновите все ресурсы на Служба приложений, которые могут полагаться на учетные данные FTP Kudu.

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

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

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

Перемещать

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

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

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

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

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

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

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

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

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

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

Совет

При отработки отказа Служба приложений за частными конечными точками можно использовать Диспетчер трафика (ATM). Хотя частные конечные точки недоступны для Диспетчер трафика проб - если все конечные точки ухудшаются, ATM разрешает маршрутизацию. Дополнительные сведения см. в разделе "Управление трафиком службы приложение Azure с помощью Диспетчер трафика Azure".

Проверить

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

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

• Проверьте все компоненты службы приложение Azure и интеграцию.

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

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

Совет

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

Очистка

Удалите исходное приложение и план Службы приложений. За план Службы приложений (не бесплатный) списываются средства, даже если в нем не выполняются какие-либо приложения.

Следующие шаги

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