OpenStack Swift 簡介

目錄

• 目錄
• 1、OpenStack Swift 是什麼?
• 2、Swift Request
  • 2.1 Account
  • 2.2 Container
  • 2.3 Object
  • 2.4 Object URL 組成
• 3、Swift Processes
  • 3.1 Proxy Layer
  • 3.2 Account Layer
  • 3.3 Container Layer
  • 3.4 Object Layer
• 4、Swift Consistency Services
  • 4.1 Auditor
  • 4.2 Replicator
• 5、Swift Cluster 分群概念
• 6、Swift 資料存取設計
  • 6.1 Partition
  • 6.2 Ring
• 7、Switch 完整架構
• 8、參考資料

1、OpenStack Swift 是什麼?

以下截至 StackSwift 的定義：

OpenStack Swift is a multi-tenant, highly scalable and durable object storage system that was designed to store large amounts of unstructured data at low cost via a RESTful HTTP API.

從上述簡單的定義，無法完全表達 Swift 的強大，因此以下列出 Swift 的特色：

• open source & 免費。
• 目前有許多大型的 object storage 雲端服務使用 Swift (例如：Rackspace、Cloud Files、HP Cloud … etc)。
• Swift 可以單獨提供 storage 服務，也可以與其他的雲端環境進行整合。
• 只要是標準的 x86 架構的硬體，搭配標準的 Linux 系統，就可以運行 Swift。
• Swift 跟 Amazon S3 相同，提供最終一致性(eventual consistency)，因此也提供了強大的水平擴展能力。
• 所有儲存在 Swift 的物件、檔案都有一個 URL。
• 提供標準的 RESTful HTTP API，因此非常合適作為經由 web-based 存取資料的用戶端、裝置、應用程式。
• 儲存於 Swift 的物件可以擁有可擴展性的 metadata，可用來有效率的進行索引 & 搜尋。
• 所有儲存在 Swift 的物件都會有多個複本存在於其他的 Zone or Region。
• Swift 透過增加額外的節點就可以很簡單的進行擴展。
• 當增加或更換硬體時，不需要將原本的資料移動到其他的節點內。
• 在 Swift 運行中，可隨時增加 or 移除節點。
• 設計在低成本的前提下，可儲存超大量非結構性資料(檔案、圖片、影像 … 等等)。

2、Swift Request

Swift 有個重要特性：

所有儲存在 Swift 的物件、檔案都有一個 URL，並可透過 HTTP RESTful API 存取

接著來看看實際上 object 是如何存放在 Swift 中的，用下圖來說明：

上圖一共有三個部分，分別是：

2.1 Account

Account storage 在整個 Swift storage 中是一個獨一無二的名稱，但 Account storage 在概念上並不屬於特定使用者的帳號 or 認證資訊，而是屬於儲存區域(storage area)的概念。
在 Account storage 中，包含了與 Account 相關的 metadata 之外，就是儲存包含在此 Account 內的 Container 資訊。

2.2 Container

Container storage 則是屬於使用者自行定義的儲存區域，除了包含一些與 Container 本身相關的 metadata 之外，裡面主要就是 object 存放的地方。

2.3 Object

Object storage 存放的資料除了檔案本身之外，還包含了與檔案相關的 metadata。

2.4 Object URL 組成

有了 Account / Container / Object 三種概念後，就可以進一步來了解每個 object 的 URL 組成，每個 object 都會有一個專屬的 URL 可供存取，結構如下：

https://swift.example.com/v1/account/container/object

其中 URL 結構包含兩個主要部分：

• Cluster 位置：也就是 https://swift.example.com/v1/
• object 位置：/account/container/object

3、Swift Processes

只要有運行 Swift process 或是 service 的機器，稱為 “node”。
運行 Proxy server process 的機器稱為 Proxy Node。
運行 Account / Container / Object process 的機器稱為 Storage Node。(當然也另外包含了處理資料一致性的 consistent service)
以下可以用一張簡單的圖說明 proxy node & storage node 在處理資料時的關係：

3.1 Proxy Layer

Proxy server process 是 Swift 中直接與外部的 client 連線的部分，用來處理來自外部的 HTTP request & response。
在整個架構中建議至少使用兩個 proxy node，以避免 single point failure 的狀況發生。
當 proxy server 收到 client request 後，會決定某個 storage node 來處理，收到 storage node 處理完的通知後會再回應給 client。

3.2 Account Layer

Account server process 用來處理與 Account 相關的 metadata & Account 內所包含的 Container 資訊，而這些資訊是存放再 Account server process 所在機器內的 SQLite 資料庫中。

3.3 Container Layer

Container server process 用來處理 Container metadata & 包含在內的 object 資訊需求，這些資料同樣也是存在 Container server process 所在機器內的 SQLite 的資料庫中。

3.4 Object Layer

