聊聊NFS为什么会Hang

昨天有个朋友咨询一个问题,他通过NFS MOUNT了一个分布式文件系统,发现对这个文件系统df的时候经常hang死,他检查了一番系统,发现内存使用率很高,大部分物理内存都被cache占用了。他想通过分析cache中都有哪些数据,通过这个分析来确认cache占用率高和NFS hang之间是否存在关联关系。当时我的建议是首先不要把问题直接定位到OS内存上,如果系统不存在严重的SWAP,哪怕物理内存使用率达到98%,也是关系不大的。

实际上使用NFS文件系统,出现客户端hang死,或者df命令HANG死的情况并不少见,我这些年里也遇到过多次。我遇到的NFS hang死问题的原因也十分复杂,不过大多数都与NFS BUG、网络问题、系统资源消耗过高、IO负载过大等有关。

NFS客户端访问NFS文件hang住,一般来说有三种可能性,一种是客户端出现问题,第二种是服务端出现问题,第三种是客户端和服务端都存在问题。似乎这个总结有点太笼统了,也有点投机取巧,不过穷举法是我们在针对未知问题分析的最重要的方法。如果我们不能穷举所有的可能性,那么在问题诊断分析的时候就可能无法定位。在我多年的经验里,很多当时认为十分灵异的问题,都是因为我们以前的知识面不足,无法穷举到真正的故障路径。

聊聊NFS为什么会Hang

上面的思维导图是我这些年遇到过的一些NFS HANG的情况,其中遇见最多的还是和网络有关的,自从NFS V3/V4版本之后,NFS或者OS自身BUG导致的问题逐渐减少,而网络方面遇到的问题逐渐变多起来。特别是防火墙问题,最近五六年里,我遇到的大型系统中的NFS问题大部分和防火墙有关。随着企业对网络安全的要求越来越高,防火墙也不断地在调整策略,有时候有一条策略就会导致NFS的网络包被防火墙过滤,从而导致NFS的故障。五六年前我遇到过一个客户的NFS故障,只要访问一个文件NFS就会HANG死,访问其他文件就啥事没有。当时实在没办法了只能用网络抓包的方式去跟踪,最后发现客户最近上了一个敏感词过滤的策略,因为这个文件名带有敏感词汇,因此网络就丢包了。

实际上IP存储专网建设十分重要,关键系统使用NFS的时候一定要使用IP存储专网,最好不要经过防火墙,不过很多大企业对于跨机房访问的网络安全管理十分变态,防火墙是必须要经过的,一个NFS访问经过至少两个防火墙,一旦网络安全管理员与存储管理员之间没有很好的沟通,那么因为防火墙导致的NFS问题那就少不了了。另外我们以前遇到的大多数NFS故障场景都没有使用IPSAN专网,NFS使用的网络是和业务网混合使用的,业务网出现的任何问题,都会引起NFS文件系统的抖动,从而导致NFS服务不稳定。

是否Socket hang的问题可以通过netstat命令来看是不是存在大量的TCP连接处于CLOSEWAIT状态,如果存在这种情况,那么很可能你遇到了socket hang。Socket hang大多数和IO负载过高、客户端或者服务器端OS相应慢或者某个OS bug有关。也可能和TCP的keepalive参数设置有关。

另外一点是我们是用NFS的环境中,可能还安装了数据库服务器、中间件服务器等,这些系统要求调整OS的网络参数,而这些参数的调整很可能并不适合NFS服务。其中常见存在冲突的几个参数如下:

  • lnet.ipv4.tcp_keepalive_time
  • lnet.ipv4.tcp_keepalive_intvl
  • lnet.ipv4.tcp_keepalive_probes
  • lnet.ipv4.tcp_tw_recycle = 0
  • lnet.ipv4.tcp_tw_reuse = 0
  • lnet.ipv4.tcp_retries1 = 3
  • lnet.ipv4.tcp_retries2 = 15

实际上NFS HANG的问题分析因为涉及的原因很多,所以往往还是不容易定位的,不过如果df命令hang,而且是可重现的,那么分析起来还是有方法的。最好的防范就是使用strace去跟踪df命令的堆栈。看看hang在什么地方,就比较容易定位问题了。

最后要说明的是,messages日志是一定要首要分析的,不管是客户端还是服务端的messages日志都应该尽早去看。虽然说很可能我们看到的只是NFS命令超时这类的比较笼统的信息。

文章版权声明

 1 原创文章作者:繁花三千只取一朵,如若转载,请注明出处: https://www.52hwl.com/99427.html

 2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈

 3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)

 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2024年1月17日 上午12:26
下一篇 2024年1月17日 上午12:26