规划数据迁移

  • 7 分钟

数据平台现代化项目分为通常按顺序完成的五个阶段。

在我们的全球零售商场景中，你的董事会已批准现代化项目，并且你开始组织人员​​和其他资源。 若要以最优方式设置和分配任务，你需要深入了解各个项目阶段。

本单元将更详细地探索这五个阶段。

数据现代化的五个阶段的示意图：发现、评估、计划、转换和验证。

启动和发现

数据平台现代化项目通常是为了满足业务或法律要求而启动的。 因此，考虑到这些需求并获得高级管理层的支持是至关重要的。 第一步是完成包括以下注意事项的发现练习：

  • 评估当前环境

    许多 IT 基础结构通常会演变数年甚至数十年时间。 在这段时间内，企业和员工可能发生巨大变化，以致组织内不再有精擅此类系统的专家。 在一些罕见情况下，组织甚至可能会忘记还有这样一些系统存在。

  • 检查现有应用程序和数据库之间的依赖关系

    你应该花点时间来了解你的应用程序如何与网络中存在的数据库进行交互。 此外，你还应该了解可能存在的任何数据库间依赖关系，以便可以按逻辑分组对数据库进行集体分组。 通过完成此练习，你可将数据库的逻辑分组用作将它们作为一个单元迁移到 Azure 的基础。

  • 列出系统的工作负载类型

    根据已识别的数据库服务器列出工作负载类型，可深入了解其使用情况。 工作负载可以根据它们是读取密集型还是写入密集型分类为分析性 (OLAP) 或事务性 (OLTP)。 这有助于确定要迁移到的数据平台技术。 进一步分类可能包括批处理或决策支持工作负载。

评估

在评估阶段，在发现阶段收集的信息用于对已识别的工作负载进行全面评估，以确定以下内容：

  • 任何潜在的迁移妨碍因素
  • 任何需要迁移后修复的中断性变更
  • 工作负载可以使用的 Azure 功能

你可以通过完成当前工作负载评估和工作负载条件评估进行确定：

  • 当前工作负载评估

    已识别的数据库服务器和应用程序经过分类和确认，以确定以下内容：数据量和预期增长率、平均资源使用情况及其对业务的关键性。 此阶段还提供了一个机会，可以考虑合并或解除本地数据库授权，以减少要迁移的数据库数并降低总拥有成本。

  • 工作负载条件评估

    在工作负载条件评估中，你可以使用当前工作负载评估中的发现，并定义用于运行已确定工作负载的迁移后条件。

    假设你发现了一个在高峰时段使用频繁但在非高峰时段使用率较低的事务数据库服务器。 在工作负载条件评估中，定义迁移后标准，例如迁移到具有自动缩放功能的 Azure SQL 数据库以处理峰值负载。

规划

数据平台现代化项目的规划阶段涉及确定目标平台、迁移方法以及针对任何计划内或计划外中断的缓解计划。

在数据平台现代化流程的计划阶段中，有七个用于描述可以如何处理从现有本地环境过渡到新的基于云的环境（公有或私有）的应用程序和数据的术语：

# 阶段 操作 说明
1。 保留 不执行任何操作 继续现代化，同时考虑保留本地服务的长期选项。
2. 重新托管 迁移到 IaaS 此方法可消除对数据中心管理的需求，并通过更低的总拥有成本 (TCO) 实现更高的投资回报率 (ROI)。
3. 重构 在最大限度减少应用程序变更的情况下迁移到 IaaS 或 PaaS 此方法可消除对数据中心管理的需求，并通过更低的总拥有成本 (TCO) 实现更高的投资回报率 (ROI)。 它还通过合并数据库降低了管理开销。
4. 重新架构 重写应用程序的核心方面以使用云技术 它支持使用新式组件，减少代码部署，并促进基础结构和服务的 DevOps 部署。
5. 重新生成 重新生成应用程序以使用 PaaS 或无服务器技术 使用较新的技术重新生成数据平台和应用程序便可以使用 Azure 的内置高可用性，提高应用程序的可移植性和可伸缩性，并最大程度地减少所用技术与支持/开发应用程序的员工之间的潜在技能差距。
6. 替换 用更新的应用程序或 SaaS 解决方案替换应用程序 如果应用程序依赖于附加到服务器的物理设备，或者它与本地基础结构紧密集成，请考虑使用替换方法。
7. 停止使用不再需要的应用程序 因不存在需要进行保留的业务或法律要求而不再使用旧版应用程序和数据库时，应考虑使用停用方法。

下图显示每个术语所需的工作量与企业通过迁移获得的价值之间的对比。

  • 平台目标选项

    选择目标平台时，有两个高级选项可用。

    • 基础结构即服务 (IaaS) - 在此方法中，你将数据迁移到安装了 SQL Server 的虚拟机上。

    • 平台即服务 (PaaS) - 在此方法中，你将数据迁移到适合你的工作负载的数据平台服务。 对于事务性工作负载，将涉及 Azure SQL 数据库或 Azure SQL 托管实例。 对于联机分析处理 (OLAP) 类型的工作负载，将涉及 Azure Synapse Analytics。

  • 按功能选择目标平台

    • Azure SQL 数据库 - 如果应用程序外围应用在数据库范围内，则适合使用。 SQL 数据库提供了一种低维护解决方案，是某些工作负载的不错选择。

    • Azure SQL 数据库弹性池 - 借助弹性池，你可将存储和计算资源分配给一组数据库，而不必单独管理每个数据库的资源。 此外，弹性池比单一数据库更容易缩放，由于对弹性池所做的更改，不再需要缩放单个数据库。

    • Azure SQL 数据库无服务器 - 该选项有效地降低了开发和测试环境中的成本。 使用自动暂停延迟功能，可以设置数据库自动暂停前的非活动时间段。 可以选择 1 小时到 7 天，也可以禁用它。 再次访问数据库时，它将恢复，并且仅在暂停期间产生存储费用。

    • Azure SQL 托管实例 - 如果应用程序外围应用在实例范围内并且需要 Azure SQL 数据库中不可用的功能，则适合使用，例如：

      • SQL 代理
      • MSDTC
      • DQS
      • MDS
      • 数据库邮件
      • Polybase
      • 链接服务器支持
      • 支持新的 Azure 云服务，例如威胁检测

    • Azure 虚拟机上的 SQL Server - 如果应用程序外围应用在实例范围内并且需要 Azure SQL 托管实例中不可用的功能，例如 SQL Server Reporting Services (SSRS)、SQL Server Analysis Services (SSAS) 和 SQL Server Integration Services (SSIS)，则适合使用。

    • Azure Synapse Analytics - 如果你的应用程序跨数大量数据运行复杂查询，并且可以利用大规模并行处理 (MPP) 缩短查询处理时间，则适合使用。

