有人知道如何从 Sun(Oracle)统一存储安装 nfsshare 吗?我们在 debian squeeze 上运行常用的硬盘和 nfs4。我们通过 Xen 的这个 NFS 共享运行我们的虚拟机。当我们的 SAN 在星期五丢失磁盘并开始重新同步(重建)时,所有 nfs 共享都停滞了,我们的一个 Dom0 崩溃得相当严重,nfs 共享导致许多虚拟机瘫痪。是否有任何安装选项可以使此错误更无缝地发生?
答案1
我不太了解 Debian,也不太了解 NFSv4。
但是,如果挂载选项仍然与 NFSv3 相同,我最喜欢的(对于任何 nfs-client-mount 和任何操作系统)是:
- 困难(因此不断重试,重试次数没有指数退避)
- bg(继续在后台尝试,而不停止安装“后面”的任何东西)
- intr(如果你真的想要——你可以终止挂载而无需重新启动客户端)
大小和大小现在默认已经调整到了合理的尺寸 - 请查看你的 lokcal 手册页。
我曾经使用过“w尺寸=32768,r尺寸=32768“以便在此之前获得更好的转会利率。
您还必须注意 nfs 服务器端(如果 NFSv4 在这里仍然与 NFSv3 相同):
- 首先启动所有 NFS 服务
- 最后启动 NFS 服务的服务 IP
否则,客户端将尝试重新连接空的“nfs-service”,并且会失败而不是重试。
顺便问一下 - 在这种情况下,SAN 与 Sun Unified Storage 有什么关系?当您“丢失”SAN 时会发生什么?为什么重建过程会破坏一切?存储不是冗余的吗?
答案2
不久前,我在 XenServer 上遇到了类似的问题,并对此进行了一些研究。显然,出于某些原因,XenServer 对其 NFS 挂载使用软挂载,并且超时时间相对较短。有些人建议直接在 xen 服务器上修改挂载脚本,因为挂载选项无法通过任何其他方式配置。显然这是唯一的方法。我们不再有这个问题,因为我们现在 100% 使用 vmware,它对 NFS 减速的适应性更强。
然而,实际问题在于底层存储的写入性能降低,这在很大程度上取决于您的 RAID 控制器(即重建期间性能下降的程度)。您可以尝试使用阵列重建的优先级设置,但这对我的控制器(Adaptec 5085)没有任何影响。您可以通过为 NFS 服务器购买更多内存来稍微改善这种情况。这样,NFS 守护进程将只写入日志条目,但它会将数据保存在 FS 缓存中直到更好的时间,但同样,根据您的情况,它可能有帮助,也可能没有帮助。
我还注意到该问题更常发生在具有奇偶校验的存储(即 RAID-5 和 RAID-6)上,因此我们尽可能尝试为虚拟机使用镜像存储。