1. Ceph簡介
所有的 Ceph 存儲集群的部署都始於一個個 Ceph節點、網絡和 Ceph存儲集群。Ceph 存儲集群至少需要一個 Ceph Monitor、一個 Manager和一個Ceph OSD 守護進程。在運行 Ceph 作為文件存儲時，還需要 Ceph 元數據服務。
Monitors：Ceph監視器（ceph-mon）維護集群狀態的映射，包括監視器映射、管理器映射、OSD映射和 CRUSH 映射。這些映射是Ceph守護進程相互協調所需的關鍵集群狀態。Monitor還負責管理守護進程和客戶機之間的身份驗證。為了冗余和高可用性，通常至少需要三個監視器。
Managers: Ceph管理進程（ceph-mgr）守護進程負責跟蹤Ceph集群的運行指標和當前狀態，包括存儲利用率、當前性能指標和系統負載。Ceph Manager 守護進程還托管基於python的模塊來管理和公開Ceph集群信息，包括基於web的Ceph dashboard 和 REST API 高可用通常需要至少兩個管理器。
Ceph OSDs: 對象存儲守護進程（ceph-osd）存儲數據，處理數據復制，恢復，重新平衡並通過檢查其他Ceph OSD 守護進程的心跳來為Ceph Monitor 和 Manager 提供一些監控信息，至少3 Ceph OSDs通常需要冗余和高可用性。
MDSs：Ceph元數據服務器（MDS，ceph-mds）Ceph元數據服務器允許POSIX文件系統用戶執行基本命令（如ls、find等）,而不會給Ceph存儲集群帶來巨大的負擔。
Ceph將數據作為對象存儲在邏輯存儲池中，使用 CRUSH算法，Ceph計算哪個對象應該被放置到哪個PG里，並進一步計算哪個Ceph OSD守護進程應該存放PG，CRUSH 算法使Ceph存儲集群能夠動態伸縮、再平衡和恢復。
2. 硬件推薦
Ceph 被設計成在普通硬件上運行，這使得建立和維護PB級別的數據集群在經濟上可行的。在規划硬件集群時，需要平衡許多考慮事項，包括故障域和潛在的性能問題。硬件規划應該包括在許多主機上分發Ceph守護進程和其他使用Ceph的進程。通常，建議在為該類型守護進程配置的主機上運行特定類型的Ceph守護進程。建議使用其他主機來處理利用你的數據集群的進程。
CPU
Ceph 元數據服務器對 CPU 敏感，它會動態地重分布它們的負載，所以你的元數據服務器應該有足夠的處理能力（如 4 核或更強悍的 CPU ）。Ceph 的 monitor 守護進程維護了 clustermap，它不給客戶端提供任何數據，因此它是輕量級的，並沒有嚴格的處理器要求。在大多數場景下，一個普通的單核服務器處理器就可以運行 Ceph monitor 服務。Ceph 的 OSD 運行着 RADOS 服務、用 CRUSH 計算數據存放位置、復制數據、維護它自己的集群運行圖副本，因此 OSD 需要一定的處理能力（如雙核 CPU ）。監視器只簡單地維護着集群運行圖的副本，因此對 CPU 不敏感；但必須考慮機器以后是否還會運行 Ceph 監視器以外的 CPU 密集型任務。例如，如果服務器以后要運行用於計算的虛擬機（如 OpenStack Nova ），你就要確保給 Ceph 進程保留了足夠的處理能力，所以我們推薦在其他機器上運行 CPU 密集型任務。
一個 Ceph OSD 守護進程需要相當數量的處理性能，因為它提供數據給客戶端。要評估 Ceph OSD 的 CPU 需求，知道服務器上運行了多少 OSD 上非常重要的。通常建議每個 OSD 進程至少有一個核心。可以通過以下公式計算 OSD 的 CPU 需求：
（（CPU sockets * CPU cores per socket * CPU clock speed in GHz ）/ No.of OSD ） >= 1
比如：
Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 6 core --> 1 * 6 * 2.40 = 14.4 適合多達 14 個 OSD 的 Ceph 節點
Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz 12 core --> 1 * 12 * 2.50 = 30 適合多達 30 個 OSD 的 Ceph 節點
如果打算使用 Ceph 糾刪碼特性，最好能有一個更高性能的CPU ，因為運行糾刪碼需要更強的處理能力。
RAM 內存
元數據服務器和監視器必須可以盡快地提供它們的數據，所以他們應該有足夠的內存，至少每進程 1GB 。 OSD 的日常運行不需要那么多內存（如每進程 500MB ）差不多了；然而在恢復期間它們占用內存比較大（如每進程每 TB 數據需要約 1GB 內存）。通常內存越多越好。
網絡
Ceph 是一個分布式存儲系統，很大程度上依賴於底層的網絡基礎設施。要讓Ceph集群變得可靠、高效，就得確保設計一個良好的網絡。建議讓所有的集群節點擁有兩張冗余獨立的網卡用於集群和客戶端流量。
一個設計良好的Ceph集群使用兩個物理隔離網絡：一個是集群網絡（內部網絡），另一個是客戶端網絡（外部網絡）。兩個網絡應該從服務器到網絡交換機以及它們之間的一切環節都進行物理隔離，如下圖：
數據存儲
要謹慎地規划數據存儲配置，因為其間涉及明顯的成本和性能折衷。來自操作系統的並行操作和到單個硬盤的多個守護進程並發讀、寫請求操作會極大地降低性能。
重要提示：因為 Ceph 發送 ACK 前必須把所有數據寫入日志（至少對 xfs 和 ext4 來說是），因此均衡日志和 OSD 性能相當重要。
硬盤驅動器
OSD 應該有足夠的空間用於存儲對象數據。考慮到大硬盤的每 GB 成本，我們建議用容量大於 1TB 的硬盤。建議用 GB 數除以硬盤價格來計算每 GB 成本，因為較大的硬盤通常會對每 GB 成本有較大影響，例如，單價為 $75 的 1TB 硬盤其每 GB 價格為 $0.07 （ $75/1024=0.0732 ），又如單價為 $150 的 3TB 硬盤其每 GB 價格為 $0.05 （ $150/3072=0.0488 ），這樣使用 1TB 硬盤會增加 40% 的每 GB 價格，它將表現為較低的經濟性。另外，單個驅動器容量越大，其對應的 OSD 所需內存就越大，特別是在重均衡、回填、恢復期間。根據經驗， 1TB 的存儲空間大約需要 1GB 內存。
提示：不顧分區而在當個硬盤上運行多個OSD 是不明智的！
提示：不顧分區而在運行了OSD的硬盤上同時運行監視器或元數據服務器也上不明智的！
存儲驅動器受限於尋道時間、訪問時間、讀寫時間、還有總吞吐量，這些物理局限性影響着整體系統性能，尤其在系統恢復期間。因此我們推薦獨立的驅動器用於安裝操作系統和軟件，另外每個 OSD 守護進程占用一個驅動器。大多數 “slow OSD”問題的起因都是在相同的硬盤上運行了操作系統、多個 OSD 、和/或多個日志文件。鑒於解決性能問題的成本差不多會超過另外增加磁盤驅動器，你應該在設計時就避免增加 OSD 存儲驅動器的負擔來提升性能。
Ceph 允許你在每塊硬盤驅動器上運行多個 OSD ，但這會導致資源競爭並降低總體吞吐量； Ceph 也允許把日志和對象數據存儲在相同驅動器上，但這會增加記錄寫日志並回應客戶端的延時，因為 Ceph 必須先寫入日志才會回應確認了寫動作。 btrfs 文件系統能同時寫入日志數據和對象數據， xfs 和 ext4 卻不能。
Ceph 最佳實踐指示，你應該分別在單獨的硬盤運行操作系統、 OSD 數據和 OSD 日志。
固態硬盤
一種提升性能的方法是使用固態硬盤（ SSD ）來降低隨機訪問時間和讀延時，同時增加吞吐量。 SSD 和硬盤相比每 GB 成本通常要高 10 倍以上，但訪問時間至少比硬盤快 100 倍。
SSD 沒有可移動機械部件，所以不存在和硬盤一樣的局限性。但 SSD 也有局限性，評估SSD 時，順序讀寫性能很重要，在為多個 OSD 存儲日志時，有着 400MB/s 順序讀寫吞吐量的 SSD 其性能遠高於 120MB/s 的。
重要提示：建議發掘 SSD 的用法來提升性能。然而在大量投入 SSD 前，我們強烈建議核實 SSD 的性能指標，並在測試環境下衡量性能。
正因為 SSD 沒有移動機械部件，所以它很適合 Ceph 里不需要太多存儲空間的地方。相對廉價的 SSD 很誘人，慎用！可接受的 IOPS 指標對選擇用於 Ceph 的 SSD 還不夠，用於日志和 SSD 時還有幾個重要考量：
- 寫密集語義： 記日志涉及寫密集語義，所以你要確保選用的 SSD 寫入性能和硬盤相當或好於硬盤。廉價 SSD 可能在加速訪問的同時引入寫延時，有時候高性能硬盤的寫入速度可以和便宜 SSD 相媲美。
- 順序寫入： 在一個 SSD 上為多個 OSD 存儲多個日志時也必須考慮 SSD 的順序寫入極限，因為它們要同時處理多個 OSD 日志的寫入請求。
- 分區對齊： 采用了 SSD 的一個常見問題是人們喜歡分區，卻常常忽略了分區對齊，這會導致 SSD 的數據傳輸速率慢很多，所以請確保分區對齊了。
SSD 用於對象存儲太昂貴了，但是把 OSD 的日志存到 SSD 、把對象數據存儲到獨立的硬盤可以明顯提升性能。 osd journal 選項的默認值是 /var/lib/ceph/osd/$cluster-$id/journal ，你可以把它掛載到一個 SSD 或 SSD 分區，這樣它就不再是和對象數據一樣存儲在同一個硬盤上的文件了。
控制器
硬盤控制器對寫吞吐量也有顯著影響，要謹慎地選擇，以免產生性能瓶頸。
其他注意事項
你可以在同一主機上運行多個 OSD ，但要確保 OSD 硬盤總吞吐量不超過為客戶端提供讀寫服務所需的網絡帶寬；還要考慮集群在每台主機上所存儲的數據占總體的百分比，如果一台主機所占百分比太大而它掛了，就可能導致諸如超過 full ratio 的問題，此問題會使 Ceph 中止運作以防數據丟失。
如果每台主機運行多個 OSD ，也得保證內核是最新的。
OSD 數量較多（如 20 個以上）的主機會派生出大量線程，尤其是在恢復和重均衡期間。很多 Linux 內核默認的最大線程數較小（如 32k 個），如果您遇到了這類問題，可以把 kernel.pid_max 值調高些。理論最大值是 4194303 。例如把下列這行加入 /etc/sysctl.conf 文件：
kernel.pid_max = 4194303
Ceph OSD 節點的密度也是影響集群性能、可用容量和 TCO（Total Cost of Ownership ，即總擁有成本）的一個重要因素。通常，大量的小容量節點 比 少量的大容量節點要好，但這並不是定論，應該選擇適當的 Ceph 節點密度，使得三個節點容量小於總容量的 10%。例如：在一個 1PB的ceph集群中，應該避免使用 4 個 250TB 的 OSD 節點，因為每個節點占用了 25% 的集群容量。相反，可以使用 13 個 80TB 的 OSD節點，每個節點容量小於集群容量的 10%。
參考鏈接：
http://docs.ceph.org.cn/start/hardware-recommendations/