仅当为共享磁盘分配了 CSV 时，Azure 数据中心 2019 故障转移群集在重新启动后无响应

Question

我们在 azure 2019 数据中心上的 2 节点集群中看到了一些非常奇怪的行为。我们没有立即发现这个问题，但在某个时候它开始发生，现在我们可以重复它。

我们有一个天蓝色的共享磁盘，我们在故障转移集群管理器中将其分配为集群共享卷。如果我们在再次启动时重新启动其中一个节点，Windows 资源管理器将在相当长的一段时间内没有响应。有趣的是，在 Windows 资源管理器变得有响应之前，powershell 也没有响应（甚至无法在其中键入命令）。我们使用任务管理器启动了 powershell。但是，从任务管理器启动命令窗口不会有延迟。

我们已从集群中删除了所有角色。删除已安装的软件并格式化 CSV 驱动器，使其全部干净。

如果我们以 CSV 形式删除磁盘并将其保留在可用磁盘中并重新启动，则不会出现延迟。如果我们将其作为 CSV 添加回来，我们会再次遇到延迟。我们可以根据需要重复此操作。

如果我们同时弹跳两个节点，则 explorer 和 powershell 最多需要 45 分钟才能再次激活。在没有 CSV 的情况下执行相同的操作没有问题。

我在事件日志中看不到任何表明问题的内容。这真是一个奇怪的现象。

我想说这是一次性的，但我们之前遇到过这个问题，并决定从头开始重新部署。一两天一切正常，然后又开始了。

我们几乎已经完成了可以尝试的事情，我想知道是否有任何类似的东西，或者是否还有其他我们可以看的东西。

Answer 1

这也是我们的客户偶然发现的一个已知问题。Microsoft 支持人员提出的建议如下：

• 检查您是否使用高级SSD作为共享磁盘；
• 确保将maxShares参数设置为与集群节点数一致，以使磁盘可在所有 FCI 节点之间共享；

这些建议都不适合我们。从头开始重新部署集群可以暂时解决问题，但正如您所注意到的，它迟早会回来。

解决此问题的一个实用方法是使用Storage Spaces Direct或Virtual SAN软件，该软件本质上是在两个 Azure 虚拟机之间复制存储，并允许您在其上构建 Microsoft 故障转移群集。作为 iSCSI 目标服务器的附加虚拟机也是一个有效的选择。