小編給大家分享一下Ceph中Snapshot的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

創(chuàng)新互聯(lián)公司是專業(yè)的天津網(wǎng)站建設(shè)公司，天津接單;提供成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行天津網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛(ài)的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!

解析Ceph: Snapshot

Wang, Haomai | 2013.12.27

經(jīng)常有開(kāi)發(fā)者在郵件列表中會(huì)問(wèn)到Ceph Snapshot的實(shí)現(xiàn)方式，受限于目前有限的實(shí)現(xiàn)文檔和復(fù)雜的代碼結(jié)構(gòu)和代碼量，弄清楚Ceph Snapshot并不是一件容易的事。正好最近在重構(gòu)Ceph存儲(chǔ)引擎層的DBObjectMap，涉及到處理Snapshot間clone的問(wèn)題，重新梳理了一次在Ceph IO路徑中占了非常大比重的snapshot相關(guān)代碼流程，在這里并不會(huì)重點(diǎn)展現(xiàn)里面的代碼或者數(shù)據(jù)結(jié)構(gòu)，而是從高層設(shè)計(jì)角度展現(xiàn)Snapshot的實(shí)現(xiàn)。

在閱讀下文前務(wù)必先了解Ceph的基本情況和使用場(chǎng)景。Why Ceph and how to use Ceph?

Ceph Snapshot使用場(chǎng)景

多數(shù)人嘗試Ceph的Snapshot往往從Ceph的RBD庫(kù)入手，也就是所謂的塊存儲(chǔ)。利用librbd通過(guò)簡(jiǎn)單的命令可以快速創(chuàng)建卷和Snapshot。

rbd create image-name –size 1024 -p pool

rbd snap create pool/image-name –snap snap-name

第一條命令創(chuàng)建了一個(gè)名為”image-name”的卷，在這個(gè)過(guò)程中l(wèi)ibrbd庫(kù)只是創(chuàng)建了一個(gè)metadata而沒(méi)有實(shí)際向Ceph申請(qǐng)空間。關(guān)于librbd如何利用Rados實(shí)現(xiàn)塊存儲(chǔ)和管理更多的細(xì)節(jié)會(huì)在以后的文章中講到，這里先留個(gè)坑。

第二條命令對(duì)”image-name”卷創(chuàng)建了一個(gè)名為”snap-name”的Snapshot，創(chuàng)建以后，對(duì)”image-name”卷的任意寫操作之后都可以在任意時(shí)間回滾到創(chuàng)建”snap-name”的Snapshot時(shí)的數(shù)據(jù)。如下面這條命令

rbd snap rollback pool/image-name –snap snap-name

在用戶實(shí)際嘗試過(guò)程中，會(huì)發(fā)現(xiàn)Ceph對(duì)于卷的操作和管理非常輕量，任意時(shí)刻，任意卷大小，任意集群大小的卷創(chuàng)建都是相同的操作量級(jí)，在其背后實(shí)質(zhì)上也是完全相同的操作。開(kāi)發(fā)者會(huì)對(duì)如何實(shí)現(xiàn)Snapshot更敢興趣，因?yàn)镾napshot的實(shí)現(xiàn)方式?jīng)Q定了如何有效的使用Snapshot。

Ceph Snapshot實(shí)現(xiàn)

在闡述之前，首先要了解Ceph有Pool的概念，也就是上面命令上涉及到的-p pool。一個(gè)Ceph Cluster可以創(chuàng)建多個(gè)Pool，每個(gè)Pool是邏輯上的隔離單位，不同的Pool可以有完全不同的數(shù)據(jù)處理方式。如Replication Size(副本數(shù))，Placement Groups(PG)，CRUSH Rules，Snapshots，Ownership都是利用Pool進(jìn)行隔離的。

因此，對(duì)Ceph的任意操作都需要先指定Pool才能進(jìn)行，上面的image操作都是在一個(gè)名為”pool”的Pool上進(jìn)行，名為”image-name”的Image也是存儲(chǔ)在”pool”中。

除了Pool概念外，Ceph實(shí)質(zhì)上有兩種Snapshot模式，并且兩種Snapshot是不能同時(shí)應(yīng)用到同一個(gè)Pool中。

1. Pool Snapshot: 對(duì)整個(gè)Pool打一個(gè)Snapshot，該P(yáng)ool中所有的對(duì)象都會(huì)受影響

2. Self Managed Snapshot: 用戶管理的Snapshot，簡(jiǎn)單的理解就是這個(gè)Pool受影響的對(duì)象是受用戶控制的。這里的用戶往往是應(yīng)用如librbd。

我們?cè)谇懊胬胷bd命令的操作實(shí)質(zhì)上是使用第二種模式，因此我們先首先介紹第二種模式的實(shí)現(xiàn)。

在前面提到，Snapshot也是利用Pool隔離的，兩種Snapshot mode的實(shí)現(xiàn)是基本相似的，如何使用是造成兩種模式分離的重要原因。每個(gè)Pool都有一個(gè)snap_seq字段，該字段可以認(rèn)為是整個(gè)Pool的Global Version。所有存儲(chǔ)在Ceph的Object也都帶有snap_seq，而每個(gè)Object會(huì)有一個(gè)Head版本的，也可能會(huì)存在一組Snapshot objects，不管是Head版本還是snapshot object都會(huì)帶有snap_seq，那么接下來(lái)我們看librbd是如何利用該字段創(chuàng)建Snapshot的。

