upmap的存储池osd坏盘处理问题

写在前面

喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文!

在《坏盘处理时osd为什么不要rm》文章中,松鼠哥对比了多组各种osd处理与数据的情况,有一个细节,那就是如果osd在重建前后要保持pg映射的一致性,那么存储池做均衡使用的是crush-compat模式,同时有读者老铁留言,说当存储池使用了upmap模式做存储池均衡的话,osd重建前后将不能保持相同的pg映射。

因为松鼠哥对存储池做均衡几乎都是推荐使用crush-compat来做,upmap实践不多,所以这种场景没有遇到过,于是有了本篇,对upmap场景下osd坏盘重建前后的pg情况做一个补充。

开始

在相同的环境中,首先使用upmap对存储池做均衡,考虑到一次均衡效果不是很好,连续做了3次:

[root@testnode1 twj]# ceph osd getmap -o osdmap
[root@testnode1 twj]# osdmaptool ./osdmap --upmap afterupmap --upmap-pool songshuge.rgw.buckets.data  --upmap-max 100 --upmap-deviation 1
[root@testnode1 twj]# source aftermap

待pg都分布均衡后,选一个osd,这里选取osd.50,记录它的pg信息,将它destroy并out出集群:

[root@testnode1 twj]# ceph pg ls-by-osd 50 |grep '47'|awk '{print $1}' > osd.50.pg 
[root@testnode1 twj]# systemctl stop ceph-osd@50.service
[root@testnode1 twj]# ceph osd destroy oosd.50 --force
[root@testnode1 twj]# ceph osd out 50

数据完成均衡后,重建该osd并加入集群:

[root@testnode1 twj]# ceph-volume --cluster ceph lvm prepare --bluestore --data xxx  --osd-id 50  --osd-fsid uuidgen --block.db yy --block.wal zz
[root@testnode1 twj]# ceph-volume lvm activate 50 xxx

待数据均衡完毕后,再次记录它的pg信息,并进行对比:

[root@testnode1 twj]# ceph pg ls-by-osd 50 |grep '47'|awk '{print $1}' > osd.50.pg.new
[root@testnode1 twj]# ls -lt
total 4096
-rw-r----- 1 root root    1423 Aug 30 09:42 osd.50.pg
-rw-r----- 1 root root    1507 Aug 30 15:41 osd.50.pg.new
[root@testnode1 twj]# diff osd.50.pg osd.50.pg.new 
73a74
> 47.509
82a84
> 47.5dc
110a113
> 47.841
112a116
> 47.885
115a120
> 47.8c4
119a125
> 47.90d
130a137
> 47.9e5
139a147
> 47.a88
152a161
> 47.b6a
171a181,182
> 47.cc2
> 47.cc8
179a191
> 47.d98

显然不同,相同的操作在此前的crush-compat模式下pg分布是相同的,那么原因是什么呢?

官方对不同模式的说明是这样的:

1.crush-compat. This mode uses the compat weight-set feature (introduced in Luminous) to manage an alternative set of weights for devices in the CRUSH hierarchy. When the balancer is operating in this mode, the normal weights should remain set to the size of the device in order to reflect the target amount of data intended to be stored on the device. The balancer will then optimize the weight-set values, adjusting them up or down in small increments, in order to achieve a distribution that matches the target distribution as closely as possible. (Because PG placement is a pseudorandom process, it is subject to a natural amount of variation; optimizing the weights serves to counteract that natural variation.)

Note that this mode is fully backward compatible with older clients: when an OSD Map and CRUSH map are shared with older clients, Ceph presents the optimized weights as the “real” weights.

The primary limitation of this mode is that the balancer cannot handle multiple CRUSH hierarchies with different placement rules if the subtrees of the hierarchy share any OSDs. (Such sharing of OSDs is not typical and, because of the difficulty of managing the space utilization on the shared OSDs, is generally not recommended.)

