ZStack如何實現(xiàn)混合云災(zāi)備？看這篇就懂了

1.“吃狗糧”的災(zāi)備危機

在我司的工程實踐中，最為常見的一個做法就是“吃狗糧”。也就是說，所有工程師的開發(fā)環(huán)境、測試環(huán)境都是由ZStack搭建的。最開始的時候，工程師們還蝸居在兩間不大的辦公室，其樂也融融。某天，隨著一聲聲哀嚎，大家發(fā)現(xiàn)有位工程師不慎把主存儲給誤刪掉了。

得益于ZStack的設(shè)計，整個環(huán)境半個小時成功恢復(fù)。原因有兩點：

系統(tǒng)自動部署了備份服務(wù)，數(shù)據(jù)庫每小時有定期備份；

ZStack本身無狀態(tài)，只要數(shù)據(jù)庫在，環(huán)境就能恢復(fù)。

有驚無險，上了一次“云頭條”。

2.災(zāi)備很重要，但為何是混合云災(zāi)備？

自己吃狗糧碰到的問題，用戶必然也會遇到。進(jìn)一步引申下來，在這個“刪庫跑路”、“誤操作導(dǎo)致數(shù)據(jù)丟失”等消息常年霸占媒體頭條的時代，我們需要嚴(yán)肅地思考一個問題：如果被刪除的不僅僅是數(shù)據(jù)庫記錄，而是真實存儲系統(tǒng)的數(shù)據(jù)，或者存儲出了故障，怎么辦？

我們需要災(zāi)備，但災(zāi)備不僅僅是數(shù)據(jù)備份。數(shù)據(jù)備份是最自然、最基礎(chǔ)的需求。完成數(shù)據(jù)恢復(fù)后，用戶真正需要恢復(fù)的是業(yè)務(wù)。在私有云的場景下，業(yè)務(wù)恢復(fù)的資源粒度可以是一臺虛擬機，甚至是一個集群。如果說，“Youcannotsellaplatformwithoutakillingapplicationrunningonit.”那么，ZStack的災(zāi)備功能將會是混合云平臺的一個殺手級應(yīng)用。

通過在ZStack中引入混合云災(zāi)備，用戶可以將虛擬機鏡像以及相關(guān)元數(shù)據(jù)備份到公有云。即使本地數(shù)據(jù)丟失，也可以抓取指定的云端備份進(jìn)行重建。甚至，用戶可以直接在公有云以備份數(shù)據(jù)創(chuàng)建一臺虛擬機。災(zāi)備云。

在進(jìn)一步回答為何是通過混合云實現(xiàn)災(zāi)備之前，我們先回顧一下私有云。

私有云

單純的私有云環(huán)境是一個閉環(huán)，整個系統(tǒng)的資源在私有云內(nèi)部調(diào)配。系統(tǒng)管理員通過IaaS軟件為公司各個部門提供應(yīng)用環(huán)境，IaaS軟件解決的是基礎(chǔ)設(shè)施的監(jiān)控可視化，資源的靈活分配，和可維護性。

簡單私有云場景

圖1是一張最簡化的私有云場景。私有云將IT人員的生產(chǎn)力從繁復(fù)瑣碎的配置中解放出來。從此IT人員更多關(guān)心的是交付，而不是如何交付。IaaS軟件理解系統(tǒng)中的所有資源關(guān)系，其中一個重要的觀念是：計算機（虛擬機）不再是分離的硬件設(shè)施，而是一個獨立、完整的資源交付單元。

在缺乏IaaS軟件的環(huán)境下，災(zāi)備的主要資源實體是存儲，它以對象存儲、塊存儲或者文件系統(tǒng)的方式，做異地備份。但存儲只是計算的諸多層面之一，如何快速、有效地將恢復(fù)的數(shù)據(jù)投入運用，還是離不開IaaS這樣的上層管理軟件。

混合云

