OpenStack物件存儲——Swift開源雲計算

OpenStack Object Storage(Swift)是OpenStack開源雲計算專案的子專案之一，被稱為物件存儲，提供了強大的擴充性、冗余和持久性。 本文將從架構、原理和實踐等幾方面講述Swift。 Swift並不是檔案系統或者即時的資料存儲系統，它稱為物件存儲，用於永久類型的靜態資料的長期存儲，這些資料可以檢索、調整，必要時進行更新。 最適合存儲的資料類型的例子是虛擬機器鏡像、圖片存儲、郵件存儲和存檔備份。 因為沒有中心單元或主控結點，Swift提供了更強的擴充性、冗余和持久性。 Swift前身是Rackspace Cloud Files專案，隨著Rackspace加入到OpenStack社區，于2010年7月貢獻給OpenStack，作為該開源專案的一部分。 Swift目前的最新版本是OpenStack Essex 1.5.1。

新浪SAE團隊對Swift有將近一年的研究和運營經驗。 在深入剖析Swift架構和原理、完全掌握Swift源碼，並且經過一段時間的測試和運營之後，我們決定將推出基於Swift的SAE Storage服務。 目前，已完成開發，並于一個月前開始線上運行，且表現非常出色。 因此，下面將分享一下我們在Swift上的一些研究和工作。

Swift特性

在OpenStack官網中，列舉了Swift的20多個特性，其中最引人關注的是以下幾點。

極高的資料持久性

一些朋友經常將資料持久性(Durability)與系統可用性(Availability)兩個概念混淆，前者也理解為數據的可靠性，是指資料存儲到系統中後，到某一天資料丟失的可能性。 例如Amazon S3的資料持久性是11個9，即如果存儲1萬(4個0)個檔到S3中，1千萬(7個0)年之後，可能會丟失其中1個檔。 那麼Swift能提供多少個9的SLA呢？ 下文會給出答案。 針對Swift在新浪測試環境中的部署，我們從理論上測算過，Swift在5個Zone、5×10個存儲節點的環境下，資料複製份是為3，資料持久性的SLA能達到10個9。

完全對稱的系統架構

「對稱」意味著Swift中各節點可以完全對等，能極大地降低系統維護成本。

無限的可擴充性

這裡的擴充性分兩方面，一是資料存儲容量無限可擴展;二是Swift性能(如QPS、輸送量等)可線性提升。 因為Swift是完全對稱的架構，擴容只需簡單地新增機器，系統會自動完成資料移轉等工作，使各存儲節點重新達到平衡狀態。

無單點故障

在互聯網業務大規模應用的場景中，存儲的單點一直是個難題。 例如資料庫，一般的HA方法只能做主從，並且「主」一般只有一個;還有一些其他開源存儲系統的實現中，中繼資料資訊的存儲一直以來是個頭痛的地方，一般只能單點存儲，而這個單點很容易成為瓶頸，並且一旦這個點出現差異， 往往能影響到整個集群，典型的如HDFS。 而Swift的中繼資料存儲是完全均勻隨機分佈的，並且與目的檔存儲一樣，中繼資料也會存儲多份。 整個Swift集群中，也沒有一個角色是單點的，並且在架構和設計上保證無單點業務是有效的。

簡單、可依賴

簡單體現在架構優美、代碼整潔、實現易懂，沒有用到一些高深的分散式存儲理論，而是很簡單的原則。 可依賴是指Swift經測試、分析之後，可以放心大膽地將Swift用於最核心的存儲業務上，而不用擔心Swift捅簍子，因為不管出現任何問題，都能通過日誌、閱讀代碼迅速解決。

應用場景

Swift提供的服務與Amazon S3相同，適用于許多應用場景。 最典型的應用是作為網盤類產品的儲存引擎，比如Dropbox背後就是使用Amazon S3作為支撐的。 在OpenStack中還可以與鏡像服務Glance結合，為其存儲鏡像檔案。 另外，由於Swift的無限擴展能力，也非常適合用於存儲日誌檔和資料備份倉庫。

Swift架構概述

