一：客户信息

內蒙古某警務雲數據中心

二：案例背景

什麼是分佈式文件系統

分佈式文件系統（DistributedFile System，DFS）是一種能夠在多台計算機之間共享文件存儲資源的系統。它將文件存儲在多個節點上，這些節點通常是位於不同地理位置的服務器或計算機集羣。分佈式文件系統的核心目標是提高文件存儲的可靠性、可擴展性和性能，同時為用户提供透明的文件訪問體驗，彷彿文件是存儲在單一的本地文件系統中一樣。

Ceph的三種存儲結構

對象存儲：Ceph 提供 S3 和 Swift 兼容的RESTful API，用於存儲和檢索對象數據。

塊存儲：Ceph 提供塊設備接口，支持虛擬機的塊存儲，如 KVM、OpenStack 等虛擬化平台。

文件系統：Ceph 提供一個 POSIX 兼容的文件系統（CephFS），支持傳統的文件存儲需求。

三：案例描述

環境：客户基於3台存儲節點構成的ceph分佈式存儲集羣，搭配KVM虛擬機使用，系統內存有若干台虛擬機，每台節點64塊硬盤，由2塊480G系統盤+4塊1TB的SSD閃存盤+64塊8TB的物理盤構成。

故障原因：幾個月前誤刪除一台虛擬機，已聯繫其他數據恢復公司，刪除後的**時間進行了硬盤鏡像，但由於該ceph版本較新，沒有任何軟件能夠支持恢復處理，故一直無法恢復虛擬機內存儲的歸檔文件。

四：解決方案

**1.**應急響應

客户聯繫我們以後，我方技術團隊面對這一緊急情況，立即讓客户的運維團隊啓動應急預案，採取了以下措施：

1.緊急停機：首先，為避免進一步的數據損壞，立即停止了所有可能影響到Ceph集羣的操作，包括數據寫入和讀取。

2.環境評估：對當前的Ceph分佈式集羣狀態進行全面評估，確認受影響的範圍及程度，包括哪些配置文件丟失，是否已造成數據損壞等。

**2.**恢復挑戰

在服務器沒有備份容災的情況下進行數據恢復是**挑戰性的，主要挑戰包括：

無備份可用：傳統的恢復方式依賴於已有的備份，而在沒有備份的情況下，需要通過日誌文件、元數據和其他剩餘數據來重建丟失的配置。

系統複雜性：KVM平台與Ceph分佈式存儲的配置複雜，恢復過程中稍有不慎就可能造成數據的**性丟失。

時間緊迫：在實際業務環境中，服務的中斷會帶來巨大的損失，因此需要快速而準確地進行恢復。

**3.**案例評估

首先，我們需要了解Ceph的分佈式存儲機制。跟其他分佈式存儲系統不一樣的是，Ceph在稱之為RADOS的核心對象存儲架構之上，提供了塊存儲、文件存儲以及對象存儲的接口，因此Ceph可以稱之為統一存儲（Unified Storage）。Ceph主要由Monitors、Managers、OSDs三種類型的組件組成。其中，Monitors負責維護集羣狀態信息，Managers負責管理集羣資源，OSDs負責存儲數據。

Ceph的底層是RADOS(分佈式對象存儲系統)，RADOS由兩部分組成：OSD和MON。MON負責監控整個集羣，維護集羣的健康狀態，維護展示集羣狀態的各種圖表，如OSDMap、MonitorMap、PGMap和CRUSHMap。OSD負責存儲數據、複製數據、平衡數據、恢復數據，與其它OSD間進行心跳檢查等。通常情況下一塊硬盤對應一個OSD。

Ceph分佈式數據的存儲過程，無論使用哪種存儲方式（對象、塊、文件），存儲的數據都會被切分成對象（Objects)。

存儲池：不同用户因為不同的目的把對象存儲在不同的存儲池裏，這些對象分佈於OSD上。對象保存在不同的存儲池（Pool）中，是對象存儲的邏輯組，對應不同的用户。存儲池管理着歸置組數量、副本數量、和存儲池規則集。

歸置組：歸置組（PGPlacementGroup）是對象池的片段，Ceph根據對象的Oid和一些其他信息做計算操作，映射到歸置組，無數的對象被劃分到不同的歸置組。PG是一個邏輯概念，它在數據尋址時類似於數據庫中的索引。每個對象都會固定映射進一個PG中，所以當我們要尋找一個對象時，只需要先找到對象所屬的PG，然後遍歷這個PG就可以了，無需遍歷所有對象。而且在數據遷移時，也是以PG作為基本單位進行遷移。

