1. PG介紹

這次主要來(lái)分享Ceph中的PG各種狀態(tài)詳解，PG是最復(fù)雜和難于理解的概念之一，PG的復(fù)雜如下： 

- 在架構(gòu)層次上，PG位于RADOS層的中間。 

a. 往上負(fù)責(zé)接收和處理來(lái)自客戶端的請(qǐng)求。

b. 往下負(fù)責(zé)將這些數(shù)據(jù)請(qǐng)求翻譯為能夠被本地對(duì)象存儲(chǔ)所能理解的事務(wù)。

- 是組成存儲(chǔ)池的基本單位，存儲(chǔ)池中的很多特性，都是直接依托于PG實(shí)現(xiàn)的。 

- 面向容災(zāi)域的備份策略使得一般而言的PG需要執(zhí)行跨節(jié)點(diǎn)的分布式寫，因此數(shù)據(jù)在不同節(jié)點(diǎn)之間的同步、恢復(fù)時(shí)的數(shù)據(jù)修復(fù)也都是依賴PG完成。

2. PG狀態(tài)表

正常的PG狀態(tài)是 100%的active + clean， 這表示所有的PG是可訪問的，所有副本都對(duì)全部PG都可用。 如果Ceph也報(bào)告PG的其他的警告或者錯(cuò)誤狀態(tài)。PG狀態(tài)表：

3. 狀態(tài)詳解及故障模擬復(fù)現(xiàn)

3.1 Degraded

3.1.1 說(shuō)明

降級(jí)：由上文可以得知，每個(gè)PG有三個(gè)副本，分別保存在不同的OSD中，在非故障情況下，這個(gè)PG是active+clean 狀態(tài)，那么，如果PG 的 副本osd.4 掛掉了，這個(gè) PG 是降級(jí)狀態(tài)。

3.1.2 故障模擬

• 停止osd.1 $ systemctl stop ceph-osd@1
• 查看PG狀態(tài) $ bin/ceph pg stat 20 pgs: 20 active+undersized+degraded; 14512 kB data, 302 GB used, 6388 GB / 6691 GB avail; 12/36 objects degraded (33.333%)
• 查看集群監(jiān)控狀態(tài)

• 客戶端IO操作

故障總結(jié)：

為了模擬故障，(size = 3, min_size = 2) 我們手動(dòng)停止了 osd.1，然后查看PG狀態(tài)，可見，它此刻的狀態(tài)是active+undersized+degraded,當(dāng)一個(gè) PG 所在的 OSD 掛掉之后，這個(gè) PG 就會(huì)進(jìn)入undersized+degraded 狀態(tài)，而后面的[0,2]的意義就是還有兩個(gè)副本存活在 osd.0 和 osd.2 上, 并且這個(gè)時(shí)候客戶端可以正常讀寫IO。

3.1.3 總結(jié)

• 降級(jí)就是在發(fā)生了一些故障比如OSD掛掉之后，Ceph 將這個(gè) OSD 上的所有 PG 標(biāo)記為 Degraded。
• 降級(jí)的集群可以正常讀寫數(shù)據(jù)，降級(jí)的 PG 只是相當(dāng)于小毛病而已，并不是嚴(yán)重的問題。
• Undersized的意思就是當(dāng)前存活的PG 副本數(shù)為 2，小于副本數(shù)3，將其做此標(biāo)記，表明存貨副本數(shù)不足，也不是嚴(yán)重的問題。

3.2 Peered

3.2.1 說(shuō)明

• Peering已經(jīng)完成，但是PG當(dāng)前Acting Set規(guī)模小于存儲(chǔ)池規(guī)定的最小副本數(shù)(min_size)。

3.2.2 故障模擬

a. 停掉兩個(gè)副本osd.1,osd.0

$ systemctl stop ceph-osd@1 $ systemctl stop ceph-osd@0 

b. 查看集群健康狀態(tài)

c. 客戶端IO操作(夯住) 

讀取對(duì)象到文件，夯住IO

$ bin/rados -p test_pool get myobject ceph.conf.old 

故障總結(jié)：

- 現(xiàn)在pg 只剩下osd.2上存活，并且 pg 還多了一個(gè)狀態(tài)：peered，英文的意思是仔細(xì)看，這里我們可以理解成協(xié)商、搜索。

