在相同的硬件上迁移到 Azure Stack HCI

项目
12/23/2024

适用于：Azure Stack HCI 版本 22H2；Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2008 R2

本主题介绍了如何使用现有的服务器硬件将 Windows Server 故障转移群集迁移到 Azure Stack HCI。此过程包括安装新的 Azure Stack HCI 操作系统、保留现有的群集设置和存储，以及导入 VM。

下图描绘了如何使用相同的服务器硬件来就地迁移 Windows Server 群集。在关闭群集后，需要安装 Azure Stack HCI，重新附加存储，导入 VM 并使其具有高可用性 (HA)。

若要将 VM 迁移到新的 Azure Stack HCI 硬件，请参阅在新硬件上迁移到 Azure Stack HCI。

备注

本文没有介绍如何迁移拉伸群集。

准备阶段

在开始迁移之前，需要注意几点要求和事项：

所有 Windows PowerShell 命令都必须以管理员身份运行。
对于 Azure Stack HCI，必须具有拥有管理员权限的域凭据。
备份源群集上的所有 VM。完成对所有应用程序和数据的故障一致性备份，完成对所有数据库的应用程序一致性备份。若要备份到 Azure，请参阅使用 Azure 备份。
收集所有群集节点和群集命名、网络配置、群集共享卷 (CSV) 复原能力和容量以及仲裁见证的清单和配置。
关闭群集 VM、脱机 CSV、脱机存储池和群集服务。
禁用群集名称对象 (CNO)（稍后重用），并且：
- 检查 CNO 是否拥有对自己的组织单位 (OU) 的“创建对象”权限
- 检查是否在 OU 上设置了块继承策略
- 在此 OU 上设置 Azure Stack HCI 所需的策略

VM 版本支持和更新

下表列出了在相同的硬件上进行就地迁移所支持的 Windows Server OS 版本及其 VM 版本。

无论 VM 运行的 OS 版本是什么，迁移到 Azure Stack HCI 所支持的最低 VM 版本都是版本 5.0。因此，在 Windows Server 2016 或更高版本系统上运行的任何版本为 2.0、3.0 或 4.0 的 VM 都必须在迁移之前更新为版本 5.0。

OS 版本	VM 版本
Windows Server 2008 SP1	2.0
Windows Server 2008 R2	3.0
Windows Server 2012	4.0
Windows Server 2012 R2	5.0
Windows Server 2016	8.0
Windows Server 2019	9.0
Windows Server 2022
Azure Stack HCI	9.0

对于 Windows Server 2008 SP1、Windows Server 2008 R2-SP1 和 Windows 2012 群集上的 VM，不支持直接迁移到 Azure Stack HCI。在这些情况下，你有两种选择：

先将这些 VM 迁移到 Windows Server 2012 R2 或更高版本系统，并更新 VM 版本，再开始迁移过程。
使用 Robocopy 将所有 VM VHD 复制到 Azure Stack HCI。然后，在 Azure Stack HCI 中新建 VM，并将复制的 VHD 附加到它们各自的 VM 上。这就绕过了这些较旧 VM 的 VM 版本限制。

更新 VM 版本

运行以下命令来显示单个服务器上的所有 VM 版本：

Get-VM * | Format-Table Name,Version

若要显示 Windows Server 群集中所有节点上的全部 VM 版本，请运行以下命令：

Get-VM -ComputerName (Get-ClusterNode)

若要将所有 Windows Server 节点上的全部 VM 都更新为最新版本，请运行以下命令：

Get-VM -ComputerName (Get-ClusterNode) | Update-VMVersion -Force

更新服务器和群集

迁移包括在 Windows Server 部署上运行 Azure Stack HCI 安装程序，以便在 VM 和存储完整的情况下进行干净 OS 安装。这将用 Azure Stack HCI 替换当前的操作系统。有关详细信息，请参阅部署 Azure Stack HCI 操作系统。然后，新建 Azure Stack HCI 群集，重新附加存储，并导入 VM。

关闭现有的群集 VM、脱机 CSV、脱机存储池和群集服务。
转到下载 Azure Stack HCI 位的位置，然后在每个 Windows Server 节点上运行 Azure Stack HCI 安装程序。
在安装过程中，选择“自定义: 仅安装更高版本的 Azure Stack HCI (高级)”。对每个服务器重复操作。
新建 Azure Stack HCI 群集。可以使用 Windows Admin Center 或 Windows PowerShell 完成此任务，如以下部分所示。

重要

Hyper-V 虚拟交换机 (VMSwitch) 名称必须与群集配置清单中捕获的名称相同。在导入 VM 之前，请确保 Azure Stack HCI 群集上使用的虚拟交换机名称与原始源虚拟交换机名称一致。

备注

必须先向 Azure 注册 Azure Stack HCI 群集，然后才能在其上新建 VM。有关详细信息，请参阅向 Azure 注册。

使用 Windows Admin Center

如果使用 Windows Admin Center 创建 Azure Stack HCI 群集，则“创建群集”向导会自动在每个服务器节点上安装所有必需的角色和功能。

若要详细了解如何创建群集，请参阅使用 Windows Admin Center 创建 Azure Stack HCI 群集。

重要

跳过“创建群集”向导中的“第 4.1 步: 清理驱动器”。否则，你会删除现有的 VM 和存储。

启动“创建群集”向导。当你到“第 4 步: 存储”时：
跳过“第 4.1 步: 清理驱动器”。请勿这样操作。
离开向导。
打开 PowerShell，然后运行以下 cmdlet 来新建 Storagesubsystem Object ID、重新发现所有存储机箱并分配 SES 驱动器号：
```
Enable-ClusterS2D -Verbose
```
如果是从 Windows Server 2016 迁移，这还会新建 ClusterperformanceHistory ReFS 卷，并将它分配给 SDDC 群集资源组。

