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中新加入一個節點時，會帶來
存儲容量增加
系統性能上升
因為是對稱架構，所以系統的擴展也相對簡單。但新加入的節點，其並未存儲數據，而為了保證新節點與舊節點的地位平等，就必然要將Swift上已經存儲的數據遷移到新的節點上。
所以面臨的問題之一就是，隨著存儲數據量的增大，會面臨大量的數據遷移，從而增加了遷移的難度和消耗的時間。而這也是制約swift系統推廣的原因之一
5：簡單可靠
Swift采用的原理比較簡單。其架構設計、代碼和算法都比較易懂、且還提供了較高的可靠性、且維護也比較容易
Swift的架構
Swift中的服務器主要有以下3種
認證節點，即提供身份的驗證
如果只單獨使用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值與遠端的其他副本進行對比，如果不同，則會做出相應的復制替換操作
本文出自 “11097124” 博客，請務必保留此出處http://11107124.blog.51cto.com/11097124/1962076
OpenStack之Swift學習