替换OSD操作的优化与分析
之前有写过一篇删除OSD的正确方式,里面只是简单的讲了下删除的方式怎样能减少迁移量,本篇属于一个扩展,讲述了 Ceph 运维当中经常出现的坏盘提换盘的步骤的优化
基础环境两台主机每台主机8个 OSD,一共 16 个 OSD,副本设置为2,PG 数设置为800,计算下来平均每个 OSD 上的 P G数目为100个,本篇将通过数据来分析不同的处理方法的差别
开始测试前先把环境设置为 noout
,然后通过停止 OSD 来模拟 OSD 出现了异常,之后进行不同处理方法
测试三种方法
首先 out 一个 OSD,然后剔除 OSD,然后增加 OSD
- 停止指定 OSD 进程
- out 指定 OSD
- crush remove 指定 OSD
- 增加一个新的 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 |
第一次 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 |
我们重新加上新的 OSD
[root@lab8106 ~]# ceph-deploy osd prepare lab8107:/dev/sdi |
加完以后统计当前的新的 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 |
整个替换流程完毕,统计上面的 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 |
等待平衡了以后记录当前的 PG 分布状态
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg2.txt |
比较前后的变动
[root@lab8106 ~]# diff -y -W 100 2pg1.txt 2pg2.txt --suppress-common-lines|wc -l |
crush remove 指定 OSD
[root@lab8106 ~]# ceph osd crush remove osd.16 |
这个地方因为上面 crush 已经是0了所以删除也不会引起 PG 变动
然后直接 ceph osd rm osd.16
同样没有 PG 变动
增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi |
等待平衡以后获取当前的 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 |
总的 PG 变动为
166+159=325
开始做norebalance,然后做crush remove,然后做add
恢复环境为初始环境,然后获取当前的 PG 分布
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg1.txt |
给集群做多种标记,防止迁移
设置为 norebalance,nobackfill,norecover,后面是有地方会解除这些设置的
[root@lab8106 ~]# ceph osd set norebalance |
crush reweight 指定 OSD
[root@lab8106 ~]# ceph osd crush reweight osd.15 0 |
这个地方因为已经做了上面的标记,所以只会出现状态变化,而没有真正的迁移,我们也先统计一下
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg2.txt |
注意这里只是计算了,并没有真正的数据变动,可以通过监控两台的主机的网络流量来判断,所以这里的变动并不用计算到需要迁移的 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 |
我的环境下,新增的 OSD 的编号为16了
解除各种标记
我们放开上面的设置,看下数据的变动情况
[root@lab8106 ceph]# ceph osd unset norebalance |
设置完了后数据才真正开始变动了,可以通过观察网卡流量看到,来看下最终pg变化
[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg3.txt |
这里我们只需要跟最开始的 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 的状态是否是正常的
总结
从我自己的操作经验来看,最开始是用的第一种方法,后面就用第二种方法减少了一部分迁移量,最近看到资料写做剔除OSD的时候可以关闭迁移防止无效的过多的迁移,然后就测试了一下,确实能够减少不少的迁移量,这个减少在某些场景下还是很好的,当然如果不太熟悉,用哪一种都可以,最终能达到的目的是一样的
附加
有人问到一个问题,为什么按照这个流程操作的时候,会出现slow request?在进行了一次验证后,发现在迁移过程中的请求路径还是很长的,所以出现slow request还是很容易的
假如我们有三个osd,分别为0,1,2,里面有各种的分布,我们在踢掉一个osd.2后,可能出现的一个情况是
某个PG(0.3b)的[2,0]分布变成了[1,0]
而此时后台的osd.1的PG(0.3b)这个目录里面的内容实际是空的,如果这个时候,前端的请求一个对象正好是分布在0.3b这个PG上的时候,后台需要先将osd.0上面的这个0.3b的对象写入到osd.1的0.3b的pg里面去,然后再去响应客户端的请求,自然路径就长了,如果这样的请求一多,响应前台的性能就有问题了,增加节点的时候同理
请求到这种空PG的对象,PG的状态会这样变化:
从active+degraded 变成active+recovery_wait+degraded
迁移的数据量是一定的,这个看是请求的时候实时迁移然后响应还是提前迁移,然后响应,所以这个中间操作过程尽量的快的完成,然后好迁移完响应前端的请求
替换OSD操作的优化与分析的更多相关文章
- 转——Android应用开发性能优化完全分析
[工匠若水 http://blog.csdn.net/yanbober 转载请注明出处.] 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉 ...
- Android 应用开发性能优化完全分析
1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只 ...
- 【转】Android应用开发性能优化完全分析
http://blog.csdn.net/yanbober/article/details/48394201 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关 ...
- Android应用开发性能优化完全分析
1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只 ...
- 转:Android应用开发性能优化完全分析
转自:http://blog.csdn.net/yanbober/article/details/48394201 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜 ...
- SQL优化-如何分析性能瓶颈
MySQL优化一览图 笔者将优化分为了两大类:软优化和硬优化.软优化一般是操作数据库即可:而硬优化则是操作服务器硬件及参数设置. 1.软优化 1)查询语句优化 首先我们可以用EXPLAIN或DESCR ...
- MySQL优化 - 性能分析与查询优化(转)
出处: MySQL优化 - 性能分析与查询优化 优化应贯穿整个产品开发周期中,比如编写复杂SQL时查看执行计划,安装MySQL服务器时尽量合理配置(见过太多完全使用默认配置安装的情况),根据应用负载 ...
- apache kafka系列之性能优化架构分析
apache kafka中国社区QQ群:162272557 Apache kafka性能优化架构分析 应用程序优化:数据压缩 watermark/2/text/aHR0cDovL2Jsb2cuY3Nk ...
- Java I/O 操作及优化建议
Java I/O I/O,即 Input/Output(输入/输出) 的简称.就 I/O 而言.概念上有 5 种模型:blocking I/O.nonblocking I/O,I/O multiple ...
随机推荐
- MySQL备份之XtraBackup工具使用
数据库的完整备份 [root@vhost1 ~]# innobackupex --defaults-file=/mysqldata/3306/my.cnf --user=root --passw ...
- 移动端调试 — chrome模拟器基础调试
打开开发者工具,进入chrome调试状态,点击左上角的手机图标,进入手机模拟器调试状态. 模拟器支持操作: 切换设备类型,模拟网络环境,模拟bar,keyboard弹出状态,横屏状态,更改UserAg ...
- 当主机ip变了修改gitlab的ip地址
gitlab服务器IP地址更换后需要修改以下两个配置中的IP地址: /var/opt/gitlab/gitlab-rails/etc/gitlab.yml /etc/gitlab/gitlab.rb ...
- vue事件的绑定
<!doctype html> <html> <head> <meta charset="UTF-8"> <title> ...
- SmokeTest测试流程
没办法了,本来是表格,但是粘贴不过来 测试目的: 用于检测该版本在基本的应用场景下,基本的功能是否满足. 测试前提: 发货版本 示例:ATV9冒烟测试测试项解读 表格获取:Google ATV hel ...
- Python笔记(二十一)_内置函数、内置方法
内置函数 issubclass(class1,class2) 判断class1类是否为class2类的子类,返回True和False 注意1:类会被认为是自身的子类 >>>issub ...
- 爬虫之requests 请求
1.发送不同的请求 import requests r = requests.get('https://www.baidu.com/') r = requests.post('http://httpb ...
- hexo博客yilia主题深度设置
转载:Shuyan http://dongshuyan.com/2019/05/24/hexo博客注意事项/ 1.微信分享异常 这里是themes\yilia\layout\ _partial\pos ...
- IDEA永久破解方法
链接: https://pan.baidu.com/s/1a1pMOP6rMrh-wJdUFSCqAw 提取码: 46cx 复制这段内容后打开百度网盘手机App,操作更方便哦
- [Codeforces 997C]Sky Full of Stars(排列组合+容斥原理)
[Codeforces 997C]Sky Full of Stars(排列组合+容斥原理) 题面 用3种颜色对\(n×n\)的格子染色,问至少有一行或一列只有一种颜色的方案数.\((n≤10^6)\) ...