![Windows Server 2012 R2 上的群集共享卷因 iSCSI 轻微暂停而丢失](https://linux22.com/image/641392/Windows%20Server%202012%20R2%20%E4%B8%8A%E7%9A%84%E7%BE%A4%E9%9B%86%E5%85%B1%E4%BA%AB%E5%8D%B7%E5%9B%A0%20iSCSI%20%E8%BD%BB%E5%BE%AE%E6%9A%82%E5%81%9C%E8%80%8C%E4%B8%A2%E5%A4%B1.png)
我们在这里遇到了一个问题,连接到我们的 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 速度限制,以降低发生这种情况的风险。但是,从我目前所见,真正的解决方案是首先避免出现这些连接间隙...