CEPH-5：ceph叢集基本概念與管理

vfanCloud發表於2022-05-05

ceph叢集基本概念與管理

ceph叢集基本概念

ceph叢集整體結構圖

名稱	作用
osd	全稱Object Storage Device，主要功能是儲存資料、複製資料、平衡資料、恢復資料等。每個OSD間會進行心跳檢查，並將一些變化情況上報給Ceph Monitor。
mon	全稱Monitor,負責監視Ceph叢集，維護Ceph叢集的健康狀態，同時維護著Ceph叢集中的各種Map圖，比如OSD Map、Monitor Map、PG Map和CRUSH Map，這些Map統稱為Cluster Map，根據Map圖和object id等計算出資料最終儲存的位置。
mgr	全稱Manager，負責跟蹤執行時指標和Ceph叢集的當前狀態，包括儲存利用率，當前效能指標和系統負載。
mds	全稱是MetaData Server，主要儲存的檔案系統服務的後設資料，如果使用cephfs功能才會啟用它，物件儲存和塊儲存裝置是不需要使用該服務。
rgw	全稱radosgw，是一套基於當前流行的RESTFUL協議的閘道器，ceph物件儲存的入口，內嵌civetweb服務，不啟用物件儲存，則不需要安裝。

ceph配置檔案

標準位置：/etc/ceph/ceph.conf

組成部分：

## 全域性配置，全域性生效
[global]
fsid = 537175bb-51de-4cc4-9ee3-b5ba8842bff2
public_network = 10.0.0.0/8
cluster_network = 10.0.0.0/8
mon_initial_members = ceph-node1
mon_host = 10.153.204.xx:6789,10.130.22.xx:6789,10.153.204.xx:6789
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

## osd專用配置，可以使用osd.num 來表示具體的哪一個osd
[osd]
[osd.1]

## monitor專用配置，可以使用mon.A 來表示具體的哪一個monitor，其中A表示該節點的名稱，使用ceph mon dump可以檢視。
[mon]
[mon.a]

## 客戶端專用配置
[client]

ceph配置檔案的載入順序：

$CEPH_CONF 環境變數

-c 指定的位置
/etc/ceph/ceph.conf
~/.ceph/ceph.conf
./ceph.conf

儲存池型別
- 副本池：replicated
  - 定義每個物件在叢集中儲存為多少個副本，預設為三個副本，一主兩備
  - 實現高可用，副本池是 ceph 預設的儲存池型別。
- 糾刪碼池：erasure code
  - 把各物件儲存為 N=K+M 個塊，其中 K 為資料塊數量，M 為編碼塊數量，因此儲存池的尺寸為 K+M。
  - 即資料儲存在 K 個資料塊，並提供 M 個冗餘塊提供資料高可用，那麼最多能故障的塊就是 M 個，實際的磁碟佔用就是 K+M 塊，因此相比副本池機制比較節省儲存資源，一般採用 8+4 機制，即 8 個資料塊+4 個冗餘塊，那麼也就是 12 個資料塊有 8 個資料塊儲存資料，有 4 個實現資料冗餘，即 1/3 的磁碟空間用於資料冗餘，比預設副本池的三倍冗餘節省空間，但是不能出現大於一定資料塊故障。
  - 不是所有的應用都支援糾刪碼池，RBD 只支援副本池而 radosgw 則可以支援糾刪碼池。
  - 對於檔案系統及塊儲存，由於讀寫效能的問題 Ceph 不建議使用糾刪碼池。
如何檢視某個儲存池為什麼型別：
```
$ ceph osd pool get test crush_rule
crush_rule: erasure-code
```

副本池IO

將一個資料物件儲存為多個副本。
在客戶端寫入操作時，ceph 使用 CRUSH 演算法計算出與物件相對應的 PG ID 和 primary OSD ，主 OSD 根據設定的副本數、物件名稱、儲存池名稱和叢集執行圖(cluster map)計算出 PG 的各輔助 OSD，然後由 OSD 將資料再同步給輔助 OSD。

