開源的最大魅力，是能夠滿足人們的探索欲和求知欲，讓我們可以很深入地了解一個(gè)系統(tǒng)，如果我們發(fā)現(xiàn)它的設(shè)計(jì)或者實(shí)現(xiàn)中有任何不合理的或者錯(cuò)誤的地方，我們可以提出自己的想法并且實(shí)現(xiàn)它，親手來完善一個(gè)大家都在關(guān)注的事物，讓無數(shù)人受益其中。今天我們就來聊一聊一個(gè)開源對象存儲系統(tǒng)——OpenStack Swift。

1.Swift概述

Swift是一個(gè)提供RESTful HTTP接口的對象存儲系統(tǒng)，最初起源于Rackspace的Cloud Files，目的是為了提供一個(gè)和AWS S3競爭的服務(wù)。

Swift于2010年開源，是OpenStack最初的兩個(gè)項(xiàng)目之一。然而，在國內(nèi)OpenStack圈里，不太能夠聽到關(guān)于Swift的聲音，究其原因正如本系列的第一篇《文件系統(tǒng)vs對象存儲——選型和趨勢》中所說的，RESTful HTTP接口的對象存儲，主要為互聯(lián)網(wǎng)應(yīng)用服務(wù)，而OpenStack廠商最關(guān)心的傳統(tǒng)行業(yè)的用戶目前能夠應(yīng)用這種存儲模式的還不多。

但實(shí)際上，Swift在一些本土互聯(lián)網(wǎng)公司確實(shí)是有一些成功的應(yīng)用，包括新浪、美團(tuán)、愛奇藝、鳳凰網(wǎng)等。國外的應(yīng)用更為廣泛，早在2010年，Swift就迎來了第一個(gè)Rackspace之外的商用案例——韓國電信，大家很熟悉的維基百科、ebay等也是Swift的用戶。相信隨著互聯(lián)網(wǎng)技術(shù)的應(yīng)用架構(gòu)逐漸被傳統(tǒng)行業(yè)接受，對象存儲和Swift將受到越來越廣泛的關(guān)注。

從OpenStack Kilo版本的數(shù)據(jù)來看，Swift社區(qū)呈現(xiàn)出多元化的特點(diǎn)而且正在健康的發(fā)展。

本文和本系列接下來的兩篇，將介紹Swift的架構(gòu)并給出規(guī)模部署的例子，從硬件配置開始一步步搭建一個(gè)Swift集群，總結(jié)Swift的特點(diǎn)并提出Swift面臨的挑戰(zhàn)和發(fā)展趨勢。

2.Swift的數(shù)據(jù)組織結(jié)構(gòu)

Swift將整個(gè)存儲分為三個(gè)層次：Account、Container 和 Object。

這里的Account本身只是一個(gè)存儲區(qū)域，并不代表認(rèn)證系統(tǒng)里的“賬號”，但是通常會讓每個(gè)Account對應(yīng)一個(gè)租戶。這就是為什么我們作為一個(gè)OpenStack用戶在使用Swift時(shí)，只能看到Container和Object，而看不到Account的原因，如果這個(gè)用戶切換到另一個(gè)租戶下，他將看到屬于另一個(gè)租戶也是是另一個(gè)Account下的Container和Object。

#p#

3Swift集群的架構(gòu)

相對于OpenStack中的其他項(xiàng)目來說，Swift比較獨(dú)立，用戶可以選擇將其單獨(dú)部署，當(dāng)然也可以與OpenSatck其他項(xiàng)目集成，甚至與Cloudfoundry和Docker集成。一般來說，Swift集群由兩類節(jié)點(diǎn)組成：Proxy節(jié)點(diǎn)和Storage節(jié)點(diǎn)。一個(gè)簡單的Swift集群如下圖所示：

Proxy節(jié)點(diǎn)上主要運(yùn)行Proxy Server服務(wù)進(jìn)程，負(fù)責(zé)接收和響應(yīng)用戶的HTTP請求，Proxy Server是一個(gè)無狀態(tài)的服務(wù)，可以很容易地進(jìn)行橫向擴(kuò)展。由于Swift自身的認(rèn)證服務(wù)只是一個(gè)測試用的TempAuth，所以通常需要使用一個(gè)外部的認(rèn)證服務(wù)，或者在Proxy節(jié)點(diǎn)上安裝額外的認(rèn)證服務(wù)。如果我們有一個(gè)OpenStack環(huán)境，我們可以直接使用該環(huán)境中的Keystone，如果不需要和OpenStack的其他部分集成，也可以在Proxy節(jié)點(diǎn)上安裝一個(gè)獨(dú)立的Keystone來提供認(rèn)證服務(wù)。

Storage節(jié)點(diǎn)上主要運(yùn)行三類存儲服務(wù)進(jìn)程：Account Server、Container Server 和 Object Server，分別負(fù)責(zé)Account、Container、Object數(shù)據(jù)的存儲，所以，在一些文獻(xiàn)中又把存儲節(jié)點(diǎn)稱作ACO節(jié)點(diǎn)。

