1.背景

毫無(wú)疑問(wèn)，乘著云計(jì)算發(fā)展的東風(fēng)，Ceph已經(jīng)是當(dāng)今最火熱的軟件定義存儲(chǔ)開(kāi)源項(xiàng)目。如下圖所示，它在同一底層平臺(tái)之上可以對(duì)外提供三種存儲(chǔ)接口，分別是文件存儲(chǔ)、對(duì)象存儲(chǔ)以及塊存儲(chǔ)，本文主要關(guān)注的是對(duì)象存儲(chǔ)即radosgw。

基于Ceph可方便快捷地搭建安全性好、可用性高、擴(kuò)展性好的私有化存儲(chǔ)平臺(tái)。私有化存儲(chǔ)平臺(tái)雖然以其安全性的優(yōu)勢(shì)受到越來(lái)越多的關(guān)注，但私有化存儲(chǔ)平臺(tái)也存在諸多弊端。 例如在如下場(chǎng)景中，某跨國(guó)公司需要在國(guó)外訪(fǎng)問(wèn)本地的業(yè)務(wù)數(shù)據(jù)，我們?cè)撊绾沃С诌@種遠(yuǎn)距離的數(shù)據(jù)訪(fǎng)問(wèn)需求呢。如果僅僅是在私有化環(huán)境下，無(wú)非以下兩種解決方案：

直接跨地域去訪(fǎng)問(wèn)本地?cái)?shù)據(jù)中心中的數(shù)據(jù)，毫無(wú)疑問(wèn)，這種解決方案會(huì)帶來(lái)較高的訪(fǎng)問(wèn)延遲。

在國(guó)外自建數(shù)據(jù)中心，不斷將本地的數(shù)據(jù)異步復(fù)制到遠(yuǎn)程數(shù)據(jù)中心，這種解決方案的缺點(diǎn)是成本太高。

在這種場(chǎng)景下，單純的私有云存儲(chǔ)平臺(tái)并不能很好的解決的上面的問(wèn)題。但是，通過(guò)采用混合云解決方案卻能較好地滿(mǎn)足上述需求。對(duì)于前文所述遠(yuǎn)距離數(shù)據(jù)訪(fǎng)問(wèn)的場(chǎng)景，我們完全能借助公有云在遠(yuǎn)程的數(shù)據(jù)中心節(jié)點(diǎn)作為存儲(chǔ)點(diǎn)，將本地?cái)?shù)據(jù)中心的數(shù)據(jù)異步復(fù)制到公有云，再通過(guò)終端直接訪(fǎng)問(wèn)公有云中的數(shù)據(jù)，這種方式在綜合成本和快捷性方面具備較大優(yōu)勢(shì)，適合這種遠(yuǎn)距離的數(shù)據(jù)訪(fǎng)問(wèn)需求。

2.發(fā)展現(xiàn)狀：RGW Cloud Sync發(fā)展歷程

基于Ceph對(duì)象存儲(chǔ)的混合云機(jī)制是對(duì)Ceph生態(tài)的良好補(bǔ)充， 基于此，社區(qū)將在Mimic這個(gè)版本上發(fā)布RGW Cloud Sync特性，初步支持將RGW中的數(shù)據(jù)導(dǎo)出到支持s3協(xié)議的公有云對(duì)象存儲(chǔ)平臺(tái)，比如我們測(cè)試中使用的騰訊云COS，同Mulsite中的其他插件一樣，RGW Cloud Sync這個(gè)特性也是做成了一個(gè)全新的同步插件（目前稱(chēng)之為aws sync module），能兼容支持S3協(xié)議。RGW Cloud Sync特性的整體發(fā)展歷程如下：

Suse公司貢獻(xiàn)了初始版本，這個(gè)版本僅支持簡(jiǎn)單上傳；

Red Hat在這個(gè)初始版本之上實(shí)現(xiàn)了完整語(yǔ)義的支持，比如multipart上傳、刪除等，考慮到同步大文件的時(shí)候可能會(huì)造成內(nèi)存爆炸的問(wèn)題，還實(shí)現(xiàn)了流式上傳。

