###背景随着ceph集群不断的变大和复杂，可能会遇到，整个容量很大，但是真正的数据使用率很低的情况。比如明明有100多TB的空间，但是数据才存了20TB,就发生了osd full的问题。磁盘使用率极
###背景随着ceph集群不断的变大和复杂，可能会遇到，整个容量很大，但是真正的数据使用率很低的情况。比如明明有100多TB的空间，但是数据才存了20TB,就发生了osd full的问题。磁盘使用率极为不平衡。这就需要人工干预了，其中有一些技巧和规范，我自己总结一下，希望对大家有用，另外下面都是我自己的理解，可能表述和理解是有问题，仅供参考，我尽可能用我实际操作的结果来证明我的理解。####机型的选择和crush map的划分
- 尽量选择同一类型的机器，不同的类型最好要弄不同的分组，如果不这么干，计算起来很麻烦，包括后面程序分析出来的结果也会不准。
- crush map特别要注意rule,如果rule里有两个不同的地域存储规则，那么采用这个规则的pool的最大可用size将由最小的地域size规定。所以，如果你有异地存储或者不同分组存储的时候，尽量像天平一样，保证两边平衡，这样才能最大限度的展现出存储能力。
####容量的显示和理解
- 容量的显示
ceph dfrados df但是要正确理解这些命令的输出，比如ceph df的输出global里的tatol size，他是指所有在线osd的存储容量总大小。你所在的pool最大可用要看对应的输出，他的计算一般是非常准确的，不过可能会让人感到很困惑，那是因为你对pool size的理解还不到位所致，但是记住，ceph df 中max available是非常准确的，它显示1T，你绝对存不了1025GB,你这里显示的比你预期的小，你得多找找原因。
- 就我目前的理解，对容量的影响大致为：副本数 osd磁盘最大使用率 crush-map crush-rule max-target-bytes max-size pg-num pool-snap rbd-snap ceph-fs-gc
####一些影响因素解释
- 快照snap本身就需要存储的，可别那这部分漏掉了，这不是日志存储系统。快照有pool的快照，不过我不知道这个怎么查看，可能是ceph osd pool ls detail查看吧，还有一个是rbd的快照，这个可以rbd snap list image来看，不过rbd只能这样一个一个来看
- 存储池的副本数副本数为2，存储就打折一半，这个也没什么好解释的，冗余的一部分肯定是要计算空间的。
- pg num的分布pg num的分布在创建存储池的时候要提前规划好，前期玩宁可设置小点，也不要太大，因为存储池的pg_num只能增大，不能减小。最好用pgcalc在线工具规划好再下手。
