騰訊雲存儲專家深度解讀基於Ceph對象存儲的混合雲機制

背景

毫無疑問，乘着雲計算髮展的東風，Ceph已是當今最火熱的軟件定義存儲開源項目。以下圖所示，它在同一底層平臺之上能夠對外提供三種存儲接口，分別是文件存儲、對象存儲以及塊存儲，本文主要關注的是對象存儲即radosgw。

基於Ceph可方便快捷地搭建安全性好、可用性高、擴展性好的私有化存儲平臺。私有化存儲平臺雖然以其安全性的優點受到愈來愈多的關注，但私有化存儲平臺也存在諸多弊端。

例如在以下場景中，某跨國公司須要在國外訪問本地的業務數據，咱們該如何支持這種遠距離的數據訪問需求呢。若是僅僅是在私有化環境下，無非如下兩種解決方案：

直接跨地域去訪問本地數據中心中的數據，毫無疑問，這種解決方案會帶來較高的訪問延遲

在國外自建數據中心，不斷將本地的數據異步複製到遠程數據中心，這種解決方案的缺點是成本過高

在這種場景下，單純的私有云存儲平臺並不能很好的解決的上面的問題。可是，經過採用混合雲解決方案卻能較好地知足上述需求。對於前文所述遠距離數據訪問的場景，咱們徹底能借助公有云在遠程的數據中心節點做爲存儲點，將本地數據中心的數據異步複製到公有云，再經過終端直接訪問公有云中的數據，這種方式在綜合成本和快捷性方面具有較大優點，適合這種遠距離的數據訪問需求。

發展示狀：RGW Cloud Sync發展歷程

基於Ceph對象存儲的混合雲機制是對Ceph生態的良好補充， 基於此，社區將在Mimic這個版本上發佈RGW Cloud Sync特性，初步支持將RGW中的數據導出到支持s3協議的公有云對象存儲平臺，好比咱們測試中使用的騰訊雲COS，同Mulsite中的其餘插件同樣，RGW Cloud Sync這個特性也是作成了一個全新的同步插件（目前稱之爲aws sync module），能兼容支持S3協議。RGW Cloud Sync特性的總體發展歷程以下：

Suse公司貢獻了初始版本，這個版本僅支持簡單上傳Red Hat在這個初始版本之上實現了完整語義的支持，好比multipart上傳、刪除等，考慮到同步大文件的時候可能會形成內存爆炸的問題，還實現了流式上傳

對於Ceph社區即將在M版本發佈的這個公有云同步特性，騰訊雲存儲團隊也在不斷關注並進行了實際落地測試使用，並根據其中存在的問題進行了反饋及開發。在實際測試過程當中，咱們搭建了以下所示的運行環境：

其中，Cloud Zone內部包含一個公有云同步插件，它被配置爲只讀zone，用以將Rgw Zone中寫入的數據跨地域同步至騰訊雲公有云對象存儲平臺COS之上。順利實現將數據從RGW中同步備份至公有云平臺，而且支持自由定製來實現將數據導入至不一樣雲端路徑，同時咱們還完善了同步狀態顯示功能，能較快監測到同步過程當中發生的錯誤以及當前落後的數據等。

核心機制 Multisite

RGW Cloud Sync這個特性本質上是基於Multisite之上的一個全新的同步插件（aws sync module）。首先來看Multisite的一些核心機制。Multisite是RGW中數據遠程備份的一種解決方案，本質上來講它是一種基於日誌的異步複製策略，下圖爲一個Multisite的示意圖。

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

Zone：存在於一個獨立的Ceph集羣，由一組rgw提供服務，對應一組後臺的poolZonegroup：包含至少一個Zone，Zone之間同步數據和元數據Realm：一個獨立的命名空間，包含至少一個Zonegroup，Zonegroup之間同步元數據

下面來看Multisite中的一些工做機制，分別是Data Sync、Async Framework、Sync Plugin這三部分。其中Data Sync部分主要分析Multisite中的數據同步流程，Async Framework部分會介紹Multisite中的協程框架，Sync Plugin部分會介紹Multisite中的一些同步插件。

Data Sync

Data Sync用以將一個Zonegroup內的數據進行備份，一個Zone內寫入的數據會最終同步到Zonegroup內全部Zone上，一個完整的Data Sync流程包含以下三步：

Init：將遠程的source zone與local zone創建日誌分片對應關係，即將遠程的datalog映射到本地，後續經過datalog就知道有沒有數據須要更新Build Full Sync Map：獲取遠程bucket的元信息並創建映射關係來記錄bucket的同步狀態，若是配置multisite的時候source zone是沒有數據的，則這步會直接跳過Data Sync：開始object數據的同步，經過RGW api來獲取source zone的datalog並消費對應的bilog來同步數據

