前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >Large omap objects 排错实战

Large omap objects 排错实战

作者头像
用户1260683
发布于 2018-12-26 03:53:14
发布于 2018-12-26 03:53:14
5.8K00
代码可运行
举报
运行总次数:0
代码可运行

线上multisite环境出现HEALTH_WARN 32 large omap objects,已经bucket auto reshard=false,所以排除是bucket index 所在的shard omap过大引发的问题,官方的给出的告警信息无法定位到具体的object,于是有了下面的排错过程

排查过程

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[root@demo supdev]# ceph health detail
HEALTH_WARN 32 large omap objects
LARGE_OMAP_OBJECTS 32 large omap objects
    32 large objects found in pool 'cn-bj-test1.rgw.log' #出现large omap的pool
    Search the cluster log for 'Large omap object found' for more details.


[root@demo supdev]# ceph pg ls-by-pool cn-bj-test1.rgw.log |awk '{print "ceph pg "$1 " query|grep num_large_omap_objects"}'|sh -x
ceph pg 11.0 query|grep num_large_omap_objects
ceph pg 11.1 query|grep num_large_omap_objects
ceph pg 11.2 query|grep num_large_omap_objects
......
+ ceph pg 11.1e6 query
+ grep num_large_omap_objects
                "num_large_omap_objects": 1 #有large omap的objcet数量
                    "num_large_omap_objects": 0
                    "num_large_omap_objects": 0


