[[440706]]

本文轉載自微信公眾號「新鈦云服」，作者祝祥。轉載本文請聯系新鈦云服公眾號。

Ceph是一個開源的分布式對象，塊和文件存儲。該項目誕生于2003年，是塞奇·韋伊的博士論文的結果，然后在2006年在LGPL 2.1許可證發布。Ceph已經與Linux內核KVM集成，并且默認包含在許多GNU / Linux發行版中。

當前的工作負載和基礎設施需要不同的數據訪問方法(對象，塊，文件)，Ceph支持所有這些方法。它旨在具有可擴展性，并且沒有單點故障。它是一款開源軟件，可以在生產環境，通用硬件上運行。

RADOS (可靠的自動分布式對象存儲)是Ceph的核心組件。RADOS對象和當今流行的對象之間存在著重要的區別，例如Amazon S3，OpenStack Swift或Ceph的RADOS對象網關提供的對象。從2005年到2010年，對象存儲設備(OSD)成為一個流行的概念。這些OSD提供了強大的一致性，提供不同的接口，并且每個對象通常駐留在單個設備上。

Ceph分為三大塊，分別是對象存儲、塊設備存儲和文件系統服務。在實際運營中，如何發現和解決關鍵的存儲問題?尤其是隨著規模的擴大與業務的幾何級數的擴張，存在運維中不可預測的問題，如何提前預判和防治?

在我們的大量的客戶案例中，我們遇到了，同時也幫客戶規避了大量的風險。如果您要自建Ceph集群，以下是一些需要考慮的錯誤配置場景。

錯誤 #1 – 選擇不佳的日志或緩存硬盤

在構建 Ceph 集群時，尤其是帶有 HDD 的集群時，您需要使用一個SSD作為日志或者緩存，它通常用來存儲一些關鍵的數據(例如預寫日志和元數據又或者是bluestore中的wal與db)。這也是為大多數存儲場景提高性能的最經濟有效的方法。

通常，大部分人會使用商業品牌服務器(用于啟動引導盤)的 M.2 SATA 接口作為日志驅動盤。問題是大多數 M.2 驅動盤僅推薦用于安裝操作系統，從而用于系統啟動，并且只有 1DWD(每天寫入量)范圍內的耐用性。尤其是對于filestore而言， Ceph 使用預寫日志和元數據的方式，這些可能很快就會耗盡。

如果您要堅持使用 M.2 端口，有些設備廠商可以定制化調整配置，從而增加ssd的讀寫耐用性。

錯誤 #2 – OSD使用 RAID

在某些情況下，這比較難解決的，尤其是對于使用英特爾至強架構的非密集型的 HDD 服務器。然而，RAID 功能在 Ceph 集群的上下文中沒有過多的作用。如果您必須要使用 RAID的話，請將其配置為 RAID-0。當然，在理想的情況下，您也可以找到一個以直通模式運行的 RAID 控制器(JBOD，磁盤直通)。

如果您無法擺脫使用 RAID 控制器，您還應該注意以下兩點：

• 禁用寫緩存(首選)。
• 有一個電池支持的緩存。

不然，您肯定會遇到問題。我們在生產環境中已經遇到過很多次了。

另外，附帶說明一下，這些服務器還往往帶有很長的電纜，這代表了額外的物理故障點。大部分情況下，故障都會很容易處理，但在某些時候，線纜松動的情況下，它會造成維護方面的一些麻煩。

錯誤 #3 – 將 MON 守護進程與 OSD 放在同一臺主機上

