Ceph在高IO下的死锁故障

原创
2015/07/01 10:16
阅读数 5.4K

在一台高性能PC服务器上,使用ceph做虚拟机镜像的存储。在做压力测试的情况下,出现了该服务器所有虚拟机不能访问的故障。

引发原因:

1.在虚拟机当中安装了一个网站服务,网站服务中使用了redis作为缓存服务器。在压力比较大的情况下(8000千次访问每秒),发生了宿主机所有的虚拟机全部不能访问的情况

2.发生故障时,部分虚拟机不能ping到,部分虚拟机是能ping到,但是不能ssh登陆


开始以为是网桥故障,KVM的virtio的网卡故障非常著名,在使用网桥的情况下,会出现内存溢出。导致网桥失效。 Xen给的解决方案是关闭网桥的tso 支持。

(运行命令ethtool --offload <network device>  tso off )

但是重启网络服务后,该故障没有消失。

因此排除网桥故障。


多次重现故障之后,有一个虚拟机的ssh没有断掉,所以还能执行cd命令,但是ls命令无法执行,报告input/output error,此错误为文件系统故障的表现。

所以开始怀疑文件系统出现问题 。

此文件系统为ceph,查看ceph日志,发现在发生故障的同时,ceph报大量一下的故障日志:

2015-06-30 16:36:28.493424 osd.0 172.23123123:6800/96711 9195 : cluster [WRN] 6 slow requests, 6 included below;
oldest blocked for > 30.934796 secs

还有

2015-06-26 18:46:45.192215 osd.2 172.132131231:6800/68644 5936 : cluster [WRN] slow request 240.415451 seconds old
, received at 2015-06-26 18:42:44.776646: osd_op(13213213500 [
stat,set-alloc-hint object_size 4194304 write_size 4194304,write 2269184~524288] 0.5652b278 ack+ondisk+write+kno
wn_if_redirected e48545) currently waiting for rw locks

明显出现了死锁。

查看磁盘IO记录,发现redis服务器,在故障发生时又大量的磁盘写入操作,发现在高操作频率的情况下,会比较频繁的触发rbd的持久化,因此引起了大量磁盘io,这些磁盘IO导致了其他磁盘操作得不到足够的写入时间,引起了ceph对osd的死锁。

解决方案是关闭了redis的rbd持久化,该问题不再出现。

长久的解决办法是不让redis持久化直接往ceph上的分区上写入。还有就是不要再ceph上的虚拟机镜像进行高IO的写入或者读取(好不靠谱。。。)

经验总结:

1.Ceph在高IO下存在死锁的风险,Ceph没有提供解锁机制,官方的解决方案是不要在ceph上放虚拟机镜像。。。无语。。

