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