ceph 分布式存储获取指定的pg分布

admin · 发表于 2022-7-26 10:01:52

购买主题本主题需向作者支付 5 金钱 才能浏览

admin · 发表于 2022-7-26 10:04:59

不难看出，PG分布的比较不均匀，但总体上来说还好，osd.28上的PG数最多 257个PG，而osd.0-14上PG数最少，只有0，平均下来，如果不同OSD之间使用量差距很大就需要引起注意

admin · 发表于 2022-7-26 10:08:27

[root@compute03 ~]# ceph pg stat
[root@compute03 ~]# ceph pg dump_stuck
ok
[root@compute03 ~]# ceph pg dump

[root@compute03 ~]# ceph pg dump_json
...........................

sum 1635749 0 0 0 0 6869267547107 66904 3988 9997885 9997885
OSD_STAT USED AVAIL USED_RAW TOTAL HB_PEERS                                                                      PG_SUM PRIMARY_PG_SUM
31    696 GiB 6.6 TiB  698 GiB 7.3 TiB  [0,1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,30] 294          133
30    638 GiB 6.7 TiB  640 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,31] 273          129
29    674 GiB 6.6 TiB  675 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,30] 277          147
28    751 GiB 6.5 TiB  753 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,27,29,30,31] 312          158
27    746 GiB 6.5 TiB  748 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,28,29,30,31] 308          169
26    611 GiB 6.7 TiB  613 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,27,29,30,31] 271          127
25    667 GiB 6.6 TiB  668 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,24,26,27,28,29,30,31] 287          152
24    681 GiB 6.6 TiB  683 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,25,26,27,28,29,30,31] 290          137
23    681 GiB 6.6 TiB  683 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,24,26,27,28,29,30,31] 286          138
22    614 GiB 6.7 TiB  616 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,21,23,24,25,26,27,28,29,30,31] 261          121
9       140 GiB 418 GiB  141 GiB 559 GiB                                  [1,3,5,6,7,8,10,11,12,13,14,17,21,23,26,29] 337          155
8       21 MiB 446 GiB  1.0 GiB 447 GiB                                  [0,2,4,6,7,9,10,11,12,13,16,19,20,25,28,31]    0             0
7       21 MiB 446 GiB  1.0 GiB 447 GiB                                  [1,3,5,6,8,9,10,11,12,13,15,18,22,24,27,30]    0             0
6       21 MiB 446 GiB  1.0 GiB 447 GiB                               [0,2,4,5,7,8,9,10,11,12,13,14,17,21,23,26,29]    0             0
5       6.4 GiB 887 GiB  7.4 GiB 894 GiB                            [0,1,2,3,4,6,7,8,9,10,11,12,13,16,19,20,25,28,31]    46          28
4       5.9 GiB 887 GiB  6.9 GiB 894 GiB                            [0,1,2,3,5,6,7,8,9,10,11,12,13,15,18,22,24,27,30]    44          20
0       5.9 GiB 887 GiB  6.9 GiB 894 GiB                         [1,2,3,4,5,6,7,8,9,10,11,12,13,14,17,21,23,26,29,31]    42          21
1       4.6 GiB 889 GiB  5.6 GiB 894 GiB                            [0,2,3,4,5,6,7,8,9,10,11,12,13,15,18,22,24,27,30]    33          15
2       4.4 GiB 889 GiB  5.4 GiB 894 GiB                            [0,1,3,4,5,6,7,8,9,10,11,12,13,16,19,20,25,28,31]    33          16
3       7.7 GiB 886 GiB  8.7 GiB 894 GiB                            [0,1,2,4,5,6,7,8,9,10,11,12,13,14,17,21,23,26,29]    58          28
10    147 GiB 411 GiB  148 GiB 559 GiB                                  [0,2,4,6,7,8,9,11,12,13,15,18,22,24,27,30] 352          177
11    140 GiB 418 GiB  141 GiB 559 GiB                                  [1,3,5,6,7,8,9,10,12,13,16,19,20,25,28,31] 335          180
12    110 GiB 2.1 TiB  112 GiB 2.2 TiB                                  [0,2,4,6,7,8,9,10,11,13,14,17,21,23,26,29] 512          259
13    110 GiB 2.1 TiB  112 GiB 2.2 TiB                               [1,3,5,6,7,8,9,10,11,12,14,16,18,22,24,27,30] 512          253
14    709 GiB 6.6 TiB  711 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,15,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] 291          142
15    662 GiB 6.6 TiB  664 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] 288          142
16    631 GiB 6.7 TiB  633 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,15,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] 280          145
17    629 GiB 6.7 TiB  630 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,18,20,21,22,23,24,25,26,27,28,29,30,31] 279          141
18    617 GiB 6.7 TiB  619 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,19,20,21,22,23,24,25,26,27,28,29,30,31] 266          126
19    633 GiB 6.7 TiB  635 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,18,20,21,22,23,24,25,26,27,28,29,30,31] 271          146
20    730 GiB 6.6 TiB  732 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,21,23,24,25,26,27,28,29,30,31] 305          160
21    667 GiB 6.6 TiB  668 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,22,23,24,25,26,27,28,29,30,31] 281          147
sum    12 TiB 131 TiB 12 TiB 144 TiB

