如何理解instance snapshot

今天就跟大家聊聊有關(guān)如何理解instance snapshot，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

instance snapshot 操作可用于備份或者將 instance 保存為新的 image。如果在生產(chǎn)系統(tǒng)中執(zhí)行 snapshot 操作，必須確保此操作快速且安全。這里有兩個關(guān)鍵點：

1. 快速。 
   為保證數(shù)據(jù)的一致性，snapshot 時需要 pause instance，操作完后再 resume。在這個過程中 instance 是無法對外服務(wù)的，為了減少對業(yè)務(wù)的影響，我們希望 snapshot 越快越好。
    

2. 安全。 
   即數(shù)據(jù)一致性，snapshot 出來的 image 不能有沒落盤的數(shù)據(jù)，能夠正常啟動。所以通常在執(zhí)行 snapshot 前要 pause instance，暫停所有的 IO 操作。

默認的 snapshot

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

snapshot 是對 instance 的鏡像文件（系統(tǒng)盤）做快照，鏡像文件位于計算節(jié)點 /var/lib/nova/instances/<instance id>/disk。在第036篇中我們詳細討論了 snapshot 的執(zhí)行步驟：

1. pause instance
   

2. 執(zhí)行 qemu-img convert 命令復(fù)制 disk 文件，生成快照文件
   

3. resume instance
   

4. 將快照文件上傳到 Glance

其中第 1 步保證了 安全，而是否 快速 取決于第 2 步要花多長時間。qemu-img convert 的執(zhí)行時間取決于 disk 及其 backing 文件的大小，通常 instance 系統(tǒng)盤都以 G 為單位，所以第 2 步花費的時間是分鐘級別的。

讓生產(chǎn)系統(tǒng)暫停幾分鐘通常是不能被接受的，所以默認的 snapshot 操作沒法做到 快速。

解決方案是什么呢？

不靠譜的 live snapshot 

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

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

這樣雖然 快速 條件滿足了，業(yè)務(wù)不會受到影響。但由于沒有 pause instance，有可能出現(xiàn)快照過程中不斷有新數(shù)據(jù)寫進 disk 文件的情況，很難保證數(shù)據(jù)的一致性，結(jié)果 安全 又成了問題。

官網(wǎng)文檔建議：如果要做 live snapshot，用戶必須自己保證數(shù)據(jù)的一致性，比如做快照前確保所有數(shù)據(jù)已經(jīng)落盤，并且不會有新數(shù)據(jù)寫進來。個人覺得，live snapshot 基本上沒法在生產(chǎn)中使用。

真正的解決方案

默認 snapshot 的問題在于 qemu-img convert 耗時太長，而耗時太長的原因是 instance 的系統(tǒng)盤是文件，拷貝文件本身就是一個耗時的操作。真正的解決方案是：

讓 instance 從 cinder volume 啟動，利用 storage provider 自己的 snapshot 技術(shù)實現(xiàn)快速復(fù)制。

現(xiàn)代存儲系統(tǒng)（無論開源還是商業(yè)存儲）基本上都提供了 volume 的 snapshot 功能，而這個 snapshot 是基于指針的，不會真正拷貝數(shù)據(jù)，所以非常快，通常一瞬間就完成，對業(yè)務(wù)幾乎沒有影響。所以如果 instance 是從 cinder volume 啟動的，那么做快照的時候 OpenStack 就會使用 storage provider 的 snapshot 完成操作。這就實現(xiàn)了既 安全 又 快速。

下面我們使用流行的分布式存儲系統(tǒng) ceph 來演示這個過程。這里省略了 ceph 作為 cinder backend 的配置方法，。

boot from volume

部署 instance 時指定創(chuàng)建 volume。

這里我們選擇的 image 是 xenial（Ubuntu 16.04），大小為 2.20 GB。確保 Create New Volume 選項為 Yes。Volume Size 為 3（大于 image 2.20 GB）。執(zhí)行部署后，OpenStack 會完成如下工作：

1. 在 ceph 中創(chuàng)建一個 3 GB 的 volume。

2. 將 image 數(shù)據(jù)拷貝到該 volume。

3. instance 從該 volume 啟動。

在 volume 管理界面可以看到這個新創(chuàng)建的 volume。
 

ubuntu-test 就是我們部署的 instance。接下來對 ubuntu-test 執(zhí)行 snapshot 操作。

操作瞬間完成！

注意到快照 snap-test 的 Size 是 0 字節(jié)，這是因為它真正的存放位置在 cehp。通過 snap-test 部署出來的 instance 直接就是 boot from volume 的。

boot from volume 其實是 OpenStack 部署 instance 的最佳實踐，instance 的啟動盤和數(shù)據(jù)盤都由 cinder 管理，而且做快照和做備份都很方便。

 instance 定制化其實是個非常重要的內(nèi)容，在生產(chǎn)環(huán)境中的需求很大。目前最主流的方案就是 cloud-init，當然僅僅 cloud-init 是不夠的，還得需要 OpenStack 服務(wù)的支持。前面之所以沒有討論，主要是因為這個主題會同時涉及 nova 和 neutron 兩大模塊，要求的知識和技能比較綜合，不過現(xiàn)在則是個非常好的時機。

看完上述內(nèi)容，你們對如何理解instance snapshot有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。