Ceph 筆記(二)

本篇文章主要簡述了 Ceph 的存儲對象名詞解釋及其含義，以及對 Ceph 集羣內 CRUSH bucket 調整、PG/PGP 參數調整等設置；同時參考了一些書籍資料簡單的概述一下 Ceph 集羣硬件要求等

1、Ceph 組件及定義

1.一、對象

對象是 Ceph 中最小的存儲單元，對象是一個數據和一個元數據綁定的總體；元數據中存放了具體數據的相關屬性描述信息等；Ceph 爲每一個對象生成一個集羣內惟一的對象標識符，以保證對象在集羣內的惟一性；在傳統文件系統的存儲中，單個文件的大小是有必定限制的，而 Ceph 中對象隨着其元數據區增大能夠變得很是巨大

1.二、CRUSH

在傳統的文件存儲系統中，數據的元數據佔據着極其重要的位置，每次系統中新增數據時，元數據首先被更新，而後纔是實際的數據被寫入；在較小的存儲系統中(GB/TB)，這種將元數據存儲在某個固定的存儲節點或者磁盤陣列中的作法還能夠知足需求；當數據量增大到 PB/ZB 級別時，元數據查找性能將會成爲一個很大的瓶頸；同時元數據的統一存放還可能形成單點故障，即當元數據丟失後，實際數據將沒法被找回；與傳統文件存儲系統不一樣的是，Ceph 使用可擴展散列下的受控複製(Controlled Replication Under Scalable Hashing,CRUSH)算法來精確地計算數據應該被寫入哪裏/從哪裏讀取；CRUSH按需計算元數據，而不是存儲元數據，從而解決了傳統文件存儲系統的瓶頸

1.三、CRUSH 查找

在 Ceph 中，元數據的計算和負載是分佈式的，而且只有在須要時纔會執行；元數據的計算過程稱之爲 CRUSH 查找，不一樣於其餘分佈式文件系統，Ceph 的 CRUSH 查找是由客戶端使用本身的資源來完成的，從而去除了中心查找帶來的性能以及單點故障問題；CRUSH 查找時，客戶端先經過 monitor 獲取集羣 map 副本，而後從 map 副本中獲取集羣配置信息；而後經過對象信息、池ID等生成對象；接着經過對象和 PG 數散列後獲得 Ceph 池中最終存放該對象的 PG；最終在經過 CRUSH 算法肯定該 PG 所需存儲的 OSD 位置，一旦肯定了 OSD 位置，那麼客戶端將直接與 OSD 通信完成數據讀取與寫入，這直接去除了中間環節，保證了性能的極大提高

1.四、CRUSH 層級結構

在 Ceph 中，CRUSH 是徹底支持各類基礎設施和用戶自定義的；CRUSH 設備列表中預先定義了一系列的設備，包括磁盤、節點、機架、行、開關、電源電路、房間、數據中心等等；這些組件稱之爲故障區(CRUSH bucket)，用戶能夠經過本身的配置把不一樣的 OSD 分佈在不一樣區域；此後 Ceph 存儲數據時根據 CRUSH bucket 結構，將會保證每份數據都會在所定義的物理組件之間徹底隔離；好比咱們定義了多個機架上的不一樣 OSD，那麼 Ceph 存儲時就會智能的將數據副本分散到多個機架之上，防止某個機架上機器所有跪了之後數據所有丟失的狀況

1.五、恢復和再平衡

當故障區內任何組件出現故障時，Ceph 都會將其標記爲 down 和 out 狀態；而後默認狀況下 Ceph 會等待 300秒以後進行數據恢復和再平衡，這個值能夠經過在配置文件中的 mon osd down out interval 參數來調整

1.六、PG

PG 是一組對象集合體，根據 Ceph 的複製級別，每一個PG 中的數據會被複制到多個 OSD 上，以保證其高可用狀態

1.七、Ceph 池

Ceph 池是一個存儲對象的邏輯分區，每個池中都包含若干個 PG，進而實現將必定對象映射到集羣內不一樣 OSD 中，池能夠以複製方式或者糾錯碼方式建立，但不可同時使用這兩種方式

2、Ceph 組件調整及操做

2.一、池操做

# 建立池rados mkpool test-pool# 列出池rados lspools# 複製池rados cppool test-pool cp-pool# 刪除池rados rmpool test-pool test-pool --yes-i-really-really-mean-it

2.二、對象操做

# 將對象加入到池內rados put testfile anaconda-ks.cfg -p test# 列出池內對象rados ls -p test# 檢查對象信息ceph osd map test testfile# 刪除對象rados rm testfile -p test

