如何在单节点 Ceph 中配置多数据副本

简介: crush.png在服务器资源不足,或者测试环境下,Ceph 通常只有一个节点,就算有多个服务器组成集群,往往存储服务器也往往只有一台,Ceph 的默认配置下,只能设置单数据备份,也就是说数据只存了一份,如果磁盘坏了,数据就丢了。
img_031b635aef5e4469f7a893b593a06fd7.png
crush.png

在服务器资源不足,或者测试环境下,Ceph 通常只有一个节点,就算有多个服务器组成集群,往往存储服务器也往往只有一台,Ceph 的默认配置下,只能设置单数据备份,也就是说数据只存了一份,如果磁盘坏了,数据就丢了。虽然测试环境数据没那么重要,总保不齐就会有关键数据放在上面,所以还是要想办法在资源有限的条件下实现数据的高可用,另外这也是一个很好的进一步理解 Ceph 概念的好机会,接下来就让我们来看看是如何实现的吧。

1. CRUSH map 规则介绍

为了把这件事说清楚,我们需要了解 CRUSH map 一些具体规则,所以先来看一下默认的 CRUSH map。

$ cat crush-map-decompiled
...
# buckets
host rbd-osd1 {
    id -3       # do not change unnecessarily
    id -4 class hdd     # do not change unnecessarily
    # weight 130.992
    alg straw2
    hash 0  # rjenkins1
    item osd.0 weight 5.458
    item osd.1 weight 5.458
    item osd.2 weight 5.458
    item osd.3 weight 5.458
    item osd.4 weight 5.458
    item osd.5 weight 5.458
    item osd.6 weight 5.458
    item osd.7 weight 5.458
    item osd.8 weight 5.458
    item osd.9 weight 5.458
    item osd.10 weight 5.458
    item osd.11 weight 5.458
    item osd.12 weight 5.458
    item osd.13 weight 5.458
    item osd.14 weight 5.458
    item osd.15 weight 5.458
    item osd.16 weight 5.458
    item osd.17 weight 5.458
    item osd.18 weight 5.458
    item osd.19 weight 5.458
    item osd.20 weight 5.458
    item osd.21 weight 5.458
    item osd.22 weight 5.458
    item osd.23 weight 5.458
}
root default {
    id -1       # do not change unnecessarily
    id -2 class hdd     # do not change unnecessarily
    # weight 130.992
    alg straw2
    hash 0  # rjenkins1
    item rbd-osd1 weight 130.992
}

# rules
rule replicated_rule {
    id 0
    type replicated
    min_size 1
    max_size 10
    step take default
    step chooseleaf firstn 0 type host
    step emit
}

我们可以看到,Ceph 集群中只有一台存储服务器:rbd-osd1,上面有 24 块硬盘。
要实现单存储上多备份,关键就在这行配置上:step chooseleaf firstn 0 type host
这句话的意思是,从选定的 bucket(也就是 host rbd-osd1)中,获取默认个(也就是 osd_pool_default_size 个,这是在 /etc/ceph/ceph.conf 中配置的)叶子节点(也就是 rbd-osd1 中包含的那 24 个 item),叶子节点的类型为 host。
默认配置出问题的地方就是在叶子节点的类型上,osd_pool_default_size 默认值是三,也就是说,需要找三个 host 类型的 bucket,host 对应的就是存储服务器,我们现在只有一个,当然不满足需求了。从 ceph 的状态上也能看出来,所有的 OSD 都因为 OSD 数量不足,处于 active+undersized 状态。

$ ceph -s
...
  data:
    pools:   1 pools, 64 pgs
    objects: 0 objects, 0 bytes
    usage:   25001 MB used, 130 TB / 130 TB avail
    pgs:     64 active+undersized

2. 修改 CRUSH map

了解到问题所在,接下来就动手修改吧,CRUSH map 支持两种修改方式,一种是命令行,优点是单条命令很简单,缺点是不够直观;第二种是手动修改配置文件,优点是所见即所得,缺点是麻烦一点,需要先导出,解码,修改,最后再编码,导入。这里因为修改的内容颇为具体,所以采用第二种方法。

先将 CRUSH map 导出到文件 crush-map 中。

$ ceph osd getcrushmap -o crush-map

