如何實現(xiàn)ceph原理分析

本篇文章為大家展示了如何實現(xiàn)ceph原理分析，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

1      整體架構(gòu)介紹

1.1      總體介紹

Ceph是一種開源的軟件定義存儲系統(tǒng)，誕生于2004年，最早致力于開發(fā)下一代高性能分布式文件系統(tǒng)的項目。Ceph可以部署在任意x86服務(wù)器上工作，具有良好的擴展性、兼容性和可靠性。它能對外提供文件系統(tǒng)服務(wù)(cephfs)、塊服務(wù)(rbd)和對象存儲服務(wù)(rgw)，是一種統(tǒng)一存儲系統(tǒng)。Ceph架構(gòu)支持海量數(shù)據(jù)存儲，集群可以擴展至PB容量，系統(tǒng)本身無熱點數(shù)據(jù)，數(shù)據(jù)尋址依賴計算而不是查找，并能做到數(shù)據(jù)狀態(tài)自維護，數(shù)據(jù)自修復(fù)，是一款優(yōu)秀的分布式存儲系統(tǒng)。

1.2      整體架構(gòu)

圖 1 ceph全景

Ceph架構(gòu)主要包含了：Rados集群，librados接口層，rgw、rbd和cephfs這三種存儲服務(wù)。

Rados集群：Rados是Ceph系統(tǒng)的核心，包含了分布式集群管理和數(shù)據(jù)管理，集群的擴展性和高可用性是在這里體現(xiàn)的。主要的組件有monitor、osd和mds。Monitor是集群的關(guān)鍵服務(wù)，它保證了集群元數(shù)據(jù)的一致性和集群的可服務(wù)性。Osd是ceph的數(shù)據(jù)服務(wù)，它負責(zé)了業(yè)務(wù)數(shù)據(jù)的落盤，數(shù)據(jù)狀態(tài)的監(jiān)控，數(shù)據(jù)狀態(tài)恢復(fù)，數(shù)據(jù)的遷移和恢復(fù)等流程。Mds是cephfs的元數(shù)據(jù)服務(wù)，維護文件系統(tǒng)的超級塊信息，目錄結(jié)構(gòu)，文件信息等。一般如果不使用cephfs，是可以不用部署mds的。

librados接口層：統(tǒng)一封裝的接口層，提供集群連接接口，pool創(chuàng)建接口，obj讀寫接口等，作為基礎(chǔ)庫提供給上層調(diào)用，比如librbd、libcephfs和librgw。第三方的應(yīng)用可以直接調(diào)用librados對ceph做二次開發(fā)。

客戶端：ceph客戶端包括rbd、rgw、cephfs這三種類型，同時也包括librbd、libcephfs和librgw這些開發(fā)庫。對外提供存儲服務(wù)，比如rbd可以導(dǎo)出scsi塊設(shè)備，cephfs可以mount到Linux主機上做為文件系統(tǒng)，也可以通過cifs/nfs導(dǎo)出為網(wǎng)絡(luò)文件服務(wù)，rgw對外直接提供s3或者swift對象存儲服務(wù)。

2      集群管理

2.1      Monitor

Monitor服務(wù)是ceph的核心服務(wù)之一，它主要作用是為整個集群提供全局的配置和系統(tǒng)信息。Ceph集群其實是體現(xiàn)在Monitor集群上的，Monitor是一個獨立部署的服務(wù)，多個Monitor組成高可用集群。Monitor采用paxos算法保證集群數(shù)據(jù)的一致性，Monitor所管理的數(shù)據(jù)包括：

1、  Monitor Map：包括集群的fsid，所有的monitor的ip和端口，以及epoch

2、  OSD Map：包括集群的fsid，所有osd狀態(tài)及監(jiān)聽地址，pool的信息及pg數(shù)等

3、  MDS Map：包括所有的mds服務(wù)的列表和狀態(tài)，data pool和metadata pool

4、  PG Map：所有pg的信息，包括狀態(tài)、version等

5、  CRUSH Map：一個樹形結(jié)構(gòu)，包括存儲設(shè)備，故障域等

2.2      心跳管理

