3.Ceph 基础篇 - RBD 块存储使用

文章转载自：https://mp.weixin.qq.com/s?__biz=MzI1MDgwNzQ1MQ==&mid=2247485253&idx=1&sn=24d9b06a3c48ce74b30acf08807a243b&chksm=e9fdd2b1de8a5ba72ab7b221f3484a95f2a977ff7a607413e3a7b92d042d117c1f05c48a34b2&scene=178&cur_album_id=1600845417376776197#rd

数据存储原理

The Ceph storage system supports the notion of ‘Pools’, which are logical partitions for storing objects.

Ceph Clients retrieve a Cluster Map from a Ceph Monitor, and write objects to pools. The pool’s size or number of replicas, the CRUSH rule and the number of placement groups determine how Ceph will place the data.

Ceph存储系统支持“池”的概念，“池”是用于存储对象的逻辑分区。

Ceph客户端从Ceph监控器检索集群映射，并将对象写入池中。池的大小或副本数，CRUSH规则和放置组的数量决定了Ceph将如何放置数据。

Pools set at least the following parameters:

Ownership/Access to Objects

The Number of Placement Groups, and

The CRUSH Rule to Use.

池至少设置以下参数：

所有权/对对象的访问展示位置组数，以及使用的CRUSH规则。

Each pool has a number of placement groups. CRUSH maps PGs to OSDs dynamically. When a Ceph Client stores objects, CRUSH will map each object to a placement group.

每个存储池中有很多的归置组（PG），当一个Ceph 客户端存储一个对象时，CURSH 将映射每个对象到一个归置组中，CRUSH map 动态映射 PGs 到OSDs。

Mapping objects to placement groups creates a layer of indirection between the Ceph OSD Daemon and the Ceph Client. The Ceph Storage Cluster must be able to grow (or shrink) and rebalance where it stores objects dynamically. If the Ceph Client “knew” which Ceph OSD Daemon had which object, that would create a tight coupling between the Ceph Client and the Ceph OSD Daemon. Instead, the CRUSH algorithm maps each object to a placement group and then maps each placement group to one or more Ceph OSD Daemons. This layer of indirection allows Ceph to rebalance dynamically when new Ceph OSD Daemons and the underlying OSD devices come online. The following diagram depicts how CRUSH maps objects to placement groups, and placement groups to OSDs.

为了创建文件对象到归置组的映射，在 Ceph OSD Daemon 和 Ceph Client 创建一个间接层；Ceph 存储集群能够存储数据时动态的增长（或缩减）和再平衡。如果 Ceph Client 知道哪个 Ceph OSD 进程拥有哪个对象，那么会在 Ceph Clinet 与 OSD 进程间创建一个紧密的耦合，CRUSH 算法把文件对象映射成归置组，每个 PG 又映射成一个或多个 OSD；当一个新的Ceph OSD 进程和底层 OSD 设置加入后，这个中间层允许Ceph 动态再平衡数据；下图描述了CRUSH 如何映射，对象到PG，PG再到OSD。

With a copy of the cluster map and the CRUSH algorithm, the client can compute exactly which OSD to use when reading or writing a particular object.

通过集群映射和CRUSH算法的副本，客户机可以精确地计算在读写特定对象时要使用哪个OSD。

在上面这张数据流转图中，每一台主机上面可以存在多个 osd ，每一个 osd，我们通常认为是一个磁盘，当然如果你使用的是 filestore 引擎，这里就是一个目录。我们这里使用默认bluestore 引擎，代表一块磁盘，注意就算是使用一个目录，也应该是整个磁盘当作一个分区，格式化完成以后，挂载到某个目录下面，我们应该这么使用才对。

