【轉載】OpenStack Swift學習筆記

標籤：style   blog   http   java   使用   os   io   strong   

免責聲明：
    本文轉自網路文章，轉載此文章僅為個人收藏，分享知識，如有侵權，請聯絡博主進行刪除。
    原文崔炳華 
    原文地址：http://blog.csdn.net/i_chips/article/details/17787017 1       概述 OpenStack Object Storage（Swift）是OpenStack開源雲端運算項目的子項目之一。Swift的目的是使用普通硬體來構建冗餘的、可擴充的分布式Object Storage Service叢集，儲存容量可達PB級。

Swift並不是檔案系統或者即時的資料存放區系統，它是Object Storage Service，用於永久類型的待用資料的長期儲存，這些資料可以檢索、調整，必要時進行更新。最適合儲存的資料類型的例子是虛擬機器鏡像、圖片儲存、郵件儲存和存檔備份。

Swift無需採用RAID（磁碟冗餘陣列），也沒有中心單元或主控結點。Swift通過在軟體層面引入一致性雜湊技術和資料冗餘性，犧牲一定程度的資料一致性來達到高可用性（High Availability，簡稱HA）和延展性，支援多租戶模式、容器和對象讀寫操作，適合解決互連網的應用情境下非結構化資料存放區問題。

2       技術特性 2.1        Swift的主要特徵

Swift的主要特性如下：

• 極高的資料持久性（Durability）。
• 完全對稱的系統架構：“對稱”意味著Swift中各節點可以完全對等，能極大地降低系統維護成本。
• 無限的可擴充性：一是資料存放區容量無限可擴充；二是Swift效能（如QPS、輸送量等）可線性提升。
• 無單點故障：Swift的中繼資料存放區是完全均勻隨機分布的，並且與對象檔案儲存體一樣，中繼資料也會儲存多份。整個Swift叢集中，也沒有一個角色是單點的，並且在架構和設計上保證無單點業務是有效。
• 簡單、可依賴。

2.2        Swift和HDFS的技術差異

Swift和HadoopDistributed File System（HDFS）都有著相似的目的：實現冗餘、快速、連網的儲存，它們的技術差異如下：

• 在Swift中，中繼資料呈分布式，跨叢集複製。而在HDFS使用了中央系統來維護檔案中繼資料（Namenode，名稱節點），這對HDFS來說無異於單一故障點，因而擴充到規模非常大的環境顯得更困難。
• Swift在設計時考慮到了多租戶架構，而HDFS沒有多租戶架構這個概念。
• 在Swift中，檔案可以寫入多次；在並行作業環境下，以最近一次操作為準。而在HDFS中，檔案寫入一次，而且每次只能有一個檔案寫入。
• Swift用Python來編寫，而HDFS用Java來編寫。
• Swift被設計成了一種比較通用的儲存解決方案，能夠可靠地儲存數量非常多的大小不一的檔案；而HDFS被設計成可以儲存數量中等的大檔案（HDFS針對更龐大的檔案作了最佳化），以支援資料處理。

3       關鍵技術 3.1        一致性雜湊（ConsistentHashing）

在分布式Object Storage Service中，一個關鍵問題是資料該如何存放。Swift是基於一致性雜湊技術，通過計算可將對象均勻分布到虛擬空間的虛擬節點上，在增加或刪除節點時可大大減少需移動的資料量；虛擬空間大小通常採用2的n次冪，便於進行高效的移位操作；然後通過獨特的資料結構 Ring（環）再將虛擬節點映射到實際的實體儲存體裝置上，完成定址過程。

圖1 一致性雜湊環結構

衡量一致性雜湊的4個指標：

• 平衡性（Balance）：平衡性是指Hash的結果能夠儘可能分布均勻，充分利用所有緩衝空間。
• 單調性（Monotonicity）：單調性是指如果已經有一些內容通過雜湊指派到了相應的緩衝中，又有新的緩衝加入到系統中。雜湊的結果應能夠保證原有已指派的內容可以被映射到新的緩衝中去，而不會被映射到舊的緩衝集合中的其他緩衝區。
• 分散性（Spread）：分散性定義了分布式環境中，不同終端通過Hash過程將內容映射至緩衝上時，因可見緩衝不同，Hash結果不一致，相同的內容被映射至不同的緩衝區。
• 負載（Load）：負載是對分散性要求的另一個緯度。既然不同的終端可以將相同的內容映射到不同的緩衝區中，那麼對於一個特定的緩衝區而言，也可能被不同的使用者映射為不同的內容。