Monitor通過心跳這種方式來獲得OSD服務(wù)的工作狀態(tài)，根據(jù)這種狀態(tài)的變化更新相應(yīng)的位圖。

首先是OSD之間會有心跳檢查，OSD會檢查osd_heartbeat_min_peers個OSD服務(wù)，peer osd其實是指的osd相鄰的osd服務(wù)，默認是10個。這些相鄰的osd服務(wù)首先是包含同一個pg的osd列表，這個是從pg_map上獲取，如果得到的osd列表超過osd_heartbeat_min_peers個就丟棄，不足的就補上當(dāng)前osd周圍狀態(tài)up的osd進來。

檢查過程是每osd_heartbeat_interval秒就檢查一次peer端的osd，默認是6秒。如果peer端osd在osd_heartbeat_grace后沒回復(fù)，默認20s，則標(biāo)記這個osd狀態(tài)為down。

圖 2 osd peer間心跳

在不同故障域之間osd的狀態(tài)變化，monitor可能不會第一時間感知到，這里設(shè)置了不同故障域的reporter個數(shù)，默認是1

圖 3 不同故障域的檢查

圖3所示，osd1和osd2分屬于兩個不同的故障域。

如果一個osd不能和peer內(nèi)的所有osd做心跳了，則會向monitor申請最新的osd map。超時時間為osd_mon_heartbeat_interval默認30s。

Monitor如果在mon_osd_report_timeout內(nèi)收不到osd的消息，則會設(shè)置osd為down，mon_osd_report_timeout默認為900s。

正常情況下osd每隔osd_mon_report_interval_min，（最短間隔時間默認為5s）會向monitor報告一次事件，事件包括start剛啟動、osd故障、up_thru的變化等。osd向monitor報告的最長時間為osd_mon_report_interval_max，默認為120s。意思是說120s無論osd有沒有狀態(tài)變化都需要向monitor報告。

圖 4 osd向monitor報告

3      數(shù)據(jù)讀寫

3.1      OSD

OSD（object storage daemon）負責(zé)Ceph集群的數(shù)據(jù)讀寫，同時也負責(zé)向Monitor報告監(jiān)控的OSD的狀態(tài)。管理數(shù)據(jù)的遷移，副本，數(shù)據(jù)平衡，數(shù)據(jù)恢復(fù)。Ceph集群數(shù)據(jù)管理的核心服務(wù)，通往磁盤的數(shù)據(jù)通道。

OSD主要包含了兩個主要組成部分，一個PG，另一個是ObjectStore。PG（placement group）是Ceph的數(shù)據(jù)管理的基本邏輯單位，參與數(shù)據(jù)讀寫，數(shù)據(jù)遷移，數(shù)據(jù)恢復(fù)等和數(shù)據(jù)相關(guān)的全部流程。ObjectStore是負責(zé)向本地存儲讀寫的模塊，現(xiàn)在常用的是filestore和bluestore，當(dāng)前onestor版本使用的是filestore。Filestore實際上是操作的本地文件系統(tǒng)，將業(yè)務(wù)最終寫到本地磁盤的文件中，默認是使用xfs文件系統(tǒng)。Bluestore是直接操作的裸盤，數(shù)據(jù)直接通過BIO下到盤上，性能相較于filestore有較大提升，Ceph的最新版本默認采用是Bluestore。

3.2      讀寫流程

圖 5 數(shù)據(jù)讀寫過程

數(shù)據(jù)要存儲在Ceph上需要經(jīng)歷幾個主要步驟：

1、  Client需要獲得Monitor最新的cluster map，得到map后確定osd的信息

2、  對象到pg的hash，具體為對待寫的object id做hash，得到的hash值，再對當(dāng)前pool的pg_num取模，最后得到該對象所在的pg id。

pg_id = hash(object_name) % pg_num

然后再將pool id加到hash值之前，比如4.f1，4就是pool id，f1是上面算出的hash值，這兩部分構(gòu)成一個pg id。

