眾所周知，ceph是近年來最為炙手可熱的開源分布式儲存系統。跟其他分布式儲存系統不一樣的是，ceph在稱之為rados的核心物件儲存架構之上，提供了塊儲存、檔案儲存以及物件儲存的介面，因此ceph可以稱之為統一儲存(unified storage)。而本文我們將討論的是ceph rados核心層面的資料恢復邏輯。
因此多副本機制是分布式儲存系統的核心機制之一，它帶來了資料高可靠性，也提高了資料可用性。然而事情是沒有十全十美的，多副本機制同時帶來了分布式系統的最大問題之一：資料一致性。不過ceph資料一致性並非本文的主題，以後有機會小焱再跟大家一起分享，本文僅會聊到資料恢復相關的資料一致性。
綜上，我們討論了為什麼ceph採用多副本機制，以及需要通過資料恢復及時補全故障帶來的副本缺失。我們也討論了保持資料一致性是故障恢復流程的難點之一。除此之外，ceph資料恢復(或者說分布式儲存資料恢復)還有其他幾個難點：
感知故障，並自動觸發資料恢復。做到這點，能減輕運維壓力，也使發現和處理故障更為及時。
盡量降低資料恢復過程中對集群資源的消耗。比如最為明顯的，如何減少網路頻寬的占用。ceph恢復資料的時候，是拷貝整個4m物件，還是只恢復有差異的資料，這兩種方式直接影響網路間傳輸的資料量。
資料恢復是否影響使用者的線上業務，ceph是如何控制和降低這個影響的？
帶著這幾個問題，下面小焱和大家一起來**ceph資料恢復的流程和關鍵細節。
ceph故障處理的流程
我們先來看一下ceph故障處理的主要流程，主要分為三大步驟：
感知集群狀態：首先ceph要能通過某種方法，及時感知集群故障，確定集群中節點的狀態，判定哪些節點離開了集群，為確定哪些資料的副本受到故障影響提供權威依據。
確定受故障影響的資料：ceph根據新的集群狀態計算和判定副本缺失的資料。
恢復受影響的資料。
對於這些步驟，我們逐個深入來**一下。
感知集群狀態
ceph集群分為mon集群和osd集群兩大部分。其中mon集群由奇數個monitor節點組成，這些monitor節點通過paxos演算法組成乙個決策者集群，共同作出關鍵集群事件的決策和廣播。「osd節點離開」和「osd節點加入」就是其中兩個關鍵的集群事件。
判定osd節點離線後，ceph將最新的osdmap通過訊息機制隨機分發給乙個osd，客戶端(對等osd)處理io請求的時候發現自身的osdmap版本過低，會向mon請求最新的osdmap。每個osd中pg的另外兩個副本可能在集群任意osd中，藉此經過一段時間的傳播，最終整個集群的osd都會接收到osdmap的更新。
確定受影響的資料
ceph中物件資料的維護由pg(placement group)負責，pg作為ceph中最小的資料管理單元，直接管理物件資料，每個osd都會管理一定數量的pg。客戶端對於物件資料的io請求，會根據物件id的hash值均衡分布在各個pg中。pg中維護了乙份pglog，用來記錄該pg的資料變化，這些記錄會被持久化記錄到後端儲存中。
pglog中記錄了每次操作的資料和pg的版本，每次資料變更操作都會使pg的版本自增，pglog中預設儲存3000條記錄，pg會定期觸發trim操作清理多餘的pglog。通常情況下，在同乙個pg的不同副本中的pglog應該是一致的，故障發生後，不同副本的pglog可能會處於不一致的狀態。
osd在收到osdmap更新訊息後，會掃瞄該osd下所有的pg，清理已經不存在的pg(已經被刪除等情況)，對pg進行初始化，如果該osd上的pg是primary pg的話，pg將進行peering操作。在peering的過程中，pg會根據pglog檢查多個副本的一致性，並嘗試計算pg的不同副本的資料缺失，最後得到乙份完整的物件缺失列表，用作後續進行recovery操作時的依據。對於無法根據pglog計算丟失資料的pg，需要通過backfill操作拷貝整個pg的資料來恢復。需要注意的是，在這peering過程完成前，pg的資料都是不可靠的，因此在peering過程中pg會暫停所有客戶端的io請求。
資料恢復
peering完成後，pg進入active狀態，並根據pg的副本狀態將自己標記為degraded/undersized狀態，在degraded狀態下，pglog儲存的日誌數量缺省會擴充套件到10000條記錄，提供更多的資料記錄便於副本節點上線後的資料恢復。進入active狀態後，pg可用並開始接受資料io的請求，並根據peering的資訊決定是否進行recovery和backfill操作。
primary pg將根據物件的缺失列表進行具體物件的資料拷貝，對於replica pg缺失的資料primary 會通過push操作推送缺失資料，對於primary pg缺失的資料會通過pull操作從副本獲取缺失資料。在恢復操作過程中，pg會傳輸完整4m大小的物件。對於無法依靠pglog進行recovery的，pg將進行backfill操作，進行資料的全量拷貝。待各個副本的資料完全同步後，pg被標記為clean狀態，副本資料保持一致，資料恢復完成。
控制恢復影響
通過ceph處理故障的流程，我們可以看到ceph如何應對集群故障常見的問題。首先是減少對資源的消耗：在斷電重啟這類故障中，ceph可以只恢復有變化的資料，從而減少資料恢復量；另一方面，mon不會主動向所有osd推送集群狀態，而是採用osd主動獲取最新osdmap的方式防止大規模集**生故障場景下產生突發流量。
另外，由於ceph的io流程必須要通過primary pg進行，一旦primary pg所在的osd宕機，io將無法正常進行。為了保證恢復過程中不會中斷正常的業務io，mon會分配pg temp臨時處理io請求，在資料恢復完成後再移除pg temp。
同時在整個恢復過程中，ceph也允許使用者通過配置檔案調整恢復執行緒數，同時進行的恢復運算元，恢復資料網路傳輸優先順序等相關引數來限制恢復的速度，從而降低對正常業務的影響。
總結以上小焱跟大家一起**了ceph資料恢復的主要技術流程，以及關鍵點。可以看出ceph在資料恢復方面，設計和細節做的都相當不錯。但是，目前ceph恢復的顆粒度仍然比較大，需要更多的io消耗；並且，被動的osdmap更新可能會導致pg不會及時恢復故障資料，在一段時間內資料可靠性會降低。
pglog是ceph進行資料恢復的重要依據，但是記錄的日誌數量有限，所以在發生故障後，盡快讓故障節點重新上線，盡量避免產生backfill操作，能極大的縮短恢復時間。
pg在peering階段會阻塞客戶端io，所以要保證pg能快速進行peering。
如果在故障過程中pglog丟失，導致無法完成peering，pg會進入incomplete狀態，這種情況下需要讓故障節點上線幫助完成資料修復。
雖然ceph的recovery操作能夠避免很多不必要的物件資料恢復，但是使用的還是完全物件拷貝，進一步的優化，可以考慮在pglog中記錄操作物件的具體資料位置、或是利用類似rsync的機制，只恢復物件副本間的差異資料。
ceph 集群故障恢復
集群規劃配置 master1 172.16.230.21 master2 172.16.230.22 master3 172.16.230.23 node1 172.16.230.26 node2 172.16.230.27 node3 172.16.23028 一 模擬monitor 宕機狀態 2...
ceph 在虛擬機器上搭建ceph集群
本實驗利用三颱虛擬機器搭建ceph集群。環境 vmware ubuntu18.04 3 主機名與主機ip ceph node1 192.168.50.101 ceph node2 192.168.50.102 ceph node3 192.168.50.103 最後在三颱機器上都各部署乙個monit...
ceph 分布式 儲存服務 恢復
systemctl isolate multi user.target適用於 ceph 15 octopus cephadm 自動部署 知曉 fsid 大部分檔案未丟失 完整步驟可以參考 官網，或者博主的 其他 ceph 系列部落格 cephadm 依賴 python36 安裝時，請開啟 工具 cu...