若要查看适用于 SQL 的每个 PaaS 产品/服务支持的功能列表，请参阅功能比较：Azure SQL 数据库和 Azure SQL 托管实例。

  • 按成本选择目标平台

    • Azure SQL 数据库 - 与 Azure IaaS 拓扑上更传统的 SQL Server 相比，Azure SQL 数据库的平台即服务性质可大幅降低管控和管理成本，因为大多数所需的工作由 Microsoft 在后台以静默方式为你完成。 大规模进行时可以节省大量时间和精力。

    • Azure SQL 数据库弹性池 - Azure SQL 数据库弹性池为具有不可预测的使用需求的多个数据库提供了显着的节省。 计算资源是共享的，可避免过度预配并降低服务器维护和管理成本。

    • Azure SQL 托管实例 - 向需要完全托管服务的客户提供 SQL 托管实例，他们可以在最大限度减少配置变更的情况下轻松直接迁移其本地环境。 该环境提供至少 8 个核心和最多 8 TB 存储，并处于隔离虚拟网络中。 此产品非常适合希望快速进入云并想要避免维护虚拟机开销的客户。

    • Azure 虚拟机上的 SQL Server - 与 PaaS 产品/服务相比，在 Azure 虚拟机上运行的 SQL Server 具有更高的计算、存储和管理成本，但可以更好地控制 SQL Server 和基础结构。

    • Azure Synapse Analytics - Azure Synapse Analytics 可以利用 MPP 体系结构在几分钟（而不是几小时）内处理复杂查询，从而降低成本。

  • 脱机和联机迁移

    在计划阶段，你需要考虑是进行脱机迁移还是联机迁移。 通过“脱机”迁移，应用程序停机时间在迁移开始的同时开始。 若要限制迁移完成时交接到新环境所需的停机时间，请使用联机迁移。 建议对脱机迁移进行测试，以便确定其停机时间是否可以接受；如果不能接受，请执行联机迁移。 此外，根据所选 Azure 平台的不同，联机和脱机选项可能不可用。

转换和优化

你的评估和计划已确定应用程序和数据库需要完成迁移后工作的方面，这些工作将转换或优化某个功能，以确保成功进行迁移。 转换通常涉及需要修复或变更数据库某个方面的工作。

优化通常涉及对迁移的数据库进行修改以利用某个功能，或优化其在 Azure 中的使用。

例如，转换可能涉及修改包含目标数据库中不支持的语法的存储过程或 SQL 查询。 这将需要调整语法以确保与新数据库平台的兼容性，确保存储过程或查询在目标环境中顺利运行而不会出现任何问题。

  • 转换

    若要确保迁移后体验成功，可能需要对数据库进行以下一项或多项更改。

    • 安装迁移前版本升级

    • 修复迁移评估工具确定的所有错误

    • 实现数据库架构变更

    • 将现有集成数据库服务迁移到 Azure

    • 处理云中的 SSIS 工作负载

  • 优化

    在迁移过程中，可能需要遵循以下一项或多项优化准则，以确保组织充分利用其对 Azure 的投资。

    • 评估目标平台可能会提供哪些新功能

    • 将工作负载重新构建为更具成本效益或性能效益的集合

    • 在迁移期间选择最高的服务级别和性能层，并在迁移完成后纵向缩减

    • 确保工作负载大小合适

    • 尽量缩短 BACPAC 文件和目标数据中心之间的距离

    • 在迁移过程中禁用自动进行数据统计

    • 分区表和索引

    • 删除已编制索引的视图并在完成后重新创建

迁移、验证和修正

此阶段涉及迁移本身，以及确认成功迁移所需的验证步骤和修正步骤。 之前的计划、评估和转换阶段将确保一切都为迁移准备就绪，并会在迁移到 Azure 后正常运行。 剩下要做的就是准备所需的迁移工具，完成迁移，并运行迁移后功能和性能验证，以确保数据与源数据库的一致性。

迁移、验证和修正注意事项

有多种工具可用于执行到所选目标平台的迁移。 这些工具会在其他模块中介绍。 同时，在完成迁移时，请务必考虑以下事项：

  • 从了解你的工作负载要求入手
  • 选择非关键工作负载或低优先级数据库进行初始迁移
  • 运行测试迁移
  • 测试数据库是否存在问题
  • 测试用于降低停机时间和兼容性问题相关风险的计划
  • 基于中断评估迁移工具，以帮助降低数据库停机风险
  • 不断迭代迁移流程
  • 考虑可用于要迁移的应用程序和数据库的维护时段
  • 让旧数据库和应用程序脱机
  • 测试第三方应用程序
  • 创建新的灾难恢复和维护计划