3、  pg到OSD的映射，數(shù)據(jù)最終需落盤，所以pg得映射到一個OSD上。這個映射過程采用的Ceph自己獨有的CRUSH算法，通過計算選擇一個合適OSD。CRUSH本質(zhì)是一種偽隨機算法。找到OSD后，Client直接與OSD通信，建立網(wǎng)絡(luò)連接，將數(shù)據(jù)發(fā)送到OSD服務(wù)處理。

4、  OSD最后把收到的數(shù)據(jù)投遞給ObjectStore，由它完成向本地存儲寫入的過程。同時完成主從OSD的數(shù)據(jù)落盤。

OSD的數(shù)據(jù)寫入過程滿足數(shù)據(jù)的強一致性，待所有數(shù)據(jù)落盤才向上返回。

圖 6 主從OSD寫入過程

1、  Client先將寫請求發(fā)到主OSD上。

2、  主OSD在收到Client請求后，立即向從OSD發(fā)送寫請求，同時也寫入主OSD的本地存儲上。

3、  主OSD收到從OSD寫入成功的ack，再確認自己處理正確，最后再返給Client寫完成ack。寫過程中必須等到所有的OSD的寫成功返回才能向Client返回寫操作成功的消息。

3.3      POOL和PG

Pool是一種邏輯上存儲資源池，Ceph對外提供的存儲服務(wù)，資源都是從Pool中劃分提供的。Pool分兩種一種是副本模式，一種是糾刪碼模式。一個Pool是由許多PG構(gòu)成的。Pool的信息保存在osd map中。

PG是對象數(shù)據(jù)的集合，同一個集合內(nèi)的對象應(yīng)用相同的存儲策略。比如對象的副本都會存放到相同的OSD列表中。一個對象只屬于一個PG，一個PG包含多個對象，一個PG會存放到多個OSD上，一個OSD會承載多個PG。

圖7表示了一個pool是雙副本，對象t1是怎么分布到pg 1.3e的。

圖 7 pg與osd對應(yīng)關(guān)系

3.4      CRUSH算法

CRUSH（control replication under scalable hash）算法是Ceph內(nèi)部中重要的尋址算法，它主要解決對象到盤的尋址過程。同時由于是通過計算得出，因此集群不需要查詢地址，所以也就沒有中心節(jié)點的產(chǎn)生，極大的減少了元數(shù)據(jù)的體量。CRUSH可以將數(shù)據(jù)盡量的分散到各個存儲上。

CRUSH算法主要使用的場景：數(shù)據(jù)io的時候，創(chuàng)建pool的時候，osd狀態(tài)up/down，osd的添加和刪除。3.2節(jié)所描述的，CRUSH主要是解決PG是如何映射到OSD列表的問題。用函數(shù)表示就是：

crush(pg.x) -> (osd.1, osd.2, osd.3,….osdN)

圖 8 CRUSH Map

CRUSH map可以認為是數(shù)據(jù)中心的抽象，它的目的是尋找到合適的位置存放數(shù)據(jù)副本。CRUSH內(nèi)容包括了組織結(jié)構(gòu)Hierarchical CRUSH Map，副本選擇規(guī)則Placement Rules以及容器Bucket。

層級化CRUSH Map，邏輯上看組織結(jié)構(gòu)是個樹形結(jié)構(gòu)。包含device和bucket，device一般為osd服務(wù)作為葉子節(jié)點。bucket作為設(shè)備的容器，一般為CRUSH Map中的普通節(jié)點。bucket的類型有osd（device），host，chassis，rack，row，pdu，pod，room，datacenter，region，root，這些類型描述了CRUSH Map中的存儲位置。每個bucket包含多個device。

Bucket Weight，權(quán)重是用來描述存儲能力的指標(biāo)。1T大小表示為1，采用雙精度數(shù)表示。Bucket的權(quán)重大小是包含子bucket或device的權(quán)重大小。

Placement Rules決定了對象副本選擇規(guī)則，它定義從哪些bucket或是device里去選擇。這樣可以定義不同的pool可以從不同的磁盤選擇存放位置。

表格 1 bucket定義

       表1中描述的是CRUSH Map的定義的Bucket，用樹形圖表示就是：

圖 9 crush map圖形化

