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

1.Swift概述

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

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

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

從OpenStack Kilo版本的數據來看，Swift社區呈現出多元化的特點而且正在健康的發展。

本文和本系列接下來的兩篇，將介紹Swift的架構并給出規模部署的例子，從硬件配置開始一步步搭建一個Swift集群，總結Swift的特點并提出Swift面臨的挑戰和發展趨勢。

2.Swift的數據組織結構

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

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

#p#

3Swift集群的架構

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

Proxy節點上主要運行Proxy Server服務進程，負責接收和響應用戶的HTTP請求，Proxy Server是一個無狀態的服務，可以很容易地進行橫向擴展。由于Swift自身的認證服務只是一個測試用的TempAuth，所以通常需要使用一個外部的認證服務，或者在Proxy節點上安裝額外的認證服務。如果我們有一個OpenStack環境，我們可以直接使用該環境中的Keystone，如果不需要和OpenStack的其他部分集成，也可以在Proxy節點上安裝一個獨立的Keystone來提供認證服務。

Storage節點上主要運行三類存儲服務進程：Account Server、Container Server 和 Object Server，分別負責Account、Container、Object數據的存儲，所以，在一些文獻中又把存儲節點稱作ACO節點。

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

在Swift中，每個Account和每個Container的信息分別存儲在一個個獨立的sqlite數據庫里，也就是說，雖然在邏輯上來說，整個存儲空間是分為Account、Container和Object三個層次，但是實際上每個Account、Container和每個Object一樣，都對應到Storage節點上的一個文件。所以，Swift的整個存儲空間是一個Flat Namespace，可以看做是一個K/V存儲。

這也就不難理解為什么說Swift是全對等架構，因為這里面沒有管理職能的元數據服務器，Account和Container的存儲方式和Object并無本質區別，每個存儲服務在集群里的地位都是等同的。Proxy Server根據REST請求中的URI的結構來確定用戶請求的是一個Account、一個Container還是一個Object。

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

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

4一個中等規模Swift部署實例

Swift集群的架構讓我們可以很容易地擴展Proxy節點和存儲節點的數量。一個中等規模Swift部署的例子如圖所示：

該案例中，Proxy節點使用Lenovo System X 3650服務器，計算能力較強，能夠應對較高的并發訪問，并方便以后在Swift上部署新的middleware以擴展其功能。

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

Swift將存儲節點分為多個zone，將副本保存到不同的zone中，一般來說，zone的數量應當大于或等于副本數量。

zone的劃分原則為物理故障隔離，例如，我們可以按機柜來劃分zone，也可以像圖中那樣把一個四節點籠子里的四臺服務器劃分到同一個zone里，分屬不同籠子的節點劃分到不同的zone。如果節點數量較少，也可以將每臺服務器劃分為一個zone。實驗、開發、測試環境中也可以按照磁盤來劃分zone，比如將一個服務器中的12塊盤分到不同的zone中。