ceph的CRUSH算法

Ceph中关于副本位置的选择，采用的算法是CRUSH。核心思想是根据（object的ID，deviceID or number,deviceweight,replica number，伪随机参数）计算出副本的位置。

Ceph采用的CRUSH算法的实现，跟openstack swift等采用一致性一致性hash有着明显的区别。先说相同之处，目的都是类似，都是为了保证副本分布的均匀，设备空间利用率的均匀，利用objectID做hash等。主要不同之处：

CRUSH更为详细的考虑了存储设备的物理结构（cluster map），例如机架位置，节点位置，包括磁盘位置等（Swift是不考虑磁盘位置的）。CRUSH中先考虑空间结构，然后在根据hash选位置；swift反过来，先直接hash得到虚拟节点，然后虚拟节点跟物理节点映射的时候考虑了空间拓扑。CRUSH可以根据不同的对象、不同的物理结构定义不同的副本位置规则，而swift中的一致性hash会麻烦。此外swift计算虚拟节点的时候并没考虑副本的编号，而CRUSH会考虑的，swift的一致性hash在处理同一个object的不同副本位置时候考虑不是那么的。

       理论上讲，CRUSH算法数据分布分布应该散列程度应该高于swift基于虚节点的方法。可以这样理解：

      从单个副本的粒度，无路是crush还是swift，其mirror replica都是分散在系统内其他节点的。

     从多个副本的粒度，例如swif虚节点上看，某个虚节点上的mirro replica虽然也散列到了其他的节点，但是如果对于固定的虚节点来说，其镜像是固定在某些节点上，而cehp在不存在这种问题。对于swift的虚节点来说，最好不要将虚节点跟某个物理节点上的物理卷或者磁盘绑定。

       从一个节点粒度看，swift中单个节点的对其他节点（即存在本节点object copy的节点）的依赖相对少一些，因为不同的虚节点依赖的物理节点不同。当然swift这种做法，可能会出现两个不同的物理节点，存在多个虚拟节点互为mirror关系。

几个不太清楚的问题：

1．如果出现了设备异常，CRUSH会重新计算一个替代的位置。问题是，在分布式系统中，两个不同的客户端去计算这个副本的问题，第一个客户端计算的时候认为设备正常，第二个客户端计算时认为设备异常，需要重新计算，那么二者的计算结果就会不同。

2．设备异常时会把副本写到一个新的位置，如果这个设备恢复了，后面需要把副本从新位置迁移回到原本应该在的位置？

3．每个客户端必须看到一致的cluster map，这个map中包含了节点和设备的状态，而ceph是去中心化的，这个cluster map可能是由一个类似zookeeper的组件来维护的。

 

Crush算法中文介绍可以参考：http://way4ever.com/?p=122

算法思想看一遍weil的论文和上面这篇材料应该足够。