帶你讀《存儲漫談Ceph原理與實踐》第三章接入層3.2對象存儲RGW（二）

3.2.2     RGW 架構

對象存儲 S3為 AWS早在 2006年推出的 IaaS服務，如今對象存儲已經成為整個網際網路行業非結構化資料存儲的底座。Ceph中的 RGW服務實作了對AWSS3接口的相容，CephRGW經過 10餘年的發展，如今已經成為對AWSS3 特性相容最全面的開源實作。任何對對象存儲實作感興趣的人都能從了解 CephRGW中受益。

RGW最初叫 s3gw，由 YehudaSadeh 主導設計，在 Ceph代碼 git 倉庫中可以追溯到的最早涉及 s3gw的送出時間為 2009 年。遵從社群所追求的通用設計理念，s3gw更名為RGW，後續也實作了對 OpenStackSwift協定的相容。

1.  實作架構

Ceph本身采用分層的架構，RAODS層中的 OSD 程序負責切片後對象資料和中繼資料的持久化存儲，作為 RADOS層用戶端存在的RGW 程序負責處理對象存儲的業務邏輯。

本章節隻分析 RGW單個元件的架構，不再贅述 Ceph 存儲系統的整體架構。

對象存儲作為對外提供HTTP（s）協定接入的服務，其邏輯有明顯的分層架構設計思路。按照 HTTP（s）請求處理階段，涉及的層有以下幾個。

（1） 負責解析和驗證 HTTP（s）請求的協定解析層。

（2）負責對解析後的對象存儲業務請求進行處理的業務邏輯層。

（3）負責對對象存儲資料和中繼資料進行持久化存取的資料持久化層。接下來逐層看看細節。

2.  協定解析層

協定解析層本質上就是 HTTP伺服器的實作，RGW提供了靈活的插件式 HTTP伺服器實作，具備以下特性。

◆  最早實作的相容 FCGI協定的 FCGIHTTP 伺服器前端。

◆  基于 C++HTTP服務端庫 civetweb 實作的伺服器前端。

◆ 基于 C++boostHTTP 标準庫 beast 實作的伺服器前端，也是預設配置使用的 HTTP伺服器。

協定解析層的主要工作内容就是解析對象存儲的 HTTP請求。對于請求認證需求，

RGW提供了以插件化方式實作的 AWSS3v2/v4類型認證以及通過外部 Keystone/LDAP元件進行認證兩種方法。

在解析HTTP協定時，協定解析層會處理Swift和S3兩種不同的對象存儲“方言”，最終将HTTP請求統一抽象成對象存儲的Op（operation）。

3.  業務邏輯層

業務邏輯層負責對象存儲Op的處理，RGW為 Op定義了統一的處理“工序”。

（1） init_processing：初始化；

（2） verify_op_mask：驗證請求的讀寫掩碼；

（3） verify_permission：驗證請求的權限；

（4） verify_params：驗證請求參數；

（5） pre_exec：執行請求的預處理；

（6） execute：處理請求；

（7） complete：執行請求完成後的後續處理。

對象存儲的業務複雜性導緻每個   Op   在進行中都涉及如配額檢查、權限控制、權限政策檢查等業務邏輯的處理，在 RGW中定義了Service 元件來提供對象存儲語義的調用接口。

對于需要多個 Service 組合構造的更複雜的對象存儲語義，RGW提供了 Control這樣的構造。

我們通過一個具體的例子來了解 RGW 業務邏輯子產品化而引入的強大抽象：Service元件和 Control元件。

對于建立 User的 Bucket來說，涉及 User和 Bucket兩個概念，對于 User的操作抽象成單獨的UserService，Bucket的操作抽象成單獨的 BucketService。兩個Service不需要知道彼此的存在，是以抽象出 Control 來提供更高層級的 API，Control元件内部再調用 Service提供的服務接口。

每個 Service都有一個關聯的 backendtype，目前支援SOBJ、OTP類型，不同類型的 backendtype意味着不同的資料持久化方式。目前 RGW 需要的資料和中繼資料存儲都是基于 RADOS實作持久化的，後續持久化資料還可以儲存到類似MySQL這樣的關系型資料庫當中。

在沒有引入 Service之前，在 RGW 中開發需要操作對象或者桶的特定功能時，通常是直接操作用來儲存特定功能資訊的RAODS對象（使用者資料切片後的對象，也就是所謂的system-object，差別于使用者可見的業務層面檔案資料rgw-object）。在引入Service之後，意味着通過為 Service實作新的 backendtype存儲類型，CephRGW可以發展為和Minio一樣的項目，即成為一個與 CephRADOS 無關的獨立對象存儲網關，社群目前正在推進的 RGW 持久化後端存儲插件化的改造（也就是 zipper計劃），正是為推動 RGW發展，實作這一目标而開展的。

4.  資料持久化層

前文多次提到了 RADOS，RADOS 提供的資料存儲接口是對象形式的。從使用者的角度來講，直接用 librados就能使用“對象存儲”。其實 RGW中的“對象”和 RADOS中的“對象”是兩個概念。

首先來看對象存儲服務，也就是 AWSS3标準中的對象，它在 RGW中簡稱 rgw-object，它的特點如下。

◆  rgw-object 可以非常大，比如單個 rgw-object 檔案大小可以高達 5TB。

◆  rgw-object 是不可變的，即一旦寫入，不可修改。

◆  對同一桶中的 rgw-object，Ceph 維護了有序的索引。

◆  rgw-object 在權限控制上支援豐富的語義，如存儲桶政策、ACL等。

◆  rgw-object通過 HTTP 協定通路。

而 CephRADOS 層的對象，簡稱 Object，它的特點如下。

◆  有限的大小，比如預設配置下，其大小通常為 4MB。

◆  Object 是可變的，即寫入後，允許修改。

◆  RADOS不單獨為 Object 維護有序索引。

◆  不支援 Object 級别的 ACL 控制。

◆  Object通過 socket 協定通路。

對比之後會發現，RGW提供的rgw-object要比RADOS提供的Object的語義更加豐富。

RADOS提供了非常清晰的通路接口， 對外暴露Pool和 Object， 以及 Object的OMAP和 xattr。建立在 RADOS 之上的應用都要确定一個所謂的資料布局的問題，對于RGW來說，就是如何将 rgw-object映射到 RADOS叢集特定 Pool的特定 Object。這部分關鍵的中繼資料被稱為 manifest。

總結一下，RGW在邏輯上需要持久化的資料分 3類。

（1） Metadata，表示系統或者桶、對象的中繼資料，按照 ObjectOMAP的形式儲存。

（2） bucketindex，儲存存儲桶中對象的清單，按照 ObjectOMAP的形式儲存。

（3） data，儲存 rgw-object的實際資料，按照 Object資料的形式儲存。

其中 Metadata 以單獨的存儲池進行存儲，按照功能類别，Metadata一部分是業務邏輯層中的Service元件和 Control 元件使用，另一部分則是儲存系統運作需要的各類日志資訊。這些存儲池的名字空間如下。

◆  業務邏輯類：

.rgw.meta:root、.rgw.meta:heap、.rgw.meta:users.keys、.rgw.meta:users.email、.rgw.meta:users.swift、.rgw.meta:users.uid、.rgw.meta:roles。

◆  日志資訊類：

.rgw.log:gc、.rgw.log:lc、.rgw.log:bl、.rgw.log、.rgw.log:intent、.rgw.log:usage。