Ceph中Snapshot的示例分析

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

解析Ceph: Snapshot

Wang, Haomai | 2013.12.27

經常有開發者在郵件列表中會問到Ceph Snapshot的實現方式，受限于目前有限的實現文檔和復雜的代碼結構和代碼量，弄清楚Ceph Snapshot并不是一件容易的事。正好最近在重構Ceph存儲引擎層的DBObjectMap，涉及到處理Snapshot間clone的問題，重新梳理了一次在Ceph IO路徑中占了非常大比重的snapshot相關代碼流程，在這里并不會重點展現里面的代碼或者數據結構，而是從高層設計角度展現Snapshot的實現。

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

Ceph Snapshot使用場景

多數人嘗試Ceph的Snapshot往往從Ceph的RBD庫入手，也就是所謂的塊存儲。利用librbd通過簡單的命令可以快速創建卷和Snapshot。

rbd create image-name –size 1024 -p pool

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

第一條命令創建了一個名為”image-name”的卷，在這個過程中librbd庫只是創建了一個metadata而沒有實際向Ceph申請空間。關于librbd如何利用Rados實現塊存儲和管理更多的細節會在以后的文章中講到，這里先留個坑。

第二條命令對”image-name”卷創建了一個名為”snap-name”的Snapshot，創建以后，對”image-name”卷的任意寫操作之后都可以在任意時間回滾到創建”snap-name”的Snapshot時的數據。如下面這條命令

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

在用戶實際嘗試過程中，會發現Ceph對于卷的操作和管理非常輕量，任意時刻，任意卷大小，任意集群大小的卷創建都是相同的操作量級，在其背后實質上也是完全相同的操作。開發者會對如何實現Snapshot更敢興趣，因為Snapshot的實現方式決定了如何有效的使用Snapshot。

Ceph Snapshot實現

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

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

除了Pool概念外，Ceph實質上有兩種Snapshot模式，并且兩種Snapshot是不能同時應用到同一個Pool中。

1. Pool Snapshot: 對整個Pool打一個Snapshot，該Pool中所有的對象都會受影響

2. Self Managed Snapshot: 用戶管理的Snapshot，簡單的理解就是這個Pool受影響的對象是受用戶控制的。這里的用戶往往是應用如librbd。

我們在前面利用rbd命令的操作實質上是使用第二種模式，因此我們先首先介紹第二種模式的實現。

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

1. 用戶申請為”pool”中的”image-name”創建一個名為”snap-name”的Snapshot

2. librbd向Ceph Monitor申請得到一個”pool”的snap sequence，Ceph Monitor會遞增該Pool的snap_seq，然后返回該值給librbd。

3. librbd將新的snap_seq替換原來image的snap_seq中，并且將原來的snap_seq設置為用戶創建的名為”snap-name”的Snapshot的snap_seq

從上面的操作中，對于版本控制實現熟悉的同學們可能就大致猜測出Ceph對于Snapshot的實現了。每個Snapshot都掌握者一個snap_seq，Image可以看成一個Head Version的Snapshot，每次IO操作對會帶上snap_seq發送給Ceph OSD，Ceph OSD會查詢該IO操作涉及的object的snap_seq情況。如”object-1″是”image-name”中的一個數據對象，那么初始的snap_seq就”image-name”的snap_seq，當創建一個Snapshot以后，再次對”object-1″進行寫操作時會帶上新的snap_seq，Ceph接到請求后會先檢查”object-1″的Head Version，會發現該寫操作所帶有的snap_seq大于”object-1″的snap_seq，那么就會對原來的”object-1″克隆一個新的Object Head Version，原來的”object-1″會作為Snapshot，新的Object Head會帶上新的snap_seq，也就是librbd之前申請到的。

Ceph的實現當然比上面提到的要復雜很多，要考慮更多的異常情況還有管理Object Snaps上。

上述提到的是第二種Snapshot Mode，那么第一種模式實際上更簡單。既然第二種方式是應用(librbd)自己申請snap_seq，然后進行管理，那么第一種是的場景可以是命令如”rados mksnap snap-name -p pool”進行全局pool的Snapshot，應用是不需要知道snap_seq的。這條命令會遞增”pool”的snap_seq，然后接下來所有”pool”下的objects對會受影響，因為所有的接下來的IO操作都會自動繼承”pool”的snap_seq，對object進行clone。在CephFS里用到這個模式管理全局的Snapshot。

所以，更簡單的講，這兩者mode的區別就在于應用進行IO請求時是否附帶snap_seq。

Object Snapshot的存儲管理

上面提到的都是如何利用snap_seq向底層存儲查找相應的對象然后返回，那么底層的存儲引擎是如何管理一個Object的不同版本的呢。

首先，任一個Object都是通過ObjectStore接口進行訪問，目前Ceph Master分支支持MemStore和FileStore兩種，FileStore是默認的存儲接口實現。以后的文章也會介紹具體的FileStore實現。

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

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

以上是“Ceph中Snapshot的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！