将 Azure 应用服务重定位到另一个区域

本文介绍了如何将应用服务资源移动到其他 Azure 区域。

出于多种原因，你可能希望将现有 Azure 资源从一个区域移到另一个区域。 你可以采取以下建议：

• 利用新的 Azure 区域。
• 部署仅在特定区域可用的功能和服务。
• 满足内部策略和治理要求。
• 与公司合并和收购保持一致
• 满足容量计划要求。

应用服务资源是特定于区域的，不能跨区域移动。 必须在目标区域中创建现有应用服务资源的副本，然后将内容重定位到新应用。 如果你的源应用使用自定义域，可在完成重定位后，将其迁移到目标区域中的新应用。

为了更轻松地复制应用，可将个体应用服务应用备份和还原到另一个区域中的应用服务计划。

先决条件

• 确保应用服务应用位于要从中进行移动的 Azure 区域中。
• 确保目标区域支持你要移动其资源的应用服务和任何相关服务。
• 验证是否有足够的权限将应用服务资源部署到目标订阅和区域。
• 验证是否为任何 Azure 策略分配了区域限制。
• 考虑任何运营成本，因为计算资源价格可能因区域而异。 若要估算可能的成本，请参阅定价计算器。

准备

查明你当前正在使用的所有应用服务资源。 例如：

• 应用服务应用
• 应用服务计划
• 部署槽位
• 在 Azure 中购买的自定义域
• TLS/SSL 证书
• Azure 虚拟网络集成
• 混合连接。
• 托管标识
• 备份设置

某些资源（例如导入的证书或混合连接）包含与其他 Azure 服务的集成。 有关如何跨区域移动这些资源的信息，请参阅相应服务的文档。

计划

本节是以下方面的规划清单：

• 状态、存储和下游依赖项
• Certificates
• 配置
• VNet 连接/自定义名称/DNS
• 标识
• 服务终结点

状态、存储和下游依赖项

• 确定应用服务应用是有状态还是无状态。 尽管我们建议应用服务应用为无状态，并且 %HOME%\site 驱动器上的文件应仅是运行已部署的应用程序所需的文件及任何临时文件，但仍可将运行时应用程序状态存储在 %HOME%\site 虚拟驱动器上。 如果应用程序在应用共享存储路径上写入状态，请确保计划你将如何在资源移动期间管理该状态。

  提示

  可使用 Kudu 和门户访问权限来提供文件访问 API（虚拟文件系统 (VFS)），该 API 可读取/写入 %HOME%\site 目录下的文件。 有关详细信息，请参阅 Kudu Wiki。

• 检查应用程序代码中的内部缓存和状态。

• 禁用会话亲和性设置。 在可能的情况下，建议禁用会话亲和性设置。 禁用会话亲和性可提高横向扩展的负载均衡。任何内部状态都可能会影响直接转换工作负载的规划（特别是在要求零停机时间的情况下）。 在可能的情况下，重构任何应用程序状态以使应用程序无状态，为移动做准备，这可能是有益的。

• 分析数据库连接字符串。 可在应用设置中找到数据库连接字符串。 但是，它们也可能在应用程序随附的配置文件中进行硬编码或管理。 在更高级别的移动工作负载规划中，分析和计划数据迁移/复制。 对于聊天式或延迟关键型应用程序，目标区域中的应用程序返回到源区域中的数据源的性能不佳。

• 分析外部缓存（例如 Redis）。 应尽可能接近应用程序部署应用程序缓存。 分析缓存的填充方式、过期/逐出策略以及冷缓存在直接转换后对第一个用户访问工作负载的影响。

• 分析和计划 API（或应用程序）依赖项。如果目标区域中的应用返回到仍在源区域中的依赖项，则跨区域通信的性能会显著降低。 建议在工作负载重定位过程中重定位所有下游依赖项。 但是，*本地*资源是例外，特别是那些在地理上更接近目标区域的资源（遣返场景可能就是这种情况）。

  Azure 容器注册表可以是配置为针对自定义容器映像运行的应用服务的下游（运行时）依赖项。 容器注册表与应用本身位于同一区域更有意义。 请考虑将所需的映像上传到目标区域中的新 ACR。 否则，如果计划将映像保留在源区域中，请考虑使用异地复制功能。

• 分析和计划区域服务。 Application Insights 和 Log Analytics 数据是区域服务。 请考虑在目标区域中创建新的 Application Insights 和 Log Analytics 存储。 对于 App Insights，新资源也会影响必须作为应用配置更改的一部分进行更新的连接字符串。

Certificates

应用服务证书资源可移动到新的资源组或订阅，但不能跨区域移动。 可以导出的证书也可以导入到应用或新区域的 Key Vault 中。 此导出和导入过程等效于区域之间的移动。