Swift使用該演算法的主要目的是在改變叢集的node數量時（增加/刪除伺服器），能夠儘可能少地改變已存在key和node的映射關係，以滿足單調性。

考慮到雜湊演算法在node較少的情況下，改變node數會帶來巨大的資料移轉。為瞭解決這種情況，一致性雜湊引入了“虛擬節點”（vnode，也稱為partition）的概念： “虛擬節點”是實際節點在環形空間的複製品，一個實際節點對應了若干個“虛擬節點”，“虛擬節點”在雜湊空間中以雜湊值排列。

總的來說，Swift中存在兩種映射關係，對於一個檔案，通過雜湊演算法（MD5）找到對應的虛節點（一對一的映射關係），虛節點再通過映射關係（ring檔案中二維數組）找到對應的裝置（多對多的映射關係），這樣就完成了一個檔案儲存體在裝置上的映射。

圖2 對象、虛結點、節點間的映射關係

在設定虛結點數的時候，需要對系統預期的規模做充分考慮，假如叢集的規模不會超過6000個結點，那麼可以將虛結點數設定為結點數的100倍。這樣，變動任意一個結點的負載僅影響1%的資料項目。此時有6百萬個vnode數，使用2bytes來儲存結點數(0~65535)。基本的記憶體佔用是6*(10^6)*2bytes=12Mb，對於伺服器來說完全可以承受。

假設有65536（2^16）個node，有128（2^7）倍的partition數（2^23，則PARTITION_POWER=23）。由於MD5碼是32位的，使用PARTITION_SHIFT（等於32- PARTITION_POWER）將資料項目的MD5雜湊值對應到partition的2^23的空間中。

3.2        資料一致性模型（ConsistencyModel）

按照Eric Brewer的CAP（Consistency，Availability，PartitionTolerance）理論，無法同時滿足3個方面，Swift放棄嚴格一致性（滿足ACID事務層級），而採用最終一致性模型（Eventual Consistency），來達到高可用性和無限水平擴充能力。

為了實現這一目標，Swift採用Quorum仲裁協議（Quorum有法定投票人數的含義）：

• 定義：N：資料的副本總數；W：寫操作被確認接受的副本數量；R：讀操作的副本數量。
• 強一致性：R+W>N，以保證對副本的讀寫操作會產生交集，從而保證可以讀取到最新版本；如果 W=N，R=1，則需要全部更新，適合大量讀少量寫操作環境下的強一致性；如果 R=N，W=1，則只更新一個副本，通過讀取全部副本來得到最新版本，適合大量寫少量讀情境下的強一致性。
• 弱一致性：R+W<=N，如果讀寫操作的複本集合不產生交集，就可能會讀到髒資料；適合對一致性要求比較低的情境。

Swift針對的是讀寫都比較頻繁的情境，所以採用了比較折中的策略，即寫操作需要滿足至少一半以上成功W>N/2，再保證讀操作與寫操作的複本集合至少產生一個交集，即R+W>N。

在分布式系統中，資料的單點是不允許存在的。線上正常存在的replica數量是1的話將非常危險的，因為一旦這個replica再次錯誤，就可能發生資料的永久性錯誤。假如我們把N設定成為2，那麼，只要有一個儲存節點發生損壞，就會有單點的存在。所以N必須大於2。但N越高，系統的維護和整體成本就越高。所以，工業界通常把N設定為3。

Swift預設配置是N=3，W=2>N/2，R=1或2，即每個對象會存在3個副本，這些副本會被盡量儲存在不同地區的節點上；W=2表示至少需要更新2個副本才算寫成功。

當R=1時，意味著某一個讀操作成功便立刻返回，此種情況下可能會讀取到舊版本（弱一致性模型）。

當R=2時，需要通過在讀操作要求標頭中增加x-newest=true參數來同時讀取2個副本的中繼資料資訊，然後比較時間戳記來確定哪個是最新版本（強一致性模型）。

如果資料出現了不一致，後台服務進程會在一定時間視窗內通過檢測和複製協議來完成資料同步，從而保證達到最終一致性。

