Openstack使用ceph要注意几个问题

据社区统计，现在Openstack落地项目使用ceph分布式存储的比例已经超过一半，也就是说Openstack使用的后台存储大部分都是ceph，为什么大家都使用ceph作为后端存储，是因为ceph作为Openstack的存储是有优势的，这里不展开讲，我觉得一个大优势是ceph几乎整合了所有的存储需求，可以给Openstack的glance、nova、cinder等组件提供统一的存储解决方案。但是在具体使用过程当中，有一些问题需要注意。

1、ceph的核心组件monitor 和 osd 需要重点考虑。monitor容忍同时发生故障的节点数是这样的：

ceph的mon能够正常情况需要保证当前剩余的mon的个数需要大于总mon个数的一半，所以，一般来说mon节点数都是奇数个，比如1,3,5,7.... ，并且，要注意，在运行过程中，要保证过半数量的mon节点运行正常，比如你有3个mon节点，那么，只能允许你有1个mon发生故障，这和你的数据副本有几份没有关系。当超过1半的mon节点发生故障，你的整个ceph存储集群将不能写入数据，这一点需要注意。

2、在动态调整OSD磁盘的时候，需要注意crush策略，默认情况下，如果使用kolla进行自动部署，osd的crush分布策略中的权重都是一样的，如果OSD磁盘容量大小不一致，那么就需要手动去调整这个weight权重，具体调整方法这里不具体描述。

3、ceph存储集群作为一个整体的系统，虽然本身有容错机制，比如多个mon，每个pool可以设置多个数据副本，但是也不能排除整个ceph集群发生不可恢复故障的可能性，比如多个服务器的物理损坏或者是不可恢复的多mon节点故障或者误操作等等。因此，考虑另外单独建立一套备份的ceph存储集群是必要的，备份的ceph集群我个人认为pool的数据副本可以是1最多2，mon节点可以单节点或3节点。

4、虽然ceph存储集群有容灾特性，但是对于服务器的重启和关闭也要持谨慎态度，因为ceph是动态分布存储，mon节点会实时监控osd的健康状态，如果发现osd不可用，他会根据相应的crush里的weight权重将故障osd上的数据副本重新分布到其他正常osd上面，以保证规定的数据副本，这样的数据动态平衡会占用整个集群的网络CPU内存资源，所以任何有计划的物理设备调整都要事先准备好相应的方案，比如计划内关闭物理设备，可以关闭ceph集群的数据重平衡：

5、对于系统正常稳定运行，预防非常重要，对于整个ceph存储集群，需要搭建监控系统实时监控，这样，可以及时发现单个偶发的故障，做到防微杜渐，不至于小问题积累，最后导致影响全局性的故障。具体的监控方法和工具这里不展开描述。

后面如果有机会，我会对ceph集群的备份和ceph的监控展开描述。