【ceph】CRUSH算法的原理与实现|File-＞Object-＞PG-＞OSD的映射方法

理解Ceph CRUSH数据定位算法

Ceph的数据定位算法，CRUSH算法，这是一种用户可控的伪随机算法。理解此算法对掌握Ceph助益很大。

下面通过示例来分析CRUSH算法。我们部署一个Ceph集群，用一个节点做monitor，用两个节点(2×3=6块硬盘)做OSD数据服务器，OSD服务器的层次结构如下：

注一：层次结构在Ceph中称之为crushmap，描述了物理集群部署结构。crushmap是Ceph的核心数据之一，由Monitor集群负责维护。

注二：crushmap除了描述物理部署结构之外，还描述了数据存放采取的动作。比如本文示例中动作是step take default，step chooseleaf firstn 0 type host，...

CRUSH算法分两步：
第一步、输入要存储数据(称为object)的key，Ceph利用一个“字符串->数值”哈希算法计算object该放在哪个PG下。
(注：PG是Ceph的一个概念，将多个数据分组存放，PG就是这个“组”，分组的目的是减少元数据量。)

第二步、根据第一步计算得到的pgid，计算PG应该放在哪些osd硬盘上。——这是CRUSH算法的核心部分。

下面重点讲第二步，也就是CRUSH算法的核心。假设我们存入的object key="bigfile"，第一步映射到pgid=6b。

算法第二步目的是计算“bigfile”应该存放到哪两个osd硬盘上(因为设置备份数为2)，输出6b，输出应该是[x, y]，比如[5,2]，代表bigfile存放在osd.5和osd.2上，并且是放在PG 6b下面。
1、参考上面的结构图，目前在root层，目标是从下一层选择第1个Host，选取算法是straw哈希算法(可在crushmap中配置)。
2、假设选取得到Host osd1，目前在第二层，目标是从下一层中选择一个osd硬盘，选取算法默认仍是straw哈希算法。
3、假设选取得到osd.5，获得第一个位置。返回顶层继续计算。
4、继续从root层执行，此时如果straw哈希算法输出不变，仍会得到相同结果。这自然不合要求，因此straw()还有一个输入参数是当前是第几次计算。
5.1、这次root straw()可能得到Host osd0，osd0层继续straw()可能得到osd.2，于是获得第二个位置，CRUSH计算结束，返回结果。
5.2、这次root straw()可能仍得到Host osd1，此时会被拒绝，因为根据crushmap设置的规则，数据尽量分散放，都放在一个机器上，机器一挂所有数据都访问不了。因此会递增输入参数“计算次数”并重新计算。
5.2.1、后续某次继续得到Host osd0，继续计算下一层，并最终返回正确结果。
5.2.2、如果连续尝试了>choose_total_tries(在crushmap中可配，默认50)次之后，表示第二个位置的计算失败，仅返回部分结果[5,]。

- EOF -

Ceph剖析：数据分布之CRUSH算法与一致性Hash--https://www.cnblogs.com/shanno/p/3958298.html

目录

CRUSH算法的原理与实现

0. 前言

1. 背景

2. CRUSH Map

3. CRUSH Rule

选择策略

<1>: choose/chooseleaf

<2>: firstn/indep

<3>: num_reps

<4>: failure domain

4. Rule执行流程

1. 再增加一步choose

2. 使用chooseleaf

random_pick_from_list

is_available

while True

备注说明

5. Rule流程举例

5.1 正常流程

5.2 存在冲突

5.3 osd.4 out

5.4 osd.2 out

5.5 EC indep

6. CRUSH特点

Reference

Notes

3. CRUSH是如何工作的？

---

CRUSH算法的原理与实现

CRUSH算法的原理与实现 - 知乎

0. 前言

本文主要面向对Ceph及分布式系统有一定了解基础的同学；新入坑的读者可以先从Ceph文档官网获取基本信息。

1. 背景

在分布式存储系统中，数据的位置存放规则一直是研究的热门话题之一。一般来说，系统中所有角色(Clients、Servers)需要有一个统一的数据寻址算法Locator，满足：

Locator(ID) -> [Device_1, Device_2, Device_3, ...]

其中输入ID是数据的唯一标识符，输出Device列表是一系列存储设备(多设备冗余以达到多份数据保护或切分提高并发等效果)。早期的直观方案是维护一张全局的Key-Value表，任何角色操作数据时查询该表即可。显然，随着数据量的增多和集群规模的扩大，要在整个系统中维护这么一张不断扩大的表变得越来越困难。CRUSH(Controlled Replication Under Scalable Hashing)即为解决此问题而生，她仅需要一份描述集群物理架构的信息和预定义的规则(均包含在CRUSH map中)，便可实现确定数据存储位置的功能。

在Ceph的RADOS中，还引入了PG的概念用以更好地管理数据，如下图所示：

​

RADOS提供的是基于object的存储功能，每个object会先通过简单的Hash算法归到一个PG中，PGID再作为入参通过CRUSH计算置入到多个OSD中(这里object可以看作是文件，PG即是一个目录，OSD是一个数据根目录下仅有一级子目录的简易文件系统)。因此，CRUSH提供的功能可以描述为：

with CRUSHMap as context:
    CRUSH(PGID) -> [OSD_1, OSD_2, OSD_3, ...]

2. CRUSH Map

CRUSH map包含了集群正常情况下完成PG定位所需要的绝大部分信息，它可以通过以下命令获取：

$ ceph osd getcrushmap -o crushmap
$ crushtool -d crushmap -o decrushmap

直接获取到的crushmap是编码过的，需要通过crushtool转换才能变成人可读的文本文件。decrushmap一般包含以下几个部分：

1. Tunables: 可调整的参数列表(仅一部分，非完整列表)
2. Devices: 存储设备列表，列举了集群中所有的OSD
3. Types: 类型定义，一般0为OSD，其它正整数代表host、chassis、rack等
4. Buckets: 容器列表，指明了每个bucket下直接包含的children项及其权重值(非OSD的items统称为bucket)
5. Rules: 规则列表，每个规则定义了一种选取OSD的方式

这里是一个非常简单的版本，描述了如下图所示的物理架构：

​

3. CRUSH Rule

当集群系统变得复杂时，我们往往需要多种策略来存放不同类型的数据；例如，将热数据存放于SSD中，而将冷数据放在HDD中。CRUSH