帶你讀《存儲漫談Ceph原理與實踐》第三章接入層3.3.檔案存儲 CephFS（三）

3.3.3  CephFS 進階特性

1.  Snapshot（快照）

（1） Snapshot特性介紹

CephFS 支援快照功能，快照檔案被建立後将儲存在快照對象目錄中的隐藏子目錄裡。通常來說，快照功能設計是為了儲存檔案系統在建立快照時間點的狀态視圖，但為了

實作以下的附加特性，CephFS快照設計選擇有别于其他幾類快照。

1）       任意子樹：快照可以在選擇的任何目錄中建立（而非僅能在根目錄下建立），并覆寫該目錄下檔案系統中的所有資料。

2）       異步：快照建立行為異步化，建立快照後由快照資料與實時資料差異造成的資料複制和資料遷移不能影響正常讀寫性能，隻能延緩完成。

為了實作這兩點，CephFS快照使用了基于COW的實作。

（2）  Snapshot 特性實作原理與細節

CephFS 快照中，較為重要的資料結構如下。

◆  SnapContext

— 個 RADOS系統的 SnapContext由一個快照序列 ID（即 snapid）清單和每一個

RADOSObject在此清單上存亡時間所對應的關聯表組成（如 Object在 snap02後建立，在 snap04 後删除，在表中會有所表示）。為了生成該清單，會将與 SnapRealm關聯的快照ID和其 past_parents的所有有效快照 ID組合在一起（SnapClient 的緩存模式會過濾掉過期的快照，以确定哪些是有效快照）。

◆  SnapRealm

無論在任何時候建立快照，都會生成一個SnapRealm，它的功能較為單一，主要用于将SnapContext 與每個打開的檔案關聯，以進行寫入。SnapRealm中還包含sr_tsrnode、past_parents、past_children、inodes_with_caps等資訊。

◆  sr_（t srnode）

sr_t是存儲在 RADOS系統 OSD 中的檔案系統快照中繼資料結構，包含序列計數器、時間戳、相關的快照 ID清單和 past_parent。

◆  SnapServer

SnapServer管理快照 ID 配置設定、快照删除，并跟蹤檔案系統中有效快照的清單，一個檔案系統隻有一個 SnapServer執行個體。

◆  SnapClient

SnapClient用于與SnapServer通信，每個MDSrank（每個rank視作一個中繼資料分片 shard，從 MDS中選出目前管理此rank的 Server）都有其自己的 SnapClient執行個體，SnapClient還負責在本地緩存有效快照資料。

（3） Snapshot處理細節

◆  建立快照

CephFS内部通過在目錄建立 .snap 子目錄的方式管理目前目錄的快照。用戶端會将請求發送到MDS伺服器，然後在伺服器的Server::handle_client_mksnap（）中處理。它會從 SnapServer中配置設定一個 snapid，利用新的 SnapRealm建立并連結一個新的inode，然後将其送出到 MDlog，送出後會觸發 MDCache::do_realm_invalidate_and_update_notify()，此函數将此 SnapRealm廣播給所有對快照目錄下任一檔案有管轄權的用戶端。用戶端收到通知後，将同步更新本地 SanpRealm層級結構，并為新的SnapRealm結構生成新的 SnapContext，用于将快照資料寫入 OSD 端。同時，快照的中繼資料會作為目錄資訊的一部分更新到OSD端（即sr_t）。整個過程是完全異步處理的。

◆  更新快照

快照資訊更新分為兩種情況。快照删除：這個過程和快照建立類似，不過行為都變為删除；檔案或目錄重命名：從父目錄SnapRealm中删除這個檔案或目錄 inode，rename代碼會為重命名的inode建立一個新的 SnapRealm，并将對舊父目錄（past_parent）SnapRealm有效的快照ID儲存到新的 SnapRealm的past_parent_snaps中。

◆  RADOS 存儲快照資料

CephFS檔案被分割成 Object後，Object層級快照行為由 RADOS自行管理。此外，在将檔案資料Object寫入 OSD時，還額外用到了 SnapContext這一結構。

◆  RADOS存儲快照中繼資料 sr_t

目錄快照資訊（及快照本身的 Inode資訊）作為目錄資訊的一部分字段進行存儲。所有目錄項的快照字段都包含其生效的第一個和最後一個Snapid（表示這個目錄項建立于哪次快照，消亡于哪次快照）。未快照的目錄項，将快照字段的最後位置設定為 CEPH_NOSNAP。

◆  快照回寫

當用戶端收到 MClientSnap消息時，它将更新本地SnapRealm内容，并将舊 Inode連結更新為需要回寫的Inode的新連結，并為這些回寫的 Inode生成 CapSnap。CapSnap被用于緩沖新寫入的資料，直到快照回寫在 OSD中完成。

同時，另一方面，在 MDS中，會為這些 CapSnap一并記錄日志，以保障這一過程的完成。

◆  删除快照

