OpenStack Object Storage(Swift)是OpenStack開源云計算項目的子項目之一，被稱為對象存儲，提供了強大的擴展性、冗余和持久性。本文將從架構(gòu)、原理和實踐等幾方面講述Swift。 Swift并不是文件系統(tǒng)或者實時的數(shù)據(jù)存儲系統(tǒng)，它稱為對象存儲，用于永久類型的靜態(tài)數(shù)據(jù)的長期存儲，這些數(shù)據(jù)可以檢索、調(diào)整，必要時進行更新。最適合存儲的數(shù)據(jù)類型的例子是虛擬機鏡像、圖片存儲、郵件存儲和存檔備份。因為沒有中心單元或主控結(jié)點，Swift提供了更強的擴展性、冗余和持久性。Swift前身是Rackspace Cloud Files項目，隨著Rackspace加入到OpenStack社區(qū)，于2010年7月貢獻給OpenStack，作為該開源項目的一部分。Swift目前的最新版本是OpenStack Essex 1.5.1。

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

　　Swift特性

　　在OpenStack官網(wǎng)中，列舉了Swift的20多個特性，其中最引人關(guān)注的是以下幾點。

　　極高的數(shù)據(jù)持久性

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

　　完全對稱的系統(tǒng)架構(gòu)

　　“對稱”意味著Swift中各節(jié)點可以完全對等，能極大地降低系統(tǒng)維護成本。

　　無限的可擴展性

　　這里的擴展性分兩方面，一是數(shù)據(jù)存儲容量無限可擴展;二是Swift性能(如QPS、吞吐量等)可線性提升。因為Swift是完全對稱的架構(gòu)，擴容只需簡單地新增機器，系統(tǒng)會自動完成數(shù)據(jù)遷移等工作，使各存儲節(jié)點重新達到平衡狀態(tài)。

　　無單點故障

　　在互聯(lián)網(wǎng)業(yè)務(wù)大規(guī)模應(yīng)用的場景中，存儲的單點一直是個難題。例如數(shù)據(jù)庫，一般的HA方法只能做主從，并且“主”一般只有一個;還有一些其他開源存儲系統(tǒng)的實現(xiàn)中，元數(shù)據(jù)信息的存儲一直以來是個頭痛的地方，一般只能單點存儲，而這個單點很容易成為瓶頸，并且一旦這個點出現(xiàn)差異，往往能影響到整個集群，典型的如HDFS。而Swift的元數(shù)據(jù)存儲是完全均勻隨機分布的，并且與對象文件存儲一樣，元數(shù)據(jù)也會存儲多份。整個Swift集群中，也沒有一個角色是單點的，并且在架構(gòu)和設(shè)計上保證無單點業(yè)務(wù)是有效的。

　　簡單、可依賴

　　簡單體現(xiàn)在架構(gòu)優(yōu)美、代碼整潔、實現(xiàn)易懂，沒有用到一些高深的分布式存儲理論，而是很簡單的原則。可依賴是指Swift經(jīng)測試、分析之后，可以放心大膽地將Swift用于最核心的存儲業(yè)務(wù)上，而不用擔(dān)心Swift捅簍子，因為不管出現(xiàn)任何問題，都能通過日志、閱讀代碼迅速解決。

　　應(yīng)用場景

　　Swift提供的服務(wù)與Amazon S3相同，適用于許多應(yīng)用場景。最典型的應(yīng)用是作為網(wǎng)盤類產(chǎn)品的存儲引擎，比如Dropbox背后就是使用Amazon S3作為支撐的。在OpenStack中還可以與鏡像服務(wù)Glance結(jié)合，為其存儲鏡像文件。另外，由于Swift的無限擴展能力，也非常適合用于存儲日志文件和數(shù)據(jù)備份倉庫。

　　Swift架構(gòu)概述

　　Swift主要有三個組成部分：Proxy Server、Storage Server和Consistency Server。其架構(gòu)如圖1所示，其中Storage和Consistency服務(wù)均允許在Storage Node上。Auth認證服務(wù)目前已從Swift中剝離出來，使用OpenStack的認證服務(wù)Keystone，目的在于實現(xiàn)統(tǒng)一OpenStack各個項目間的認證管理。

?

　　圖1 Swift部署架構(gòu)

　　主要組件

　　Proxy Server

　　Proxy Server是提供Swift API的服務(wù)器進程，負責(zé)Swift其余組件間的相互通信。對于每個客戶端的請求，它將在Ring中查詢Account、Container或Object的位置，并且相應(yīng)地轉(zhuǎn)發(fā)請求。Proxy提供了Rest-full API，并且符合標(biāo)準(zhǔn)的HTTP協(xié)議規(guī)范，這使得開發(fā)者可以快捷構(gòu)建定制的Client與Swift交互。

　　Storage Server

　　Storage Server提供了磁盤設(shè)備上的存儲服務(wù)。在Swift中有三類存儲服務(wù)器：Account、Container和Object。其中Container服務(wù)器負責(zé)處理Object的列表，Container服務(wù)器并不知道對象存放位置，只知道指定Container里存的哪些Object。這些Object信息以sqlite數(shù)據(jù)庫文件的形式存儲。Container服務(wù)器也做一些跟蹤統(tǒng)計，例如Object的總數(shù)、Container的使用情況。

　　Consistency Servers

