共計 3687 個字符，預計需要花費 10 分鐘才能閱讀完成。
丸趣 TV 小編給大家分享一下 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 中。
Pool Snapshot: 對整個 Pool 打一個 Snapshot，該 Pool 中所有的對象都會受影響
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 的。
用戶申請為”pool”中的”image-name”創建一個名為”snap-name”的 Snapshot
librbd 向 Ceph Monitor 申請得到一個”pool”的 snap sequence，Ceph Monitor 會遞增該 Pool 的 snap_seq，然后返回該值給 librbd。
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 的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！