- 這時(shí)候讀取文件，會(huì)發(fā)現(xiàn)指令會(huì)卡在那個(gè)地方一直不動(dòng)，為什么就不能讀取內(nèi)容了，因?yàn)槲覀冊(cè)O(shè)置的 min_size=2 ，如果存活數(shù)少于2，比如這里的 1 ，那么就不會(huì)響應(yīng)外部的IO請(qǐng)求。

d. 調(diào)整min_size=1可以解決IO夯住問題

設(shè)置min_size = 1

$ bin/ceph osd pool set test_pool min_size 1 set pool 1 min_size to 1 

e. 查看集群監(jiān)控狀態(tài)

f. 客戶端IO操作

讀取對(duì)象到文件中

$ ll -lh ceph.conf* -rw-r--r-- 1 root root 6.1K Jun 25 14:01 ceph.conf -rw-r--r-- 1 root root 6.1K Jul 3 20:11 ceph.conf.old -rw-r--r-- 1 root root 6.1K Jul 3 20:11 ceph.conf.old.1 

故障總結(jié)：

- 可以看到，PG狀態(tài)Peered沒有了，并且客戶端文件IO可以正常讀寫了。

- 當(dāng)min_size=1時(shí)，只要集群里面有一份副本活著，那就可以響應(yīng)外部的IO請(qǐng)求。

3.2.3 總結(jié)

• Peered狀態(tài)我們這里可以將它理解成它在等待其他副本上線。
• 當(dāng)min_size = 2 時(shí)，也就是必須保證有兩個(gè)副本存活的時(shí)候就可以去除Peered這個(gè)狀態(tài)。
• 處于 Peered 狀態(tài)的 PG 是不能響應(yīng)外部的請(qǐng)求的并且IO被掛起。

3.3 Remapped

3.3.1 說(shuō)明

• Peering完成，PG當(dāng)前Acting Set與Up Set不一致就會(huì)出現(xiàn)Remapped狀態(tài)。

3.3.2 故障模擬

a. 停止osd.x

$ systemctl stop ceph-osd@x 

b. 間隔5分鐘，啟動(dòng)osd.x

$ systemctl start ceph-osd@x 

c. 查看PG狀態(tài)

d. 客戶端IO操作

rados讀寫正常

rados -p test_pool put myobject /tmp/test.log 

3.3.3 總結(jié)

在 OSD 掛掉或者在擴(kuò)容的時(shí)候PG 上的OSD會(huì)按照Crush算法重新分配PG 所屬的osd編號(hào)。并且會(huì)把 PG Remap到別的OSD上去。

Remapped狀態(tài)時(shí)，PG當(dāng)前Acting Set與Up Set不一致。

客戶端IO可以正常讀寫。

3.4 Recovery

3.4.1 說(shuō)明

指PG通過PGLog日志針對(duì)數(shù)據(jù)不一致的對(duì)象進(jìn)行同步和修復(fù)的過程。

3.4.2 故障模擬

a. 停止osd.x

$ systemctl stop ceph-osd@x 

b. 間隔1分鐘啟動(dòng)osd.x

osd$ systemctl start ceph-osd@x 

c. 查看集群監(jiān)控狀態(tài)

$ ceph health detail HEALTH_WARN Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degraded PG_DEGRADED Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degraded pg 1.19 is active+recovery_wait+degraded, acting [29,9,17] 

3.4.3 總結(jié)

Recovery是通過記錄的PGLog進(jìn)行恢復(fù)數(shù)據(jù)的。

記錄的PGLog 在osd_max_pg_log_entries=10000條以內(nèi)，這個(gè)時(shí)候通過PGLog就能增量恢復(fù)數(shù)據(jù)。

3.5 Backfill

3.5.1 說(shuō)明

• 當(dāng)PG的副本無(wú)非通過PGLog來(lái)恢復(fù)數(shù)據(jù)，這個(gè)時(shí)候就需要進(jìn)行全量同步，通過完全拷貝當(dāng)前Primary所有對(duì)象的方式進(jìn)行全量同步。

3.5.2 故障模擬

a. 停止osd.x

$ systemctl stop ceph-osd@x 

