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

Question

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

我们有一个 Azure 共享磁盘，我们在故障转移群集管理器中将其指定为群集共享卷。如果我们在重新启动时重新启动其中一个节点，Windows 资源管理器将在相当长的一段时间内无响应。有趣的是，在 Windows 资源管理器恢复响应之前，PowerShell 也没有响应（甚至无法在其中输入命令）。我们已经使用任务管理器启动了 PowerShell。但是从任务管理器启动命令窗口没有延迟。

我们已经从集群中删除了所有角色。删除了已安装的软件并格式化了 CSV 驱动器，因此一切都干净了。

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

如果我们同时重启两个节点，则 Explorer 和 Powershell 最多需要 45 分钟才能再次激活。如果不使用 CSV 执行相同操作，则不会出现任何问题。

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

我想说这只是个例，但我们之前也遇到过这个问题，所以决定从头开始重新部署。一切正常，一两天后又开始出现问题。

我们可以尝试的事情已经差不多结束了，我想知道是否有人见过类似的事情，或者是否还有其他我们可以研究的事情。

Answer 1

这是一个已知问题，我们的客户也曾遇到过。Microsoft 支持人员给出的建议如下：

• 检查您是否正在使用高级 SSD作为共享磁盘；
• 确保设置最大分享量与集群节点数一致的参数，使得磁盘可在所有 FCI 节点之间共享；

这两个建议对我们都没有用。从头开始重新部署集群可以暂时解决问题，但正如您所注意到的，这个问题迟早会再次出现。

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