圖3 Quorum協議樣本

3.3        環（Ring）

Ring是Swift中最重要的組件，用於記錄儲存物件與物理位置間的映射關係。在涉及查詢Account、Container、Object資訊時就需要查詢叢集的Ring資訊。

環是為了將虛擬節點（partition，分區）均衡地映射到一組實體儲存體裝置上，並提供一定的冗餘度而設計的，其資料結構由以下資訊組成：

存放裝置列表、裝置資訊包括唯一標識號（id）、地區號（zone）、權重（weight）、IP 位址（ip）、連接埠（port）、裝置名稱（device）、中繼資料（meta）。

Swift為賬戶、容器和對象分別定義了的Ring，其尋找過程是相同的。Ring中每個partition在叢集中都預設有3個replica。每個partition的位置由ring來維護，並儲存在映射中。

Ring使用zone來保證資料的物理隔離。每個partition的replica都確保放在了不同的zone中。Zone只是個抽象概念，它可以是一個磁碟（disk drive），一個伺服器（server），一個機架（cabinet），一個交換器（switch），甚至是一個資料中心（datacenter），以提供最進階別的冗餘性，建議至少部署5個zone。

權重參數是個相對值，可以來根據磁碟的大小來調節，權重越大表示可分配的空間越多，可部署更多的分區。

當叢集中發生儲存節點宕機、新增（刪）儲存節點、新增（刪）zone等必須改變partition和node間的映射關係時，還可以對Ring檔案通過重新平衡（rebalance）來進行更新。當虛節點需要移動時，環會確保一次移動最少數量的虛節點數，並且一次只移動一個虛節點的一個副本。

總的來說，Ring引入一致性雜湊的原因是為了減少由於增加結點導致資料項目移動的數量來提高單調性；引入partition的原因是為了減少由於節點數過少導致移動過多的資料項目；引入replica的原因是防止資料單點、提高冗餘性；引入zone的原因是為了保證分區容忍性；引入weight的原因是為了保證partition分配的均衡。

4       架構設計 4.1        Swift資料模型

Swift採用層次資料模型，共設三層邏輯結構：Account/Container/Object（賬戶/容器/對象）。每層節點數均沒有限制，可以任意擴充。這裡的賬戶和個人賬戶不是一個概念，可理解為租戶，用來做頂層的隔離機制，可以被多個個人賬戶所共同使用；容器類似檔案夾，代表封裝一組對象；對象由中繼資料和資料兩部分組成。

4.2        Swift系統架構

Swift採用完全對稱、面向資源的分布式系統架構設計，所有組件都可擴充，避免因單點失效而擴散並影響整個系統運轉；通訊方式採用非阻塞式 I/O 模式，提高了系統吞吐和響應能力。

Swift組件包括：

