硬體規格建議

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的優化方式很多，但一定要選擇有效且合理的優化方式。

 

 

 

 

 

OSD

1. OSD 磁碟採用 JBOD 組態或個別的 RAID-0 組態。
2. 作業系統專屬的磁碟/SSD，最好採用 RAID 1 組態。
3. OSD 主機將要代管用於快取分層的一部分快取池，請至少額外配置 4 GB RAM。
4. 獨立的 10 GbE 網路 (公用/用戶端和後端)，需要 4x 10 GbE，建議 2x 25 GbE。

 

建議的生產叢集組態