Swift主要有三個組成部分：Proxy Server、Storage Server和Consistency Server。 其架構如圖1所示，其中Storage和Consistency服務均允許在Storage Node上。 Auth認證服務目前已從Swift中剝離出來，使用OpenStack的認證服務Keystone，目的在於實現統一OpenStack各個專案間的認證管理。

圖1 Swift部署架構

主要元件

Proxy Server

Proxy Server是提供Swift API的伺服器進程，負責Swift其餘元件間的相互通信。 對於每個用戶端的請求，它將在Ring中查詢Account、Container或Object的位置，並且相應地轉發請求。 Proxy提供了Rest-full API，並且符合標準的HTTP協定規範，這使得開發者可以快捷構建定制的Client與Swift交互。

Storage Server

Storage Server提供了磁片設備上的存儲服務。 在Swift中有三類存儲伺服器：Account、Container和Object。 其中Container伺服器負責處理Object的清單，Container伺服器並不知道物件存放位置，只知道指定Container裡存的哪些Object。 這些Object資訊以sqlite資料庫檔案的形式存儲。 Container伺服器也做一些跟蹤統計，例如Object的總數、Container的使用方式。

Consistency Servers

在磁片上存儲資料並向外提供Rest-ful API並不是難以解決的問題，最主要的問題在於故障處理。 Swift的Consistency Servers的目的是查找並解決由資料損壞和硬體故障引起的錯誤。 主要存在三個Server：Auditor、Updater和Replicator。 Auditor運行在每個Swift伺服器的後臺持續地掃描磁片來檢測物件、Container和帳號的完整性。 如果發現資料損壞，Auditor就會將該檔移動到隔離區域，然後由Replicator負責用一個完好的拷貝來替代該資料。 圖2給出了隔離物件的處理流圖。 在系統高負荷或者發生故障的情況下，Container或帳號中的資料不會被立即更新。 如果更新失敗，該次更新在本地檔案系統上會被排入佇列，然後Updaters會繼續處理這些失敗了的更新工作，其中由Account Updater和Container Updater分別負責Account和Object清單的更新。 Replicator的功能是處理資料的存放位置是否正確並且保持資料的合理拷貝數，它的設計目的是Swift伺服器在面臨如網路中斷或者磁碟機故障等臨時性故障情況時可以保持系統的一致性。

Ring

Ring是Swift最重要的元件，用於記錄存儲物件與物理位置間的映射關係。 在涉及查詢Account、Container、Object資訊時，就需要查詢集群的Ring資訊。 Ring使用Zone、Device、Partition和Replica來維護這些映射資訊。 Ring中每個Partition在集群中都(預設)有3個Replica。 每個Partition的位置由Ring來維護，並存儲在映射中。 Ring檔在系統初始化時創建，之後每次增減存儲節點時，需要重新平衡一下Ring檔中的專案，以保證增減節點時，系統因此而發生遷移的檔數量最少。

圖2 隔離物件的處理流圖

原理

Swift用到的演算法和存儲理論並不複雜，主要有幾下幾個概念。

一致性雜湊演算法

Swift利用一致性雜湊演算法構建了一個冗余的可擴展的分散式物件存儲集群。 Swift採用一致性雜湊的主要目的是在改變集群的Node數量時，能夠盡可能少地改變已存在Key和Node的映射關係。 該演算法的思路分為以下三個步驟。 首先計算每個節點的雜湊值，並將其分配到一個0~232的圓環區間上。 其次使用相同方法計算存儲物件的雜湊值，也將其分配到這個圓環上。 隨後從資料對應到的位置開始順時針查找，將資料保存到找到的第一個節點上。 如果超過232仍然找不到節點，就會保存到第一個節點上。 假設在這個環形雜湊空間中存在4台Node，若增加一台Node5，根據演算法得出Node5被映射在Node3和Node4之間，那麼受影響的將僅是沿Node5逆時針遍歷到Node3之間的物件(它們本來映射到Node4上)。 其分佈如圖3所示。

圖3 一致性雜湊環結構

Replica

