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

Modified on: Fri, 08 Nov 2019 23:20:02 +0800

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

从我的测试中,如果管理程序当前安装的GlusterFS节点出现故障(使用默认的GlusterFS设置),则连接超时大约需要45秒,而glusterfs客户端会故障转移到另一个节点。在此45秒内,IO操作将挂起,从VM的角度来看,这意味着磁盘无响应。

我知道对于Linux,如果磁盘没有响应,经过一段时间(我不确定多长时间)内核会将文件系统重新安装为只读。

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

我的问题是,我应该设置多少这样的值,以便大多数操作系统能够容忍没有副作用的虚拟磁盘无响应的时间?

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

相关信息:

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

作者:,Pellaeon

最佳答案

磁盘驱动程序通常会等到超出可配置的超时时间,甚至报告所请求操作的错误。

如您所知,这是Linux中的/sys/block/<devicename>/device/timeout,默认为 60 30秒。

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

只要上游没有报告错误,您将看不到立即操作(如FS的ro-remount),即使在超时结束后您通常会看到更多的错误处理程序操作(记录,重置设备等) 。)在将错误传递回上层之前。

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

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

通常,您需要将故障转移时间尽可能低,同时仍然可以在没有过早故障转移的情况下运行,因为偶尔会出现负载峰值或网络故障。确定适合您的特定情况的正确值是在长时间的操作中进行的反复试验。对于通用服务器虚拟机,如果可行并且您的基础架构支持,我会针对大小为10秒的事情。

作者:,the-wabbit

相关问答

添加新评论