圖9所示，root作為crush map的入口，定義了bucket rack0，其中包括3個host，每個host包括了兩個device osd。bucket的定義了隨機選擇算法為straw2，hash算法為rjenkins1。這里的hash算法是用來計算隨機值，隨機選擇算法是根據(jù)隨機值判定選擇OSD。

表1中所定義的選擇規(guī)則是partition0_rule和partition0_ec_rule_1。規(guī)則原型如下：

ruleset：當(dāng)前規(guī)則的id

type：pool的存儲模式

min_size：如果Pool的副本數(shù)小于min_size則不使用這個規(guī)則

max_size：如果Pool的副本數(shù)大于max_size則不使用這個規(guī)則

step take <bucket-name> [class <device-class>]：

選擇一個bucket，一般是root類型bucket，以這個為查詢的輸入，遍歷這顆樹。同時也可而已指定自定義的設(shè)備類型。

step choose firstn {num} type {bucket-type}：

深度優(yōu)先選擇num個bucket-type類型的子bucket。

l  If {num} == 0, choose pool-num-replicas buckets (all available).

l  If {num} > 0 && < pool-num-replicas, choose that many buckets.

l  If {num} < 0, it means pool-num-replicas - {num}.

如果num為0則選擇和pool副本數(shù)一樣的，num大于0小于pool的副本數(shù)，則返回num個副本數(shù)，如果num小于0，則返回pool副本數(shù)減num的個數(shù)。

step chooseleaf firstn {num} type {bucket-type}：

和上一條規(guī)則一樣，區(qū)別在于chooseleaf是選擇葉子節(jié)點，一般就是osd。

step emit：

輸出選擇結(jié)果。

3.4.1  Straw算法

現(xiàn)在有了crush的組織結(jié)構(gòu)CRUSH Map和選擇規(guī)則Placement Rules，從bucket中選出合適的設(shè)備是采用隨機算法來做具體的選擇。當(dāng)前CRUSH所支持的隨機算法有：

表格 2 隨機選擇算法

具體描述Straw算法，提供各個bucket盡量公平的選擇機會，權(quán)重越大選中的概率越高。執(zhí)行過程其實遞歸遍歷bucket，找到合適device。如果權(quán)限大就盡量找權(quán)限大的，如果權(quán)限一樣則隨機返回。

圖 10 straw代碼片段

       如代碼所示：

1、  crush(pg_id, osd_id, r) => draw，r為常數(shù)，運算次數(shù)

2、  ( draw &0xffff ) * osd_weight => straw

3、  得到最大的high_draw，返回該item

其中draw就是隨機數(shù)，然后用draw乘以權(quán)重得到一個簽值，選中最大簽值的OSD。要保證不能每次都選中權(quán)重最大那個，隨機數(shù)的產(chǎn)生就很重要。

圖 11 rjenkins hash算法

將3組數(shù)據(jù)傳入進行混合攪拌，盡量得到一個隨機值。可以看到只要傳入的值是相同的，得到隨機值也是相同的，所以CRUSH是一個偽隨機的算法。

參考源碼src/crush/mapper.c，入口函數(shù)crush_do_rule

3.5      ObjectStore模塊

ObjectStore是Ceph系統(tǒng)落盤前的最后一個模塊，它負責(zé)保證業(yè)務(wù)數(shù)據(jù)可以安全可靠高效的IO。ObjectStore定義事務(wù)操作，具體的本地存儲必須實現(xiàn)這些操作。ObjectStore目前包括4種本地實現(xiàn)：

1、  FileStore：H、J版本使用較多的本地存儲，采用文件系統(tǒng)做為對象讀寫的方式。

2、  BlueStore：最新L版本支持的本地存儲，未來Ceph的默認方式，拋棄掉文件系統(tǒng)直接操作塊設(shè)備，性能最好。

3、  KStore：使用KV存儲系統(tǒng)作為本地存儲。

4、  MemStore：數(shù)據(jù)和元數(shù)據(jù)都保存在內(nèi)存中，主要用于測試和驗證。

目前用于生產(chǎn)環(huán)境的是FileStore和BlueStore。

