OpenStack對象存儲——Swift

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

新浪SAE團隊對Swift有將近一年的研究和運營經驗。在深刻剖析Swift架構和原理、徹底掌握Swift源碼，而且通過一段時間的測試和運營 以後，咱們決定將推出基於Swift的SAE Storage服務。目前，已完成開發，並於一個月前開始線上運行，且表現很是出色。所以，下面將分享一下咱們在Swift上的一些研究和工做。

Swift特性

在OpenStack官網中，列舉了Swift的20多個特性，其中最引人關注的是如下幾點。

極高的數據持久性

一些朋友常常將數據持久性（Durability）與系統可用性（Availability）兩個概念混淆，前者也理解爲數據的可靠性，是指數據存 儲到系統中後，到某一天數據丟失的可能性。例如Amazon S3的數據持久性是11個9，即若是存儲1萬（4個0）個文件到S3中，1千萬（7個0）年以後，可能會丟失其中1個文件。那麼Swift能提供多少個9 的SLA呢？下文會給出答案。針對Swift在新浪測試環境中的部署，咱們從理論上測算過，Swift在5個Zone、5×10個存儲節點的環境下，數據 複製份是爲3，數據持久性的SLA能達到10個9。

徹底對稱的系統架構

「對稱」意味着Swift中各節點能夠徹底對等，能極大地下降系統維護成本。

無限的可擴展性

這裏的擴展性分兩方面，一是數據存儲容量無限可擴展；二是Swift性能（如QPS、吞吐量等）可線性提高。由於Swift是徹底對稱的架構，擴容只需簡單地新增機器，系統會自動完成數據遷移等工做，使各存儲節點從新達到平衡狀態。

無單點故障

在互聯網業務大規模應用的場景中，存儲的單點一直是個難題。例如數據庫，通常的HA方法只能作主從，而且「主」通常只有一個；還有一些其餘開源存儲 系統的實現中，元數據信息的存儲一直以來是個頭痛的地方，通常只能單點存儲，而這個單點很容易成爲瓶頸，而且一旦這個點出現差別，每每能影響到整個集羣， 典型的如HDFS。而Swift的元數據存儲是徹底均勻隨機分佈的，而且與對象文件存儲同樣，元數據也會存儲多份。整個Swift集羣中，也沒有一個角色 是單點的，而且在架構和設計上保證無單點業務是有效的。

簡單、可依賴

簡單體如今架構優美、代碼整潔、實現易懂，沒有用到一些高深的分佈式存儲理論，而是很簡單的原則。可依賴是指Swift經測試、分析以後，能夠放心 大膽地將Swift用於最核心的存儲業務上，而不用擔憂Swift捅簍子，由於無論出現任何問題，都能經過日誌、閱讀代碼迅速解決。

應用場景

Swift提供的服務與Amazon S3相同，適用於許多應用場景。最典型的應用是做爲網盤類產品的存儲引擎，好比Dropbox背後就是使用Amazon S3做爲支撐的。在OpenStack中還能夠與鏡像服務Glance結合，爲其存儲鏡像文件。另外，因爲Swift的無限擴展能力，也很是適合用於存儲 日誌文件和數據備份倉庫。

Swift架構概述

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

圖1 Swift部署架構

主要組件

Proxy Server

Proxy Server是提供Swift API的服務器進程，負責Swift其他組件間的相互通訊。對於每一個客戶端的請求，它將在Ring中查詢Account、Container或 Object的位置，而且相應地轉發請求。Proxy提供了Rest-full API，而且符合標準的HTTP協議規範，這使得開發者能夠快捷構建定製的Client與Swift交互。

Storage Server

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

Consistency Servers

在磁盤上存儲數據並向外提供Rest-ful API並非難以解決的問題，最主要的問題在於故障處理。Swift的Consistency Servers的目的是查找並解決由數據損壞和硬件故障引發的錯誤。主要存在三個Server：Auditor、Updater和Replicator。 Auditor運行在每一個Swift服務器的後臺持續地掃描磁盤來檢測對象、Container和帳號的完整性。若是發現數據損壞，Auditor就會將 該文件移動到隔離區域，而後由Replicator負責用一個無缺的拷貝來替代該數據。圖2給出了隔離對象的處理流圖。 在系統高負荷或者發生故障的狀況下，Container或帳號中的數據不會被當即更新。若是更新失敗，該次更新在本地文件系統上會被加入隊列，而後 Updaters會繼續處理這些失敗了的更新工做，其中由Account Updater和Container Updater分別負責Account和Object列表的更新。 Replicator的功能是處理數據的存放位置是否正確而且保持數據的合理拷貝數，它的設計目的是Swift服務器在面臨如網絡中斷或者驅動器故障等臨 時性故障狀況時能夠保持系統的一致性。

