Hi 你好,欢迎访问!登录
当前位置:首页 - Linux - 正文 君子好学,自强不息!

记TFS一次人为故障引起的连锁反应

2016-05-02Linux撒加4127°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的运维又有了一个新的层次。

  选择打赏方式
微信赞助

打赏

QQ钱包

打赏

支付宝赞助

打赏

  选择分享方式
  移步手机端
记TFS一次人为故障引起的连锁反应

1、打开你手机的二维码扫描APP
2、扫描左则的二维码
3、点击扫描获得的网址
4、可以在手机端阅读此文章
未定义标签

发表评论

选填

必填

必填

选填

请拖动滑块解锁
>>


  用户登录