Proxy Server通過一種叫做Ring數(shù)據(jù)結(jié)構(gòu)來確定數(shù)據(jù)存放在哪個(gè)存儲節(jié)點(diǎn)上，Ring是一種經(jīng)過改進(jìn)的一致性哈希實(shí)現(xiàn)，可以將一份數(shù)據(jù)映射到多個(gè)設(shè)備，具體映射到幾個(gè)設(shè)備上，取決于創(chuàng)建Ring時(shí)設(shè)定的副本數(shù)量。Swift 2.0版發(fā)布以后，用戶可以利用存儲策略(Storage Policy)功能給各個(gè)Container指定不同的副本數(shù)量，或者使用糾刪碼(Erasure Code)，關(guān)于Swift中的存儲策略請參考《OpenStack Swift 存儲策略》( http://www.ibm.com/developerworks/cn/cloud/library/1411_limy_openstackswift/ )

在Swift中，每個(gè)Account和每個(gè)Container的信息分別存儲在一個(gè)個(gè)獨(dú)立的sqlite數(shù)據(jù)庫里，也就是說，雖然在邏輯上來說，整個(gè)存儲空間是分為Account、Container和Object三個(gè)層次，但是實(shí)際上每個(gè)Account、Container和每個(gè)Object一樣，都對應(yīng)到Storage節(jié)點(diǎn)上的一個(gè)文件。所以，Swift的整個(gè)存儲空間是一個(gè)Flat Namespace，可以看做是一個(gè)K/V存儲。

這也就不難理解為什么說Swift是全對等架構(gòu)，因?yàn)檫@里面沒有管理職能的元數(shù)據(jù)服務(wù)器，Account和Container的存儲方式和Object并無本質(zhì)區(qū)別，每個(gè)存儲服務(wù)在集群里的地位都是等同的。Proxy Server根據(jù)REST請求中的URI的結(jié)構(gòu)來確定用戶請求的是一個(gè)Account、一個(gè)Container還是一個(gè)Object。

在一些文獻(xiàn)中或者有些人在交流的時(shí)候，會把Account和Container信息稱作Swift中的“元數(shù)據(jù)”，我不贊同這種說法，我也沒有在Swift官方文檔中的任何地方看到將這兩類信息稱為“元數(shù)據(jù)”的說法，它們和文件系統(tǒng)的元數(shù)據(jù)有本質(zhì)的區(qū)別。事實(shí)上，在Swift中，元數(shù)據(jù)(metadata)指的是對象的屬性(attribute)，它是對象的描述信息，Swift借助xfs等底層機(jī)制的特性和將對象的屬性/元數(shù)據(jù)和對象的數(shù)據(jù)放在一起存儲。

如果我們希望擴(kuò)展Swift的功能，比如在用戶上傳對象的時(shí)候進(jìn)行查毒、數(shù)據(jù)壓縮或者黃色圖片等非法信息掃描，可以通過在Proxy Server上增加Middleware來實(shí)現(xiàn)，這里的Middleware(中間件)是Python WSGI框架中的一個(gè)概念，每個(gè)HTTP請求，都通過一層層中間件處理后傳遞給最核心的Proxy Server;Proxy Server產(chǎn)生的響應(yīng)，也通過一層層中間件的處理最后返回給用戶。事實(shí)上，Swift對Keystone的調(diào)用正是通過middleware來實(shí)現(xiàn)的。

4一個(gè)中等規(guī)模Swift部署實(shí)例

Swift集群的架構(gòu)讓我們可以很容易地?cái)U(kuò)展Proxy節(jié)點(diǎn)和存儲節(jié)點(diǎn)的數(shù)量。一個(gè)中等規(guī)模Swift部署的例子如圖所示：

該案例中，Proxy節(jié)點(diǎn)使用Lenovo System X 3650服務(wù)器，計(jì)算能力較強(qiáng)，能夠應(yīng)對較高的并發(fā)訪問，并方便以后在Swift上部署新的middleware以擴(kuò)展其功能。

Storage節(jié)點(diǎn)使用存儲密度較高的超云R6440-G9服務(wù)器(該服務(wù)器的具體情況和技術(shù)剖析請參考文章《旁觀高密存儲服務(wù)器(1)：不擇手段混合型》)6個(gè)滿配的4U籠子共24個(gè)Storage節(jié)點(diǎn)，每節(jié)點(diǎn)12塊希捷的3.5寸4T硬盤，能夠提供約1.2 PB的物理存儲空間，采用三副本策略，共提供384TB的存儲容量。

Swift將存儲節(jié)點(diǎn)分為多個(gè)zone，將副本保存到不同的zone中，一般來說，zone的數(shù)量應(yīng)當(dāng)大于或等于副本數(shù)量。

zone的劃分原則為物理故障隔離，例如，我們可以按機(jī)柜來劃分zone，也可以像圖中那樣把一個(gè)四節(jié)點(diǎn)籠子里的四臺服務(wù)器劃分到同一個(gè)zone里，分屬不同籠子的節(jié)點(diǎn)劃分到不同的zone。如果節(jié)點(diǎn)數(shù)量較少，也可以將每臺服務(wù)器劃分為一個(gè)zone。實(shí)驗(yàn)、開發(fā)、測試環(huán)境中也可以按照磁盤來劃分zone，比如將一個(gè)服務(wù)器中的12塊盤分到不同的zone中。