ceph学习之CRUSH

CRUSH的全称是Controlled Replication Under Scalable Hashing，是ceph数据存储的分布式选择算法，也是ceph存储引擎的核心。在之前的博客里介绍过，ceph的客户端在往集群里读写数据时，动态计算数据的存储位置。这样ceph就无需维护一个叫metadata的东西，从而提高性能。

ceph分布式存储有关键的3R: Replication（数据复制）、Recovery（数据恢复）、Rebalancing（数据均衡）。在组件故障时，ceph默认等待300秒，然后将OSD标记为down和out，并且初始化recovery操作。这个等待时间可以在集群配置文件的mon_osd_down_out_interval参数里设置。在recovery过程中，ceph会重新产生受故障影响的数据。

 

因为CRUSH会复制数据到不同的磁盘，这些数据副本在recovery时就变得有用。在恢复过程中，CRUSH会尽量移动最小数量的数据，并且产生一个新的集群布局，从而使集群从故障中恢复。

当新的主机或磁盘加入到集群时，CRUSH开始rebalancing操作，它将数据从存在的主机、磁盘迁移到新的主机、磁盘。rebalancing时会尽量利用所有磁盘，以提高集群性能。例如，某个ceph集群包含2000个OSD，现在新加入20个OSD，这样仅1%的数据将被迁移。在迁移中所有存在的磁盘会并行工作，使得迁移工作尽快完成。当然，如果ceph集群在重度使用中，推荐做法是新加入的磁盘设置权重0，并且逐步提高权重，使得数据迁移缓慢发生，以免影响性能。所有的分布式存储在扩容时都建议这样操作，比如我之前写的swift容量管理文章。

在实际中可能经常需要调整集群的布局。默认的CRUSH布局很简单，执行ceph osd tree命令，会看到仅有host和OSD这两种bucket类型在root下面。默认的布局对分区容错很不利，没有rack、row、room这些概念。下面我们增加一种bucket类型：rack（机架）。所有的host（主机）都应位于rack下面。

注：如下文字及图片，都来自《learning ceph》这本书。建议读者有时间详读原著。

（1）执行ceph osd tree得到当前的集群布局：

osdtree

（2）增加rack：

1
2
3
$ ceph osd crush add-bucket rack01 rack
$ ceph osd crush add-bucket rack02 rack
$ ceph osd crush add-bucket rack02 rack

（3）将host移动到rack下面：

1
2
3
$ ceph osd crush move ceph-node1 rack=rack01
$ ceph osd crush move ceph-node2 rack=rack02
$ ceph osd crush move ceph-node3 rack=rack03

（4）将rack移动到默认的root下面：

1
2
3
$ ceph osd crush move rack03 root=default
$ ceph osd crush move rack02 root=default
$ ceph osd crush move rack01 root=default

（5）再次运行ceph osd tree命令，会看到新的布局已产生，所有host都位于特定rack下面。按此操作，就完成了对CRUSH布局的调整。

osdtree2

 

对一个已知对象，可以根据CRUSH算法，查找它的存储结构。比如data这个pool里有一个文件resolv.conf：

1
2
$ rados -p data ls
resolv.conf

显示它的存储结构：

1
2
$ ceph osd map data resolv.conf
osdmap e43 pool 'data' (0) object 'resolv.conf' -> pg 0.9f1f5993 (0.13) -> up ([1,2,0], p1) acting ([1,2,0], p1)

输出结果说明：

  • osdmap e43: 这是osdmap的epoll版本
  • pool ‘data’: 这是pool名字
  • object ‘resolv.conf’: 这是对象名字
  • pg 0.9f1f5993 (0.13): 这是PG号
  • up ([1,2,0], p1): 存储该PG的3个OSD都是活跃的，这是一个有序数组，第一个是primary OSD
  • acting ([1,2,0], p1): 说明该PG存储在哪3个OSD里，同上也是有序数组

ceph osd map命令只是自己计算一遍CRUSH，它并不确认目标pool里是否真有这个对象，所以随便输入什么文件名，它总是返回成功。

 

关于对象在ceph里的存储，遵循如下示意图：

pgstru

首先要存储的大数据（比如rbd设备），被打散成一系列小对象，每个对象会计算出它对应的PG号。取决于replication size的不同，每个PG会分布到多个OSD上。PG的全称是placement groups，它是一个逻辑存储单位，存在的目的是为了更好的管理和定位数以亿计的存储对象。