混合云災(zāi)備應(yīng)運而生。首先，相比于公有云，通常的私有云規(guī)模很難有足夠大的資源池。資源過多會導(dǎo)致浪費，這是企業(yè)不愿意看到的情況。資源過少則無法應(yīng)對突發(fā)需求，這也是企業(yè)的痛點。其次，公有云都會提供完善的IaaS應(yīng)用編程接口，私有云可以通過編程接口延伸IaaS框架內(nèi)的各種資源需求。由此可見，在打通了公有云的數(shù)據(jù)和網(wǎng)絡(luò)層面后，公有云不但可以應(yīng)對突發(fā)的計算需求，還是一個非常合適的災(zāi)備載體，主要原因如下：

完備的應(yīng)用編程接口

良好的彈性計算能力；

近乎無限的存儲空間。

混合云場景

圖2展示了對接公有云后的混合云場景。對比圖1和圖2，我們也許會發(fā)現(xiàn)，這兩者的區(qū)別和Subversion與Git之間的區(qū)別有些許神似之處——即：系統(tǒng)資源的存取是否集中。

3.混合云災(zāi)備如何實現(xiàn)？

ZStack自有的鏡像倉庫設(shè)計，是實現(xiàn)混合云災(zāi)備的核心。

鏡像倉庫設(shè)計思想

圖3展示了ZStack鏡像倉庫的高層次構(gòu)架。與OpentackGlance，以及DockerRegistry類似，ZStack鏡像倉庫（以下簡稱鏡像倉庫）并不負(fù)責(zé)實際的存儲，只是完成鏡像的管理工作，以及元數(shù)據(jù)的維護。

ZStack鏡像倉庫架構(gòu)

但是鏡像倉庫采用的數(shù)據(jù)組織方式與前述兩者完全不同。簡單來說，鏡像倉庫的數(shù)據(jù)存儲方式與git類似，是一個內(nèi)容可尋址存儲。所有存儲入口都通過一層中間件封裝，實際的存儲工作則由后臺存儲插件完成?？梢詫颖镜卮鎯?，或者AliyunOSS等云存儲。

這種設(shè)計有如下好處：

數(shù)據(jù)存儲和管理邏輯分離；

因為內(nèi)容可尋址，客戶端和服務(wù)器可以分別對所有數(shù)據(jù)（包括元數(shù)據(jù)）做哈希驗證，互不信任；

數(shù)據(jù)不可更改（包括元數(shù)據(jù)），任何更改都會改變哈希值。

說到鏡像的組織，ZStack鏡像倉庫通過元數(shù)據(jù)維護了鏡像之間的關(guān)系，對于鏡像的格式并不關(guān)心。倉庫中的鏡像來源可以是qcow2文件，也可以是RBD鏡像，重建整個鏡像的工作由客戶端負(fù)責(zé)。比如，對于qcow2文件可以用qemu-img工具，而對于RBD鏡像則可以使用rbd工具進(jìn)行管理。

如何用鏡像倉庫實現(xiàn)混合云災(zāi)備

現(xiàn)在我們來看看，如何用鏡像倉庫實現(xiàn)混合云災(zāi)備。

具體來說，我們在鏡像倉庫上實現(xiàn)了push和pull操作，使得不同鏡像倉庫之間可以方便地同步指定鏡像。和git類似：

push是將本地的鏡像推送到遠(yuǎn)程；

pull是將遠(yuǎn)程的鏡像抓取到本地。

ZStack鏡像倉庫的push和pull

對于任意備份在公有云上的鏡像倉庫，其中包含的鏡像和本地鏡像倉庫并無二致。同樣由于內(nèi)容可尋址，在鏡像的傳輸過程中可以避免大量不必要的數(shù)據(jù)傳輸。這一點是非常關(guān)鍵的：

數(shù)據(jù)的完整性可以輕松驗證；

極大地提高了鏡像傳輸速度，節(jié)省了時間；

節(jié)省了出數(shù)據(jù)中心的流量，節(jié)約客戶成本。

在具體實現(xiàn)中，還需要考慮如何處理讀寫沖突、寫寫合并以及橫向擴展等問題。限于篇幅，細(xì)節(jié)不再贅述。

以下是ZStack基于鏡像倉庫的幾個典型災(zāi)備策略。