讀寫資料：

## 讀資料
1.客戶端傳送讀請求，RADOS 將請求傳送到主 OSD。
2.主 OSD 從本地磁碟讀取資料並返回資料，最終完成讀請求。

## 寫資料
1.客戶端APP請求寫入資料，RADOS傳送資料到主OSD。
2.主OSD寫入完畢後將完成訊號給客戶端APP，併傳送資料到各副本OSD。
3.副本OSD寫入資料，併傳送寫入完成訊號給主OSD。

糾刪碼池 IO

Ceph 從 Firefly 版本開始支援糾刪碼，但是不推薦在生產環境使用糾刪碼池。
糾刪碼池降低了資料儲存所需要的磁碟總空間數量，但是讀寫資料的計算成本要比副本池高，RGW 可以支援糾刪碼池，RBD 不支援。

讀寫資料：

## 讀資料
1.從相應的 OSDs 中獲取資料後進行解碼
2.如果此時有資料丟失，Ceph 會自動從存放校驗碼的 OSD 中讀取資料進行解碼
3.完成資料解碼後返回資料

## 寫資料
1.資料將在主 OSD 進行編碼然後分發到相應的 OSDs 上去
2.計算合適的資料塊並進行編碼
3.對每個資料塊進行編碼並寫入OSD

PG與PGP
- PG = Placement Group # 歸置組
- PGP = Placement Group for Placement purpose # 歸置組的組合，pgp 相當於是 pg 對應 osd 的一種排列組合關係。
歸置組(placement group)是用於跨越多osd將資料儲存在每個儲存池中的內部資料結構。 pg 在 osd 守護程式和 ceph 客戶端之間的一箇中間層，hash 演算法負責將每個物件動態對映到一個pg中，此pg即為主pg，按照儲存池的副本數量（例如3個）會再將每個主pg再複製出兩個副本pg，CRUSH 演算法負責將三個 pg 動態對映到三個不同的 OSD 守護程式中，此三個pg組成一個pgp，從而在 osd 中達到多副本高可用。

檔案定址流程大致如下圖所示：

File->Objects->PGs->OSDs。

需要注意的幾個點：

PG和PGP可以自定義數量，且是針對於儲存池的，但PG總數會根據OSD叢集的大小決定
相對於儲存池來說，PG是一個虛擬元件，它是物件對映到儲存池時使用的虛擬層
出於規模伸縮及效能方面的考慮，ceph將儲存池細分為多個PGP，每個PGP中有一個主PG，主PG所在的OSD節點便是主OSD。
當有新OSD節點加入叢集時，ceph會通過CRUSH重新組合PGP，致使每個OSD都有資料，達到整個叢集的資料平衡。

PG的分配計算：

官方建議：每個osd中的pg數量最好不要超過100個，公式：Total PGS = (Total_number_of _osd * 100) / max_replication_count
具體演算法：舉例現在有12臺osd機器，我需要建立20個儲存池。

此時pg總數為：12 * 100 / 3 = 400

平均每個儲存池分配pg數量為：400 / 20 = 20

這裡計算出，平均每個儲存池可以分配20個pg，但每個儲存池pg的個數推薦為2的N次冪，故2、4、8、16、32、64、128等，這時要結合具體的pool是來儲存什麼，大概能儲存多少資料來進行一個簡單的轉換，如果此pool只儲存一些後設資料，則分配4即可，反之資料量比較大的，可以分配16、32等。

另外pool中pg個數是推薦用2的整數次冪，也可以不用，但會有警告提示。

PG與PGP組合：

檢視replicapool池的pg、pgp數量

$ ceph osd pool get replicapool pg_num 
pg_num: 32
$ ceph osd pool get replicapool pgp_num 
pgp_num: 32

檢視replicapool池的pg、pgp分佈

