浅谈ceph之数据均衡

ceph之数据均衡

在loongarch架构的3c5000龙芯服务器上使用ceph集群时，观察到所有节点的osd数据不均衡问题，根据此现象查找解决问题。

查看集群状态

lsblk

[root@controller1 ~]# lsblk
NAME                                                                                                    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                                                                                                       8:0    0 238.5G  0 disk 
├─sda1                                                                                                    8:1    0     3G  0 part /boot
├─sda2                                                                                                    8:2    0    16G  0 part [SWAP]
├─sda3                                                                                                    8:3    0  39.1G  0 part /
└─sda4                                                                                                    8:4    0 180.4G  0 part 
  └─ceph--df8bc3d5--827e--4ff4--91a2--ab47f147bc49-osd--block--57378063--d5b3--4528--9a48--905fb4c3f931 253:1    0 180.4G  0 lvm  
sdb                                                                                                       8:16   0 238.5G  0 disk 
├─sdb1                                                                                                    8:17   0     3G  0 part 
├─sdb2                                                                                                    8:18   0 172.5G  0 part 
├─sdb3                                                                                                    8:19   0    47G  0 part 
└─sdb4                                                                                                    8:20   0    16G  0 part 
  └─ceph--f786b0f8--7ae1--437d--8281--5011f74e2cc1-osd--block--2dceb423--a93c--4022--9f4d--ec9be3e2eebc 253:0    0    16G  0 lvm  

ceph osd df

ceph osd df 命令用于显示 Ceph 存储集群中每个 OSD（对象存储守护进程）的磁盘使用情况和容量信息。这个命令可以帮助您监视集群中不同 OSD 的空间利用情况，以便及时进行容量规划和故障排查。

可以观察到osd.0的使用率高达94%而其他的却只有不到40%甚至有5%
第二天osd.0超过95%，根据官方文档，集群中出现一个超过95%的osd时，集群将不再接收写入数据。

[root@controller1 ~]# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE    RAW USE DATA    OMAP    META     AVAIL   %USE  VAR  PGS STATUS 
 0   ssd 0.01559  1.00000 180 GiB 171 GiB 5.2 GiB   8 KiB 1024 MiB 9.8 GiB 94.55 1.99 221     up 
 1   ssd 0.01559  1.00000  16 GiB 6.2 GiB 5.2 GiB 160 KiB 1024 MiB 9.8 GiB 38.86 0.82 195     up 
 2   ssd 0.17569  1.00000 180 GiB  10 GiB 9.3 GiB  94 KiB 1024 MiB 170 GiB  5.71 0.12 385     up 
 3   ssd 0.01559  1.00000  16 GiB 2.1 GiB 1.1 GiB     0 B    1 GiB  14 GiB 13.14 0.28  31     up 
 4   ssd 0.01559  1.00000  16 GiB 5.4 GiB 4.4 GiB 117 KiB 1024 MiB  11 GiB 33.77 0.71 192     up 
 5   ssd 0.01559  1.00000  16 GiB 7.0 GiB 6.0 GiB 112 KiB 1024 MiB 9.0 GiB 43.64 0.92 224     up 
                    TOTAL 424 GiB 202 GiB  31 GiB 493 KiB  6.0 GiB 223 GiB 47.50                 
MIN/MAX VAR: 0.12/1.99  STDDEV: 30.05

• ID：每个 OSD 的唯一标识符。
• CLASS：OSD 的类别，通常表示存储介质的类型（例如，ssd 表示固态硬盘）。
• WEIGHT：OSD 的权重，影响数据分布和负载均衡。
• REWEIGHT：OSD 的重新权重，如果 OSD 处于维护模式，可以手动调整该值。
• SIZE：OSD 的总容量。
• USE：OSD 已经使用的容量。
• AVAIL：OSD 可用的容量。
• %USE：已使用容量的百分比。
• VAR：方差，表示数据在 OSD 之间的分布均衡度。
• PGS：关联到该 OSD 的 PG（Placement Group）数量。

针对这种情况查阅资料，调整osd.0的权重变小让数据像其他设备迁移。

ceph osd crush rewight 0 0.001 

ID CLASS WEIGHT  REWEIGHT SIZE    RAW USE DATA    OMAP   META     AVAIL   %USE  VAR  PGS STATUS 
 0   ssd 0.00099  1.00000 180 GiB 166 GiB 832 MiB  8 KiB 1024 MiB  14 GiB 92.14 1.95  35     up 
 1   ssd 0.01559  1.00000  16 GiB 8.6 GiB 7.6 GiB  8 KiB 1024 MiB 7.4 GiB 53.67 1.14 382     up 
 2   ssd 0.17569  1.00000 180 GiB 8.5 GiB 7.5 GiB  8 KiB 1024 MiB 171 GiB  4.75 0.10 382     up 
 3   ssd 0.01559  1.00000  16 GiB 1.9 GiB 872 MiB  8 KiB 1024 MiB  14 GiB 11.57 0.25  34     up 
 4   ssd 0.01559        0     0 B     0 B     0 B    0 B      0 B     0 B     0    0   0   down 
 5   ssd 0.01559        0     0 B     0 B     0 B    0 B      0 B     0 B     0    0   0   down 
                    TOTAL 392 GiB 185 GiB  17 GiB 32 KiB  4.0 GiB 207 GiB 47.21                 