[root@demo supdev]# ceph pg 11.1e6 query #查询pg详细信息
{
    "state": "active+clean",
.....
    "info": {
        "pgid": "11.1e6",
        "last_update": "10075'3051746",
        "last_complete": "10075'3051746",
        "log_tail": "10075'3050200",
        "last_user_version": 3051746,
        "last_backfill": "MAX",
        "last_backfill_bitwise": 0,
        "purged_snaps": [],
.....

              "acting": [
                    46, #主OSD id=46
                    63, #从OSD
                    23  #从OSD
                ],
            "stat_sum": {
                "num_bytes": 40,
                "num_objects": 2,
                "num_object_clones": 0,
                "num_object_copies": 6,
                "num_objects_missing_on_primary": 0,
                "num_objects_missing": 0,
                "num_objects_degraded": 0,
                "num_objects_misplaced": 0,
                "num_objects_unfound": 0,
                "num_objects_dirty": 2,
                "num_whiteouts": 0,
                "num_read": 3055759,
                "num_read_kb": 3056162,
                "num_write": 5986011,
                "num_write_kb": 53,
                "num_scrub_errors": 0,
                "num_shallow_scrub_errors": 0,
                "num_deep_scrub_errors": 0,
                "num_objects_recovered": 0,
                "num_bytes_recovered": 0,
                "num_keys_recovered": 0,
                "num_objects_omap": 1,
                "num_objects_hit_set_archive": 0,
                "num_bytes_hit_set_archive": 0,
                "num_flush": 0,
                "num_flush_kb": 0,
                "num_evict": 0,
                "num_evict_kb": 0,
                "num_promote": 0,
                "num_flush_mode_high": 0,
                "num_flush_mode_low": 0,
                "num_evict_mode_some": 0,
                "num_evict_mode_full": 0,
                "num_objects_pinned": 0,
                "num_legacy_snapsets": 0,
                "num_large_omap_objects": 1 #large omap的object数量
            },
            ...
                "agent_state": {}
}


[root@demo supdev]# ceph osd find 46 #根据OSD id找到对应的主机信息
{
    "osd": 46,
    "ip": "100.1.1.40:6812/3691515",
    "crush_location": {
        "host": "TX-100-1-40-sata",
        "media": "site1-rack2-sata",
        "mediagroup": "site1-sata",
        "root": "default"
    }
}


[root@demo supdev]# zcat /var/log/ceph/ceph-osd.46.log-20181210.gz |grep omap #根据OSD日志找到具体的object名称
2018-12-09 23:03:18.803799 7f90e9b46700  0 log_channel(cluster) log [WRN] : Large omap object found. Object: 11:67885262:::sync.error-log.3:head Key count: 2934286 Size (bytes): 657040594 
#OSD 46上的object名称为sync.error-log.3的omap超出标准



[root@demo supdev]# rados ls -p cn-bj-test1.rgw.log|grep "sync.error-log.3$" #确定objects存在
sync.error-log.3

#注意整个multisite的同步过程中的错误日志信息以omap形式存储在sync.error-log.* 
#吐槽一下,错误日志分32个shard存储,代码写死了,而且错误日志目前还只能通过手工清理,无法像其他日志一样自动trim,随着错误日志不断堆积,才引发了今天的问题。

[root@demo supdev]# radosgw-admin sync error list|more#查看错误日志
[
    {
        "shard_id": 0,
        "entries": [
            {
                "id": "1_1540890427.972991_36.1",
                "section": "data",
                "name": "demo2:afd874cd-f976-4007-a77c-be6fca298b71.34353.1:3",
                "timestamp": "2018-10-30 09:07:07.972991Z",
                "info": {
                    "source_zone": "afd874cd-f976-4007-a77c-be6fca298b71",
                    "error_code": 5,
                    "message": "failed to sync bucket instance: (5) Input/output error"
                }
            },
......
            {
                "id": "1_1543395420.626552_32014.1",
                "section": "data",
                "name": "demo1:afd874cd-f976-4007-a77c-be6fca298b71.34209.1:0/file1205085",
                "timestamp": "2018-11-28 08:57:00.626552Z",
                "info": {
                    "source_zone": "afd874cd-f976-4007-a77c-be6fca298b71",
                    "error_code": 5,
                    "message": "failed to sync object(5) Input/output error"
                }
            }


[root@TX-97-140-6 supdev]# radosgw-admin sync error trim --start-date=2018-11-14 --end-date=2018-11-28 #按日期清理错误日志记录

优化定位效率

简单写了个脚本,先根据warn信息找pool,之后再根据pool找出有large omap objects的pg,凑合用,不保证没bug,在12.2.10下面测试通过。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[root@demo cephuser]# cat large_obj.py
import json
import rados
import rbd

ceph_conf_path = '/etc/ceph/ceph.conf'
rados_connect_timeout = 5

class RADOSClient(object):
    def __init__(self,driver,pool=None):
        self.driver = driver
        self.client, self.ioctx = driver._connect_to_rados(pool)
    def __enter__(self):
        return self
    def __exit__(self, type_, value, traceback):
        self.driver._disconnect_from_rados(self.client, self.ioctx)

class RBDDriver(object):
    def __init__(self,ceph_conf_path,rados_connect_timeout,pool=None):
        self.ceph_conf_path = ceph_conf_path
        self.rados_connect_timeout = rados_connect_timeout
        self.pool = pool
    def _connect_to_rados(self, pool=None):
        client = rados.Rados(conffile=self.ceph_conf_path)
        try:
            if self.rados_connect_timeout >= 0:
                client.connect(timeout=
                               self.rados_connect_timeout)
            else:
                client.connect()
            if self.pool == None:
                                ioctx = None
            else:
                                ioctx = client.open_ioctx(self.pool)
            return client, ioctx
        except rados.Error:
            msg = "Error connecting to ceph cluster."
            client.shutdown()
            raise msg

    def _disconnect_from_rados(self, client, ioctx=None):
                if ioctx == None:
                        client.shutdown()
                else:
                        ioctx.close()
                        client.shutdown()

class cmd_manager():
    def get_large_omap_obj_poolname(self):
        with RADOSClient(RBDDriver(ceph_conf_path,rados_connect_timeout)) as dr:
                result = ''
                cmd = '{"prefix": "health", "detail": "detail", "format": "json"}'
                result = dr.client.mon_command(cmd,result)
                if result[0] == 0:
                    res_ = json.loads(result[1])
                    if res_["checks"]['LARGE_OMAP_OBJECTS']:
                        return res_["checks"]['LARGE_OMAP_OBJECTS']['detail'][0]['message'].split("'")[1]
                else:
                    return False
    def get_pg_list_by_pool(self,poolname):
        with RADOSClient(RBDDriver(ceph_conf_path,rados_connect_timeout)) as dr:
                result = ''
                cmd = '{"prefix": "pg ls-by-pool", "poolstr": "' + poolname + '", "format": "json"}'
                result = dr.client.mon_command(cmd,result)
                if result[0] == 0:
                    return json.loads(result[1])
                else:
                    return False

cmd_ = cmd_manager()
poolname =  cmd_.get_large_omap_obj_poolname()
print "Large omap objects poolname = {0}".format(poolname)
res =  cmd_.get_pg_list_by_pool(poolname)
for i in res:
    if i["stat_sum"]["num_large_omap_objects"] != 0:
        print "pgid={0} OSDs={1} num_large_omap_objects={2}".format(i["pgid"],i["acting"],i["stat_sum"]["num_large_omap_objects"])

再爆一个雷

如果你认为通过上面方式清除omap集群就能立马恢复状态,那就太天真,告警信息“HEALTH_WARN 32 large omap objects”依然挂在那里不尴不尬,虽然omap清理了,但是因为对应PG状态没更新,所以告警信息依然存在,只能通过手工或者其他方式去触发PG的状态更新,我这边是通过ceph pg deep-scrub {pg}去触发pg信息更新,注意如果你用scrub是没用,必须deep-scrub,这里又要吐槽官方的逻辑设计,真是WFK!当然你也可以放那里不管,等后台自动deep-scrub也能恢复。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-12-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Ceph对象存储方案 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Ceph 故障排查笔记 | 万字经验总结
删除当前 osd 的所有数据,并且重新加载 osd,此操作一定要保证有冗余可用的 osd,否则会造成整个 osd 数据损坏。
米开朗基杨
2021/05/11
7.9K0
index pool的 large omap 处理
向单个bucket压测2000W个object,默认设置shard数为16,压测到1800W出现large omap,介绍一下错误定位和如何处理。
用户1260683
2019/03/08
4.5K0
RGW Bucket Shard设计与优化-中
如何缓解 index shard 过大造成的影响 下面这些都是属于应急操作,属于快速止血止痛,部分操作属高危,一定要谨慎使用。 1 调整OSD的几个op超时参数 下面的几个参数只是用例,具体根据各位线上情况进行调整,但是不宜过大。 osd_op_thread_timeout = 90 #default is 15 osd_op_thread_suicide_timeout = 300 #default is 150 filestore_op_thread_timeout = 180 #d
用户1260683
2018/01/31
4.3K1
Ceph快照详解
Ceph的快照与其他系统的快照一样,是基于COW(copy-on-write)实现的。其实现由RADOS支持,基于OSD服务端——每次做完快照后再对卷进行写入时就会触发COW操作,即先拷贝出原数据对象的数据出来生成快照对象,然后对原数据对象进行写入。于此同时,每次快照的操作会更新卷的元数据,以及包括快照ID,快照链,parent信息等在内的快照信息。
thierryzhou
2022/12/01
4.3K0
Ceph快照详解
从hammer到jewel的RGW升级实战-by秦牧羊
本篇来自秦牧羊的一篇分享,讲述的是从hammer升级到jewel的过程,以及其中的一些故障的处理,是一篇非常详细的实战分享
用户2772802
2018/08/06
6380
Ceph 自动化四大天王
每一个Ceph新手,都或多或少被文中提到的四大天(坑)王吊打过,或钢筋铁骨成为大神,或删库跑路沦为亡魂。因此有必要给大家早早普及一下这四大天王的手段,帮各位早脱苦海。本文建立在你已经基本了解Ceph的构架和基本原理,如果不熟悉的同学可以看下面内容
用户1260683
2021/12/04
1.3K1
RGW Bucket Shard设计与优化-上
1 bucket index背景简介 bucket index是整个RGW里面一个非常关键的数据结构,用于存储bucket的索引数据,默认情况下单个bucket的index全部存储在一个shard文件(shard数量为0,主要以OMAP-keys方式存储在leveldb中),随着单个bucket内的Object数量增加,整个shard文件的体积也在不断增长,当shard文件体积过大就会引发各种问题,常见的问题有: 对index pool进行scrub或deep-scrub的时候,如果shard对应的Obj
用户1260683
2018/01/31
5.2K0
Ceph:关于 Ceph 存储架构的一些笔记
Ceph 集群搭建使用标准硬件和存储设备的服务器,是一个高度可扩展的分布式存储系统, 采用模块化分布式架构。Ceph 主要通过 RADOS 核心组件来提供能力。
山河已无恙
2023/08/21
1.3K0
Ceph:关于 Ceph 存储架构的一些笔记
Ceph分布式存储工作原理 及 部署介绍
存储根据其类型,可分为块存储,对象存储和文件存储。在主流的分布式存储技术中,HDFS/GPFS/GFS属于文件存储,Swift属于对象存储,而Ceph可支持块存储、对象存储和文件存储,故称为统一存储。
洗尽了浮华
2022/03/28
6.3K0
Ceph分布式存储工作原理 及 部署介绍
Ceph理解
- 图虽然很复杂,但如果理解了几个基本操作的含义就很好读下来了,这里是三个操作的伪代码,take和emit很好理解,select主要是遍历当前bucket,如果出现重复、失败或者超载就跳过,其中稍微复杂的“first n”部分是一旦遇到失败,第一种情况是直接使用多备份,第二种情况是使用erasing code基本可以忽略。看着下面的图就更好理解具体的算法了
ZHaos
2019/02/27
2.3K0
分布式存储Cephfs读取优化方案
继上次分享的 Ceph介绍及原理架构分享 和 分布式存储Ceph之PG状态详解 ,这次分享点干货。 用户需要从cephfs存储系统中检索一个大文件指定关键字的一行信息, 并且对延迟和性能要求比较高。
Lucien168
2020/07/20
1.8K0
分布式存储Cephfs读取优化方案
RGW Bucket Shard设计与优化-下
OMAP过大的OSD服务恢复 当bucket index所在的OSD omap过大的时候,一旦出现异常导致OSD进程崩溃,这个时候就需要进行现场"救火",用最快的速度恢复OSD服务,于是有了下面这篇文章。 先确定对应OSD的OMAP大小,这个过大会导致OSD启动的时候消耗大量时间和资源去加载levelDB数据,导致OSD无法启动(超时自杀)。特别是这一类OSD启动需要占用非常大的内存消耗,一定要注意预留好内存。(物理内存40G左右,不行用swap顶上) root@demo:/# du -sh /var/l
用户1260683
2018/01/31
2.4K0
RGW Bucket Shard设计与优化-下
Ceph亚太峰会RGW议题分享
Ceph亚太峰会RGW部分议题分享 本次Ceph亚太峰会干货最实在的的要数Redhat的《Common Support Issues and How to Troubleshoot Them》这里把RGW部分摘出来,和大家分享一下,本次议题主要是涉及到RGW中Object数量过多导致的OSD异常如何处理。 故障现象描述 Flapping OSD's when RGW buckets have millions of objects ● Possible causes ○ The first issue h
用户1260683
2018/06/11
2.5K1
RGW Bucket Shard优化
bucket index是整个RGW里面一个非常关键的数据结构,用于存储bucket的索引数据,默认情况下单个bucket的index全部存储在一个shard文件(shard数量为0,主要以OMAP-keys方式存储在leveldb中),随着单个bucket内的Object数量增加,整个shard文件的体积也在不断增长,当shard文件体积过大就会引发各种问题。
Lucien168
2020/07/20
3.2K0
RGW Bucket Shard优化
Ceph分布式存储日常运维管理手册
nearfull osd(s) or pool(s) nearfull 此时说明部分osd的存储已经超过阈值,mon会监控ceph集群中OSD空间使用情况。如果要消除WARN,可以修改这两个参数,提高阈值,但是通过实践发现并不能解决问题,可以通过观察osd的数据分布情况来分析原因。
民工哥
2020/09/15
2.5K0
Ceph分布式存储日常运维管理手册
Ceph性能调优和建议
这些集群范围内的配置参数定义在Ceph的配置文件中,因此任何一个Ceph守护进程启动时都将会遵循已定义的设置。缺省的配置文件是ceph.conf,放在/etc/ceph目录下。这个配置文件有一个global部分和若干个服务类型部分。任何时候一个Ceph服务启动,都会应用[gloabl]部分,以及进程特定部分的配置。一个Ceph配置文件有多个部分,如下图所示。
博文视点Broadview
2020/06/12
5.8K0
Ceph性能调优和建议
ceph 存储池pool操作
1、列出存储池 ceph osd lspools 2、创建存储池 ceph osd pool create poolname pg-num pgp-num replicated crush-ruleset-name expected-num-objects //副本方式 ceph osd pool create poolname pg-num pgp-num erasure erasure-code-profile crush-ruleset-name expected-num-objects //poolname 要唯一 3、设置存储池配额 ceph osd pool set-quota poolname max-objects max-bytes 4、删除存储池 ceph osd pool delete poolname 5、重命名存储池 ceph osd pool rename {current-pool-name} {new-pool-name} 6、存储池统计信息 rados df 7、存储池快照 ceph osd pool mksnap poolname snapname 8、删除存储池快照 ceph osd pool rmsnap poolname snapname 9、查看存储池配置 ceph osd pool get poolname [key]
用户5760343
2022/05/18
8320
【问题修复】osd自杀问题跟踪
RGW的index数据以omap形式存储在OSD所在节点的leveldb中,当单个bucket存储的Object数量高达百万数量级的时候,deep-scrub和bucket list一类的操作将极大的消耗磁盘资源,导致对应OSD出现异常,如果不对bucket的index进行shard切片操作(shard切片实现了将单个bucket index的LevelDB实例水平切分到多个OSD上),数据量大了以后很容易出事。
Lucien168
2020/07/20
1.9K0
【问题修复】osd自杀问题跟踪
ceph分布式存储-常见 PG 故障处理
创建一个新集群后,PG 的状态一直处于 active , active + remapped 或 active + degraded 状态, 而无法达到 active + clean 状态 ,那很可能是你的配置有问题。
Lucien168
2020/07/20
3.6K0
ceph运维操作
如果是在admin节点修改的ceph.conf,想推送到所有其他节点,则需要执行下述命令
匿名用户的日记
2022/01/05
3.4K0
相关推荐
Ceph 故障排查笔记 | 万字经验总结
更多 >
领券
社区富文本编辑器全新改版!诚邀体验~
全新交互,全新视觉,新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能,全面提升创作效率和体验
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文