计划服务重定位时，需要考虑许多不同类型的证书：

要考虑的一些其他要点：

• 应用分配的地址（其中应用服务应用的 SSL 连接绑定到特定应用指定 IP）可用于允许将来自第三方网络的调用列入应用服务。 例如，网络/IT 管理员可能需要锁定来自本地网络或 VNet 的出站调用，以使用静态已知地址。 因此，如果“应用分配的地址”功能正在使用中，应检查进入应用的调用方的上游防火墙规则（如内部、外部或第三方），并告知新地址。 防火墙规则可以是内部、外部或第三方，例如合作伙伴或知名客户。

• 请考虑任何上游网络虚拟设备 (NVA) 或反向代理。 如果要重写主机头和/或 SSL 终止，则 NVA 配置可能需要更改。

配置

• 可以从 Azure 门户捕获现有应用设置和连接字符串的快照。 展开“设置”>“环境变量”，选择“应用设置”或“连接字符串”下的“高级编辑”，并保存包含现有设置或连接的 JSON 输出。 需要在新区域中重新创建这些设置，但这些值本身可能会由于连接服务中的后续区域更改而更改。

• 无法跨 Azure 地理边界导出现有 Key Vault 引用。 必须在新区域中重新创建任何必需的引用。

• 应用配置可以通过 Azure 应用程序配置或其他一些中心（下游）数据库依赖项进行管理。 查看任何应用程序配置存储区或类似的存储区，了解可能需要修改的环境和特定于区域的设置。

• 确保检查任何磁盘文件配置，该配置可能会也可能不会被应用程序设置替代。

VNet 连接/自定义名称/DNS

• 应用服务环境是 VNet 注入单租户服务。 应用服务环境网络不同于多租户应用服务，后者需要一个或两个“专用终结点”或“区域 VNet 集成”。 其他可能正在发挥作用的选项包括基于旧版 P2S VPN 的 VNet 集成和混合连接（Azure 中继服务）。

  注意

  ASEv3 网络得到简化 - Azure 管理流量和应用服务环境自身的下游依赖项对客户虚拟网络不可见，这大大简化了客户对所有流量使用强制隧道或通过网络虚拟设备/防火墙发送一部分出站流量所需的配置。

  混合连接（Azure 中继）是区域性连接。 如果使用混合连接，尽管 Azure 中继命名空间可移动到另一个区域，但重新部署混合连接（确保在部署目标资源时在新区域中设置混合连接），并将其重新链接到混合连接管理器会更简单。 应仔细考虑混合连接管理器位置。

• 遵循热备用状态区域的策略。 确保核心网络和连接、中心网络、域控制器、DNS、VPN 或 Express Route 等存在，并在资源重定位之前进行测试。

• 验证任何上游或下游网络 ACL 和配置。 例如，考虑一个仅将你的应用流量列入允许列表的外部下游服务。 针对多租户应用服务的向新应用计划的重定位也将是出站 IP 地址的变化。

• 在大多数情况下，最好确保目标区域 VNet 具有唯一的地址空间。 例如，如果需要复制数据，唯一的地址空间有助于实现 VNet 连接。 因此，在这些场景中，有一个隐含要求以更改：

  • 专用 DNS
  • 按 IP 地址（没有主机名）引用资源的任何硬编码或外部配置
  • 网络ACL，包括网络安全组和防火墙配置（此处也考虑对任何本地 NVA 的影响）
  • 任何路由规则、用户定义的路由表

  此外，如果继续使用现有的 DevOps 部署资源，请确保检查配置，包括区域特定的 IP 范围/服务标记。

• 对于为 Azure 域和 Azure DNS 专用区域配置为转发到 Azure 的客户部署的专用 DNS，需要的更改较少。 但是，由于专用终结点基于资源 FQDN，且这通常也是资源名称（预期在目标区域中可能有所不同），请记住交叉检查配置，以确保在配置中引用的 FQDN 相应地更新。

• 在目标区域中重新创建专用终结点（如使用）。 这同样适用于区域 VNet 集成。

• 应用服务环境的 DNS 通常通过客户专用自定义 DNS 解决方案进行管理（每个应用都有一个手动设置替代）。 应用服务环境为入口/出口提供负载均衡器，而应用服务本身对主机头进行筛选。 因此，可将多个自定义名称指向同一应用服务环境入口终结点。 应用服务环境不需要域验证。

  注意

  应用服务环境 v3 的 Kudu 终结点仅在 {resourcename}.scm.{asename}.appserviceenvironment.net 提供。 有关应用服务环境 v3 DNS 和网络等的详细信息，请参阅应用服务环境网络。

  对于应用服务环境，客户拥有该路由，因此拥有用于直接转换的资源。 只要从外部启用了对应用服务环境的访问权限（通常通过第 7 层 NVA 或反向代理），就可以使用流量管理器或 Azure Front Door/其他 L7 全局负载均衡服务。