對(duì)于Ceph社區(qū)即將在M版本發(fā)布的這個(gè)公有云同步特性，進(jìn)行了實(shí)際落地測(cè)試使用，并根據(jù)其中存在的問(wèn)題進(jìn)行了反饋及開(kāi)發(fā)。在實(shí)際測(cè)試過(guò)程中，我們搭建了如下所示的運(yùn)行環(huán)境：

其中，Cloud Zone內(nèi)部包含一個(gè)公有云同步插件，它被配置為只讀zone，用以將Rgw Zone中寫(xiě)入的數(shù)據(jù)跨地域同步至騰訊云公有云對(duì)象存儲(chǔ)平臺(tái)COS之上。順利實(shí)現(xiàn)將數(shù)據(jù)從RGW中同步備份至公有云平臺(tái)，并且支持自由定制來(lái)實(shí)現(xiàn)將數(shù)據(jù)導(dǎo)入至不同云端路徑，同時(shí)我們還完善了同步狀態(tài)顯示功能，能較快監(jiān)測(cè)到同步過(guò)程中發(fā)生的錯(cuò)誤以及當(dāng)前落后的數(shù)據(jù)等。

3.核心機(jī)制

Multisite

RGW Cloud Sync這個(gè)特性本質(zhì)上是基于Multisite之上的一個(gè)全新的同步插件（aws sync module）。首先來(lái)看Multisite的一些核心機(jī)制。Multisite是RGW中數(shù)據(jù)遠(yuǎn)程備份的一種解決方案，本質(zhì)上來(lái)說(shuō)它是一種基于日志的異步復(fù)制策略，下圖為一個(gè)Multisite的示意圖。

Multisite中主要有以下基本概念：

Zone：存在于一個(gè)獨(dú)立的Ceph集群，由一組rgw提供服務(wù)，對(duì)應(yīng)一組后臺(tái)的pool；

Zonegroup：包含至少一個(gè)Zone，Zone之間同步數(shù)據(jù)和元數(shù)據(jù)；

Realm：一個(gè)獨(dú)立的命名空間，包含至少一個(gè)Zonegroup，Zonegroup之間同步元數(shù)據(jù)。

下面來(lái)看Multisite中的一些工作機(jī)制，分別是Data Sync、Async Framework、Sync Plugin這三部分。其中Data Sync部分主要分析Multisite中的數(shù)據(jù)同步流程，Async Framework部分會(huì)介紹Multisite中的協(xié)程框架，Sync Plugin部分會(huì)介紹Multisite中的一些同步插件。

Data Sync

Data Sync用以將一個(gè)Zonegroup內(nèi)的數(shù)據(jù)進(jìn)行備份，一個(gè)Zone內(nèi)寫(xiě)入的數(shù)據(jù)會(huì)最終同步到Zonegroup內(nèi)所有Zone上，一個(gè)完整的Data Sync流程包含如下三步：

Init：將遠(yuǎn)程的source zone與local zone建立日志分片對(duì)應(yīng)關(guān)系，即將遠(yuǎn)程的datalog映射到本地，后續(xù)通過(guò)datalog就知道有沒(méi)有數(shù)據(jù)需要更新；

Build Full Sync Map：獲取遠(yuǎn)程bucket的元信息并建立映射關(guān)系來(lái)記錄bucket的同步狀態(tài)，如果配置multisite的時(shí)候source zone是沒(méi)有數(shù)據(jù)的，則這步會(huì)直接跳過(guò)；

Data Sync：開(kāi)始o(jì)bject數(shù)據(jù)的同步，通過(guò)RGW api來(lái)獲取source zone的datalog并消費(fèi)對(duì)應(yīng)的bilog來(lái)同步數(shù)據(jù)。

下面以一個(gè)bucket中數(shù)據(jù)的增量同步來(lái)闡述Data Sync的工作機(jī)制。了解RGW的人都應(yīng)該知道，一個(gè)bucket實(shí)例至少包含一個(gè)bucket shard，Data Sync是以bucket shard為單位來(lái)同步的，每個(gè)bucket shard有一個(gè)datalog shard 及bilog shard與之對(duì)應(yīng)。