OSD：最後PG會根據管理員設置的副本數量進行復制，然後通過crush算法存儲到不同的OSD節點上，最終把PG中的所有對象存儲到OSD節點上。

BlueStore：在新版本中，Ceph默認以Bluestore存儲引擎，作為RADOS中OSD的ObjectStore存儲底層實現BlueStore整體架構。

存儲空間：BlueStore將整個存儲空間分為3個部分：WAL，DB，SLOW。慢速(Slow)空間：主要用於存儲對象數據，由BlueStore管理。高速(DB)空間：存儲blufs和rocksdb產生的數據，由BlueFS直接管理，如果不存在或者DB設備空間不足，則選擇Slow類型設備空間。超高速(WAL)空間：主要存儲RocksDB的WAL（即.log）文件，由BlueFS直接管理，如果不存在或者WAL設備空間不足，則逐級降級選擇DB、SLOW分區。

Rocksdb：BlueStore使用Rocksdb作為自己元數據存儲的底層實現，將各種元數據以kv型記錄的方式存在數據庫中。寫入機制：任何元數據的寫入都會先寫到WAL，然後再寫入MemoryTable(Memtable)。當一個Memtable寫滿了之後，就會變成immutable的Memtable，RocksDB在後台會通過一個flush線程將這個Memtableflush到磁盤，生成一個SortedStringTable(SST)文件。

BlueFS：BlueFS與通用文件系統不同，是Bluestore專為Rocksdb所設計的精簡文件系統。BlueFS的文件和目錄的元數據以日誌事務的形式保存在日誌文件中，在上電過程中，replay日誌文件中的事務，就可以加載所有的元數據到內存中。

在本案例中，由於配置文件誤刪除，導致部分OSD無法正常工作，進而影響了存儲池的訪問。我們還利用Ceph的日誌文件進行了深入分析，試圖從日誌中找到任何可能的線索，比如配置文件的修改記錄或異常操作。雖然日誌文件不能直接恢復丟失的配置文件，但它提供了寶貴的參考信息，幫助確認恢復操作的正確性和完整性。

**4.**恢復方案

首先給大家梳理下Ceph分佈式故障後，常規處理的主要流程，分為三大步驟：

1. 感知集羣狀態

Ceph集羣分為MON集羣和OSD集羣兩大部分。其中MON集羣由奇數個Monitor節點組成，這些Monitor節點通過Paxos算法組成一個決策者集羣，共同作出關鍵集羣事件的決策和廣播。“OSD節點離開”和“OSD節點加入”就是其中兩個關鍵的集羣事件。

MON集羣管理着整個Ceph集羣的成員狀態，將OSD節點的狀態信息存放在OSDMap中，OSD節點定期向MON和對等OSD（Peer OSD）發送心跳包，聲明自己處於在線狀態。MON接收來自OSD的心跳消息確認OSD在線；同時，MON也接收來自OSD對於Peer OSD的故障檢測。MON根據心跳間隔等信息判定OSD是否在線，同時更新OSDMap並向各個節點通告最新集羣狀態。比如某台服務器宕機，其上OSD節點和MON集羣的心跳超時或是這些OSD的對等OSD發送的失敗通告超過閾值後，這些OSD將被MON集羣判定為離線。

判定OSD節點離線後，Ceph將最新的OSDMap通過消息機制隨機分發給一個OSD，客户端（對等OSD）處理IO請求的時候發現自身的OSDMap版本過低，會向MON請求最新的OSDMap。每個OSD中PG的另外兩個副本可能在集羣任意OSD中，藉此經過一段時間的傳播，最終整個集羣的OSD都會接收到OSDMap的更新。

2. 確定受故障影響的數據

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請求。

3. 恢復受影響的數據

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數據恢復方案：

1.數據分析：

1.1：BlueStore架構

用winhex隨機查看一塊1TB的閃存盤和一塊12TB的物理盤，查看關鍵扇區：得知該ceph分佈式存儲系統是基於bluestore架構構成的，採用的是ceph的塊存儲。

BlueStore是 Ceph 的一種存儲引擎，設計用於直接管理原始塊設備（如 HDD 或 SSD）而不是通過文件系統來存儲數據。與傳統的基於文件系統的存儲引擎（如 Filestore）相比，BlueStore 提供了更高的性能和更高效的存儲利用率。

由於我司對ceph數據存儲的16進制結構十分了解，（可以使用winhex直接手動提取數據文件），並有多起類似的數據恢復的成功案例，故直接開始提取數據。

1.2分佈式存儲中元數據概述

提取之前，首先要科普1下元數據的作用，方便大家理解：

