Ceph對象存儲網關中的索引工做原理<轉>

Ceph 對象存儲網關容許你經過 Swift 及 S3 API 訪問 Ceph 。它將這些 API 請求轉化爲 librados 請求。Librados 是一個很是出色的對象存儲（庫）可是它沒法高效的列舉對象。對象存儲網關維護自有索引來提高列舉對象的響應性能並維護了其餘的一些元信息。有關對象存儲網關索引工做原理的文章不多，因此我寫了這篇博文，權當拋磚迎玉。

咱們先來看看一個已存在的 bucket

這個 bucket 的對象列表存儲在一個單獨的 rados 對象中。這個對象的名字是 .dir. 加上 bucket id 。索引對象存儲在一個名爲 .rgw.buckets.index 的獨立存儲池中。因此本例中，mybucket 的索引應該是 .dir.default.14113.1（譯者注：原文中是.dir.default.2529250.167, 基於原理和實踐，肯定此處有誤，特此更正）。

 

找到 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)

咱們看到鍵值數據庫在 OSD 3 及 5 上，其中 3 是主 OSD（第一個）。

找到 OSD 3 上的鍵值數據庫

能夠看到 osd.3 在主機 ceph-osd1 上

這就是包含索引的鍵值數據庫 leveldb。