前言

Ceph是一個可靠地、自動重均衡、自動恢復的分布式存儲系統，根據場景劃分可以將Ceph分為三大塊，分別是對象存儲、塊設備存儲和文件系統服務。

在虛擬化領域里，比較常用到的是Ceph的塊設備存儲，比如在OpenStack項目里，Ceph的塊設備存儲可以對接OpenStack的cinder后端存儲、Glance的鏡像存儲和虛擬機的數據存儲，比較直觀的是Ceph集群可以提供一個raw格式的塊存儲來作為虛擬機實例的硬盤。

Ceph相比其它存儲的優勢點在于它不單單是存儲，同時還充分利用了存儲節點上的計算能力，在存儲每一個數據時，都會通過計算得出該數據存儲的位置，盡量將數據分布均衡，同時由于Ceph的良好設計，采用了CRUSH算法、HASH環等方法，使得它不存在傳統的單點故障的問題，且隨著規模的擴大性能并不會受到影響。

損壞 Ceph 集群的 10 種方式

以下是破壞 Ceph 集群的 10 種原始方法的摘要。  

1、錯誤的 CRUSH 故障域：  

如果您不正確地配置 CRUSH，這可能會導致問題。因此一定需要在您的集群上進行測試，以驗證是否按預期處理了故障。  

2、停用主機：

這種情況的一個示例是運行 size = 2、min_size = 1并且需要更換一些硬件的集群。歸置組只剩下一個磁盤作為副本，如果丟失該磁盤，數據就會丟失。Ceph 集群將不得不被廢棄并從頭開始重建。  

3、刪除 MON 數據目錄中的“日志”文件：

始終確保監視器有足夠的磁盤空間，并且永遠不要從其數據目錄中手動刪除文件。  

4、刪除錯誤的池：  

在移除池之前仔細檢查。更好的是，在移除池之前請其他人查看它。  

5 、長時間設置noout標志：  

始終確保集群的運行狀態為 HEALTH_OK ，并查看集群是否處于 HEALTH_WARN 狀態較長時間。  

6、使用 nobarrier 選項安裝 XFS：

由于新版本之后支持使用 Bluestore，這個問題 100% 解決了。因為 Bluestore 不再使用 XFS。  

7、在沒有 BBU 的 HBA 上啟用寫回：

在沒有備用電池單元的情況下，切勿在 HBA 中打開寫回緩存。  

8、創建過多的歸置組：  

創建歸置組時要小心。當集群需要重新re-peer所有歸置組時，它可能會損害集群。  

9、使用 2 副本：  

假如一臺主機被下電進行維護。現在，一部分數據依賴于一個磁盤。如果此磁盤發生故障，則所有數據都將丟失。  

10、忽視監視器：  

建議使用監視器專用硬件。  

損壞 Ceph 集群的另外 6 種方法

以下是另外 6種方式的摘要：

11、不了解使用的自動化工具：  

簡而言之，了解您的自動化工具在做什么，為什么要這樣做，并且絕對了解它不應該做什么。您還應該意識到，您的自動化工具應該可以幫助您執行您已經知道的內容。如果你想使用 Ceph，你應該了解 Ceph。例如，如果你想使用 Ceph 和 ceph-ansible，你應該了解 Ceph 和 Ansible。

12、運行 min_size=1：  

我們建議您至少運行三個副本。但是，如果你不能，永遠不要將你的 min_size 降低到低于 1，或者最好不要將你的冗余對象降低到“0”。確保您始終編寫至少 1 個冗余對象。這也適用于糾刪碼。

13、未完全完成更新：  

Ceph 的文檔有時缺少部分細節。在某些情況下，根據 Ceph 的通用文檔，完成升級工作。但是，如果您查看詳細的 Ceph 版本的發行說明，很多步驟都被跳過甚至沒有觸及。因此，請仔細檢查更新是否已完成。

14、過早完成更新：  

請確保您不要過早完成升級，并且您確實遵循所有步驟。

15、在負載均衡器后面運行多個有相同 id 的 rbd：

我們有一個客戶有 9 個 rbd，但只配置了 3 個后端rbd。對于每個 rbd，他們有 3 個進程在運行。他們都在跳過哪個是活躍的。在負載均衡器后面，這導致數百萬個未完成的部分上傳。客戶的整個集群都滿了。接下來，他們添加了新硬件，并且后續仍在添加新硬件。幸運的是，我們發現這是問題所在。為了解決這個問題，我們重命名了 6 個 rbd，清點了所有對象并確保它們都被清理干凈。

16、盲目相信你的 PG 自動縮放：  

有時候，一直到您寫入數據，您才真正發現 PG 的配置不正確。您在寫入大量數據的同時也拆分了所有歸置組，導致性能非常差，最終嚴重影響客戶應用。除非您額外采取相關措施，否則沒有真正的方法可以解決它。