在分佈式存儲系統中，元數據是系統運轉的關鍵，它不僅支撐了數據的存儲、訪問、複製和恢復，還在負載均衡、安全管理、去重等方面發揮了重要作用。由於分佈式存儲系統的複雜性和規模性，元數據的管理和優化對系統的性能、可靠性和可擴展性有着直接影響。

大概歸類為：

數據定位與訪問：

在分佈式存儲系統中，數據通常被拆分成多個塊，並分佈在不同的存儲節點上。元數據用於記錄每個數據塊的位置、存儲節點的地址、塊的大小、複製數量等信息。

如：當客户端請求訪問某一數據時，系統首先查找相關的元數據，以確定數據塊所在的節點，然後從這些節點讀取數據。比如我司曾處理過的HDFS分佈式存儲中，NameNode 負責管理元數據，記錄文件的分塊信息以及這些塊所在的 DataNode。當用户請求文件時，NameNode 提供數據塊的位置，客户端再從對應的 DataNode 中獲取數據。

數據複製與一致性：

分佈式存儲系統為了確保數據的可靠性和可用性，通常會將數據複製到多個節點。元數據在這種場景中記錄了每個數據塊的副本數量、位置以及版本信息。

如：當一個數據文件被更新時，元數據會記錄新的ID號，並觸發其他數據文件的更新。如在本作的Ceph分佈式存儲系統中，Ceph Monitor 維護了集羣的元數據，包括存儲池、數據副本位置和狀態等。

故障檢測與恢復：

分佈式存儲系統需要處理節點故障、數據損壞等問題。元數據記錄了哪些節點存儲了哪些數據塊，因此，當某個節點發生故障時，系統可以利用元數據來重新分配數據塊，確保數據的完整性。

如：當某個節點不可用時，系統可以通過元數據識別丟失的數據塊，並從其他副本中恢復這些數據。例如，在 Amazon S3雲存儲中，元數據會跟蹤每個對象的存儲位置和狀態，如果某個存儲節點失效，系統可以自動從其他節點恢復數據。

負載均衡與擴展：

為了保證系統的性能，需要對存儲節點的負載進行均衡，並且系統可能需要隨着數據量的增長進行擴展。元數據可以提供關於當前數據分佈、節點負載的統計信息，以幫助系統做出負載均衡和擴展決策。

如：元數據幫助系統決定新數據應該存放在哪些節點上，以及何時將某些數據遷移到其他節點以平衡負載。比如在老版本的ceph分佈式存儲系統中，當時沒有bluestore架構，元數據可以讓系統決定將新數據寫入哪個XFS分區中，以避免某些節點過載。

元數據總結：元數據=數據標籤，分佈式系統中的元數據大致等於（不限於）windows平台中NTFS文件系統中的MFT、linux平台中EXT4、XFS等多種文件系統中的index，只不過在分佈式存儲系統中我們稱為"元數據"。

1.3提取元數據

提取元數據中我司內部定義的能夠支持本次數據恢復提取的三種類型（僅代表我司內部擬定的統稱，與外界同名的類型存在一定偏差），並創建數據庫進行存儲：

meta_chunk：元數據自身空間分佈信息

meta_data：元數據本身

meta_id：元數據內部通信

1.3.1：獲取12個SSD閃存盤的“OSD”位圖：在當前ceph分佈式存儲系統中：除系統盤外，每個成員盤為1個OSD塊。只不過這個塊過於巨大（大塊），即每個物理盤的數據位圖，然後從12塊閃存盤中分離出元數據存儲在哪些小塊內的meta_chunk信息。

在塊存儲的Ceph中，對於底層來説，OSD的含義和CephFS中差異較大，本案例為塊存儲案例，故加“”。

1.3.2：獲取meta_data

根據獲取的meta_chunk信息，提取出現有的完整的元數據，再根據現有元數據特徵（多特徵），獲取所有能夠提取的元數據，我們依據meta_data將元數據按記錄的數據類型再次歸類（本次案例只列出3種對本次恢復有關的類型：文件名、目錄、osd空間分配）。

1.3.3.元數據整理

依據meta_data內的meta_id的信息記錄，分離現有數據和丟失數據的meta_data（包含當前持久化之前的曾經存在過的瞬時狀態的數據）。

1.3.4.計算數據地址

將元數據重組，解析meta_data內鍵值記錄的字節流，獲得數據的OSD小塊ID，但由於元數據數量過於龐大，只能通過自建一個“元數據數據庫”來存儲和管理這些信息。

2.數據恢復提取

