什麼樣的備份容災系統才真正適合雲化數據中心？

作者 | 陳元強

責編 | 郭芮

以虛擬化、超融合、雲平台等為形態的雲化數據中心已經成為越來越多的企業機構數據中心升級方案。據權威媒體統計，雲每年以25%的速度增加，其中虛擬化滲透率大於80%。雲在按需交付、資源池化等方面有先天的優勢，但隨之也帶來更多的數據和業務安全風險。無論是自建的雲還是公有雲，每年都頻繁發生大量的數據安全和業務中斷事故。

在備份容災管理領域，一方面IT基礎架構的雲化變化速度已經大大超出了現有的數據保護技術的變化速度，而另一方面不少廠商又都聲稱自家的產品可以備份雲。那麼到底該如何選擇真正適合雲化數據中心的備份容災系統，本文重點從以下幾個方面展開討論。

什麼是雲化數據中心？

簡單講，就是當業務需要，數據中心可以在數分鐘內增加或減少業務所需要的計算、存儲、網路等資源。再簡單講，就是隨時增加或減少可以安裝部署業務應用軟體的伺服器。

自建雲化數據中心的方案有多種思路，如下：

1、虛擬化為中心的經典架構

這種方案是目前最主流的雲化數據中心方案，主要採用的方案就是虛擬化操作系統、伺服器與企業級集中式存儲，該方案成熟度最高。這種方案，隨著虛擬機規模增加，底層的集中存儲會越來越感覺到不夠用。這時候需要增加新的存儲或伺服器部署，重新遷移或分布虛擬機系統。

2、以OpenStack為代表的開源大集成架構

這套體系接近公有雲平台的體系，主要的3個核心服務都採用高度彈性的方案來構成。隨著引入的服務越多，運維管理複雜度也大幅度提升。目前開源體系最大的問題在於企業級運維管理的能力較弱，可靠性不能很好保障，可管理性差，易用性方面門檻很高，需要高度依賴商業發行版企業來保障持續的運行。

這類平台通常是從幾千到上萬個虛擬機規模，是一些大型企業在重點升級的雲架構方案。

3、各類公有雲的企業部署版本

國內的雲計算公司，都相應推出了企業內部部署的版本，與OpenStack的架構類似，核心也包含3大核心服務，以及各類上層應用服務。第2、第3這類通常是一些大型企業，或者技術運維能力很強的機構才會採用。通常需要企業自己配置開發運維團隊。

4、採用商業超融合的架構

第2、3涉及到的硬體投入、軟體投入以及人力投入都很大，一般的中小企業都難以部署和運維。超融合把雲計算里最核心的能力：虛擬化計算、軟體定義網路與分散式存儲三大核心服務融合在一起，形成3-4個伺服器節點一組的模塊化方案。

通過分散式文件系統融合伺服器集群管理技術，把伺服器的存儲能力連接起來，形成可以被伺服器共享的存儲池，伺服器內置的虛擬化操作系統。通過Web 管理控制台，可以為企業打造按需交付的雲平台。

該方案無需外置其他存儲設備，更容易交付和運維，企業自建私有雲變得簡單很多。通常超融合方案按照3 個伺服器節點起進行部署，如果需要擴容，再按3-4個節點一組進行擴容。

雲化數據中心與傳統的數據中心有何不同？

1、傳統數據中心的典型結構

下面我們來看一看傳統數據中心的架構示意圖：

一般每台伺服器上跑1-3個業務不等，各業務通過不同的安裝目錄和不同網路埠來隔離。所有伺服器數據都存入NAS/SAN 等集中式存儲。

2、成本與運維效率對比

兩種數據中心，由於底層架構不一樣，無論在成本、效率、以及運維管理方法等方面區別很大。

這也是為什麼越來越多的企業機構加速數據中心雲化，只有這樣才能更敏捷支持業務發展需求，提高資源利用率。

3、數據備份和業務連續運行保護模型對比

傳統數據中心和雲化數據中心在保護模型上，區別非常大。了解這些區別後，才有利於我們選擇合適的保護方案。

當前的雲化數據中心數據備份容災現狀

1、用物理機時代設計的保護模型保護雲

國內外一些廠家產品都源於物理機保護的模型，延展到虛擬化領域。其基本的架構設計模型如下：

基本上就是一個簡單的集成架構，把備份軟體部署到伺服器上，然後交付到客戶。增加了虛擬機備份支持，本質上，在保護架構設計上沒有特別變化。