3.5.1  FileStore

FileStore默認使用xfs文件系統(tǒng)保存數(shù)據(jù)。利用文件系統(tǒng)POSIX接口實現(xiàn)ObjStore的接口，每個對象在底層是以文件存在。

圖 12 filestore結(jié)構(gòu)

FileStore包含F(xiàn)ileJournal和DBObjectMap兩個模塊，F(xiàn)ileStore為了提高ObjectStore寫事務(wù)處理能力和原子性引入了FileJournal。它相當(dāng)于數(shù)據(jù)庫的WAL(write ahead log)，為了保證每個寫事務(wù)的完整性。它會使用direct io方式寫到j(luò)ournal日志里，完成后再將事務(wù)提交到FileStore的隊列中繼續(xù)完成寫操作，如果中途有發(fā)生crash，OSD在做recovery的時候會將日志恢復(fù)出來。

FileStore寫數(shù)據(jù)順序是，先寫journal然后再寫盤上。Journal寫完后會返回給上層，但是要能read ready還是要等到數(shù)據(jù)落盤后才行，不過在大量小io隨機寫場景性能還是不錯。FileStore由于先寫日志再寫盤，所以有個寫放大的問題。

DBObjectMap是專門用來管理對象的屬性的模塊，有兩種實現(xiàn)xattr和omap。xattr是用文件系統(tǒng)的擴展屬性實現(xiàn)的，受限于文件系統(tǒng)擴展屬性的長度限制，適合小量數(shù)據(jù)存放。omap是采用leveldb k-v鍵值存儲實現(xiàn)，如果屬性大小超過xattr的限制，則可以存放到omap中。

3.5.2  Bluestore

圖 13 bluestore整體結(jié)構(gòu)

Bluestore為解決filestore在寫數(shù)據(jù)前先寫journal產(chǎn)生的寫放大，并針對ssd做了相應(yīng)的優(yōu)化。Bluestore直接操作裸盤，盡可能的避免文件系統(tǒng)（xfs、ext4）的開銷。操作裸盤則盤空間管理由allocator（默認是BitmapAllocator）處理。Bluestore在io過程中產(chǎn)生的元數(shù)據(jù)，元數(shù)據(jù)則存放到rocksdb kv數(shù)據(jù)庫中。rocksdb存數(shù)據(jù)依賴文件系統(tǒng)，但是rocksdb將底層系統(tǒng)相關(guān)的抽象為env，用戶程序只需要實現(xiàn)相應(yīng)的接口就可以提供底層的系統(tǒng)的封裝。Bluestore實現(xiàn)了BlueRocksEnv，并實現(xiàn)了Bluefs支撐BlueRocksEnv。Bluefs的日志和數(shù)據(jù)文件都是保存在裸盤上，和用戶數(shù)據(jù)共享裸盤設(shè)備，也可以分開指定不同設(shè)備。

圖 14 osd設(shè)備數(shù)據(jù)分區(qū)

osd目錄分區(qū)：默認占用100M，默認掛載xfs文件系統(tǒng)。提供基本的描述信息，包括whoami（osd編號），osd的type，osd的魔術(shù)字，block塊設(shè)備入口等。

Block dev label分區(qū)：默認占用4K。存儲bluestore_bdev_label_t結(jié)構(gòu)體信息，包含osd_uuid，塊設(shè)備size，設(shè)備描述信息，創(chuàng)建時間等。

Bluefs supper block分區(qū)：默認占用4K。存儲bluefs_super_t結(jié)構(gòu)體信息，包含osd_uuid，version和block_size等。

DB數(shù)據(jù)分區(qū)：默認占用MAX[1G，塊設(shè)備總大小的4%]，保存DB數(shù)據(jù)和日志數(shù)據(jù)。

用戶數(shù)據(jù)分區(qū)：默認占用剩余空間，存放用戶業(yè)務(wù)數(shù)據(jù)。

元數(shù)據(jù)映射關(guān)系：

圖 15 元數(shù)據(jù)映射關(guān)系

