运维人员踩坑记录之总是被忽略的NFS难题

场景

某一天晚上,小明的手机突然收到一堆短信,他很是奇怪,现在的人应该基本都是玩微信,谁还玩短信这么无聊,小明随之一看,当场吓了个半死,是一堆服务器宕机的告警!

图片.png 

难道机房被火力***了吗?冷静,冷静,小明忍住心慌,打开了电脑,然后打开自己平时用来测试服务器网络的脚本,咦,网络全通,然后再远程服务器看看,发现远程正常,防火墙正常,SNMP服务正常,应用服务正常,但告警短信还是不停的发过来。

恐怖如斯!

不过小明是见过大场面的运维,他很想直接关手机,然后睡觉,但是运维的职业精神引导着他打开了监控服务器,经过一系列检查,确实无法正常监控,然后这些服务器都有一个共同点,df -h卡死

到这里,其实有些经验的人就应该发现,这些服务器都是挂载着同一个NFS服务,而这个NFS服务挂掉了!

图片.png 

解决方法

一、如果NFS服务器能恢复,这当然是最理想的情况了,当nfs服务器恢复之时,告警就会自动取消

二、但还是会有一些尴尬的时候,就是nfs服务器死得不能再死了,短时间内或者永久没办法恢复

解决思路:

1、强制取消客户端挂载

2、重新挂载一个新的NFS

处理方法:

1、强制取消客户端挂载

umount -lf nfs目录

2、若不能正常取消挂载,还有另一个办法

df -h主要的文件在/etc/mtab和/etc/fstab,nfs的挂载信息是在/etc/mtab,而且它是一个软连接

图片.png 

而/proc/self/mounts是一个内核创建的文件,无法修改,所以我们只能修改/etc/mtab,可以直接用sed进行修改,例如
sed -i ‘29d’ /etc/mtab

图片.png 

但是这样,软连接其实会直接中断,或者直接将文件备份,重新创建一个mtab文件,将异常的nfs挂载信息清理了,就能正常df -h了,但是实际上这条异常的nfs信息是没有清理的,还是需要将物理机重启一遍

温馨提醒,不管是遇到什么故障,第一时间,是冷静有条理的分析!


猜你喜欢

转载自blog.51cto.com/15024210/2680166