Hardware Recommendations【硬件推薦】

‍‍

硬件推薦（內容提要）

 

1.CPU  
2.RAM
3.Data Storage（數據存儲）
     3.1 Hard Disk Drives（硬盤驅動器）
     3.2 Solid State Drives（固態硬盤）
     3.3 Controllers（控制器）
     3.4 Additional Considerations（其餘注意事項）
4.Networks（網絡）
5.Failure Domains（故障域）
6.Minimum Hardware Recommendations（最低硬件建議）
7.Production Cluster Example（生產集羣示例）

硬件推薦‍‍

        Ceph的目的是要在標準硬件上運行，這使得PB級數據集羣的建設和維護從經濟上來講是可行的。規劃集羣硬件時，須要平衡多方面的因素，包括故障域和潛在的性能問題。硬件規劃應包括分佈在許多主機上使用的Ceph的Ceph守護進程和其餘進程。通常來講，咱們建議某一特定類型，這種類型的守護進程配置爲一臺機器上只運行一種類型的守護進程。咱們建議利用你的數據集羣的進程時使用其餘的主機（如OpenStack裏面的CloudStack，等等）。

        建議:也須要檢查ceph日誌。 相似於Ceph Write Throughput 1, Ceph Write Throughput 2, Argonaut v. Bobtail Performance Preview, Bobtail Performance - I/O Scheduler Comparison的文章和其餘的文章是一個很好的信息來源。

1.CPU 

        Ceph的元數據服務器動態地從新分配他們的負荷，這是CPU密集型。所以你的元數據服務器應該有足夠的處理能力（如4核或更強悍）。的處理器Ceph的OSDs運行着RADOS服務、用CRUSH計算數據存放位置、複製數據、維護它本身的集羣運行圖副本。所以OSDs應該有必定的處理能力（如雙核處理器）。監視器只是簡單地維護着集羣主副本，所以它們不是CPU密集型。除了運行Ceph的守護進程，你還必須考慮主機是否運行CPU密集型進程。例如，若是你的主機將運行用於計算的虛擬機（如OpenStack Nova）,你將要確保其餘的進程爲Ceph進程留下了足夠的處理能力，咱們建議在不一樣的主機上運行額外的CPU密集型進程。

2.RAM 

    元數據服務器和監視器必須可以快速的提供他們的數據，所以他們應該有足夠的內存（例如，以每一個守護進程爲例須要1GB內存）。OSDs進行常規操做不須要太多的內存（例如，以每一個守護進程爲例須要500MB內存）；然而，在恢復過程期間很明顯的它們須要更多的內存（例如，一個守護進程每存儲1TB數據須要~1GB內存）。通常來講，更大的內存更好。

3.數據存儲 

       謹慎規劃你的數據存儲配置。有顯着的成本和性能折衷的考慮時能夠規劃數據存儲。同步操做系統的操做，同時要求多個守護進程對單個驅動器的讀取和寫入操做會在很大程度上下降計算機性能。也要考慮文件系統限制：BTRFS對於生產是不太穩定的，但它有日誌的功能，並同時寫入數據，而XFS和ext4則沒有。

        重要提示：   當Ceph的全部數據寫入到日誌，才能夠發送一個ACK（至少XFS和EXT4），所以日誌和OSDs平衡的表現真的很重要！