在建立完對(duì)應(yīng)關(guān)系及進(jìn)行完全量同步之后，本地Zone會(huì)記錄Sourcezone每個(gè)datalog 分片對(duì)應(yīng)的sync_marker。此后local zone會(huì)定期將sync_marker與遠(yuǎn)程datalog的max_marker比對(duì)，若仍有數(shù)據(jù)未同步，則通過(guò)rgw消費(fèi)datalog entry，datalog entry中記錄了對(duì)應(yīng)的bucket shard，消費(fèi)bucket shard對(duì)應(yīng)的bilog則可進(jìn)行數(shù)據(jù)同步。如下面這個(gè)圖所示，遠(yuǎn)程的datalog是以 gw_data_chang_log_entry這樣一種格式來(lái)存儲(chǔ)日志的，我們可發(fā)現(xiàn)，每條datalog entry中包含rgw_data_change這樣一個(gè)域，而rgw_data_change中包括的key這個(gè)域則是bucket shard的名字，之后就可以找到與之對(duì)應(yīng)的bilog shard，從而消費(fèi)bilog來(lái)進(jìn)行增量同步。而全量同步其實(shí)就是沒(méi)有開(kāi)始這個(gè)sync_marker,直接從頭開(kāi)始消費(fèi)datalog來(lái)進(jìn)行數(shù)據(jù)同步。

Async Framework

RGW中使用的異步執(zhí)行框架是基于boost::asio::coroutine這個(gè)庫(kù)來(lái)開(kāi)發(fā)的，它是一個(gè)stackless coroutine，和常見(jiàn)的協(xié)程技術(shù)不同，Async Framework沒(méi)有使用ucontext技術(shù)來(lái)保存當(dāng)前堆棧信息來(lái)支持協(xié)程，而是使用宏的技巧來(lái)達(dá)到類(lèi)似效果，它通過(guò) reenter/yield/fork 幾個(gè)偽關(guān)鍵字（宏）來(lái)實(shí)現(xiàn)協(xié)程。RGWCoroutine是RGW中定義的關(guān)于協(xié)程的抽象類(lèi)，它本身也是boost::asio::coroutine 的子類(lèi)，它是用于描述一個(gè)任務(wù)流的，包含一個(gè)待實(shí)現(xiàn)的隱式狀態(tài)機(jī)。RGWCoroutine可以call其他RGWCoroutine，也可以spawn一個(gè)并行的RGWCoroutine。

RGWCoroutine 類(lèi)會(huì)包含一個(gè) RGWCoroutinesStack成員，使用call調(diào)用其他RGWCoroutine的時(shí)候會(huì)將其對(duì)應(yīng)的任務(wù)流都存儲(chǔ)在堆棧上，直到所有任務(wù)流完成之后控制權(quán)才會(huì)回到調(diào)用者處。然而，spawn一個(gè)新的RGWCoroutine時(shí)候會(huì)生成一個(gè)新的任務(wù)棧來(lái)存儲(chǔ)任務(wù)流，它不會(huì)阻塞當(dāng)前正在執(zhí)行的任務(wù)流。當(dāng)一個(gè)協(xié)程需要執(zhí)行一個(gè)異步IO操作的時(shí)候，它會(huì)標(biāo)記自身為阻塞狀態(tài)，而這個(gè)IO事件會(huì)在任務(wù)管理器處注冊(cè)，一旦IO完成后任務(wù)管理器會(huì)解鎖當(dāng)前堆棧，從而恢復(fù)這個(gè)協(xié)程的控制。下圖為一個(gè)簡(jiǎn)單的協(xié)程使用例子，實(shí)現(xiàn)了一個(gè)有預(yù)定周期的請(qǐng)求處理器。

Sync Plugin

