YigS3 協(xié)議兼容的分布式對象存儲系統(tǒng)
Yet another Index Gateway
Yig 是 S3 協(xié)議兼容的分布式對象存儲系統(tǒng)。它脫胎于開源軟件 ceph ，在多年的商業(yè)化運(yùn)維中， 針對運(yùn)維中出現(xiàn)的問題和功能上的新需求，重新實(shí)現(xiàn)了一遍 radosgw 用于解決以下問題：
單 bucket 下面文件數(shù)目的限制
大幅度提高小文件的存儲能力
bucket 下面文件過多時，list 操作延遲變高
后臺 ceph 集群在做 recovery 或者 backfill 時極大影響系統(tǒng)性能
提高大文件上傳并發(fā)效率
Yig 設(shè)計(jì)
設(shè)計(jì)一個新的存儲系統(tǒng)解決以上問題，無非這些思路
隔離后臺 rebalance 影響
根據(jù) haystack 的論文，默認(rèn)的 filestore 或者 bludestore ，并不特別適合小文件存儲，需要新的存儲引擎
radosgw 對 librados 提高的 omap 和 cls 用得太重，我們?nèi)绾魏喕軜?gòu)，讓代碼更容易懂，也更不容易出錯。
更加統(tǒng)一的 cache 層，提高讀性能
架構(gòu)如圖所見：
S3 API layer，負(fù)責(zé) S3 API 的解析，處理。所有元數(shù)據(jù)存儲在 hbase 中，元數(shù)據(jù)包括 bucket 的信息，object 的元數(shù)據(jù)（如ACL，contenttype），multipart 的切片信息，權(quán)限管理，BLOB Storage 的權(quán)值和調(diào)度。所以的元數(shù)據(jù)都 cache 在統(tǒng)一的 cache 層?？梢钥吹剿性獢?shù)據(jù)都存儲在 hbase 中，并且有統(tǒng)一的 cache ，相比于 radosgw 大大提高的對元數(shù)據(jù)操作的可控性，也提高了元數(shù)據(jù)查詢的速度。
BLOB Storage 層，可以并行的存在多個 Ceph Cluster 。只使用 rados_read/rados_write 的 API 。如果其中一個 ceph cluster 正在做 rebalance ，可以把它上面所有寫請求調(diào)度到其他 ceph 集群，減少寫的壓力，讓 rebalance 迅速完成。從用戶角度看，所有的寫入并沒有影響，只是到這個正在 rebalance 的 ceph cluster 上的讀請求會慢一點(diǎn)兒。大規(guī)模擴(kuò)容也非常容易，比如存在這種情況，初期上線了5臺服務(wù)器做存儲，發(fā)現(xiàn)容量增加很快，希望加到50臺，但是在原 ceph 集群上一下添加45臺新服務(wù)器，rebalance 的壓力太大。在 yig 的環(huán)境中，只要新建一個45臺的 ceph 集群，接入 yig 的環(huán)境就行，可以快速無縫的添加容量。
在 ceph 層提升性能
使用 libradosstriper API 提升大文件讀取寫入性能
對于大文件，相比與 radosgw 每次使用 512K 的 buf ，用 rados_write 的 API 寫入 ceph 集群，yig 使用動態(tài)的 buf ，根據(jù)用戶上傳的速度的大小調(diào)整 buf 在 (512K~1M) 之間。 并且使用 rados striping 的 API 提高寫入的并發(fā)程度。讓更多的 OSD 參與到大文件的寫入，提高并發(fā)程度。 拆分方法如圖：
使用 kvstore 提升小文件存儲性能
針對小文件，直接使用 kvstore 存儲，底層使用 rocksdb ，這個方案相比與 bluestore 或者 filestore 更輕。性能更好。但是要注意2點(diǎn)：
默認(rèn)的 kvstore 并沒有打開布隆過濾器，需要在 ceph 的配置文件中配置打開，否則讀性能會很差
在 Ceph 的 replicatePG 層，每次寫 object 之前，都會嘗試讀取原 Object ，然后在寫入。這個對于 rbd 這種大文件的應(yīng)用影響不大，但是對于小文件寫入就非常糟糕。 所以我們在 rados 的請求中加入的一個新的 FLAG: LIBRADOS_OP_FLAG_FADVISE_NEWOBJ，在 replicatedPG 中會檢查是否有這個 FLAG ，如果有，就不會嘗試讀取不存在的小文件。通過這個 patch ，可以極大的提升小文件的寫入性能和降低 cpu 的利用率。
測試
功能測試
因?yàn)椴捎昧藰?biāo)準(zhǔn)的 S3 接口，可以使用標(biāo)準(zhǔn)的工具。
采用標(biāo)準(zhǔn)的 python boto 庫測試 yig
復(fù)用 ceph 社區(qū)的 s3-test 項(xiàng)目測試 yig
性能測試
ceph cluster 性能測試原始 ceph 性能，使用 rados bench 測試4k小文件的隨機(jī)讀寫。
使用 wrk 配合 lua 腳本測試 S3 API
使用 ycsb 測試 S3 API 性能
部分性能測試數(shù)據(jù)： 測試平臺: 后臺3臺物理機(jī)，ceph 采用普通硬盤，hbase 采用普通硬盤，3副本方案 測試場景：寫入1K小文件，然后測試在 90% read 和 10% write 的情況下（類似有于線上環(huán)境）的性能數(shù)據(jù) 測試結(jié)果：
load 數(shù)據(jù)階段性能: 可以看到即使是在3副本的情況下，S3 寫入 iops 仍然很高，可以注意到?jīng)]割一段時間，iops 的的性能會下降，這是由于 rocksdb 后臺在做 compaction 。
模擬線上環(huán)境性能：
由于是讀多寫少的環(huán)境，iops 相比于純寫入有很大提升，也不容易發(fā)生 compact ，所以 iops 能維持在較高的水平。延遲情況是90%以上的請求延遲小于1s，平均延遲就更小了。
<b id="afajh"><abbr id="afajh"></abbr></b>