重點內容

• 後設資料管理十分重要，猶如整個儲存系統的“大黃頁”，如果後設資料操作出現效能瓶頸，將嚴重影響儲存系統的整體效能。
• 如何提升後設資料處理速度與高可用是後設資料管理的挑戰之一。SmartX 分散式儲存 ZBS 採用 Log Replication 的機制，在後設資料儲存方案上選擇將 LevelDB 和 Zookeeper 相結合，從而以更加精簡的架構實現了高可靠、高效能與輕量級的後設資料服務。
• 更多 ZBS 架構設計與技術解讀，請閱讀文末電子書 《分散式塊儲存 ZBS 自主研發之旅》。

在之前的幾篇關於 SmartX 分散式塊儲存 ZBS 架構設計文章中，已對 ZBS 儲存的 整體架構設計、 接入協議 NVMe-oF 和 資料同步協議 RDMA 進行了較為全面的介紹。為了幫助使用者更好地理解 ZBS 儲存底層的設計實現，本篇文章將涉足儲存系統中非常重要的元件之一：後設資料管理。

後設資料是什麼？通常得到相對簡單的答案是描述資料的資料。這句解釋並沒有錯，但是有些抽象，並不容易理解。後設資料本身並不會暴露自己給使用者，僅是為儲存系統或檔案系統服務，我們可以將後設資料想象成過去查公司電話和地址的大黃頁或是圖書的索引，用於記錄資料的儲存位置。當使用者需要讀取或修改某個檔案時，這個檔案對應儲存的具體位置，就是由後設資料進行管理的。當然，除了記錄儲存位置，後設資料還會儲存一些資料的屬性資訊，來擴充套件資料的管理能力，例如資料塊什麼時間建立、什麼時間發生修改、資料塊是否需要回收、資料塊的操作許可權等。

所以，在儲存系統內部，後設資料管理十分地重要，凡是涉及到儲存系統的資料訪問，都會經過後設資料的查詢或更新操作，如果後設資料操作出現效能瓶頸，將會嚴重影響儲存系統的效能表現。 本文透過多個維度展開介紹後設資料管理的現狀以及未來的發展趨勢，同時分享 ZBS 的後設資料設計思想。

後設資料管理演變

最簡單的後設資料管理 Meta Server（後設資料服務）+ Meta DB（資料庫）：這種方案算是初代經典的設計思想，後續方案在此基礎上進行延展。

基於高可用架構的後設資料管理：這個方案的前置條件需要部署多節點，合理佈局 Master 和 Slave 角色，從而提高節點容錯性。

基於記憶體的後設資料管理：Meta Server 透過將後設資料全部載入到記憶體，加速後設資料的訪問速度，從而滿足後設資料訪問更高的效能要求。由於採用記憶體載入後設資料，在設計上，需要評估資料規模。

在海量資料規模下，單節點記憶體已不能承載全部的後設資料，將後設資料分割槽（分散式架構橫向擴充套件）則是一條主要的技術發展方向：將後設資料按照規則進行分拆，透過多個 Meta Server 服務來管理各自維護的後設資料。此方案還需要一層路由或代理服務角色，用來處理請求轉發。

除後設資料橫向擴充套件外，另一條技術方向是分層（Tier Layer）管理後設資料，這裡稱為縱向擴充套件。設計思想是將熱點資料做記憶體快取（Cache Layer）、冷資料做持久化儲存在磁碟（Persisted Layer），根據演算法，實現冷熱資料的交換。

後設資料管理的挑戰

設計和管理儲存系統的後設資料是一個複雜的任務，面臨著多個挑戰。以下是一些與後設資料管理相關的主要挑戰：

• 一致性和完整性 ：後設資料的一致性和完整性是關鍵問題。當多個使用者或應用程式同時對儲存系統進行讀寫操作時，確保後設資料的一致性和完整性需要採用適當的鎖定和同步機制，以及正確的事務處理策略。
• 效能和可伸縮性：後設資料的管理對儲存系統的效能和可伸縮性有重要影響。後設資料的訪問和更新操作需要快速響應，並能夠處理高併發的請求。設計高效的後設資料儲存和檢索機制，以及合理的快取策略，可以提高儲存系統的效能和可伸縮性。
• 後設資料的儲存和備份：後設資料本身也需要進行儲存和備份。後設資料的儲存可能需要考慮容錯和冗餘，以防止後設資料丟失或損壞。
• 後設資料的查詢和檢索：儲存系統中的後設資料通常需要進行查詢和檢索操作。後設資料的查詢可能涉及複雜的條件和關聯關係，需要設計高效的查詢引擎和索引策略。
• 後設資料的演化和版本管理：隨著儲存系統的演化和升級，後設資料的結構和內容可能會發生變化。管理後設資料的演化和版本也是挑戰之一，需要考慮向後相容性和資料遷移策略，以確保後設資料的連續性和可靠性。

儲存系統的後設資料管理涉及到資料量和複雜性、一致性和完整性、效能和可伸縮性、儲存和備份、查詢和檢索、演化和版本管理等多個挑戰。解決這些挑戰需要綜合考慮系統架構、儲存技術、資料管理策略等多方面的因素。