2、保護容量固定

通常這類架構在底層選用的備份存儲容量上，很固定。廠家在做方案時候，通常會考慮預留較大的空間用於備份數據增長的需求。

這會帶來兩個問題，一是初次投入較高，二是無法適應雲數據規模增長的需求。最終空間會用滿，這時候必須增加新的設備。增加新的設備，由於設備之間相互獨立。勢必會帶來維護、遷移和更多的數據存儲開銷。

3、備份策略模型笨重

傳統備份方案有全量、增量、差異備份方式。由於一直以來，考慮到底層存儲和各種情況導致的數據錯誤，廠商通常採用幾種方式結合的方案來保護物理機模型的備份數據。其中全量模型，會大幅度增加系統的存儲開銷，在雲場景由於數據量大數十倍，顯然是不合適的。

4、恢復速度慢

物理機時代設計的數據恢復方案，通常考慮的是數據回寫恢復的方式。這種方式在數據規模不大的情況下，可以工作得很好。一旦數據規模很大的時候，這種方式恢復效率非常低。

5、容災粒度粗

在傳統物理機數據中心時代，關鍵業務要做容災保護，通常採用的是存儲級複製方案。這種方案，在物理機時代工作得很好。通常一些重要業務如資料庫等是獨享存儲資源的。

在雲化時代，所有的業務都共享存儲，採用這種複製方案，顯然是缺少優先順序、重要性區分。在異地容災效率方面，不能很好地解決業務重要性和業務帶寬資源分配的關聯關係。

具備雲化數據中心級保護能力的備份系統的八個特徵

特徵一、支持虛擬化在線全增量即時合成模式的備份

通過雲平台輸出的API來備份數據，而不是安裝客戶端去備份Guest虛擬機內部數據。通過雲平台輸出的API 來備份數據的兼容性好，數據一致性更能得到保障。

在備份模型選擇上，選用全增量模型備份是非常有必要。第一次採用全量備份，第2次以後採用增量備份方式，可以最有效的降低數據讀取量，減少網路傳輸，最大程度提高備份系統的效率。同時系統可以根據增量數據即時合成為全量版本，用於快速恢復。

特徵二、支持Scale Out模型的擴展方案

雖然可以採用插滿硬碟槽位（ScaleUp）或多台組合的方案，來備份整個雲數據中心。但這不是最佳實踐。這種方式會大幅度提高運維管理難度。人為的分割和遷移數據、任務。規模越大，這種方案越難用。到了上千節點的規模，涉及數百TB 到PB 級數據，一般的方案需要多台設備（10 台到20 台不等）組合到一起，這種方案幾乎難以實際運用。

應雲而生的是Scale Out 的橫向擴展模型。簡單來說，就是一組一組地擴展，而組與組之間可以無縫融合成一個大組。所有組內的伺服器節點數據都是共享的。另外，系統也能自動平衡內部的數據和任務分布。數據存儲和任務處理性能，同步提升。

Scale Out 模型理論上能達到無上限的數據存儲能力和保護能力。

特徵三、集群範圍的全局數據處理消重壓縮能力

不少的備份廠家產品是支持數據消重技術，但由於架構設計的原因，也僅僅是在單套系統內部。單套系統保護的雲主機規模有限，重刪效果也大大降低。

對於高度重複的雲化數據中心來說，備份系統具備集群範圍的消重壓縮能力，是一個關鍵指標，一些情況甚至高達90%的重複比例。如果用傳統的方案，會投入數倍的成本來存儲重複的數據。對於一些數千個雲節點的大規模雲平台，這將是巨大的投入。

特徵四、批量並發即時恢復能力

如果還是按照現有的傳統數據恢復方案，對於高度敏捷的雲平台，慢如蝸牛的恢復速度，顯然是不能容忍的。即時恢復，就是採用先在數分鐘內（最短時間）應急恢復業務，然後再在線遷移。

批量即時恢復能力要求備份系統能夠識別和支持並發的隨機IO 流，並能很好的支持並發頻繁的隨機IO 讀寫需求。

特徵五、多節點對等任務並行執行能力

雲平台天生就是節點數量多，數據量大。

對於備份系統，是否能並行處理任務顯得非常重要。否則是無法有效、即時保護好整個雲平台。現有的方案還未準備好去支持數以百計的並行備份任務。