　　在磁盤上存儲數(shù)據(jù)并向外提供Rest-ful API并不是難以解決的問題，最主要的問題在于故障處理。Swift的Consistency Servers的目的是查找并解決由數(shù)據(jù)損壞和硬件故障引起的錯誤。主要存在三個Server：Auditor、Updater和Replicator。 Auditor運行在每個Swift服務(wù)器的后臺持續(xù)地掃描磁盤來檢測對象、Container和賬號的完整性。如果發(fā)現(xiàn)數(shù)據(jù)損壞，Auditor就會將該文件移動到隔離區(qū)域，然后由Replicator負責(zé)用一個完好的拷貝來替代該數(shù)據(jù)。圖2給出了隔離對象的處理流圖。 在系統(tǒng)高負荷或者發(fā)生故障的情況下，Container或賬號中的數(shù)據(jù)不會被立即更新。如果更新失敗，該次更新在本地文件系統(tǒng)上會被加入隊列，然后Updaters會繼續(xù)處理這些失敗了的更新工作，其中由Account Updater和Container Updater分別負責(zé)Account和Object列表的更新。 Replicator的功能是處理數(shù)據(jù)的存放位置是否正確并且保持數(shù)據(jù)的合理拷貝數(shù)，它的設(shè)計目的是Swift服務(wù)器在面臨如網(wǎng)絡(luò)中斷或者驅(qū)動器故障等臨時性故障情況時可以保持系統(tǒng)的一致性。

?

　　圖2 隔離對象的處理流圖

　　Ring

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

　　原理

　　Swift用到的算法和存儲理論并不復(fù)雜，主要有幾下幾個概念。

　　一致性哈希算法

　　Swift利用一致性哈希算法構(gòu)建了一個冗余的可擴展的分布式對象存儲集群。Swift采用一致性哈希的主要目的是在改變集群的Node數(shù)量時，能夠盡可能少地改變已存在Key和Node的映射關(guān)系。 該算法的思路分為以下三個步驟。 首先計算每個節(jié)點的哈希值，并將其分配到一個0~232的圓環(huán)區(qū)間上。其次使用相同方法計算存儲對象的哈希值，也將其分配到這個圓環(huán)上。隨后從數(shù)據(jù)映射到的位置開始順時針查找，將數(shù)據(jù)保存到找到的第一個節(jié)點上。如果超過232仍然找不到節(jié)點，就會保存到第一個節(jié)點上。 假設(shè)在這個環(huán)形哈希空間中存在4臺Node，若增加一臺Node5，根據(jù)算法得出Node5被映射在Node3和Node4之間，那么受影響的將僅是沿Node5逆時針遍歷到Node3之間的對象(它們本來映射到Node4上)。其分布如圖3所示。

?

　　圖3 一致性哈希環(huán)結(jié)構(gòu)

　　Replica

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

　　Zone

　　如果所有的Node都在一個機架或一個機房中，那么一旦發(fā)生斷電、網(wǎng)絡(luò)故障等，都將造成用戶無法訪問。因此需要一種機制對機器的物理位置進行隔離，以滿足分區(qū)容忍性(CAP理論中的P)。因此，Ring中引入了Zone的概念，把集群的Node分配到每個Zone中。其中同一個Partition的Replica不能同時放在同一個Node上或同一個Zone內(nèi)。注意，Zone的大小可以根據(jù)業(yè)務(wù)需求和硬件條件自定義，可以是一塊磁盤、一臺存儲服務(wù)器，也可以是一個機架甚至一個IDC。

　　Weight

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

?

　　圖4 一種Swift部署集群

　　實例分析

　　圖4中是新浪SAE在測試環(huán)境中部署的Swift集群，集群中又分為5個Zone，每個Zone是一臺存儲服務(wù)器，每臺服務(wù)器上由12塊2TB的SATA磁盤組成，只有操作系統(tǒng)安裝盤需要RAID，其他盤作為存儲節(jié)點，不需要RAID。前面提到過，Swift采用完全對稱的系統(tǒng)架構(gòu)，在這個部署案例中得到了很好的體現(xiàn)。圖4中每個存儲服務(wù)器的角色是完全對等的，系統(tǒng)配置完全一樣，均安裝了所有Swift服務(wù)軟件包，如Proxy Server、Container Server和Account Server等。上面的負載均衡(Load Balancer)并不屬于Swift的軟件包，出于安全和性能的考慮，一般會在業(yè)務(wù)之前擋一層負載均衡設(shè)備。當(dāng)然可以去掉這層代理，讓Proxy Server直接接收用戶的請求，但這可能不太適合在生產(chǎn)環(huán)境中使用。 圖4中分別表示了上傳文件PUT和下載文件GET請求的數(shù)據(jù)流，兩個請求操作的是同一個對象。上傳文件時，PUT請求通過負載均衡隨機挑選一臺Proxy Server，將請求轉(zhuǎn)發(fā)到后者，后者通過查詢本地的Ring文件，選擇3個不同Zone中的后端來存儲這個文件，然后同時將該文件向這三個存儲節(jié)點發(fā)送文件。這個過程需要滿足NWR策略(Quorum Protocol)，即3份存儲，寫成功的份數(shù)必須大于3/2，即必須保證至少2份數(shù)據(jù)寫成功，再給用戶返回文件寫成功的消息。下載文件時，GET請求也通過負載均衡隨機挑選一臺Proxy Server，后者上的Ring文件能查詢到這個文件存儲在哪三個節(jié)點中，然后同時去向后端查詢，至少有2個存儲節(jié)點“表示”可以提供該文件，然后Proxy Server從中選擇一個節(jié)點下載文件。

　　小結(jié)

　　Swift簡單、冗余、可擴展的架構(gòu)設(shè)計保證了它能夠用于IaaS的基礎(chǔ)服務(wù)。在Rackspace Cloud Files服務(wù)兩年的運行積累使得Swift代碼變得越來越成熟，目前已部署在全球各地的公有云、私有云服務(wù)中。隨著OpenStack的不斷完善和發(fā)展，Swift將得到更廣泛的應(yīng)用。