大多数操作系统 (VM) 可以容忍的合理存储故障转移时间是多少？

Question

我有一个 GlusterFS 2 节点 2 副本设置。我打算将它用作 OpenStack 实例存储，其中存储了 VM 磁盘映像。

根据我的测试，如果虚拟机管理程序当前安装的 GlusterFS 节点出现故障（使用默认 GlusterFS 设置）连接超时需要大约 45 秒，并且 glusterfs 客户端故障转移到另一个节点。在这 45 秒内 IO 操作将挂起，从 VM 的角度来看，这意味着磁盘变得无响应。

我知道对于 Linux，如果磁盘变得无响应，一段时间后（我不确定多长时间）内核会将文件系统重新挂载为只读。

我还可以降低 GlusterFS 卷的值network.ping-timeout，这将减少故障转移时间。

我的问题是，我应该设置多少这个值，以便大多数操作系统可以容忍虚拟磁盘的无响应时间而没有副作用？

更准确地说，我想知道 Windows NTFS、FreeBSD UFS/ZFS 和 Linux ext4 可以容忍的磁盘无响应时间。涉及的参数有哪些？（例如，/sys/block/sda/device/timeout在 Linux 上）

相关信息：

• 如何降低 Gluster FS 对等超时/减少对等影响？

• http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465

更新：@the-wabbit 已经回答了关于 Linux 和 Windows 的问题，我也想知道 FreeBSD 的情况

Answer 1

磁盘驱动程序通常会等待，直到超过可配置的超时，然后才报告所请求的操作的错误。

正如您所发现的，这是/sys/block/<devicename>/device/timeout在 Linux 中，默认为60 30 秒。

Windows 将此配置存储为全局设置TimeoutValue(REG_DWORD)，HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\默认时间为 60 秒。

只要上游没有报告错误，您就不会看到任何立即操作（例如 FS 的 ro-remount），即使在超时之后，您通常会在之前看到更多错误处理程序操作（记录、重置设备等）。错误被传递回上层。

但请注意，还会有其他影响影响整体可用性。

• 应用程序或系统服务可能会实现自己的超时并在到期时抛出异常
• 在请求周转率较高的服务器上，您将看到队列已满且内存耗尽，因为新客户端不断提交新请求，而旧请求仍在等待存储响应。
• 如果发生故障的设备上碰巧有交换空间，则所有页面输入/页面输出请求都将停止，从而有效地阻止在这些内存页面上工作的进程。

一般来说，您会希望保持尽可能短的故障转移时间，同时仍能正常运行，而不会因偶尔的负载峰值或网络故障而导致过早的故障转移。为您的具体使用情况确定正确的值需要经过长时间的操作进行反复试验。对于通用服务器虚拟机，如果可行并且您的基础设施支持的话，我的目标是 10 秒。