一個對象對應(yīng)一個onode，一個onode包含多個extent，多個extent存放在一個或者多個blob里，每個blob又對應(yīng)到多個pextent，就是具體的物理塊，這樣就完成了extent到pextent的映射。

BlueStore讀過程比較簡單，如果有預(yù)讀標(biāo)志則從cache里讀，如果沒命中則需要從盤上讀出來并且添加到cache中。

Bluestore寫過程比較復(fù)雜，大致分為大寫和小寫。根據(jù)寫入數(shù)據(jù)長度來確定是小寫還是大寫，通過對min_alloc_size（blob的最小分配大寫默認64K）取模，如果小于64K為小寫流程，如果大于64K則為大寫流程。

圖 16 寫場景

小寫分為覆蓋寫和非覆蓋寫，其中非覆蓋小寫和大寫沒有寫懲罰，先寫數(shù)據(jù)然后改元數(shù)據(jù)。覆蓋寫場景會產(chǎn)生WAL日志，先要完成WAL日志處理落盤后，再寫入業(yè)務(wù)數(shù)據(jù)。

整體來說性能比filestore提高不少。

4      數(shù)據(jù)peering和恢復(fù)

Ceph系統(tǒng)中承擔(dān)數(shù)據(jù)IO和數(shù)據(jù)恢復(fù)的基本邏輯單元叫PG（Placement Group），PG是Ceph中數(shù)據(jù)載體。可以理解PG為一個目錄或者集合，包含了多個對象。

PG有自己的狀態(tài)，PG健康度出現(xiàn)異常，狀態(tài)會發(fā)生變遷，數(shù)據(jù)也會發(fā)生遷移。

active+clean：PG的健康時的狀態(tài)。

Degraded：降級狀態(tài)，如果是雙副本的配置，有個osd掛掉了，PG就會進入這種狀態(tài)。這種情況下PG還是可以提供IO服務(wù)的。

Recovery：一個osd出現(xiàn)故障下線了，但這時pg還是可讀寫的，當(dāng)故障osd啟動后，它所保存的數(shù)據(jù)比其他osd版本要舊這個時候就會產(chǎn)生recovery，保證數(shù)據(jù)一致。

Remapped：如果osd下線是由于硬盤故障，這個時候就是永久性故障，需要再分配新osd做重新映射。選中新osd后，數(shù)據(jù)還是為空的，需要從正常的osd上將數(shù)據(jù)全量拷貝到新osd上，所以狀態(tài)一般是remapped+backfilling。

Peered：出現(xiàn)這種狀態(tài)，是由于故障的osd數(shù)量過多，造成了pg不能讀寫了。這個狀態(tài)可以理解為正常的osd在等待其他副本osd上線。

4.1      數(shù)據(jù)peering機制

Peering過程是一個PG對應(yīng)的一組OSD的狀態(tài)達到一致的過程，PG達到active時，peering過程就完成了，但是PG對應(yīng)的OSD上的數(shù)據(jù)并不一定完全一致。

PG發(fā)生的場景：

n  系統(tǒng)初始化OSD啟動重新加載PG或者創(chuàng)建PG，會觸發(fā)PG發(fā)起一次Peering過程。

n  OSD故障或OSD增加減少，會導(dǎo)致PG的acting set發(fā)生變化，PG也會發(fā)起一次Peering過程。

peering概念介紹

1、  acting set和up set

acting set是一個PG活動的一組OSD，該列表是有序的，下標(biāo)第一個OSD為prime OSD。up set一般與acting set相同。不相同的情況是OSD故障導(dǎo)致，生成臨時PG。這個時候acting set和up set不一致。

2、  臨時pg

原OSDacting set列表中[0,1,2]的主OSD osd.0故障了，crush重新選出的acting set為[3,1,2]，但是這個時候osd3并沒有該PG的數(shù)據(jù)，需要做backfill，這個時候osd3是不能讀的。所以會產(chǎn)生一個臨時PG做為prime，比如通知monitor讓osd1做臨時prime，這個時候up set就為[1,3,2]，acting set還是[3,1,2]，backfill做完，臨時pg取消，兩個列表就想同了。

3、  Authoritative History權(quán)威日志