$ ceph pg ls-by-pool replicapool | awk '{print $1,$2,$15}'
PG OBJECTS ACTING
2.0 596 [3,1,0]p3
2.1 623 [3,4,0]p3
2.2 570 [3,4,0]p3
2.3 560 [3,4,0]p3
2.4 630 [0,3,4]p0
2.5 574 [4,0,3]p4
2.6 572 [4,3,0]p4
2.7 572 [3,4,0]p3
2.8 622 [3,4,0]p3
2.9 555 [0,3,4]p0
2.a 523 [1,3,0]p1
2.b 574 [4,3,0]p4
2.c 620 [4,3,0]p4
2.d 637 [1,3,0]p1
2.e 522 [0,3,4]p0
2.f 599 [4,3,0]p4
2.10 645 [4,3,0]p4
2.11 534 [3,4,0]p3
2.12 622 [4,3,0]p4
2.13 577 [1,3,0]p1
2.14 661 [3,4,0]p3
2.15 626 [1,3,0]p1
2.16 585 [2,4,0]p2
2.17 610 [3,4,0]p3
2.18 610 [4,2,0]p4
2.19 560 [4,3,0]p4
2.1a 599 [3,4,0]p3
2.1b 614 [1,2,0]p1
2.1c 581 [4,3,0]p4
2.1d 614 [4,3,0]p4
2.1e 595 [0,3,1]p0
2.1f 572 [3,4,0]p3
  
* NOTE: afterwards

PG的狀態解釋：

在osd擴縮容或者一些特殊情況的時候，ceph會以pg為整體進行rebalancing資料重平衡，此時pg會出現很多不同的狀態，例如：

$ ceph -s 
  cluster:
    id:     537175bb-51de-4cc4-9ee3-b5ba8842bff2
    health: HEALTH_WARN
            Degraded data redundancy: 152/813 objects degraded (18.696%), 43 pgs degraded, 141 pgs undersized
 
  services:
    mon: 2 daemons, quorum yq01-aip-aikefu10,bjkjy-feed-superpage-gpu-04 (age 111s)
    mgr: yq01-aip-aikefu10(active, since 11d), standbys: bjkjy-feed-superpage-gpu-04
    mds: mycephfs:1 {0=ceph-node2=up:active} 1 up:standby
    osd: 8 osds: 8 up (since 3d), 8 in (since 3d); 124 remapped pgs
    rgw: 2 daemons active (ceph-node1, ceph-node2)
 
  task status:
 
  data:
    pools:   8 pools, 265 pgs
    objects: 271 objects, 14 MiB
    usage:   8.1 GiB used, 792 GiB / 800 GiB avail
    pgs:     152/813 objects degraded (18.696%)
             114/813 objects misplaced (14.022%)
             111 active+clean+remapped
             98  active+undersized
             43  active+undersized+degraded
             13  active+clean

