在迁移之前设计工作负荷体系结构

本文介绍在云中设计工作负荷的预期迁移状态的过程和注意事项。 本文回顾了在迭代中定义工作负荷体系结构的一部分的活动。

有关 增量合理化 的文章表明，某些体系结构假设是包括迁移的任何业务转换的一部分。 本文阐明了典型假设。 它还指出了一些可以避免的障碍，它通过挑战体系结构假设来识别加速业务价值的机会。 此用于设计体系结构的增量模型可帮助团队更快地移动并更快地获得业务成果。

基于常见假设的基本体系结构设计

对于任何迁移工作，以下假设都是典型的：

• 假设一个基础设施即服务（IaaS）工作负载。 迁移工作负荷主要涉及通过 IaaS 迁移将服务器从物理数据中心移动到云数据中心。 此过程通常需要最少的重新开发或重新配置。 此方法称为 搬迁迁移 。
• 使体系结构保持一致。 在迁移期间对核心体系结构进行更改会大大增加复杂性。 在新平台上调试已更改的系统会引入许多难以隔离的变量。 工作负荷在迁移期间应仅经历轻微更改，并且任何更改都应经过全面测试。
• 计划调整资产大小。 假设几乎没有现场资产能够完全利用任何资源。 在迁移之前或迁移期间，将调整资产大小，以最符合实际使用要求。 Azure Migrate 和 Modernize 等工具根据实际使用情况提供大小调整建议。
• 收集业务连续性和灾难恢复（BCDR）要求。 如果您已与企业就工作负载协商了服务级别协议（SLA），请在迁移到 Azure 后继续使用该协议。 如果尚未设置 SLA，请在设计云中的工作负荷之前定义一个 SLA，以确保进行适当的设计。
• 迁移过程中停机时间的规划。 与未能满足 SLA 要求一样，将工作负荷提升到生产环境时发生的停机可能会对业务产生负面影响。 有时，必须以最短停机时间进行转换的解决方案需要体系结构更改。 在开始发布规划之前，假设已大致了解停机时间要求。
• 定义用户和应用程序流量模式。 现有解决方案可能依赖于现有的网络路由模式和解决方案。 确定支持当前网络使用情况所需的资源。
• 计划避免网络冲突。 将数据中心合并到单个云提供商中时，可能会在域名系统（DNS）或其他网络结构中创建冲突。 在迁移过程中，设计时务必规避这些冲突，以防止云中托管的生产系统中断。
• 规划路由表。 如果合并网络或数据中心，请确保项目包含用于修改路由表的计划。 考虑跨数据中心路由要求。

登陆区域的设计体系结构

在云采用框架的 “就绪”阶段 ，组织部署了共享平台服务，作为采用 Azure 登陆区域的一部分。 在准备好你的登陆区域以进行迁移中，你已经准备好登陆区域，以接收迁移后的工作负载。

根据此规划，可以假定以下迁移组件已到位：

• 混合连接将 Azure 网络连接到本地网络。
• Azure 防火墙等网络安全设备处理工作负荷外部流量的检查。
• 用于强制实施治理做法的 Azure 策略，例如日志记录要求、允许的区域、不允许的服务和其他控制措施都处于活动状态。
• Azure Monitor 中设置了用于共享日志记录的 Azure Monitor 日志工作区。
• 为了支持已加入域的服务器或其他标识需求，已建立共享标识资源。

如果未建立这些迁移要素，你的组织应立即重新审视“就绪”阶段以满足这些需求。 如果没有这些组件，迁移可能会有延迟和挫折，并且不太成功。

你正在设计的工作负载已为其分配了订阅，理想情况下，通过 订阅的售货过程。 订阅可能包含多个工作负荷或仅包含一个工作负荷，具体取决于组织 如何完成工作负荷的资源组织。 如果迁移具有许多应用程序环境的工作负荷，则甚至可以根据 应用程序环境的指南有多个订阅。

设计工作负荷网络体系结构

计划将应用程序特定的资源部署到特定订阅，并计划为工作负荷设计专用虚拟网络。 有关详细信息，请参阅 有关设计网络体系结构的指南。 应特别注重 对虚拟网络进行分段。

网络可能需要负载均衡器和其他应用程序交付资源等资源。 可以使用 N 层体系结构指南 在 Azure 中规划这些资源。

设计工作负荷依赖项

迁移评估工具应该为你提供一种执行依赖项分析的方法，例如 Azure Migrate 和现代化中的 依赖项分析 。 该工具可帮助你识别服务器之间的相互依赖关系。

除了规划工作负荷本身的体系结构之外，可能需要考虑工作负荷到工作负荷的依赖关系。 例如，某些工作负荷可能需要频繁通信。 如果是这样，那么规划迁移波次和依赖关系，以满足此要求，有助于确保迁移的成功。

