這是 OpenStack 實施經驗分享系列的第 13 篇。
instance snapshot 操作可用於備份或者將 instance 保存為新的 image。如果在生產系統中執行 snapshot 操作，必須確保此操作快速且安全。這里有兩個關鍵點：
-
快速。
為保證數據的一致性，snapshot 時需要 pause instance，操作完后再 resume。在這個過程中 instance 是無法對外服務的，為了減少對業務的影響，我們希望 snapshot 越快越好。
-
安全。
即數據一致性，snapshot 出來的 image 不能有沒落盤的數據，能夠正常啟動。所以通常在執行 snapshot 前要 pause instance，暫停所有的 IO 操作。
默認的 snapshot
默認配置下的 snapshot 操作是否能滿足快速和安全這兩個條件呢？
snapshot 是對 instance 的鏡像文件（系統盤）做快照，鏡像文件位於計算節點 /var/lib/nova/instances/<instance id>/disk。在第036篇中我們詳細討論了 snapshot 的執行步驟：
-
pause instance
-
執行 qemu-img convert 命令復制 disk 文件，生成快照文件
-
resume instance
-
將快照文件上傳到 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 會完成如下工作：
-
在 ceph 中創建一個 3 GB 的 volume。
-
將 image 數據拷貝到該 volume。
-
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 定制化這個主題，從原理到實踐力求把它講透。只是容器部分不得不再多等一下了，見諒見諒。