前文所述的數(shù)據(jù)同步過(guò)程是將數(shù)據(jù)從一個(gè)ceph zone同步到另一ceph zone，我們完全可以將過(guò)程抽象出來(lái)，使數(shù)據(jù)同步變得更加通用，方便添加不同的sync module來(lái)實(shí)現(xiàn)將數(shù)據(jù)遷移到不同的目的地。因?yàn)樯蠈酉M(fèi)datalog的邏輯都是一致的，只有最后一步上層數(shù)據(jù)到目的地這步是不一樣的，因此我們只需實(shí)現(xiàn)數(shù)據(jù)同步和刪除的相關(guān)接口就可實(shí)現(xiàn)不同的同步插件，每個(gè)插件在RGW中都被稱(chēng)為一個(gè)sync module，目前Ceph中有以下四個(gè)sync module：

rgw：默認(rèn)sync module，用以在ceph zone之間同步數(shù)據(jù)

log：用于獲取object的擴(kuò)展屬性并進(jìn)行打印

elasticsearch：用于將數(shù)據(jù)的元信息同步至ES以支持一些搜索請(qǐng)求

aws：Mimic版本發(fā)布，用于導(dǎo)出RGW中的數(shù)據(jù)到支持S3協(xié)議的對(duì)象存儲(chǔ)平臺(tái) 4

RGW Cloud Sync

Streaming process

前文講到Suse公司貢獻(xiàn)了RGW Cloud Sync的初始版本，如下圖所示，它的一個(gè)同步流程邏輯上來(lái)說(shuō)主要分為三步，第一通過(guò)aws sync module通過(guò)http connection將遠(yuǎn)程的object拉取過(guò)來(lái)裝載至內(nèi)存中，之后將這個(gè)object put到云端，之后云端會(huì)返回一個(gè)put result。

對(duì)于小文件來(lái)說(shuō)，這個(gè)流程是沒(méi)問(wèn)題的，但是如果這個(gè)object比較大的情況，全部load到內(nèi)存中就有問(wèn)題了，因此Red Hat在此基礎(chǔ)之上支持了Streaming process。本質(zhì)上是使用了一個(gè)新的協(xié)程，這里稱(chēng)之為pipe CR，它采用類(lèi)似管道的機(jī)制，同時(shí)保持兩個(gè)http connection，一個(gè)用于拉取遠(yuǎn)程object，一個(gè)用于上傳object，且這兩個(gè)過(guò)程是并行的，這樣可以有效防止內(nèi)存爆炸，具體如下圖所示。

Multipart upload

Multipart upload是在Streaming process基礎(chǔ)之上用以支持大文件的分片上傳。它的整體流程如下：

Json config

公有云存儲(chǔ)環(huán)境相對(duì)來(lái)說(shuō)比較復(fù)雜，需要更加復(fù)雜的配置來(lái)支持aws sync module的使用，因此Red Hat在這個(gè)插件上支持了json config。

相對(duì)其他插件來(lái)說(shuō)主要增加了三個(gè)配置項(xiàng)，分別是host_style, acl_mapping,target_path，其中host_style是配置域名的使用格式，acl_mapping 是配置acl信息的同步方式，target_path是配置元數(shù)據(jù)在目的處的存放點(diǎn)。如下圖所示為一個(gè)實(shí)際使用的配置，它表示配置了aws zone，采用path-style這種域名格式，target_path是rgw加其所在zonegroup的名字并加上它的user_id，之后是它的bucket名字，最終這個(gè)object在云端的路徑就是target_path加上object名字。

5.關(guān)于RGW Cloud Sync方面的后續(xù)工作主要有以下四項(xiàng)：

同步狀態(tài)顯示的優(yōu)化，比如顯示落后的datalog、bucket、object等，同時(shí)將一些同步過(guò)程中發(fā)生的錯(cuò)誤上報(bào)至Monitor；

數(shù)據(jù)的反向同步，即支持將公有云的數(shù)據(jù)同步至RGW；

支持將RGW的數(shù)據(jù)導(dǎo)入更多的公有云平臺(tái)，而不是僅僅支持S3協(xié)議的平臺(tái)；

在此基礎(chǔ)之上以RGW為橋梁來(lái)實(shí)現(xiàn)不同云平臺(tái)之間的數(shù)據(jù)同步。