(链接地址:http://ceph.com/docs/master/rados/troubleshooting/troubleshooting-osd/

2.在系统设计的时候,应该将存储网络和业务网络隔离和分开。一个系统服务,应该分为,外网,业务网,存储网,心跳网,管理网,五种网络组建形式。




展开阅读全文
打赏
1
44 收藏
分享
加载中

引用来自“Brin想写程序”的评论

Possible solutions

Remove VMs Cloud Solutions from Ceph Hosts

引用来自“LinuxWind”的评论

表示楼主没有好好看清楚官方文档,联系一下上下文。 整体来说,楼主给这个问题下的定义有问题。
问题是什么呢? 现在只要在虚拟机里面dd一个5G文件都能让ceph中的虚拟机死锁。
2015/07/15 09:58
回复
举报

引用来自“Brin想写程序”的评论

Possible solutions

Remove VMs Cloud Solutions from Ceph Hosts

引用来自“LinuxWind”的评论

表示楼主没有好好看清楚官方文档,联系一下上下文。 整体来说,楼主给这个问题下的定义有问题。
机器down了。 查看文档了一遍又一遍,没有解决方案. Remove VMs Cloud Solutions from Ceph Hosts 你觉得应该怎么解释呢? 我觉得与其继续看官方文档,不如去看源代码,看看这个问题到底出在哪里。
2015/07/15 09:53
回复
举报

引用来自“Brin想写程序”的评论

Possible solutions

Remove VMs Cloud Solutions from Ceph Hosts
表示楼主没有好好看清楚官方文档,联系一下上下文。 整体来说,楼主给这个问题下的定义有问题。
2015/07/15 09:41
回复
举报

引用来自“江鸟”的评论

引用来自“Brin想写程序”的评论

引用来自“cxzjsy”的评论

从ceph的日志看不出有任何的bug,只能说明ceph现在处理的比较慢
会报出一个rw lock错误和大量的slow reques错误。 在osd个数少于5个的时候,经常可以触发。 但是增大osd个数,其实也会死掉,不过好处是可能只死掉一个虚拟机。 如果osd个数少,死掉的虚拟机非常多。

五个osd太少了 验证功能还好 跑生产不合适

引用来自“Brin想写程序”的评论

我们改成了12个osd一样还是出现这个问题

引用来自“江鸟”的评论

你的虚机重启了吗?
只有重启,才能恢复。。所以每次都要重启
2015/07/10 13:54
回复
举报

引用来自“江鸟”的评论

引用来自“Brin想写程序”的评论

引用来自“cxzjsy”的评论

从ceph的日志看不出有任何的bug,只能说明ceph现在处理的比较慢
会报出一个rw lock错误和大量的slow reques错误。 在osd个数少于5个的时候,经常可以触发。 但是增大osd个数,其实也会死掉,不过好处是可能只死掉一个虚拟机。 如果osd个数少,死掉的虚拟机非常多。

五个osd太少了 验证功能还好 跑生产不合适

引用来自“Brin想写程序”的评论

我们改成了12个osd一样还是出现这个问题
你的虚机重启了吗?
2015/07/10 11:45
回复
举报

引用来自“江鸟”的评论

引用来自“Brin想写程序”的评论

引用来自“cxzjsy”的评论

从ceph的日志看不出有任何的bug,只能说明ceph现在处理的比较慢
会报出一个rw lock错误和大量的slow reques错误。 在osd个数少于5个的时候,经常可以触发。 但是增大osd个数,其实也会死掉,不过好处是可能只死掉一个虚拟机。 如果osd个数少,死掉的虚拟机非常多。

五个osd太少了 验证功能还好 跑生产不合适
我们改成了12个osd一样还是出现这个问题
2015/07/08 17:20
回复
举报

引用来自“江鸟”的评论

我们最初遇到这样问题是osd比较少时候(不到20) 如果有osd out了 rebalance就会出现slow request,通过调整osd同步策略解决了。另外如果虚机一直运行 内部会积压大量的写请求,导致一直很慢,只有重启虚机来释放写请求。如果一直不重启,就会持续积压,甚至恶化,就像上边提到的24小时也不恢复。
我们这边测试的现象是如果osd比较少的情况下,会出现所有虚拟机挂掉的情况,但是如果osd比较多,其实也会出现虚拟机死锁,但是好一点的在于不是所有虚拟机都挂。
2015/07/08 17:20
回复
举报

引用来自“Brin想写程序”的评论

引用来自“cxzjsy”的评论

从ceph的日志看不出有任何的bug,只能说明ceph现在处理的比较慢
会报出一个rw lock错误和大量的slow reques错误。 在osd个数少于5个的时候,经常可以触发。 但是增大osd个数,其实也会死掉,不过好处是可能只死掉一个虚拟机。 如果osd个数少,死掉的虚拟机非常多。

五个osd太少了 验证功能还好 跑生产不合适
2015/07/08 00:12
回复
举报
我们最初遇到这样问题是osd比较少时候(不到20) 如果有osd out了 rebalance就会出现slow request,通过调整osd同步策略解决了。另外如果虚机一直运行 内部会积压大量的写请求,导致一直很慢,只有重启虚机来释放写请求。如果一直不重启,就会持续积压,甚至恶化,就像上边提到的24小时也不恢复。
2015/07/08 00:02
回复
举报

引用来自“罗兴峰”的评论

这样的ceph就没法用了哦
别的集群存储方案用什么呢
不知道啊..我们是必须用ceph,所以采取的方案就是只用ceph做虚拟机的根,虚拟机里面不跑大IO的应用,如果出现大IO的场景,就用本地磁盘,让虚拟机挂.
2015/07/07 21:01
回复
举报
更多评论
打赏
31 评论
44 收藏
1
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部