一次磁盘空间不足引发的思考
2018年7月23周一晚上8点多，我的直接Leader给我打电话联系，向我咨询了上周四（7月19日）生产服务器磁盘不足导致的几个重要URl访问缓慢甚至无法访问的情况，我当时寻思故障发生的主要原因就是该服务器磁盘空间不足导致，因为当时接到服务器磁盘不足10%的预警邮件，但未能及时进行处理，屋漏偏逢连夜雨，该服务器有一些程序应该是有突然会消耗磁盘空间的隐患，偏偏也发生在那个时刻，最直接的结果就是生产服务器歇菜34分钟左右。下面将事后的故障分析原因抛出来供大家参考：
问题发现
发现时间：【2018-7-19 11:12】
-
发现方式：
- [ ] 用户发现
- [ ] 技术人员发现
- [✔] 告警发现
-
告警方式：
- [ ] 电话告警
- [ ] 邮件告警
- [✔] 短信告警
- [ ] 未收到告警
问题描述：
通过360网站监控服务收到异常通知：http://XXXXXXXXXX.com/index 连接被拒绝，与此同时团队人员接收到生产服务器磁盘空间不足10%的邮件预警后开始排查问题原因。
产生影响
- 故障开始时间：【2018-7-19 11:54】
故障解决时间：【2018-7-19 12:30】
-
是否影响用户：
- [ ] 用户无感知
- [✔] 用户感知
-
影响描述：【着重描述是否影响客户体验，影响时长、程度】
在该生产服务器重启期间，导致相关服务报告中心无法正常加载以致于用户无法正常登陆，在产品交流群中有一名用户反馈无法加载界面，但在预警邮件中未接收到有关用户反馈无法使用的错误邮件信息，因此可判断为小范围影响，影响时长总计34分钟，影响程度低。
问题原因
- 原因一
从以上两图来看zabbix监控上发现10点的时候磁盘空间已剩9.28%，在11：10分接到inode节点空间不足的报警的时候，即从10点到11：10分的时候磁盘空间只剩下0.31%，从下面的折线图可以明显看到从10点到11点有某种原因(由于相关日志缺失，目前还未找到具体原因)突然占用掉磁盘空间： - 原因二
该服务器磁盘总空间大小为200G，实际可用空间为/dev/sda3(136G)，当启用多个docker容器并且利用的是devicemapper存储方式会预先占用磁盘10G空间大小，因此不排除是由于服务器本身磁盘空间太小不足以支撑生产业务需求的原因
核心技术原因
如上图所示，在此服务器上启用的docker容器采用devicemapper方式，此方式会预先占用服务器磁盘空间107G，但容器本身实际占用的空间并未达到107G，所以导致下图结果： 即逻辑上所有文件占用磁盘总容量未达到系统统计的已用磁盘容量，但实际上是docker容器预先占用了磁盘空间
解决方案
目前解决方案是在该服务器上额外增加一块容量为500G的磁盘，将docker容器数据文件挂载到新的磁盘上，以保证生产正常进行，如果要从技术上来改变docker容器存储方式，还做技术上的拓展，如果其他产品利用到docker技术，可以注意docker容器的存储方式，去做一个更加适合自身业务的容器。