三种增删osd的方法数据量迁移大小

本文通过实验对比了三种不同的Ceph OSD替换方法,详细分析了每种方法下的PG迁移数量,旨在寻找最佳的替换策略,以减少数据迁移量。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、前言

之前有写过一篇删除OSD的正确方式,里面只是简单的讲了下删除的方式怎样能减少迁移量,本篇属于一个扩展,讲述了 Ceph 运维当中经常出现的坏盘提换盘的步骤的优化

基础环境两台主机每台主机8个 OSD,一共 16 个 OSD,副本设置为2,PG 数设置为800,计算下来平均每个 OSD 上的 P G数目为100个,本篇将通过数据来分析不同的处理方法的差别

开始测试前先把环境设置为 noout,然后通过停止 OSD 来模拟 OSD 出现了异常,之后进行不同处理方法

二、测试三种方法

方法一:首先 out 一个 OSD,然后剔除 OSD,然后增加 OSD

  1. 停止指定 OSD 进程
  2. out 指定 OSD
  3. crush remove 指定 OSD
  4. 增加一个新的 OSD

一般生产环境会设置为 noout,当然不设置也可以,那就交给程序去控制节点的 out,默认是在进程停止后的五分钟,总之这个地方如果有 out 触发,不管是人为触发,还是自动触发数据流是一定的,我们这里为了便于测试,使用的是人为触发,上面提到的预制环境就是设置的 noout

开始测试前获取最原始的分布

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > pg1.txt

获取当前的 PG 分布,保存到文件pg1.txt,这个 PG 分布记录是 PG 所在的 OSD,记录下来,方便后面进行比较,从而得出需要迁移的数据

停止指定的 OSD 进程
[root@lab8106 ~]# systemctl stop ceph-osd@15

停止进程并不会触发迁移,只会引起 PG 状态的变化,比如原来主 PG 在停止的 OSD 上,那么停止掉 OSD 以后,原来的副本的那个 PG 就会角色升级为主 PG 了

out 掉一个 OSD
[root@lab8106 ~]# ceph osd out 15

在触发 out 以前,当前的 PG 状态应该有 active+undersized+degraded,触发 out 以后,所有的 PG 的状态应该会慢慢变成 active+clean,等待集群正常后,再次查询当前的 PG 分布状态

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > pg2.txt

保存当前的 PG 分布为pg2.txt
比较 out 前后的 PG 的变化情况,下面是比较具体的变化情况,只列出变化的部分

[root@lab8106 ~]# diff -y -W 100 pg1.txt pg2.txt  --suppress-common-lines

这里我们关心的是变动的数目,只统计变动的 PG 的数目

[root@lab8106 ~]# diff -y -W 100 pg1.txt pg2.txt  --suppress-common-lines|wc -l
102

第一次 out 以后有102个 PG 的变动,这个数字记住,后面的统计会用到

从 crush 里面删除 OSD
[root@lab8106 ~]# ceph osd crush remove osd.15

crush 删除以后同样会触发迁移,等待 PG 的均衡,也就是全部变成 active+clean 状态

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > pg3.txt

获取当前的 PG 分布的状态
现在来比较 crush remove 前后的 PG 变动

[root@lab8106 ~]# diff -y -W 100 pg2.txt pg3.txt  --suppress-common-lines|wc -l
137

我们重新加上新的 OSD

[root@lab8106 ~]# ceph-deploy osd prepare lab8107:/dev/sdi
[root@lab8106 ~]# ceph-deploy osd activate lab8107:/dev/sdi1

加完以后统计当前的新的 PG 状态

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > pg4.txt

比较前后的变化

[root@lab8106 ~]# diff -y -W 100 pg3.txt pg4.txt  --suppress-common-lines|wc -l
167

整个替换流程完毕,统计上面的 PG 总的变动

102 +137 +167 = 406

也就是按这个方法的变动为406个 PG,因为是只有双主机,里面可能存在某些放大问题,这里不做深入的讨论,因为我的三组测试环境都是一样的情况,只做横向比较,原理相通,这里是用数据来分析出差别

方法二:先crush reweight 0 ,然后out,然后再增加osd

首先恢复环境为测试前的环境

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 2pg1.txt

记录最原始的 PG 分布情况

crush reweight 指定OSD
[root@lab8106 ~]# ceph osd crush reweight osd.16 0
reweighted item id 16 name 'osd.16' to 0 in crush map

等待平衡了以后记录当前的 PG 分布状态

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 2pg2.txt
dumped pgs in format plain

比较前后的变动

[root@lab8106 ~]# diff -y -W 100 2pg1.txt 2pg2.txt  --suppress-common-lines|wc -l
166

crush remove 指定 OSD
[root@lab8106 ~]# ceph osd crush remove osd.16
removed item id 16 name 'osd.16' from crush map

这个地方因为上面 crush 已经是0了所以删除也不会引起 PG 变动
然后直接 ceph osd rm osd.16 同样没有 PG 变动