* NOTE: Omap statistics are gathered during deep scrub and may be inaccurate soon afterwards depending on utilisation. See http://docs.ceph.com/docs/master ... up/#omap-statistics for further details.

admin · 发表于 2022-7-26 10:09:25

常见的PG状态：

常见的pg状态：
creating ：创建中
down ：PG处于失效状态，PG处于离线状态

repair （修复）：PG正在被检查，被发现的任何不一致都将尽可能的被修复。

peering（等待互联）：
1. 当ceph peering pg, ceph 将会把 pg 副本协定导入 osd, 当 ceph 完成 peering, 意味着 osd 同意当前 PG 状态, 并允许写入
2. PG处于 peering 过程中, peering 由主 osd 发起的使存放 PG 副本的所有 OSD 就 PG 的所有对象和元素数据的状态达成一致的过程,  peering 过程完成后, 主 OSD 就可以接受客户端写请求.

active：
1. 当 ceph 完成 peering 过程, pg 将会变成 active, active 状态意味着 pg 中的数据变得可用, 主 pg 将可执行读写操作
2. PG 是活动的, 意味着 PG 中的数据可以被读写, 对该 PG 的操作请求都讲会被处理.

clean: 干净态。PG当前不存在待修复的对象， Acting Set和Up Set内容一致，并且大小等于存储池的副本数

replay（重做）：某OSD崩溃后，PG正在等待客户端重新发起操作。

degraded（降级）：
1. 当客户端写对象到主 osd, 主 OSD 会把数据写复制到对应复制 OSD, 在主 OSD 把对象写入存储后, PG 会显示为 degraded 状态, 直到主 osd 从复制 OSD 中接收到创建副本对象完成信息
2. PG 处于 active+degraded 原因是因为 OSD 是处于活跃, 但并没有完成所有的对象副本写入, 假如 OSD DOWN, CEPH 标记每个 PG 分配到这个相关 OSD 的
状态为 degraded, 当 OSD 重新上线, OSD 将会重新恢复,
3. 假如 OSD DOWN 并且 degraded 状态持续, CEPH 会标记 DOWN OSD, 并会对集群迁移相关 OSD 的数据, 对应时间由 mon osd down out interval 参数决定
4. PG 可以被北极为 degraded, 因为 ceph 在对应 PG 中无法找到一个或者多个相关的对象, 你不可以读写 unfound 对象, 你仍然可以访问标记为 degraded PG 的其他数据
5. PG 中部分对象的副本数量未达到规定的数量

inconsistent（不一致）：PG副本出现不一致, 对象大小不正确或者恢复借宿后某个副本出现对象丢失现象

recoverying（恢复中）：
ceph 设备故障容忍在一定范围的软件与硬件问题, 当 OSD 变 DOWN, 那么包含该 OSD 的 PG 副本都会有问题, 当 OSD 恢复, OSD 对应的 PG 将会更新
并反映出当前状态, 在一段时间周期后, OSD 将会恢复 recoverying 状态
recovery 并非永远都有效, 因为硬件故障可能会导致多个 OSD 故障, 例如, 网络交换机故障, 可以导致集群中的多个主机及主机包含的 OSD 故障
当网络恢复之后, 每个 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

