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

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

出于多种原因，你可能希望将现有 Azure 资源从一个区域移到另一个区域。 您可能想要：

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

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

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

先决条件

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

准备

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

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

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

计划

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

• 状态、存储和下游依赖项
• 证书
• 配置
• 虚拟网络连接/自定义名称/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，新资源也会影响必须作为应用配置更改的一部分进行更新的连接字符串。

证书

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

在计划服务迁移时，需要考虑不同类型的证件：

证书类型	可出口的	注释
托管的应用服务	否	在新区域重新创建这些证书。
托管的 Azure Key Vault	是的	这些证书可以从 Key Vault 导出，然后在新的区域导入到 Key Vault。
私钥（自托管）	是的	可以从应用服务导出在 Azure 外部获取的证书，然后将其导入到新应用或新区域中的 Key Vault。
公钥	否	你的应用可能拥有只有公钥而没有私钥的证书，这些证书用于访问其他安全终结点。 获取所需的公钥证书文件，并将其导入新区域中的应用。

要考虑的一些其他要点：

• 应用分配的地址（其中应用服务应用的 SSL 连接绑定到特定应用指定 IP）可用于允许将来自第三方网络的调用列入应用服务。 例如，网络/IT 管理员可能需要锁定来自本地网络或虚拟网络的出站呼叫，以使用静态已知地址。 因此，如果“应用分配的地址”功能正在使用中，应检查进入应用的调用方的上游防火墙规则（如内部、外部或第三方），并告知新地址。 防火墙规则可以是内部、外部或第三方，例如合作伙伴或知名客户。
• 请考虑任何上游网络虚拟设备 (NVA) 或反向代理。 如果您正在重写主机头或执行 SSL 卸载，则可能需要更改 NVA 配置。

注释

应用服务环境是唯一允许通过 SSL 对下游应用程序依赖项进行下游调用的应用服务产品/服务，其中 SSL 依赖于自签名证书/使用非标准根 CA 证书生成的 PKI。 多租户服务不为客户提供将文件上传到可信证书存储的功能。

应用服务环境目前不允许购买 SSL 证书，只允许自带证书。 IP-SSL 是不可能的（而且没有意义），但 SNI 是。 内部应用服务环境不会与公共域相关联，因此必须使用的 SSL 证书由客户提供，因此是可传输的，例如使用 PKI 生成的内部使用的证书。 外部模式下的应用服务环境 v3 与常规多租户应用服务共享相同的功能。

配置

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

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

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

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

虚拟网络连接/自定义名称/DNS

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

  注释

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

  混合连接（Azure 中继）是区域性连接。 如果使用混合连接，通常更简单的方法是重新部署，而不是将 Azure 中继命名空间移动到另一个区域，尽管移动是可能的。 确保在部署目标资源时在新区域中配置混合连接，并将其重新链接到混合连接管理器。 请务必仔细考虑混合连接管理器的位置。

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

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

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

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

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

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

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

  • 应用服务环境的 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 应用服务重新创建到目标区域，必须事先创建虚拟网络和子网。 如果使用 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），有助于为外部用户和应用程序实现顺利切换。

小窍门

在专用终结点后对应用服务进行故障转移时，可使用流量管理器 (ATM)。 尽管流量管理器探测器无法访问专用终结点，但如果所有终结点都出现故障，ATM 仍然允许路由。 有关详细信息，请参阅使用 Azure 流量管理器控制 Azure 应用服务流量。

驗證

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

• 将 Azure 应用服务重定位到目标区域后，运行冒烟测试和集成测试。 可手动测试或通过脚本运行测试。 确保验证所有配置和依赖资源已正确链接，以及所有已配置的数据都可访问。
• 验证所有 Azure 应用服务组件和集成。
• 对目标区域部署执行集成测试，包括所有正式回归测试。 集成测试应与适用于工作负载的业务部署和测试流程的常规节奏保持一致。
• 在某些情况下，特别是在重定位包括更新、对应用程序或 Azure 资源的更改或使用情况配置文件中的更改的情况下，使用负载测试来验证新的工作负载是否符合目的。 负载测试也是验证操作和监视覆盖范围的机会。 例如，使用负载测试来验证所需的基础结构和应用程序日志是否正确生成。 应根据已建立的工作负载性能基线来衡量负载测试。

小窍门

应用服务重定位也是重新评估可用性和灾难恢复规划的机会。 应用服务和应用服务环境（应用服务环境 v3）支持 可用性区域 ，建议使用可用性区域配置进行配置。 请记住部署、定价和限制的先决条件，并将这些条件纳入资源移动规划。 有关可用性区域和应用服务的详细信息，请参阅 Azure 应用服务中的可靠性。

清除

删除源应用和应用服务计划。 非自由层中的应用服务计划会产生费用，即使其中未运行任何应用。

后续步骤

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