• 代理服務（ProxyServer）：Swift通過Proxy Server向外提供基於HTTP的REST服務介面，會根據環的資訊來尋找服務地址並轉寄使用者請求至相應的賬戶、容器或者對象，進行CRUD（增刪改查）等操作。由於採用無狀態的REST請求協議，可以進行橫向擴充來均衡負載。在訪問Swift服務之前，需要先通過認證服務擷取存取權杖，然後在發送的請求中加入頭部資訊 X-Auth-Token。Proxy 伺服器負責Swift架構的其餘組件間的相互連信。Proxy 伺服器也處理大量的失敗請求。例如，如果對於某個對象PUT請求時，某個儲存節點不可用，它將會查詢環可傳送的伺服器並轉寄請求。對象以流的形式到達（來自） 物件服務器，它們直接從Proxy 伺服器傳送到（來自）使用者—Proxy 伺服器並不緩衝它們。
• 認證服務（AuthenticationServer）：驗證訪問使用者的身份資訊，並獲得一個對象存取權杖（Token），在一定的時間內會一直有效；驗證存取權杖的有效性並緩衝下來直至到期時間。
• 快取服務（CacheServer）：緩衝的內容包括物件服務令牌，賬戶和容器的存在資訊，但不會緩衝對象本身的資料；快取服務可採用Memcached叢集，Swift會使用一致性雜湊演算法來分配緩衝地址。
• 賬戶服務（AccountServer）：提供賬戶中繼資料和統計資訊，並維護所含容器列表的服務，每個賬戶的資訊被儲存在一個SQLite資料庫中。
• Container Service（ContainerServer）：提供容器中繼資料和統計資訊（比如對象的總數，容器的使用方式等），並維護所含對象列表的服務。Container Service並不知道對象存在哪，只知道指定容器裡存的哪些對象。 這些對象資訊以SQLite資料庫檔案的形式儲存，和對象一樣在叢集上做類似的備份。 
• 物件服務（ObjectServer）：提供對象中繼資料和內容服務，可以用來儲存、檢索和刪除本地裝置上的對象。在檔案系統中，對象以二進位檔案的形式儲存，它的中繼資料存放區在檔案系統的擴充屬性（xattr）中，建議採用預設支援擴充屬性（xattr）的XFS檔案系統。每個對象使用對象名稱的雜湊值和操作的時間戳記組成的路徑來儲存。最後一次寫操作總可以成功，並確保最新一次的對象版本將會被處理。刪除也被視為檔案的一個版本（一個以".ts"結尾的0位元組檔案，ts表示墓碑）。
• 複製服務（Replicator）：會檢測本地分區副本和遠程副本是否一致，具體是通過對比雜湊檔案和進階浮水印來完成，發現不一致時會採用推式（Push）更新遠程副本：對於對象的複製，更新只是使用rsync同步檔案到對等節點。帳號和容器的複製通過HTTP或rsync來推送整個資料庫檔案上丟失的記錄；另外一個任務是確保被標記刪除的對象從檔案系統中移除：當有一項（對象、容器、或者帳號）被刪除，則一個墓碑檔案被設定作為該項的最新版本。複製器將會檢測到該墓碑檔案並確保將它從整個系統中移除。
• 更新服務（Updater）：當對象由於高負載或者系統故障等原因而無法立即更新時，任務將會被序列化到在本地檔案系統中進行排隊，以便服務恢複後進行非同步更新；例如成功建立對象後Container Service器沒有及時更新對象列表，這個時候容器的更新操作就會進入排隊中，更新服務會在系統復原正常後掃描隊列並進行相應的更新處理。
• 審計服務（Auditor）：在本機伺服器上會反覆地爬取來檢查對象，容器和賬戶的完整性，如果發現位元級的錯誤，檔案將被隔離，並複製其他的副本以覆蓋本地損壞的副本；其他類型的錯誤（比如在任何一個Container Service器中都找不到所需的對象列表）會被記錄到日誌中。
• 賬戶清理服務（AccountReaper）：移除被標記為刪除的賬戶，刪除其所包含的所有容器和對象。刪除帳號的過程是相當直接的。對於每個帳號中的容器，每個對象先被刪除然後容器被刪除。任何失敗的刪除請求將不會阻止整個過程，但是將會導致整個過程最終失敗（例如，如果一個對象的刪除逾時，容器將不能被刪除，因此帳號也不能被刪除）。整個處理過程即使遭遇失敗也繼續執行，這樣它不會因為一個麻煩的問題而中止恢複叢集空間。帳號收割器將會繼續不斷地嘗試刪除帳號直到它最終變為空白，此時資料庫在db_replicator中回收處理，最終移除這個資料庫檔案。

圖4 Swift系統架構

Swift支援的所有操作可以總結為下表：

表1 SwiftRESTful API總結

4.3        Ring的資料結構

Ring 的資料結構由三個頂層域構成，其中：

• List of Devices，表示叢集中裝置的列表，在Ring類內部被稱為devs；
• Partition Assignment List，用於存放每個replica與device間映射關係，在Ring類內部被稱為_replica2part2dev_id；
• Partition Shift Value，表示計算資料hash的移位量，在Ring類內部稱為_part_shift。

使用python讀取/etc/swift/object.ring.gz存放的資料，可以獲得以devs、 part_shift、 replica2part2dev_id 為key的dict類資料。

4.4        Swift儲存結構

在Storage Node上運行著Linux系統並使用了XFS檔案系統，邏輯上使用一致性雜湊演算法將固定總數的partition映射到每個Storage Node上，每個data也使用同樣的雜湊演算法映射到partition上。

儲存內容一般放在/srv/node/sdb1之類的路徑下，其目錄結構如下所示：accounts、async_pending、containers、objects、quarantined和tmp。其中accounts、containers、objects分別是帳號、容器、對象的儲存目錄，async_pending是非同步待更新目錄，quarantined是隔離目錄，tmp是臨時目錄。