Object server process 負責實際檔案的儲存，檔案是以二進位的方式儲存於磁碟中。
除了二進位資料外，還包含了很重要的時間戳記(timestamp)資訊，時間戳記資訊可以讓 Swift 同時儲存多種不同版本的檔案，
而 object 的 metadata 則是以副檔名 xattrs 的方式，與 object 儲存在一起，Swift 會負責將這些資料複製到多個不同節點上。

4、Swift Consistency Services

為了確保每個 storage node 之間的資料一致，Swift 提供了兩個重要的 Service，分別是 Auditor & Replicator。

4.1 Auditor

Auditor service 運作在每一個 storage node 中，持續掃描磁碟確認沒有任何錯誤的發生，若是有錯誤發生，Auditor service 就會將有問題的 object 移到隔離區。

每一個 process(Account / Container / Object) 都有專屬的 Auditor 進行資料檢查之用。

4.2 Replicator

同樣的 Account / Container / Object process 也都有相對應的 replicator，功能主要用來確保本地端的資料與 Cluster 中其他 storage node 的資料是一致的。
比較需要注意的是，replicator service 只會將新的資料送到其他的 storage node，而不會從其他的 storage node 抓取新資料回來更新本地端資料。
而 replicator service 是透過 checksum 的方式來達到各 storage node 資料的一致：

5、Swift Cluster 分群概念

Swift 是由一堆 proxy node & storage node 所組成，為了容易區分，因此有 Region & Zone 兩種邏輯上的分群概念。
以下直接用一張圖來說明 Region & Zone 的樣子：

Zone 是由多個 storage node 所組成，一般常用來作為資料中心內部同機櫃的分類之用，或是用來將特別用途的 node 歸類之用。
Region 則是由多個 Zone 組成，一般常用來區分不同區域的資料中心。

Region & Zone 是可以隨使用者自行定義的，上述只是範例而已。

6、Swift 資料存取設計

6.1 Partition

Swift 為了有效的跨 storage node 來存放資料，並可以達到快速存取的目的，在資料存放的模型有經過特別設計，以下用一張簡單的圖來說明：

從上圖可以看到有三種元素，分別是：

1. Storage Node
2. Disk
3. Partition

每個 Storage node 可能會有好幾個 Disk。
而 Partition 在這邊並不是傳統磁碟分割的概念來看，而是應該把它當作是 Disk 的一個目錄的概念來看，所以一個 Disk 會有很多個 Partition。
Partition 是 Swift process 處理的最小單位，也是資料實際存放的地方，而 consistency process 則是以 partition 為單位在檢查資料的一致性，資料在不同的硬碟(or 設備)間移動也是以 partition 為單位。
透過以 paritition 為單位來處理的方式，Swift 可以減少 process & 網路的負擔。

6.2 Ring

Ring 在 Swift 架構中是個相當重要的部分，它是一個映射(mapping)檔案，由一致性的 hash 演算法所產生，種類有三種，分別是 Account Ring / Container Ring / Object Ring。
透過 Ring 就可以知道每一個 object 實際對應到的 Account & Container & 實際存放的位置(partition)，如下圖：

Ring 存在於 Swift Storage Cluster 中的每一個 node 中，透過 Ring，可以確保每個 object 在 Swift Storage Cluster 中有多個複本存在於不同的 storage 內，也可以確保後續可以進行快速的存取。
透過維持一致性的 Ring，Swift Storage Cluster 不僅避免了單點錯誤的狀況發生，提升存取的速度，也大大的增加水平擴展的能力。

7、Switch 完整架構

最後來個 Swift Storage Cluster 的完整架構概觀：

• Proxy Server 是直接接受來自 client 請求的部分。
• Proxy Server 收到 client 請求後，會透過 Ring 快速地進行 object 的存取 or 將資料同步到不同的 Object Server(storage node) 上。
• 不同的 Object Server 可能會根據不同的規劃(地理區域、服務對象、功能性….等)，區分成不同的 Zone(or Region) 作為管理之用。

8、參考資料

• OpenStack Swift | SwiftStack
• OpenStack Swift Tech Brief | SwiftStack
• OpenStack Swift Architecture | SwiftStack
• Zmanda - OpenStack Swift 雲端存儲架構說明(一)
• Hugo Pot: OpenStack Swift (ep0) - 進化的儲存系統與需求
• 黑毛到白毛的攻城獅之路: OpenStack Swift 的儲存結構最佳化
• 蕃薯的筆記本: 從Hadoop到OpenStack Swift 再到Ceph
• 深入雲存儲系統Swift核心組件：Ring實現原理剖析_人人IT網-StackDoc
• 深入雲存儲系統Swift核心組件：Ring數據結構及構建、重平衡操作_人人IT網-StackDoc
• 多租戶技術 - 維基百科，自由的百科全書