这是Ceph开发每周谈的第七十四篇文章,记录从17年5月08号到17年5月14号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落,想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼,但对于社区的方向和实况仍有所脱节,笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新,围绕几个热点进行深度解析,如果正好有产业届新闻的话就进行解读,最后有读者反馈问题的话并且值得一聊的话,就附上答疑部分。
-
一句话消息
Cephalocon 2017 宣布由于美国政策、峰会规模和赞助商问题取消。
-
CRUSH 不均衡问题
Loic 长期在 CRUSH 模块工作,最近在解决一个 Ceph 中经常碰到的问题,怎么解决少量 PG 情况下的数据均衡问题,通常会导致最高 25% 的不均衡度。比如说,当两个 OSD 使用了相同权重,然后随机分布 4 个 PG,可能会使得一个 OSD 有 3 个,另外一个只有一个,这个问题可以通过给每个 OSD 配备上千个 PG 解决,但是这会导致大量的 PG 相关资源消耗。另外一个原因是条件概率,对于双副本池来说,PG 映射给 OSD 一定是不通的,第二个 OSD 的选择是随机的,因此会跟第一个 OSD 不通,当所有 OSD 有相同概率时,这个情况不显著,但是当 OSD 不通的权重时,这个情况会变得明显。
通常来说,修改存储池的副本数量是比较常见的运维操作:
- pool size
- numeric id
- number of PGs
- root of the CRUSH rule (take step)
- the CRUSH rule itself
for size in [1,pool size] copy all weights to the size - 1 weight set recursively walk the root for each bucket at a given level in the hierarchy repeat until the difference with the expected distribution is small map all PGs in the pool, with size instead of pool size in the size - 1 weight set lower the weight of the most overfilled child increase the weight of the most underfilled child
当一个 bucket 被精确给予期望的 PG 并且没能均衡分布 PG 时,子节点的权重会被修改来匹配最理想的分布,增加和减少权重可以从其他 Item 那得到或者推送 PG,由于目前没有一个很好的数据公式来计算,所以仍然需要模拟权重来进行。