ZStack如何實現混合云災備？看這篇就懂了
原創【51CTO.com原創稿件】 本文以輕松詼諧的風格為你深入淺出解讀ZStack混合云災備的實現機制。
1. “吃狗糧”的災備危機
在我司的工程實踐中，最為常見的一個做法就是“吃狗糧”。也就是說，所有工程師的開發環境、測試環境都是由ZStack搭建的。最開始的時候，工程師們還蝸居在兩間不大的辦公室，其樂也融融。某天，隨著一聲聲哀嚎，大家發現有位工程師不慎把主存儲給誤刪掉了。
得益于ZStack的設計，整個環境半個小時成功恢復。原因有兩點：
- 系統自動部署了備份服務，數據庫每小時有定期備份；
- ZStack本身無狀態，只要數據庫在，環境就能恢復。
有驚無險，上了一次“云頭條”。
2. 災備很重要，但為何是混合云災備？
自己吃狗糧碰到的問題，用戶必然也會遇到。進一步引申下來，在這個“刪庫跑路”、“誤操作導致數據丟失”等消息常年霸占媒體頭條的時代，我們需要嚴肅地思考一個問題：如果被刪除的不僅僅是數據庫記錄，而是真實存儲系統的數據，或者存儲出了故障，怎么辦？
我們需要災備，但災備不僅僅是數據備份。數據備份是最自然、最基礎的需求。完成數據恢復后，用戶真正需要恢復的是業務。在私有云的場景下，業務恢復的資源粒度可以是一臺虛擬機，甚至是一個集群。如果說，“ You cannot sell a platform without a killing application running on it.” 那么，ZStack的災備功能將會是混合云平臺的一個殺手級應用。
通過在ZStack 中引入混合云災備，用戶可以將虛擬機鏡像以及相關元數據備份到公有云。即使本地數據丟失，也可以抓取指定的云端備份進行重建。甚至，用戶可以直接在公有云以備份數據創建一臺虛擬機。災備云。
在進一步回答為何是通過混合云實現災備之前，我們先回顧一下私有云。
私有云
單純的私有云環境是一個閉環，整個系統的資源在私有云內部調配。系統管理員通過IaaS軟件為公司各個部門提供應用環境，IaaS軟件解決的是基礎設施的監控可視化，資源的靈活分配，和可維護性。
簡單私有云場景
圖1是一張最簡化的私有云場景。私有云將IT人員的生產力從繁復瑣碎的配置中解放出來。從此IT人員更多關心的是交付，而不是如何交付。IaaS軟件理解系統中的所有資源關系，其中一個重要的觀念是：計算機（虛擬機）不再是分離的硬件設施，而是一個獨立、完整的資源交付單元。
在缺乏 IaaS 軟件的環境下，災備的主要資源實體是存儲，它以對象存儲、塊存儲或者文件系統的方式，做異地備份。但存儲只是計算的諸多層面之一，如何快速、有效地將恢復的數據投入運用，還是離不開IaaS這樣的上層管理軟件。
混合云
混合云災備應運而生。首先，相比于公有云 ，通常的私有云規模很難有足夠大的資源池。資源過多會導致浪費，這是企業不愿意看到的情況。資源過少則無法應對突發需求，這也是企業的痛點。其次，公有云都會提供完善的IaaS應用編程接口，私有云可以通過編程接口延伸IaaS框架內的各種資源需求。由此可見，在打通了公有云的數據和網絡層面后，公有云不但可以應對突發的計算需求，還是一個非常合適的災備載體，主要原因如下：
- 完備的應用編程接口
- 良好的彈性計算能力；
- 近乎無限的存儲空間。
混合云場景
圖2展示了對接公有云后的混合云場景。對比圖1和圖2，我們也許會發現，這兩者的區別和Subversion與Git之間的區別有些許神似之處 —— 即：系統資源的存取是否集中。
3. 混合云災備如何實現？
ZStack自有的鏡像倉庫設計，是實現混合云災備的核心。
鏡像倉庫設計思想
圖3展示了ZStack鏡像倉庫的高層次構架。與 Opentack Glance ，以及 Docker Registry類似，ZStack 鏡像倉庫（以下簡稱鏡像倉庫）并不負責實際的存儲，只是完成鏡像的管理工作，以及元數據的維護。
ZStack鏡像倉庫架構
但是鏡像倉庫采用的數據組織方式與前述兩者完全不同。簡單來說，鏡像倉庫的數據存儲方式與git類似，是一個內容可尋址存儲。所有存儲入口都通過一層中間件封裝，實際的存儲工作則由后臺存儲插件完成。可以對接本地存儲，或者Aliyun OSS 等云存儲。
這種設計有如下好處：
- 數據存儲和管理邏輯分離；
- 因為內容可尋址，客戶端和服務器可以分別對所有數據（包括元數據）做哈希驗證，互不信任；
- 數據不可更改（包括元數據），任何更改都會改變哈希值。
說到鏡像的組織，ZStack鏡像倉庫通過元數據維護了鏡像之間的關系，對于鏡像的格式并不關心。倉庫中的鏡像來源可以是qcow2 文件，也可以是 RBD 鏡像，重建整個鏡像的工作由客戶端負責。比如，對于 qcow2 文件可以用 qemu-img 工具，而對于 RBD 鏡像則可以使用rbd工具進行管理。
如何用鏡像倉庫實現混合云災備
現在我們來看看，如何用鏡像倉庫實現混合云災備。
具體來說，我們在鏡像倉庫上實現了 push 和 pull 操作，使得不同鏡像倉庫之間可以方便地同步指定鏡像。和git類似：
- push 是將本地的鏡像推送到遠程；
- pull 是將遠程的鏡像抓取到本地。
ZStack鏡像倉庫的push和pull
對于任意備份在公有云上的鏡像倉庫，其中包含的鏡像和本地鏡像倉庫并無二致。同樣由于內容可尋址，在鏡像的傳輸過程中可以避免大量不必要的數據傳輸。這一點是非常關鍵的：
- 數據的完整性可以輕松驗證；
- 極大地提高了鏡像傳輸速度，節省了時間；
- 節省了出數據中心的流量，節約客戶成本。
在具體實現中，還需要考慮如何處理讀寫沖突、寫寫合并以及橫向擴展等問題。限于篇幅，細節不再贅述。
以下是ZStack基于鏡像倉庫的幾個典型災備策略。
備份策略
用戶可以對需要備份的虛擬機執行手動備份，或者指定備份策略執行自動備份。比如，備份間隔時間等等。手動備份能力是必要的，這使得用戶可以及時對虛擬機做備份，避免時間窗口的風險。
恢復虛擬機
當用戶對根云盤進行備份之后，恢復虛擬機只需要將遠程的備份抓取到本地鏡像倉庫，然后創建虛擬機即可。就像開啟了時光隧道，用戶使虛擬機回到任意的備份點。
恢復數據盤
同樣的邏輯也適用于數據盤。鏡像倉庫并不區分根云盤或者數據盤。恢復數據盤只需要將遠程的備份抓取到本地，然后加載到虛擬機。
鏡像倉庫就是這只“魔戒”
綜前所述，鏡像倉庫對本地、異地，rbd 以及 qcow2，以及不同的存儲后端，都呈現了統一的服務接口。這是策略與機制分離的典型應用，鏡像倉庫只提供鏡像的存儲和維護機制，而對如何使用鏡像毫不關心。另外，由于鏡像倉庫的數據組織特性，倉庫間的數據可以按需指定資源同步。正是這種靈活的設計，為ZStack的災備能力提供了堅實的基礎條件。
如果沒有公有云
退一步，用戶沒有對接公有云環境的狀況下，只要數據通道的速度有充分保證，用戶可以異地（比如IDC機房）部署鏡像倉庫，同樣可以很容易地實現異地備份。唯一的缺點在于，如果本地私有云突然發生災難，沒有辦法利用公有云的能力，快速恢復關鍵應用。
小結
正如同雞蛋不能放在同一只籃子里，重要的數據也不能全都放在本地。隨著硬件能力的不斷進步，用戶擁有單位資源的成本在不斷降低，但是數據的潛在價值卻在不斷攀升。數據越龐大，業務規模越龐大，導致的代價也隨之越來越高昂。擁有災備能力，擁有系統化恢復業務的能力，才能全無后顧之憂。在云的世界里，“后悔藥”其實是存在的。
李群，ZStack首席工程師。統籌負責ZStack研發工作，在云計算以及安全領域有豐富的研發經驗。2007年加入EMC云計算基礎設施部，負責通用Appliance平臺的研發工作；2010年加入Intel開發者產品部，負責SGX指令集的SDK研發；2015年加入微軟中國云計算創新中心，負責Azure中國區CDN服務的研發。
【作者簡介】
李群，ZStack首席工程師。統籌負責ZStack研發工作，在云計算以及安全領域有豐富的研發經驗。2007年加入EMC云計算基礎設施部，負責通用Appliance平臺的研發工作；2010年加入Intel開發者產品部，負責SGX指令集的SDK研發；2015年加入微軟中國云計算創新中心，負責Azure中國區CDN服務的研發。
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