3.1硬盤驅動器

         OSDs對象數據應該有足夠的硬盤容量。咱們推薦的最小的硬盤驅動器大小爲1TB。考慮到較大的硬盤每GB的成本優點，咱們建議硬盤驅動器的價格除以吉字節數獲得每GB的成本，由於較大的磁盤驅動器在每GB的花費上能夠具備顯着的影響。例如，1TB的硬盤售價爲$75.00 ，其成本爲每GB0.07美圓（即$ 75/1024 = 0.0732）。相比之下；3TB的硬盤售價爲$150.00，其成本爲每GB0.05美圓（即$ 150/3072 = 0.0488）。在上述的例子中，使用1TB的磁盤，通常每GB的成本增長40％，構建集羣遠低於成本效益。此外，存儲驅動器的容量更大，則你將須要更多的內存提供給每一個OSD守護進程，尤爲是在平衡、回填、恢復期間。通常經驗法則是~1GB 內存，1TB的存儲空間。

        提示:在單個磁盤的分區上運行多個OSD不是一個好主意。

        提示:在單個磁盤的分區上運行一個OSD和一個監視器或元數據服務不是一個好主意。

        存儲驅動器受尋道時間，訪問時間，讀取和寫入時間，以及總吞吐量的限制。這些物理限制會影響整個系統的性能，尤爲是在恢復過程當中。咱們建議爲操做系統和軟件使用專用的驅動器，而且爲你在主機上運行每一個OSD守護分配一個驅動器。大多數「慢OSD」的問題的產生是因爲在一個操做系統同一驅動器上運行多個OSDs和/或多個日誌。因爲解決性能問題的一小部分的成本可能超過額外的磁盤驅動器的成本，所以你能夠加快你的的集羣設計規劃，爲了不OSD存儲驅動器負荷太重。

        您可能在每一個硬盤驅動器上同時運行多個Ceph的OSD守護程序，可是這可能會致使資源爭用，並下降總體吞吐量。你可能把日誌和對象數據存儲在相同的驅動器上，但這樣可能會增長所花費在記錄寫入操做和發送ACK給客戶端的時間。在CEPH能夠ACK對於寫入操做前,Ceph必須把操做寫入到日誌。BTRFS文件系統的日誌數據和對象數據的同時能夠寫，而XFS和ext4的不能。

        Ceph的最佳作法決定，你應該分開在單獨的驅動器上運行操做系統，OSD數據和OSD日誌。

3.2固態硬盤

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

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

       重要提示:咱們建議探索利用固態硬盤來提高性能。然而，在做出重大投資固態硬盤以前，咱們強烈建議審查一個SSD的性能指標和在測試配置時測試SSD來衡量性能。

       因爲固態硬盤沒有移動機械部件，在Ceph的領域使用它們而不使用大量的存儲空間是有道理的（例如，日誌）。相對便宜的固態硬盤可能會吸引到你的經濟頭腦。謹慎使用。當SSD和Ceph一塊兒用時，僅僅能夠運行的IOPS是不夠的。日誌和SSD有幾個重要的性能方面的考慮：

 •寫入密集型的語義：日誌涉及寫入密集型的語義，所以你應該確保當你寫入數據時，你選擇的SSD部署將等於或優於硬盤驅動器。廉價的固態硬盤，甚至可能會爲了加快訪問時間而引入寫入延遲，由於有時高性能硬盤驅動器在寫入上能夠和一些市場上現有的更經濟的固態硬盤同樣快，甚至更快！

•連續寫入：當你在SSD上儲存多個日誌時，你也必須考慮SSD連續寫入的限制太多，由於它們可能在處理請求的同時會寫入多個OSD日誌。

•分區對齊： SSD性能的一個常見問題，由於人們喜歡爲驅動器分區做爲最佳實踐，但他們每每忽略了適當的固態硬盤分區對齊，這可能會致使固態硬盤的數據傳輸速度要慢得多。確保SSD分區正確對齊。

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

        Ceph使CephFS的文件系統性能加速的一個方法是在CephFS文件內容的存儲中分開存儲CephFS元數據。Ceph爲CephFS元數據提供了一個默認的元數據池。你永遠不能爲CephFS元數據建立一個元數據池，可是你能夠爲僅指向一臺主機的SSD存儲介質的CephFS元數據池建立一個CRUSH的映射層。見 池映射到不一樣類型的OSD獲取更多細節。

3.3控制器

        磁盤控制器對於寫入吞吐量也有顯着的影響。謹慎考慮你選擇的磁盤控制器，以確保他們不會建立一個性能瓶頸。

        建議:Ceph的日誌每每是Ceph的性能問題一個很好的信息來源。爲了獲取更多詳細信息，請參閱 Ceph Write Throughput 1 和 Ceph Write Throughput 2

3.4其餘注意事項

        您能夠在每臺主機上運行多個OSD，但你應該確保你的OSD硬盤總吞吐量的總和不超過所需的用來服務客戶端須要來讀取或寫入數據的網絡帶寬。您還應該考慮在每一個主機上的集羣存儲的總體數據百分比。若是特定主機上的比例大而且主機發生故障，它可能會致使問題，好比超負荷，這會致使CEPH由於防止數據丟失的安全警告而中止操做。

        當你在每臺主機運行多個OSDs時，你還須要保證內核是最新的。請參閱推薦操做系統的glibc和 syncfs（2）以確保您的硬件當在每臺主機上運行多個OSD時的執行像先前預計的那樣。

