系统设计 | Ceph 数据分布算法crush

目标

• crush算法是为了解决分布式存储领域中的数据分布问题，简言之就是数据如何分布在各个节点和磁盘上。
• 针对ceph而言，这里的数据就是PG副本，节点/磁盘对应的是OSD进程事例。

难点

数据分布有啥难点呢？

• 均匀性：如何保证数据均匀分布？读写负载均匀？
• 集群伸缩：增加或者删除节点，迁移的数据尽量少。
• 适合大规模场景：集群规模大了，元信息就多了，这种场景下的性能问题必须考虑：如何保证元信息少？快速计算元信息？

集中式元信息 VS 分布式元信息存储

• 无论是P2P场景还是分布式存储场景，元信息都有这两种方式，对比如下

	集中式	分布式
优点	读写性能好，网络开销低	可用性高，无单点
	集群伸缩时，收敛快速	元数据服务器读写负载均匀，无性能瓶颈
	易调试，方便运营和运维	理论可以无限扩展
缺点	单点问题	读写性能差，网络开销大
	元信息服务器负载高，存在瓶颈	异常情况，可能引起广播风暴
	扩展性存在限制	运维困难

核心思想

1. 映射关系(pg -> osd(x,y,z))

CRUSH(pg_id，cluster state，rule set) --> (OSDi, OSDj, OSDk)

输入参数

• pg_id
• cluster Map: 静态的ceph集群拓扑结构，树状结构，这棵树的叶子节点是device（osd），其他节点都是bucket（OSD的容器）；
• placement rules: 自定义策略（不同rack/1SSD + 2HDD）
  

2. bucket算法

• 采用伪随机的方式从bucket中选取一个item，就是有可能不是绝对的均衡。
• hash(pg_id, replicate_id, bucket_id)

1. uniform bucket
2. list bucket
3. tree bucket
4. straw bucket: 默认算法，增加和删除是性能都较好，迁移数据较少

3. 冲突，失效和过载

会重新选择osd

4. 数据迁移

遗留问题

1. crushMap的何时更新？客户端是否存在crushMap一致性问题