clean：乾淨態，PG當前不存在待修復的物件，並且大小等於儲存池的副本數，即PG的活動集(Acting Set)和上行集(Up Set)為同一組 OSD 且內容一致。
active：就緒狀態或活躍狀態，Active 表示主 OSD 和備 OSD 處於正常工作狀態，此時的 PG 可以正常處理來自客戶端的讀寫請求，正常的 PG 預設就是 Active+Clean 狀態。
peering：正在同步狀態，同一個 PG 中的OSD需要將準備資料同步一致，而Peering(對等)就是OSD同步過程中的狀態。
activating：Peering 已經完成，PG 正在等待所有 PG 例項同步 Peering 的結果(Info、Log 等)
degraded：降級狀態，出現於 OSD 被標記為 down 以後，那麼其他對映到此 OSD 的 PG 都會轉換到降級狀態，如果此OSD被標記為down的時間超過 5 分鐘還沒有修復，ceph 會對被降級的 PG 啟動恢復操作，直到所有由於此 OSD 而被降級的 PG 重新恢復為 clean 狀態。
undersized：PG 當前副本數小於其儲存池定義的值的時候，PG 會轉換為 undersized 狀態，直到新增備份 OSD 新增完成，或者修復完成。
remapped：當 pg 改變, 資料從舊的 OSD 遷移到新的 OSD, 新的主 OSD 應該請求將會花費一段時間, 在這段時間內, 將會繼續向舊主 OSD 請求服務, 直到 PG 遷移完成。
scrubbing：scrub 是 ceph 對資料的清洗狀態，用來保證資料完整性的機制，Ceph 的 OSD 定期啟動 scrub 執行緒來掃描部分物件，通過與其他副本比對來發現是否一致，主要檢查後設資料(metadata )資訊，比如檔名、object屬性、大小等，如果不一樣，就會從主pg複製一份過去。
stale：過期狀態，正常狀態下，每個OSD都要週期性的向 RADOS 叢集中的監視器(mon)報告其作為OSD所持有的所有主PG的最新統計資料，因任何原因導致某個OSD無法正常向監視器傳送彙報資訊的、或者由其他OSD報告某個OSD已經down的時候，則所有以此OSD為主PG則會立即被標記為stale狀態，即它們的主 OSD 已經不是最新的資料了。
recovering：正在恢復態，叢集正在執行遷移或同步物件和他們的副本。這可能是由於新增了一個新的OSD到叢集中或者某個OSD 宕掉後，PG被CRUSH演算法重新分配到不同的OSD，其中PG發生內部資料同步的過程。
backfilling：後臺填充態，backfill 是recovery的一種特殊場景，指peering完成後，如果基於當前權威日誌無法對Up Set(上行集)當中的某些PG例項實施增量同步（例如承載這些 PG 例項的 OSD 離線太久，或者是新的 OSD 加入叢集導致的 PG 例項整體遷移），則通過完全拷貝當前 Primary 所有物件的方式進行全量同步，此過程中的 PG 會處於 backfilling。
backfill-toofull：某個需要被 Backfill 的 PG 例項，其所在的 OSD 可用空間不足，Backfill 流程當前被掛起時 PG給的狀態。
creating：建立PG中的狀態，一般出現建立新pool時。
incomplete：Peering過程中由於無法選出權威日誌或者通過choos_acting選出的acting不足以完成資料恢復，（例如針對糾刪碼，存活的副本數小於k值）等，導致Peering無法正常完成。即pg後設資料丟失，無法恢復pg狀態。（ceph-objectstore-tool工具可以調整此狀態pg為complete）

noscrub 和 nodeep-scrub
- noscrub：資料輕量掃描，主要檢查後設資料資訊是否一致，若不一致則會進行同步，一般為一天進行一次比對，預設開啟。
- nodeep-scrub：資料深度掃描，對所有資料的全量掃描，包括後設資料、object等，一般一週進行一次，預設開啟。
資料校驗時會導致讀壓力增大，如果掃描出資料不一致還要進行同步寫，增大寫的壓力，因此在做擴容等操作的時候，我們會人為去設定noscrub與nodeep-scrub，暫停資料校驗。檢視pool是否開啟清洗：
```
$ ceph osd pool get replicapool noscrub
noscrub: false
$ ceph osd pool get replicapool nodeep-scrub
nodeep-scrub: false
```

資料壓縮

如果使用 BlueStore 儲存引擎，ceph 支援稱為 "實時資料壓縮" 即邊壓縮邊儲存資料的功能，該功能有助於節省磁碟空間，可以在BlueStore OSD上建立的每個儲存池池上啟用或禁用壓縮，以節約磁碟空間，預設沒有開啟壓縮，需要後期配置並開啟：

## 開啟壓縮功能
$ ceph osd pool set <pool name> compression_algorithm <壓縮演算法> 
演算法介紹：
  sanppy：預設演算法，消耗cpu較少
  zstd：壓縮比好，但消耗 CPU
  lz4：消耗cpu較少
  zlib：不推薦
  
$ ceph osd pool set replicapool compression_algorithm snappy
set pool 2 compression_algorithm to snappy

