将 SQL Server 数据库迁移到 Azure

本文内容

本文演示虚构公司 Contoso 如何评估、计划和将各种本地SQL Server数据库迁移到 Azure。

考虑迁移到 Azure 时，Contoso 公司需要进行技术和财务评估，以确定它的本地工作负荷是否是适合迁移到云中的候选项。 具体而言，Contoso 团队想要评估进行迁移时计算机和数据库的兼容性。 此外，它希望估计在 Azure 中运行 Contoso 资源的容量和成本。

业务驱动因素

Contoso 在维护其网络上存在的各种SQL Server工作负荷版本时遇到了各种问题。 在最新的投资者会议后，CFO 和 CTO 已决定将所有工作负载迁移到 Azure。 将所有工作负载移动到 Azure 后，Contoso 就可以从结构化资本支出模型转移到流畅的运营费用模型。

IT 领导团队与业务合作伙伴密切合作，了解业务和技术要求：

迁移目标

Contoso 云团队确定其针对各种迁移的目标。 团队使用这些目标来确定最佳迁移方法。

要求详细信息

性能

迁移后，Azure 中应用程序的性能应与当前在 Contoso 本地环境中运行的应用程序相同。 迁移到云并非表示应用程序性能变得不太重要。

兼容性

Contoso 需要了解其应用程序和数据库与 Azure 的兼容性。 该公司还需要了解其 Azure 托管选项。

数据源

所有数据库都必须移动到 Azure，但没有任何例外。 根据所使用的 SQL 功能的数据库和应用程序分析，它们将移动到 PaaS、IaaS 或托管实例。

应用程序

应用程序必须尽可能迁移到云。 如果无法移动，则仅允许通过专用连接通过 Azure 网络连接到迁移的数据库。

成本

Contoso 不仅想要了解其迁移选项，还想要了解迁移到云后与基础结构相关的成本。

Management

为各部门和资源组创建资源管理组，以管理所有已迁移的 SQL 数据库。 使用部门信息标记所有资源以获取退款要求。

限制

最初，并非所有运行应用程序的分支机构都有指向 Azure 的直接 ExpressRoute 链接，因此这些办事处必须通过虚拟网络网关进行连接。

解决方案设计

Contoso 使用 Azure Migrate 对数字资产进行了迁移评估。

该评估导致多个工作负载分布在多个部门。 迁移项目的总体大小需要一个完整的项目管理办公室 (PMO) ，以管理通信、资源和计划计划的具体信息。

解决方案评审

Contoso 通过将利弊清单放置在一起来评估其建议的设计。

注意事项详细信息

优点

Azure 提供了一个单一的玻璃窗格，用于数据库工作负荷。

可以使用 Azure 成本管理 + 计费来监视成本。

Azure 计费 API 可简化业务退款计费。

服务器和软件维护仅减少到基于 IaaS 的环境。

缺点

由于基于 IaaS 的虚拟机的要求，团队仍必须管理这些计算机上的软件。

预算和管理

在迁移发生之前，请设置必要的 Azure 结构以支持解决方案的管理和计费方面。

对于管理要求，公司会创建多个 管理组 来支持组织结构。

对于计费要求，公司会使用相应的计费标记 标记 每个 Azure 资源。

迁移过程

数据迁移遵循标准的可重复模式。 此过程涉及基于 Microsoft 最佳做法的以下步骤：

迁移：迁移后：步骤 1：发现

Contoso 使用 Azure Migrate 在 Contoso 环境中显示依赖项。 Azure Migrate 会自动发现 Windows 和 Linux 系统上的应用程序组件，并映射服务之间的通信。 Azure Migrate 还显示 Contoso 服务器、进程、入站和出站连接延迟以及跨其 TCP 连接的体系结构的端口之间的连接。

Contoso 还会将数据迁移助手添加到其 Azure Migrate 项目中。 使用 数据迁移助手，Contoso 可以评估其数据库以迁移到 Azure。

步骤 2：应用程序评估

评估确定 Contoso 主要使用 。基于 NET 的应用程序。 但某些项目使用其他技术，如 PHP 和Node.js。 供应商购买的系统还引入了不基于 .NET 的应用程序。 Contoso 标识以下应用程序：

步骤 3：数据库评估

当 Azure Migrate 发现每个数据库时，数据迁移助手 (DMA) 运行并确定团队使用的功能。 DMA 通过检测可能影响新版SQL Server或Azure SQL数据库中的数据库功能的兼容性问题，帮助 Contoso 评估其数据库迁移到 Azure。

