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

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

在我的testing中,如果pipe理程序当前挂载的GlusterFS节点失败(使用默认的GlusterFS设置),连接超时需要大约45秒,而glusterfs客户端故障转移到另一个节点。 在这45秒内,IO操作将挂起,从虚拟机的angular度来看,这意味着磁盘变得无法响应。

我知道对于Linux来说,如果磁盘变得没有响应,一段时间之后(我不知道多久)内核将以只读的方式重新挂载文件系统

我也可以降低GlusterFS卷的network.ping-timeout ,这会减less故障切换时间。

我的问题是,我应该设置这个值多less,以便大多数操作系统可以容忍虚拟磁盘没有反应时间没有副作用?

更确切的说,我想知道Windows NTFS,FreeBSD UFS / ZFS和Linux ext4可以容忍的磁盘无响应时间。 涉及的参数是什么? (例如,Linux上的/sys/block/sda/device/timeout

相关信息:

  • 如何降低Gluster FS的对等超时/降低对等的影响?

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

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

磁盘驱动程序通常会等到超过可configuration的超时时间之后才报告所请求操作的错误。

正如你已经发现的那样,这是Linux中的/sys/block/<devicename>/device/timeout ,默认值为60 30秒。

Windows将该configuration存储在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\的全局设置TimeoutValue (REG_DWORD), TimeoutValue 60秒。

只要上游没有报告错误,你就不会立即看到行动(就像是重新安装FS),即使在超时之后,你通常会看到更多的error handling程序动作(logging,重置设备等)一个错误被传回到上层。

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

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

一般来说,您将希望保持尽可能低的故障切换时间,同时由于偶尔出现的负载峰值或networking故障而仍然不会过早地进行故障切换。 确定适合您使用的具体情况的正确价值是在长时期的操作中非常多的反复试验工作。 对于一般用途的服务器虚拟机,如果可行并且得到您的基础设施的支持,我会把目标定在10秒内。

FreeBSD有geom_mountver( https://www.freebsd.org/cgi/man.cgi?gmountver ),可以用它来容忍任何故障转移时间。 如果您使用ZFS,则可能需要禁用deadman计时器; 如果一个IO在15分钟内没有完成(IIRC),将会使该盒子恐慌。