直接嘗試删除帶快照的目錄會失敗，必須先删除快照。在用戶端删除快照資訊後，将發送請求給映射的OSD，使其删除相關的快照檔案資料。而通過将目錄資訊更新覆寫後寫入 OSD對象的方式，快照中繼資料将被異步删除。

◆  硬連結

具有過多硬連結的 Inode将被轉移到虛拟全局 SnapRealm。虛拟全局 SnapRealm覆寫檔案系統中的所有快照，以處理這種棘手情況。Inode的資料将為任何新快照保留，這些保留的資料也将覆寫 Inode的任何連結上的快照。

◆  多檔案系統

需要注意的是，CephFS的快照和多個檔案系統的互動是存在問題的——每個 MDS叢集獨立配置設定 snappid，如果多個檔案系統共享一個池，快照會沖突。如果此時有客戶删除一個快照，将會導緻其他人丢失資料，并且這種情況不會提升異常，這也是 CephFS的快照不推薦使用的原因之一。

（4）  Snapshot 工具指令限制總結

預設情況下，檔案系統沒有啟用快照功能，要想在現有檔案系統上啟用它，可使用以下指令開啟。

#建立快照

#ceph fs set <fs_name> allow_new_snaps true

啟用快照後，CephFS中的所有目錄都将具有一個特殊的 .snap目錄（如果需要，可以使用用戶端snapdir配置其他名稱）。

要建立CephFS快照，請在 .snap 目錄下建立一個具有你選擇的名稱的子目錄。例如，要在目錄“/1/2/3/”上建立快照，請調用以下指令。

#在⽬錄 "/1/2/3/" 上建立快照

#mkdir/1/2/3/.snap/my-snapshot-name

◆  恢複快照

#恢複快照

#cp -ra/1/2/3/.snap/my-snapshot-name/*/1/2/3/

#删除快照

#rmdir/1/2/3/.snap/my-snapshot-name

◆  快照限制（“s”标志）

要建立或删除快照，用戶端除了需要“rw”外還需要“s”權限标志。請注意，當權限    字元串還包含“p”标志時，“s”标志必須出現在其後（除“rw”以外的所有标志都必須按字母表順序指定）。例如，在以下代碼段中，client.0可以在子檔案系統“cephfs_a”的“bar”目錄中建立或删除快照。

client.0

key:AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw==

caps: [mds] allow rw allow rws path=/barcaps: [mon] allow r

caps:[osd] allow rw tag cephfs data=cephfs_a

◆  ceph-syn

ceph-syn是一個适用于 CephFS的簡單的人造載荷生成器。它通過 libcephfs庫在目前運作着的檔案系統上生成簡單的載荷，此檔案系統不必通過ceph-fuse或核心用戶端挂載。可以用一個或多個--syn指令參數規定特定的載荷，而此測試工具也可以用來操作快照（但作為一個測試工具，不推薦直接使用）。

#在 path上建立⼀個名為snapname的快照

#ceph-syn --syn mksnap path snapname

# 删除path上名為snapname的快照

#ceph-syn --syn rmnap path snapname

◆  cephfs-shell

cephfs-shell提供類似于 shell的指令，可以直接與 CephFS系統進行互動（需要注意的是，cephfs-shell基于Python，需要依賴 cmd2子產品）。

cephfs-shell[options][command]

cephfs-shell[options] –[command command ...]

-c--config FILE // Path to cephfs-shell.conf

-b --batch FILE// Pathto batch file

-t --test FILE   // Path to transcript(s) in FILE for testing

建立或删除快照：

snap {create|delete} <snap_name> <dir_name>snap_name - Snapshot name to be created or deleted

dir_name- directory under which snapshot should be created or deleted

◆  用戶端版本

Mimic版本（13版本）以後的 fuse與 lib 庫用戶端都可以支援快照。核心版本等于及高于 4.17的核心用戶端可以支援快照，這點與之後講述的 Quota一緻。

2.  Quota配額

（1） Quota特性介紹

CephFS   允許在系統中的任何目錄上設定配額。配額可以限制目錄層次結構中該節點下方存儲的位元組或檔案的數量。

（2）  Quota 特性實作原理與細節

目前來說，CephFSQuota 特性有以下細節。

◆  CephFSQuota是針對目錄的，可限制目錄下存放的檔案數量和容量。

◆  CephFS 沒有一個統一的UID/GID機制，傳統的基于使用者群組的配額管理機制很難使用。

◆  CephFS一般與用戶端應用配合使用，将使用者關聯到對應的 CephFS目錄。

（3） Quota 目前實作的局限性

◆  配額需要用戶端合作

CephFSQuota 取決于挂載檔案系統的用戶端的合作，以在達到限制時停止寫入程式。CephFS    服務端本身不能阻止用戶端寫入所需數量的資料，在用戶端完全不受信任的環境中，Quota無法阻止用戶端填滿檔案系統。