雲平台的備份系統，不僅要求能夠保護更多的任務，同時應該能夠具備在集群備份系統內部，任務可以在失敗後，跨節點執行，以滿足更高的可靠性要求。

特徵六、無限制版本管理能力

內置無限制的版本管理能力，可以有效提高雲平台數據應用能力。無論1 個月前、2 個月前、3 個月前的數據，都可以得到有效的恢復、複製、克隆等。

區別與雲自己的快照，該能力可以基於任何歷史點執行任意多次的恢復、克隆、讀寫等。

特徵七、細粒度恢復和數據複製能力

備份系統既能夠備份整體雲主機（虛擬機）數據，也需要能夠執行文件級的數據恢復能力，根據業務情況組合使用。

對於執行異地容災的場景，任務級粒度複製數據，可以有效降低帶寬的使用，優先保護好重要業務。

特徵八、備份系統能夠輸出管理API

備份系統能夠輸出管理API ，可以更加容易管理生產系統和備份系統。輕鬆集成在雲管理平台，或企業IT 集中管理平台。使得整個備份流程更加容易根據企業需求自動化統一管理。

關於雲化數據中心備份容災選擇常見的幾個誤區

1、支持了虛擬機備份就是雲架構的備份系統

支持虛擬機備份是基本條件，而通過雲平台輸出的備份API 來備份虛擬機系統是雲架構的備份系統的必要條件。

雲架構備份系統工作是否良好，除了能支持基本的備份外，備份速度是否高，備份效率是否高，是否能快速恢復業務、是否能支持API 對接等，都是需要考慮的。

2、過度依賴品牌，品牌越知名越放心

在傳統以物理機為基礎構建的數據中心，以品牌來選擇是合情合理。很多廠家的方案都是超過十年以上的研發，積累了大量的數據備份容災實踐。

尤其是一些一線大品牌，甚至超過20 年的歷史，對資料庫、操作系統、小型機以及各種變形的高可用架構的保護，都非常擅長。

但在雲化數據中心時代，由於IT 架構的變化很大，大品牌擅長的兼容性、可靠性、性能、備份模型全都優勢不再，一切從零開始。大公司、創新品牌都是從同一起點出發。誰起步早？誰更專註？誰就越有優勢，誰就能最早適應客戶的雲場景。

3、備份軟體安裝在客戶機系統里（Guest OS）

在客戶機操作系統裡面安裝客戶端的方案，這是保護物理機的方案。如果一台宿主機通過雲化系統虛擬出10 個客戶機系統，就需要安裝10 個客戶端。這種方式，運維管理複雜，也額外會佔用更多的系統資源。

這種方案，對客戶端的設計會提出更高的要求。直接拿備份物理機的軟體過來在客戶機內部部署，這是最差的方案。

4、備份系統的容量按照物理機應用數據模型估算

根據應用數據的規模和增長，來確定保護容量是傳統數據中心保護方案常用的方案。雲化時代，需要重新根據系統和應用數據兩個維度來估算備份系統的容量，才能達到最好的保護和應用效果。

5、不考慮平滑的擴容方案

在傳統數據中心，備份系統配置的容量一般能很好支持3 年以上的運行，所以擴容不是最需要考慮的要素。在方案的選擇上，擴容不是最迫切的需求點。

而在雲化時代，數據增長與變化的速度會很快。半年到一年的擴容周期是非常正常。因此拿已有的經驗去確定方案，後期的成本更高，系統升級、擴容、遷移等管理就很複雜。

後記

在雲時代，數據保護和管理的應用場景已經在發生革命性的變化，但很多用戶和行業從業者還停留在傳統架構中來思考和選擇解決方案，這勢必將更多的雲環境下的數據置於無有效保護的險境之中。

本文從技術層面剖析，拋磚引玉，歡迎大家交流。

作者：陳元強，深圳市木浪雲數據有限公司聯合創始人 & CEO，木浪云云數據管理創建人，多備份在線備份雲服務創始人。超過18年網路與數據安全、分散式系統與海量業務架構設計、雲服務創業等經歷，曾就職於騰訊盛大、宜搜、永達，並擔任大數據、搜索、移動、信息安全等業務線總監崗位。曾發起創立騰訊第1 套具有核心專利技術百億級實時大數據平台，更早負責永達大型網路安全管理平台研發（保護全國鐵路客票核心業務系統和數十萬節點安全），防DDOS 系統研發等。

聲明：本文為作者投稿，版權歸對方所有。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！