你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
在迁移之前设计工作负荷体系结构
本文介绍在云中设计工作负荷的预期迁移状态的过程和注意事项。 本文回顾了在迭代中定义工作负荷体系结构的一部分的活动。
有关 增量合理化 的文章表明，某些体系结构假设是包括迁移的任何业务转换的一部分。 本文阐明了典型假设。 它还指出了一些可以避免的障碍，它通过挑战体系结构假设来识别加速业务价值的机会。 此用于设计体系结构的增量模型可帮助团队更快地移动并更快地获得业务成果。
基于常见假设的基本体系结构设计
以下假设对于任何迁移工作都是典型的：
- 假设基础结构即服务（IaaS）工作负荷。 迁移工作负荷主要涉及通过 IaaS 迁移将服务器从物理数据中心移动到云数据中心。 此过程通常需要最少的重新开发或重新配置。 此方法称为 直接迁移和迁移 。
- 使体系结构保持一致。 在迁移期间对核心体系结构进行更改会大大增加复杂性。 在新平台上调试变更后的系统会引入许多难以隔离的变量。 工作负荷在迁移期间应仅经历轻微更改，并且任何更改都应经过全面测试。
- 计划调整资产大小。 假设很少有本地资产完全使用任何资源。 在迁移之前或迁移期间，将调整资产大小，以最符合实际使用要求。 Azure Migrate 和现代化等工具根据实际用途提供大小调整。
- 捕获业务连续性和灾难恢复（BCDR）要求。 如果已与业务协商的工作负荷达成了一致的服务级别协议（SLA），请在迁移到 Azure 后继续使用 SLA。 如果尚未设置 SLA，请在设计云中的工作负荷之前定义一个 SLA，以确保进行适当的设计。
- 规划迁移停机时间。 与未能满足 SLA 要求一样，将工作负荷提升到生产环境时发生的停机可能会对业务产生负面影响。 有时，必须以最短停机时间进行转换的解决方案需要体系结构更改。 在开始发布规划之前，假设已大致了解停机时间要求。
- 定义用户和应用程序流量模式。 现有解决方案可能依赖于现有的网络路由模式和解决方案。 确定支持当前网络使用情况所需的资源。
- 计划避免网络冲突。 将数据中心合并到单个云提供商中时，可能会在域名系统（DNS）或其他网络结构中创建冲突。 在迁移过程中，请务必避免这些冲突，以避免云中托管的生产系统的中断。
- 规划路由表。 如果合并网络或数据中心，请确保项目包含用于修改路由表的计划。 考虑跨数据中心路由要求。
登陆区域的设计体系结构
在云采用框架就绪阶段，组织部署了共享平台服务，作为采用 Azure 登陆区域的一部分。 在 “准备好登陆区域进行迁移”中，准备登陆区域以接收已迁移的工作负荷。
根据此规划，可以假定以下迁移组件已到位：
- 混合连接将 Azure 网络连接到本地网络。
- 网络安全设备（例如Azure 防火墙处理工作负荷外流量的检查。
- 用于强制实施治理做法的 Azure 策略，例如日志记录要求、允许的区域、不允许的服务和其他控制措施都处于活动状态。
- Azure Monitor 中设置了用于共享日志记录的 Azure Monitor 日志工作区。
- 建立共享标识资源以支持已加入域的服务器或其他标识需求。
如果未建立这些迁移概要，你的组织应立即重新访问“就绪”阶段以满足这些需求。 如果没有这些组件，迁移可能会有延迟和挫折，并且不太成功。
你设计的工作负荷已为其分配了订阅，理想情况下，通过订阅自动售货过程。 订阅可能包含多个工作负荷或仅包含一个工作负荷，具体取决于组织如何完成工作负荷的资源组织。 如果迁移具有许多应用程序环境的工作负荷，则甚至可以根据应用程序环境的指南有多个订阅。
设计工作负荷网络体系结构
计划将应用程序特定的资源部署到特定订阅，并计划为工作负荷设计专用虚拟网络。 有关详细信息，请参阅有关设计网络体系结构的指南。 应特别注重 对虚拟网络进行分段。
网络可能需要负载均衡器和其他应用程序交付资源等资源。 可以使用 N 层体系结构指南 在 Azure 中规划这些资源。
设计工作负荷依赖项
迁移评估工具应该为你提供一种执行依赖项分析的方法，例如 Azure Migrate 和现代化中的依赖项分析 。 该工具可帮助你识别服务器之间的相互依赖关系。
除了规划工作负荷本身的体系结构之外，可能需要考虑工作负荷到工作负荷的依赖关系。 例如，某些工作负荷可能需要频繁通信。 如果是这样，请规划迁移波和依赖项来考虑此要求有助于使迁移成功。
可以使用 Azure 体系结构中心（例如 辐射到辐射 型网络）中的指南来设计迁移后互连工作负载的工作方式。
准备采用机密计算
具有主权要求的工作负荷的子集可能会导致使用机密计算。 作为主权登陆区域部署的一部分，将创建用于机密计算的管理组。
在主权上下文中，使用机密计算需要 Azure 密钥库 和客户管理的密钥作为支持服务。 有关详细信息，请参阅 使用 Microsoft Cloud for Sovereignty 中的客户管理的密钥进行加密。
更新初始云估算
完成体系结构设计后，请重新访问云估算，以确保仍处于计划预算范围内。 添加负载均衡器或备份等支持服务时，成本可能会发生变化。 尽管可以使用 Azure Migrate 和现代化中的业务案例等工具执行详细的成本管理练习，但在调整体系结构设计时，应定期重新审视估算值。
如果你熟悉传统的 IT 采购流程，估计云中的资源可能看起来很陌生。 采用云技术时，购置从刚性结构化资本支出模型转变为流畅的运营费用模型。 规划到云的迁移通常是组织或 IT 团队首次遇到此更改。
在传统的资本支出模型中，IT 团队尝试将各种计划中多个工作负荷的购买能力结合起来。 此方法集中了一组可支持这些解决方案的共享 IT 资产池。 在运营费用云模型中，成本可以直接归因于单个工作负荷、团队或业务部门的支持需求。 它使组织能够更直接地将成本归因于内部客户及其支持的业务目标。 这种更动态的财务管理方法通常称为财务运营（FinOps）。 尽管 FinOps 不是特定于 Azure 的注意事项，但对 FinOps 有一个扩展的理解会很有帮助。 有关详细信息，请参阅 什么是 FinOps？。
设计用于迁移的 工作负荷体系结构时，可以将定价计算器 与评估信息一起使用，以了解整个工作负荷的价格。
此外，迁移工作负荷后，应继续工作以优化工作负荷成本。 有关组织如何成熟其成本管理技能的详细信息，请参阅 改进成本管理规则。
了解何时更改体系结构
迁移往往侧重于维护现有体系结构并将其过渡到云平台。 但是，有时可能需要重新架构工作负荷，甚至进行迁移。 此列表提供了在迁移之前可能需要进行体系结构更改的示例：
- 偿还技术债务。 一些老化的工作负荷携带大量技术债务。 技术债务可能会增加任何云提供商的托管成本，进而带来长期挑战。 当技术债务不自然地增加托管成本时，应评估替代体系结构。
- 提高可靠性。 标准操作基线在云中提供一定程度的可靠性和恢复。 某些工作负荷团队可能需要更高的 SLA，这可能会导致体系结构更改。
- 高成本工作负荷。 在迁移期间，应优化所有资产，使其大小与实际使用情况保持一致。 某些工作负荷可能需要进行体系结构修改才能解决特定的成本问题。
- 性能要求。 当工作负荷性能直接影响业务时，可能需要额外的体系结构注意事项。
- 保护应用程序。 安全要求往往集中实施，通常应用于项目组合中的所有工作负荷。 某些工作负荷可能有特定的安全要求，可能会导致体系结构更改。
其中每个条件都可用作潜在迁移障碍的指示器。 在大多数情况下，可以通过正确调整服务器大小、添加新服务器或进行其他更改来迁移工作负荷后解决条件。 但是，如果在迁移工作负荷之前需要这些条件中的任何一个，请从迁移波中删除工作负荷并单独对其进行评估。
Azure 良好架构框架和 Azure 良好架构评审可以帮助指导与特定工作负荷的技术所有者进行对话，帮助他们考虑部署工作负荷的替代选项。
然后，工作负荷被归类为云采用计划中重新架构或现代化工作。 由于重新构建工作负荷需要额外的时间，因此将这些备用工作负荷采用路径视为独立于迁移过程。
体系结构检查列表
可以使用以下检查列表来确保涵盖关键体系结构注意事项：
- 确认体系结构满足可用性、灾难恢复和数据恢复的 SLA。
- 确认已将网络分段做法应用于网络设计。
- 确认你计划进行监视和日志捕获。
- 确认虚拟机的大小是否适合所需的实际计算时间。
- 确认磁盘的大小是否适合所需的实际大小和性能。
- 确认你已计划进行负载均衡服务（如果需要）。 这些服务可能包括Azure 负载均衡器、Azure 应用程序网关、Azure Front Door 或Azure 流量管理器实例。
- 确认计划满足主权和机密计算要求（如果需要）。