如果是从 Windows Server 2019 迁移，这还会添加现有的 ClusterperformanceHistory ReFS 卷，并将它分配给 SDDC 群集资源组。
返回到向导。在“第 4.2 步: 验证驱动器”中，验证是否列出了所有驱动器，并且没有警告或错误。
完成向导。

使用 Windows PowerShell

如果使用 PowerShell 创建 Azure Stack HCI 群集，则必须使用此 cmdlet 在每个 Azure Stack HCI 群集节点上安装下列角色和功能：

Install-WindowsFeature -Name Hyper-V, Failover-Clustering, FS-Data-Deduplication, Bitlocker, Data-Center-Bridging, RSAT-AD-PowerShell -IncludeAllSubFeature -IncludeManagementTools -Verbose

若要详细了解如何使用 PowerShell 创建群集，请参阅使用 Windows PowerShell 创建 Azure Stack HCI 群集。

备注

对之前禁用的群集名称对象重用相同的名称。

运行 cmdlet 以创建群集：

New-cluster -name "clustername" -node Server01,Server02 -staticaddress xx.xx.xx.xx -nostorage

运行该 cmdlet 来新建 Storagesubsystem Object ID、重新发现所有存储机箱并分配 SES 驱动器号：
```
Enable-ClusterS2D -Verbose
```
如果是从 Windows Server 2016 迁移，这还会新建 ClusterperformanceHistory ReFS 卷，并将它分配给 SDDC 群集资源组。

备注

如果存储池显示“少数磁盘”错误（可以在群集管理器中看到），请重新运行 Enable-ClusterS2D -verbose cmdlet。
使用群集管理器启用除了是 ReFS 卷的 ClusterperformanceHistory 卷之外的所有 CSV（确保它们都不是 ReFS CSV）。
如果是从 Windows Server 2019 迁移，请重新运行 Enable-ClusterS2D -verbose cmdlet。这会将 ClusterperformanceHistory ReFS 卷与 SDDC 群集资源组关联。

通过运行该 cmdlet 来确定当前的存储池名称和版本：

Get-StoragePool | ? IsPrimordial -eq $false | ft FriendlyName,Version

现在，确定新的存储池名称和版本：

Get-StoragePool | ? IsPrimordial -eq $false | ft FriendlyName,Version

创建仲裁见证。有关操作说明，请参阅创建群集见证。
使用该 cmdlet 来验证存储修复作业是否已完成：
```
Get-StorageJob
```
备注

这可能需要相当长的时间，具体视升级过程中运行的 VM 数量而定。
验证所有磁盘是否都正常运行：
```
Get-VirtualDisk
```
确定群集节点版本（显示 ClusterFunctionalLevel 和 ClusterUpgradeVersion）。运行 cmdlet 以获取此内容：
```
Get-ClusterNodeSupportedVersion
```
备注

ClusterFunctionalLevel 自动设置为 10，不需要因新建操作系统和群集而进行更新。
更新存储池，如下所示：
```
Get-StoragePool | Update-StoragePool
```

ReFS 卷

如果是从 Windows Server 2016 迁移，则支持复原文件系统 (ReFS) 卷，但 Azure Stack HCI 使用镜像加速奇偶校验 (MAP) 卷带来的性能增强并不能让此类卷受益。此增强需要使用 PowerShell New-Volume cmdlet 新建 ReFS 卷。

对于 Windows Server 2016 MAP 卷，ReFS 压缩是不可用的，因此可以重新附加这些卷，但与在 Azure Stack HCI 群集中新建 MAP 卷相比，性能要差一些。

导入 VM

最佳做法是，每个群集节点至少创建一个群集共享卷 (CSV)，以便为每个 CSV 所有者均衡 VM，从而提高 VM 工作负载的复原能力、性能和规模。默认情况下，这种均衡每五分钟自动发生一次，在源群集节点和目标群集节点之间使用 Robocopy 时需要考虑，以确保源和目标 CSV 所有者匹配，从而实现最佳的传输路径和速度。

在 Azure Stack HCI 群集上执行下列步骤，以导入 VM，使其具有高可用性，然后启动它们：

运行 cmdlet 以显示所有 CSV 所有者节点：
```
Get-ClusterSharedVolume
```
对于每个服务器节点，转到 C:\Clusterstorage\Volume，然后为所有 VM 设置路径，例如 C:\Clusterstorage\volume01。
在每个 CSV 所有者节点上运行该 cmdlet，以在导入 VM 之前显示每个卷的所有 VM VMCX 文件的路径。修改路径以匹配你的环境：
```
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse
```
为每个服务器节点运行该 cmdlet，以导入和注册所有 VM，并使其在每个 CSV 所有者节点上具有高可用性。这样可以确保 VM 的均匀分布，从而实现最佳处理器和内存分配：
```
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRole
```
启动每个节点上的每个目标 VM：
```
Start-VM -Name
```
登录并验证所有 VM 是否正在运行，且其中是否包含你的所有应用和数据：
```
Get-VM -ComputerName Server01 | Where-Object {$_.State -eq 'Running'}
```
最后，将 VM 更新到最新的 Azure Stack HCI 版本，以充分利用所有改进：
```
Get-VM | Update-VMVersion -Force
```

后续步骤

迁移后，验证群集。请参阅验证 Azure Stack HCI 群集。
若要将 Windows Server VM 迁移到新的 Azure Stack HCI 硬件，请参阅在新硬件上迁移到 Azure Stack HCI。

通过