新年上班第一天生产环境分布式文件系统崩了！！

柔情只为你懂 2021-09-07 06:12 235阅读 0赞

## 写在前面 ##

说来也怪，早不崩晚不崩，偏偏在上班第一天的时候，生产环境分布式文件系统崩了。我才刚来到我的工位坐下，“叮铃铃”电话响了，是运营打来的，“喂，冰河，快点看看，生产环境的图片和视频都无法上传了，系统崩溃了，快点看看啊！”。你说我一个不是做运维的，直接打来电话让我看生产环境的事故？原来是运维那哥们还没上班，额，好吧，我接受了，于是我迅速整理好工位，摆出电脑，登录服务器，一顿操作猛如虎，10分钟搞定了，剩下的就是异步复制图片和视频了。

今天，就和小伙伴们分享下，这次生产环境分布式文件系统出现的问题，以及我是如何10分钟排查问题和解决问题的。另外，本文不是基于生产环境事故写的，而是事后，我在我本机虚拟机上模拟的环境。解决问题的思路和方法都是一样的。

额，估计运维要被3.25了！！

文章已收录到：

[https://github.com/sunshinelyz/technology-binghe][https_github.com_sunshinelyz_technology-binghe]

[https://gitee.com/binghe001/technology-binghe][https_gitee.com_binghe001_technology-binghe]

## 问题定位 ##

通过登录服务器查看系统的访问日志，发现日志文件中输出了如下异常信息。

org.csource.common.MyException: getStoreStorage fail, errno code: 28
    	at org.csource.fastdfs.StorageClient.newWritableStorageConnection(StorageClient.java:1629)
    	at org.csource.fastdfs.StorageClient.do_upload_file(StorageClient.java:639)
    	at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:162)
    	at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:180)

很明显，是系统无法上传文件导致的问题，这个日志信息很重要，对问题的排查起到了至关重要的作用。

## 分析原因 ##

既然是上传文件出现了问题，那我先试试能不能访问以前上传的文件呢？经过验证，以前上传的文件是可以访问的，再次验证了是上传文件的问题。

既然生产环境是使用的分布式文件系统，一般情况下是没哈问题的，上传文件出现了问题，大概率的事件是服务器磁盘空间不足了。那我就来顺着这个思路排查下问题。

于是乎，我使用`df -h` 查看服务器的存储空间使用率，已经达到91%了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center]

**嗯，磁盘空间有可能是引起问题的原因。接下来，再来进一步确认下是否是磁盘空间造成的问题。**

于是，我再打开`/etc/fdfs/`目录下的tracker.conf的配置，看到预留的存储空间为10%（注：这里的分布式文件系统使用的是FastDFS）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 1]

看到这里，可以确定就是磁盘空间不足造成的无法上传文件的问题。

**总体原因就是：服务器磁盘空间已使用91%，而在分布式文件系统的配置中预留的磁盘空间为10%，实际在上传文件的时候，系统已经检测到当前服务器剩余的磁盘空间不足10%，抛出异常，拒绝上传文件。**

到此，问题出现的原因已经确定了，接下来就是要解决问题了。

## 解决问题 ##

首先，有两种方式可以解决这个问题，一种就是删除不需要的文件；另一种就是扩容磁盘空间。

### 删除不需要的文件 ###

这种方式慎用，这里，我也简单的介绍下这种方式。我给小伙伴们提供了几种递归删除的方式。

递归删除.pyc格式的文件。

find . -name '*.pyc' -exec rm -rf { } \;

打印当前文件夹下指定大小的文件

find . -name "*" -size 145800c -print

递归删除指定大小的文件(145800)

find . -name "*" -size 145800c -exec rm -rf { } \;

递归删除指定大小的文件，并打印出来

find . -name "*" -size 145800c -print -exec rm -rf { } \;

下面是对上述命令的一些简要说明。

*  `"."` 表示从当前目录开始递归查找
 *  `“ -name '*.exe' "`根据名称来查找，要查找所有以.exe结尾的文件夹或者文件
 *  `" -type f "`查找的类型为文件
 *  `"-print"` 输出查找的文件目录名
 *  `-size 145800c` 指定文件的大小
 *  `-exec rm -rf {} \;` 递归删除（前面查询出来的结果）

### 扩容磁盘空间 ###

这里，冰河推荐使用这种方式，我修复生产环境的故障也是使用的这种方式。

通过查看服务器的磁盘空间发现，/data目录下的空间足足有5TB，呵呵，运维哥们为啥不把文件系统的数据存储目录指向/data目录呢。于是乎，我开始将文件系统的数据存储目录迁移到/data目录下，整个过程如下所示。

注意：这里，我就简单的模拟将 **/opt/fastdfs\_storage\_data下的数据迁移至/data下**。

（1）拷贝文件，迁移数据

cp -r /opt/fastdfs_storage_data  /data
    cp -r  /opt/fastdfs_storage  /data
    cp -r /opt/fastdfs_tracker /data

（2）修改路径

这里需要修改文件系统的 /etc/fdfs/storage.conf ,mod\_fastdfs.conf ,client.conf,tracker.conf文件。

*  /etc/fdfs/storage.conf

store_path0=/data/fastdfs_storage_data
    base_path=/data/fastdfs_storage

*  /etc/fdfs/mod\_fastdfs.conf

store_path0=/data/fastdfs_storage_data  (有两处)
    base_path=/data/fastdfs_storage

*  /etc/fdfs/client.conf

base_path=/data/fastdfs_tracker

*  /etc/fdfs/tracker.conf

base_path=/data/fastdfs_tracker

重新建立 M00 至存储目录的符号连接：  
ln -s /data/fastdfs\_storage\_data/data /data/fastdfs\_storage\_data/data/M00

（3）杀掉进程, 重启存储服务 (追踪器和存储器)

依次执行以下命令

pkill -9 fdfs
      service fdfs_trackerd start
      service fdfs_storaged start

（4）修改文件的读取路径 nginx配置

location ~/group1/M00{ 
    	root /data/fastdfs_storage_data/data;
    }

（5）重启nginx

cd /opt/nginx/sbin
    ./nginx -s reload

好了，问题搞定，运营可以正常上传图片和视频了。

**好了，今天就到这儿吧，我是冰河，大家有啥问题可以在下方留言，也可以加我微信：sun\_shine\_lyz，我拉你进群，一起交流技术，一起进阶，一起牛逼~~**

[https_github.com_sunshinelyz_technology-binghe]: https://github.com/sunshinelyz/technology-binghe
[https_gitee.com_binghe001_technology-binghe]: https://gitee.com/binghe001/technology-binghe
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center]: /images/20210901/443e21c735e34e3c8e8bce6f4f68c324.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210901/bc768b5fa668483085418244f689c709.png