引言
在分散式儲存系統中，硬體故障是無法避免的風險。Apache Ozone 作為支援 HDFS 與 S3 協議的高可用性儲存解決方案，其核心設計目標在於確保資料持續可用性與系統穩定性。本文深入解析 Ozone 的故障容錯機制，探討其如何透過架構設計與自動化處理流程，實現資料一致性與服務連續性。
技術定義與架構概述
Apache Ozone 是由 Apache 基金會（Apache Foundation）維護的分散式儲存系統，專為雲端與大規模資料處理場景設計。其核心架構包含三大元件：
- Ozone Manager (OM)：儲存命名空間元資料（如檔案名稱、體積、桶位等），採用 Raft 協議實現高可用性，資料跨三節點複製。
- Storage Container Manager (SCM)：管理儲存容器（Storage Container）的元資料，同樣使用 Raft 協議確保一致性。
- Data Node：儲存實際資料塊，透過 SCM 管理資料複製與分佈。
此架構設計使 Ozone 能在硬體故障時，透過自動化機制維持資料可用性與系統穩定性。
故障容錯機制與處理流程
網路故障
- Leader 分區：當 Leader 節點與 Followers 之間網路中斷時，Followers 會重新選舉 Leader，原 Leader 經過超時後自動降級。
- 自動恢復：網路恢復後，原 Leader 會重新加入集群，同步最新狀態。
- Raft 一致性：所有操作需經由 Quorum（2/3 節點）確認，確保狀態一致性。
節點故障
- 節點宕機：剩餘兩節點仍可運作，客戶端自動重試操作於新 Leader。
- 節點替換：硬體故障節點需進行 Bootstrapping，重新加入集群並同步資料。
- 冗餘建議：建議使用 RAID 1 設置，提升磁碟冗餘性。
磁碟故障
Ozone Manager 磁碟故障
- 資料庫故障：若磁碟無法讀取/寫入，節點會關閉並記錄錯誤，觸發 Leader 選舉。
- 資料恢復：行政人員可更換磁碟後重新加入集群。
Data Node 磁碟故障
Volume Scanner 機制：
- 目錄檢查：驗證磁碟掛載點與權限配置。
- 磁碟檢查：執行 I/O 驗證（寫入測試資料→同步→讀取驗證→刪除測試資料）。
- 容錯策略：採用滑動窗口機制，若連續兩次檢查失敗則標記磁碟故障並觸發資料複製。
Container Scanner 機制：
- 檢查儲存容器內所有資料塊的校驗和與 RockDB 元資料。
- 確認資料一致性後，若發現資料損壞立即觸發複製。
故障處理細節
- 資料複製策略：資料節點故障時，SCM 會標記節點為 Stale，待確認後觸發資料複製。
- 性能考量：避免過度複製，需確保節點故障判定準確性。
- 監控機制：Recon 服務定期收集節點狀態，提供 Web UI 顯示。
- 錯誤處理：對偶發性 I/O 錯誤採用多次檢查機制，避免誤判磁碟故障。
故障恢復流程
- 網路分區：自動 Leader 選舉與狀態同步。
- 節點宕機：剩餘節點繼續運作，客戶端重試操作。
- 磁碟故障：Volume Scanner 與 Container Scanner 逐步標記故障，觸發資料複製。
- 集群恢復：更換故障硬體後重新加入集群，同步最新狀態。
數據一致性驗證與容錯策略
磁碟健康檢查機制
- 磁碟檢查流程：
- 寫入資料後讀取回傳並與記憶體資料比對。
- 確認無誤後刪除檔案。
- 若任一階段失敗，採用多階段檢查策略。
- 預設使用滑動窗口機制（最近3次檢查）。
- 若前兩次檢查成功，視為磁碟正常。
- 若兩次檢查失敗，主動標記磁碟異常並觸發資料複製。
容器掃描器（Container Scanner）
- 兩階段檢查機制：
- 元資料檢查（Metadata Check）：確認容器目錄存在性與可讀性，驗證元資料檔完整性。
- 資料檢查（Data Check）：遍歷容器內所有塊，比對塊長度與校驗和與 RockDB 元資料。
- 異常處理：若塊資料損壞，標記整個容器為不健康，選擇複製整個容器而非單塊修復。
按需掃描（On-Demand Scans）
- 觸發條件：客戶端讀取/寫入時發生異常，或背景掃描未及時處理的容器問題。
- 處理流程：
- 客戶端讀取時發現容器異常。
- 數據節點將磁碟與容器標記為待處理。
- SCM 協調複製：從其他健康節點複製資料，刪除異常節點的資料副本。
客戶端資料一致性驗證
- 寫入流程：產生資料校驗和，併發傳輸至數據節點，節點驗證校驗和匹配後持久化。
- 讀取流程：節點回傳資料與校驗和，客戶端驗證匹配後確認讀取成功，若不匹配則重試其他節點。
未來改進方向
- 校驗和優化：降低校驗和驗證開銷，考慮將校驗和儲存於塊檔案頭部以支援零拷貝傳輸。
- 軟故障處理：處理節點/磁碟運行緩慢問題，透過 SCM 與 Recon 伺服器監測節點狀態，動態調整資料傳輸路徑。
- 校驗和儲存方式：考慮將校驗和儲存於塊檔案頭部，降低 RockDB 與網路傳輸間的資料分離需求。
配置與監控
- 可調參數：掃描頻率與帶寬分配、錯誤檢測閾值（如滑動窗口長度）、資料複製策略。
- 監控指標：掃描消耗的帶寬與頻率、發現的錯誤數量與類型、磁碟/容器異常率。
磁碟故障處理細節
- RockDB 故障處理：節點無法處理 Raft 事務時自動關閉，新節點接替領導者角色，故障節點需手動排查（磁碟損壞/資料庫腐敗），其他節點儲存完整資料可支援資料恢復。
- 資料節點磁碟配置：每個磁碟對應一個 RockDB 儲存容器元資料，元資料於容器複製中同步，磁碟故障視為容器故障，需從其他複製體重構資料。
卷故障處理機制
當儲存卷故障時，系統會將資料從其他備份節點重新寫入集群現有空間，此過程會同時處理元數據，使其隨資料一起被遷移並注入至其他 Rock 實例，確保資料持續可用性與集群整體一致性。
數據節點維護模式
數據節點提供兩種維護模式：Decommission 與 Maintenance。
Decommission 模式：
- 用途：永久移除節點，並觸發所有資料重複寫入（re-pc）。
- 行為：節點將被標記為移除，資料會從其他備份節點遷移，節點不會再重新啟用，適用於長期移除節點的場景。
Maintenance 模式：
- 用途：暫時關閉節點，避免觸發資料重複寫入。
- 行為：節點會被標記為維護狀態，系統不會主動觸發資料重複，節點可預期重新啟動，適用於作業系統升級等短暫維護需求。
主節點 Decommission 機制
主節點（Metadata Nodes）僅支援 Decommission 模式，因其集群成員關係為靜態（固定三節點）。操作流程如下：
- 使用 Decommission CLI 工具停止指定節點。
- Raft 協議會更新集群狀態，標記該節點為停用。
- 系統會選舉新主節點，集群持續運作。
- 完成升級後，可透過 Recommission 操作重新加入集群。
- 重複此流程可於三主節點間輪替維護。
此設計確保主節點的穩定性與集群的高可用性。
總結
Apache Ozone 透過 Raft 協議、自動化故障恢復機制與資料一致性驗證，實現高可用性與資料持續可用性。其設計核心在於透過冗餘複製、智能監控與自動化處理流程，有效應對硬體故障與網路異常。建議在部署時合理配置冗餘策略，並透過監控指標及時發現潛在問題，以確保系統穩定運作。