你真的會 snapshot 嗎？ - 天天5分鐘玩轉 OpenStack（163）

​這是 OpenStack 實施經驗分享系列的第 13 篇。

 

instance snapshot 操做可用於備份或者將 instance 保存爲新的 image。若是在生產系統中執行 snapshot 操做，必須確保此操做快速且安全。這裏有兩個關鍵點：

 

1. 快速。 
   爲保證數據的一致性，snapshot 時須要 pause instance，操做完後再 resume。在這個過程當中 instance 是沒法對外服務的，爲了減小對業務的影響，咱們但願 snapshot 越快越好。
    

2. 安全。 
   即數據一致性，snapshot 出來的 image 不能有沒落盤的數據，可以正常啓動。因此一般在執行 snapshot 前要 pause instance，暫停全部的 IO 操做。

 

默認的 snapshot

 

默認配置下的 snapshot 操做是否能知足快速和安全這兩個條件呢？

 

snapshot 是對 instance 的鏡像文件（系統盤）作快照，鏡像文件位於計算節點 /var/lib/nova/instances/<instance id>/disk。在第036篇中咱們詳細討論了 snapshot 的執行步驟：

 

1. pause instance
    

2. 執行 qemu-img convert 命令複製 disk 文件，生成快照文件
    

3. resume instance
    

4. 將快照文件上傳到 Glance

其中第 1 步保證了 安全，而是否 快速 取決於第 2 步要花多長時間。qemu-img convert 的執行時間取決於 disk 及其 backing 文件的大小，一般 instance 系統盤都以 G 爲單位，因此第 2 步花費的時間是分鐘級別的。

 

讓生產系統暫停幾分鐘一般是不能被接受的，因此默認的 snapshot 操做無法作到 快速。

 

解決方案是什麼呢？

 

不靠譜的 live snapshot

 

Nova 很早就提出了 live snapshot 的替代方案，具體見官網 http://docs.openstack.org/ops-guide/ops-user-facing-operations.html#live-snapshots

 

live snapshot 的原理是：作快照時不 pause instance，直接執行 qemu-img convert。也就是去掉第 1 和 第 3 步。

 

這樣雖然 快速 條件知足了，業務不會受到影響。但因爲沒有 pause instance，有可能出現快照過程當中不斷有新數據寫進 disk 文件的狀況，很難保證數據的一致性，結果 安全 又成了問題。

 

官網文檔建議：若是要作 live snapshot，用戶必須本身保證數據的一致性，好比作快照前確保全部數據已經落盤，而且不會有新數據寫進來。我的以爲，live snapshot 基本上無法在生產中使用。

 

那到底有沒有既 安全 又 快速 的方案呢？

 

真正的解決方案

 

默認 snapshot 的問題在於 qemu-img convert 耗時太長，而耗時太長的緣由是 instance 的系統盤是文件，拷貝文件自己就是一個耗時的操做。真正的解決方案是：

 

讓 instance 從 cinder volume 啓動，利用 storage provider 本身的 snapshot 技術實現快速複製。

 

現代存儲系統（不管開源仍是商業存儲）基本上都提供了 volume 的 snapshot 功能，而這個 snapshot 是基於指針的，不會真正拷貝數據，因此很是快，一般一瞬間就完成，對業務幾乎沒有影響。因此若是 instance 是從 cinder volume 啓動的，那麼作快照的時候 OpenStack 就會使用 storage provider 的 snapshot 完成操做。這就實現了既 安全 又 快速。

 

下面咱們使用流行的分佈式存儲系統 ceph 來演示這個過程。這裏省略了 ceph 做爲 cinder backend 的配置方法，若是有興趣能夠參考官網 http://docs.ceph.com/docs/master/rbd/rbd-openstack/

 

boot from volume

 

部署 instance 時指定建立 volume。
 

 

 

 

這裏咱們選擇的 image 是 xenial（Ubuntu 16.04），大小爲 2.20 GB。確保 Create New Volume 選項爲 Yes。Volume Size 爲 3（大於 image 2.20 GB）。執行部署後，OpenStack 會完成以下工做：

 

1. 在 ceph 中建立一個 3 GB 的 volume。

2. 將 image 數據拷貝到該 volume。

3. instance 從該 volume 啓動。

在 volume 管理界面能夠看到這個新建立的 volume。
 

 

 

ubuntu-test 就是咱們部署的 instance。接下來對 ubuntu-test 執行 snapshot 操做。

 

 

 

 

 

操做瞬間完成！

 

 

 

注意到快照 snap-test 的 Size 是 0 字節，這是由於它真正的存放位置在 cehp。經過 snap-test 部署出來的 instance 直接就是 boot from volume 的。

 

boot from volume 實際上是 OpenStack 部署 instance 的最佳實踐，instance 的啓動盤和數據盤都由 cinder 管理，並且作快照和作備份都很方便。

 

下期預告

 

到這裏，實施經驗分享部分就先告一段落。按照以前的計劃，接下來是容器技術的內容。不過最近收到不少同窗的留言，但願講一講 cloud-init 的工做原理和相關應用。

 

instance 定製化實際上是個很是重要的內容，在生產環境中的需求很大。目前最主流的方案就是 cloud-init，固然僅僅 cloud-init 是不夠的，還得須要 OpenStack 服務的支持。前面之因此沒有討論，主要是由於這個主題會同時涉及 nova 和 neutron 兩大模塊，要求的知識和技能比較綜合，不過如今則是個很是好的時機。

 

接下來 CloudMan 會系統講解 instance 定製化這個主題，從原理到實踐力求把它講透。只是容器部分不得再也不多等一下了，見諒見諒。