Ceph对象存储网关中的索引工作原理

Ceph对象存储网关允许你通过Swift及S3 API访问Ceph。他将这些API请求转化为librados请求。Librados是一个非常出色的对象存储（库）但是它无法高效的列举对象。对象存储网关维护自有索引来提升列举对象的响应性能并维护了其他的一些元信息。
我们先来看看一个已存在的bucket

这个bucket的对象列表存储在一个单独的rados对象中。这个对象的名字是.dir.加上bucket id。索引对象存储在一个名为.rgw.buckets.index的独立存储池中。所以本例中，mybucket的索引应该是.dir.default.14113.1。

找到bucket索引

# rados -p .rgw.buckets.index ls - | grep "default.14113.1"
.dir.default.14113.1

你可以看到从.rgw.buckets.index存储池返回的索引对象。

查看索引对象的内容

# rados -p rados -p .rgw.buckets.index get .dir.default.14113.1 indexfile
# wc -c indexfile
0 indexfile

对象0字节，怎么回事呢？秘密是：索引信息实际上存储在Ceph的键/值数据库中。每个OSD都有一个本地leveldb键/值数据库。因此索引对象实际上只是一个占位符，Ceph通过它找到那个包含索引信息的OSD键/值数据库。

查看键/值数据库的内容
先来看看索引键

# rados -p .rgw.buckets.index listomapkeys 
.dir.default.14113.1myobject

所以索引建就是对象名（情理之中）

再来看看索引值

现在比较对头了！本例中索引占175字节，从上面的十六进制转储信息可以看到一些信息片段。如果你用上面的转储信息与radosgw-admin输出的对象元信息对比，你就会知道索引中存储的是什么。

对象元信息

我们可以确定索引包含如下信息:

• name
• owner
• owner_display_name
• etag

• tag

  需要注意的是owner既是键也是值。我认为这样做是在出现数据损坏时能通过扫描索引值来恢复索引键。
  owner_display_name在这里是为了兼容S3。显然是一个读写妥协。
  etag（实体标签）是对象的MD5值，也是为了兼容S3。这有点得不偿失，因为我可以肯定如果每次创建一个对象就要计算MD5，这将会损害写性能。
  我怀疑radosgw-admin显示的其他元信息也包含在索引中（或者为空或者不可见）

找到键值数据库
计算出包含索引对象的OSD

# ceph osd map .rgw.buckets.index .rgw.buckets.index .dir.default.14113.24

osdmap e60 pool '.rgw.buckets.index' (11) object '.dir.default.14113.24/.rgw.buckets.index' -> pg 11.e6c72a3f (11.3f) -> up ([3,5], p3) acting ([3,5], p3)

我们看到键值数据库在OSD3及5上，其中3是主OSD（第一个）。
找到OSD3上的键值数据库

可以看到osd.3在主机ceph-osd1上

这就是包含索引的键值数据库leveldb