## 指定壓縮模式
$ ceph osd pool set <pool name> compression_mode <指定模式>
模式介紹：
  none:從不壓縮資料，預設值。
  passive:除非寫操作具有可壓縮的提示集，否則不要壓縮資料。
  aggressive:壓縮資料，除非寫操作具有不可壓縮的提示集。
  force:無論如何都嘗試壓縮資料，即使客戶端暗示資料不可壓縮也會壓縮，也就是在所有情況下都使用壓縮

$ ceph osd pool set replicapool compression_mode passive
set pool 2 compression_mode to passive

全域性壓縮選項，這些可以配置到 ceph.conf 中，作用於所有儲存池：

bluestore_compression_algorithm #壓縮演算法
bluestore_compression_mode      #壓縮模式
bluestore_compression_required_ratio #壓縮後與壓縮前的壓縮比，預設為.875
bluestore_compression_min_blob_size  #小於它的塊不會被壓縮,預設0
bluestore_compression_max_blob_size  #大於它的塊在壓縮前會被拆成更小的塊,預設 0
bluestore_compression_min_blob_size_ssd #預設 8k
bluestore_compression_max_blob_size_ssd #預設 64k
bluestore_compression_min_blob_size_hdd #預設 128k
bluestore_compression_max_blob_size_hdd #預設 512k

此功能開啟會影響cpu的使用率，如果環境為生產環境，不建議開啟此功能。

ceph叢集管理命令

儲存池基本管理

建立儲存池，格式示例

$ ceph osd pool create <poolname> pg_num pgp_num {replicated|erasure}

$ ceph osd pool create study 8 8 
pool 'study' created

列出儲存池

$ ceph osd lspools
1 .rgw.root
2 study

重新命名儲存池，格式示例

$ ceph osd pool rename old-name new-name 

$ ceph osd pool rename study re-study
pool 'study' renamed to 're-study'

顯示儲存池用量資訊

$ rados df 
或者
$ ceph osd df

刪除儲存池

## 1、ceph為了防止儲存池被誤刪，故設定了兩個機制來保護，首先要將儲存池的nodelete標誌為false
$ ceph osd pool set re-study nodelete false
set pool 13 nodelete to true
$ ceph osd pool get re-study nodelete
nodelete: false

## 2、第二個機制，要將mon設定為允許刪除--mon-allow-pool-delete=true
$ ceph tell mon.* injectargs --mon-allow-pool-delete=true 
injectargs:mon_allow_pool_delete = 'true' 

## 3、開始刪除，要寫兩邊儲存池的名字，並加引數--yes-i-really-really-mean-it
$ ceph osd pool rm re-study re-study --yes-i-really-really-mean-it
pool 're-study' removed

儲存池配額

儲存池可以設定兩個配對儲存的物件進行限制，一個配額是最大空間(max_bytes)，另外一個配額是物件最大數量(max_objects)，預設不會限制，例如：

## 檢視replicapool儲存池的配額情況，N/A表示不限制
$ ceph osd pool get-quota replicapool 
quotas for pool 'replicapool':
  max objects: N/A
  max bytes  : N/A
  
## 限制最大物件數為1000，最大byte為1000000000
$ ceph osd pool set-quota replicapool max_objects 1000
set-quota max_objects = 1000 for pool replicapool

$ ceph osd pool set-quota replicapool max_bytes 1000000000
set-quota max_bytes = 1000000000 for pool replicapool

$ ceph osd pool get-quota replicapool 
quotas for pool 'replicapool':
  max objects: 1k objects
  max bytes  : 954 MiB
  
## 可以再設定為不限額
$ ceph osd pool set-quota replicapool max_bytes 0

儲存池常用引數

檢視儲存池物件副本數和最小副本數

$ ceph osd pool get replicapool size
size: 1

$ ceph osd pool get replicapool min_size 
min_size: 1

min_size：提供服務所需要的最小副本數，預設為2，表示如果一個3副本的儲存池，其中一個副本所在的osd壞掉了，那麼還剩兩副本，可以正常工作，但如果再壞掉一個，只剩下一個副本，則此儲存池不能正常提供服務。

