RGW Bucket Shard设计与优化-下

OMAP过大的OSD服务恢复

当bucket index所在的OSD omap过大的时候,一旦出现异常导致OSD进程崩溃,这个时候就需要进行现场"救火",用最快的速度恢复OSD服务,于是有了下面这篇文章。

先确定对应OSD的OMAP大小,这个过大会导致OSD启动的时候消耗大量时间和资源去加载levelDB数据,导致OSD无法启动(超时自杀)。特别是这一类OSD启动需要占用非常大的内存消耗,一定要注意预留好内存。(物理内存40G左右,不行用swap顶上)

root@demo:/# du -sh /var/lib/osd/ceph-214/current/omap/
22G     /var/lib/osd/ceph-214/current/omap/
  2017-08-11 11:52:46.601938 7f298ae2e700  1 heartbeat_map is_healthy 'FileStore::op_tp thread 0x7f2980894700' had suicide timed out after 180
     0> 2017-08-11 11:52:46.605728 7f298ae2e700 -1 common/HeartbeatMap.cc: In function 'bool ceph::HeartbeatMap::_check(ceph::heartbeat_handle_d*, const char*, time_t)' thread 7f298ae2e700 time 2017-08-11 11:52:46.601952
common/HeartbeatMap.cc: 79: FAILED assert(0 == "hit suicide timeout") #超时自杀

1

启动OSD服务之前调整osd超时设置

在故障节点ceph.conf配置中加上

[osd]
debug osd = 20 #调整debug级别

[osd.214]
            ...
        filestore_op_thread_suicide_timeout = 7000 #设置对应的osd超时,防止osd自杀

2

启动OSD进程

观察日志

tailf /home/ceph/log/ceph-osd.214.log

启动服务

/etc/init.d/ceph start osd.214

后台多启动一个top观察进程的资源消耗,目前OMAP在16G左右的OSD,需要大概37G的内存。恢复过程中OSD进程会占用非常高的内存和CPU,如下图

3

择机释放内存

当观察到日志中有下面的记录就可以启动内存的释放操作(也可以放到最后去做)

2017-08-11 15:08:14.551305 7f2b3fcab900  0 osd.214 29425 load_pgs opened 181 pgs

释放内存命令如下

ceph tell osd.214 heap release

4

OSD服务恢复过程中的监测

经过上面的操作以后osd会持续进行Omap数据的恢复,整个过程比较漫长,可以同时开 watch ceph -s 进行观察,一般恢复速率为每秒14MB,恢复时长估算公式

恢复时长(单位:秒) = OMAP总容量 / 14
注意:其中OMAP总容量是前面du命令得到的

恢复过程中的日志如下

2017-08-11 15:11:25.049357 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] handle_message: 0x651131200
2017-08-11 15:11:25.049380 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] handle_push ObjectRecoveryInfo(6f648ab6/.dir.hxs1.55076.1.6/head//76@29425'5676261, copy_subset: [], clone_subset: {})ObjectRecoveryProgress(!first, data_recovered_to:0, data_complete:false, omap_recovered_to:0_00001948372.1948372.3, omap_complete:false)
2017-08-11 15:11:25.049400 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] submit_push_data: Creating oid 6f648ab6/.dir.hxs1.55076.1.6/head//76 in the temp collection
2017-08-11 15:11:25.123153 7f2a3b327700 10 osd.214 29450 dequeue_op 0x651131200 finish
2017-08-11 15:11:25.138155 7f2b357a1700  5 osd.214 29450 tick
2017-08-11 15:11:25.138186 7f2b357a1700 20 osd.214 29450 scrub_should_schedule should run between 0 - 24 now 15 = yes
2017-08-11 15:11:25.138210 7f2b357a1700 20 osd.214 29450 scrub_should_schedule loadavg 3.34 >= max 0.5 = no, load too high
2017-08-11 15:11:25.138221 7f2b357a1700 20 osd.214 29450 sched_scrub load_is_low=0
2017-08-11 15:11:25.138223 7f2b357a1700 10 osd.214 29450 sched_scrub 76.2a9 high load at 2017-08-10 11:39:35.359828: 99109.8 < max (604800 seconds)
2017-08-11 15:11:25.138235 7f2b357a1700 20 osd.214 29450 sched_scrub done
2017-08-11 15:11:25.138237 7f2b357a1700 10 osd.214 29450 do_waiters -- start
2017-08-11 15:11:25.138239 7f2b357a1700 10 osd.214 29450 do_waiters -- finish
2017-08-11 15:11:25.163988 7f2aaef77700 20 osd.214 29450 share_map_peer 0x66b4e0260 already has epoch 29450
2017-08-11 15:11:25.164042 7f2ab077a700 20 osd.214 29450 share_map_peer 0x66b4e0260 already has epoch 29450
2017-08-11 15:11:25.268001 7f2aaef77700 20 osd.214 29450 share_map_peer 0x66b657a20 already has epoch 29450
2017-08-11 15:11:25.268075 7f2ab077a700 20 osd.214 29450 share_map_peer 0x66b657a20 already has epoch 29450

