Ceph Large omap objects现象及原理分析

Large omap objects现象

以下是真实的问题场景，以此文进行记录并分享。

Q1：集群出现了Large omap objects告警，这是什么问题？有什么影响？

Q2：Large omap objects告警的触发条件是什么？

Q3：这个告警怎么处理？或者怎么优化解决？

随着Ceph对象存储的产品不断成熟，用户数量的不断增加，对集群的性能考验也愈发严峻。特别是某些大型用户在特定场景下需要对单个bucket进行上传大量的对象，同时如果用户直接或者间接（应用程序调用list object接口）对单个bucket进行多次list object操作，会有一些IO响应慢，日志中可能会出现slow request，则可能会发现ceph出现了large omap objects告警。本文基于ceph luminous版本展开讨论，该版本引入了large omap objects告警功能。

集群出现如下large omap objects告警，下面对此展开分析：

出现上述告警后，运维人员可以通过ceph health detail查看具体的告警信息进行定位，一般large omap objects出现在存储池default.rgw.buckets.index。每个bucket在存储池default.rgw.buckets.index中都对应一个rados索引对象。存储池default.rgw.buckets.index中对象的格式为.dir.<marker>。

Bucket属性

先简单介绍bucket属性，并举例列出bucket的rados索引对象和bucket内对象名称的关系。

图1

上面给出了bucket的id，marker，owner，quota等属性。这里我们关注marker，通过marker信息，可以到对应的pool default.rgw.buckets.index找到该bucket，如下：

向bucket test1 分别上传obj1，obj2，obj3三个对象：

我们可以通过rados listomapkeys命令查看bucket的索引对象下的对象。

也就是说存储池default.rgw.buckets.index中bucket 对应的索引对象记录了bucket中对象等信息。这里联想单个bucket下大量对象的问题，大家应该会想到large omap objects的生成跟这个索引下的对象存在一定关系。

告警产生

接下来通过large omap objects中的告警信息追溯该告警产生的原因，并找出对应的指标值。

1. Large omap objects的告警来源如下：

void PGMap::get_health_checks(…) const

{

utime_t now = ceph_clock_now();

const auto max = cct->_conf->get_val<uint64_t>("mon_health_max_detail");

const auto& pools = osdmap.get_pools();

…

if (!detail.empty()) {

ostringstream ss;

ss << pg_sum.stats.sum.num_large_omap_objects << " large omap objects";//ceph -s中告警信息显示

auto& d = checks->add("LARGE_OMAP_OBJECTS", HEALTH_WARN, ss.str());

stringstream tip;

tip << "Search the cluster log for 'Large omap object found' for more "

<< "details.";

detail.push_back(tip.str());

d.detail.swap(detail);

}

…

}

从上述代码中可以发现large omap objects的数量统计来源于变量：pg_sum.stats.sum.num_large_omap_objects，那么通过对变量num_large_omap_objects的跟踪，得知large omap objects数量的来源是从ceph的deep scrub中检测出来的。

2. Ceph deep scrub检测large omap objects

void PG::scrub_finish()

