MON的稳定性问题：

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

mon选举风暴：

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

会造成客户端的请求变慢或者锁住

LevelDB的暴涨：

LevelDB的大小会涨到几十GB然后影响了osd的请求

会造成客户端的请求变慢或者锁住

频繁的客户端请求的DDOS：

mon的响应因为levelDB变慢或者选举风暴，都会造成客户端发出大量的消息流

让客户端操作失效，包括卷创建，rbd的连接

解决办法：

LevelDB的暴涨的问题解决办法

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

选举风暴问题解决办法

[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上使用也是可以的，这个时候尽量有更多的内存和更好的磁盘性能也能减少一些负担