当OSD对应的PG状态都恢复正常就可以进行下面的收尾操作了。

5

收尾工作

  1. 清理内存 OSD完成数据恢复以后,CPU会下降,但是内存不会释放,必须使用前面的命令去释放内存。
  1. 调整日志级别 ceph tell osd.214 injectargs "--debug_osd=0/5"
  2. 删除ceph.conf里面之前临时新加的内容

至此bucket shard部分三篇内容就分享完了。

原文发布于微信公众号 - Ceph对象存储方案(cephbook)

原文发表时间:2017-09-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小文博客

小文’s blog – 论坛搭建教程-附源码-直播搭建

4313
来自专栏SDNLAB

网络操作系统VyOS应用实践(一)

前言 本文在前面安装篇的基础上,对其功能进行应用实践。本文先介绍使用中的一些注意事项,后面介绍其网络接口相关的功能。 探索开始 这款操作系统目的是为了在x86平...

1.1K6
来自专栏L宝宝聊IT

Linux基础——centOS7的安装

3093
来自专栏黑泽君的专栏

Win10没有以太网图标如何找回?以太网适配器不见了怎么恢复?

Win10以太网适配器不见了怎么恢复?以太网其实就是Win7系统中常说的“本地连接”假若用户发现网络适配器中的以太网适配器图标不见了,可以在设备管理器中添加一些...

771
来自专栏云计算教程系列

求生之路2服务器搭建教程

《求生之路2》(英语:Left 4 Dead 2)是2008年由V社开发、以丧尸为主题的恐怖生存类游戏《求生之路》的续作,游戏初次于2009年电玩E3展亮相,并...

1.1K4
来自专栏pangguoming

只需一点小修改,HTC Vive画面会更清晰锐利

这里要先谢谢@NB81rkd0qB,他的那个帖子里其实很多碰到的问题都可以解决,但是目前有点乱,所以我这里斗胆整理一下,希望能帮助一下朋友们。 第一步:我们要找...

3398
来自专栏大魏分享(微信公众号:david-share)

RedHat Ceph存储——《面向生产环境的Ceph 对象网关指南》

5194
来自专栏安恒信息

[紧急]Discuz!X 安全漏洞预警

1DISCUZ漏洞 2017年9月29日,Comsenz向Discuz!X官方Git提交了加强安全性的代码更新,代码更改记录: https://gitee.co...

42512
来自专栏磨磨谈

查询OSD运行在哪些cpu上

在看CPU相关的文章的时候,想起来之前有文章讨论是否要做CPU绑定,这个有说绑定的也有说不绑定的,然后就想到一个问题,有去观测这些OSD到底运行在哪些CPU上面...

1311
来自专栏blackpiglet

Ceph RGW bucket 自动分片介绍和存在的问题

工作中存储集群使用了 Ceph 技术,所用的是版本是 Luminous 12.2.4,因为刚刚上手 Ceph,不少概念和问题也都是头一次听说,比如这次的自动分片...

2514

扫码关注云+社区

领取腾讯云代金券