圖2 隔離對象的處理流圖

Ring

Ring是Swift最重要的組件，用於記錄存儲對象與物理位置間的映射關係。在涉及查詢Account、 Container、Object信息時，就須要查詢集羣的Ring信息。 Ring使用Zone、Device、Partition和Replica來維護這些映射信息。Ring中每一個Partition在集羣中都（默認）有3 個Replica。每一個Partition的位置由Ring來維護，並存儲在映射中。Ring文件在系統初始化時建立，以後每次增減存儲節點時，須要從新 平衡一下Ring文件中的項目，以保證增減節點時，系統所以而發生遷移的文件數量最少。

原理

Swift用到的算法和存儲理論並不複雜，主要有幾下幾個概念。

一致性哈希算法

Swift利用一致性哈希算法構建了一個冗餘的可擴展的分佈式對象存儲集羣。Swift採用一致性哈希的主要目的是在改變集羣的Node數量時，能 夠儘量少地改變已存在Key和Node的映射關係。 該算法的思路分爲如下三個步驟。 首先計算每一個節點的哈希值，並將其分配到一個0~232的圓環區間上。其次使用相同方法計算存儲對象的哈希值，也將其分配到這個圓環上。隨後從數據映射到 的位置開始順時針查找，將數據保存到找到的第一個節點上。若是超過232仍然找不到節點，就會保存到第一個節點上。 假設在這個環形哈希空間中存在4臺Node，若增長一臺Node5，根據算法得出Node5被映射在Node3和Node4之間，那麼受影響的將僅是沿 Node5逆時針遍歷到Node3之間的對象（它們原本映射到Node4上）。其分佈如圖3所示。

圖3 一致性哈希環結構

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

Zone

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

Weight

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

圖4 一種Swift部署集羣

實例分析

圖4中是新浪SAE在測試環境中部署的Swift集羣，集羣中又分爲5個Zone， 每一個Zone是一臺存儲服務器，每臺服務器上由12塊2TB的SATA磁盤組成，只有操做系統安裝盤須要RAID，其餘盤做爲存儲節點，不須要RAID。 前面提到過，Swift採用徹底對稱的系統架構，在這個部署案例中獲得了很好的體現。圖4中每一個存儲服務器的角色是徹底對等的，系統配置徹底同樣，均安裝 了全部Swift服務軟件包，如Proxy Server、Container Server和Account Server等。上面的負載均衡（Load Balancer）並不屬於Swift的軟件包，出於安全和性能的考慮，通常會在業務以前擋一層負載均衡設備。固然能夠去掉這層代理，讓Proxy Server直接接收用戶的請求，但這可能不太適合在生產環境中使用。 圖4中分別表示了上傳文件PUT和下載文件GET請求的數據流，兩個請求操做的是同一個對象。上傳文件時，PUT請求經過負載均衡隨機挑選一臺Proxy Server，將請求轉發到後者，後者經過查詢本地的Ring文件，選擇3個不一樣Zone中的後端來存儲這個文件，而後同時將該文件向這三個存儲節點發送 文件。這個過程須要知足NWR策略（Quorum Protocol），即3份存儲，寫成功的份數必須大於3/2，即必須保證至少2份數據寫成功，再給用戶返回文件寫成功的消息。下載文件時，GET請求也 經過負載均衡隨機挑選一臺Proxy Server，後者上的Ring文件能查詢到這個文件存儲在哪三個節點中，而後同時去向後端查詢，至少有2個存儲節點「表示」能夠提供該文件，而後 Proxy Server從中選擇一個節點下載文件。

小結

Swift簡單、冗餘、可擴展的架構設計保證了它可以用於IaaS的基礎服務。在Rackspace Cloud Files服務兩年的運行積累使得Swift代碼變得愈來愈成熟，目前已部署在全球各地的公有云、私有云服務中。隨着OpenStack的不斷完善和發 展，Swift將獲得更普遍的應用。