1.RBD介绍
RBD即RADOS Block Device的简称，RBD块存储是最稳定且最常用的存储类型。RBD块设备类似磁盘可以被挂载。 RBD块设备具有快照、多副本、克隆和一致性等特性，数据以条带化的方式存储在Ceph集群的多个OSD中。如下是对Ceph RBD的理解。
RBD 就是 Ceph 里的块设备，一个 4T 的块设备的功能和一个 4T 的 SATA 类似，挂载的 RBD 就可以当磁盘用；
resizable：这个块可大可小；
data striped：这个块在Ceph里面是被切割成若干小块来保存，不然 1PB 的块怎么存的下；
thin-provisioned：精简置备，1TB 的集群是能创建无数 1PB 的块的。其实就是块的大小和在 Ceph 中实际占用大小是没有关系的，刚创建出来的块是不占空间，今后用多大空间，才会在 Ceph 中占用多大空间。举例：你有一个 32G 的 U盘，存了一个2G的电影，那么 RBD 大小就类似于 32G，而 2G 就相当于在 Ceph 中占用的空间 ；
块存储本质就是将裸磁盘或类似裸磁盘(lvm)设备映射给主机使用，主机可以对其进行格式化并存储和读取数据，块设备读取速度快但是不支持共享。
ceph可以通过内核模块和librbd库提供块设备支持。客户端可以通过内核模块挂在rbd使用，客户端使用rbd块设备就像使用普通硬盘一样，可以对其就行格式化然后使用；客户应用也可以通过librbd使用ceph块，典型的是云平台的块存储服务（如下图），云平台可以使用rbd作为云的存储后端提供镜像存储、volume块或者客户的系统引导盘等。
使用场景： 云平台（OpenStack做为云的存储后端提供镜像存储）
K8s容器
map成块设备直接使用 ISCIS
安装Ceph客户端
2.RBD常用命令
3.Pool配置操作
Pool的基本配置
若少于5个OSD， 设置pg_num为128。
5~10个OSD，设置pg_num为512。
10~50个OSD，设置pg_num为4096。
超过50个OSD，可以参考pgcalc计算。
（1）创建pool
语法：
ceph osd pool create {pool-name} {pg-num} [{pgp-num}] [replicated] \
[crush-ruleset-name] [expected-num-objects]
ceph osd pool create {pool-name} {pg-num} {pgp-num} erasure \
[erasure-code-profile] [crush-ruleset-name] [expected_num_objects]
（2）创建一个test-pool，pg_num为512 （我这里是6个osd）：
ceph osd pool set volumes pg_num 512
ceph osd pool set volumes pgp_num 512
修改volumes的pg以及pgp数量 根据osd来修改
ceph osd pool create test-pool 128
（3）设置pool配额
支持object个数配额以及容量大小配额。
设置允许最大object数量为100：
ceph osd pool set-quota test-pool max_objects 100
设置允许容量限制为10GB:
ceph osd pool set-quota test-pool max_bytes $((10 * 1024 * 1024 * 1024))
取消配额限制只需要把对应值设为0即可。
（4）重命名pool
ceph osd pool rename test-pool test-pool-new
（5）删除Pool
删除一个pool会同时清空pool的所有数据，因此非常危险。(和rm -rf /类似）。因此删除pool时ceph要求必须输入两次pool名称，同时加上–yes-i-really-really-mean-it选项。
ceph osd pool delete test-pool test-pool --yes-i-really-really-mean-it
（6）查看pool状态信息
rados df
（7）创建快照
ceph支持对整个pool创建快照（和Openstack Cinder一致性组区别？），作用于这个pool的所有对象。但注意ceph有两种pool模式：
Pool Snapshot，我们即将使用的模式。创建一个新的pool时，默认也是这种模式。
Self Managed Snapsoht，用户管理的snapshot，这个用户指的是librbd，也就是说，如果在pool创建了rbd实例就自动转化为这种模式。
这两种模式是相互排斥，只能使用其中一个。因此，如果pool中曾经创建了rbd对象（即使当前删除了所有的image实例）就不能再对这个pool做快照了。反之，如果对一个pool做了快照，就不能创建rbd image了。
ceph osd pool mksnap test-pool test-pool-snapshot
查看信息
ceph osd pool ls detail （可以查看到快照信息）
（8）删除快照
ceph osd pool rmsnap test-pool test-pool-snapshot
设置pool
通过以下语法设置pool的元数据：
ceph osd pool set {pool-name} {key} {value}
比如设置pool的冗余副本数量为3:
ceph osd pool set test-pool size 3
其他配置项参考文档。
通过get操作能够获取pool的配置值,比如获取当前pg_num：
ceph osd pool get test-pool pg_num
获取当前副本数:
ceph osd pool get test-pool size
4.RBD配置操作
（1）RBD挂载到操作系统
①创建rbd使用的pool（数字根据自己的磁盘计算）
ceph osd pool create rbd 32 32
ceph osd pool application enable rbd rbd
②创建一个块设备
rbd create --size 10240 image01
③查看块设备
rbd ls
rbd info image01
④将块设备映射到系统内核
rbd map image01 （会报错 因为系统内核不支持 需要禁用一部分feature）
⑤禁用当前系统内核不支持的feature
rbd feature disable foo_image exclusive-lock, object-map, fast-diff, deep-flatten
⑥再次映射
rbd map image01
⑦格式化块设备镜像
mkfs.xfs /dev/rbd0
⑧mount到本地
mount /dev/rbd0 /mnt
umount /mnt
⑨取消块设备和内核映射
rbd unmap image01
⑩删除RBD块设备
rbd rm image01
（2）快照设置
①创建快照
rbd create --size 10240 image02
rbd snap create image02@image02_snap01
②列出创建的快照
rbd snap list image02
或
rbd ls -l
③查看快照详细信息
rbd info image02@image02_snap01
④克隆快照（快照必须处于被保护状态才能被克隆）
rbd snap protect image02@image02_snap01
rbd clone rbd/image02@image02_snap01 kube/image02_clone01
⑤查看快照的children
rbd children image02
⑥去掉快照的parent
rbd flatten kube/image02_clone01
⑦恢复快照
rbd snap rollback image02@image02_snap01
⑧删除快照
rbd snap unprotect image02@image02_snap01
rbd snap remove image02@image02_snap01
（3）导出导入RBD镜像
导出RBD镜像
rbd export image02 /tmp/image02
导出RBD镜像
rbd import /tmp/image02 rbd/image02 --image-format 2
5.PG的常见状态
ceph - pg 常见状态
pg ( placement group ) 是数据存储的重要单位
在使用 ceph 的时候, pg 会经常发生状态的变化, 参考下面例子
当创建池的时候, 将会创建相应的 pg, 那么可以看到 pg creating 状态
当部分 pg 创建成功后, 将会发现 pg 会进入 peering 状态
当所有 pg peering 完成后, 将可见到状态变成 active+clean
常见的 pg 状态
creating (创建中)
PG 正在被创建, 通常当存储池正在卑创建或增加一个存储池的 PG 数量时, PG 会呈现这个状态
Down (失效)
PG 处于失效状态, PG 应该处于离线状态
repair(修复)
PG 正在被检查, 被发现的任何不一致都将尽可能被修复.
peering (等待互联)
当 ceph peering pg, ceph 将会把 pg 副本协定导入 osd, 当 ceph 完成 peering, 意味着 osd 同意当前 PG 状态, 并允许写入
PG 处于 peering 过程中, peering 由主 osd 发起的使存放 PG 副本的所有 OSD 就 PG 的所有对象和元素数据的状态达成一致的过程, peering 过程完成后, 主 OSD 就可以接受客户端写请求.
Active (活动)
当 ceph 完成 peering 过程, pg 将会变成 active, active 状态意味着 pg 中的数据变得可用, 主 pg 将可执行读写操作
PG 是活动的, 意味着 PG 中的数据可以被读写, 对该 PG 的操作请求都讲会被处理.
Clean (干净)
当 pg 显示 clean 状态, 主 osd 与副本 osd 成功同步并且没有异步复制, ceph 在 pg 中所有对象具有正确的副本数量
PG 中的所有对象都已经卑复制了规定的副本数量.
Replay (重做)
某 OSD 崩溃后, PG 正在等待客户端重新发起操作
Degraded (降级)
当客户端写对象到主 osd, 主 OSD 会把数据写复制到对应复制 OSD, 在主 OSD 把对象写入存储后, PG 会显示为 degraded 状态, 直到主 osd 从复制 OSD 中接收到创建副本对象完成信息
PG 处于 active+degraded 原因是因为 OSD 是处于活跃, 但并没有完成所有的对象副本写入, 假如 OSD DOWN, CEPH 标记每个 PG 分配到这个相关 OSD 的
状态为 degraded, 当 OSD 重新上线, OSD 将会重新恢复,
假如 OSD DOWN 并且 degraded 状态持续, CEPH 会标记 DOWN OSD, 并会对集群迁移相关 OSD 的数据, 对应时间由 mon osd down out interval 参数决定
PG 可以被北极为 degraded, 因为 ceph 在对应 PG 中无法找到一个或者多个相关的对象, 你不可以读写 unfound 对象, 你仍然可以访问标记为 degraded PG 的其他数据
PG 中部分对象的副本数量未达到规定的数量
Inconsistent (不一致)
PG副本出现不一致, 对象大小不正确或者恢复借宿后某个副本出现对象丢失现象
recoverying (恢复中)
ceph 设备故障容忍在一定范围的软件与硬件问题, 当 OSD 变 DOWN, 那么包含该 OSD 的 PG 副本都会有问题, 当 OSD 恢复, OSD 对应的 PG 将会更新
并反映出当前状态, 在一段时间周期后, OSD 将会恢复 recoverying 状态
recovery 并非永远都有效, 因为硬件故障可能会导致多个 OSD 故障, 例如, 网络交换机故障, 可以导致集群中的多个主机及主机包含的 OSD 故障
当网络恢复之后, 每个 OSD 都必须执行恢复
CEPH 提供一定数量的设定在新服务请求与恢复 PG 中数据对象时的资源平衡,
osd recovery delay start 设定允许 osd 重启, re-peer 并在启动 恢复之前处理一些回应请求,
osd recovery threads 设定了恢复过程中线程限制 (默认 1 )
osd recovery thread timeout 设定线程超时, 因为可能出现多个 osd 故障, 重启后在 re-peer 过程中可能出现污染
osd recovery max active 设定限制对一个 osd 从故障后, 恢复请求并发数量
osd recovery max chunk 限制恢复时的数据 chunk 大小, 预防网络堵塞
PG 正在迁移或者同步对象及其副本, 一个 OSD 停止服务(DOWN), 其内容将会落后与 PG 内的其他副本, 这时 PG 将会进入 recoverying 状态, 该 OSD 上的对象将从其他副本同步过来
BACK FILLING (回填)
当新 OSD 加入集群, CRUSH 将会为集群新添加的 OSD 重新分配 PG, 强制新的 OSD 接受重新分配的 PG 并把一定数量的负载转移到新 OSD 中
back filling OSD 会在后台处理, 当 backfilling 完成, 新的 OSD 完成后, 将开始对请求进行服务
在 backfill 操作期间, 你可以看到多种状态, backfill_wait 表示 backfill 操作挂起, 但
backfill 操作还没有开始 ( PG 正在等待开始回填操作 ) backfill 表示 backfill 操作正在执行
backfill_too_full 表示在请求 backfill 操作, 由于存储能力问题, 但不可以完成, ceph
提供设定管理装载重新分配 PG 关联到新的 OSD osd_max_backfills 设定最大数量并发 backfills 到一个
OSD, 默认 10 osd backfill full ratio 当 osd 达到负载, 允许 OSD 拒绝 backfill 请求,
默认 85%, 假如 OSD 拒绝 backfill 请求, osd backfill retry interval 将会生效, 默认
10 秒后重试 osd backfill scan min , osd backfill scan max 管理检测时间间隔 一个新
OSD 加入集群后, CRUSH 会把集群先有的一部分 PG 分配给他, 该过程称为回填, 回填进程完成后, 新 OSD
准备好了就可以对外提供服务
REMAPPED (重映射)
当 pg 改变, 数据从旧的 osd 迁移到新的 osd, 新的主 osd 应该请求将会花费一段时间, 在这段时间内, 将会继续向旧主 osd 请求服务, 直到
PG 迁移完成, 当数据迁移完成, mapping 将会使用新的 OSD 响应主 OSD 服务
当 PG 的 action set 变化后, 数据将会从旧 acting set 迁移到新 action set, 新主 OSD 需要过一段时间后才能提供服务, 因此它会让老的主 OSD 继续提供服务, 知道 PG 迁移完成, 数据迁移完成后, PG map 将会使用新 acting set 中的主 OSD
STALE (旧)
当 ceph 使用 heartbeat 确认主机与进程是否运行, ceph osd daemon 可能由于网络临时故障, 获得一个卡住状态 (stuck state) 没有得到心跳回应
默认, osd daemon 会每 0.5 秒报告 PG, up 状态, 启动与故障分析,
假如 PG 中主 OSD 因为故障没有回应 monitor 或者其他 OSD 报告 主 osd down, 那么 monitor 将会标记 PG stale,
当你重启集群, 通常会看到 stale 状态, 直到 peering 处理完成,
在集群运行一段时候, 看到 stale 状态, 表示主 osd PG DOWN 或者没有主 osd 没有报告 PG 信息到 monitor 中
PG 处于未知状态, monitors 在 PG map 改变后还没有收到过 PG 的更新, 启用一个集群后, 常常会看到主 peering 过程结束前 PG 处于该状态
Scrubbing (清理中)
PG 在做不一至性校验
有问题的 PG:
inactive:
PG 很长时间没有显示为 acitve 状态, (不可执行读写请求), PG 不可以执行读写, 因为等待 OSD 更新数据到最新的备份状态
unclean:
PG 很长时间都不是 clean 状态 (不可以完成之前恢复的操作), PG 包含对象没有完成相应的复制副本数量, 通常都要执行恢复操作
stale:
PG 状态很长时间没有被 ceph-osd 更新过, 标识存储在该 GP 中的节点显示为 DOWN, PG 处于 unknown 状态, 因为 OSD 没有报告 monitor 由 mon osd report timeout 定义超时时间
