环境介绍

公司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的运维又有了一个新的层次。

转自：grapenvine.cn

填问卷！赢大奖！DTCC 2016门票等你拿！

2016第七届中国数据库技术大会(DTCC)将于2016年5月12日-14日在北京国际会议中心盛大召开！

本届大会云集了100余位国内外顶尖专家，共设2大主题会场，25个技术专场，吸引了超过5000人次的行业人士参加。

这样一场旷世盛宴，你，想不想参加？

现在，机会来了！

即日起，填写DTCC 2016会前调查问卷，就有机会赢取价值2600元的大会门票1张！仅限10张！

快来试试吧！

点击阅读原文，即刻填写问卷！

↓↓↓

ITPub博客

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

最新文章