ZBS Meta 後設資料服務

ZBS 對後設資料的需求

ZBS 儲存的定位是分散式塊儲存系統，主要應用場景包括雲端計算 IaaS、虛擬化、裸金屬資料庫和容器。基於這些應用場景，ZBS 對後設資料管理有如下幾個需求：

• 由於後設資料的重要性，對後設資料的第一個需求就是 可靠性。後設資料必須是儲存多份，同時後設資料服務還需要提供 Failover 的能力。
• 第二個需求就是 高效能。儘管可以對 I/O 路徑進行最佳化，使得大部分 I/O 請求都不需要訪問後設資料服務，但永遠都有一些 I/O 請求還是需要修改後設資料，比如資料分配等。為避免後設資料操作成為系統效能的瓶頸，後設資料操作的響應時間必須足夠短。同時由於分散式系統的叢集規模在不斷的擴大，對於後設資料服務的併發能力也有較高的要求。
• 最後一個需求是 輕量級。由於定位 ZBS 大部分使用場景是私有部署，也就是將 ZBS 部署在客戶的資料中心內，且由客戶自己運維，這個場景和很多網際網路公司自己來運維自己的產品是完全不同的。所以對於 ZBS 來說，更強調整個儲存系統，尤其是後設資料服務的輕量級，以及易運維的能力。希望後設資料服務輕量到和資料服務混合部署在一起，這樣的好處是可以三節點起步，無需獨立的管理角色節點。
  • 如果大家瞭解 HDFS 的話，HDFS 中的後設資料服務的模組叫做 Namenode，這是一個非常重量級的模組。Namenode 需要被獨立部署在一臺物理伺服器上，且對硬體的要求非常高，也非常不易於運維，無論是升級還是主備切換，都是非常重的操作，非常容易因操作問題而引發故障。

ZBS 後設資料儲存技術實現思考

提及後設資料儲存，第一個想到的方案就是關係型資料庫，例如 MySQL，以及一些成熟的 KV 儲存引擎，例如 LevelDB，RocksDB 等。這種型別的儲存最大的問題就是無法提供可靠的資料保護和 Failover 能力。LevelDB 和 RocksDB 雖然非常輕量級，但都只能把資料儲存在單機上。儘管 MySQL 提供一些主備方案，但 MySQL 的主備方案過於笨重，在故障切換場景中並不靈活，且缺乏簡易的自動化運維方案，所以並不是一個十分好的選擇。

其他的方案還包括分散式資料庫，例如 MongoDB 和 Cassandra。這兩種分散式資料庫都可以解決資料保護和提供 Failover 機制。但是他們都不提供或不能全面支援 ACID 機制，所以在上層實現時會比較麻煩，需要額外的工作量。其次就是這些分散式資料庫在運維上也相對複雜，不是很易於自動化運維。

基於 Paxos 或者 Raft 協議自己實現一個框架？這樣實現的代價會非常大，對於一個初創公司並不是一個 較好 選擇（SmartX 成立時間是 2013 年，當時 Raft 也只是剛剛提出）。

還可以選擇 Zookeeper。Zookeeper 基於 ZAB 協議（Zookeeper Atomic Broadcast），可以提供一個穩定可靠的分散式儲存服務（崩潰恢復和訊息廣播），確保事務的一致性。但 Zookeeper 的最大的問題是儲存的資料容量非常有限，為了提高訪問速度，Zookeeper 把儲存的所有資料都快取在記憶體中，所以這種方案導致後設資料服務所能支撐的資料規模嚴重受限於伺服器的記憶體容量，使得後設資料服務無法做到輕量級，也無法和資料服務混合部署在一起。

最後還有一種方案是基於 DHT（Distributed Hash Table）的路線（很多開源類產品，例如 Ceph，都是基於 DHT 實現）。這種方案的好處即後設資料中不需要儲存資料副本的儲存位置，而是根據一致性雜湊的方式計算出來，這樣就極大地降低了後設資料服務的儲存壓力和訪問壓力。但使用 DHT ，就喪失了對資料副本位置的控制權，在實際生產環境中，非常容易造成叢集中的資料不均衡的現象。同時在運維過程中，如果遇到需要新增節點、移除節點、新增磁碟、移除磁碟的情況，由於雜湊環會發生變化，一部分資料需要重新分佈，會在叢集中產生不必要的資料遷移，而且資料量往往非常大。而這些運維操作在客戶的資料中心幾乎每天都會發生。大規模的資料遷移很容易影響到線上的業務的效能，所以 DHT 使得運維操作變得非常麻煩而不可控。

ZBS 後設資料設計實現

透過以上分析，可以看出，每種技術路線均有各種各樣的問題，並不能直接使用。 ZBS 採用 Log Replication 的機制，設計上，選擇 Raft 可能要優於 ZK，但綜合評估實現複雜性和代價， 最終選擇 LevelDB 和 Zookeeper 相結合，並同時避開他們自身的問題，實現後設資料管理服務。

