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