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服務器在面臨如網絡中斷或者驅動器故障等臨時性故障情況時可以保持系統的一致性。

?

　　圖2 隔離對象的處理流圖

　　Ring

　　Ring是Swift最重要的組件，用于記錄存儲對象與物理位置間的映射關系。在涉及查詢Account、Container、Object信息時，就需要查詢集群的Ring信息。 Ring使用Zone、Device、Partition和Replica來維護這些映射信息。Ring中每個Partition在集群中都(默認)有3個Replica。每個Partition的位置由Ring來維護，并存儲在映射中。Ring文件在系統初始化時創建，之后每次增減存儲節點時，需要重新平衡一下Ring文件中的項目，以保證增減節點時，系統因此而發生遷移的文件數量最少。

　　原理

　　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將得到更廣泛的應用。