介绍 Azure 迁移框架

  • 5 分钟

在开始将 Tailwind Traders 的本地工作负载迁移到 Azure 之前，应考虑创建迁移计划。 该计划应确定要迁移的工作负载，以及迁移期间要使用的适当服务或工具。 理想情况下，该计划还应包含有关如何优化已迁移服务的详细信息。

Azure 迁移框架可帮助你制定计划并完成迁移。 该框架包括四个阶段：评估、迁移、优化和监视。

第 1 阶段：评估本地环境

在第一阶段，评估当前本地环境：

  • 确定迁移范围内的应用及其相关的服务器、服务和数据
  • 开始让利益干系人（例如 IT 部门和相关业务小组）参与进来
  • 创建计划迁移的服务器、服务和应用的完整清单和依赖关系映射
  • 使用 Azure 总拥有成本计算器 (TCO) 估算成本节省
  • 确定可用于执行这四个阶段的适当工具和服务

迁移策略模式

将工作负荷迁移到云有五种广泛的策略模式，通常称为合理化的五个 R：重新托管、重构、重新架构、重新生成和替换。 采用的策略因业务驱动因素和迁移目标而异。 可以考虑采用多种模式。 可以选择重新托管简单应用或对业务并不重要的应用，但重新架构更为复杂的业务关键型应用。

  • 重新托管：重新托管通常称为“直接迁移”。 此策略无需更改代码，并允许将现有工作负载快速迁移到 Azure。 每个工作负载都按原样迁移，不会产生与更改代码相关的风险和费用。

  • 重构：重构通常称为“重新打包”。 重构需要对应用进行最小程度的更改，以便应用能连接到 Azure 平台即服务 (PaaS) 并使用云产品/服务。 可以将现有应用迁移到 Azure 应用服务或 Azure Kubernetes 服务 (AKS)。 或者，可以将关系数据库和非关系数据库重构为其他选项。 重构为 Azure SQL 托管实例、Azure Database for MySQL、Azure Database for PostgreSQL 和 Azure Cosmos DB（如果可以轻松重新打包应用，使其能在 Azure 中工作）。

  • 重新架构：重新架构以让迁移着重于修改和扩展应用功能及基本代码，从而优化应用体系结构以实现云可伸缩性。 可将整体应用分解为一组一起工作且缩放轻松的微服务。 或者，可以将关系数据库和非关系数据库重新架构为完全托管的数据库解决方案。 重新架构为 Azure SQL 托管实例、Azure Database for MySQL、Azure Database for PostgreSQL 和 Azure Cosmos DB。

  • 重新生成：重新生成使用 Azure 云技术完全重新生成应用，是更进一步的迁移模式。 可使用云原生技术（如 Azure Functions、Azure AI、Azure SQL 托管实例和 Azure Cosmos DB）生成尚无人开发的应用。

  • 替换：使用目前可用的最佳技术和方法实施解决方案。 有时，服务型软件 (SaaS) 应用程序可以提供托管应用程序所需的所有功能。 你可以随后安排工作负荷进行替换，将其从迁移范围中删除。

下面列出了适用于这四种模式的方案。

重新托管 重构 重新架构 重新生成 Replace
快速将工作负载迁移到云

在不修改工作负载的情况下移动工作负载

适用于旨在在迁移后利用 Azure IaaS 可伸缩性的应用

当工作负载对业务非常重要，但无需立即更改应用功能时		 应用 Azure 提供的创新 DevOps 做法

为工作负载实现 DevOps 容器策略

支持现有基本代码的可移植性，以及可用的开发技能		 应用需要进行重大修订以纳入新功能

应用需要进行重大修订才能在云平台上有效运行

使用现有应用程序投资

满足可伸缩性要求

应用创新的 DevOps 做法

最大程度地减少虚拟机的使用		 快速开发

支持功能和生命周期有限的现有应用

使用 DevOps 做法加速业务创新

使用 Azure 区块链等新的云原生技术重新进行构建

在云中将旧版应用程序重新构建为“无代码应用”或“低代码应用”		 围绕行业最佳做法进行标准化

加快采用业务流程驱动方法的速度

重新分配开发投资以形成竞争差异化或优势

以 SaaS 产品/服务取代现有解决方案

第 2 阶段：迁移工作负载

完成评估后，可以开始执行迁移目标应用及其相关服务和数据的过程。 迁移阶段通常包括以下工作：

  • 部署云基础结构目标。 在迁移 Tailwind Traders 的工作负载之前，需要创建所需的云基础结构目标。 根据用于执行迁移的工具，可能需要在开始迁移之前创建所需的 Azure 资源。 某些工具（例如 Azure Migrate 和 Azure 数据库迁移服务）可为你创建目标 Azure 资源。

  • 迁移工作负载。 试行工作负载迁移并为试行选择非关键应用是个不错的想法。 可通过此方法熟悉工具、获得流程和过程的经验并降低迁移大型或复杂工作负载时的风险。

  • 解除分配本地基础结构：成功迁移源应用和数据库并感到满意后，必须解除分配这些源工作负载。 考虑保留源工作负载备份和存档的数据。 这些数据提供历史存档，将来可能很有用。 可将这些备份和存档存储在 Azure Blob 存储中。

第 3 阶段：优化已迁移的工作负载

在规划优化阶段时，有三项需要重点关注的主要工作：

  • 分析工作负载的迁移成本
  • 查看降低成本的建议
  • 明确用于提高工作负载性能的选项

可以在 Azure 门户中使用 Microsoft 成本管理（以前称为 Azure 成本管理和计费）来分析工作负载成本。 此工具适用于包含已迁移工作负载的 Azure 资源组。 可以在“成本分析”>“成本管理”部分找到该工具。 以下屏幕截图显示 ContosoResourceGroup 资源组最近的计费周期的成本分析。 分析结果根据服务名称、区域和资源显示成本。 可以自定义显示结果以满足你的需求。

Screenshot that shows a cost analysis example with estimated costs in the Azure portal.

为了帮助降低成本，可以通过选择“顾问建议”来使用 Azure 顾问功能。 分析当前成本并查看建议后，可以明确提高工作负载性能的选项。

第 4 阶段：监视工作负载

可以使用 Azure Monitor 从 Azure 虚拟机捕获运行状况和性能信息。 在目标虚拟机上安装 Azure Monitor 日志（以前称为日志分析）代理，然后设置警报和报告。

注意

可以在运行 Windows 或 Linux 的计算机上安装 Azure Monitor 日志代理。

可针对一定的数据源范围设置警报：

  • 特定指标值，例如 CPU 使用率
  • 日志文件中的特定文本
  • 运行状况指标
  • 自动缩放指标