MIN/MAX VAR: 0.10/1.95  STDDEV: 35.82

发现调整让其变小只能让小幅度的让使用率变小，并不能解决问题，使用ceph -s命令显示如下

[root@controller1 dev]# ceph -s
  cluster:
    id:     b6793217-68bd-4f06-8123-f03be36d97fe
    health: HEALTH_WARN
            1 backfillfull osd(s)
            4 pool(s) backfillfull
            Reduced data availability: 1 pg inactive
            Low space hindering backfill (add storage if this doesn't resolve itself): 4 pgs backfill_toofull
            Degraded data redundancy: 992/3279 objects degraded (30.253%), 165 pgs degraded, 414 pgs undersized
            3 pools have too many placement groups
            1/3 mons down, quorum controller1,controller2
 
  services:
    mon: 3 daemons, quorum controller1,controller2 (age 73m), out of quorum: controller3
    mgr: controller1(active, since 44h)
    osd: 6 osds: 4 up (since 72m), 4 in (since 62m); 37 remapped pgs
 
  data:
    pools:   4 pools, 416 pgs
    objects: 1.09k objects, 8.4 GiB
    usage:   185 GiB used, 207 GiB / 392 GiB avail
    pgs:     0.240% pgs not active
             992/3279 objects degraded (30.253%)
             204/3279 objects misplaced (6.221%)
             214 active+undersized
             164 active+undersized+degraded
             31  active+undersized+remapped
             3   active+undersized+remapped+backfill_toofull
             2   active+clean+remapped
             1   undersized+peered
             1   active+undersized+degraded+remapped+backfill_toofull
 
  io:
    client:   0 B/s rd, 0 B/s wr, 0 op/s rd, 0 op/s wr

很困惑为何osd0和osd4的使用率这么高，于是停掉这两个服务，让osd均衡一晚上发现其余四个osd均衡正常，并无高额的数据，于是准备重建osd0和osd4,先重建一个osd0,发现有如下变化

[root@controller3 ~]# ceph -s
  cluster:
    id:     b6793217-68bd-4f06-8123-f03be36d97fe
    health: HEALTH_WARN
            3 pools have too many placement groups
 
  services:
    mon: 3 daemons, quorum controller1,controller2,controller3 (age 5h)
    mgr: controller1(active, since 12m)
    osd: 6 osds: 5 up (since 5h), 5 in (since 5h); 76 remapped pgs
 
  data:
    pools:   4 pools, 400 pgs
    objects: 1.13k objects, 8.6 GiB
    usage:   31 GiB used, 377 GiB / 408 GiB avail
    pgs:     203/3390 objects misplaced (5.988%)
             324 active+clean
             76  active+clean+remapped
 
  io:
    client:   4.5 KiB/s rd, 5 op/s rd, 0 op/s wr

[root@controller3 ~]# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE    RAW USE DATA    OMAP   META     AVAIL   %USE  VAR  PGS STATUS 
 0   ssd 0.17619  1.00000 180 GiB 9.1 GiB 8.1 GiB    0 B    1 GiB 171 GiB  5.06 0.67 375     up 
 1   ssd 0.01599  1.00000  16 GiB 2.6 GiB 1.6 GiB 16 KiB 1024 MiB  13 GiB 16.22 2.14  52     up 
 2   ssd 0.17168  1.00000 180 GiB 8.8 GiB 7.8 GiB 16 KiB 1024 MiB 171 GiB  4.87 0.64 373     up 
 3   ssd 0.01599  1.00000  16 GiB 2.1 GiB 1.1 GiB  8 KiB 1024 MiB  14 GiB 13.39 1.77  44     up 
 4   ssd 0.17168        0     0 B     0 B     0 B    0 B      0 B     0 B     0    0   0   down 
 5   ssd 0.01599  1.00000  16 GiB 8.3 GiB 7.3 GiB  8 KiB 1024 MiB 7.7 GiB 51.72 6.84 356     up 
                    TOTAL 408 GiB  31 GiB  26 GiB 49 KiB  5.0 GiB 377 GiB  7.57                 

查询资料 得知可能与osd分布的不均匀有关系，一般部署osd时要保证节点间的osd分布是一致的，所以再重新新建osd4之后集群恢复到正常状态。