b. 間隔10分鐘啟動(dòng)osd.x

$ osd systemctl start ceph-osd@x 

c. 查看集群健康狀態(tài)

$ ceph health detail HEALTH_WARN Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degraded PG_DEGRADED Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degraded pg 3.7f is active+undersized+degraded+remapped+backfilling, acting [21,29] 

3.5.3 總結(jié)

無(wú)法根據(jù)記錄的PGLog進(jìn)行恢復(fù)數(shù)據(jù)時(shí)，就需要執(zhí)行Backfill過程全量恢復(fù)數(shù)據(jù)。

如果超過osd_max_pg_log_entries=10000條， 這個(gè)時(shí)候需要全量恢復(fù)數(shù)據(jù)。

3.6 Stale

3.6.1 說(shuō)明

• mon檢測(cè)到當(dāng)前PG的Primary所在的osd宕機(jī)。
• Primary超時(shí)未向mon上報(bào)pg相關(guān)的信息(例如網(wǎng)絡(luò)阻塞)。
• PG內(nèi)三個(gè)副本都掛掉的情況。

3.6.2 故障模擬

a. 分別停止PG中的三個(gè)副本osd, 首先停止osd.23

$ systemctl stop ceph-osd@23 

b. 然后停止osd.24

$ systemctl stop ceph-osd@24 

c. 查看停止兩個(gè)副本PG 1.45的狀態(tài)

d. 在停止PG 1.45中第三個(gè)副本osd.10

$ systemctl stop ceph-osd@10 

e. 查看停止三個(gè)副本PG 1.45的狀態(tài)

f. 客戶端IO操作

讀寫掛載磁盤IO 夯住

ll /mnt/ 

故障總結(jié)：

先停止同一個(gè)PG內(nèi)兩個(gè)副本，狀態(tài)是undersized+degraded+peered。

然后停止同一個(gè)PG內(nèi)三個(gè)副本，狀態(tài)是stale+undersized+degraded+peered。

3.6.3 總結(jié)

當(dāng)出現(xiàn)一個(gè)PG內(nèi)三個(gè)副本都掛掉的情況，就會(huì)出現(xiàn)stale狀態(tài)。

此時(shí)該P(yáng)G不能提供客戶端讀寫，IO掛起夯住。

Primary超時(shí)未向mon上報(bào)pg相關(guān)的信息(例如網(wǎng)絡(luò)阻塞),也會(huì)出現(xiàn)stale狀態(tài)。

3.7 Inconsistent

3.7.1 說(shuō)明

• PG通過Scrub檢測(cè)到某個(gè)或者某些對(duì)象在PG實(shí)例間出現(xiàn)了不一致

3.7.2 故障模擬

a. 刪除PG 3.0中副本osd.34頭文件

$ rm -rf /var/lib/ceph/osd/ceph-34/current/3.0_head/DIR_0/1000000697c.0000122c__head_19785300__3 

b. 手動(dòng)執(zhí)行PG 3.0進(jìn)行數(shù)據(jù)清洗

$ ceph pg scrub 3.0 instructing pg 3.0 on osd.34 to scrub 

c. 檢查集群監(jiān)控狀態(tài)

$ ceph health detail HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent OSD_SCRUB_ERRORS 1 scrub errors PG_DAMAGED Possible data damage: 1 pg inconsistent pg 3.0 is active+clean+inconsistent, acting [34,23,1] 

d. 修復(fù)PG 3.0

故障總結(jié)：

當(dāng)PG內(nèi)部三個(gè)副本有數(shù)據(jù)不一致的情況，想要修復(fù)不一致的數(shù)據(jù)文件，只需要執(zhí)行ceph pg repair修復(fù)指令，ceph就會(huì)從其他的副本中將丟失的文件拷貝過來(lái)就行修復(fù)數(shù)據(jù)。

3.7.3 故障模擬

