ceph-deploy osd扩容和换盘

指尖二进制 • 1 年前 • 943 次点击 • CEPH

[TOC]

ceph扩容分为两种，一种横向扩容一种纵向扩容。
横向扩容：增加节点：scale out --增加更多的节点
纵向扩容：在单节点上增加更多的磁盘：scale up

1.osd纵向扩容

查看信息

[root@controller ~]# cd ceph-deploy/
[root@controller ceph-deploy]# ceph-deploy disk list controller

要更换磁盘（删除其分区表）以准备与Ceph一起使用，请执行以下操作：

ceph-deploy disk zap {osd-server-name} {disk-name}
ceph-deploy disk zap osdserver1 /dev/sdb /dev/sdc

如果有数据可以运行zap清除

[root@controller ceph-deploy]# ceph-deploy disk zap controller /dev/sde

增加osd

[root@controller ceph-deploy]# ceph-deploy --overwrite-conf osd create controller --data /dev/sde

2.数据rebalancing重分布

在扩容ceph往里面加osd，他会去做数据的分布叫rebalancing。
什么叫rebalancing？
当集群中目前有两个osd，上面分别有10个PG，object分别是放到pg里面。扩容之后新增加了一个osd，会把之前的数据移动一部分到新增加的osd上。让整个集群看起来相对均衡。在扩容的过程中移动的是pg并不是对象，假设移动对象的情况下涉及到的数据量大计算复杂。所以移动pg，pg是有限的。

为什么移动pg？
是因为加入了osd，osd自动把状态上报给monitor，monitor能知道cluster map也就是osd map发生了变动，这个时候就会触发rebalancing，确保osd上面的pg能够平滑移动到新的osd节上。

所以在实际的生产环境中，pg里面存储了很多数据，这个时候移动可能会涉及到性能。
假设一次性加入很多osd进来，那么之前很多pg都需要移动，而pg中存储了大量的数据，此时rebalancing业务可能受影响，所以在扩容的过程中防止业务受影响一次不要扩容太多osd，一个一个慢慢往上加。

[root@controller ceph-deploy]# ceph -s
  cluster:
    id:     73c4cfc1-af4c-4be5-8ad4-fb0ff78b2efc
    health: HEALTH_WARN
            Degraded data redundancy: 261/2388 objects degraded (10.930%), 33 pgs degraded, 6 pgs undersized

  services:
    mon: 3 daemons, quorum controller,compute01,compute02 (age 34m)
    mgr: controller(active, since 46m), standbys: compute01, compute02
    osd: 10 osds: 10 up (since 75s), 10 in (since 75s); 7 remapped pgs

  data:
    pools:   3 pools, 384 pgs
    objects: 796 objects, 3.3 GiB
    usage:   20 GiB used, 480 GiB / 500 GiB avail
    pgs:     261/2388 objects degraded (10.930%)
             33/2388 objects misplaced (1.382%)
             348 active+clean
             28  active+recovery_wait+degraded
             5   active+recovery_wait+undersized+degraded+remapped
             2   active+recovery_wait+remapped
             1   active+recovering+undersized+remapped

  io:
    recovery: 8.8 MiB/s, 4 objects/s

  progress:
    Rebalancing after osd.9 marked in
      [===================...........]

扩容

[root@controller ceph-deploy]# ceph-deploy osd create compute01 --data /dev/sde
[root@controller ceph-deploy]# ceph-deploy osd create compute02 --data /dev/sde

扩容完了立刻实时监测，查看状态可以查看到rebalancing数据重分布过程

[root@controller ceph-deploy]# watch -n1 'ceph -s'

3.临时关闭rebalancing重分布

每个osd最多有一个线程在做数据的填充，值调的同步的时候快，消耗性能也多。

[root@controller ~]# ceph --admin-daemon /var/run/ceph/ceph-mon.controller.asok config show |grep max_backfills
    "osd_max_backfills": "1",

注意ceph网络
在osd进行扩容数据进行重分布走的就是cluster_network网络，客户端连接是public_network网络。
生产中一定要分开，cluster_network使用万兆网卡减少之间的影响。因为如果在扩容osd时rebalancing流量较大此时就会影响到业务了。

[root@controller ~]# cat /etc/ceph/ceph.conf
public_network = 10.0.0.0/24
cluster_network = 172.16.0.0/24