可以使用 Azure 体系结构中心（例如 辐射到辐射 型网络）中的指南来设计迁移后互连工作负载的工作方式。

准备采用机密计算

具有主权要求的工作负荷子集可能需要使用机密计算。 作为主权登陆区域部署的一部分，将创建用于机密计算的管理组。

在主权上下文中，使用机密计算需要 Azure Key Vault 和客户管理的密钥作为支持服务。 有关详细信息，请参阅 Microsoft Cloud for Sovereignty 中使用客户管理的密钥进行加密。

更新初始云估算

完成体系结构设计后，请重新访问云估算，以确保仍处于计划预算范围内。 添加负载均衡器或备份等支持服务时，成本可能会发生变化。 尽管可以使用 Azure Migrate 和现代化中的 业务案例 等工具执行详细的成本管理练习，但在调整体系结构设计时，应定期重新审视估算值。

如果你熟悉传统的 IT 采购流程，估计云中的资源可能看起来很陌生。 采用云技术时，购置从刚性结构化资本支出模型转变为流畅的运营费用模型。 规划到云的迁移通常是组织或 IT 团队首次遇到此更改。

在传统的资本支出模型中，IT 团队尝试将各种计划中多个工作负荷的购买能力结合起来。 此方法集中了一组可支持这些解决方案的共享 IT 资产池。 在运营费用云模型中，成本可以直接归因于单个工作负荷、团队或业务部门的支持需求。 它使组织能够更直接地将成本归因于内部客户及其支持的业务目标。 这种更动态的财务管理方法通常称为 FinOps。 尽管 FinOps 不是特定于 Azure 的注意事项，但对 FinOps 有一个扩展的理解会很有帮助。 有关详细信息，请参阅 什么是 FinOps？。

设计用于迁移的工作负荷体系结构时，可以将 定价计算器 与评估信息一起使用，以了解整个工作负荷的价格。

此外，迁移工作负荷后，应继续工作以优化工作负荷成本。 有关组织如何成熟其成本管理技能的详细信息，请参阅 改进成本管理规则。

了解何时更改体系结构

迁移往往侧重于维护现有体系结构并将其过渡到云平台。 但是，有时可能需要重新架构工作负荷，甚至进行迁移。 此列表提供了在迁移之前可能需要进行体系结构更改的示例：

• 支付技术债务。 一些老化的工作负荷携带大量技术债务。 技术债务会导致长期挑战，因为它会增加云提供商的托管成本。 当技术债务不自然地增加托管成本时，应评估替代体系结构。
• 提高可靠性。 标准操作基线在云中提供一定程度的可靠性和恢复能力。 某些工作负荷团队可能需要更高的 SLA，这可能会导致体系结构更改。
• 高成本工作负荷。 在迁移期间，应优化所有资产，使其大小与实际使用情况保持一致。 某些工作负荷可能需要进行体系结构修改才能解决特定的成本问题。
• 性能要求。 当工作负荷性能直接影响业务时，可能需要额外的体系结构注意事项。
• 保护应用程序。 安全要求往往集中实施，通常应用于项目组合中的所有工作负荷。 某些工作负荷可能有特定的安全要求，可能会导致体系结构更改。

其中每个条件都可用作潜在迁移障碍的指示器。 在大多数情况下，可以通过正确调整服务器大小、添加新服务器或进行其他更改来迁移工作负荷后解决条件。 但是，如果在迁移工作负荷之前需要这些条件中的任何一个，请从迁移波中删除工作负荷并单独对其进行评估。

Azure Well-Architected Framework 和 Azure Well-Architected 评审可以帮助指导与特定工作负荷的技术所有者进行对话，帮助他们考虑部署工作负荷的替代选项。

然后，工作负荷被归类为云采用计划中重新架构或现代化工作。 由于重新构建工作负荷需要额外的时间，因此将这些备用工作负荷采用路径视为独立于迁移过程。

体系结构清单

可以使用以下清单来确保涵盖关键体系结构注意事项：

• 确认体系结构满足可用性、灾难恢复和数据恢复的 SLA。
• 确认已将网络分段做法应用于网络设计。
• 请确认您已计划进行监控和日志记录。
• 确认虚拟机的大小是否适合所需的实际计算时间。
• 确认磁盘的大小是否适合所需的实际大小和性能。
• 确认你已计划进行负载均衡服务（如果需要）。 这些服务可能包括 Azure 负载均衡器、Azure 应用程序网关、Azure Front Door 或 Azure 流量管理器的实例。
• 确认是否已规划主权和机密计算要求（如果需要）。

后续步骤

部署迁移工作负载