• 當(dāng)osd短暫掛掉的時(shí)候，因?yàn)榧簝?nèi)還存在著兩個(gè)副本，是可以正常寫入的，但是 osd.34 內(nèi)的數(shù)據(jù)并沒有得到更新，過了一會(huì)osd.34上線了，這個(gè)時(shí)候osd.34的數(shù)據(jù)是陳舊的，就通過其他的OSD 向 osd.34 進(jìn)行數(shù)據(jù)的恢復(fù)，使其數(shù)據(jù)為最新的，而這個(gè)恢復(fù)的過程中，PG的狀態(tài)會(huì)從inconsistent ->recover -> clean,最終恢復(fù)正常。
• 這是集群故障自愈一種場(chǎng)景。

3.8 Down

3.8.1 說(shuō)明

Peering過程中，PG檢測(cè)到某個(gè)不能被跳過的Interval中(例如該Interval期間，PG完成了Peering，并且成功切換至Active狀態(tài)，從而有可能正常處理了來(lái)自客戶端的讀寫請(qǐng)求),當(dāng)前剩余在線的OSD不足以完成數(shù)據(jù)修復(fù).

3.8.2 故障模擬

a. 查看PG 3.7f內(nèi)副本數(shù)

$ ceph pg dump | grep ^3.7f dumped all 3.7f 43 0 0 0 0 494927872 1569 1569 active+clean 2018-07-05 02:52:51.512598 21315'80115 21356:111666 [5,21,29] 5 [5,21,29] 5 21315'80115 2018-07-05 02:52:51.512568 6206'80083 2018-06-29 22:51:05.831219 

b. 停止PG 3.7f 副本osd.21

$ systemctl stop ceph-osd@21 

c. 查看PG 3.7f狀態(tài)

$ ceph pg dump | grep ^3.7f dumped all 3.7f 66 0 89 0 0 591396864 1615 1615 active+undersized+degraded 2018-07-05 15:29:15.741318 21361'80161 21365:128307 [5,29] 5 [5,29] 5 21315'80115 2018-07-05 02:52:51.512568 6206'80083 2018-06-29 22:51:05.831219 

d. 客戶端寫入數(shù)據(jù)，一定要確保數(shù)據(jù)寫入到PG 3.7f的副本中[5,29]

e. 停止PG 3.7f中副本osd.29,并且查看PG 3.7f狀態(tài)

f. 停止PG 3.7f中副本osd.5,并且查看PG 3.7f狀態(tài)

g. 拉起PG 3.7f中副本osd.21(此時(shí)的osd.21數(shù)據(jù)比較陳舊), 查看PG狀態(tài)(down)

h. 客戶端IO操作

此時(shí)客戶端IO都會(huì)夯住

ll /mnt/  

故障總結(jié)：

首先有一個(gè)PG 3.7f有三個(gè)副本[5,21,29]， 當(dāng)停掉一個(gè)osd.21之后， 寫入數(shù)據(jù)到osd.5, osd.29。 這個(gè)時(shí)候停掉osd.29, osd.5 ，最后拉起osd.21。 這個(gè)時(shí)候osd.21的數(shù)據(jù)比較舊，就會(huì)出現(xiàn)PG為down的情況，這個(gè)時(shí)候客戶端IO會(huì)夯住，只能拉起掛掉的osd才能修復(fù)問題。

3.8.3 結(jié)論

• 典型的場(chǎng)景：A(主)、B、C

1. 首先kill B

2. 新寫入數(shù)據(jù)到 A、C

3. kill A和C

4. 拉起B(yǎng)

• 出現(xiàn)PG為Down的場(chǎng)景是由于osd節(jié)點(diǎn)數(shù)據(jù)太舊，并且其他在線的osd不足以完成數(shù)據(jù)修復(fù)。
• 這個(gè)時(shí)候該P(yáng)G不能提供客戶端IO讀寫， IO會(huì)掛起夯住。

本文作者：李航，多年的底層開發(fā)經(jīng)驗(yàn)，在高性能nginx開發(fā)和分布式緩存redis cluster有著豐富的經(jīng)驗(yàn)，目前從事Ceph工作兩年左右。 先后在58同城、汽車之家、優(yōu)酷土豆集團(tuán)工作。 目前供職于滴滴基礎(chǔ)平臺(tái)運(yùn)維部 負(fù)責(zé)分布式Ceph集群開發(fā)及運(yùn)維等工作。 個(gè)人主要關(guān)注的技術(shù)領(lǐng)域：高性能Nginx開發(fā)、分布式緩存、分布式存儲(chǔ)。