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

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

[[383073]]

作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址:

https://github.com/sunshinelyz/mykit-delay

写在前面

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

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

额,估计运维要被3.25了!!

文章已收录到:

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

问题定位

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

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

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

分析原因

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

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

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

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

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

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

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

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

解决问题

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

删除不需要的文件

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

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

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

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

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

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

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

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

  1. 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)拷贝文件,迁移数据

  1. cp -r /opt/fastdfs_storage_data  /data 
  2. cp -r  /opt/fastdfs_storage  /data 
  3. cp -r /opt/fastdfs_tracker /data  

(2)修改路径

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

  • /etc/fdfs/storage.conf
  1. store_path0=/data/fastdfs_storage_data  
  2. base_path=/data/fastdfs_storage 
  • /etc/fdfs/mod_fastdfs.conf
  1. store_path0=/data/fastdfs_storage_data  (有两处) 
  2. base_path=/data/fastdfs_storage  
  • /etc/fdfs/client.conf
  1. base_path=/data/fastdfs_tracker 
  • /etc/fdfs/tracker.conf
  1. base_path=/data/fastdfs_tracker 

重新建立 M00 至存储目录的符号连接:ln -s /data/fastdfs_storage_data/data /data/fastdfs_storage_data/data/M00

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

依次执行以下命令

  1. pkill -9 fdfs 
  2.  service fdfs_trackerd start 
  3.  service fdfs_storaged start 

(4)修改文件的读取路径 nginx配置

  1. location ~/group1/M00{ 
  2.  root /data/fastdfs_storage_data/data; 

(5)重启nginx

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

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

本文转载自微信公众号「 冰河技术」,可以通过以下二维码关注。转载本文请联系 冰河技术公众号。

 

责任编辑:武晓燕 来源: 冰河技术
相关推荐

2020-02-03 13:30:54

钉钉企业微信移动应用

2021-05-17 08:11:44

MySQL数据库索引

2010-11-01 05:50:46

分布式文件系统

2017-10-17 08:33:31

存储系统分布式

2012-08-31 16:04:11

HDFS分布式文件系统

2013-01-07 10:29:31

大数据

2013-06-18 14:00:59

HDFS分布式文件系统

2010-11-15 13:24:07

分布式文件系统

2010-06-04 18:45:43

Hadoop分布式文件

2012-09-19 15:05:24

MogileFS分布式文件系统

2012-09-19 13:43:13

OpenAFS分布式文件系统

2012-08-10 22:44:52

ArchSummit

2021-02-03 21:15:44

Ansible系统运维系统管理员

2013-05-27 14:46:06

文件系统分布式文件系统

2012-10-09 16:43:47

FastDFS分布式文件系统

2012-05-10 15:23:53

分布式文件系统测试

2011-07-15 17:48:27

Platform

2012-05-10 14:04:07

分布式文件系统架构

2011-03-16 14:23:38

分布式文件

2020-01-03 08:33:57

Ceph硬件系统
点赞
收藏

51CTO技术栈公众号