下面以一個bucket中數據的增量同步來闡述Data Sync的工做機制。瞭解RGW的人都應該知道，一個bucket實例至少包含一個bucket shard，Data Sync是以bucket shard爲單位來同步的，每一個bucket shard有一個datalog shard 及bilog shard與之對應。在創建完對應關係及進行徹底量同步以後，本地Zone會記錄Sourcezone每一個datalog 分片對應的sync_marker。此後local zone會按期將sync_marker與遠程datalog的max_marker比對，若仍有數據未同步，則經過rgw消費datalog entry，datalog entry中記錄了對應的bucket shard，消費bucket shard對應的bilog則可進行數據同步。以下面這個圖所示，遠程的datalog是以 gw_data_chang_log_entry這樣一種格式來存儲日誌的，咱們可發現，每條datalog entry中包含rgw_data_change這樣一個域，而rgw_data_change中包括的key這個域則是bucket shard的名字，以後就能夠找到與之對應的bilog shard，從而消費bilog來進行增量同步。而全量同步其實就是沒有開始這個sync_marker,直接從頭開始消費datalog來進行數據同步。

Async Framework

RGW中使用的異步執行框架是基於boost::asio::coroutine這個庫來開發的，它是一個stackless coroutine，和常見的協程技術不一樣，Async Framework沒有使用ucontext技術來保存當前堆棧信息來支持協程，而是使用宏的技巧來達到相似效果，它經過 reenter/yield/fork 幾個僞關鍵字（宏）來實現協程。

RGWCoroutine是RGW中定義的關於協程的抽象類，它自己也是boost::asio::coroutine 的子類，它是用於描述一個任務流的，包含一個待實現的隱式狀態機。RGWCoroutine能夠call其餘RGWCoroutine，也能夠spawn一個並行的RGWCoroutine。RGWCoroutine 類會包含一個 RGWCoroutinesStack成員，使用call調用其餘RGWCoroutine的時候會將其對應的任務流都存儲在堆棧上，直到全部任務流完成以後控制權纔會回到調用者處。然而，spawn一個新的RGWCoroutine時候會生成一個新的任務棧來存儲任務流，它不會阻塞當前正在執行的任務流。當一個協程須要執行一個異步IO操做的時候，它會標記自身爲阻塞狀態，而這個IO事件會在任務管理器處註冊，一旦IO完成後任務管理器會解鎖當前堆棧，從而恢復這個協程的控制。下圖爲一個簡單的協程使用例子，實現了一個有預約週期的請求處理器。

Sync Plugin

前文所述的數據同步過程是將數據從一個ceph zone同步到另外一ceph zone，咱們徹底能夠將過程抽象出來，使數據同步變得更加通用，方便添加不一樣的sync module來實現將數據遷移到不一樣的目的地。由於上層消費datalog的邏輯都是一致的，只有最後一步上層數據到目的地這步是不同的，所以咱們只需實現數據同步和刪除的相關接口就可實現不一樣的同步插件，每一個插件在RGW中都被稱爲一個sync module，目前Ceph中有如下四個sync module：

rgw：默認sync module，用以在ceph zone之間同步數據log：用於獲取object的擴展屬性並進行打印elasticsearch：用於將數據的元信息同步至ES以支持一些搜索請求aws：Mimic版本發佈，用於導出RGW中的數據到支持S3協議的對象存儲平臺 RGW Cloud Sync Streaming process

前文講到Suse公司貢獻了RGW Cloud Sync的初始版本，以下圖所示，它的一個同步流程邏輯上來講主要分爲三步，第一經過aws sync module經過http connection將遠程的object拉取過來裝載至內存中，以後將這個object put到雲端，以後雲端會返回一個put result。

對於小文件來講，這個流程是沒問題的，可是若是這個object比較大的狀況，所有load到內存中就有問題了，所以Red Hat在此基礎之上支持了Streaming process。本質上是使用了一個新的協程，這裏稱之爲pipe CR，它採用相似管道的機制，同時保持兩個http connection，一個用於拉取遠程object，一個用於上傳object，且這兩個過程是並行的，這樣能夠有效防止內存爆炸，具體以下圖所示。

Multipart upload

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

Json config

公有云存儲環境相對來講比較複雜，須要更加複雜的配置來支持aws sync module的使用，所以Red Hat在這個插件上支持了json config。

相對其餘插件來講主要增長了三個配置項，分別是host_style, acl_mapping,target_path，其中host_style是配置域名的使用格式，acl_mapping 是配置acl信息的同步方式，target_path是配置元數據在目的處的存放點。以下圖所示爲一個實際使用的配置，它表示配置了aws zone，採用path-style這種域名格式，target_path是rgw加其所在zonegroup的名字並加上它的user_id，以後是它的bucket名字，最終這個object在雲端的路徑就是target_path加上object名字。

後續工做

根據社區的規劃，關於RGW Cloud Sync方面的後續工做主要有如下四項：

同步狀態顯示的優化，好比顯示落後的datalog、bucket、object等，同時將一些同步過程當中發生的錯誤上報至Monitor

數據的反向同步，即支持將公有云的數據同步至RGW

支持將RGW的數據導入更多的公有云平臺，而不是僅僅支持S3協議的平臺

在此基礎之上以RGW爲橋樑來實現不一樣雲平臺之間的數據同步