OpenStack Object Storage（Swift）概述

概述

OpenStack Object Storage（Swift）是OpenStack開源雲計算項目的子項目之一，被稱爲對象存儲，提供了強大的擴展性、冗餘和持久性。 Swift並非文件系統或者實時的數據存儲系統，它稱爲對象存儲，用於永久類型的靜態數據的長期存儲，這些數據能夠檢索、調整，必要時進行更新。最適合存儲的數據類型的例子是虛擬機鏡像、圖片存儲、郵件存儲和存檔備份。由於沒有中心單元或主控結點，Swift提供了更強的擴展性、冗餘和持久性。Swift前身是Rackspace Cloud Files項目，隨着Rackspace加入到OpenStack社區，於2010年7月貢獻給OpenStack，做爲該開源項目的一部分。

 

1、Swift管理的資源

swift管理的資源分三級：Account、Container、Object。一個Tenant擁有一個Account，Account下存放Container，Container下存儲Object。

 

2、Swift架構概述

Swift主要有三個組成部分：Proxy Server、Storage Server和Consistency Server。其中Storage和Consistency服務均運行在Storage Node上。Auth認證服務目前已從Swift中剝離出來，使用OpenStack的認證服務Keystone，目的在於實現統一OpenStack各個項目間的認證管理。

一、Proxy Server

Proxy server 是負責將Swift架構其他的部分整合起來。對於每一個客戶端的請求，它將在Ring中查詢Account、Container或Object的位置，而且相應地路由請求。

Proxy提供了Rest-full API，而且符合標準的HTTP協議規範，這使得開發者能夠快捷構建定製的Client與Swift交互。

二、Storage Server

Storage Server提供了磁盤設備上的存儲服務。在Swift中有三類存儲服務：Account、Container和Object。

1）、Object Server

Object Server 是一個很是簡單的二進制對象存儲服務器，能夠用來存儲、檢索和刪除存儲在本地設備上的對象。對象以二進制文件的形式存儲在文件系統上，元數據存儲在文件的擴展屬性中（xattrs）。這須要對象服務器的基本文件系統的選擇支持xattrs。

2)、Container Server

Container Server最重要的工做就是處理對象列表。它不知道對象存儲在哪裏，只是知道什麼對象在一個特殊的容器中。這個列表以sqlite數據庫文件的形式存儲，和對象同樣在集羣中進行相似的備份。跟蹤統計包括對象的總數，容器的存儲使用的狀況。

3)、Account Server

Account Server 跟 Container Server很是的類似，只是它負責容器的列表，而不是對象。

三、Consistency Servers

在磁盤上存儲數據並向外提供Rest-ful API並非難以解決的問題，最主要的問題在於故障處理。Swift的Consistency Servers的目的是查找並解決由數據損壞和硬件故障引發的錯誤。主要存在三個服務：Auditor、Updater和Replicator。

1)、Auditor

Auditor運行在每一個Swift服務器的後臺，持續地掃描磁盤來檢測Object、Container和Account的完整性。若是發現數據損壞，Auditor就會將該文件移動到隔離區域，而後由Replicator負責用一個無缺的拷貝來替代該數據。若是發現其餘的錯誤，Auditor會把它們記錄到日誌中。

2)、Replicator

Replication被設計用來面對臨時的網絡停機或者驅動失敗時，保持系統的一致性。

replication比較本地的數據（object，account和container）和每個遠端副本，來確保它們全都包含最新的版本。

replication的操做包括update和remove。

3)、Updaters

有時當容器或者帳戶數據不能被當即更新時，一般發生在故障的狀況下或者高負載的時期。若是一次更新失敗，此次更新將會被保存到本地文件系統上的隊列裏，而後Updater會執行失敗的更新。

 

3、重要概念

一、Ring

Ring是Swift重要的組件，一個ring表明雲存儲中的實體（Account、Container、Object）到物理位置的映射。Account、Container、Object都有各自分離的ring。當其餘的組件須要對Account、Container、Object執行某些操做時，它們都須要和對應的ring交互來肯定這些實體在集羣中的位置。

Ring使用Zone、Device、Partition和Replica來維護這些映射信息。Ring中每一個Partition在集羣中都（默認）有3個Replica。每一個Partition的位置由Ring來維護，並存儲在映射中。

Ring文件在系統初始化時建立，以後每次增減存儲節點時，須要從新平衡一下Ring文件中的項目，以保證增減節點時，系統所以而發生遷移的文件數量最少。

二、Zone

若是全部的Node都在一個機架或一個機房中，那麼一旦發生斷電、網絡故障等，都將形成用戶沒法訪問。所以須要一種機制對機器的物理位置進行隔離，以知足分區容忍性（CAP理論中的P）。所以，Ring中引入了Zone的概念，把集羣的Node分配到每一個Zone中。其中同一個Partition的Replica不能同時放在同一個Node上或同一個Zone內。注意，Zone的大小能夠根據業務需求和硬件條件自定義，能夠是一塊磁盤、一臺存儲服務器，也能夠是一個機架甚至一個IDC。

zone ： a group of nodes that is as isolated as possible from other nodes (separate servers, network, power, even geography).The ring guarantees that every replica is stored in a separate zone.

三、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系統是可靠的，沒有單點故障。

四、Weight

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

 

4、原理

Swift利用一致性哈希算法構建了一個冗餘的可擴展的分佈式對象存儲集羣。Swift採用一致性哈希的主要目的是在改變集羣的Node數量時，可以儘量少地改變已存在Key和Node的映射關係。

該算法的思路分爲如下三個步驟。首先計算每一個節點的哈希值，並將其分配到一個0~232的圓環區間上。其次使用相同方法計算存儲對象的哈希值，也將其分配到這個圓環上。隨後從數據映射到的位置開始順時針查找，將數據保存到找到的第一個節點上。若是超過232仍然找不到節點，就會保存到第一個節點上。 假設在這個環形哈希空間中存在4臺Node，若增長一臺Node5，根據算法得出Node5被映射在Node3和Node4之間，那麼受影響的將僅是沿Node5逆時針遍歷到Node3之間的對象（它們原本映射到Node4上）。其分佈如圖所示。

 

 

 

參考： http://www.programmer.com.cn/12403/