OpenStack之Swift學習

Swift是OpenStack雲存儲服務的重要組件，它提供了高可用、分佈式、持久性、大文件的對象存儲服務。此外Swift還能夠利用一系列的便宜硬件存儲設備，提供安全、可靠的存儲服務。

問：爲何使用Swift？它有什麼優勢？

1：數據的持久性

數據的持久性是衡量存儲系統的重要指標。持久性就是指用戶的數據存儲到系統中後丟失的可能性。爲了防止數據的丟失，提升數據的持久性，Swift採用冗餘Replica(副本)的處理方法，Replica的默認值爲3.

2：架構對稱性

對稱性是指Swift架構設計上，每一個服務器節點的功能和做用是相等的，而不是採用HDFS(hadoop distributed file system)主從架構。由於採用主從架構，每每會由於master的壓力過大，增長維護的困難，一旦master節點掛掉，便會致使服務的不可靠性。而對稱性的便利就是系統維護簡單，且不會由於某個節點掛掉，對服務形成影響

3：無單節點故障

Swift採用對稱性設計，因此每一個節點的地位徹底相等，因此沒有一個節點是單點的。即系統的性能不會由於某個節點的實效而形成整個系統不可用。此外Swift對元數據（數據的描述信息，如全部者，權限，類型等）的處理與對象文件的存儲方式相同，即都是採用徹底多份均勻隨機分佈存儲。

4:可擴展性

當王Swift中新加入一個節點時，會帶來

1. 存儲容量增長    

2. 系統性能上升

由於是對稱架構，因此係統的擴展也相對簡單。但新加入的節點，其並未存儲數據，而爲了保證新節點與舊節點的地位平等，就必然要將Swift上已經存儲的數據遷移到新的節點上。

因此面臨的問題之一就是，隨着存儲數據量的增大，會面臨大量的數據遷移，從而增長了遷移的難度和消耗的時間。而這也是制約swift系統推廣的緣由之一

5：簡單可靠

Swift採用的原理比較簡單。其架構設計、代碼和算法都比較易懂、且還提供了較高的可靠性、且維護也比較容易

Swift的架構

Swift中的服務器主要有如下3種

1. 認證節點，即提供身份的驗證

   若是隻單獨使用Swift的話，其驗證服務能夠直接使用Swift內置的認證服務，並將此內置的認證服務放在認證節點上；而若是將Swift放在OpenStack中的話，那麼Swift就會才用keystone提供的認證服務，而此時認證節點就不屬於Swift了

   

   2.代理節點，轉發客戶端的請求給Swift + 提供Swift API服務進程

       Proxy server提供了Rest-full API，這讓開發者能夠基於Swift API構建本身的應用程序

   3.存儲節點，將磁盤存儲服務轉換爲Swift中的存儲服務，因爲存儲目標的不一樣，存儲節點上運行的             存儲服務也分爲如下三種：

 Object Server：對象服務（即指用戶要存儲的數據）提供了二進制大對象存儲服務，對象數據是直接利用文件系統的存儲功能，可是對象的元數據是存放在文件系統的擴展屬性中的，所以Object Server 須要底層文件系統提供擴展屬性

Container Server：容器服務（容器之存儲組件，能夠將容器理解爲文件夾，可是容器不能 像文件夾那樣進行嵌套）主要處理對象列表。但從容器到對象是單一映射關係，即容器服務不知道對象存放在哪一個容器上，但卻知道容器上存放了那些對象。這部分信息以文件的形式存放，採用徹底均勻隨機多份存儲（與對象數據的存儲方式同樣）惟一不一樣的是採用的是SQlite格式進行存儲（一種輕型關聯式，嵌套式的數據庫，佔用資源很是少，在嵌入式中均有使用）  

     

Account Server：帳戶服務主要是處理容器列表，除此以外帳戶與容器服務並沒有什麼不一樣

 一個簡單的Swift部署實例就是將對象服務，容器服務，帳戶服務都部署在存儲節點上。若是採用這種方式部署且保證硬件的配置相同，則存儲節點的地位是平等的。

Swift故障處理

Swift的真正難點在於，因爲數據的損壞或者物理硬件故障形成了數據的不一致性！

存儲系統通常採用徹底均勻隨機多備份的方式避免丟失的數據，不過也所以帶來了多個備份之間的數據可能不一致的問題。好比一個文件有3個備份，分別存放在A、B、C服務器上，可是因爲A服務器忽然斷電等意外狀況，等重啓以後A的數據確定一B和C的不一樣

而Swift主要採用下面三個服務來保證在遇到故障時保證數據的一致性：

Auditor：審計服務，審計器會反覆檢測帳戶、容器、對象的一致性。一旦發現某個文件的數據不完整，會馬上將此文件隔離。而後Auditor會通知Replication×××，讓其從其餘一直的副本複製並替換此文件。若是出現其餘錯誤，如全部的副本都掛了，則會將此錯誤信息記錄入日誌

Updater：更新器的主要做用是延遲更新。延遲的主要緣由是爲了因對用戶數據上傳的過程當中出現故障或者異常。在正常的狀況下，其更新順序爲：用戶上傳數據成功後，Object Server向Container Server發起通知，通知Container Server某個Container中新加入了一個Object。Container Server收到該通知，更新好Object列表後，會向Account Server發起通知。Container Server收到通知並更新Container 列表。而這是理想的更新順序。

在實際應用中，因爲網絡斷開、系統高負載、磁盤寫入等待等各類緣由的干擾，都有可能致使更新的失敗，而當某個更新失敗以後，這次更新的操做會被加入到更新隊列中，而後由Updater處理這些失敗了的更新工做。

Replicator：×××負責用完整的副本替換掉損壞的數據。一般會每隔一段時間自動掃描一下本地文件的hash值，並將此hash值與遠端的其餘副本進行對比，若是不一樣，則會作出相應的複製替換操做