我们在这里遇到了一个问题，连接到我们的 Hyper-V 2012 R2 集群的集群共享卷会因为其使用的 iSCSI SAN 连接出现轻微中断而丢失/出现故障。这当然是一个问题，因为它会导致所有虚拟机崩溃或关闭。
当主 SAN 节点故障转移到其副本时，iSCSI SAN 连接就会中断。在辅助节点恢复之前，大约有 10-15 秒的停机时间。我们正在使用基于 FreeBSD + ZFS 的解决方案与 HAST + CARP 结合使用，以提供高可用性存储。
当非群集 iSCSI LUN 安装在 Windows 端时，故障转移会起作用，例如与启动器建立正常连接。 I/O 会暂停，直到重新建立连接。我期望 CSV 有同样的行为，但遗憾的是，它似乎对 I/O 超时非常挑剔。
有没有办法延长 CSV 超时时间，或者也许有其他方法可以解决此问题？
答案1
我发现很多人都有这样的情况。
大多数情况下，问题在于以下之一：
备份流量与集群管理流量并非完全隔离。由于以太网是个麻烦，数据包冲突的增加大大减少了带宽和心跳的往返时间。然后砰的一声！CSV 就瘫痪了
另一个常见问题是与总体负载相比，总体以太网速度太低。当备份开始时，由于各种原因，您会遇到流量激增的情况。
据我所知，没有办法延长超时时间。CSV 对心跳超时的要求确实非常苛刻。在几个站点上遇到此问题后，我们在 BackupChain 中设置了 I/O 速度限制，以降低发生这种情况的风险。但是，从我目前所见，真正的解决方案是首先避免出现这些连接间隙...