指的是記錄pg完整順序的連續(xù)的操作日志記錄，做為數(shù)據(jù)恢復(fù)的依據(jù)。

Peering的過程，基本分為三個步驟

l  GetInfo : pg的主osd通過發(fā)送消息獲取各個從OSD的pg_info信息。

l  GetLog：根據(jù)pg_info的比較，選擇一個擁有權(quán)威日志的osd（auth_log_shard） , 如果主osd不是擁有權(quán)威日志的osd，就去擁有權(quán)威日志的osd獲取，獲取后主osd也擁有權(quán)威日志。

l  GetMissing：拉取其它從OSD 的pg log（或者部分獲取，或者全部獲取FULL_LOG) , 通過本地的auth log對比，來判別從OSD 上缺失的object 信息。以用于后續(xù)recovery過程的依據(jù)。

l  Active: 激活主osd，并發(fā)想通知notify消息，激活相應(yīng)的從osd。

簡單來說peering并不恢復(fù)數(shù)據(jù)，只是將各個osd的狀態(tài)統(tǒng)一起來，明確哪些對象需要恢復(fù)，為下一步做準(zhǔn)備。

4.2      數(shù)據(jù)恢復(fù)

Peering完成后，就可以知道是否有數(shù)據(jù)需要恢復(fù)了。恢復(fù)的方式有兩種recovery和backfill。

Recovery是就根據(jù)PG日志中缺失的記錄來修復(fù)不一致的對象。

Backfill是PG通過重新掃描所有對象，對比發(fā)現(xiàn)缺失的對象，通過整體拷貝的方式修復(fù)。當(dāng)OSD失效時間過長導(dǎo)致無法根據(jù)PG日志記錄來修復(fù)，或者新OSD加入導(dǎo)致的數(shù)據(jù)遷移，這些都會導(dǎo)致Backfill流程。

5      數(shù)據(jù)端到端一致性

存儲系統(tǒng)中io路徑復(fù)雜，傳統(tǒng)存儲系統(tǒng)一般包括從應(yīng)用層到內(nèi)核文件系統(tǒng)、塊設(shè)備、SCSI層再到HBA和磁盤控制器，每層都有出錯的可能。因此傳統(tǒng)的端到端解決方案會以數(shù)據(jù)塊校驗為主來解決。

 因為 Ceph 作為一個應(yīng)用層的應(yīng)用，這時候如果封裝固定數(shù)據(jù)塊并且加入校驗數(shù)據(jù)會導(dǎo)致較嚴重的性能問題，因此 Ceph 在這方面只是引入 Scrub 機制(Read Verify)來保證數(shù)據(jù)的正確性。

簡單來說，Ceph 的 OSD 會定時啟動 Scrub 線程來掃描部分對象，通過與其他副本進行對比來發(fā)現(xiàn)是否一致，如果存在不一致的情況，Ceph 會拋出這個異常交給用戶去解決。

Scrub按照掃描內(nèi)容不同分為兩種方式：

n  一種叫srub，它只是比較各個對象的副本元數(shù)據(jù)，來檢查數(shù)據(jù)一致性。只是檢查元數(shù)據(jù)，所以讀取和計算的量都比較小，一種輕量的檢查。

n  一種叫deep-srub，它要進一步檢查對象的數(shù)據(jù)內(nèi)容是否一致，實現(xiàn)深度掃描，幾乎要掃描磁盤上的所有數(shù)據(jù)并計算crc32校驗，所有開銷很大，占用系統(tǒng)資源很多。

Scrub按照掃描的方式分為兩種：

n  在線掃描：不影響系統(tǒng)正常業(yè)務(wù)。

n  離線掃描：需要系統(tǒng)?；騼鼋Y(jié)業(yè)務(wù)。

Ceph的Scrub是實現(xiàn)了在線掃描，可不中斷系統(tǒng)業(yè)務(wù)的前提下執(zhí)行scrub，但是針對具體某個對象做Scrub，是會鎖定對象的，阻止客戶端對它的訪問，一直到Scrub執(zhí)行完成才會釋放。

上述內(nèi)容就是如何實現(xiàn)ceph原理分析，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。