例如：
[root@ ~]# ceph osd map volumes rbd_id.volume-1421625f-a9a2-41d0-8023-4cec54b33a57
osdmap e5276 pool 'volumes' (1) object 'rbd_id.volume-1421625f-a9a2-41d0-8023-4cec54b33a57' -> pg 1.2cdd8028 (1.28) -> up ([32,26,41], p32) acting ([32,26,41], p32)

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 定义超时时间
ceph pg 常见问题处理：

案例1:

1. 检查集群状态发现有pg  inconsistent
通过ceph health detail查看具体的PG id。

$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
pg 3.0 is active+clean+inconsistent, acting [34,23,1]

通过上面输出可以看到当前PG3.0处于inconsistent，并且它的三副本分别在osd.34,osd.23,osd.1。

2. 修复PG 3.0
$ ceph pg repair 3.0
instructing pg 3.0 on osd.34 to repair

#查看集群监控状态
$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent, 1 pg repair
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent, 1 pg repair
pg 3.0 is active+clean+scrubbing+deep+inconsistent+repair, acting [34,23,1]

#集群监控状态已恢复正常
$ ceph health detail
HEALTH_OK

3. 根据以往经验，pg出现inconsistent很有可能是对应的osd磁盘上有逻辑坏道，可以去查看osd [34,23,1]的磁盘，查看对应节点上的dmesg日志。
dimes -T |grep -I err
案例2: osd挂了

当osd短暂挂掉的时候，因为集群内还存在着两个副本，是可以正常写入的，但是 osd.34 内的数据并没有得到更新，过了一会osd.34上线了，这个时候osd.34的数据是陈旧的，就通过其他的OSD 向 osd.34 进行数据的恢复，使其数据为最新的，而这个恢复的过程中，PG的状态会从inconsistent ->recover -> clean,最终恢复正常。
这是集群故障自愈一种场景。

admin · 发表于 2022-7-26 10:14:15

1、查看ceph集群配置信息

ceph daemon /var/run/ceph/ceph-mon.$(hostname -s).asok config show
2、在部署节点修改了ceph.conf文件，将新配置推送至全部的ceph节点

ceph-deploy  --overwrite-conf config push dlp node1 node2 node3
3、检查仲裁状态，查看mon添加是否成功

ceph quorum_status --format json-pretty
4、列式pool列表

ceph osd lspools
5、列示pool详细信息

ceph osd dump | grep pool
6、检查pool的副本数

ceph osd dump|grep -i size
7、创建pool

ceph osd pool create pooltest 128
8、删除pool

ceph osd pool delete data　　#会提示确认信息（增加命令，如下）
ceph osd pool delete data data  --yes-i-really-really-mean-it
9、设置pool副本数

ceph osd pool get data size
ceph osd pool set data size 3
10、设置pool配额

ceph osd pool set-quota data max_objects 100                            #最大100个对象
ceph osd pool set-quota data max_bytes $((10 * 1024 * 1024 * 1024))    #容量大小最大为10G
11、重命名pool

ceph osd pool rename data date
12、PG, Placement Groups。CRUSH先将数据分解成一组对象，然后根据对象名称、复制级别和系统中的PG数等信息执行散列操作，再将结果生成PG ID。可以将PG看做一个逻辑容器，这个容器包含多个对象，同时这个逻辑对象映射之多个OSD上。如果没有PG，在成千上万个OSD上管理和跟踪数百万计的对象的复制和传播是相当困难的。没有PG这一层，管理海量的对象所消耗的计算资源也是不可想象的。建议每个OSD上配置50~100个PG。

　　PGP是为了实现定位而设置的PG，它的值应该和PG的总数(即pg_num)保持一致。对于Ceph的一个pool而言，如果增加pg_num，还应该调整pgp_num为同样的值，这样集群才可以开始再平衡。

   参数pg_num定义了PG的数量，PG映射至OSD。当任意pool的PG数增加时，PG依然保持和源OSD的映射。直至目前，Ceph还未开始再平衡。此时，增加pgp_num的值，PG才开始从源OSD迁移至其他的OSD，正式开始再平衡。PGP，Placement Groups of Placement。

　　计算PG数：

　　ceph集群中的PG总数：

PG总数 = (OSD总数 * 100) / 最大副本数       ** 结果必须舍入到最接近的2的N次方幂的值
　　ceph集群中每个pool中的PG总数：

存储池PG总数 = (OSD总数 * 100 / 最大副本数) / 池数
　　获取现有的PG数和PGP数值：