Osd: 对象存储设备 Object storage device，每一块磁盘就叫做一个osd，每台主机上面有多个 osd，多台主机构成 Rados cluster (RADOS 存储集群)，在这个集群内，除了存储节点外，还有一类节点叫 mon，叫元数据节点，ceph 不是没有元数据集群节点吗？而ceph集群没有说叫元数据节点，而是叫监视器mon——>monitor，它是用来管理整个集群的，比如你总共有多少个节点，每一个节点上面有多少个 osd，每一个 osd 是否健康，每一个 osd 位于哪个节点上等等，它会持有整个集群的运行图，或者叫运行状态、元数据，或者叫集群元数据，注意不是文件元数据。如果这个集群元数据节点挂了，整个集群将无法工作了，因此需要为这个 mon 节点需要做高可用，它使用 paxos 协议来实现集群的一致性，就像 etcd 使用 raft 协议一样，每一个节点都有完整的副本，它属于节点级冗余，这里的 mon 也是节点级冗余，为了确保数据在各节点上面是强一致的，每个节点都可写，写完之后，同步给其它节点，同时写的话，如果修改了同一个键，同步给另外的节点，发现不一样，是不是就冲突了，为了避免这种情况，他使用了一种叫分布式强一致性协议 paxos，它也是分布式最早的一种协议，mon 就是使用 paxos 协议在多个节点来协作的，这叫集群元数据 ；有了集群，为了监控整个集群，我们需要对 RADOS 集群中的 mon 做查询 ，就需要频繁访问这个 mon，或者监控软件需要周期性采集数据，而 mon 是实时查询集群数据的，大家知道这种实时查询代价是很高的，因此 mon 不太适用于频繁的周期性的采集集群数据的这种监控操作，但是监控又是必须的，所以 ceph 的新版本，引入了一个新组件，叫做 mgr，manager 的简写，这个组件专门维护这种查询类的操作，他的查询方式是在集群空闲的时候去查询，然后把查询到的集群信息缓存下来，等有监控来采集数据时，直接返回并响应，这叫mgr。有了这些组件才是一个完整的RADOS集群。

当我们要把一个文件存入到集群时，怎么存呢？通常情况下，当你接入ceph存储集群，你必须通过一个客户端来实现，基础架构篇讲过了三种（rbd、rgw、cephfs），或者根据 API 自研，无论通过哪种方式，都需要借助 API 接口把文件切分成固定大小的对象，而这个对象存储到哪里去？好了，到了抽象的概念了，ceph 的存储空间是没有目录的，所有的对象都是存储在一个平面上的，注意，所有的对象都在同一个平面上，所以所有的对象都不能重名，但是即便如此，我们存储1亿个对象，放在同一个命名空间下就可以管理了，但是将来迁移可以管理都不是很方便，因此 RADIOS 把它的存储切分成了多个分区，你可以理解为多个大磁盘，方便管理，每一个分区就叫一个存储池（pool），存储池的大小取决于下面的存储空间的大小，它和我们真正意义上的分区，不是一回事，你可以把存储池类比为 k8s 里面的命名空间就行了。而我们不能叫它命名空间，我们叫存储池，而存储池存放的数据有可能也很大；而存储池可以进一步划分，并非是必备组件，它是可选的，它被叫做名称空间，每一个存储池进一步切分成名称空间，这是两级管理的逻辑组件，接着是三级，每一个存储池中有多个 PG 存在，PG 叫归置组，存储池 pool 是抽象的概念，归置组 PG 也是抽象的概念，事实上，并不存在任何一个 PG，它是一个看不见，摸不着的，更不是一个实体。那么任何一个文件存放到 RADOS 存储系统的时候，如何存储呢？一个对象放在了哪一个osd上面？这中间是靠 cursh 算法来完成，每个对象存放在哪个存储池上面是固定的，存储池必须创建才能使用，这点各位要注意，但 PG 是不可捉摸的东西，它是一个虚拟的中间层，当我们把一个对象真正存入到 osd 中时，一定是要向某个存储池请求的，而后，我们需要把对象的名字，做一致性 hash 计算，计算完以后，会落到某个 PG 上面，比如说我们规定存储池中有64个 PG，比如说我们对象的名字对64做一致性hash计算，映射到 hash 环上，hash 环上并没有 PG，某个对象，一定属于某个存储池的某个 PG上 面来的；但 PG 是假的，虚拟的，事实上，是不存在的，要注意这点，只是一个计算的结果，把每一个 PG 存放在 osd 上面，PG 怎么到 osd，关键点来了，这是cursh 算法的第二步，我们需要把 PG 根据这个存储池的副本冗余数量和存储池的类型，找到足量的 osd 来存，存储池有类型，存储池的类型就是管理存储池冗余数据的，数据冗余无非是做数据分片的副本，这儿不叫分片，叫 PG，我们叫主 PG，也叫活动 PG 和副本 PG，我们这样来称呼就行了，一个 PG 里面的对象是统一被管理的，写的时候，一定是先写主 PG，然后再由主 PG 同步给副本 PG，当然如何同步是 OSD 内部管理的，所以我们的存储池和 crush 算法一定要确保哪个是主 PG 哪个是副本 PG，如果冗余1份，就是1主1副PG，如果冗余5份，就是1主5从，一般来讲传统的存储池，只冗余2份，一共3份，但是这样一来，我们的存储资源的利用率也只有1/3。

