你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
选择用于迁移的 Azure 区域
将现有环境迁移到 Azure 时，需要选择一个 Azure 区域或一组区域来托管迁移的组件。 区域选择涉及以下高级步骤：
- 查看核心 Azure 区域选择指南，了解如何选择满足要求的 Azure 区域。
- 清点并记录环境的当前状态 。
- 实现迁移的一般方法 ，包括是在单个区域中运行、使用多个可用性区域还是使用多个区域。
- 评估可能需要的进程更改 。
- 规划迁移过程。
- 优化和提升流程更改。
本文提供有关如何选择满足迁移需求的 Azure 区域的指导。 如果尚未这样做，可能需要扩展 登陆区域区域 以支持多区域方法。
注意
本文介绍特定于工作负荷迁移的注意事项。 还应了解为任何组织或工作负荷选择 Azure 区域的一般原则。 有关详细信息，请参阅 “选择 Azure 区域”。
记录方案复杂性
确定方案是否需要文档和流程一致性。 以下方法有助于评估潜在挑战，并制定通用行动方针：
- 考虑更可靠的就绪性和治理实现。
- 清点受影响的地理区域。 编译受影响国家或地区的列表。
- 记录用户群。 云迁移是否会影响标识国家或地区的员工、合作伙伴或客户？
- 记录数据中心和资产。 迁移工作是否包括标识国家或地区中的任何资产？
- 记录区域产品版本可用性和故障转移要求。
- 记录复原要求 ，以确定是否需要可用性区域。 通常，考虑整个方案的复原要求，而不是针对单个区域。
- 记录主权要求和数据驻留要求。 具有特定主权或数据驻留要求的工作负荷可能会影响你选择的 Azure 区域。
在整个迁移过程中，请考虑如何使各种方案和清单的更改保持一致。 下表显示了如何记录各种方案的示例。
| 区域 | 国家/地区 | 本地员工 | 本地外部用户 | 本地数据中心或资产 | 数据主权要求 |
|---|---|---|---|---|---|
| 北美 | 美国 | 是 | 合作伙伴和客户 | 是 | 否 |
| 北美 | 加拿大 | 否 | 客户 | 是 | 是 |
| 欧洲 | 德国 | 是 | 合作伙伴和客户 | 否 - 仅网络 | 是 |
| 亚太 | 韩国 | 是 | 合作伙伴 | 是 | 否 |
为什么用户位置是相关的？
支持多个国家或地区用户的组织开发解决用户流量的技术解决方案。 在某些情况下，解决方案涉及到资产的本地化。 在其他情况下，此组织可能会选择实现全球广域网络 (WAN) 解决方案，通过以网络为中心的解决方案来处理不同的用户群。 无论哪种情况，不同用户的使用情况配置文件都可能会影响迁移策略。
例如，如果组织支持德国的员工、合作伙伴和客户，但目前德国没有数据中心，则组织可能会实施 租用线路 解决方案。 这种类型的解决方案将流量路由到其他国家或地区的数据中心。 这种现有路由对已迁移应用程序的感知性能有很大风险。 在已建立且优化的全球 WAN 中注入更多跃点，可能会在迁移后造成应用程序性能不佳的感知。 查找并解决这些问题可能会严重增加项目延迟。
以下每个部分都包含有关跨评估、迁移和优化先决条件和过程应对这种复杂性的指导。 了解每个国家/地区中的用户配置文件对于正确管理这种复杂性至关重要。
为什么数据中心位置是相关的？
现有数据中心的位置可能会影响迁移策略。 请考虑下列因素：
体系结构决策：迁移策略设计的第一步是确定目标区域。 现有资产的位置通常影响这种决定。 此外，云服务的可用性以及这些服务的单位成本可能会因区域而异。 数据驻留要求（包括主权要求）也可能会影响体系结构决策。 了解当前和未来的资产的位置会影响体系结构决策，并会影响预算估计。
数据中心依赖项：在“文档方案复杂性”部分中的表中，示例方案显示可能需要规划各种全局数据中心之间的依赖关系。 在此规模上运行的组织可能无法记录或清楚地了解这些依赖项。 组织评估用户配置文件的方法有助于标识组织中的某些依赖关系。 你的团队还应探索更多评估步骤，以帮助缓解依赖项带来的风险和复杂性。
实现常规方法
下面的方法将使用数据驱动模型来应对全球迁移复杂性。 如果迁移范围包含多个区域，云采用团队应评估以下就绪性注意事项：
确定是否可以满足业务需求：使用多个可用性区域来确定高可用性、复原能力、性能和成本的要求。 如果未满足这些要求，请考虑是否需要多区域方法。
评估数据主权：数据主权可能需要本地化某些资产，但许多资产不受这些合规性约束的约束。 日志记录、报告、网络路由、标识和其他中心 IT 服务等服务可能有资格作为跨多个订阅或区域的共享服务进行托管。 使用这些服务的共享服务模型评估数据主权。 有关此方法的概述，请参阅 包含共享服务的中心辐射型拓扑的参考体系结构。
确保环境可缩放：如果部署多个类似环境的实例，则可以为环境的迁移建立专用团队，以帮助创建一致性、改进治理和加速部署。 复杂企业治理指南确立了一种方法，以用于创建跨多个区域缩放的环境。
数据驱动的先决条件
如果团队熟悉基线方法和就绪情况，请考虑以下数据驱动的先决条件：
完成常规发现：完成文档复杂性中的表，以评估云采用策略的复杂性。
分析每个受影响的国家或地区的用户配置文件：了解迁移过程中的常规用户路由非常重要。 更改全局租约线并将 Azure ExpressRoute 等连接添加到云数据中心可能会导致网络延迟数月。 请在此过程中尽早解决用户路由问题。
完成初始数字资产合理化：如果将复杂性引入迁移策略，请完成初始数字资产合理化。 有关详细信息，请参阅什么是数字资产？
对数字资产要求使用标记：建立标记策略以标识受数据主权要求影响的任何工作负载。 确保所需的标记在数字资产合理化中开始，并延续到迁移的资产。
评估中心辐射型模型：分布式系统通常共享公共依赖项。 通常可以通过实现中心辐射型模型来解决共享依赖项问题。 虽然实现中心辐射型模型超出了迁移过程的范围，但应标记该模型，以供在就绪性过程的未来迭代中考虑。
确定迁移积压工作优先级：如果需要网络更改来支持支持多个区域的工作负荷的生产部署，云策略团队应跟踪和管理网络更改导致的升级。 这种更高级别的执行支持通过释放策略团队来重新考虑积压工作并确保网络更改不会阻止全球工作负荷，从而帮助加速变革。 仅当网络更改完成时，才能设置全局工作负载的优先级。
这些先决条件有助于建立能够在迁移策略执行过程中应对这种复杂性的过程。
评估过程变更
如果迁移方案涉及全局资产和用户基础复杂性，请添加关键活动来评估迁移候选项。 这些活动会生成数据，帮助你阐明全球用户和资产的障碍和结果。
评估过程中的建议操作
评估跨数据中心依赖项： Azure Migrate 中的依赖项分析工具可帮助确定依赖项。 在开始迁移之前使用这些工具。 如果方案涉及全局复杂性，则评估依赖项是评估过程中的必要步骤。 可以使用 依赖项分组 可视化依赖项，并确定支持工作负荷所需的任何资产的 IP 地址和端口。
重要
- 你需要一位了解资产放置和 IP 地址架构的主题专家（SME）来识别位于辅助数据中心的资产。
- 评估可视化效果中的下游依赖项和客户端，以了解双向依赖项。
确定全局用户影响：先决条件用户配置文件分析的输出应识别受全局用户配置文件影响的任何工作负荷。 如果迁移候选项位于受影响的工作负荷列表中，迁移架构师应咨询网络和操作中小企业。 这些专家可以帮助验证网络路由和性能预期。 体系结构至少应包括最近的网络运营中心与 Azure 之间的 ExpressRoute 连接。 ExpressRoute 连接的参考体系结构有助于配置必要的网络连接。
符合性设计：先决条件用户配置文件分析的输出还应识别受数据主权要求影响的任何工作负荷。 在评估过程的体系结构活动中，分配的架构师应咨询合规性中小企业。 这些专家可以帮助架构师了解跨多个区域进行迁移和部署的任何要求。 这些要求会显著影响设计策略。 以下参考体系结构可帮助设计：
警告
如果使用 ExpressRoute 的参考体系结构或应用程序的参考体系结构，则可能需要从副本 (replica)过程中排除特定数据元素以满足数据主权要求。 排除特定数据元素的任务会向提升过程添加一个步骤。
迁移过程变更
如果迁移必须部署到多个区域的应用程序，云采用团队必须考虑更多注意事项。 Azure Site Recovery 保管库和配置和进程服务器的设计是其中两个注意事项。 另外两个注意事项是网络带宽设计和数据同步。
迁移过程中建议的操作
Site Recovery 保管库设计：Site Recovery 是云原生副本 (replica)和将数字资产同步到 Azure 的建议工具。 Site Recovery 副本 (replica) Site Recovery 保管库中每个资产的相关数据。 此保管库绑定到特定区域和 Azure 数据中心中的特定订阅。 如果将资产副本 (replica)到第二个区域，则可能还需要另一个 Site Recovery 保管库。
配置和进程服务器设计：Site Recovery 适用于绑定到单个 Site Recovery 保管库的配置和进程服务器的本地实例。 使用此配置时，可能需要在源数据中心安装这些服务器的第二个实例，以便副本 (replica)。
网络带宽设计：在副本 (replica)和持续同步期间，通过网络将二进制数据从源数据中心移动到目标 Azure 数据中心的 Site Recovery 保管库。 副本 (replica)和同步过程消耗带宽。 将工作负荷复制到第二个区域会增加消耗的带宽量。
在某些情况下，带宽受到限制。 其他情况下，工作负荷涉及大量配置或数据偏移。 在这些情况下，将数据副本 (replica)到第二个区域可能会干扰完成迁移所需的时间。 更重要的是，这些约束可能会影响仍依赖于源数据中心中可用带宽的用户或应用程序的体验。
数据同步：最大的带宽消耗通常来自同步数据平台。 如果跨多个可用性区域进行部署，则可以使用区域冗余的数据服务，这些服务可跨多个可用性区域自动同步数据。 跨多个区域的部署通常需要数据同步才能使应用程序保持一致。 此方法在多区域 Web 应用程序和多区域 n 层应用程序的参考体系结构中定义。
如果希望应用程序保持同步的操作状态，则可能需要将源数据平台与每个云平台同步。 在迁移应用程序和中间层资产之前执行此同步。
Azure 到 Azure 灾难恢复：替代选项可能会进一步降低复杂性。 如果使用双重部署来满足时间线和数据同步需求，Azure 到 Azure 灾难恢复可能是可接受的解决方案。 在此方案中，将使用单个 Site Recovery 保管库和配置和进程服务器设计将工作负荷迁移到第一个 Azure 数据中心。 测试工作负载后，可以将其从已迁移的资产恢复到另一个 Azure 数据中心。
此方法可减少对源数据中心中的资源的影响。 Azure 到 Azure 灾难恢复还利用 Azure 数据中心之间的快速传输速度和高带宽限制。
注意
Azure 到 Azure 灾难恢复方法可以通过更高的出口带宽费用增加短期迁移成本。
发布过程更改
在优化和提升过程中解决全局复杂性时，可能需要在部署到的每个区域中进行相同的工作。 如果使用单个区域，则仍可能需要副本 (replica)业务测试和业务更改计划。
发布过程中的建议操作
预测试优化：与任何迁移工作一样，初始自动测试可以发现潜在的优化机会。 对于全局工作负载，请单独测试每个区域中的工作负载。 网络或所选 Azure 数据中心中的少量配置更改可能会影响性能。
业务更改计划：为任何复杂的迁移方案创建业务更改计划。 业务更改计划有助于确保清楚地传达业务流程和用户体验的更改。 该计划还有助于确保明确沟通集成更改所需的工作时间。 如果是全球迁移工作，则计划应考虑到每个受影响地理区域内的用户。
业务测试：每个区域可能还需要业务测试。 业务测试有助于确保有足够的性能和遵守修改的网络路由模式。
促销外部测试版：升级通常作为单个活动进行，生产流量会立即重新路由到已迁移的工作负荷。 在全局发布努力中，应在称为 外部测试版的用户的预定义集合中提供促销。 升级外部测试版使云策略团队和云采用团队有机会观察性能并提高对每个区域中用户的支持。 可以在网络级别控制促销航班。 具体而言，可以将特定 IP 范围的路由从源工作负荷资产更改为新迁移的资产。 迁移指定的用户集合后，可以重新路由下一个组。
航班优化：促销航班的一个好处是，它们提供更深入的观察和优化已部署资产的机会。 在首个外部测试版成功短暂使用生产后，可以在 IT 操作程序支持的情况下对迁移的资产进行优化。