2.1：將meta_data與osd小塊進行關聯，獲取meta_data內記錄的存儲結構，本次案例獲取為4+2結構，即一份數據切割為4份存儲，再配兩份校驗，即4+2，有些廠商對客户也稱為“三副本”

這裏小編也覺得奇怪，按理説三副本是指的三份文件副本1+1+1的方式，但是在實際遇到的有些客户説廠家給他們説的三副本，但其實小編看到是4+2。

2.2：從KVM的日誌中獲取虛擬機的**識別碼，與meta_data關聯，鎖定所需恢復的虛擬機名。

2.3：通過自建的“元數據數據庫”引導提取對應的每個osd小塊，然後按照4+2組合成虛擬磁盤文件的碎片，再通過大量碎片的組合，最終形成完整的虛擬磁盤文件。

2.4：使用winhex或常見的數據恢復工具對虛擬磁盤文件進行展開，導出裏面的數據或生成新的虛擬磁盤文件交付給客户。

五：案例總結

經過緊張而有序的工作，我方技術團隊終於成功恢復了Ceph分佈式存儲服務器集羣的配置文件，並確保了整個系統環境的穩定運行。此次事件雖然驚心動魄，但也帶來了寶貴的經驗教訓：

1. 加強備份管理：務必建立健全的備份機制，定期備份Ceph集羣關鍵配置文件和數據，確保備份的完整性和可用性，以防不測。

2. 提高安全意識：合理設置管理員權限，加強運維人員的安全教育和培訓，提升自身的運維能力和數據保護水平，降低人為錯誤的發生概率。

3. 完善應急預案：制定規範的操作流程，不斷完善和優化應急預案，確保在緊急情況下能夠迅速、有效地響應。

4. 加強監控與日誌分析：開啓日誌審計功能，記錄管理員的所有操作，便於追溯和排查問題，充分利用監控系統和日誌分析工具，及時發現並處理潛在問題。

Ceph是當前非常流行的開源分佈式存儲系統，具有高擴展性、高性能、高可靠性等優點，同時提供塊存儲服務(rbd)、對象存儲服務(rgw)以及文件系統存儲服務(cephfs)。目前也是OpenStack的主流後端存儲，和OpenStack親如兄弟，為OpenStack提供統一共享存儲服務。使用Ceph作為OpenStack後端存儲，具有如下優點：

所有的計算節點共享存儲，遷移時不需要拷貝根磁盤，即使計算節點掛了，也能立即在另一個計算節點啓動虛擬機（evacuate）。

利用COW（Copy On Write)特性，創建虛擬機時，只需要基於鏡像clone即可，不需要下載整個鏡像，而clone操作基本是0開銷，從而實現了秒級創建虛擬機。

Ceph RBD支持thin provisioning，即按需分配空間，有點類似Linux文件系統的sparse稀疏文件。創建一個20GB的虛擬硬盤時，最開始並不佔用物理存儲空間，只有當寫入數據時，才按需分配存儲空間。

OpenStack和KVM有什麼區別？OpenStack和KVM雖然都屬於雲計算技術領域的範疇，但兩者有着不同的概念。簡單來説，OpenStack是一個開源的雲計算管理平台項目，由多個主要的組件構成，可以用來部署和管理雲計算平台中的各種資源；而KVM（Kernel-based Virtual Machine）是一種基於Linux內核實現的開源虛擬化技術，可以將Linux內核轉化為一個超級虛擬機監控器。

OpenStack和KVM的關係：OpenStack是雲管理平台，其本身並不提供虛擬化功能，真正的虛擬化能力是由底層的Hypervisor（如KVM、Qemu、Xen等）提供。而OpenStack則可以管理KVM虛擬化環境。KVM可幫助您將Linux轉變為虛擬機監控程序，使主機計算機能夠運行多個隔離的虛擬環境，即虛擬客户機或虛擬機（VM）。它是目前比較熱門的虛擬化方案，例如許多國外主機都是基於KVM虛擬化的。KVM這樣的Hypervisor軟件，實際上是提供了一種虛擬化能力，模擬CPU的運行，更為底層。但是它的用户交互並不良好，不方便使用。於是，為了更好地管理虛擬機，就需要OpenStack這樣的雲管理平台。

當數據發生丟失時，金海境科技研發團隊深入研究各種服務器和系統設計思路，認真對比故障類別，攻克疑難恢復案例，總結成功恢復經驗，擁有成功修復服務器數據庫，虛擬化平台，分佈式存儲等數據中心相關的上萬個疑難案例，並掌握了網絡加密恢復核心技術，所有恢復的數據不丟記錄，結構完整，直接使用，不報錯。