mon的稳定性问题

MON的稳定性问题:

  • mon的选举风暴影响客户端IO
  • LevelDB的暴涨
  • 频繁的客户端请求的DDOS

mon选举风暴:

monmap会因为mon之间或者mon与客户端之间网络的影响或者消息传递的异常发生变化,从而触发选举
会造成客户端的请求变慢或者锁住

LevelDB的暴涨:

LevelDB的大小会涨到几十GB然后影响了osd的请求
会造成客户端的请求变慢或者锁住

频繁的客户端请求的DDOS:

mon的响应因为levelDB变慢或者选举风暴,都会造成客户端发出大量的消息流
让客户端操作失效,包括卷创建,rbd的连接

解决办法:

LevelDB的暴涨的问题解决办法

升级ceph的版本,这个在0.94.6版本解决了这个问题

leveldb.png-21.9kB

选举风暴问题解决办法

[mon]

mon_lease = 20 (default = 5)

mon_lease_renew_interval = 12 (default 3)

mon_lease_ack_timeout = 40 (default 10)

mon_accept_timeout = 40 (default 10)

[client]

mon_client_hunt_interval = 40 (defaiult 3)

将mon的数据放置在ssd上,因为LevelDB存储了集群的 metadata,包括 osdmap, pgmap, monmap,clientID, authID etc 等等,很大的leveldb会有更长的查询时间,更长的IO等待,然后就是更慢的客户端请求

这个地方是增长了mon之间判断需要切换的时间,降低客户端的请求的频率,使用ssd加快查询的速度

这个问题是一个不太容易发觉的问题,有时候就是ceph -s反应的很慢,但是很多时候可能体现的就是客户端出现请求缓慢,然后还找不到原因,所以说硬件的隔离是非常有必要的,不要为了省成本然后影响了整个环境的稳定性和性能,对于很大的环境mon需要用三台独立的机器,这个机器需要一定的内存和cpu,磁盘使用ssd,1U服务器就可以了,上面可以运行一些其他类似管理平台,或者一些监控服务什么的,混合在osd的机器上的时候,一旦OSD出现大量的数据迁移的时候,或者大量的请求的时候,会阻塞了消息,这个就是做方案的时候需要考虑的问题,当然在性能要求不那么高的时候将mon混合在osd上使用也是可以的,这个时候尽量有更多的内存和更好的磁盘性能也能减少一些负担