4.網絡 

        建議每臺機器最少兩個千兆網卡，如今大多數普通硬盤吞的吐量都能達到100MB/s，網卡應該能處理因此OSD硬盤總吞吐量，因此推薦最少兩個千兆網卡，分別用於公網（前端）和集羣網絡（後端）。集羣網絡（最好別鏈接到互聯網）用於處理由數據複製產生的額外負載，而且有助於阻止拒絕服務攻擊，拒絕服務攻擊會干擾數據歸置組，使之在OSD數據複製時不能回到active+clean狀態。請考慮部署萬兆網卡。經過1Gbps網絡複製1TB數據耗時3小時，而3TB（一個典型的驅動配置）須要9小時，與之相反，若是使用10Gbps複製時間可分別縮減到20分鐘和1小時。在一個PB級集羣中，OSD磁盤失敗是常態，而非異常；在性價比合理的前提下，系統管理員想讓PG儘快從degraded（降級）狀態恢復到active+clean狀態。另外，一些部署工具（如Dell的Crowbar）有5種不一樣的網絡部署，使用了VLAN以提升網絡和硬件可管理性。VLAN使用802.1q協議，還須要採用支持VLAN功能的網卡和交換機，增長的硬件成本可用節省的運營（網絡安裝、維護）成本抵消。使用VLAN來處理虛擬機流量間的集羣和計算堆棧（如OpenStack、CloudStack等等）時，採用10G網卡值得考慮使用。每一個網絡的頂級機架路由器到核心路由器通訊應該有更快的吞吐量，例如，40Gbps~100Gbps。

        你的服務器硬件上應該配置底板管理控制器（Baseboard Management Controller，BMC），管理和部署工具也應該大規模使用BMC，因此考慮一個帶外網絡管理成本/本效益平衡。Hypervisor的SSH訪問，VM圖像上傳，操做系統的映像安裝，套接字管理等，會使網絡上的負載增長很明顯。運行三個網絡看起來有些浪費，但沒個通訊路徑表明一個潛在的容量，在部署大規模數據集羣以前，你應該謹慎考慮吞吐量和/或性能瓶頸。

5.故障域 

         故障域指任何致使不能訪問一個或多個OSD的故障，這多是中止了主機上的守護程序、硬盤故障，操做系統崩潰，網卡發生故障、電源供應器故障、網絡中斷、 停電等等。規劃出你的硬件需求時，你必須權衡付出不少努力來減小故障域帶來的成本削減、隔離每一個潛在故障域增長的成本的誘惑。

6.最低硬件建議 

Ceph能夠運行在廉價的普通硬件上，小型生產集羣和開發集羣能夠在通常的硬件上。

過程標準最低配置推薦

ceph OSD處理器1X 64位AMD-64/i386的雙核

RAM每一個守護500 MB

存儲卷每一個守護1X磁盤

網絡2個1GB以太網網卡

ceph mon處理器1X 64位AMD-64/i386

RAM1 GB的守護

磁盤空間10 GB每守護

網絡2個1GB以太網網卡

ceph MDS處理器1X的64位AMD-64/i386四核心

RAM最低1 GB每守護

磁盤空間每一個守護進程1 MB

網絡2個1GB以太網網卡

提示:若是在只有一個硬盤的機器上運行OSD，要把數據和操做系統分別放到不一樣分區;通常來講，咱們推薦操做系統和數據分別使用不一樣的硬盤。

7.生產集羣示例 

 PB級生產集羣也可使用普通硬件，但應該配備更多內存、CPU和數據存儲空間來解決流量壓力。

一個最新（2012）的Ceph集羣項目使用了兩個至關強悍的OSD硬件配置，和稍遜的監視器配置。

組態標準最低配置推薦

戴爾PE R510處理器2個64位四核Xeon處理器

RAM16 GB

存儲卷8個2TB驅動器。1個操做系統，7個存儲

客戶端網絡2個1GB以太網網卡

OSD網絡2個1GB以太網網卡

管理 網絡2個1GB以太網網卡

戴爾PE R515處理器1X 16核 Opteron CPU

RAM16 GB

存儲卷12X 3TB硬盤的存儲

OS存儲1X 500GB硬盤的操做系統。

客戶端網絡2個1GB以太網網卡

OSD網絡2個1GB以太網網卡

管理網絡2個1GB以太網網卡