◆  Quota控制時間因素不精确

達到Quota 限制後，寫入檔案系統的程序将在短時間内停止而非立刻停止。用戶端将不可避免地被允許寫入超出配置限制的資料量。一般而言，在超出配置的限制後的 10s（取決于檢測已使用 Quota 的時間間隔，此參數可以調整，但一般推薦預設為10s，過短可能會影響性能）内，程序将被停止寫入。

◆  Quota僅在核心版本等于及高于 4.17的核心用戶端中實作

Mimic版本（13版本）以後的 fuse與 lib庫用戶端都可以支援Quota。核心版本等于及高于 4.17的核心用戶端可以支援 Quota。

◆  在與基于路徑的通路限制一起使用時，必須仔細配置 Quota

基于路徑限制挂載時必須謹慎地配置 Quota。用戶端必須能夠通路配置了Quota的那個目錄的索引節點，這樣才能執行Quota管理。如果某一用戶端被 MDS能力限制成了隻能通路一個特定路徑（如/home/user），并且無權通路配置了Quota的父目錄（如/ home），這個用戶端就不會受父目錄（如/home）的限制去執行Quota。是以，基于路徑做通路控制時，最好在限制了用戶端的那個目錄（如 /home/user）或者它更下層的子目錄上配置 Quota。

◆  快照未計入 Quota

目前建立快照造成的COW 增量資料未被計入Quota 進行限制。避免出現此種狀況的基本方法是不要同時使用快照和Quota功能。快照 COW增量資料計入Quota統計有待未來開發。

（4） Quota工具指令總結

CephFS的 mount方式分為核心态 mount和使用者态 mount，核心态使用 mount指令挂載，使用者态使用ceph-fuse指令挂載。核心态隻有在 kernel4.17+ Cephmimic以上的版本才支援 Quota，使用者态則沒有限制。

◆  核心态 mount與使用者态 mount挂載

#核心态 mount

# mount -t ceph 192.168.3.1:/test /mnt/cephfs/ -o name=adminsecret=AQCs2Q9bqAjCHRAAlQUF+hAiXhbErk4NdtvORQ==

# ⽤戶态mount

#ceph-fuse -r/test /mnt/cephfs/ --nameclient.admin

◆  配置 Quota

# ⾸先在 CephFS建立⼀個要限額的⽬錄

#mkdir /mnt/cephfs

#ceph-fuse/mnt/Cephfs

# 然後在⽬錄上使⽤ setfattr設定限額屬性

#setfattr-n ceph.quota.max_bytes-v100000000 /mnt/cephfs/test

3.  QoS服務品質

（1） QoS特性介紹

QoS（Quality   of   Service，服務品質）指一個網絡能夠利用各種基礎技術，為指定的網絡通信提供更好的服務的能力，是一種用來解決網絡時延和阻塞等問題的網絡安全機制。 在CephFS中，目前傾向使用限流的方式來實作 QoS 目的。此功能目前尚未引入，Ceph社群考慮在 16版本及之後着手開發限流功能。

（2）  QoS特性實作設想與 Ceph社群方向

目前 Ceph 社群對限流功能設想的實作方向是在用戶端進行令牌桶算法流控。通過将QoS資訊設定為目錄的 xattrs之一（和 Quota一樣）來控制流控開啟、關閉與監控，同時可以使用一次 QoS設定來控制通路相同目錄的所有用戶端的限流。

而配置 QoS 的流程則參照Quota 的配置流程，當MDS收到 QoS 設定時，它将向所有用戶端廣播該資訊。流控限額可以線上更改，設定以後如 Quota一樣由用戶端進行具體的流控行為。

Ceph 社群為限流功能預留的配置方式如下。

setfattr -n ceph.qos.limit.iops -v 200 / mnt / cephfs/ testdirs /setfattr -n ceph.qos.burst.read_bps -v 200 / mnt / cephfs / testdirs/getfattr -n ceph.qos.limit.iops / mnt / cephfs / testdirs /

getfattr -n ceph.qos /mnt / cephfs /testdirs /

Ceph社群也讨論了這樣設計可能會遇到的問題。由于CephFS用戶端I/O路徑中沒有隊列，是以，如果流控小于請求的塊大小，則整個用戶端将被完全阻塞，直到獲得足夠的令牌為止。

此外，在單個共享目錄多用戶端共享挂載情況下，如果不對用戶端分别控制，流控會變得不可預測。對于這一點，Ceph社群計劃了兩種模式。

1）       所有用戶端都使用相同的 QoS 設定而不去理會多個用戶端的情況，即幹脆放任上述不可預測性。這樣做的好處是不會因為總的流控限制，間接影響了用戶端的可挂載數量。

2）     所有用戶端共享特定的QoS設定。

◆  設定總限制，所有用戶端均受平均數限制：total_limit/clients_num。

◆  設定總限額，mds 通過用戶端的曆史I/O＆BPS 分擔用戶端的限額。