在Ceph正常運行的 99% 場景中，監控服務的負載壓力很小。但是，當您的集群處于繁忙或者故障時，例如硬件出現故障以及數據重新均衡時，它的工作將變的異常繁忙以及重要。此時，您的監視器MON會清理您的集群數據，以確保您返回的內容與您存儲的內容一致。畢竟，Ceph 的最核心的宗旨就是“我們不會丟失數據”。在故障期間，監視器會執行校驗和，這需要大量的計算能力。它還可能執行將一個OSD遷移數據到另外一個OSD的任務，此時您的 OSD 也會更加繁忙地工作。最后，它負責一些選舉的任務，這就是為什么通常有奇數個監視器的原因。這里記錄(https://docs.ceph.com/en/latest/rados/configuration/mon-config-ref/)是“Ceph 監視器經常將其數據從內存刷新到磁盤，干擾 Ceph OSD 守護進程的工作負載”的問題。

因此，當您構建一個最小規模的集群(通常為 3 臺主機)并且其中一個出現故障時，整個集群也會崩潰，后面我們會簡單講解一下。

最好的解決方案是配置單獨的監視器和存儲服務守護程序。在實際生產中，大部分情況下，我們都沒有從MON與OSD混合放在同一臺主機中獲得多少好處。如果您擔心硬件資源的浪費，一種潛在的替代方法是將它們放在虛擬機中。這也是一個更好的選擇，即獨立了服務，也節省了資源。

錯誤 #4 – 錯誤地設置 min_size 和副本大小

將 min_size 設置為 1 并將副本大小設置為 2 是大部分人都喜歡的配置 。它看起來類似于服務器的 RAID1，因為，這樣可以讓系統在副本降級的狀態下運行，并且在數據副本恢復的過程中依然保留比較好的效率。

但請記住——Ceph 不希望您丟失數據。這意味著當你讀時，它會檢查以確保你寫的數據仍然是你寫的。同時，這些結果都需要在多個副本之間進行同步與比較。當沒有副本可供比較時，Ceph 認為您不能再信任何 read ，它即不會讓你寫也不會再讓你讀。整個系統都被鎖定了。因此，如果此時隨便一塊磁盤脫機，即使是暫時的，集群也將停止訪問與使用故障 OSD 關聯的歸置組。同樣，使用 min_size 1，很容易出現重大問題，它沒有法子保證Ceph數據的一致性。

如果您需要增加可用存儲容量，另一種選擇是使用糾刪碼。您可能會犧牲一些性能，但可以獲得更高的存儲效率，而不會冒大量數據無法訪問的風險。

錯誤 #5 – 高密的服務器更好

更密集的服務器、更密集的驅動器、更密集的 CPU – 這樣您就可以降低服務器、PCB、CPU 和網絡的成本，對嗎?

事實證明，當您在集群中使用基于復制或糾刪碼的數據保護機制時，最好將數據帶寬分布范圍擴大。在 CPU 中——更密集意味著更多的時鐘周期浪費和更大的功率預算，這會對您的機柜和功率容量產生額外影響。對于 25KW 功率的機架來說可能沒什么大不了的，但是當您的機架功率低于 8KW 時絕對是一個問題，這也是大部分機柜的標準水平。

但最大的問題是故障范圍。假設您使用了3臺高密的服務器來構建了一個最小可行集群。每臺有最高配置的60快盤，每個盤的容量為 18TB。如果從單個osd盤中恢復丟失的數據需要 1 天，那么從丟失的一臺服務器中恢復數據將需要 2 個月。哪怕是遷移物理磁盤也不起作用，因為 OSD 必須在新服務器中重新創建。在那個時候，如果您丟失另一個盤或服務器，這時候可能就會擴大故障，甚至丟失數據。

總結

擁有強大而活躍的 Ceph 用戶社區是保持Ceph項目持續發展的關鍵。但是這并不意味著大家可以放心的使用Ceph。反而，我們更應該關注Ceph的使用場景以及相關的運維方案。架構以及安裝一個安全可靠的Ceph集群也變的至關重要。

Ceph確實有無限擴容的能力，但需要良好的初始規劃，否則擴容過程也會出現一些問題。

在某些場景下，Ceph有些浪費硬件，成本核算時要考慮多一些。因此，如何合理去配置副本數，OSD數至關重要。不合理的規劃除了資源浪費外，也可能導致性能問題，尤其是在副本恢復或者數據均衡的時候。 

Ceph的優化方式很多，但一定要選擇有效且合理的優化方式。