OpenStack的Swift組件詳解
一：簡介
背景
1.Swift 最初是由 Rackspace 公司開發的高可用分佈式對象存儲服務（Object Storage Service），並於 2010 年貢獻給 OpenStack 開源社區作為其最初的核心子項目之一，為其 Nova 子項目提供虛機鏡像存儲服務。Swift 構築在比較便宜的標準硬件存儲基礎設施之上，無需采用 RAID（磁盤冗餘陣列），通過在軟件層面引入一致性散列技術和數據冗餘性，犧牲一定程度的數據一致性來達到高可用性和可伸縮性，支持多租戶模式、容器和對象讀寫操作，適合解決互聯網的應用場景下非結構化數據存儲問題。
2. Swift 包括2個組成部分，一個是代理服務（proxy）,一個是存儲服務（storage）。
- 代理服務是Swift內部存儲的拓撲邏輯，即一個具體文件位於哪個存儲節點的哪個區上。它同時是一個web服務器，通過http或https對外提供REST API服務。
- 存儲服務是負責文件存儲的服務，由3個組件組成：account-server、container-server、object-server。其中object-server負責具體的文件存儲，container-server包含到每個object的索引，account-server包含到每個container 的索引。
原理
1. 一致性散列（Consistent Hashing)：Swift 是基於一致性散列技術，通過計算可將對象均勻分佈到虛擬空間的虛擬節點上，在增加或刪除節點時可大大減少需移動的數據量；虛擬空間大小通常采用 2 的 n 次冪，便於進行高效的移位操作；然後通過獨特的數據結構 Ring（環）再將虛擬節點映射到實際的物理存儲設備上，完成尋址過程。
- 1. 平衡性：平衡性是指哈希的結果能夠盡可能的分佈到所有的緩沖中去，這樣可以使得所有緩沖空間能夠都得到利用。為瞭更好的滿足平衡性，引入瞭虛擬節點概念，虛擬節點是實際節點在hash空間的復制品，一個實際節點對應若幹個虛擬節點，這個對應的個數也稱為復制個數，虛擬節點在hash空間以hash值排列。
- 2. 單調性：單調性是指如果已經有些內容通過Hash分派到相應的緩沖中，又有新的緩沖加入到系統中，哈希的結果應能夠保證原有已分配的內容可以被映射到原有或者新的緩沖中區，而不會被映射到舊的或者其他緩沖區。
- 3. 分散性：在分佈式環境中，客戶端可能看不到所有的緩沖，而隻能看到其中一部分。當終端希望通過哈希過程將內容映射到緩沖上時，由於不同的客戶端所看到的緩沖范圍可能不同，從而導致得到的Hash結果不一致，導致結果相同的內容被映射到不用的緩沖區中。這種情況應該被避免，因為這將會導致相同的內容將會被映射到不同緩沖區中，降低瞭系統的存儲效率。
- 4. 負載：負載時對分散性要求的另一個維度。既然相同的內容可能被映射到不同的緩沖中去，那麼對於同一個緩沖而言，就有可能被不同的用戶映射不同的內容。與分散性一樣，這種情況應該被避免。
- 5. 如圖所示，以逆時針方向遞增的散列空間有 4 個字節長共 32 位，整數范圍是[0~232-1]；將散列結果右移 m 位，可產生 232-m個虛擬節點，例如 m=29 時可產生 8 個虛擬節點。在實際部署的時候需要經過仔細計算得到合適的虛擬節點數，以達到存儲空間和工作負載之間的平衡。
2. 數據一致性模型（Consistency Model）
按照 Eric Brewer 的 CAP（Consistency，Availability，Partition Tolerance）理論，無法同時滿足 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。Swift 默認配置是 N=3，W=2>N/2，R=1 或 2，即每個對象會存在 3 個副本，這些副本會盡量被存儲在不同區域的節點上；W=2 表示至少需要更新 2 個副本才算寫成功；當 R=1 時意味著某一個讀操作成功便立刻返回，此種情況下可能會讀取到舊版本（弱一致性模型）；當 R=2 時，需要通過在讀操作請求頭中增加 x-newest=true 參數來同時讀取 2 個副本的元數據信息，然後比較時間戳來確定哪個是最新版本（強一致性模型）；如果數據出現瞭不一致，後臺服務進程會在一定時間窗口內通過檢測和復制協議來完成數據同步，從而保證達到最終一致性。如圖 2 所示：
3. 環的數據結構
環是為瞭將虛擬節點（分區）映射到一組物理存儲設備上，並提供一定的冗餘度而設計的，其數據結構由以下信息組成：
- 存儲設備列表、設備信息包括唯一標識號（id）、區域號（zone）、權重（weight）、IP 地址（ip）、端口（port）、設備名稱（device）、元數據（meta）。
- 分區到設備映射關系（replica2part2dev_id 數組)。
- 計算分區號的位移(part_shift 整數)。
使用對象的層次結構 account/container/object 作為鍵，使用 MD5 散列算法得到一個散列值，對該散列值的前 4 個字節進行右移操作得到分區索引號，移動位數由上面的 part_shift 設置指定；按照分區索引號在分區到設備映射表（replica2part2dev_id）裡查找該對象所在分區的對應的所有設備編號，這些設備會被盡量選擇部署在不同區域（Zone）內，區域隻是個抽象概念，它可以是某臺機器，某個機架，甚至某個建築內的機群，以提供最高級別的冗餘性，建議至少部署 5 個區域；權重參數是個相對值，可以來根據磁盤的大小來調節，權重越大表示可分配的空間越多，可部署更多的分區。
4. 數據模型
Swift 采用層次數據模型，共設三層邏輯結構：Account/Container/Object（即賬戶/容器/對象)，每層節點數均沒有限制，可以任意擴展。
賬戶和個人賬戶不是一個概念，可理解為租戶，用來做頂層的隔離機制，可以被多個個人賬戶所共同使用；
容器代表封裝一組對象，類似文件夾或目錄；葉子節點代表對象，由元數據和內容兩部分組成，如圖所示：
特性
1.大量對象的存儲（Storageoflargenumberofobjects）。
2. 大對象的存儲（Storageoflargesizedobjects）。
3. 數據冗餘（DataRedundancy）。
4. 檔案能力——存儲大數據集（Archivalcapabilities-Workwithlargedatasets）。
5. 虛擬機和雲應用的數據容器（Datacontainerforvirtualmachinesandcloudapps）。
6. 流媒體的能力（MediaStreamingcapabilities）。
7. 對象存儲安全（Securestorageofobjects）。
8. 備份和檔案（Backupandarchival）。
9. 極高的擴展性（Extremescalability）
二：架構
核心架構
組件詳解
1. 代理服務（Proxy Server）：對外提供對象服務 API，會根據環的信息來查找服務地址並轉發用戶請求至相應的賬戶、容器或者對象服務；由於采用無狀態的 REST 請求協議，可以進行橫向擴展來均衡負載。
2. 認證服務（Authentication Server）：驗證訪問用戶的身份信息，並獲得一個對象訪問令牌（Token），在一定的時間內會一直有效；驗證訪問令牌的有效性並緩存下來直至過期時間。
3. 緩存服務（Cache Server）：緩存的內容包括對象服務令牌，賬戶和容器的存在信息，但不會緩存對象本身的數據；緩存服務可采用 Memcached 集群，Swift 會使用一致性散列算法來分配緩存地址。
4. 賬戶服務（Account Server）：提供賬戶元數據和統計信息，並維護所含容器列表的服務，每個賬戶的信息被存儲在一個 SQLite數據庫中。
5. 容器服務（Container Server）：提供容器元數據和統計信息，並維護所含對象列表的服務，每個容器的信息也存儲在一個 SQLite 數據庫中。
6. 對象服務（Object Server）：提供對象元數據和內容服務，每個對象的內容會以文件的形式存儲在文件系統中，元數據會作為文件屬性來存儲，建議采用支持擴展屬性的 XFS 文件系統。
7. 復制服務（Replicator）：會檢測本地分區副本和遠程副本是否一致，具體是通過對比散列文件和高級水印來完成，發現不一致時會采用推式（Push）更新遠程副本，例如對象復制服務會使用遠程文件拷貝工具 rsync 來同步；另外一個任務是確保被標記刪除的對象從文件系統中移除。
8. 更新服務（Updater）：當對象由於高負載的原因而無法立即更新時，任務將會被序列化到在本地文件系統中進行排隊，以便服務恢復後進行異步更新；例如成功創建對象後容器服務器沒有及時更新對象列表，這個時候容器的更新操作就會進入排隊中，更新服務會在系統恢復正常後掃描隊列並進行相應的更新處理。
9. 審計服務（Auditor）：檢查對象，容器和賬戶的完整性，如果發現比特級的錯誤，文件將被隔離，並復制其他的副本以覆蓋本地損壞的副本；其他類型的錯誤會被記錄到日志中。
10. 賬戶清理服務（Account Reaper）：移除被標記為刪除的賬戶，刪除其所包含的所有容器和對象。
Swift對CAP的支持程度
1. CAP概述：美國著名科學傢，Berkerly大學Brewer教授提出的一個分佈式系統不能同時滿足一致性，可用性和分區容錯性這三個需求，最多隻能同時滿足兩個。重要屬性：
- 一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結果，也就是在分佈式環境中，多點的數據是一致的。
- 可用性(Availability)：每一個操作總是能夠在確定的時間內返回，也就是系統隨時都是可用的。
- 分區可容忍性(ToleranceofnetworkPartition)：在出現網絡分區（比如斷網）的情況下，分離的系統也能正常運行。
2. Swift對CAP的支持
- Consistency：Swift的一致性歸為弱一致性模型。Swift 由 updater 保證最終一致性，auditor 保證存儲對象的完整性。Swift 隻能保證數據的最終一致性，即，如果upload(update也是一種upload)一個object,從其他客戶端GET這個object，不一定是最新的。
- Availability：基於python對hash的原生支持，swift中廣泛使用瞭hash算法。比如均衡ring中partition的分佈，objectupdate備份策略。sqlite控制account/container/object的相關信息，簡化瞭維護成本。
三：常用操作
以上就是OpenStack的Swift組件詳解的詳細內容，更多關於OpenStack的Swift的資料請關註WalkonNet其它相關文章！