Ceph是一個可靠地、自動重均衡、自動恢復(fù)的分布式存儲系統(tǒng)，根據(jù)場景劃分可以將Ceph分為三大塊，分別是對象存儲、塊設(shè)備存儲和文件系統(tǒng)服務(wù)。在虛擬化領(lǐng)域里，比較常用到的是Ceph的塊設(shè)備存儲，比如在OpenStack項目里，Ceph的塊設(shè)備存儲可以對接OpenStack的cinder后端存儲、Glance的鏡像存儲和虛擬機的數(shù)據(jù)存儲，比較直觀的是Ceph集群可以提供一個raw格式的塊存儲來作為虛擬機實例的硬盤。
Ceph相比其它存儲的優(yōu)勢點在于它不單單是存儲，同時還充分利用了存儲節(jié)點上的計算能力，在存儲每一個數(shù)據(jù)時，都會通過計算得出該數(shù)據(jù)存儲的位置，盡量將數(shù)據(jù)分布均衡，同時由于Ceph的良好設(shè)計，采用了CRUSH算法、HASH環(huán)等方法，使得它不存在傳統(tǒng)的單點故障的問題，且隨著規(guī)模的擴大性能并不會受到影響。
企業(yè)在實際Ceph遇到的五大問題：
一、擴容問題
Ceph中數(shù)據(jù)以PG為單位進行組織，因此當(dāng)數(shù)據(jù)池中加入新的存儲單元（OSD）時，通過調(diào)整OSDMAP會帶來數(shù)據(jù)重平衡。正如提到的，如果涉及到多個OSD的擴容是可能導(dǎo)致可用PG中OSD小于min_size，從而發(fā)生PG不可用、IO阻塞的情況。為了盡量避免這種情況的出現(xiàn)，只能將擴容粒度變小，比如每次只擴容一個OSD或者一個機器、一個機柜（主要取決于存儲隔離策略），但是這樣注定會帶來極大的運維工作量，甚至連擴容速度可能都趕不上數(shù)據(jù)增長速度。
二、數(shù)據(jù)遷移過程中的IO爭用問題
在頻繁數(shù)據(jù)遷移過程中帶來的IO爭用問題。當(dāng)集群規(guī)模變大后，硬盤損壞、PG數(shù)量擴充可能會變得常態(tài)化。
三、PG數(shù)量調(diào)整問題
在解決了數(shù)據(jù)遷移過程中的PG可用性問題和IO爭用問題后，提到的PG數(shù)量調(diào)整問題自然也就解決了。
四、集群利用率問題
存儲成本問題主要是講集群可用率問題，即：Ceph集群規(guī)模增大后，偽隨機算法導(dǎo)致了存儲資源分布不均衡，磁盤利用率方差過大的問題。
五、運維復(fù)雜度問題
Ceph本身是一個十分復(fù)雜的體系，要做到穩(wěn)定運維非?？粗貓F隊的實力。
以下是一些典型問題解答，歡迎參考：
1、PG和PGP的區(qū)別是什么？調(diào)整PGP會不會引起PG內(nèi)的對象的分裂？
Lucien168：
首先來一段英文關(guān)于PG和PGP區(qū)別的解釋：
PG=Placement Group
PGP=Placement Group for Placement purpose
pg_num=number of placement groups mapped to an OSD
When pg_num is increased for any pool,every PG of this pool splits into half,but they all remain mapped to their parent OSD.
Until this time,Ceph does not start rebalancing.Now,when you increase the pgp_num value for the same pool,PGs start to migrate from the parent to some other OSD,and cluster rebalancing starts.This is how PGP plays an important role.
By Karan Singh
以上是來自郵件列表的Karan Singh的PG和PGP的相關(guān)解釋，他也是Learning Ceph和Ceph Cookbook的作者，以上的解釋沒有問題，我們來看下具體在集群里面具體作用：
PG是指定存儲池存儲對象的目錄有多少個，PGP是存儲池PG的OSD分布組合個數(shù)
PG的增加會引起PG內(nèi)的數(shù)據(jù)進行分裂，分裂到相同的OSD上新生成的PG當(dāng)中
PGP的增加會引起部分PG的分布進行變化，但是不會引起PG內(nèi)對象的變動
寧澤陽：
我的理解是pgp用于承載pg，建議保持pg和pgp一致，調(diào)整pg數(shù)目時會進行pg內(nèi)對象分裂，調(diào)整pgp時會引起pg重分布。
zhuqibs：
（1）PG是指定存儲池存儲對象的目錄有多少個，PGP是存儲池PG的OSD分布組合個數(shù)
（2）PG的增加會引起PG內(nèi)的數(shù)據(jù)進行分裂，分裂到相同的OSD上新生成的PG當(dāng)中
（3）PGP的增加會引起部分PG的分布進行變化，但是不會引起PG內(nèi)對象的變動
2、多節(jié)點組成Ceph存儲集群后，時間如何同步？
寧澤陽：
集群內(nèi)配置ntp服務(wù)器，其他節(jié)點從這里同步時間即可。或者集群配置公司通用的ntp服務(wù)器也可以，如果有的話。
wzpystcdc：
每臺服務(wù)器開啟NTP服務(wù)進行同步
Lucien168：
通過ntp然后進行監(jiān)控，如果不同步，集群也會出現(xiàn)告警提示。
zhuqibs：
集群節(jié)點的時間同步，是傳統(tǒng)的ntp服務(wù)
3、當(dāng)Ceph集群存儲容量快接近水位，擴容一次擴多少節(jié)點合適？
寧澤陽：
建議結(jié)合業(yè)務(wù)需求來進行擴容，覆蓋業(yè)務(wù)需求后容量使用情況在50%左右為宜，即可以避免大量空間冗余浪費，也可以避免頻繁擴容。
zhuqibs：
缺省的水位線在85%~95%,生產(chǎn)中一般將其改到70%~80%，一旦達到一個區(qū)間，就可以考慮擴容了，節(jié)點數(shù)量要根據(jù)你一年內(nèi)數(shù)據(jù)量增加的預(yù)估來計算
Lucien168：
設(shè)置好水位線一般70%以內(nèi)，然后進行擴容，擴容的時候會有數(shù)據(jù)發(fā)送遷移，控制好集群內(nèi)數(shù)據(jù)遷移的大小，避免遷移量太大，影響客戶端io請求延遲。
大黑兔愛吃魚：
主要和集群規(guī)模及單節(jié)點容量有關(guān)，最好在百分之60左右開始擴容，單個節(jié)點方式逐步增加，待數(shù)據(jù)平衡完成后在進行下一個節(jié)點，這樣影響較小，比較安全。
4、調(diào)整pg數(shù)量有什么問題需要注意，會有什么影響，怎樣提前規(guī)劃好？
【問題描述】前期由于存儲容量和集群規(guī)模不大，設(shè)置的pg數(shù)量也比較小，后期由于集群規(guī)模變大，勢必需要調(diào)整pg數(shù)量，調(diào)整pg數(shù)量有什么問題需要注意，會有什么影響，怎樣提前規(guī)劃好？
寧澤陽：
調(diào)整pg數(shù)目時會發(fā)生大量pg分裂遷移，建議在業(yè)務(wù)低峰期進行并做好恢復(fù)帶寬限制。如果集群不能一次規(guī)劃建設(shè)到位的話建議按照官方算法按照每次擴容完成后的總osd數(shù)目進行調(diào)整以獲得最佳配比。
zhuqibs：
（1）預(yù)設(shè)Ceph集群中的PG數(shù)至關(guān)重要，公式如下:
PG總數(shù)=(OSD數(shù)100)/最大副本數(shù)
（2）集群中單個池的PG數(shù)計算公式如下
PG總數(shù)=(OSD數(shù)100)/最大副本數(shù)/池數(shù)
Lucien168：
pg數(shù)量，一般都是按照pool的容量進行規(guī)劃設(shè)置的。官方也有相關(guān)計算器，一般推進一個osd大概100個osd左右進行評估設(shè)置。pg數(shù)量設(shè)置不好會影響數(shù)據(jù)均衡，影響性能。需要提前規(guī)劃好。
5、Ceph擴容后，集群內(nèi)數(shù)據(jù)遷移量過大，怎樣不影響用戶IO阻塞？
寧澤陽：
可以限制重平衡的io數(shù)目和重平衡的io帶寬減少對正常業(yè)務(wù)io的影響，或者只在業(yè)務(wù)低峰期打開重平衡。
zhuqibs：
降低recovery的I/O優(yōu)先級，使得Client IO優(yōu)先
djl2020：
通過對數(shù)據(jù)遷移進行時間和流量上的雙重QOS策略來保證線上業(yè)務(wù)穩(wěn)定運行。
Lucien168：
集群內(nèi)部流量遷移進行速率的控制，優(yōu)先保證客戶端io請求流量。
6、集群規(guī)模增大后，偽隨機算法導(dǎo)致存儲資源分布不均衡，磁盤利用率方差過大，怎樣保證數(shù)據(jù)數(shù)據(jù)均衡，集群的利用率最大化？
寧澤陽：
首先是要控制存儲的分配情況，避免超分比過多，如果單個磁盤使用過多時，建議優(yōu)先進行集群的整體擴容，將整體使用率降下來，使用率較低時集群的穩(wěn)定性會更好。如果是在開發(fā)測試環(huán)境這種不太重要的用途上，可以配置osd定期自動reweight來重平衡osd的使用情況。
zhuqibs：
頻繁的調(diào)整osd的權(quán)重是不可取的，必須要做好規(guī)劃，對數(shù)據(jù)規(guī)模進行必要的預(yù)估。
djl2020：
在集群部署階段，對業(yè)務(wù)的數(shù)據(jù)規(guī)模進行預(yù)估，調(diào)整osd的權(quán)重，減少數(shù)據(jù)量增加后，集群各個硬盤的使用率差值。在業(yè)務(wù)上限后，定期做好巡檢，根據(jù)業(yè)務(wù)調(diào)整數(shù)據(jù)均衡。
Lucien168：
一般這種情況，建議做個均衡插件，定期進行均衡設(shè)置，控制好均衡算法。
7、ceph集群擴容前要做哪些準備工作，如何確保擴容過程對業(yè)務(wù)影響最小？
寧澤陽：
建議在規(guī)劃存儲池時對存儲池的規(guī)模容量做好規(guī)劃，一次建設(shè)完成，以避免對現(xiàn)有存儲池的擴容，現(xiàn)有存儲池擴容時會發(fā)生大量的數(shù)據(jù)遷移，遷移整體耗時會較長，如果必須擴容的話，可以提前評估業(yè)務(wù)低峰窗口，并限制數(shù)據(jù)平衡速率，在擴容完成后根據(jù)osd數(shù)目調(diào)整pg數(shù)目，減少對業(yè)務(wù)io的影響。
zhuqibs：
crushmap改變導(dǎo)致的Ceph rebalance，所以整體IO的下降（磁盤IO被反復(fù)的rebalance占滿），甚至是某些數(shù)據(jù)暫時不可用。所以要在業(yè)務(wù)量較少的時間段進行擴容
djl2020：
1.評估業(yè)務(wù)類型，根據(jù)業(yè)務(wù)關(guān)聯(lián)性區(qū)分池內(nèi)擴容和整池擴容。
2.評估業(yè)務(wù)模型特點，規(guī)避業(yè)務(wù)高峰期進行擴容和數(shù)據(jù)恢復(fù)。
3.評估線上業(yè)務(wù)流量和集群的性能，在擴容后對數(shù)據(jù)均衡進行流量控制。
Lucien168：
擴容前，需要評估內(nèi)部集群數(shù)據(jù)的遷移量，做好集群內(nèi)部流量遷移的限速，避免遷移量太大，影響客戶端io請求。
8、機器死機，如何不影響用戶請求io，并且盡量讓集群內(nèi)部數(shù)據(jù)遷移量最小化，影響最??？
寧澤陽：
死機后禁止數(shù)據(jù)恢復(fù)和數(shù)據(jù)重平衡，機器恢復(fù)后再打開數(shù)據(jù)平衡，此時不會影響pg和osd的映射關(guān)系，因此不會發(fā)生大量數(shù)據(jù)遷移，只會對舊數(shù)據(jù)進行追數(shù)更新，整個過程中都是不影響用戶io的。
djl2020：
設(shè)置集群維護模式，設(shè)置集群osd no-out，no-recovery,no-backfill；當(dāng)有主機或OSD下線時，osd不會自動out，不會發(fā)生數(shù)據(jù)遷移，當(dāng)主機恢復(fù)后，取消no-recovery和no-backfill，集群只會對增量數(shù)據(jù)進行recovery和backfill，減少數(shù)據(jù)遷移量。
Lucien168：
設(shè)置集群為維護模式，避免有數(shù)據(jù)遷移的發(fā)生，盡快恢復(fù)死機的機器，重新拉起osd起來。
9、osd龜速、無響應(yīng)，會是哪些方面的問題？
寧澤陽：
檢查下集群是否存在slow request，如果存在的話可以看一下集中在哪些osd，這些osd是否硬盤故障或者網(wǎng)絡(luò)中斷，將這些osd踢出集群是否可以恢復(fù)。
Lucien168：
一個反復(fù)出現(xiàn)的問題是OSD龜速或無響應(yīng)。在深入性能問題前，你應(yīng)該先確保不是其他故障。例如，確保你的網(wǎng)絡(luò)運行正常、且OSD在運行，還要檢查OSD是否被恢復(fù)流量拖住了。
Tip：較新版本的Ceph能更好地處理恢復(fù)，可防止恢復(fù)進程耗盡系統(tǒng)資源而導(dǎo)致up且in的OSD不可用或響應(yīng)慢。
網(wǎng)絡(luò)問題
Ceph是一個分布式存儲系統(tǒng)，所以它依賴于網(wǎng)絡(luò)來互聯(lián)OSD們、復(fù)制對象、從錯誤中恢復(fù)和檢查心跳。網(wǎng)絡(luò)問題會導(dǎo)致OSD延時和震蕩（反復(fù)經(jīng)歷up and down，詳情可參考下文中的相關(guān)小節(jié)）。
確保Ceph進程和Ceph依賴的進程已建立連接和/或在監(jiān)聽。
netstat-a|grep ceph
netstat-l|grep ceph
sudo netstat-p|grep ceph
檢查網(wǎng)絡(luò)統(tǒng)計信息。
netstat-s
zhuqibs：
不太明白，是什么行為的慢
（1）io慢，分布式存儲的寫，必然比單盤慢，因為有多副本，有網(wǎng)絡(luò)傳輸時間；使用ssd盤，采用高速網(wǎng)絡(luò)，是解決之道；
（2）如果是load balance慢，那就是單看網(wǎng)絡(luò)了；
其他，需要很多的參數(shù)調(diào)優(yōu)
10、osd啟動報錯了，應(yīng)該從哪幾個方面診斷排錯?
寧澤陽：
一般報錯的提示都是比較明晰的，按照提示處理就可以了。
Lucien168：
首先看報什么錯誤，然后根據(jù)問題，找對應(yīng)的解決方案，一般網(wǎng)上都有對應(yīng)的解決方案。最后，搞不定把詳細的步驟和日志，帖到社區(qū)。
zhuqibs：
原因太多了，主要工具就是看日志：
（1）文件系統(tǒng)的問題；
（2）認證的問題；
（3）osd狀態(tài)不對；
（4）osd資源問題
……
11、如何用邏輯卷做OSD？
寧澤陽：
用邏輯卷，物理卷或者文件來做osd都可以，流程都是一致的。
zhuqibs：
使用bluestore
（1)創(chuàng)建邏輯卷
vgcreate cache/dev/sdb lvcreate--size 100G--name db-lv-0 cache
vgcreate cache/dev/sdb lvcreate--size 100G--name wal-lv-0 cache
(2)創(chuàng)建OSD
ceph-deploy osd create--bluestore storage1--data/dev/sdc--block-db cache/db-lv-0--block-wal cache/wal-lv-0
ceph-deploy osd create--bluestore storage2--data/dev/sdc--block-db cache/db-lv-0--block-wal cache/wal-lv-0
ceph-deploy osd create--bluestore storage3--data/dev/sdc--block-db cache/db-lv-0--block-wal cache/wal-lv-0
12、Ceph啟動報錯：Error ENOENT:osd.2 does not exist.create it before updating the crush map
寧澤陽：
crushmap和實際osd對不上，實際沒有osd2，卻在crushmap里出現(xiàn)了，需要更新下crushmap或者創(chuàng)建下osd2。
Lucien168：
提示很清楚，根據(jù)提示多檢查步驟。
zhuqibs：
都說了osd不存在，創(chuàng)建一個唄
/usr/local/bin/ceph osd create
13、ceph報錯，RuntimeError:Failed to connect any mon？
寧澤陽：
該節(jié)點和monitor節(jié)點網(wǎng)絡(luò)通訊異常的概率比較大，可以測一下到monitor的端口通不通。
Lucien168：
ping mon地址，檢查mon日志，是否有錯誤日志。
zhuqibs：
無法和monitor通訊，檢查monitor的工作狀態(tài)
14、客戶端反饋ceph存儲讀寫緩慢排查思路是怎么樣的？
寧澤陽：
從存儲端-網(wǎng)絡(luò)端-客戶端逐層排查。首先確認慢是普遍慢還是個別客戶端慢，個別客戶端的負載如何，到存儲端的網(wǎng)絡(luò)路徑和其他客戶端相比如何，存儲端是否有網(wǎng)絡(luò)打滿的情況，是否有不健康的磁盤，可以按照這種思路逐個去排查。
zhuqibs：
1、OSD請求緩慢的主要原因是：
a、底層硬件的問題，例如磁盤驅(qū)動器，主機，機架或網(wǎng)絡(luò)交換機。
b、網(wǎng)絡(luò)問題。這些問題通常與flapping OSD有關(guān)。
c、系統(tǒng)負載。
2、使用dump_historic_ops administration socket命令確定慢速請求的類型
3、使用ceph osd perf確定慢速磁盤
Lucien168：
這種情況，一般去查看集群端，是否存在slow request請求的日志，如果有相關(guān)的慢請求日志，跟進日志分析問題，看看是否是某塊盤出現(xiàn)問題。
15、ceph如何進行監(jiān)控體系建設(shè)從而更快的進行故障恢復(fù)？
寧澤陽：
首先是需要對事件和日志進行監(jiān)控，同時需針對關(guān)鍵metric進行監(jiān)控記錄，事件及日志一般用于集群不可用的告警，metric主要用于提升存儲系統(tǒng)性能，并發(fā)現(xiàn)潛在的性能隱患。推薦使用prometheus+grafana進行監(jiān)控，官方是有ceph的exporter可以參考的。
zhuqibs：
all-in-kubenetes，我們公司就用Prometheus+grafana把監(jiān)控全包了，監(jiān)控需要統(tǒng)一，工具太多，未必是好事。
Lucien168：
ceph監(jiān)控目前主流的Ceph開源監(jiān)控軟件有：Calamari、VSM、Inkscope、Ceph-Dash、Zabbix等，下面簡單介紹下各個開源組件。也可以自己定制化開發(fā)。
監(jiān)控指標(biāo)按照等級進行劃分，設(shè)置相關(guān)的故障自愈等相關(guān)的措施。
16、ceph如何進行性能優(yōu)化？
寧澤陽：
從硬件配置選擇，到bios-raid-os-ceph各層配置均按照社區(qū)建議方案進行調(diào)整，如果時間允許，可以對各參數(shù)進行壓測以獲得最佳配置。
zhuqibs：
硬件層面
a、硬件規(guī)劃
b、SSD選擇
c、BIOS設(shè)置
軟件層面
a、Linux OS
b、Ceph Configurations
c、PG Number調(diào)整
d、CRUSH Map
e、其他因素
Lucien168：
系統(tǒng)層面優(yōu)化內(nèi)核參數(shù)
客戶端緩存
服務(wù)端緩存
調(diào)優(yōu)隊列大小等各種參數(shù)
ntzs：
性能優(yōu)化從底層硬件、網(wǎng)絡(luò)、操作系統(tǒng)、軟件參數(shù)、緩存等幾方面
一、硬件：選用ceph合適的硬件。盡量增加SSD，合理分配到pool和index
二、網(wǎng)絡(luò)：1.增加收發(fā)包ethtool-G eth4 rx 8192 tx 8192
2.增加網(wǎng)絡(luò)帶寬，區(qū)分集群內(nèi)外網(wǎng)絡(luò)
三、操作系統(tǒng)：1.調(diào)整包echo"8192”>/sys/block/sda/queue/read_ahead_kb
2.減少swap使用vm.swappiness=5
四、軟件:
1.RGW（對象存儲）
rgw_cache_enabled=true#開啟RGW cache
rgw_thread_pool_size=2000
rgw_cache_lru_size=20000
rgw_num_rados_handles=128
2.RBD（塊存儲）
rbd_cache_enabled=true#開啟RBD cache
rbd_cache_size=268435456
rbd_cache_max_dirty=134217728
rbd_cache_max_dirty_age=5
3.優(yōu)化OSD scrub周期及相關(guān)參數(shù)
osd scrub begin hour=4
osd scrub end hour=12
osd scrub chunk min=5
osd scrub chunk max=5
osd scrub sleep=1（不建議增大太多，會延長scrub完成時間）
osd scrub min interval=2592000
osd scrub max interval=2592000
osd deep scrub interval=2419200
osd scrub load threshold=0.30
osd scrub during recovery=false
osd scrub priority=5
osd scrub interval randomize ratio=0.35
五、緩存：增加磁盤緩存到SSD上（有版本要求）ceph-volume lvmcache add
17、如何發(fā)現(xiàn)和解決關(guān)鍵的存儲問題？
【問題描述】Ceph分為三大塊，分別是對象存儲、塊設(shè)備存儲和文件系統(tǒng)服務(wù)。在實際運營中，如何發(fā)現(xiàn)和解決關(guān)鍵的存儲問題？尤其是隨著規(guī)模的擴大與業(yè)務(wù)的幾何級數(shù)的擴張，存在運維中不可預(yù)測的問題，如何提前預(yù)判和防治？
寧澤陽：
規(guī)模擴大和業(yè)務(wù)擴張是一個過程，在這個過程中建議加強對網(wǎng)絡(luò)和磁盤IO這些容易出現(xiàn)問題的點的監(jiān)控并進行歷史趨勢分析，從趨勢中發(fā)現(xiàn)性能容量的瓶頸，并盡量將瓶頸提前消滅掉。
zhuqibs：
不可預(yù)知的問題，要解決豈不是先知。
（1）全方位的監(jiān)控是解決問題的問題的其中之一方法，thanos+Prometheus+grafana能同時監(jiān)控很多kubenetes集群；
（2）可靠高速的網(wǎng)絡(luò)，大部分ceph問題都是由網(wǎng)絡(luò)引起的，ceph性能不僅靠磁盤性能，更靠高速的網(wǎng)絡(luò)。
（3）kubenetes的自愈功能，kubenetes考慮了一部分的自愈功能
lhs0981101410：
加強日常的巡檢
Daniel1111：
規(guī)模擴大和業(yè)務(wù)擴張需要關(guān)注存儲節(jié)點資源的消耗，除了CPU、MEM、Disk io util、NIC throughout，還需要關(guān)注FD文件句柄數(shù)、進程和線程數(shù)、端口占用數(shù)等。此外慢盤、慢節(jié)點也更容易出現(xiàn)，需要人工處理或者實現(xiàn)自動化。