如果集群中的資料在本地節點上只有一份，一旦發生故障就可能會造成資料的永久性丟失。 因此，需要有冗余的副本來保證資料安全。 Swift中引入了Replica的概念，其預設值為3，理論依據主要來源於NWR策略(也叫Quorum協定)。 NWR是一種在分散式存儲系統中用於控制一致性級別的策略。 在Amazon的Dynamo雲存儲系統中，使用了NWR來控制一致性。 其中，N代表同一份資料的Replica的份數，W是更新一個資料物件時需要確保成功更新的份數; R代表讀取一個資料需要讀取的Replica的份數。 公式W+R>N，保證某個資料不被兩個不同的事務同時讀和寫;公式W>N/2保證兩個事務不能併發寫某一個資料。 在分散式系統中，資料的單點是不允許存在的。 即線上正常存在的Replica數量為1的情況是非常危險的，因為一旦這個Replica再次出錯，就可能發生資料的永久性錯誤。 假如我們把N設置成為2，那麼只要有一個存儲節點發生損壞，就會有單點的存在，所以N必須大於2。 N越高，系統的維護成本和整體成本就越高。 工業界通常把N設置為3。 例如，對於MySQL主從結構，其NWR數值分別是N= 2， W = 1， R = 1，沒有滿足NWR策略。 而Swift的N=3， W=2， R=2，完全符合NWR策略，因此Swift系統是可靠的，沒有單點故障。

Zone

如果所有的Node都在一個機架或一個機房中，那麼一旦發生斷電、網路故障等，都將造成使用者無法訪問。 因此需要一種機制對機器的物理位置進行隔離，以滿足分區容忍性(CAP理論中的P)。 因此，Ring中引入了Zone的概念，把集群的Node分配到每個Zone中。 其中同一個Partition的Replica不能同時放在同一個Node上或同一個Zone內。 注意，Zone的大小可以根據業務需求和硬體條件自訂，可以是一塊磁片、一台存儲伺服器，也可以是一個機架甚至一個IDC。

Weight

Ring引入Weight的目的是解決未來添加存儲能力更大的Node時，分配到更多的Partition。 例如，2TB容量的Node的Partition數為1TB的兩倍，那麼就可以設置2TB的Weight為200，而1TB的為100。

圖4 一種Swift部署集群

實例分析

圖4中是新浪SAE在測試環境中部署的Swift集群，集群中又分為5個Zone，每個Zone是一台存儲伺服器，每台伺服器上由12塊2TB的SATA磁片組成，只有作業系統安裝盤需要RAID，其他盤作為存儲節點，不需要RAID。 前面提到過，Swift採用完全對稱的系統架構，在這個部署案例中得到了很好的體現。 圖4中每個存儲伺服器的角色是完全對等的，系統組態完全一樣，均安裝了所有Swift服務套裝軟體，如Proxy Server、Container Server和Account Server等。 上面的負載均衡(Load Balancer)並不屬於Swift的套裝軟體，出於安全和性能的考慮，一般會在業務之前擋一層負載均衡設備。 當然可以去掉這層代理，讓Proxy Server直接接收使用者的請求，但這可能不太適合在生產環境中使用。 圖4中分別表示了上傳檔PUT和下載檔案GET請求的資料流程，兩個請求操作的是同一個物件。 上傳檔時，PUT請求通過負載均衡隨機挑選一台Proxy Server，將請求轉發到後者，後者通過查詢本地的Ring檔，選擇3個不同Zone中的後端來存儲這個檔，然後同時將該檔向這三個存儲節點發送檔。 這個過程需要滿足NWR策略(Quorum Protocol)，即3份存儲，寫成功的份數必須大於3/2，即必須保證至少2份資料寫成功，再給使用者返回檔寫成功的消息。 下載檔案時，GET請求也通過負載均衡隨機挑選一台Proxy Server，後者上的Ring檔能查詢到這個檔存儲在哪三個節點中，然後同時去向後端查詢，至少有2個存儲節點「表示」可以提供該檔，然後Proxy Server從中選擇一個節點下載檔案。

小結

Swift簡單、冗余、可擴展的架構設計保證了它能夠用於IaaS的基礎服務。 在Rackspace Cloud Files服務兩年的運行積累使得Swift代碼變得越來越成熟，目前已部署在全球各地的公有雲、私有雲服務中。 隨著OpenStack的不斷完善和發展，Swift將得到更廣泛的應用。