2.upmap. In Luminous and later releases, the OSDMap can store explicit mappings for individual OSDs as exceptions to the normal CRUSH placement calculation. These upmap entries provide fine-grained control over the PG mapping. This balancer mode optimizes the placement of individual PGs in order to achieve a balanced distribution. In most cases, the resulting distribution is nearly perfect: that is, there is an equal number of PGs on each OSD (±1 PG, since the total number might not divide evenly).

To use upmap, all clients must be Luminous or newer.

内容有点长,简单来说就是,crush-compat主要参考weight做均衡,对client比较友好,upmap依赖osdmap实现,对client版本有点要求,read和upmap-read是R版本以后的功能,暂且不说。

从实现来看,crush-compat会将均衡的信息写入到crushmap中,就在crushmap的最后面:

# choose_args
choose_args 18446744073709551615 {
  {
    bucket_id -1
    weight_set [
      [ 7.953 8.055 7.992 ]
    ]
  }
......

当我们处理osd不rm时,这个信息是不会被破坏的,也就能够让osd保持pg的映射一致性,而upmap方式则是将pg均衡信息写入到了osdmap中,经过测试,destroy osd就会直接导致这些信息的变化:

在destroy之前,定位到osdmap版本为263625,osdmap中的pg upmap信息:
[root@testnode1 ceph]# osdmaptool --print osdmap.263625 > qian.osd.upmap
osdmaptool: osdmap file 'osdmap.263625'
[root@testnode1 ceph]# more qian.osd.upmap 
osd.311 up   in  weight 1 up_from 257374 up_thru 261950 down_at 257366 last_clean_interval [257354,257373) [v2:192.168.1.1:10025/1265298,v1:192.168.1.1:10028/1265298] [v2:192.168.1.1:10048/2265298,v1:192.168.1.1:10049/2265298] exists,up f7f47c72-4a9d-4db9-9550-c555de928792

pg_upmap_items 47.3a [40,31]
pg_upmap_items 47.50 [58,51]
pg_upmap_items 47.57 [10,1]
......

可以看到,osdmap的最后就是upmap的信息,那么destroy之后,osdmap的版本必然是变化的,不过upmap信息也会跟着变化:

在destroy之后,定位到最新osdmap版本为264472,osdmap中的pg upmap信息:
[root@testnode1 ceph]# osdmaptool --print osdmap.264472 > hou.osd.upmap
osdmaptool: osdmap file 'osdmap.264472'
[root@testnode1 ceph]# more hou.osd.upmap 
osd.311 up   in  weight 1 up_from 257374 up_thru 261950 down_at 257366 last_clean_interval [257354,257373) [v2:192.168.1.1:10025/1265298,v1:192.168.1.1:10028/1265298] [v2:192.168.1.1:10048/2265298,v1:192.168.1.1:10049/2265298] exists,up f7f47c72-4a9d-4db9-9550-c555de928792

pg_upmap_items 47.3a [40,31]
pg_upmap_items 47.50 [58,51]
pg_upmap_items 47.57 [10,1]
......

进行一个对比
[root@testnode1 ceph]# grep 'pg_upmap_items' qian.osd.upmap > qian1
[root@testnode1 ceph]# grep 'pg_upmap_items' hou.osd.upmap > hou2
[root@testnode1 ceph]# wc -l hou2 
272 hou2
[root@testnode1 ceph]# wc -l qian1 
281 qian1

确实是变化了。

那么就要讨论一个问题了:处理osd前后,pg保持相同的映射有什么用?

从实际的使用来看,如果pg能够在坏盘前后,不rm的情况下保持相同的pg映射,好处还是挺多的:

  • 首先,如果能快速换盘,不会产生misplace的数据。
  • 其次,换上新盘重建osd之后,存储池总体的均衡度与原来保持一致,无需再做均衡。
  • 再者,对追踪某些pg问题保留线索,尤其是非常棘手的问题,松鼠哥之前有遇到过类似的。
  • 最后,为开发新技术和新方案提供了很好的思路,这因为过于先进,就不展开说了。

总之,松鼠哥推荐使用crush-compat来对集群做pg的均衡,效果也不错,兼容性也好。

总结

本来没有多想其他可能的均衡方式会不会带来不一样的场景,用crush-compat的场景很多,但是阅读了松鼠哥文章的老铁乐于在评论区提出看法,松鼠哥非常欢迎这种方式,能多学习新知识新技术~

喜欢ceph的话欢迎关注 奋斗的cepher 微信公众号阅读更多好文!

<think>我们正在讨论Ceph集群中OSD的详细信息,特别是`cephosddump`命令的使用方法和输出解析。根据引用[1]中提到的命令,`cephosddump`是用于查看OSD状态的命令之一,它会输出OSD的详细信息。接下来,我将详细解释该命令的使用方法以及如何解析其输出。###1.命令使用方法在Ceph集群的任何管理节点上,以具有相应权限的用户(通常是ceph用户)执行以下命令:```bashceph osd dump```###2.输出解析`ceph osd dump`命令的输出包含多个部分,我们将逐一解析关键信息。####输出示例(简化): ```epoch1234fsid12345678-90ab-cdef-1234-567890abcdefcreated2023-01-01T00:00:00.000000+0000modified2023-01-02T00:00:00.000000+0000flagssortbitwise,recovery_deletes,purged_snapdirscluster_snapshotpool1'rbd'replicated size3min_size2crush_rule0 object_hash rjenkinspg_num128pgp_num128 autoscale_modewarnlast_change123owner0flagshashpspoolstripe_width0application rbdpool2'cephfs_data'replicated size3min_size2crush_rule0 object_hash rjenkinspg_num256pgp_num256 autoscale_modeonlast_change124owner0 flagshashpspool stripe_width0 applicationcephfsmax_osd10osd.0upinweight1.000up_from100up_thru100down_at0last_clean_interval [0,0)10.0.0.1:6800/1000(root)0:0:0-0osd.1upinweight1.000 up_from101 up_thru101down_at0last_clean_interval [0,0)10.0.0.2:6800/1000 (root)0:0:0-0...```####关键字段解析:- **epoch**:当前OSD map的版本号,每次OSD map有变化递增。 -**fsid**:集群的唯一标识符。- **created/modified**:创建和最后修改间。 -**flags**:集群标志,例如`sortbitwise`表示使用位排序,`recovery_deletes`表示在恢复删除对象等。- **pool**:存储池信息,包括:-池ID和名称(如`pool1 'rbd'`)-类型(如`replicated`)-副本数(`size`)-最小副本数(`min_size`)-CRUSH规则ID(`crush_rule`)-PG数量(`pg_num`)和PGP数量(`pgp_num`)-自动扩展模式(`autoscale_mode`)-应用类型(`application`,如rbd、cephfs)- **max_osd**:集群中最大OSD编号(从0开始,所以实际OSD数量为max_osd+1)。- **osd.x**:每个OSD的详细信息,包括:-**状态**:`up`表示OSD进程正在运行,`in`表示OSD在集群中(可以被映射数据),`down`和`out`表示异常。- **权重**:`weight`表示CRUSH算法中该OSD的权重,影响数据分布。-**间信息**:`up_from`(最近一次启动的间点),`up_thru`(OSD被认为可用的间点),`down_at`(OSD宕机的间点)。-**IP地址和端口**:OSD服务地址。- **位置信息**:在CRUSH map中的位置,例如`(root)0:0:0-0`表示在默认根下。 ###3.实际应用通过`cephosddump`命令,管理员可以获取OSD的详细配置和状态,用于:-检查OSD是否正常(`up`且`in`)-查看存储池配置-诊断集群问题(如OSD宕机、权重变化等)###注意事项-输出信息量较大,建议配合`grep`等命令过滤信息,例如`ceph osd dump| grep-A10"osd.0"`查看osd.0的详细信息。-输出中的间信息是epoch间(即间戳),可使用`date-d@间戳`转换为可读格式。 §§相关问题§§1.如何查看Ceph集群中某个特定OSD的详细信息?2.`ceph osd dump`和`ceph osd tree`命令有什么区别?3.当OSD状态为`down`,应该如何处理?</think>### `ceph osd dump` 命令详解 `ceph osd dump` 是 Ceph 集群中用于获取 OSD(对象存储守护进程)详细信息的核心命令,它以结构化格式输出 OSD 的完整配置和状态数据[^1]。 --- #### **命令语法** ```bash ceph osd dump [--format <format>] # 格式可选 json、json-pretty、plain ``` 示例: ```bash ceph osd dump --format json-pretty # 以易读的 JSON 格式输出 ``` --- #### **关键输出解析** 输出包含以下核心部分(以典型字段为例): 1. **全局信息** ```json "epoch": 123, // OSD map 版本号(集群配置变更递增) "fsid": "a1b2c3d4-...", // 集群唯一标识 "created": "2023-10-01T12:00:00Z", // 初始创建间 "modified": "2023-10-05T14:30:00Z" // 最后修改间 ``` 2. **OSD 状态列表** ```json "osds": [ { "osd": 0, // OSD ID "up": 1, // 运行状态 (1=up, 0=down) "in": 1, // 集群状态 (1=in, 0=out) "weight": 1.0, // CRUSH 权重(数据分布比例) "public_addr": "10.0.0.1:6800", // 客户端通信地址 "cluster_addr": "10.0.0.1:6801", // 集群内部通信地址 "state": ["exists", "up"], // 状态标签 "last_clean_begin": 162000000, // 最后一次清理开始间戳 "last_clean_end": 162000360 // 清理结束间戳 }, ... // 其他 OSD 条目 ] ``` 3. **存储池配置** ```json "pools": [ { "pool": 1, // 存储池 ID "pool_name": "rbd", // 存储池名称 "type": 1, // 类型 (1=replicated, 3=erasure) "size": 3, // 副本数 "crush_rule": 0, // 使用的 CRUSH 规则 ID "pg_num": 128 // 归置组 (PG) 数量 } ] ``` 4. **CRUSH 规则** ```json "crush_rules": [ { "rule_id": 0, // 规则 ID "rule_name": "replicated_rule", "steps": [ // 数据分布逻辑 {"op": "take", "item": -1}, {"op": "chooseleaf", "num": 0, "type": "host"} ] } ] ``` --- #### **关键状态解读** - **`up`/`in` 组合状态**: - `up=1, in=1`:OSD 运行正常且数据可读写 ✅ - `up=1, in=0`:OSD 运行中但被踢出集群(需检查 `ceph osd in <id>`) ⚠️ - `up=0, in=1`:OSD 宕机但仍在集群中(需重启或替换) ❌ - **权重异常**: - `weight=0`:OSD 不存储数据(通常因故障手动设置) - 权重不均:导致数据分布倾斜(通过 `ceph osd reweight` 调整) - **间戳诊断**: - `last_clean_*` 异常:可能存在数据清理积压 - 长间无更新:可能 OSD 进程僵死 --- #### **实战应用场景** 1. **故障排查** ```bash ceph osd dump | grep -A 5 "osd.5" # 聚焦特定 OSD 状态 ``` 2. **配置审计** ```bash ceph osd dump | grep "size" # 检查所有存储池副本数 ``` 3. **自动化脚本** ```bash ceph osd dump -f json | jq '.osds[] | select(.up==0)' # 提取所有宕机 OSD ``` > ⚠️ **注意**:输出可能包含数百行,建议配合 `grep`/`jq` 过滤关键信息。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

奋斗的松鼠

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值