在 IBM Bluemix 雲平臺上開發並部署您的下一個應用。

OpenStack Swift 原理、架構與 API 介紹

回頁首

背景與概覽

Swift 最初是由 Rackspace 公司開發的高可用分散式物件儲存服務，並於 2010 年貢獻給 OpenStack 開源社群作為其最初的核心子專案之一，為其 Nova 子專案提供虛機映象儲存服務。Swift 構築在比較便宜的標準硬體儲存基礎設施之上，無需採用 RAID（磁碟冗餘陣列），通過在軟體層面引入一致性雜湊技術和資料冗餘性，犧牲一定程度的資料一致性來達到高可用性和可伸縮性，支援多租戶模式、容器和物件讀寫操作，適合解決網際網路的應用場景下非結構化資料儲存問題。

此專案是基於 Python 開發的，採用 Apache 2.0 許可協議，可用來開發商用系統。

回頁首

基本原理

一致性雜湊（Consistent Hashing)

面對海量級別的物件，需要存放在成千上萬臺伺服器和硬碟裝置上，首先要解決定址問題，即如何將物件分佈到這些裝置地址上。Swift 是基於一致性雜湊技術，通過計算可將物件均勻分佈到虛擬空間的虛擬節點上，在增加或刪除節點時可大大減少需移動的資料量；虛擬空間大小通常採用 2 的 n 次冪，便於進行高效的移位操作；然後通過獨特的資料結構 Ring（環）再將虛擬節點對映到實際的物理儲存裝置上，完成定址過程。

圖 1. 一致性雜湊

如圖 1 中所示，以逆時針方向遞增的雜湊空間有 4 個位元組長共 32 位，整數範圍是[0~232-1]；將雜湊結果右移 m 位，可產生 232-m個虛擬節點，例如 m=29 時可產生 8 個虛擬節點。在實際部署的時候需要經過仔細計算得到合適的虛擬節點數，以達到儲存空間和工作負載之間的平衡。

資料一致性模型（Consistency Model）

按照 Eric Brewer 的 CAP（Consistency，Availability，Partition Tolerance）理論，無法同時滿足 3 個方面，Swift 放棄嚴格一致性（滿足 ACID 事務級別），而採用最終一致性模型（Eventual Consistency），來達到高可用性和無限水平擴充套件能力。為了實現這一目標，Swift 採用 Quorum 仲裁協議(Quorum 有法定投票人數的含義)：

（1）定義：N：資料的副本總數；W：寫操作被確認接受的副本數量；R：讀操作的副本數量

（2）強一致性：R+W>N，以保證對副本的讀寫操作會產生交集，從而保證可以讀取到最新版本；如果 W=N，R=1，則需要全部更新，適合大量讀少量寫操作場景下的強一致性；如果 R=N，W=1，則只更新一個副本，通過讀取全部副本來得到最新版本，適合大量寫少量讀場景下的強一致性。

（3）弱一致性：R+W<=N，如果讀寫操作的副本集合不產生交集，就可能會讀到髒資料；適合對一致性要求比較低的場景。

Swift 針對的是讀寫都比較頻繁的場景，所以採用了比較折中的策略，即寫操作需要滿足至少一半以上成功 W >N/2，再保證讀操作與寫操作的副本集合至少產生一個交集，即 R+W>N。Swift 預設配置是 N=3，W=2>N/2，R=1 或 2，即每個物件會存在 3 個副本，這些副本會盡量被儲存在不同區域的節點上；W=2 表示至少需要更新 2 個副本才算寫成功；當 R=1 時意味著某一個讀操作成功便立刻返回，此種情況下可能會讀取到舊版本（弱一致性模型）；當 R=2 時，需要通過在讀操作請求頭中增加 x-newest=true 引數來同時讀取 2 個副本的元資料資訊，然後比較時間戳來確定哪個是最新版本（強一致性模型）；如果資料出現了不一致，後臺服務程序會在一定時間視窗內通過檢測和複製協議來完成資料同步，從而保證達到最終一致性。如圖 2 所示：

圖 2. Quorum 協議示例

環的資料結構

環是為了將虛擬節點（分割槽）對映到一組物理儲存裝置上，並提供一定的冗餘度而設計的，其資料結構由以下資訊組成：

• 儲存裝置列表、裝置資訊包括唯一標識號（id）、區域號（zone）、權重（weight）、IP 地址（ip）、埠（port）、裝置名稱（device）、元資料（meta）。
• 分割槽到裝置對映關係（replica2part2dev_id 陣列)
• 計算分割槽號的位移(part_shift 整數，即圖 1 中的 m)

以查詢一個物件的計算過程為例：

圖 3. 環的資料機構

使用物件的層次結構 account/container/object 作為鍵，使用 MD5 雜湊演算法得到一個雜湊值，對該雜湊值的前 4 個位元組進行右移操作得到分割槽索引號，移動位數由上面的 part_shift 設定指定；按照分割槽索引號在分割槽到裝置對映表（replica2part2dev_id）裡查詢該物件所在分割槽的對應的所有裝置編號，這些裝置會被儘量選擇部署在不同區域（Zone）內，區域只是個抽象概念，它可以是某臺機器，某個機架，甚至某個建築內的機群，以提供最高級別的冗餘性，建議至少部署 5 個區域；權重引數是個相對值，可以來根據磁碟的大小來調節，權重越大表示可分配的空間越多，可部署更多的分割槽。