ceph 集群也支持另外的一种存储池，叫纠删码存储池，类似于 RAID，这样一来，利用率变高了，一样的有冗余能力。文件存储到存储系统分为两步；

1. 文件被按固定大小的切分成块，映射为存储池中的 PG；

2. 把 PG 映射为 osd， 这两步都是由 crush 算法完成的；

当然了 ceph 不光是要完成映射，万一哪个 osd 坏了，还要把坏的修复过来，这是内部的工作逻辑，自行修复。

RDB 基础

1. 使用 create 创建 pool 池（还有一种是通过init 的方式创建）

# 查看集群中的 pools
[root@ceph-node01 ~]# ceph osd lspools

# 使用 create 方式创建 pool 池
[root@ceph-node01 ~]# ceph osd pool create ceph-demo 64 64
pool 'ceph-demo' created

# 再次查看
[root@ceph-node01 ~]# ceph osd lspools
1 ceph-demo
[root@ceph-node01 ~]#

创建命令时需要指定PG、PGP数量，还可以指定复制模型还是纠删码模型，副本数量等等

[root@ceph-node01 ~]# ceph osd pool create
Invalid command: missing required parameter pool(<poolname>)
osd pool create <poolname> <int[0-]> {<int[0-]>} {replicated|erasure} {<erasure_code_profile>} {<rule>} {<int>} {<int>} {<int[0-]>} {<int[0-]>} {<float[0.0-1.0]>} : create pool
Error EINVAL: invalid command
[root@ceph-node01 ~]#

获取 pool 池属性信息，可以重新设置，有很多参数，都可以如下设置

# 获取 pg 个数
[root@ceph-node01 ~]# ceph osd pool get ceph-demo pg_num
pg_num: 64

# 获取 pgp 个数
[root@ceph-node01 ~]# ceph osd pool get ceph-demo pgp_num
pgp_num: 64

# 获取副本数
[root@ceph-node01 ~]# ceph osd pool get ceph-demo size
size: 3

# 获取使用模型
[root@ceph-node01 ~]# ceph osd pool get ceph-demo crush_rule
crush_rule: replicated_rule

# 设置副本数
[root@ceph-node01 ~]# ceph osd pool set ceph-demo size 2

# 设置 pg 数量
[root@ceph-node01 ~]# ceph osd pool set ceph-demo pg_num 128

# 设置 pgp 数量
[root@ceph-node01 ~]# ceph osd pool set ceph-demo pgp_num 128

1. 创建完 pool 后，需要初始化 pool

[root@ceph-node01 ceph-deploy]# rbd pool init ceph-demo

这里先不做，看下报错，然后我们排查问题；

1. 创建 rbd 块设备

# 查看 块设备
[root@ceph-node01 ~]# rbd -p ceph-demo ls

# 创建 块设备方式一
[root@ceph-node01 ~]# rbd create -p ceph-demo --image rbd-demo.img --size 10G

# 创建 块设备方式二
[root@ceph-node01 ~]# rbd create ceph-demo/rbd-demo2.img --size 10G

# 查看 块设备
[root@ceph-node01 ~]# rbd -p ceph-demo ls
rbd-demo.img
rbd-demo2.img
[root@ceph-node01 ~]#

查看块设备信息

[root@ceph-node01 ceph-deploy]# rbd info ceph-demo/rbd-demo2.img
rbd image 'rbd-demo2.img':
  size 10 GiB in 2560 objects
  order 22 (4 MiB objects)  # 每块 4 M，默认
  snapshot_count: 0
  id: 6150b827120b # 块设备 ID 号
  block_name_prefix: rbd_data.6150b827120b
  format: 2
  features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
  op_features:
  flags:
  create_timestamp: Sat Oct 3 23:40:53 2020
  access_timestamp: Sat Oct 3 23:40:53 2020
  modify_timestamp: Sat Oct 3 23:40:53 2020
[root@ceph-node01 ceph-deploy]#