如何根据对象计算出PG号，以及PG号如何分布到具体的OSD上，这个就是CRUSH算法，如下示意图：

crushmap

首先，根据对象名和pool里配置的PG数量（这些都已知），运用哈希函数计算出PG号。接下来根据PG号、集群状态、存储规则，运行CRUSH算法，找出具体负责存储的首要和次要OSD。最后客户端从这些OSD上对存储对象进行数据读和写。

在安装ceph的文档里，也提到了如何查看、编辑和更新crushmap。crushmap与ceph的存储架构有关，在实际中可能需要经常调整它。如下先把它dump出来，再反编译成明文进行查看。

1
2
3
$ ceph osd getcrushmap -o crushmap.original
got crush map from osdmap epoch 56
$ crushtool -d crushmap.original -o crushmap

 

然后查看这个文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
ceph@ceph:~$ cat crushmap
# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable straw_calc_version 1
 
# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
 
# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root
 
# buckets
host ceph2 {
id -2 # do not change unnecessarily
# weight 0.240
alg straw
hash 0 # rjenkins1
item osd.0 weight 0.080
item osd.1 weight 0.080
item osd.2 weight 0.080
}
root default {
id -1 # do not change unnecessarily
# weight 0.240
alg straw
hash 0 # rjenkins1
item ceph2 weight 0.240
}
 
# rules
rule replicated_ruleset {
ruleset 0
type replicated
min_size 1
max_size 10
step take default
step chooseleaf firstn 0 type osd
step emit
}
 
# end crush map

这个文件包括几节，大概说明下：

  • crushmap设备：见上述文件#device后面的内容。这里列举ceph的OSD列表。不管新增还是删除OSD，这个列表会自动更新。通常你无需更改此处，ceph会自动维护。
  • crushmap bucket类型：见上述文件#types后面的内容。定义bucket的类型，包括root、datacenter、room、row、rack、host、osd等。默认的bucket类型对大部分ceph集群来说够用了，不过你也可以增加自己的类型。
  • crushmap bucket定义：见上述文件#buckets后面的内容。这里定义bucket的层次性架构，也可以定义bucket所使用的算法类型。
  • crushmap规则：见上述文件#rules后面的内容。它定义pool里存储的数据应该选择哪个相应的bucket。对较大的集群来说，有多个pool，每个pool有它自己的选择规则。

crushmap的bucket是按层次性分布的，见如下示意图：

crushlevel

crushmap应用的实际场景，举个例子，我们可以定义一个pool名字为SSD，它使用SSD磁盘来提高性能。再定义一个pool名字为SATA，它使用SATA磁盘来获取更好的经济性。不过我手头并没有这样的测试环境，如下配置并非针对我的测试环境进行。假设有3个ceph存储node，每个node上都有独立的osd服务。

首先在crushmap文件里增加如下节：

crushssd

上述增加2个root bucket，注意id不要冲突。item后面是ceph的node列表，我们假设node1运行SSD硬盘，node2、node3运行SATA硬盘。

再增加2条规则：

crushrule

  • ruleset 3这个规则里，step take sata表示优先选择sata的bucket
  • ruleset 4这个规则里，step take ssd表示优先选择ssd的bucket

修改完后，重新编译crushmap并且加载到集群中使之生效。

1
2
3
$ crushtool -c crushmap -o crushmap.new
$ ceph osd setcrushmap -i crushmap.new
set crush map

接下来观察ceph -s是否健康状态OK。如果健康OK，增加2个pool:

1
2
3
$ ceph osd pool create sata 64 64
 
$ ceph osd pool create ssd 64 64

给上述2个新创建的pool分配crush规则：

1
2
3
$ ceph osd pool set sata crush_ruleset 3
 
$ ceph osd pool set ssd crush_ruleset 4

查看规则是否生效：

1
$ ceph osd dump |egrep -i "ssd|sata"

现在写往sata pool的目标，将优先存储到SATA设备上。写往ssd pool的目标，将优先存储到SSD设备上。可以用rados命令进行测试：

1
2
3
$ rados -p ssd put filename file.ssd
 
$ rados -p sata put filename file.sata

最后使用ceph osd map命令检查它们的存储位置：

1
2
3
$ ceph osd map ssd file.ssd
 
$ ceph osd map sata file.sata

 

 

本文转自：http://blog.dnsbed.com/archives/1714

posted @ 2017-05-19 16:15  netmouser  阅读(1414)  评论(0)  编辑  收藏  举报