1）CPU選擇

Ceph metadata server會動態的重新分配負載，它是CPU敏感性的，所以Metadata Server應該有比較好的處理器性能 (比如四核CPU). Ceph OSDs運行RADOS服務，需要通過CRUSH來計算數據的存放位置，replicate數據，以及維護Cluster Map的拷貝，因此OSD也需要合適的處理性能 Ceph Monitors 簡單的維護了Cluster Map的主幹信息所以這個是CPU不敏感的。

2）RAM選擇

Metadata servers 以及Monitors 必須能夠快速的提供數據，因此必須有充足的內存(e.g., 1GB of RAM per daemon instance). OSDs 在執行正常的操作時不需要過多的內存 (e.g., 500MB of RAM per daemon instance);但是 執行恢復操作時，就需要大量的內存(e.g., ~1GB per 1TB of storage per daemon). Generally, 而且是越多越好。

3）Data Storage選擇

規劃數據存儲時要考慮成本和性能的權衡。同時OS操作，同時多個後臺程序對單個驅動器進行讀寫操作會顯著降低性能。也有文件系統的限制考慮：BTRFS對於生產環境來說不是很穩定，但有能力記錄journal和並行的寫入數據，而XFS和EXT4會好一點。

提示:不推薦單個磁盤的分區上運行多個OSD。不推薦單個磁盤的分區上運行一個OSD和一個監視器或元數據服務。

存儲驅動器受尋道時間，訪問時間，讀取和寫入時間，以及總吞吐量的限制。這些物理限制會影響整個系統的性能，尤其是在恢復過程中。我們建議為操作系統和軟件使用專用的驅動器，並且為你在主機上運行每個OSD守護分配一個驅動器。大多數“慢OSD”的問題的產生是由於在一個操作系統同一驅動器上運行多個OSDs和/或多個日誌。

由於解決性能問題的一小部分的成本可能超過額外的磁盤驅動器的成本，因此你可以加快你的的集群設計規劃，為了避免OSD存儲驅動器負荷過重。

在每個硬盤驅動器上同時運行多個Ceph的OSD守護程序，但是這可能會導致資源爭用，並降低整體吞吐量。你可能把日誌和對象數據存儲在相同的驅動器上，但這樣可能會增加所花費在記錄寫入操作和發送ACK給客戶端的時間。在CEPH可以ACK對於寫入操作前,Ceph必須把操作寫入到日誌。

BTRFS文件系統的日誌數據和對象數據的同時可以寫，而XFS和ext4的不能。Ceph的推薦做法，分開在單獨的驅動器上運行操作系統，OSD數據和OSD日誌。

本文原創地址：https://www.linuxprobe.com/ceph-linux.html

4）固態硬盤選擇

性能改進的機會之一是使用固態硬盤（SSD），以減少隨機訪問時間，讀取等待時間，同時吞吐量加速。固態硬盤每GB的費用與硬盤驅動器相比往往超過10倍之多，但固態硬盤往往表現至少比硬盤驅動器快100倍的訪問時間。

固態硬盤沒有移動機械部件，所以他們不需要受同類型硬盤驅動器的限制。盡管固態硬盤有明顯的局限性。重要的是考慮其連續讀取和寫入的性能。當存儲多個OSDs的多個日誌時，有400MB/s的順序寫入吞吐量的SSD的性能，相比機械盤120MB/s的順序寫入吞吐量，SSD更好、更快。

固態硬盤的OSD對象存儲成本高昂，通過存儲一個OSD的日誌在一個單獨的硬盤驅動器SSD和OSD的對象數據上時，OSDs上可能會看到一個顯著的性能提升。OSD日誌配置默認在/var/lib/ceph/osd/$cluster-$id/journal裏。你可以掛載這個路徑到SSD或SSD的分區上，將日誌文件和數據文件分別存放在不同的磁盤。

5）Networks選擇

建議每臺機器最少兩個千兆網卡，現在大多數普通硬盤吞的吐量都能達到100MB/s，網卡應該能處理所以OSD硬盤總吞吐量，所以推薦最少兩個千兆網卡，分別用於public network和cluster_network。集群網絡（最好別連接到互聯網）用於處理由數據復制產生的額外負載，並且有助於阻止拒絕服務***，拒絕服務***會幹擾數據歸置組，使之在OSD數據復制時不能回到active+clean狀態。請考慮部署萬兆網卡。通過1Gbps網絡復制1TB數據耗時3小時，而3TB（一個典型的驅動配置）需要9小時，與之相反，如果使用10Gbps復制時間可分別縮減到20分鐘和1小時。

在一個PB級集群中，OSD磁盤失敗是常態，而非異常；在性價比合理的前提下，系統管理員想讓PG盡快從degraded（降級）狀態恢復到active+clean狀態。采用10G網卡值得考慮使用。每個網絡的頂級機架路由器到核心路由器通信應該有更快的吞吐量，例如，40Gbps~100Gbps。

6）其他註意事項：

可以在每臺主機上運行多個OSD進程，但應該確保OSD硬盤的吞吐量總和不超過客戶端讀取或寫入數據所需的網絡帶寬。也應該考慮在每個主機上數據的存儲率。如果一個特定的主機上的百分比較大，它可能會導致問題:為了防止數據丟失,會導致Ceph停止操作。

當每臺主機上運行多個OSD進程時，還需要保證內核是最新的。 當每臺主機上運行多個OSD進程時（如>20）會產生很多的線程，特別是進行recovery和relalancing操作。許多Linux內核默認線程限最大數量比較小（例如，32k的）。如果您遇到這方面的問題，可以考慮把kernel.pid_max設置的高一點。理論上的最大值為4,194,303。

簡單介紹Ceph分布式存儲集群