Swift 為賬戶，容器和物件分別定義了的環，查詢賬戶和容器的是同樣的過程。

資料模型

Swift 採用層次資料模型，共設三層邏輯結構：Account/Container/Object（即賬戶/容器/物件)，每層節點數均沒有限制，可以任意擴充套件。這裡的賬戶和個人賬戶不是一個概念，可理解為租戶，用來做頂層的隔離機制，可以被多個個人賬戶所共同使用；容器代表封裝一組物件，類似資料夾或目錄；葉子節點代表物件，由元資料和內容兩部分組成，如圖 4 所示：

圖 4. Swift 資料模型

回頁首

系統架構

Swift 採用完全對稱、面向資源的分散式系統架構設計，所有元件都可擴充套件，避免因單點失效而擴散並影響整個系統運轉；通訊方式採用非阻塞式 I/O 模式，提高了系統吞吐和響應能力。

圖 5. Swift 系統架構

Swift 元件包括：

• 代理服務（Proxy Server）：對外提供物件服務 API，會根據環的資訊來查詢服務地址並轉發使用者請求至相應的賬戶、容器或者物件服務；由於採用無狀態的 REST 請求協議，可以進行橫向擴充套件來均衡負載。
• 認證服務（Authentication Server）：驗證訪問使用者的身份資訊，並獲得一個物件訪問令牌（Token），在一定的時間內會一直有效；驗證訪問令牌的有效性並快取下來直至過期時間。
• 快取服務（Cache Server）：快取的內容包括物件服務令牌，賬戶和容器的存在資訊，但不會快取物件本身的資料；快取服務可採用 Memcached 叢集，Swift 會使用一致性雜湊演算法來分配快取地址。
• 賬戶服務（Account Server）：提供賬戶元資料和統計資訊，並維護所含容器列表的服務，每個賬戶的資訊被儲存在一個 SQLite 資料庫中。
• 容器服務（Container Server）：提供容器元資料和統計資訊，並維護所含物件列表的服務，每個容器的資訊也儲存在一個 SQLite 資料庫中。
• 物件服務（Object Server）：提供物件元資料和內容服務，每個物件的內容會以檔案的形式儲存在檔案系統中，元資料會作為檔案屬性來儲存，建議採用支援擴充套件屬性的 XFS 檔案系統。
• 複製服務（Replicator）：會檢測本地分割槽副本和遠端副本是否一致，具體是通過對比雜湊檔案和高階水印來完成，發現不一致時會採用推式（Push）更新遠端副本，例如物件複製服務會使用遠端檔案拷貝工具 rsync 來同步；另外一個任務是確保被標記刪除的物件從檔案系統中移除。
• 更新服務（Updater）：當物件由於高負載的原因而無法立即更新時，任務將會被序列化到在本地檔案系統中進行排隊，以便服務恢復後進行非同步更新；例如成功建立物件後容器伺服器沒有及時更新物件列表，這個時候容器的更新操作就會進入排隊中，更新服務會在系統恢復正常後掃描佇列並進行相應的更新處理。
• 審計服務（Auditor）：檢查物件，容器和賬戶的完整性，如果發現位元級的錯誤，檔案將被隔離，並複製其他的副本以覆蓋本地損壞的副本；其他型別的錯誤會被記錄到日誌中。
• 賬戶清理服務（Account Reaper）：移除被標記為刪除的賬戶，刪除其所包含的所有容器和物件。

回頁首

API

Swift 通過 Proxy Server 向外提供基於 HTTP 的 REST 服務介面，對賬戶、容器和物件進行 CRUD 等操作。在訪問 Swift 服務之前，需要先通過認證服務獲取訪問令牌，然後在傳送的請求中加入頭部資訊 X-Auth-Token。下面是請求返回賬戶中的容器列表的示例：

GET /v1/<account> HTTP/1.1
Host: storage.swift.com
X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
響應頭部資訊中包含狀態碼 200，容器列表包含在響應體中：
HTTP/1.1 200 Ok
Date: Thu, 07 Jan 2013 18:57:07 GMT
Server: Apache
Content-Type: text/plain; charset=UTF-8
Content-Length: 32

images
movies
documents
backups

Swift 支援的所有操作可以總結為表 1：

表 1. Swift RESTful API 總結

詳細的 API 規範可以參考開發者指南。應用開發可採用 Swift 專案本身已經包含的 Python 的繫結實現；如果使用其它程式語言，可以參考 Rackspace 相容 Swift 的 Cloud Files API，支援 Java，.Net，Ruby，PHP 等語言繫結。

回頁首

結束語

OpenStack Swift 作為穩定和高可用的開源物件儲存被很多企業作為商業化部署，如新浪的 App Engine 已經上線並提供了基於 Swift 的物件儲存服務，韓國電信的 Ucloud Storage 服務。有理由相信，因為其完全的開放性、廣泛的使用者群和社群貢獻者，Swift 可能會成為雲端儲存的開放標準，從而打破 Amazon S3 在市場上的壟斷地位，推動雲端計算在朝著更加開放和可互操作的方向前進。