備份策略

用戶可以對需要備份的虛擬機執(zhí)行手動備份，或者指定備份策略執(zhí)行自動備份。比如，備份間隔時間等等。手動備份能力是必要的，這使得用戶可以及時對虛擬機做備份，避免時間窗口的風(fēng)險。

恢復(fù)虛擬機

當(dāng)用戶對根云盤進(jìn)行備份之后，恢復(fù)虛擬機只需要將遠(yuǎn)程的備份抓取到本地鏡像倉庫，然后創(chuàng)建虛擬機即可。就像開啟了時光隧道，用戶使虛擬機回到任意的備份點。

恢復(fù)數(shù)據(jù)盤

同樣的邏輯也適用于數(shù)據(jù)盤。鏡像倉庫并不區(qū)分根云盤或者數(shù)據(jù)盤。恢復(fù)數(shù)據(jù)盤只需要將遠(yuǎn)程的備份抓取到本地，然后加載到虛擬機。

鏡像倉庫就是這只“魔戒”

綜前所述，鏡像倉庫對本地、異地，rbd以及qcow2，以及不同的存儲后端，都呈現(xiàn)了統(tǒng)一的服務(wù)接口。這是策略與機制分離的典型應(yīng)用，鏡像倉庫只提供鏡像的存儲和維護機制，而對如何使用鏡像毫不關(guān)心。另外，由于鏡像倉庫的數(shù)據(jù)組織特性，倉庫間的數(shù)據(jù)可以按需指定資源同步。正是這種靈活的設(shè)計，為ZStack的災(zāi)備能力提供了堅實的基礎(chǔ)條件。

如果沒有公有云

退一步，用戶沒有對接公有云環(huán)境的狀況下，只要數(shù)據(jù)通道的速度有充分保證，用戶可以異地（比如IDC機房）部署鏡像倉庫，同樣可以很容易地實現(xiàn)異地備份。唯一的缺點在于，如果本地私有云突然發(fā)生災(zāi)難，沒有辦法利用公有云的能力，快速恢復(fù)關(guān)鍵應(yīng)用。

小結(jié)

正如同雞蛋不能放在同一只籃子里，重要的數(shù)據(jù)也不能全都放在本地。隨著硬件能力的不斷進(jìn)步，用戶擁有單位資源的成本在不斷降低，但是數(shù)據(jù)的潛在價值卻在不斷攀升。數(shù)據(jù)越龐大，業(yè)務(wù)規(guī)模越龐大，導(dǎo)致的代價也隨之越來越高昂。擁有災(zāi)備能力，擁有系統(tǒng)化恢復(fù)業(yè)務(wù)的能力，才能全無后顧之憂。在云的世界里，“后悔藥”其實是存在的。

李群，ZStack首席工程師。統(tǒng)籌負(fù)責(zé)ZStack研發(fā)工作，在云計算以及安全領(lǐng)域有豐富的研發(fā)經(jīng)驗。2007年加入EMC云計算基礎(chǔ)設(shè)施部，負(fù)責(zé)通用Appliance平臺的研發(fā)工作；2010年加入Intel開發(fā)者產(chǎn)品部，負(fù)責(zé)SGX指令集的SDK研發(fā)；2015年加入微軟中國云計算創(chuàng)新中心，負(fù)責(zé)Azure中國區(qū)CDN服務(wù)的研發(fā)。

【作者簡介】

李群，ZStack首席工程師。統(tǒng)籌負(fù)責(zé)ZStack研發(fā)工作，在云計算以及安全領(lǐng)域有豐富的研發(fā)經(jīng)驗。2007年加入EMC云計算基礎(chǔ)設(shè)施部，負(fù)責(zé)通用Appliance平臺的研發(fā)工作；2010年加入Intel開發(fā)者產(chǎn)品部，負(fù)責(zé)SGX指令集的SDK研發(fā)；2015年加入微軟中國云計算創(chuàng)新中心，負(fù)責(zé)Azure中國區(qū)CDN服務(wù)的研發(fā)。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。