• 对于服务的公共多租户版本，为数据平面终结点预配一个默认名称 {resourcename}.azurewebsites.net，并为 Kudu (SCM) 终结点预配一个默认名称。 由于服务默认提供公共终结点，因此必须验证绑定以证明域所有权。 但是，绑定到位后，不需要重新验证，也不需要公共 DNS 记录指向应用服务终结点。

• 如果你使用自定义域，将其预先绑定到目标应用。 在目标应用中验证并启用域。

标识

• 需要重新创建任何系统分配的托管标识，以及新目标区域中的应用。 通常，自动创建的 Microsoft Entra ID 应用（EasyAuth 使用的应用）默认为应用资源名称。

• 用户分配的托管标识也不能跨区域移动。 若要将用户分配的托管标识保留在应用的同一资源组中，必须在新区域中重新创建它们。 有关详细信息，请参阅将 Azure 资源托管标识重定位到另一区域。

• 在重定位的服务中，向托管标识授予与要替换的原始标识相同的权限，包括组成员身份。

• 计划将标识提供者 (IDP) 重定位到目标区域。 尽管 Microsoft Entra ID 是一项全局服务，但某些解决方案依赖于本地（或下游）IDP。

• 将任何资源更新到可能依赖于 Kudu FTP 凭据的应用服务。

服务终结点

Azure 应用服务的虚拟网络服务终结点限制对指定虚拟网络的访问。 此外，还可通过这些终结点将访问限制为一系列 IPv4（Internet 协议版本 4）地址范围。 任何从外部连接到事件中心的用户都无法访问这些资源。 如果在事件中心资源的源区域中配置了服务终结点，则需要在目标区域中执行相同的操作。

若要成功将 Azure 应用服务重新创建到目标区域，必须事先创建 VNet 和子网。 如果使用 Azure 资源转移器工具执行所有这些资源的移动，则不会自动配置服务终结点。 因此，需要手动配置服务终结点，这可以通过 Azure 门户、Azure CLI 或 Azure PowerShell 来完成。

重定位

若要重定位应用服务资源，可使用 Azure 门户或基础结构即代码 (IaC)。

使用 Azure 门户进行重定位

使用 Azure 门户进行重定位的最大优势是其简单性。 应用、计划和内容以及许多设置将被克隆到新的应用服务资源和计划中。

请记住，对于应用服务环境（独立）层，首先需要在另一个区域中重新部署整个应用服务环境，然后便可开始在新区域中的新应用服务环境中重新部署各个计划。

使用 Azure 门户将应用服务资源重定位到新区域：

1. 创建源应用的备份。
2. 在目标区域中的新应用服务计划中创建一个应用。
3. 在目标应用中还原备份
4. 如果你使用自定义域，请使用 asuid.提前将其绑定到目标应用，并在目标应用中启用该域。
5. 将目标应用中的其他所有内容配置为与源应用相同，并验证你的配置。
6. 当你已准备好将自定义域指向目标应用时，重新映射域名。

使用 IaC 进行重定位

当存在现有持续集成和持续交付/部署 (CI/CD) 管道或可创建该管道时，使用 IaC。 有了 CI/CD 管道，便可通过部署操作或 Kudu zip 部署在目标区域创建应用服务资源。

SLA 要求应确定需要多少额外的工作。 例如：这是一次停机时间有限的重新部署，还是一次几乎没有停机时间的所需准实时直接转换？

包含外部、全局流量路由边缘服务（例如流量管理器或 Azure Front Door）有助于促进外部用户和应用程序的直接转换。

Validate

完成重定位后，使用推荐的准则测试和验证 Azure 应用服务：

• 将 Azure 应用服务重定位到目标区域后，运行冒烟测试和集成测试。 可手动测试或通过脚本运行测试。 确保验证所有配置和依赖资源已正确链接，以及所有已配置的数据都可访问。

• 验证所有 Azure 应用服务组件和集成。

• 对目标区域部署执行集成测试，包括所有正式回归测试。 集成测试应与适用于工作负载的业务部署和测试流程的常规节奏保持一致。

• 在某些情况下，特别是在重定位包括更新、对应用程序或 Azure 资源的更改或使用情况配置文件中的更改的情况下，使用负载测试来验证新的工作负载是否符合目的。 负载测试也是验证操作和监视覆盖范围的机会。 例如，使用负载测试来验证所需的基础结构和应用程序日志是否正确生成。 应根据已建立的工作负载性能基线来衡量负载测试。

清理

删除源应用和应用服务计划。 非免费层级中的应用服务计划会产生费用，即使其中没有正在运行的应用也是如此。

后续步骤

使用 PowerShell 克隆 Azure 应用服务应用