這裡簡單地介紹一下 Log Replication。簡單來說，把資料或者狀態看作是一組對資料操作的歷史集合，而每一個操作都可以透過被序列化成 Log 記錄下來。如果可以拿到所有的 Log，並按照 Log 裡面記錄的操作重複一遍，那麼就可以完整的恢復資料的狀態。任何一個擁有 Log 的程式都可以透過重放 Log 的方式恢復資料。如果對 Log 進行復制，實際上也就相當於對資料進行了複製。這就是 Log Replication 最基本的想法。

ZBS 後設資料的關鍵能力設計：

• 可靠性 – 在單 Master 架構中，後設資料必須儲存多份，同時後設資料服務需要提供容錯和快速切換的能力。ZBS 選擇採用單機 KV DB 來實現 Meta 本地後設資料持久化，利用 Log Replication 機制實現後設資料在多節點間的資料同步。當 Meta Lead 失效，Follower 節點透過 Zookeeper 選主快速接管後設資料服務。
• 高效能 – 最小化後設資料服務在儲存 I/O 路徑中的參與度。ZBS 將控制平面與資料平臺進行分離，使大部分 I/O 請求不需要訪問後設資料服務，當需要修改後設資料時，比如資料分配，後設資料操作的響應時間必須足夠快。ZBS 定義資料塊 Extent 為 256 MiB，在 2 PiB 叢集儲存容量規模下（當前版本下，SmartX 單叢集容量上限），後設資料可全部載入到記憶體中操作，提高查詢效率。
• 輕量級 – 為了讓架構簡單，ZBS 並沒有拆分成管理節點和資料節點，而是儘可能保證效能和安全性的前提下，降低後設資料的儲存空間和記憶體消耗。後設資料服務與資料服務混合部署在同一個節點，三節點即可部署交付，而無需獨立部署管理節點。

ZBS 後設資料服務的具體實現：

• 叢集部署多個（3 或 5）Meta Server，每個 Server 本地執行了一個 LevelDB 資料庫，Meta Server 透過 Zookeeper 進行選主，Leader 節點對外提供服務，其他 Meta Server 進入 Standby 狀態。
• 當 Leader 節點接收到後設資料的更新操作後，會將這個操作序列化成一組操作日誌，並將這組日誌寫入 Zookeeper。由於 Zookeeper 是多副本的，所以一旦 Log 資料寫入 Zookeeper，也就意味著 Log 資料是安全的。
• 為了避免 Zookeeper 消耗過多記憶體，ZBS 會對 Zookeeper 中的 Log 定期執行清理。只要 Log 已經被所有的 Meta Server 同步完， Zookeeper 中儲存的 Log 就可以被刪除了，以節省空間。
• 當日志提交成功後，Meta Server 就可以將對後設資料的修改同時提交到本地的 LevelDB 中。這裡 LevelDB 中儲存的是一份全量的資料，而不需要以 Log 的形式儲存。
• 對於非 Leader 的 Meta Server 節點，會非同步的從 Zookeeper 中拉取 Log，並將透過反序列化，將 Log 轉換成對後設資料的操作，再將這些修改操作提交到本地的 LevelDB 中。這樣就能保證每一個 Meta Server 都可以儲存一個完整的後設資料。
• Meta Server Failover 邏輯非常簡單。當 Leader 節點發生故障，Standby 狀態的 Meta Server 透過 Zookeeper 再重新進行一次選主，選出一個新的 Meta Leader。這個新的 Leader 首先從 Zookeeper 上同步所有還未拉取的日誌，反序列化後提交到本地的 LevelDB 中，然後就可以對外正常提供後設資料服務。

ZBS 後設資料服務特點：

• 架構簡單，由 Zookeeper 負責選主和 Log Replication，由 LevelDB 負責本地後設資料的儲存。
• 處理效能高，Zookeeper 和 LevelDB 本身的效能都很出色，而且在部署時，將 Zookeeper 和 LevelDB 執行在 SSD 高速儲存介質。在實際測試中，對於單次後設資料的修改都是在毫秒級完成。在併發的場景下，可以對後設資料修改的日誌做 Batch，以提高併發能力。
• 切換速度快，Meta Server Failover 的時間就是叢集選主，再加上 Log 同步的時間，可以做到秒級恢復後設資料服務。
• 後設資料服務對資源消耗非常小，可以做到和資料服務混合部署，從而實現叢集三節點起步。

未來後設資料管理的趨勢和發展

隨著儲存系統的不斷髮展和變化，後設資料管理也在不斷演化和改進。正如前文對後設資料管理技術路線的分析，透過分割槽（分散式架構）實現後設資料管理，可以更好地面對資料激增、架構橫向擴充套件、查詢速度提升、降低切換時間等要求與挑戰。

後設資料在儲存系統中發揮著重要的作用，未來的後設資料管理也將面臨更多的挑戰和機遇。透過合理的後設資料管理策略和技術實現，可以更好地管理和維護資料，並提高儲存系統的可靠性、穩定性和高效執行。

這裡留個彩蛋，ZBS 將在下一個大版本更新時進一步最佳化後設資料管理機制，待正式釋出後，再分享其背後的思考和設計實現。

想了解更多 ZBS 的架構原理和技術細節？歡迎閱讀電子書 。