Contoso 遵循以下步骤评估其数据库，然后将结果数据上传到 Azure Migrate：

下载 DMA。创建评估项目。在 DMA 中，登录到 Azure Migrate 项目并同步评估摘要。

DMA 为目标环境提供了性能和可靠性改进建议，并可便于将架构、数据和非包含对象从源服务器迁移到目标服务器。

详细了解数据迁移助手。

Contoso 使用 DMA 运行评估，然后将数据直接上传到 Azure Migrate。

现在，随着数据库信息加载到 Azure Migrate 中，Contoso 会识别必须迁移的 1，000 多个数据库实例。 在这些实例中，公司可将大约 40% 迁移到 Azure SQL 数据库。 公司必须将其余 60% 移到 Azure 虚拟机 或 Azure SQL 托管实例 上运行的SQL Server。 在 60% 中，大约 10% 需要基于虚拟机的方法。 其余实例可以移动到Azure SQL 托管实例。

当无法在数据源上运行 DMA 时，以下准则是用于数据库迁移的团队。

注意

Contoso 在评估阶段发现了各种开放源代码数据库。 另外，他们遵循将开放源代码数据库迁移到 Azure 中的指导进行迁移规划。

步骤 4：迁移规划

有了手头的信息，Contoso 使用以下准则来确定对每个数据库使用哪种迁移方法。

目标数据库使用情况详细信息联机迁移脱机迁移最大大小迁移指南

Azure SQL 数据库 (PaaS)

SQL Server（仅限数据）

这些数据库使用基本表、列、存储过程和函数

数据迁移助手，事务复制

BACPAC、bcp

1 TiB

链接

Azure SQL 托管实例

SQL Server（高级功能）

这些数据库使用触发器和其他，例如自定义 .NET 类型、服务代理等。

数据迁移助手，事务复制

BACPAC、bcp、本机备份/还原

2 TiB 到 8 TiB

链接

Azure 虚拟机 (IaaS) 上的 SQL Server

SQL Server（第三方集成）

SQL Server必须具有，例如跨实例服务代理、加密提供程序、缓冲池、低于 100 的兼容性级别、数据库镜像、FILESTREAM、PolyBase、需要访问文件共享、外部脚本、扩展存储过程等的任何内容。 或者服务器必须安装第三方软件才能支持数据库的活动。

事务复制

BACPAC、bcp、快照复制、本机备份/恢复、将物理机转换为 VM

4 GiB 到 64 TiB

链接

由于数据库数量众多，Contoso 会创建一个项目管理办公室 (PMO) ，以跟踪每个数据库迁移实例。 PMO 将 责任和责任 分配给每个业务和应用程序团队。

Contoso 还执行 工作负荷就绪情况评审。 此评审检查基础结构、数据库和网络组件。

步骤 5：测试迁移

迁移准备的第一部分涉及将所有数据库的测试迁移到预设置环境。 为了节省时间，团队会编写迁移的所有操作脚本，并记录每个操作的时间。 为了加快迁移速度，他们确定可以并发运行的迁移操作。

如果发生意外故障，将为每个数据库工作负荷标识任何回滚过程。

对于基于 IaaS 的工作负荷，公司事先设置所有必需的第三方软件。

测试迁移后，Contoso 可以使用各种 Azure 成本估算工具 来更准确地了解其迁移的未来运营成本。

步骤 6：迁移

对于生产迁移，Contoso 会确定所有数据库迁移的时间范围，以及周五午夜到周日午夜 (周五午夜) 的足够运行时间范围mssql数据库迁移，且业务停机时间最小。

根据记录的测试过程，他们尽可能多地通过脚本运行每个迁移，限制手动任务以最大程度地减少错误。

如果任何迁移在该窗口失败，他们将回滚并在下一个迁移窗口期重新安排。

迁移后的清理

Contoso 标识所有数据库工作负荷的存档窗口。 当窗口过期时，公司将从本地基础结构停用资源。

停用资源包括：

查看部署

Azure 显示已迁移的资源后，Contoso 需要积极行动、全面保护新的基础结构。

安全性备份许可和成本优化后续步骤

在本文中，Contoso 评估、计划并将其 Microsoft SQL Server 工作负载迁移到了 Azure。

Azure DevOps 项目可用于在 SQL 迁移旅程中学习，它与云采用框架保持一致。 此项目指导你完成关键决策。 有关详细信息，请参阅 Azure DevOps 项目。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!