2.三、修改 PG 和 PGP

計算 PG 數爲 Ceph 企業級存儲必不可少的的一部分，其中集羣內 PG 計算公式以下

PG 總數 = (OSD 數 * 100) / 最大副本數

對於單個池來說，咱們還應該爲池設定 PG 數，其中池的 PG 數計算公式以下

PG 總數 = (OSD 數 * 100) / 最大副本數 / 池數

PGP 是爲了實現定位而設計的 PG，PGP 的值應該與 PG 數量保持一致；當池的 pg_num 增長的時候，池內全部 PG 都會一分爲二，可是他們仍然保持着之前 OSD 的映射關係；當增長 pgp_num 的時候，Ceph 集羣纔會將 PG 進行 OSD 遷移，而後開始再平衡過程

獲取現有 PG 和 PGP 值能夠經過以下命令

ceph osd pool get test pg_num
ceph osd pool get test pgp_num

當計算好 PG 和 PGP 之後能夠經過如下命令設置

ceph osd pool set test pgp_num 32
ceph osd pool set test pgp_num 32

一樣在建立 pool 的時候也能夠同步指定

ceph osd pool create POOLNAME PG PGP

2.四、pool 副本數調整

默認狀況，當建立一個新的 pool 時，向 pool 內存儲的數據只會有 2 個副本，查看 pool 副本數能夠經過以下命令

ceph osd dump | grep pool

當咱們須要修改默認副本數以使其知足高可靠性需求時，能夠經過以下命令完成

ceph osd pool set POOLNAME size NUM

2.五、定製機羣佈局

上面已經講述了 CRUSH bucket 的概念，經過如下相關命令，咱們能夠定製本身的集羣佈局，以使 Ceph 完成數據的容災處理

# 查看現有集羣佈局ceph osd tree# 添加機架ceph osd crush add-bucket rack01 rack
ceph osd crush add-bucket rack02 rack
ceph osd crush add-bucket rack03 rack# 移動主機到不一樣的機架(dockerX 爲個人主機名)ceph osd crush move docker1 rack=rack01
ceph osd crush move docker2 rack=rack02
ceph osd crush move docker3 rack=rack03# 移動每一個機架到默認的根下ceph osd crush move rack01 root=default
ceph osd crush move rack02 root=default
ceph osd crush move rack03 root=default

最終集羣總體佈局以下

  ~ ceph osd tree
ID WEIGHT  TYPE NAME            UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.01469 root default
-5 0.00490     rack rack01
-2 0.00490         host docker1
 0 0.00490             osd.0         up  1.00000          1.00000
-6 0.00490     rack rack02
-3 0.00490         host docker2
 1 0.00490             osd.1         up  1.00000          1.00000
-7 0.00490     rack rack03
-4 0.00490         host docker3
 2 0.00490             osd.2         up  1.00000          1.00000

3、Ceph 硬件配置

硬件規劃通常是一個企業級存儲的必要工做，如下簡述了 Ceph 的通常硬件需求

3.一、監控需求

Ceph monitor 經過維護整個集羣的 map 從而完成集羣的健康處理；可是 monitor 並不參與實際的數據存儲，因此實際上 monitor 節點 CPU 佔用、內存佔用都比較少；通常單核 CPU 加幾個 G 的內存便可知足需求；雖然 monitor 節點不參與實際存儲工做，可是 monitor 的網卡至少應該是冗餘的，由於一旦網絡出現故障則集羣健康會難以保證

3.二、OSD 需求

OSD 做爲 Ceph 集羣的主要存儲設施，其會佔用必定的 CPU 和內存資源；通常推薦作法是每一個節點的每塊硬盤做爲一個 OSD；同時 OSD 還須要寫入日誌，因此應當爲 OSD 集成日誌留有充足的空間；在出現故障時，OSD 需求的資源可能會更多，因此 OSD 節點根據實際狀況(每一個 OSD 會有一個線程)應該分配更多的 CPU 和內存；固態硬盤也會增長 OSD 存取速度和恢復速度

3.三、MDS 需求

MDS 服務專門爲 CephFS 存儲元數據，因此相對於 monitor 和 OSD 節點，這個 MDS 節點的 CPU 需求會大得多，同時內存佔用也是海量的，因此 MDS 通常會使用一個強勁的物理機單獨搭建

轉載請註明出處，本文采用 CC4.0 協議受權

本文轉自: https://mritd.me/2017/05/30/ceph-note-2/