记TFS一次人为故障引起的连锁反应
2016-05-02Linux撒加4550°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的运维又有了一个新的层次。