如果两个网络就是在一起的，这个时候也在扩容，已经影响到线上业务了。
这个时候可以把rebalancing暂停了。

[root@controller ~]# ceph -h|grep reba
 norebalance|norecover|noscrub|nodeep-scrub|notieragent|
 norebalance|norecover|noscrub|nodeep-scrub|notieragent|
[root@controller ~]# ceph osd set norebalance #关闭标志位
norebalance is set

[root@controller ~]# ceph -s
  cluster:
    id:     236d7731-b1ce-4340-a218-0c2f1eecf61a
    health: HEALTH_WARN
            norebalance flag(s) set #这个就是用来做数据分布的

用来做数据填充的也需要关闭掉nobackfill

[root@controller ~]# ceph osd set nobackfill
nobackfill is set
[root@controller ~]# ceph -s
  cluster:
    id:     236d7731-b1ce-4340-a218-0c2f1eecf61a
    health: HEALTH_WARN
            nobackfill,norebalance flag(s) set
如果设置了nobackfill,norebalance标志位，如果有osd正在同步的情况下会把这个任务暂停掉，业务流量就能访问正常了。

取消nobackfill,norebalance

[root@controller ~]# ceph osd unset nobackfill
nobackfill is unset
[root@controller ~]# ceph osd unset norebalance
norebalance is unset
[root@controller ~]# ceph -s
  cluster:
    id:     236d7731-b1ce-4340-a218-0c2f1eecf61a
    health: HEALTH_OK

4.osd坏盘更换

可以查看到坏的磁盘信息

[root@controller ~]# dmesg

查看数据延迟（当硬盘磁道快坏了的时候可以查看延迟）

[root@controller ~]# ceph osd perf
osd commit_latency(ms) apply_latency(ms)
  5                  0                 0
  4                  0                 0
  0                  0                 0
  1                  0                 0
  2                  0                 0
  3                  0                 0

停止坏盘的osd

[root@controller ~]# systemctl stop ceph-osd@9

当踢掉ceph-osd@9时，数据就会做一个重分布的过程，不会立即同步，需要等大概10分钟左右才会触发rebalance动作。这个时候一直ceph -s数据都没有动。

[root@controller ~]# ceph -s
  cluster:
    id:     73c4cfc1-af4c-4be5-8ad4-fb0ff78b2efc
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 237/2388 objects degraded (9.925%), 81 pgs degraded, 97 pgs undersized

  services:
    mon: 3 daemons, quorum controller,compute01,compute02 (age 7m)
    mgr: controller(active, since 2d), standbys: compute01, compute02
    osd: 10 osds: 9 up (since 101s), 10 in (since 37h)

  data:
    pools:   3 pools, 384 pgs
    objects: 796 objects, 3.3 GiB
    usage:   20 GiB used, 480 GiB / 500 GiB avail
    pgs:     237/2388 objects degraded (9.925%) #此时已经237pg数受影响了，但是还没有触发rebalance动作
             287 active+clean
             81  active+undersized+degraded
             16  active+undersized

查看是否同步完成

[root@controller ceph-deploy]# ceph -s
  cluster:
    id:     73c4cfc1-af4c-4be5-8ad4-fb0ff78b2efc
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum controller,compute01,compute02 (age 2h)
    mgr: controller(active, since 2d), standbys: compute01, compute02
    osd: 10 osds: 9 up (since 43m), 9 in (since 33m)

  data:
    pools:   3 pools, 384 pgs
    objects: 796 objects, 3.3 GiB
    usage:   19 GiB used, 431 GiB / 450 GiB avail
    pgs:     384 active+clean

  io:
    client:   8.2 KiB/s rd, 9 op/s rd, 0 op/s wr

等待同步完成之后进行删除osd，在osd-map里面剔除掉osd.9

[root@controller ~]# ceph osd tree
 9   hdd 0.04880         osd.9         down  1.00000 1.00000
[root@controller ~]# ceph osd out osd.9
marked out osd.9. 

[root@controller ~]# ceph osd tree|grep osd.9
 9   hdd 0.04880         osd.9         down        0 1.00000 #权重已经变为0

删除crush map

[root@controller ~]# ceph osd crush dump|more
[root@controller ~]# ceph osd crush rm osd.9
removed item id 9 name 'osd.9' from crush map
[root@controller ~]# ceph osd crush dump|more #再次查看就没有osd.9了