增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi
[root@lab8106 ~]#ceph-deploy osd activate lab8107:/dev/sdi1

等待平衡以后获取当前的 PG 分布

[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 2pg3.txt

来比较前后的变化

[root@lab8106 ~]# diff -y -W 100 2pg2.txt 2pg3.txt --suppress-common-lines|wc -l
159

总的 PG 变动为

166+159=325

方法3:开始做norebalance,然后做crush remove,然后做add

恢复环境为初始环境,然后获取当前的 PG 分布

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 3pg1.txt
dumped pgs in format plain

给集群做多种标记,防止迁移

设置为 norebalance,nobackfill,norecover,后面是有地方会解除这些设置的

[root@lab8106 ~]# ceph osd set norebalance
set norebalance
[root@lab8106 ~]# ceph osd set nobackfill
set nobackfill
[root@lab8106 ~]# ceph osd set norecover
set norecover

crush reweight 指定 OSD
[root@lab8106 ~]# ceph osd crush reweight osd.15 0
reweighted item id 15 name 'osd.15' to 0 in crush map

这个地方因为已经做了上面的标记,所以只会出现状态变化,而没有真正的迁移,我们也先统计一下

[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 3pg2.txt
[root@lab8106 ~]# diff -y -W 100 3pg1.txt 3pg2.txt --suppress-common-lines|wc -l
158

注意这里只是计算了,并没有真正的数据变动,可以通过监控两台的主机的网络流量来判断,所以这里的变动并不用计算到需要迁移的 PG 数目当中

crush remove 指定 OSD
[root@lab8106 ~]#ceph osd crush remove osd.15
删除指定的 OSD

删除以后同样是没有 PG 的变动的

ceph osd rm osd.15

这个地方有个小地方需要注意一下,不做 ceph auth del osd.15 把15的编号留着,这样好判断前后的 PG 的变化,不然相同的编号,就无法判断是不是做了迁移了

增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi
[root@lab8106 ~]#ceph-deploy osd activate lab8107:/dev/sdi1

我的环境下,新增的 OSD 的编号为16了

解除各种标记

我们放开上面的设置,看下数据的变动情况

[root@lab8106 ceph]# ceph osd unset norebalance
unset norebalance
[root@lab8106 ceph]# ceph osd unset nobackfill
unset nobackfill
[root@lab8106 ceph]# ceph osd unset norecover
unset norecover

设置完了后数据才真正开始变动了,可以通过观察网卡流量看到,来看下最终pg变化

[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 3pg3.txt
dumped pgs in format plain
[root@lab8106 ~]# diff -y -W 100 3pg1.txt 3pg3.txt --suppress-common-lines|wc -l
195

这里我们只需要跟最开始的 PG 分布状况进行比较就可以了,因为中间的状态实际上都没有做数据的迁移,所以不需要统计进去,可以看到这个地方动了195个 PG
总共的 PG 迁移量为

195

三、数据汇总

现在通过表格来对比下三种方法的迁移量的比较(括号内为迁移 PG 数目)

  方法一 方法二 方法三
所做操作 stop osd (0)
out osd(102)
crush remove osd (137)
add osd(167)
crush reweight osd(166)
out osd(0)
crush remove osd (0)
add osd(159)
set 标记(0)
crush reweight osd(0)
crush remove osd (0)
add osd(195)
PG迁移数量 406 325 195

可以很清楚的看到三种不同的方法,最终的触发的迁移量是不同的,处理的好的话,能节约差不多一半的迁移的数据量,这个对于生产环境来说还是很好的,关于这个建议先在测试环境上进行测试,然后再操作,上面的操作只要不对磁盘进行格式化,操作都是可逆的,也就是可以比较放心的做,记住所做的操作,每一步都做完都去检查 PG 的状态是否是正常的

<think>我们正在讨论Rook-Ceph集群中节点标签变更对OSD加入时间的影响。用户的问题是:在三节点架构中,移除master标签后,节点多久能作为OSD节点加入集群? 根据引用[4]的内容,我们知道在Rook-Ceph中可以通过节点亲和性(nodeAffinity)来调度Ceph组件(如MDS)到特定标签的节点上。同样,OSD的调度也可以使用类似机制。 然而,用户的问题是关于移除master标签后节点重新加入OSD集群的时间。这里需要明确几点: 1. 在Rook-Ceph中,OSD的调度是由Rook Operator控制的,它通过节点上的标签来决定是否在某个节点上部署OSD。 2. 当节点被移除某个标签(例如master标签)后,Rook Operator会检测到节点标签的变化,并重新评估该节点是否符合OSD的部署条件。 3. 重新加入的时间取决于Rook Operator的重新调度周期以及Ceph集群的恢复速度。 具体过程: - 当节点被移除master标签(假设之前因为master标签而不部署OSD,现在移除了就可以部署)后,Rook Operator会重新评估该节点。 - Rook Operator的监控循环周期通常是即时的,但实际变更可能需等待几秒到几分钟。 - 一旦Rook Operator决定在该节点上部署OSD,它会启动一个Pod(osd-prepare)来准备OSD(如分区、格式化等),然后启动OSD Pod。 - 整个过程中,OSD加入集群的时间包括: a. Rook Operator检测到节点标签变更的时间(一般1分钟内)。 b. 准备OSD的时间(取决于磁盘大小和速度,通常几分钟)。 c. OSD Pod启动并加入Ceph集群的时间(通常1-2分钟)。 因此,从移除标签到OSD完全加入并开始服务,通常需要5-10分钟。但具体时间取决于集群的当前负载和硬件性能。 另外,引用[3]提到Ceph集群需要至少一个Monitor和Manager,以及足够数量的OSD(根据副本数要求)。移除节点标签不会直接影响这些核心组件,除非这些组件也在该节点上运行。 建议步骤: 1. 移除节点上的master标签:`kubectl label node <node-name> master-`(注意最后的减号表示移除)。 2. 观察Rook Operator的日志:`kubectl logs -n rook-ceph -l app=rook-operator`,查看是否触发了重新调度。 3. 检查OSD Pod的状态:`kubectl get pods -n rook-ceph -o wide | grep osd`,看新OSD是否被调度到该节点。 4. 检查Ceph集群状态:通过`kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph -s`查看OSD是否加入。 注意:如果节点之前已经作为OSD运行过,并且有数据残留,可能需要清理磁盘(Rook会处理,但若之前是异常退出,可能需要手动清理)。 总结:移除标签后,节点通常会在几分钟内被Rook Operator检测到并开始加入OSD集群,整个过程大约5-10分钟。 相关问题: 1. 如何监控Rook-Ceph集群中OSD的状态变化? 2. 在Rook-Ceph中,如何配置节点标签以控制OSD的部署? 3. 当节点标签变更后,Rook Operator的工作流程是怎样的?</think>在 Rook-Ceph 三节点架构中,移除节点的 `master` 标签后,节点重新作为 OSD 加入集群的时间取决于以下关键因素: ### 时间线分析 1. **即时生效(<1分钟)** - 标签变更命令执行后立即生效:`kubectl label node <node-name> master-`(末尾 `-` 表示移除标签) - Rook Operator 通过 Kubernetes Watch API 实时监控节点标签变化[^4] 2. **OSD 自动加入(1-5分钟)** - Rook Operator 检测到标签变更后,自动触发 OSD 准备流程(`osd-prepare` Pod) - 新 OSD Pod 启动并注册到 Ceph 集群,日志可通过以下命令监控: ```bash kubectl logs -n rook-ceph -l app=rook-ceph-operator --tail=50 ``` - 加入时间受磁盘大小影响(大容量磁盘初始化更久) 3. **数据均衡(5分钟-数小时)** - OSD 加入后触发 CRUSH 规则重新计算 - 数据自动迁移以实现均衡,可通过 Ceph 命令观察进度: ```bash kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph -s ``` - 迁移速度取决于集群负载和数据量(每 TB 数据约需 10-30 分钟) ### 关键验证点 1. **确认 OSD 状态**(加入完成后): ```bash kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph osd tree # 检查节点对应的 OSD 状态应为 "up" 和 "in" ``` 2. **检查节点调度约束**: ```yaml # rook-ceph-cluster.yaml 需配置正确亲和性规则 placement: osd: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: master # 确保此处无 master 标签要求 operator: DoesNotExist # 正确配置 ``` 错误配置会导致 OSD 无法调度[^4] ### 加速加入的技巧 1. **手动触发重调度**: ```bash kubectl delete pod -n rook-ceph -l app=rook-ceph-operator ``` 2. **调整 OSD 资源限制**(大集群适用): ```yaml osd: resources: limits: cpu: "2" memory: "4Gi" ``` > ⚠️ 注意:若节点曾运行过其他工作负载,需清理残留存储(`/var/lib/rook`),否则可能导致 OSD 加入失败[^1]。 --- ### 操作流程图解 ```mermaid graph TD A[移除master标签] -->|即时| B[Rook Operator 检测变更] B --> C[启动 osd-prepare Pod] C --> D{磁盘初始化} D -- 成功 --> E[部署 OSD DaemonSet] E --> F[OSD 注册到 Ceph] F --> G[数据均衡迁移] D -- 失败 --> H[检查 /var/lib/rook 残留] ``` 通常完整加入过程在 **5-15 分钟**内完成(不含数据迁移)。若超过 30 分钟无进展,需检查 `rook-ceph-operator` 日志及节点存储状态。 --- ### 相关问题 1. 如何验证 Rook-Ceph 中 OSD 的数据均衡是否完成? 2. 节点存储残留导致 OSD 加入失败时应如何清理? 3. Rook-Ceph 的 CRUSH 规则如何影响数据分布效率? 4. 如何监控 Rook Operator 对节点标签变化的响应延迟?
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值