1. 删除块设备

[root@ceph-node01 ~]# rbd rm -p ceph-demo --image rbd-demo2.img
Removing image: 100% complete...done.
[root@ceph-node01 ~]#

1. 设备挂载

由于没有虚拟机进行挂载，所以需要使用内核 map 进行挂载；

[root@ceph-node01 ~]# rbd map ceph-demo/rbd-demo.img
rbd: sysfs write failed
RBD image feature set mismatch. Try disabling features unsupported by the kernel with "rbd feature disable".
In some cases useful info is found in syslog - try "dmesg | tail".
rbd: map failed: (6) No such device or address
[root@ceph-node01 ~]#

映射的过程当中出现错误，这是因为 Centos7 当中不支持这几个特性，我们可以在创建时指定 features 。

[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img deep-flatten
[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img fast-diff
[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img object-map
rbd: failed to update image features: 2020-09-29 10:29:37.787 7fc8a06ddc80 -1 librbd::Operations: one or more requested features are already disabled(22) Invalid argument

[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img exclusive-lock
[root@ceph-node01 ~]#

再次挂载，挂载成功

[root@ceph-node01 ~]# rbd map ceph-demo/rbd-demo.img
/dev/rbd0
[root@ceph-node01 ~]#

查看设备列表

[root@ceph-node01 ~]# rbd device list
id pool namespace image snap device
0 ceph-demo rbd-demo.img - /dev/rbd0
[root@ceph-node01 ~]#

通过fdisk 查看设备列表

[root@ceph-node01 ~]# fdisk -l

......

磁盘 /dev/rbd0：10.7 GB, 10737418240 字节，20971520 个扇区
Units = 扇区 of 1 * 512 = 512 bytes
扇区大小(逻辑/物理)：512 字节 / 512 字节
I/O 大小(最小/最佳)：4194304 字节 / 4194304 字节

[root@ceph-node01 ~]#

1. 使用 rbd 设备

# 格式化为 ext4
[root@ceph-node01 ~]# mkfs.ext4 /dev/rbd0
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: 完成
文件系统标签=
OS type: Linux
块大小=4096 (log=2)
分块大小=4096 (log=2)
Stride=1024 blocks, Stripe width=1024 blocks
655360 inodes, 2621440 blocks
131072 blocks (5.00%) reserved for the super user
第一个数据块=0
Maximum filesystem blocks=2151677952
80 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: 完成
正在写入inode表: 完成
Creating journal (32768 blocks): 完成
Writing superblocks and filesystem accounting information: 完成

# 查看设备
[root@ceph-node01 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 252:0 0 50G 0 disk
├─vda1 252:1 0 500M 0 part /boot
└─vda2 252:2 0 49.5G 0 part
  ├─centos-root 253:0 0 44.5G 0 lvm /
  └─centos-swap 253:1 0 5G 0 lvm [SWAP]
vdb 252:16 0 100G 0 disk
└─ceph--f80dea0c--8b8c--46aa--95aa--35589c59b708-osd--block--136f6cf7--05a0--4325--aa92--ad316560edff
                                                                                 253:2 0 100G 0 lvm
vdc 252:32 0 100G 0 disk
rbd0 251:0 0 10G 0 disk
[root@ceph-node01 ~]#

mount rbd 设备

[root@ceph-node01 ~]# mkdir /mnt/rbd-demo
[root@ceph-node01 ~]# mount /dev/rbd0 /mnt/rbd-demo/
[root@ceph-node01 ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
。。。
/dev/rbd0 9.8G 37M 9.2G 1% /mnt/rbd-demo
[root@ceph-node01 ~]# cd /mnt/rbd-demo
[root@ceph-node01 rbd-demo]# ls
lost+found
[root@ceph-node01 rbd-demo]# echo `date` >test
[root@ceph-node01 rbd-demo]# ll
总用量 20
drwx------ 2 root root 16384 9月 29 10:36 lost+found
-rw-r--r-- 1 root root 43 9月 29 10:41 test
[root@ceph-node01 rbd-demo]#

1. 块设备扩容

设备可以扩容，也可以缩容，但不建议使用缩容，有可能产生数据丢失。

[root@ceph-node01 rbd-demo]# rbd resize ceph-demo/rbd-demo.img --size 20G
Resizing image: 100% complete...done.
[root@ceph-node01 rbd-demo]# rbd -p ceph-demo info --image rbd-demo.img
rbd image 'rbd-demo.img':
  size 20 GiB in 5120 objects # 已经扩容到了20G
  order 22 (4 MiB objects)
  snapshot_count: 0
  id: 12e14e0cad6b
  block_name_prefix: rbd_data.12e14e0cad6b
  format: 2
  features: layering
  op_features:
  flags:
  create_timestamp: Tue Sep 29 10:13:59 2020
  access_timestamp: Tue Sep 29 10:13:59 2020
  modify_timestamp: Tue Sep 29 10:13:59 2020
[root@ceph-node01 rbd-demo]#

我们通过 fdisk -l 发现设备也扩容成功了，但 df -h 文件系统没有扩容，我们要使用文件系统能够识别到这个空间，就需要使用 resize2fs 命令；

[root@ceph-node01 rbd-demo]# resize2fs /dev/rbd0
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/rbd0 is mounted on /mnt/rbd-demo; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 3
The filesystem on /dev/rbd0 is now 5242880 blocks long.

[root@ceph-node01 rbd-demo]# df -h
文件系统 容量 已用 可用 已用% 挂载点
。。。
/dev/rbd0 20G 44M 19G 1% /mnt/rbd-demo
[root@ceph-node01 rbd-demo]#

块设备扩容一般会涉及ny三方面的内容：

1. 底层存储的扩容；
2. 磁盘分区的扩容；
3. 文件系统的扩容；

这里第 2 步省略了，我们直接使用了整块盘，其实在虚拟化环境中，也不建议对磁盘再分区。

RBD 数据写入流程

1. 一个对象会切割成多个object(默认是4M)

[root@ceph-node01 ~]# rbd -p ceph-demo info rbd-demo.img
rbd image 'rbd-demo.img':
  size 20 GiB in 5120 objects
  order 22 (4 MiB objects)
  snapshot_count: 0
  id: 12e14e0cad6b
  block_name_prefix: rbd_data.12e14e0cad6b
  format: 2
  features: layering
  op_features:
  flags:
  create_timestamp: Tue Sep 29 10:13:59 2020
  access_timestamp: Tue Sep 29 10:13:59 2020
  modify_timestamp: Tue Sep 29 10:13:59 2020
[root@ceph-node01 ~]#

这里最多有 5120 个object，object 的前缀都是以rbd_data. 开头；

查看 object 信息；

[root@ceph-node01 ~]# rados -p ceph-demo ls|grep rbd_data.12e14e0cad6b
rbd_data.12e14e0cad6b.000000000000042f
rbd_data.12e14e0cad6b.0000000000000060
rbd_data.12e14e0cad6b.0000000000000020
rbd_data.12e14e0cad6b.0000000000000c00
。。。
[root@ceph-node01 ~]#

查看每个object的大小

[root@ceph-node01 ~]# rados -p ceph-demo stat rbd_data.12e14e0cad6b.000000000000042f
ceph-demo/rbd_data.12e14e0cad6b.000000000000042f mtime 2020-10-04 00:50:12.000000, size 4194304
[root@ceph-node01 ~]#

注意，当前查看的这个 object的大小为 4M，有些 object 有可能小于 4M，但不可能大小4M；

1. 查看 object 落在哪个 PG 上面

[root@ceph-node01 ~]# ceph osd map ceph-demo bd_data.12e14e0cad6b.000000000000042f
osdmap e37 pool 'ceph-demo' (1) object 'bd_data.12e14e0cad6b.000000000000042f' -> pg 1.46b3a134 (1.34) -> up ([2,1], p2) acting ([2,1], p2)
[root@ceph-node01 ~]#

资源池 ceph-demo中的1号对象，然后是objcect id，经过crush算法得到 PG为1.34，最终落到OSD 2和 1上面 ，通过ceph osd tree，可以查看对应的节点；

[root@ceph-node01 ~]# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.39067 root default
-3 0.09769 host ceph-node01
 0 hdd 0.09769 osd.0 up 1.00000 1.00000
-5 0.09769 host ceph-node02
 1 hdd 0.09769 osd.1 up 1.00000 1.00000
-7 0.19530 host ceph-node03
 2 hdd 0.19530 osd.2 up 1.00000 1.00000
[root@ceph-node01 ~]#

osd.2 对应的是 ceph-node03 节点，osd.1 对应的是 ceph-node02 节点；

[root@ceph-node01 ~]# for i in `rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b`
> do
> ceph osd map ceph-demo $i
> done
osdmap e37 pool 'ceph-demo' (1) object 'rbd_data.12e14e0cad6b.000000000000042f' -> pg 1.38cd6b20 (1.20) -> up ([2,1], p2) acting ([2,1], p2)
osdmap e37 pool 'ceph-demo' (1) object 'rbd_data.12e14e0cad6b.0000000000000060' -> pg 1.cf585158 (1.58) -> up ([2,0], p2) acting ([2,0], p2)
osdmap e37 pool 'ceph-demo' (1) object 'rbd_data.12e14e0cad6b.0000000000000020' -> pg
。。。
'rbd_data.12e14e0cad6b.0000000000000421' -> pg 1.8116d2df (1.5f) -> up ([2,0], p2) acting ([2,0], p2)
[root@ceph-node01 ~]#

通过上面可以看到 rbd-demo.img 存储分布到了不同的 PG，然后 PG 又映射到了不同的 OSD 上面；

RBD 特性之一瘦分配

瘦分配随着空间使用的情况，自动的扩这个空间，大约使用了144M；

[root@ceph-node01 ~]# for i in `rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b`; do rados -p ceph-demo stat $i | gawk '{print $NF}'; done>size.log
[root@ceph-node01 ~]# cat size.log |gawk 'BEGIN{SUM=0}{SUM+=$1}END{print SUM/1024/1024}'
144.652
[root@ceph-node01 ~]#

现在我们自动化通过监控 watch -n 1 'rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b|wc -l' object 数量的变化来查看动态扩空间来说明瘦分配机制，打开另一个窗口，向 /mnt/ rbd-demo/ 目录中写入1G的数据文件，可以看到动态分配磁盘空间；

[root@ceph-node01 rbd-demo]# dd if=/dev/zero of=/mnt/rbd-demo/test.log count=1024 bs=1014k
记录了1024+0 的读入
记录了1024+0 的写出
1063256064字节(1.1 GB)已复制，1.61673 秒，658 MB/秒
[root@ceph-node01 rbd-demo]#

再次进行计算，大约占了一个多G的量，通过df对比下；

[root@ceph-node01 ~]# for i in `rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b`; do rados -p ceph-demo stat $i | gawk '{print $NF}'; done>size.log
[root@ceph-node01 ~]# cat size.log |gawk 'BEGIN{SUM=0}{SUM+=$1}END{print SUM/1024/1024}'
1158.67
[root@ceph-node01 ~]#

通过df 查看空间，基本与上面计算的一致；

[root@ceph-node01 ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
。。。
/dev/rbd0 20G 1.1G 18G 6% /mnt/rbd-demo
[root@ceph-node01 ~]#

总结

数据存储流程

1. 文件对象；
2. 切割成大小为4M的 object 对象；
3. object 对象通过CRUSH 算法映射到 PG；
4. PG 通过CRUSH算法映射到OSD；

基本使用

创建 pool 池：ceph osd pool create ceph-demo 64 64
在 Pool 池中创建 rbd 对象：
rbd create -p ceph-demo --image rbd-demo.img --size 10G
使用内核map 挂载rbd对象：rbd map ceph-demo/rbd-demo.img
格式化块设备：mkfs.ext4 /dev/rbd0
挂载块设备：mount /dev/rbd0 /mnt/rbd-demo/
设置 pool 池信息：ceph osd pool set ceph-demo size 2
扩容 rbd 块设备：rbd resize ceph-demo/rbd-demo.img --size 20G
扩容挂载后文件系统：resize2fs /dev/rbd0
删除块设备：rbd rm -p ceph-demo --image rbd-demo2.img

信息查看

查看pool池中的rbd块设备：rbd -p ceph-demo ls

查看块设备详细信息方式一：rbd info ceph-demo/rbd-demo2.img、

查看块设备详细信息方式二：rbd -p ceph-demo info rbd-demo.img

查看本机rbd设备列表：rbd device list

查看块设备对应的所有 objects ：rados -p ceph-demo ls|grep rbd_data.12e14e0cad6b

单个object对象映射的PG及OSD信息/大小等：ceph osd map ceph-demo bd_data.12e14e0cad6b.000000000000042f