本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 迁移 Windows 失效转移群集
[Microsoft 失效转移群集](https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview)是一组服务器，它们之间大多使用共享存储。您可以使用失效转移群集来提高应用程序和服务的可用性。您还可以将失效转移群集迁移到 AWS Cloud ，从而受益于其可靠性、性能和更低的 TCO。
Windows 失效转移群集在云中的工作方式与在本地环境中的工作方式不同。需要注意的是，只有多子网集群才能部署在云中。与本地环境不同，Windows 失效转移群集中的 IP 地址分配给弹性网络适配器（ENA），而不是在操作系统级别。在本地环境中，操作系统处理 IP 地址分配，但云提供商（AWS）负责云中的 IP 地址分配。由于失效转移群集是操作系统级别的功能，因此它无法控制 IP 失效转移。因此，同一 IP 不能在不同节点之间进行失效转移。要解决这个问题，可以使用多子网集群，其中集群会失效转移到辅助 IP。辅助 IP 分配给另一个子网中的 ENA，并且可以联机。有关更多信息，请参阅 Microsoft 文档中的 [Failover Clustering Networking Basics and Fundamentals](techcommunity.microsoft.com/blog/failoverclustering/failover-clustering-networking-basics-and-fundamentals/1706005)。
将 Windows 故障转移群集迁移到 AWS 其中可能是一个复杂的过程，但只要仔细规划和实施，就可以最大限度地减少对业务运营的干扰。例如，每个应用程序在失效转移群集上的配置都不同，因此必须了解其需求，然后预先了解如何在云中满足这些需求。该过程涉及到以下步骤：
+ 确保所有集群节点均运行相同版本的 Windows 并进行所有必要的更新
+ 配置集群仲裁
+ 确保所有应用程序和数据均已备份并可在迁移期间恢复
## 评测
评估阶段是将故障转移群集迁移到的过程中的关键步骤 AWS。在此阶段，您将收集有关当前环境的信息，确定迁移到环境的可行性 AWS，并确定任何潜在的挑战或风险。我们建议您在评测阶段按照以下步骤操作：
+ **评估应用程序的就绪性** — 确定您的应用程序是否可以在 AWS 不进行修改的情况下迁移到，或者是否需要对其进行更新或重写以利用云原生服务。
+ **评估您的网络和安全要求** —确定您的网络和安全要求，包括防火墙、负载均衡器的配置和。 VPNs
+ **评估您的数据迁移需求** — 确定如何将数据迁移到哪里 AWS，包括数据的大小和位置、迁移所需的时间以及任何数据传输成本。在本地环境中，您可能正在使用各种存储技术，例如 JBOD、NAS 和 SAN。每个人都可以通过不同的访问方法（例如 SAN 光纤通道、iSCSI、SAS 或 SMB/NFS 共享）将数据呈现给您的应用程序。
+ **识别潜在的风险和挑战**：识别可能影响迁移过程的任何潜在风险或挑战，例如停机、兼容性问题或数据丢失。
+ **估算成本** — 估算迁移到的成本 AWS，包括 Amazon EC2 实例、存储、数据传输和任何其他 AWS 服务 所需的成本。
+ **制定迁移计划**-根据评估阶段收集的信息，制定详细的迁移计划，包括时间表、所需资源以及迁移到 AWS所涉及的步骤。
### 评估您的当前环境
评测您的当前环境，包括硬件和软件配置，以确定需要迁移到 AWS的内容。确定应用程序、服务器和数据库之间的任何依赖关系。
### 确定您的迁移策略
考虑迁移到云原生服务的选项 AWS，包括一种 lift-and-shift方法或重新架构您的环境，以利用云原生服务。
+ **传统失效转移群集迁移**：如果您要从头开始手动配置 Microsoft 失效转移群集，则可以按照[在 Amazon EC2 上部署 SQL Server](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/create-sql-server-on-ec2-instance.html) 中的说明进行操作。共享存储是进行失效转移群集迁移最重要的考虑因素之一。亚马逊 EBS 多重连接不支持 SCSI-3 永久预留，但是[ FSx 适用于 Windows 文件服务器](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)的亚马逊和[ FSx 适用于 NetApp ONTAP 的亚马逊](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html)都可以很好地用作共享存储选项。最常见的用例之一是使用 Amazon for Windows 文件服务器的 SQL Server 群集使用始终开启 FSx 的故障转移群集实例。有关更多信息，请参阅 AWS 存储博客上的 “[使用亚马逊 FSx Windows 文件服务器简化微软 SQL Server 高可用性部署](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)” 一文。下一步是将节点迁移到云端。这可以通过使用来实现 AWS Application Migration Service。有关更多信息，请参阅 AWS 存储博客中的[将你的 Microsoft Windows 集群 CloudEndure 迁移到 AWS 使用迁移](https://aws.amazon.com/blogs/storage/migrating-your-microsoft-windows-clusters-to-aws-using-cloudendure-migration/)的文章。然后，您可以为应用程序配置集群化角色以提供高可用性。
+ **使用延伸集群在几乎无需停机的情况下进行迁移**：如果您有业务关键型应用程序要迁移到云，并且承受不起停机时间，那么延伸集群可能非常适合****。对于 [Microsoft 延伸集群](https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/stretch-cluster-replication-using-shared-storage)，站点 A 和站点 B 必须通过网络相互通信，但它们可以拥有自己单独的共享存储。在迁移方案中，您可以利用它来发挥您的优势。例如，您的源（无论是在本地还是在其他提供商的云中）可以是站点 A，该站点与您部署站点 B 的 Amazon VPC 具有网络连接。站点 B 启动并正常运行后，您可以切换到站点 B。在此方法中，数据复制机制至关重要，因为您的源存储技术在哪种复制方法可能起作用方面存在限制因素。
+ 将@@ **部署在 VMware本地的故障转移群集迁移到 VMware Clou VMware d on AWS** — Cloud on AWS 原生支持 SCSI-3 永久预留。这使得在 C VMware loud on 上的虚拟机磁盘 (VMDK) 上托管故障转移群集成为可能。 AWS有关更多信息，请参阅 VMware 文档 AWS中的将[带有共享磁盘的 SQL Server FCI 群集迁移到 VMware 云端](https://docs.vmware.com/en/VMware-Cloud-on-AWS/solutions/VMware-Cloud-on-AWS.919a954a9b6ca17cdc719ec42cda1401/GUID-E1F09B84241F7DD1DC702613CB717B2C.html)。
**注意**
自 2024 年 4 月 30 日起， VMware Cloud on AWS 不再由其渠道 AWS 合作伙伴转售。服务将继续通过 Broadcom 提供。我们鼓励您联系您的 AWS 代表了解详情。
+ **使用亚马逊 EBS 多连接卷迁移 SQL Server FCI — 您可以使用亚马逊 EBS 多连接**和 NVMe 预留来创建 SQL Server 故障转移群集实例 ()FCIs，将亚马逊 EBS `io2` 卷作为 Windows 服务器故障转移群集上的共享存储。这些卷只能挂载到位于相同可用区中的实例。使用亚马逊 EBS `io2` 卷部署 Windows 服务器故障转移群集需要最新的 Windows 驱动程序，这些驱动程序可将 SCSI 预留命令转换为 NVMe 预留命令。 有关使用此方法将本地 SQL Server FCI 迁移到单个可用区中 AWS 的更多信息，请参阅 AWS 博客文章 [How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/)。
评估阶段对于确保将故障转移群集成功迁移到至关重要 AWS。如果您花时间收集信息并识别潜在的挑战，则可以制定全面的迁移计划，以最大限度地减少停机时间、降低风险并确保平稳过渡到 AWS。
## 动员
在将故障转移群集迁移到的过程中 AWS，移动阶段包括为群集的迁移做好准备， AWS 并对其进行测试以确保其正常运行。动员阶段包括以下步骤：
1. **准备目标环境**-在此步骤中，您将创建托管故障转移群集所需的 AWS 资源。这一点涉及到设置 VPC、子网、安全组和其他必要资源。
1. **准备源环境**：在此步骤中，您将为现有的失效转移群集做好迁移准备。这一点可能涉及到更改网络配置、配置复制或安装必要的软件。
1. **验证集群** – 在源环境和目标环境均准备就绪后，您可以执行验证测试，以确保集群正常运行。这一点涉及到运行一系列测试，以确保集群能够成功失效转移到目标环境。
1. **创建复制链接** – 验证测试完成后，您可以在源环境和目标环境之间创建复制链接。这样可确保将对源环境所做的任何更改复制到目标环境。
1. **监控复制**：建立复制链接后，监控复制过程以确保正确复制所有更改。
1. **对集群进行失效转移** – 验证复制是否正常运行后，对目标环境执行最后一次失效转移。这一点涉及到在源环境中停止集群服务，然后在目标环境中启动这些服务。
1. **测试失效转移**：失效转移完成后，执行测试，以确保集群上运行的应用程序和服务在新环境中运行正常
## 迁移
迁移 Microsoft 失效转移群集可能是一个复杂的过程，需要仔细规划和实施才能确保取得成功的结果。在对生产环境进行任何更改之前，必须彻底评测现有环境、识别潜在问题，并制定包括测试和验证在内的全面迁移计划。在迁移阶段，密切监控迁移过程并及时解决任何问题或意外行为非常重要。所有利益相关者（包括 IT 团队、业务用户和供应商）之间的沟通和协作对于实现顺利的迁移过程是至关重要的。
此外，重要的是要考虑迁移对在失效转移群集上运行的任何第三方应用程序或服务的影响。确定所有依赖关系并对这些应用程序进行全面测试，以确保它们在迁移后继续按预期运行。迁移阶段的另一个关键方面是制定回滚计划，以防在迁移过程中出现任何不可预见的问题或故障。理想情况下，该计划包括还原迁移和恢复原始环境的步骤，同时最大限度地减少对生产环境的任何影响。
最后，在迁移完成且失效转移群集在新环境中成功运行之后，必须执行迁移后验证和测试，以确认一切是否按预期运行。这一点包括监控性能、验证失效转移功能以及确保所有应用程序和服务都能正常运行。