Ceph存儲系統Scrub機制分析

2018年11月12日，Linux基金會在德國柏林的「Ceph Day」上正式宣布成立「Ceph基金會」來支持Ceph開源項目。Ceph基金會接受Linux基金會的管理，它的成立將為Ceph社區的合作和成長提供一個中立的機構。

理事會由所有高級成員，普通成員代表，准成員代表和Ceph領導團隊代表組成，董事會的主要職責在於：

建立並批准用於支持Ceph項目的年度預算

建立特設委員會以滿足項目的當前需求

協調外展或營銷

定期開會討論基金會活動，Ceph項目的現狀以及整體項目戰略

在董事會面前對任何決定或事項進行投票

Ceph基金會董事會不對Ceph的技術治理負責，也沒有任何直接控制權。開發和工程活動通過傳統的開源流程進行管理，並由Ceph領導團隊監督。董事會主要成員如下：

創始頂級會員主要包括:Amihan，Canonical，中國移動，DigitalOcean，Intel，ProphetStor Data Services，OVH，Red Hat，SoftIron，SUSE，Western Digital，XSKY和ZTE。

普通會員和準會員包括ARM，平安科技，小桔科技(滴滴出行)， 中鐵信弘遠 ，Ambedded Technology，Croit GmbH，EasyStack，Intelligent Systems Services，Catalyst Cloud，QCT，歐洲粒子物理研究所，英國科學與技術設施委員會，莫納什大學，希臘GRNET機構，南非射電天文觀測台(SARAO)，加州大學聖克魯茲分校開放源碼軟體研究中心(CROSS)等。

Ceph作為最流行的分散式軟體定義存儲系統，目前服務於各個行業的客戶，包括金融機構(如Bloomberg，Fidelity)，雲服務提供商(如Rackspace，Linode)，學術和政府機構(如Massachusetts Open Cloud)，電信基礎設施提供商(如Deutsche Telekom)，汽車製造商(寶馬)，軟體解決方案提供商(如SAP，Salesforce)等等。

Ceph基金會的成立將對Ceph技術發展和社區壯大起著積極作用，目前有很多企業存儲系統都是基於開源Ceph優化而來。只是國內，市場上就已經湧現大量Ceph系產品，如H3C的ONEstor塊和對象、UniStor文件系統，中興CloveStorage，衫岩SandStone，XYSK(星辰天合) X-CBS、X-EBS和X-EOS，浪潮AS13000系列等。

關於Ceph架構，數據分布和特性對比(參考「詳解Ceph數據是如何布局」)，筆者在前期的文章中已經做了詳細分享。今天就跟大家一起討論下Ceph的可靠性恢復原理:Scrub機制。

Scrub是Ceph集群進行的副本間的數據掃描操作，以檢測副本間的數據一致性，包括Scrub和Deep-Scrub，其中Scrub只是對元數據信息進行掃描，相對比較快，而Deep-Scrub不僅對元數據進行掃描，還會對存儲的數據進行掃描，相對比較慢。Ceph集群會定期進行Scrub操作。

Scrub默認策略是每天到每周(如果集群負荷大周期就是一周，如果集群負荷小周期就是一天)進行一次，時間區域默認為全天(0時-24時)，Deep-Scrub默認策略是每周一次。

Ceph進行數據讀寫時並不會增加校驗數據來保證數據的正確性(類似ECC、CheckSum等)，只能通過內部的Scrub機制來校驗數據。

Scrub流程是以PG為單位定期觸發的，由該 PG 的Master 角色所在 OSD 啟動；每次Scrub會掃描一個PG內的部分對象，校驗期間對象的數據是不允許修改。

校驗信息包括每個對象的元信息如大小、擴展屬性的所有鍵和歷史版本信息等，在Ceph 中被稱為 ScrubMap。發起者會比較多個ScrubMap並發現不一致的對象，不一致對象會被收集最後發送給 Monitor，由用戶手工發起修復。

Ceph允許通過Deep Scrub模式來全量比較對象信息來期望發現Ceph 本身或者文件系統問題，這通常會帶來較大的 IO 負擔，較少在生產環境使用。

當然，Ceph Scrub機制存在的問題。在發現不一致對象後，缺少策略來自動矯正錯誤，比如如果多數副本達成一致，那麼少數副本對象會被同化。Scrub 機制並不能及時解決存儲系統端到端正確的問題，很有可能上層應用早已經讀到錯誤數據，下面一起來看看Scrub的工作流程：

OSD 會以 PG 為粒度觸發 Scrub流程，觸發的頻率可以通過選項指定，而一個PG的Scrub啟動都是由該 PG 的 Master 角色所在OSD啟動。

一個PG在普通的環境下會包含幾千個到數十萬個不等的對象，因為Scrub流程需要提取對象的校驗信息然後跟其他副本的校驗信息對比，這期間被校驗對象的數據是不能被修改的。因此一個PG的Scrub流程每次會啟動小部分的對象校驗，Ceph 會以每個對象名的哈希值的部分作為提取因子，每次啟動對象校驗會找到符合本次哈希值的對象，然後進行比較。這也是 Ceph稱其為Chunky Scrub的原因。

在找到待校驗對象集後，發起者需要發出請求來鎖定其他副本的這部分對象集。因為每個對象的Master和Replicate節點在實際寫入到底層存儲引擎的時間會出現一定的差異。這時候，待校驗對象集的發起者會附帶一個版本發送給其他副本，直到這些副本節點與主節點同步到相同版本。

在確定待校驗對象集在不同節點都處於相同版本後，發起者會要求所有節點都開始計算這個對象集的校驗信息並反饋給發起者。

該校驗信息包括每個對象的元信息如大小、擴展屬性的所有鍵和歷史版本信息等等，在Ceph 中被稱為 ScrubMap。

發起者會比較多個ScrubMap並發現不一致的對象，不一致對象會被收集最後發送給 Monitor，最後用戶可以通過Monitor了解Scrub的結果信息。

另外，當用戶在發現出現不一致的對象時，可以通過「ceph pgrepair [pg_id]」的方式來啟動修復進程，目前的修復僅僅會將主節點的對象全量複製到副本節點，因此目前要求用戶手工確認主節點的對象是「正確副本」。此外，Ceph允許Deep Scrub模式來全量比較對象信息來期望發現 Ceph 本身或者文件系統問題，這通常會帶來較大的IO負擔，因此在實際生產環境中很難達到預期效果。

通過上述Scrub流程，大家也會發現目前的 Scrub機制還存在以下2個問題：

在發現不一致對象後，缺少策略來自動矯正錯誤，比如如果多數副本達成一致，那麼少數副本對象會被同化。

Scrub 機制並不能及時解決存儲系統端到端正確的問題，很有可能上層應用早已經讀到錯誤數據。

對於第一個問題，目前Ceph已經有Blueprint來加強Scrub的修復能力，用戶啟動Repair時會啟動多數副本一致的策略來替代目前的主副本同步策略。

對於第二個問題，傳統端到端解決方案會更多採用固定數據塊附加校驗數據的「端到端校驗」方案，但是 Ceph 因為並不是存儲設備空間實際的管理和分配者，它依賴於文件系統來實現存儲空間的管理，如果採用對象校驗的方式會嚴重損耗性能。

因此在從文件系統到設備的校驗需要依賴於文件系統，而Ceph包括客戶端和伺服器端的對象正確性校驗只能更多的依賴於ReadVerify機制，在涉及數據遷移時需要同步的比較不同副本對象的信息來保證正確性。目前的非同步方式會允許期間發生錯誤數據返回的可能性。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！