你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

将 SQL Server Always On 可用性组迁移到 Azure VMware 解决方案

项目
01/08/2025

本文介绍如何将 SQL Server Always On 可用性组迁移到 Azure VMware 解决方案。对于 VMware HCX，可以遵循 VMware vMotion 迁移过程。

我们已使用 Windows Server（2019 和 2022）数据中心版本以及部署在本地环境中的虚拟机对 Microsoft SQL Server（2019 和 2022）进行了测试。 Windows Server 和 SQL Server 是遵循 Microsoft 和 VMware 的最佳做法和建议配置的。本地源基础结构是在 Dell PowerEdge 服务器和 Intel Optane P4800X SSD NVMe 设备上运行的 VMware vSphere 7.0 Update 3 和 VMware vSAN。

先决条件

以下是将 SQL Server 实例迁移到 Azure VMware 解决方案的先决条件。

查看并记录群集中每个节点的存储和网络配置。
维护所有 SQL Server 数据库的备份。
备份托管 SQL Server 的一个或多个虚拟机。
从任何 VMware vSphere 分布式资源计划程序 (DRS) 组和规则中删除虚拟机。
必须在本地数据中心和运行已迁移工作负载的 Azure VMware 解决方案私有云之间配置 VMware HCX。有关如何配置 HCX 的详细信息，请参阅 Azure VMware 解决方案文档。
确保 SQL Server 及使用它的工作负载所用的所有网段都已扩展到 Azure VMware 解决方案私有云中。若要验证此步骤，请参阅配置 VMware HCX 网络扩展。

VMware HCX over VPN 或 ExpressRoute 连接均可用作迁移的网络配置。

使用 VMware HCX over VPN 时，由于其带宽有限，因此它通常适用于能够承受较长停机时间的工作负载（例如非生产环境）。

对于以下任何实例，建议使用 ExpressRoute 连接进行迁移：

生产环境
数据库较大的工作负载
在需要最大程度地减少停机时间的方案中，建议使用 ExpressRoute 连接进行迁移。

下一部分将讨论进一步的停机时间注意事项。

停机时间注意事项

迁移期间的停机时间取决于要迁移的数据库大小，以及专用网络与 Azure 云之间的连接速度。虽然 SQL Server 可用性组迁移可以在最短的解决方案停机时间内执行，但最好在预先批准的更改时段内的非高峰时段进行迁移。

下表指出了迁移每个 SQL Server 拓扑的预计停机时间。

方案	预计停机时间	说明
SQL Server 独立实例	低	迁移是使用 VMware vMotion 完成的，数据库在迁移期间可用，但不建议在迁移期间提交任何关键数据。
SQL Server Always On 可用性组	低	在迁移第一个次要副本期间，主要副本将始终可用，并且在初次故障转移到 Azure 后，次要副本将变成主要副本。
SQL Server Always On 故障转移群集实例	高	群集的所有节点都将关闭，并通过 VMware HCX 冷迁移进行迁移。停机时间取决于数据库大小，以及专用网络与 Azure 云之间的连接速度。

Windows Server 故障转移群集仲裁注意事项

Microsoft SQL Server Always On 可用性组依赖于 Windows Server 故障转移群集，这需要仲裁投票机制来维护群集的一致性。

需要奇数个投票元素，这是通过群集中奇数个节点或者使用见证来实现的。可通过三种不同的方式配置见证：

磁盘见证
文件共享见证
云见证

如果群集使用磁盘见证，则必须使用本文档所述的过程将磁盘与群集共享存储的其余部分一起迁移。

如果群集使用本地运行的文件共享见证，则迁移群集的见证类型取决于 Azure VMware 解决方案的使用方案，有几个选项需要考虑。

数据中心扩展：在本地维护文件共享见证。工作负载分布在数据中心和 Azure 中。因此，数据中心和 Azure 之间的连接应始终可用。无论在哪种情况下，都请考虑带宽限制并做好相应的规划。
数据中心出口：对于此方案，可以使用两个选项。在这两种选项中，都可以在迁移期间在本地维护文件共享见证，以防在此过程中需要回滚。
- 在 Azure VMware 解决方案私有云中部署新的文件共享见证。
- 部署一个在 Azure VMware 解决方案私有云所在区域的 Azure Blob 存储中运行的云见证。
灾难恢复和业务连续性：对于灾难恢复方案，最合适且最可靠的选项是创建一个在 Azure 存储中运行的云见证。
应用程序现代化：对于此用例，最佳选项是部署云见证。

有关配置和管理仲裁的详细信息，请参阅故障转移群集文档。有关在 Azure Blob 存储中部署云见证的信息，请参阅管理故障转移群集的群集仲裁。

迁移 SQL Server Always On 可用性组

使用管理凭据通过 SQL Server Management Studio 访问 Always On 可用性组。
- 选择主要副本并打开可用性组属性。
- 将“可用性模式”更改为“异步提交”，以便迁移副本。
- 将可用性组的每个成员的“故障转移模式”更改为“手动”。
访问本地 vCenter Server 并转到 HCX 区域。
在“服务”下，选择“迁移”>“迁移”。
- 选择一个运行要迁移的数据库的次要副本的虚拟机。
- 在远程私有云中设置 vSphere 群集，该群集现在将用作计算容器，托管迁移的一个或多个 SQL Server VM。
- 为“vSAN 数据存储”选择远程存储。
- “选择一个文件夹” 。此操作并非强制性的，但建议将 Azure VMware 解决方案私有云中的不同工作负载分开。
- 保留“与源相同的格式”。
- 为“vMotion”选择“迁移配置文件”。
- 在“扩展选项”中，选择“迁移自定义属性”。
- 验证本地网段在 Azure 中是否具有正确的远程延伸网段。
- 选择“验证”，并确保所有检查均已完成且状态为通过。最常见的错误与存储配置有关。再次验证是否不存在虚拟 SCSI 控制器采用物理共享设置。
- 选择“开始”开始迁移。
迁移完成后，访问迁移的副本，并验证与可用性组中其余成员的连接。
在 SQL Server Management Studio 中，打开“可用性组仪表板”，并验证副本是否显示为“联机”。
- 由于在迁移过程中副本与主要副本不同步，因此“故障转移准备就绪”列中会显示“数据丢失”状态。
再次编辑可用性组属性，并将“可用性模式”重新设置为“同步提交”。
- 次要副本开始同步回迁移期间对主要副本所做的所有更改。等到它显示为“已同步”状态。
在“可用性组仪表板”中，在 SSMS 中选择“启动故障转移向导”。
选择迁移的副本，然后选择“下一步”。
使用 DB 管理员凭据连接到下一个屏幕中的副本。
查看更改并选择“完成”以启动故障转移操作。
在下一个屏幕中监视故障转移的进度，操作完成后选择“关闭”。
刷新 SQL Server Management Studio (SSMS) 中的“对象资源管理器”视图，验证迁移的实例现在是否是主要副本。
对可用性组的其余副本重复步骤 1 到 6。

注意

一次迁移一个副本，并验证每次迁移后所有更改是否都同步回副本。不要使用“HCX 批量迁移”同时迁移所有副本。
所有副本的迁移完成后，使用 SQL Server Management Studio 访问 Always On 可用性组。
- 打开仪表板并验证任何副本中没有数据丢失，并且所有副本均处于“已同步”状态。
- 编辑可用性组的“属性”，并将所有副本中的“故障转移模式”设置为“自动”。