• objects：在objects目錄下存放的是各個partition目錄，其中每個partition目錄是由若干個suffix_path名的目錄和一個hashes.pkl檔案組成，suffix_path目錄下是由object的hash_path名構成的目錄，在hash_path目錄下存放了關於object的資料和中繼資料；object的資料存放在尾碼為.data的檔案中，它的metadata存放在以尾碼為.meta的檔案中，將被刪除的Object以一個0位元組尾碼為.ts的檔案存放。
• accounts：在accounts目錄下存放的是各個partition，而每個partition目錄是由若干個suffix_path目錄組成，suffix_path目錄下是由account的hsh名構成的目錄，在hsh目錄下存放了關於account的sqlite db；在account的db檔案中，包含了account_stat、container、incoming_sync 、outgoing_sync 4張表；其中，表account_stat是記錄關於account的資訊，如名稱、建立時間、container數統計等等；表container記錄關於container的資訊；表incoming_sync記錄到來的同步資料項目；表outgoing_sync表示推送出的同步資料項目。
• containers：containers目錄結構和產生過程與accounts類似，containers的db中共有5張表，其中incoming_sync和outgoing_sync的schema與accounts中的相同。其他3張表分別為container_stat、object、sqlite_sequence；表container_stat與表account_stat相似，其區別是container_stat存放的是關於container資訊。
• tmp：tmp目錄作為account/container/object server向partition目錄內寫入資料前的臨時目錄。例如，client向server上傳某一檔案，object server調用DiskFile類的mkstemp方法建立在路徑為path/device/tmp的目錄。在資料上傳完成之後，再調用put()方法，將資料移動到相應路徑。
• async_pending：async_pending存放未能及時更新而被加入更新隊列的資料。本地server在與remote server建立HTTP串連或者發送資料時逾時導致更新失敗時，將把檔案放入async_pending目錄。這種情況經常發生在系統故障或者是高負荷的情況下。如果更新失敗，本次更新被排入佇列，然後由Updater繼續處理這些失敗的更新工作；account與container的db和object兩者的pending檔案處理方式有所不同：db的pending檔案在更新完其中的一項資料之後，刪除pending檔案中的相應的資料項目，而object的資料在更新完成之後，移動pending檔案到目標目錄。
• quarantined：quarantined路徑用於隔離發生損壞的資料。Auditor進程會在本機伺服器上每隔一段時間就掃描一次磁碟來檢測account、container、object的完整性。一旦發現不完整的資料，該檔案就會被隔離，該目錄就稱為quarantined目錄。為了限制Auditor消耗過多的系統資源，其預設掃描間隔是30秒，每秒最大的掃描檔案數為20，最高速率為10Mb/s。account和container的Auditor的掃描間隔比object要長得多。

圖5 隔離對象的處理流程

5       小結

Swift犧牲一定程度的資料一致性，來達到高可用性和延展性，支援多租戶模式、容器和對象讀寫操作，適合解決互連網的應用情境下非結構化資料存放區問題。

有理由相信，因為其完全的開放性、廣泛的使用者群和社區貢獻者，Swift可能會成為雲端儲存的開放標準，從而打破Amazon S3在市場上的壟斷地位，推動雲端運算在朝著更加開放和可互操作的方向前進。

6       參考資料

1) 《Openstack Swift 原理、架構與 API 介紹》，http://www.kankanews.com/ICkengine/archives/66411.shtml

2) 《深入雲端儲存系統Swift核心組件：Ring實現原理剖析》，http://www.cnblogs.com/yuxc/archive/2012/06/22/2558312.html

3) 《深入雲端儲存系統Swift核心組件：Ring資料結構及構建、重平衡操作》，http://www.cnblogs.com/yuxc/archive/2012/06/28/2568584.html

4) 《深入雲端儲存系統Swift儲存節點：儲存實現分析》，http://www.cnblogs.com/yuxc/archive/2012/07/04/2575536.html

5) 《OpenStackObject Storage Service——Swift開源雲端運算》，http://dev.yesky.com/244/33228744.shtml

6) 《討論：HDFS和OpenStackObject Storage Service的技術差異》，http://os.51cto.com/art/201202/314254.htm