1. 用戶申請(qǐng)為”pool”中的”image-name”創(chuàng)建一個(gè)名為”snap-name”的Snapshot

2. librbd向Ceph Monitor申請(qǐng)得到一個(gè)”pool”的snap sequence，Ceph Monitor會(huì)遞增該P(yáng)ool的snap_seq，然后返回該值給librbd。

3. librbd將新的snap_seq替換原來(lái)image的snap_seq中，并且將原來(lái)的snap_seq設(shè)置為用戶創(chuàng)建的名為”snap-name”的Snapshot的snap_seq

從上面的操作中，對(duì)于版本控制實(shí)現(xiàn)熟悉的同學(xué)們可能就大致猜測(cè)出Ceph對(duì)于Snapshot的實(shí)現(xiàn)了。每個(gè)Snapshot都掌握者一個(gè)snap_seq，Image可以看成一個(gè)Head Version的Snapshot，每次IO操作對(duì)會(huì)帶上snap_seq發(fā)送給Ceph OSD，Ceph OSD會(huì)查詢?cè)揑O操作涉及的object的snap_seq情況。如”object-1″是”image-name”中的一個(gè)數(shù)據(jù)對(duì)象，那么初始的snap_seq就”image-name”的snap_seq，當(dāng)創(chuàng)建一個(gè)Snapshot以后，再次對(duì)”object-1″進(jìn)行寫操作時(shí)會(huì)帶上新的snap_seq，Ceph接到請(qǐng)求后會(huì)先檢查”object-1″的Head Version，會(huì)發(fā)現(xiàn)該寫操作所帶有的snap_seq大于”object-1″的snap_seq，那么就會(huì)對(duì)原來(lái)的”object-1″克隆一個(gè)新的Object Head Version，原來(lái)的”object-1″會(huì)作為Snapshot，新的Object Head會(huì)帶上新的snap_seq，也就是librbd之前申請(qǐng)到的。

Ceph的實(shí)現(xiàn)當(dāng)然比上面提到的要復(fù)雜很多，要考慮更多的異常情況還有管理Object Snaps上。

上述提到的是第二種Snapshot Mode，那么第一種模式實(shí)際上更簡(jiǎn)單。既然第二種方式是應(yīng)用(librbd)自己申請(qǐng)snap_seq，然后進(jìn)行管理，那么第一種是的場(chǎng)景可以是命令如”rados mksnap snap-name -p pool”進(jìn)行全局pool的Snapshot，應(yīng)用是不需要知道snap_seq的。這條命令會(huì)遞增”pool”的snap_seq，然后接下來(lái)所有”pool”下的objects對(duì)會(huì)受影響，因?yàn)樗械慕酉聛?lái)的IO操作都會(huì)自動(dòng)繼承”pool”的snap_seq，對(duì)object進(jìn)行clone。在CephFS里用到這個(gè)模式管理全局的Snapshot。

所以，更簡(jiǎn)單的講，這兩者mode的區(qū)別就在于應(yīng)用進(jìn)行IO請(qǐng)求時(shí)是否附帶snap_seq。

Object Snapshot的存儲(chǔ)管理

上面提到的都是如何利用snap_seq向底層存儲(chǔ)查找相應(yīng)的對(duì)象然后返回，那么底層的存儲(chǔ)引擎是如何管理一個(gè)Object的不同版本的呢。

首先，任一個(gè)Object都是通過(guò)ObjectStore接口進(jìn)行訪問(wèn)，目前Ceph Master分支支持MemStore和FileStore兩種，F(xiàn)ileStore是默認(rèn)的存儲(chǔ)接口實(shí)現(xiàn)。以后的文章也會(huì)介紹具體的FileStore實(shí)現(xiàn)。

在Ceph中，每一個(gè)Object都有三種類型的存儲(chǔ)接口，分別是最主要的Object存儲(chǔ)，xattr存儲(chǔ)和omap存儲(chǔ)。Object存儲(chǔ)就是用戶實(shí)際數(shù)據(jù)的存放，xattr主要用來(lái)給CephFS提供XATTR數(shù)據(jù)存放，omap存儲(chǔ)可以理解成一個(gè)k/v存儲(chǔ)并且與某一個(gè)object相關(guān)聯(lián)。而一個(gè)Object的元數(shù)據(jù)(pool，PG，name等等)都有一個(gè)object_info_t的結(jié)構(gòu)進(jìn)行管理，有一個(gè)SnapSetContext結(jié)構(gòu)管理Snapshots，兩者都作為一個(gè)object的k/v存儲(chǔ)持久化。默認(rèn)的FileStore是利用LevelDB作為鍵值存儲(chǔ)，然后通過(guò)DBObjectMap類對(duì)LevelDB進(jìn)行映射管理。

在Snapshot的實(shí)現(xiàn)上，最重要的其實(shí)就是Clone操作，那么在FileStore層面，Object數(shù)據(jù)存儲(chǔ)是實(shí)際上就是一個(gè)文件，Object間克隆依賴OSD數(shù)據(jù)目錄的文件系統(tǒng)，如Ext4或者XFS會(huì)直接完全拷貝數(shù)據(jù)，使用Btrfs會(huì)利用ioctl的BTRFS_IOC_CLONE_RANGE命令，kv數(shù)據(jù)克隆通過(guò)一個(gè)巧妙的KeyMapping實(shí)現(xiàn)COW策略(略微復(fù)雜，后面文章解讀)，而xattr則完全copy實(shí)現(xiàn)(xattr在Ceph中較少用到)。

以上是“Ceph中Snapshot的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！