然后解码,并输出到文件 crush-map-decompiled 中。

$ crushtool -d crush-map -o crush-map-decompiled

修改 crush-map-decompiled,将 type 改为 osd,即可

$ cat crush-map-decompiled
...
# rules
rule replicated_rule {
    id 0
    type replicated
    min_size 1
    max_size 10
    step take default
    step chooseleaf firstn 0 type osd
    step emit
}

将改好的文件编码到文件 crush-map 中。

$ crushtool -c crush-map-decompiled -o crush-map

最后导入。

$ ceph osd setcrushmap -o crush-map

3. 修改 /etc/ceph/ceph.conf

不过事情没有那么简单,还需要配合 ceph.conf 的修改才行,我们要修改 osd_crush_chooseleaf_type
这个参数每个取值的意义在 Ceph 的官方文档中,有明确的说明,0 是给单节点的 ceph 集群使用的,而 1 是默认值,所以我们需要修改。

#Choose a reasonable crush leaf type.
#0 for a 1-node cluster.
#1 for a multi node cluster in a single rack
#2 for a multi node, multi chassis cluster with multiple hosts in a chassis
#3 for a multi node cluster with hosts across racks, etc.
osd crush chooseleaf type = {n}

集群是使用 ceph-deploy 来部署的,所以需要修改 ceph-deploy 目录下的文件,然后推送到 ceph 集群中的服务器中:

$ cat ceph.conf
...
osd_crush_chooseleaf_type = 0
...

$ ceph-deploy --overwrite-conf config push rbd-master1 rbd-osd1

4. 动态修改 ceph 配置

至此问题还是没有完全解决,原因是配置文件的变动需要,进程的重启才能生效,不重启有没有办法让改动生效呢?有的,需要使用的 ceph daemon 命令。

sudo ceph daemon mon.rbd-master1 config set osd_pool_default_size 0

5. 参考文档

目录
相关文章
|
11月前
|
运维 NoSQL 安全
【最佳实践】高可用mongodb集群(1分片+3副本):规划及部署
结合我们的生产需求,本次详细整理了最新版本 MonogoDB 7.0 集群的规划及部署过程,具有较大的参考价值,基本可照搬使用。 适应数据规模为T级的场景,由于设计了分片支撑,后续如有大数据量需求,可分片横向扩展。
1023 1
|
存储 缓存 负载均衡
高可用mongodb集群(分片+副本):规划及部署
高可用mongodb集群(分片+副本):规划及部署
1127 0
|
22天前
|
存储 运维 负载均衡
构建高可用的 ChunkServer 系统
【8月更文第30天】在分布式文件系统中,ChunkServer(也称为 DataNode)负责存储文件的数据块(chunks)。为了保证系统的高可用性和数据冗余,需要设计一种可靠的 ChunkServer 部署方案。本文将探讨如何设计和实现一个高可用的 ChunkServer 系统,并通过具体的代码示例来展示其实现细节。
29 0
|
3月前
|
消息中间件 Java Kafka
kafka 磁盘扩容与数据均衡操作代码
Kafka 的磁盘扩容和数据均衡是与保证Kafka集群可用性和性能相关的两个重要方面。在 Kafka 中,分区数据的存储和平衡对集群的运行至关重要。以下是有关Kafka磁盘扩容和数据均衡的一些建议
43 1
|
存储 NoSQL
Cassandra集群删除宕机节点
Cassandra集群删除宕机节点
Cassandra集群删除宕机节点
|
安全 NoSQL MongoDB
高可用mongodb集群(分片+副本):shard2副本重建
高可用mongodb集群(分片+副本):shard2副本重建
432 0
|
NoSQL 安全 MongoDB
高可用mongodb集群(分片+副本):用户权限配置
高可用mongodb集群(分片+副本):用户权限配置
417 0
|
缓存
OushuDB 管理指南系统扩容均衡HDFS
OushuDB 管理指南系统扩容均衡HDFS
120 0
OushuDB 管理指南系统扩容均衡HDFS
|
存储 网络协议 索引
GlusterFS数据存储脑裂修复方案
本文档介绍了glusterfs中可用于监视复制卷状态的`heal info`命令以及解决脑裂的方法
1390 0