我正在帮助解决 Windows Server 2019 Data Center 上现有的 Windows 故障转移群集问题。该群集设置为使用存储空间直通 (http://aka.ms/s2d)，但部署存在问题，具体来说，S2D 使用的 NIC 端口上的网络驱动程序版本不匹配。为了帮助恢复集群，我将关闭集群，并将所有节点上的所有网络端口的驱动程序版本改为相同。目前的计划是在集群离线后运行 NIC 驱动程序安装，然后同时重新启动所有节点并使集群联机。
问题就在这里：除了对驱动程序软件进行就地更新/升级外，显然没有关于如何安全地执行此操作的官方文档。删除设备条目，然后重新安装新的驱动程序软件，这似乎“有点过分”，因为这还需要完全重置网络堆栈，通过（有点晦涩的）powershell 命令。
问题（分为三部分）：
是否有已知的最佳实践来更新网卡运行 S2D 的故障转移群集上的驱动程序（不要与 HDD、SDD 或 NVMe 驱动程序混淆) 是否可以保证干净的驱动程序更新而不会干扰集群？
我的“就地”方法是否足够并能按预期发挥作用？
或者这个集群只是简单地完成了，可能需要销毁并重建？
答案1
几个月后，我找到了答案。具体来说，回答我问题的每个部分：
- 目前确实没有已知的方法或文档可供参考（我能找到）。
- 就地方法是可行的，但有一些注意事项。
- 您不需要破坏集群，尽管如果您粗心大意，您很容易就会这样做。
您需要具有管理员 powershell 访问权限，并且需要双手弄脏直至手腕才能完成此操作。 这是一个危险的过程。如果操作不当，您的集群可能会瘫痪甚至被毁掉。我无法介绍每个安装，我只能描述我如何解决问题。如果您不确定以下步骤，或者没有驱动程序，或者有任何其他可能导致问题的原因，请不要继续。如果出现问题，您可以保留这两个部分，我不会承担责任。 您已被适当警告有关数据丢失的危险。
对于我的具体安装，问题出在 NIC 本身的特定驱动程序上。经过大量研究（包括深入阅读 NIC 驱动程序的供应商勘误表），我能够确定要使用的正确版本级别。卸载所有网络驱动程序版本和/或回滚到所需的特定版本后，NIC 表现良好，并且一旦纠正过程完成，就一直表现良好。不幸的是，这需要一次将一个节点脱机，但只要您有耐心，这是可行的。
- 开始之前，请确保您已准备好所有必备驱动程序。将驱动程序复制到目标节点，以便本地可用。集群上的数据（特别是集群共享卷）已备份、克隆或移动到安全位置。您认识到，您将降低正在使用的任何集群共享卷以及任何超融合虚拟机的性能。如果出现问题，您愿意并能够从集群中弹出一个节点。 这些都是重要的先决条件，您应该确保自己能够根据自己的决定完成其中任何一项/全部。在至少考虑完所有这些条件之前，请不要继续。
- 对于需要 NIC 驱动程序更新的给定节点，耗尽所有活动角色并准备暂停它，就像开始维护或修补周期一样。
- 一旦耗尽/暂停完成，请继续禁用“包装”NIC 的任何 hyper-v 交换机（如果您有这种常见的安排）。一些部署使用此安排来尝试将 NIC“融合”或“绑定”到统一接口中。 请注意，某些集群不会有此功能，如果是这种情况，请继续下一步。
- 继续禁用连接到私有结构交换机的 Windows 中的物理网卡。此时，不应有任何流量从集群传递到节点。
- 驱动程序回滚可能会触发删除 NIC 的 DCB 和/或 QoS 设置，具体取决于供应商的安装过程。虽然不太可能，但如果是这种情况，下一步仍有可能跨越节点的无可挽回点。请确保您已准备好应对节点由于此活动而无法重新加入集群的可能性。
- 继续卸载和/或回滚分配给私有结构交换机的 NIC 上的驱动程序。如果它们默认为从 Microsoft 下载的库存驱动程序，则没问题，因为您可以用之前在本地启动驱动器上暂存的驱动程序替换它们。
- 如果 Microsoft 提供的 NIC 驱动程序不是您需要的正确版本，或者驱动程序只能从供应商处获得，请继续安装 NIC 驱动程序。根据驱动程序软件和您的情况，您可能需要重新启动节点 - 希望不会，但如果是这种情况，仍需做好准备。
- 检查连接到私有结构交换机的每个 NIC 的驱动程序修订级别。 它们必须是您需要的版本。如果不是，请采取一切必要的补救措施，安装正确的驱动程序。
- 确保主机上存在所有正确的设置，具体来说，Windows 的数据中心桥接功能已启用，所有私有结构 NIC 端口都已启用 RDMA，这些 NIC 端口的 DCBX 接受功能已启用。已禁用（这是正确的，不是打字错误，而是参数
Set-NetQoSDcbxSetting -Willing），您所需要的 QoSPolicies 没有冲突，您有一个“集群”QoS 策略、一个“SMB”策略和一个“SMB Direct”策略，您为“集群”和“SMB Direct”创建了 ETS 流量类（请注意，使用端口 445 时“SMB”将被“SMB Direct”覆盖），并且您分别为集群（7）和 SMB（3）分配了 NetQoS 流控制。 - 确认所有主机 NIC 设置后，通过
Enable-NetAdapterQospowershell 命令为每个 NIC 启用 QoS。 - 重新启用物理 NIC 端口以重新获得对私有结构交换机的访问权限。
- 如果使用 Hyper-V 包装器交换机，请重新启用相应的 Hyper-V“NIC”。
- 打开性能监视器（每个人都忘记了的那个老旧、破旧的监视器），并在屏幕上放置一些 RDMA 流量的线条。重新启用 NIC 后，您应该开始看到少量一致的数据传入，因为即使节点处于暂停状态，集群仍会继续默默地传送 S2D 流量。另外，打开事件查看器并查看您能找到的任何集群日志，寻找与其他节点进行数据交换的证据。
- 如果您认为该节点功能正常，请继续恢复其运行。您不必将角色故障转移回原始节点，但这完全取决于您和您的情况。
- 一旦集群共享卷或多或少稳定，您就可以对每个需要它的节点重复此过程。 在另一个节点上尝试此操作之前，您需要确保您的 CSV 是健康且稳定的。不要急于求成。
- 一旦所有节点稳定，确保整个集群恢复服务。
答案2
在具有不同固件版本的 NIC 无法很好地协同工作的情况下，您所做的操作是有意义的。但通常情况下，您应该探索 CAU 集群感知更新作为一种可能的选择。DELL/HP 和联想已将 CAU 集成到其工作流程中。