{

…

if (deep_scrub) {

if ((scrubber.shallow_errors == 0) && (scrubber.deep_errors == 0))

info.history.last_clean_scrub_stamp = now;

info.stats.stats.sum.num_shallow_scrub_errors = scrubber.shallow_errors;

info.stats.stats.sum.num_deep_scrub_errors = scrubber.deep_errors;

info.stats.stats.sum.num_large_omap_objects = scrubber.omap_stats.large_omap_objects;

info.stats.stats.sum.num_omap_bytes = scrubber.omap_stats.omap_bytes;

info.stats.stats.sum.num_omap_keys = scrubber.omap_stats.omap_keys;

dout(25) << __func__ << " shard " << pg_whoami << " num_omap_bytes = "

<< info.stats.stats.sum.num_omap_bytes << " num_omap_keys = "

<< info.stats.stats.sum.num_omap_keys << dendl;

publish_stats_to_osd();

} else {

…

}

上述的关键变量，并给他们做出解释。

num_large_omap_objects：指存储池中omap key或omap bytes超过阈值的shard数。

num_omap_bytes：对象的omap大小，这里的对象可以是bucket所有shard。

num_omap_keys：对象的omap key数量，这里的对象可以是bucket所有shard。

跟踪变量num_large_omap_objects这里的large_omap_objects是从下面的函数获取。

3.获取变量large_omap_objects

void PGBackend::be_omap_checks(…) const

{

…

ScrubMap::object& obj = it->second;

omap_stats.omap_bytes += obj.object_omap_bytes;

omap_stats.omap_keys += obj.object_omap_keys;

if (obj.large_omap_object_found) {

pg_t pg;

auto osdmap = get_osdmap();

osdmap->map_to_pg(k.pool, k.oid.name, k.get_key(), k.nspace, &pg);

pg_t mpg = osdmap->raw_pg_to_pg(pg);

omap_stats.large_omap_objects++;

warnstream << "Large omap object found. Object: " << k

<< " PG: " << pg << " (" << mpg << ")"

<< " Key count: " << obj.large_omap_object_key_count

<< " Size (bytes): " << obj.large_omap_object_value_size

<< '\n';

break;

}

…

}

从上述判断if (obj.large_omap_object_found)得知，需要根据变量large_omap_object_found来确定large omap对象的判断依据。

4.Ceph deep scrub获取omap相关属性，并将单个shard的omap_keys和omap_bytes跟阈值进行比较，判断当前shard是否为large omap objects。

int ReplicatedBackend::be_deep_scrub(…)

{

…

int max = g_conf->osd_deep_scrub_keys;

while (iter->status() == 0 && iter->valid()) {

pos.omap_bytes += iter->value().length();

++pos.omap_keys;//获取omap_keys数量

--max;

fixme: we can do this more efficiently.

bufferlist bl;

::encode(iter->key(), bl);

::encode(iter->value(), bl);

pos.omap_hash << bl;

iter->next();

…

}

if (pos.omap_keys > cct->_conf->

osd_deep_scrub_large_omap_object_key_threshold ||

pos.omap_bytes > cct->_conf->

osd_deep_scrub_large_omap_object_value_sum_threshold) {

dout(25) << __func__ << " " << poid

<< " large omap object detected. Object has " << pos.omap_keys

<< " keys and size " << pos.omap_bytes << " bytes" << dendl;

o.large_omap_object_found = true;//比较每个分片的阈值

o.large_omap_object_key_count = pos.omap_keys;

o.large_omap_object_value_size = pos.omap_bytes;

map.has_large_omap_object_errors = true;

}

…

}

当变量large_omap_object_found为true时需要满足以下两个条件之一即可：

1.pos.omap_keys>osd_deep_scrub_large_omap_object_key_threshold

2.pos.omap_bytes>osd_deep_scrub_large_omap_object_value_sum_threshold

默认阈值：

osd_deep_scrub_large_omap_object_key_threshold为200000（20万）

osd_deep_scrub_large_omap_object_value_sum_threshold为1G

通过上述变量的跟踪，可以得知large omap objects是通过ceph deep scrub进行发现并上报的，遍历每个索引对象bucket中的分片（分片配置下文会讲），当分片的omap_keys的数量或omap_bytes的大小超过上述阈值时，会影响到large omap objects，并产生告警。

分片配置

当用户将大量对象（数百万个）都存在一个bucket中时，存储桶的索引操作会让性能受到严重影响。RGW中存在配置可以对索引进行分片，减少性能瓶颈。在对象存储中存在配置分片（shard）存在两个方法：

1. rgw_override_bucket_index_max_shards（默认值为0）

2. bucket_index_max_shards（这个在multisite中应用较多，这里不讨论）

在图1中看到的bucket info中rgw_override_bucket_index_max_shards值为0 ，表示桶的索引分片处于关闭状态。下面我们可以看下这个配置的生效阶段。

1. 获取bucket分片值

int RGWRados::init_complete()

{

…

bucket_index_max_shards = (cct->_conf->rgw_override_bucket_index_max_shards ? cct->_conf->rgw_override_bucket_index_max_shards :

get_zone().bucket_index_max_shards);

if (bucket_index_max_shards > get_max_bucket_shards()) {

bucket_index_max_shards = get_max_bucket_shards();//最大值不能超过65521

ldout(cct, 1) << __func__ << " bucket index max shards is too large, reset to value: "

<< get_max_bucket_shards() << dendl;

}

ldout(cct, 20) << __func__ << " bucket index max shards: " << bucket_index_max_shards << dendl;

…

}

上述bucket分片值在创建桶的时候进行了初始化，如下：

int RGWRados::create_bucket(…)

{

…

if (pmaster_num_shards) {

info.num_shards = *pmaster_num_shards;

} else {

info.num_shards = bucket_index_max_shards;

}

…

int r = init_bucket_index(info, info.num_shards);

…

}

bucket_index_max_shards最终写入到bucket info的num_shards中。

对象的shard分配

下面我们通过上传一个对象来跟踪该对象最终是怎么分配到具体的shard中的。为了测试方便我们将rgw_override_bucket_index_max_shards设置为5.

RGW中上传对象的函数入口：

int RGWRados::get_bucket_index_object(const string& bucket_oid_base, const string& obj_key,//上传的对象名称

uint32_t num_shards, RGWBucketInfo::BIShardsHashType hash_type, string *bucket_obj, int *shard_id)

{

int r = 0;

switch (hash_type) {

case RGWBucketInfo::MOD:

if (!num_shards) {

By default with no sharding, we use the bucket oid as itself

(*bucket_obj) = bucket_oid_base;

if (shard_id) {

*shard_id = -1;

}

} else {

uint32_t sid = rgw_bucket_shard_index(obj_key, num_shards);//用hash算法获取shard_id

…

}

break;

default:

r = -ENOTSUP;

}

return r;

}

inline函数如下，rgw_bucket_shard_index将obj_key和设置的shard数，通过哈希和求模算法，得到具体的分片序号。根据哈希的伪随机可知，同名对象的shard分配是固定的，也就是如果对象删除后，再次上传，在相同的shard上仍然能找到同名的对象。

static inline uint32_t rgw_bucket_shard_index(const std::string& key,

int num_shards) {

uint32_t sid = ceph_str_hash_linux(key.c_str(), key.size());

uint32_t sid2 = sid ^ ((sid & 0xFF) << 24);

return rgw_shards_mod(sid2, num_shards);

}

这里做如下测试，向同一个bucket中上传两次同名文件，但是大小不一样，验证其shard分片：

1.查看创建桶的shard数，rgw_override_bucket_index_max_shards值为5.对应的bucket的分片数也为5,格式为.dir.<markder>.<shard>.

2. 向测试桶testbk中上传对象test_obj，对象存储在分片2中，即.dir.<marker>.2。

3. 删除原test_obj，并上传不同大小的test_obj，对象仍然存储在分片2中

从上述测试结果来看，验证了同名对象分配的shard是不变的。

Bucket list请求

这次问题发生的前提条件就是通过RGW日志发现client存在大量的bucket list请求，导致IO无法及时响应，存在slow request问题。我们下面探索一下list请求的底层处理。

RGW请求处理

RGW作为client，在发出list object请求时，调用关系如下：

1. RGWRados::open_bucket_index调用如下函数，根据bucket_info.num_shards获取bucket全部的分片，便于后面进行遍历查找。

2. issue_bucket_list_op操作分类两个主要步骤：

1）定义bucket list操作类型，便于OSD进行对应的请求处理。

2）进行异步操作。

static bool issue_bucket_list_op(…) {

librados::ObjectReadOperation op;

cls_rgw_bucket_list_op(op, start_obj, filter_prefix,

num_entries, list_versions, pdata);

return manager->aio_operate(io_ctx, oid, &op);

}

上述函数首先定义了bucket list的操作类型，然后异步执行这个操作。我们进一步查看这个OP的类型如下。

通过cls_rgw_bucket_list_op定义了这个请求的OP类型，以便于后续OSD接收到请求后对应的请求处理。

void cls_rgw_bucket_list_op(…)

{

…

op.exec(RGW_CLASS, RGW_BUCKET_LIST, in, new ClsBucketIndexOpCtx<rgw_cls_list_ret>(result, NULL));

}

#define RGW_CLASS "rgw"

#define RGW_BUCKET_LIST "bucket_list"

以下是RGW请求发送及OSD请求处理关系图

图2 RGW，OSD发送消息处理

Op类型定义

通过宏定义知道这个OP类型是bucket_list操作，结合图2，后续OSD收到该请求后会调用对应的函数进行处理。

紧接着librados::ObjectOperation::exec à ObjectOperation::call

查看ObjectOperation::call，增加了OSD的操作类型是CEPH_OSD_OP_CALL。

void call(const char *cname, const char *method, bufferlist &indata,

bufferlist *outdata, Context *ctx, int *prval) {

add_call(CEPH_OSD_OP_CALL, cname, method, indata, outdata, ctx, prval);

}

请求异步执行

发送对应的请求给OSD处理。_send_op中定义的消息类型是MOSDOp

class MOSDOp : public MOSDFastDispatchOp

通过类的定义可知，继承了fastdispatch。消息类型是CEPH_MSG_OSD_OP。

MOSDOp()

: MOSDFastDispatchOp(CEPH_MSG_OSD_OP, HEAD_VERSION, COMPAT_VERSION),

partial_decode_needed(true),

final_decode_needed(true) { }

OSD消息处理

通过发送的fastdispatch消息类型定义，OSD会从ms_fast_dispatch入口进行处理，调用关系如下，OSD将此消息进行入队操作，如图2。

OSD消息队列处理

PrimaryLogPG::do_osd_ops函数中涉及到omap key操作的有三种情况：

1.case CEPH_OSD_OP_CALL

这里会处理RGW过来的bucket list请求操作。

ClassHandler::ClassMethod *method = cls->get_method(mname.c_str());

if (!method) {

dout(10) << "call method " << cname << "." << mname << " does not exist" << dendl;

result = -EOPNOTSUPP;

break;

}

int flags = method->get_flags();

if (flags & CLS_METHOD_WR)

ctx->user_modify = true;

bufferlist outdata;

dout(10) << "call method " << cname << "." << mname << dendl;

int prev_rd = ctx->num_read;

int prev_wr = ctx->num_write;

result = method->exec((cls_method_context_t)&ctx, indata, outdata);

上述method是调用RGW的bucket list，也就是OP类型定义中确定的rgw_bucket_list函数。然后调用read_bucket_header à cls_cxx_map_read_header

再次调用do_osd_ops 的case CEPH_OSD_OP_OMAPGETHEADER

int cls_cxx_map_read_header(cls_method_context_t hctx, bufferlist *outbl)

{

PrimaryLogPG::OpContext **pctx = (PrimaryLogPG::OpContext **)hctx;

vector<OSDOp> ops(1);

OSDOp& op = ops[0];

int ret;

op.op.op = CEPH_OSD_OP_OMAPGETHEADER;

ret = (*pctx)->pg->do_osd_ops(*pctx, ops);

if (ret < 0)

return ret;

outbl->claim(op.outdata);

return 0;

}

2.case CEPH_OSD_OP_OMAPGETHEADER

1. omap get header的处理情况

case CEPH_OSD_OP_OMAPGETHEADER:

tracepoint(osd, do_osd_op_pre_omapgetheader, soid.oid.name.c_str(), soid.snap.val);

if (!oi.is_omap()) {

return empty header

break;

}

++ctx->num_read;

{

osd->store->omap_get_header(ch, ghobject_t(soid), &osd_op.outdata);

ctx->delta_stats.num_rd_kb += SHIFT_ROUND_UP(osd_op.outdata.length(), 10);

ctx->delta_stats.num_rd++;

}

break;

2. 如果ceph底层采用filestore，那么调用关系如下：

FileStore::omap_get_header

—> DBObjectMap::get_header

int DBObjectMap::get_header(const ghobject_t &oid,

bufferlist *bl)

{

MapHeaderLock hl(this, oid);

Header header = lookup_map_header(hl, oid);

if (!header) {

return 0;

}

return _get_header(header, bl);

}

从上述函数可知，最后是从数据库中获取对应数据,并存入内存变量bl中

3.case CEPH_OSD_OP_OMAPGETKEYS

这里调用DBObjectMap::get_iterator获得数据库的迭代器，用来处理listomapkeys请求，从下面代码得知最终是根据oid从数据库中获取数据。最后将获得的key序列化到内存变量bl中。如果是对default.rgw.buckets.index中索引对象进行listomapkeys，那么这里encode到bl中的就是bucket内的对象名。

ObjectMap::ObjectMapIterator DBObjectMap::get_iterator(

const ghobject_t &oid)

{

MapHeaderLock hl(this, oid);

Header header = lookup_map_header(hl, oid);

if (!header)

return ObjectMapIterator(new EmptyIteratorImpl());

DBObjectMapIterator iter = _get_iterator(header);

iter->hlock.swap(hl);

return iter;

}