记TFS一次人为故障引起的连锁反应
2016-05-02Linux撒加4603°c
A+ A-环境介绍
公司TFS集群由2台Name Server和5台Data Server构成,使用Tengine-tfs模块进行图片的上传,图片的处理使用LUA调用gm命令。
5台Data Server使用300G * 2 + 2TB * 12的方式构成,裸容量120TB
出现的问题
上周在巡检TFS集群的时候,发现每台DS Server的容量都只有20G,而且通过ssm命令发现整个TFS集群的存储容量使用率已经到96%了,通过排查发现每台DS上的ds.conf中,mount_maxsize都只配置了20G,造成2TB的磁盘严重使用不当。
解决过程
既然是mount_maxsize配置不合理,那就配置为合理的值就好,将DS一台一台的下线进行调整。
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 1922859824 1616498672 208685480 89% /opt/websuite/tfs/data/disk1
/dev/sdc1 1922859824 1616498660 208685492 89% /opt/websuite/tfs/data/disk2
/dev/sdd1 1922859824 1616498276 208685876 89% /opt/websuite/tfs/data/disk3
/dev/sde1 1922859824 1616498716 208685436 89% /opt/websuite/tfs/data/disk4
/dev/sdf1 1922859824 1616498600 208685552 89% /opt/websuite/tfs/data/disk5
/dev/sdg1 1922859824 1616498732 208685420 89% /opt/websuite/tfs/data/disk6
/dev/sdh1 1922859824 1616498272 208685880 89% /opt/websuite/tfs/data/disk7
/dev/sdi1 1922859824 1616498568 208685584 89% /opt/websuite/tfs/data/disk8
/dev/sdj1 1922859824 1616498064 208686088 89% /opt/websuite/tfs/data/disk9
/dev/sdk1 1922859824 1616497660 208686492 89% /opt/websuite/tfs/data/disk10
/dev/sdl1 1922859824 1616497844 208686308 89% /opt/websuite/tfs/data/disk11
/dev/sdm1 1922859824 1616498188 208685964 89% /opt/websuite/tfs/data/disk12
mount_maxsize的大小不应超过df中Available的大小,注意直接执行df命令出来的单位默认是KB
咨询了张友东,可下线一台机器,停掉DS,等待DS上所有的数据都复制完,然后再format,启动DS,当时其实并不理解这个处理过程,导致下一个不部分才有内容。
我按照我自己的理解,将其中一台DS下线,format了DS,之后就重启了DS,(其实此时需要通过命令来确定复制是否OK的),启动后发现没有报错,然后等了半小时后将其他的DS也一一做了这样的操作,原本以为磁盘的容量就这样调整完了,也没报错,没得问题。
解决后的连锁反应
第二天,业务开始报上传图片时而可以,时而不能上传图片,看日志有报错:
a)block创建失败
b)block流失,无法执行复制任务
到第二天下午5点多时,故障达到高峰,整个业务已不正常,这时候看TFS的官方wiki,发现一些命令的使用跟当前安装的TFS版本比,很多指令不支持,我擦啊。。。。。。
随后整理了下思路,既然是block无法创建,那先看看不能创建block的id是什么,以及确定丢失的block,通过命令
ssm -s NSIP:PORT -i block,输出
BLOCK_ID VERSION FILECOUNT SIZE DEL_FILE DEL_SIZE SEQ_NO COPYS
17652 0 0 0 0 0 1 2
17653 0 0 0 0 0 1 2
17654 0 0 0 0 0 1 2
我看到COPYS的列都是2,但是个别是0,还有是1的,想到NS里配置了副本的数量刚好是2,此时连忙执行
ssm -s NSIP:PORT -i block |awk '($8 ~ /1/)'
ssm -s NSIP:PORT -i block |awk '($8 ~ /0/)'
两条指令的输出结果中,有问题的blockid与日志中报错的blockid对应上了,到这基本就有了解决问题的思路了,那就是将这些有问题的blockid移除。
此处查看TFS的官方wiki,又被坑了,我日啊。。。
研究下了tfstool指令和admintool后,写了一个脚本来清理有问题的blockid(此处也是单独实验了下,发现确实能处理有问题的block,才决定用脚本批量来做)
#!/bin/bash
badblk=`/opt/websuite/tfs/bin/ssm -s 172.16.4.71:8100 -i block |awk '($8 ~ /0/)' |awk '{print $1}'`
for i in $badblk ;
do
/opt/websuite/tfs/bin/admintool -s 172.16.4.71:8100 -i "removeblk $i"
done
如果COPYS为1的block是因为还没有同步,这些BLOCK是不需要处理的,待同步后就好了,对于COPYS为0的block就是有问题的,需要清理。脚本执行完后,等待了一会,再次执行
ssm -s NSIP:PORT -i block |awk '($8 ~ /1/)'
ssm -s NSIP:PORT -i block |awk '($8 ~ /0/)'
发现所有的block的COPYS都为2了,此时上传图片又恢复了正常。
通过这次事件,还是明确了一件事,能让脚本处理的事情,尽量不要让人去做,人的不确定因素太多了,在做运维标准化的时候,尽量减少人为配置的项目还是可以避免很多问题的。不过此次故障排除也对TFS的运维又有了一个新的层次。