删除osd

[root@controller ~]# ceph osd rm osd.9
removed osd.9
[root@controller ~]# ceph osd tree
ID CLASS WEIGHT  TYPE NAME           STATUS REWEIGHT PRI-AFF
-1       0.43918 root default
-5       0.14639     host compute01
 3   hdd 0.04880         osd.3           up  1.00000 1.00000
 4   hdd 0.04880         osd.4           up  1.00000 1.00000
 5   hdd 0.04880         osd.5           up  1.00000 1.00000
-7       0.14639     host compute02
 6   hdd 0.04880         osd.6           up  1.00000 1.00000
 7   hdd 0.04880         osd.7           up  1.00000 1.00000
 8   hdd 0.04880         osd.8           up  1.00000 1.00000
-3       0.14639     host controller
 0   hdd 0.04880         osd.0           up  1.00000 1.00000
 1   hdd 0.04880         osd.1           up  1.00000 1.00000
 2   hdd 0.04880         osd.2           up  1.00000 1.00000

删除认证信息

[root@controller ~]# ceph auth list
[root@controller ~]# ceph auth rm osd.9 #删除对应认证信息
updated

删除osd过程
删除之前做一个ceph osd out动作，做数据的重分布，安全
1.cursh map
2.auth
3.osd

5.数据一致性检查

三副本：

正常的一份数据会存储3份，怎么确保三份数据时一致的呢？ceph会定期检查三份数据内容是否一致，检查的方式有两种。

一种叫scrub轻量的一致性检查，轻量的一致性检查：主要对比object的元数据的内容是否一样（文件名、文件属性、大小），如果不一样就会从主节点的pg里面复制一份

一种叫deeper scrubbing深度的一致性检查：主要对比数据的内容（数据是否一样）（缺散检查）把两个缺散进行对比看数据是否一样。这个动作对于ceph集群大的时候比如上百T是消耗非常大的，非常的的一个负荷。所以这个检查间隔比较长通常每周做一次。

对于轻量的scrub来说类似于fsck检查存储中的内容，防止磁盘坏道、数据不一致。轻量的检查就能够检查出来，默认每天会自动检查。

针对于pg级别的（scrub轻量级）

[root@controller ~]# ceph -h|grep scrub
[root@controller ~]# ceph pg dump #拿到pg id
 2.7c
[root@controller ~]# ceph pg scrub 2.7c
instructing pg 2.7c on osd.2 to scrub
[root@controller ~]# ceph -s #动作很快基本看不到任何信息

深度检查（将pg数据取出来进行对比）如果pg数据较多会耗费内存资源，因为需要把数据取出来在进行hash

[root@controller ~]# ceph pg deep-scrub 2.7c
instructing pg 2.7c on osd.2 to deep-scrub
[root@controller ~]# ceph -s
  cluster:
    id:     7580ffaa-ed48-435e-b49a-1bb46de61d1d
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum controller,compute01,compute02 (age 95m)
    mgr: controller(active, since 95m), standbys: compute01, compute02
    mds: cephfs-demo:1 {0=controller=up:active} 2 up:standby
    osd: 6 osds: 6 up (since 5m), 6 in (since 5m)
    rgw: 1 daemon active (controller)

  data:
    pools:   8 pools, 256 pgs
    objects: 4.64k objects, 17 GiB
    usage:   49 GiB used, 251 GiB / 300 GiB avail
    pgs:     256 active+clean

循环深度检查pg

[root@controller ~]# for i in `ceph pg dump |grep "active+clean"|awk '{print $1}'`;do ceph pg deep-scrub ${i};done
[root@controller ceph-deploy]# ceph -s
  cluster:
    id:     73c4cfc1-af4c-4be5-8ad4-fb0ff78b2efc
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum controller,compute01,compute02 (age 2h)
    mgr: controller(active, since 2d), standbys: compute01, compute02
    osd: 9 osds: 9 up (since 77m), 9 in (since 67m)

  data:
    pools:   3 pools, 384 pgs
    objects: 796 objects, 3.3 GiB
    usage:   19 GiB used, 431 GiB / 450 GiB avail
    pgs:     384 active+clean
             1   active+clean+scrubbing+deep    #关注