ceph osd pool get data pg_num
ceph osd pool get data pgp_num
13、修改存储池的PG和PGP

ceph osd pool set data pg_num = 1
ceph osd pool set data pgp_num = 1

admin · 发表于 2022-7-26 10:17:54

修复方式 wanted: command to clear 'incomplete' PGs
比如：pg 1.1是incomplete，先对比pg 1.1的主副本之间 pg里面的对象数哪个对象数多就把哪个pg export出来
然后import到对象数少的pg里面然后再mark complete，一定要先export pg备份。
简单方式，数据可能又丢的情况

a. stop the osd that is primary for the incomplete PG;
b. run: ceph-objectstore-tool --data-path ... --journal-path ... --pgid $PGID --op mark-complete
c. start the osd.

保证数据完整性

#1. 查看pg 1.1主副本里面的对象数，假设主本对象数多，则到主本所在osd节点执行
$ ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0/ --journal-path /var/lib/ceph/osd/ceph-0/journal --pgid 1.1 --op export --file /home/pg1.1

#2. 然后将/home/pg1.1 scp到副本所在节点（有多个副本，每个副本都要这么操作），然后到副本所在节点执行
$ ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1/ --journal-path /var/lib/ceph/osd/ceph-1/journal --pgid 1.1 --op import --file /home/pg1.1

#3. 然后再makr complete $ ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1/ --journal-path /var/lib/ceph/osd/ceph-1/journal --pgid 1.1 --op mark-complete

#4. 最后启动osd $ start osd

验证方案

#1. 把状态incomplete的pg，标记为complete。建议操作前，先在测试环境验证，并熟悉ceph-objectstore-tool工具的使用。
PS：使用ceph-objectstore-tool之前需要停止当前操作的osd，否则会报错。

#2. 查询pg 7.123的详细信息，在线使用查询
ceph pg 7.123 query > /export/pg-7.123-query.txt

#3. 每个osd副本节点进行查询
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op info > /export/pg-7.123-info-osd641.txt
如
pg 7.123 OSD 1 存在1,2,3,4,5 object
pg 7.123 OSD 2 存在1,2,3,6 object
pg 7.123 OSD 2 存在1,2,3,7 object

#4. 查询对比数据
#4.1 导出pg的object清单
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op list > /export/pg-7.123-object-list-osd-641.txt

#4.2 查询pg的object数量
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op list|wc -l

#4.3 对比所有副本的object是否一致。
diff -u /export/pg-7.123-object-list-osd-1.txt /export/pg-7.123-object-list-osd-2.txt
比如：pg 7.123是incomplete，对比7.123的所有副本之间pg里面的object数量。
- 如上述情况，diff对比后，每个副本（主从所有副本）的object list是否一致。避免有数据不一致。使用数量最多，并且diff对比后，数量最多的包含所有object的备份。
- 如上述情况，diff对比后，数量是不一致，最多的不包含所有的object，则需要考虑不覆盖导入，再导出。最终使用完整的所有的object进行导入。注：import是需要提前remove pg后进行导入，等于覆盖导入。
- 如上述情况，diff对比后，数据是一致，则使用object数量最多的备份，然后import到object数量少的pg里面然后在所有副本mark complete，一定要先在所有副本的osd节点export pg备份，避免异常后可恢复pg。

#5. 导出备份
查看pg 7.123所有副本里面的object数量，参考上述情况，假设osd-641的object数量多，数据diff对比一致后，则到object数量最多，object list一致的副本osd节点执行（最好是每个副本都进行导出备份,为0也需要导出备份）
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op export --file /export/pg1.414-osd-1.obj

#6. 导入备份
然后将/export/pg1.414-osd-1.obj scp到副本所在节点，在对象少的副本osd节点执行导入。（最好是每个副本都进行导出备份,为0也需要导出备份）
将指定的pg元数据导入到当前pg,导入前需要先删除当前pg（remove之前请先export备份一下pg数据）。需要remove当前pg,否则无法导入，提示已存在。
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-57/ --type bluestore --pgid 7.123 --op remove 需要加–force才可以删除。
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-57/ --type bluestore --pgid 7.123 --op import --file /export/pg1.414-osd-1.obj

#7. 标记pg状态，makr complete（主从所有副本执行）
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-57/ --type bluestore --pgid 7.123

		自动登录	找回密码
密码			注册