檢視儲存池pg、pgp數量

$ ceph osd pool get replicapool pg_num 
pg_num: 32

$ ceph osd pool get replicapool pgp_num 
pgp_num: 32

控制是否可以更改儲存池的pg、pgp、儲存大小

$ ceph osd pool get replicapool nopgchange
nopgchange: false

$ ceph osd pool get replicapool nosizechange
nosizechange: false

輕量掃描和深層掃描管理

## 關閉輕量掃描和深層掃描
$ ceph osd pool set replicapool noscrub true
$ ceph osd pool set replicapool nodeep-scrub true

## 掃描的最小與最大間隔時間，預設沒設定，如果需要，則要在配置檔案中指定
osd_scrub_min_interval xxx
osd_scrub_max_interval xxx
osd_deep_scrub_interval xxx

ceph osd預設配置檢視

$ ceph daemon osd.1 config show | grep scrub

ceph叢集
2024-08-25
cephadm訪問ceph叢集的方式及管理員節點配置案例
2024-08-22
ceph叢集的OSD管理基礎及OSD節點擴縮容
2024-08-21
Redis Manager 叢集管理與節點管理
2018-12-15
Redis
管理 ES 叢集：叢集與外部間的安全通訊
2020-02-16
ceph-deploy離線部署ceph叢集及報錯解決FAQ
2022-02-28
手把手教你使用rpm部署ceph叢集
2020-11-14
kubernets1.13.1叢集使用ceph rbd塊儲存
2021-09-09
ceph叢集常用命令精華彙總!
2020-11-06
CEPH-2：rbd功能詳解及普通使用者應用ceph叢集
2022-03-29
管理 ES 叢集：管叢集身份認證與使用者鑑權
2020-02-16
為K8S叢集準備Ceph儲存
2023-02-15
K8S
ceph叢集手動部署（後期新增mon和osd）
2020-10-30
docker筆記41-ceph叢集的日常運維
2018-10-29
Docker筆記運維
LightDB canopy叢集管理
2023-02-15
KunlunDB叢集管理介面
2022-04-07
Ceph Reef(18.2.X)的內建Prometheus監控叢集
2024-08-25
Prometheus
管理 ES 叢集：Hot & Warm 架構與 Shard Filtering
2020-02-19
架構Filter
管理 ES 叢集：集常見的叢集部署方式
2020-02-18
[自動化]基於kolla的自動化部署ceph叢集
2022-02-28
kubernetes叢集管理命令(三)
2019-06-20
管理 ES 叢集：叢集內部間的安全通訊
2020-02-16
管理 ES 叢集：如何對叢集進行容量規劃
2020-02-20
Ceph分散式叢集部署
2020-12-19
分散式
kubernetes與web叢集
2018-12-13
Web
踩坑日誌--CEPH叢集常見問題解決辦法
2020-11-06
Oracle叢集軟體管理-新增和刪除叢集節點
2020-03-19
Oracle
管理 ES 叢集：分片設定及管理
2020-02-20
ElasticSearch 叢集基本概念及常用操作彙總（建議收藏）
2020-11-10
Elasticsearch
在 Minecraft 中管理 Kubernetes 叢集
2020-10-12
Raft
Elasticsearch——叢集管理及文件CRUD
2019-01-26
Elasticsearch
Ubuntu22.04LTS基於cephadm快速部署Ceph Reef(18.2.X)叢集
2024-08-21
Ubuntu
Redis叢集與高可用
2024-07-19
Redis
golang分散式與叢集
2021-12-22
Golang分散式
Ceph 管理和使用
2021-08-24
K8S安全學習之叢集搭建&基本概念理解
2022-03-25
K8S
ray-分散式計算框架-叢集與非同步Job管理
2023-04-25
分散式框架非同步
MySQL DB 叢集管理平臺--orchestrator
2024-09-25
MySql

CEPH-5：ceph叢集基本概念與管理

ceph叢集基本概念與管理

ceph叢集基本概念

ceph叢集管理命令

相關文章