以虛擬化、超融合、云平臺等為形態(tài)的云化數(shù)據(jù)中心已經(jīng)成為越來越多的企業(yè)機構數(shù)據(jù)中心升級方案。據(jù)權威媒體統(tǒng)計，云每年以25%的速度增加，其中虛擬化滲透率大于80%。云在按需交付、資源池化等方面有先天的優(yōu)勢，但隨之也帶來更多的數(shù)據(jù)和業(yè)務安全風險。無論是自建的云還是公有云，每年都頻繁發(fā)生大量的數(shù)據(jù)安全和業(yè)務中斷事故。
在備份容災管理領域，一方面IT基礎架構的云化變化速度已經(jīng)大大超出了現(xiàn)有的數(shù)據(jù)保護技術的變化速度，而另一方面不少廠商又都聲稱自家的產(chǎn)品可以備份云。那么到底該如何選擇真正適合云化數(shù)據(jù)中心的備份容災系統(tǒng)，本文重點從以下幾個方面展開討論。
什么是云化數(shù)據(jù)中心？
簡單講，就是當業(yè)務需要，數(shù)據(jù)中心可以在數(shù)分鐘內(nèi)增加或減少業(yè)務所需要的計算、存儲、網(wǎng)絡等資源。再簡單講，就是隨時增加或減少可以安裝部署業(yè)務應用軟件的服務器。
自建云化數(shù)據(jù)中心的方案有多種思路，如下：
1、虛擬化為中心的經(jīng)典架構
這種方案是目前最主流的云化數(shù)據(jù)中心方案，主要采用的方案就是虛擬化操作系統(tǒng)、服務器與企業(yè)級集中式存儲，該方案成熟度最高。這種方案，隨著虛擬機規(guī)模增加，底層的集中存儲會越來越感覺到不夠用。這時候需要增加新的存儲或服務器部署，重新遷移或分布虛擬機系統(tǒng)。
2、以OpenStack為代表的開源大集成架構
這套體系接近公有云平臺的體系，主要的3個核心服務都采用高度彈性的方案來構成。隨著引入的服務越多，運維管理復雜度也大幅度提升。目前開源體系最大的問題在于企業(yè)級運維管理的能力較弱，可靠性不能很好保障，可管理性差，易用性方面門檻很高，需要高度依賴商業(yè)發(fā)行版企業(yè)來保障持續(xù)的運行。
這類平臺通常是從幾千到上萬個虛擬機規(guī)模，是一些大型企業(yè)在重點升級的云架構方案。
3、各類公有云的企業(yè)部署版本
國內(nèi)的云計算公司，都相應推出了企業(yè)內(nèi)部部署的版本，與OpenStack的架構類似，核心也包含3大核心服務，以及各類上層應用服務。第2、第3這類通常是一些大型企業(yè)，或者技術運維能力很強的機構才會采用。通常需要企業(yè)自己配置開發(fā)運維團隊。
4、采用商業(yè)超融合的架構
第2、3涉及到的硬件投入、軟件投入以及人力投入都很大，一般的中小企業(yè)都難以部署和運維。超融合把云計算里最核心的能力：虛擬化計算、軟件定義網(wǎng)絡與分布式存儲三大核心服務融合在一起，形成3-4個服務器節(jié)點一組的模塊化方案。
通過分布式文件系統(tǒng)融合服務器集群管理技術，把服務器的存儲能力連接起來，形成可以被服務器共享的存儲池，服務器內(nèi)置的虛擬化操作系統(tǒng)。通過Web管理控制臺，可以為企業(yè)打造按需交付的云平臺。
該方案無需外置其他存儲設備，更容易交付和運維，企業(yè)自建私有云變得簡單很多。通常超融合方案按照3個服務器節(jié)點起進行部署，如果需要擴容，再按3-4個節(jié)點一組進行擴容。
什么樣的備份容災系統(tǒng)才真正適合云化數(shù)據(jù)中心？｜技術頭條
云化數(shù)據(jù)中心與傳統(tǒng)的數(shù)據(jù)中心有何不同？
1、傳統(tǒng)數(shù)據(jù)中心的典型結構
下面我們來看一看傳統(tǒng)數(shù)據(jù)中心的架構示意圖：
一般每臺服務器上跑1-3個業(yè)務不等，各業(yè)務通過不同的安裝目錄和不同網(wǎng)絡端口來隔離。所有服務器數(shù)據(jù)都存入NAS/SAN等集中式存儲。
2、成本與運維效率對比
兩種數(shù)據(jù)中心，由于底層架構不一樣，無論在成本、效率、以及運維管理方法等方面區(qū)別很大。
這也是為什么越來越多的企業(yè)機構加速數(shù)據(jù)中心云化，只有這樣才能更敏捷支持業(yè)務發(fā)展需求，提高資源利用率。
3、數(shù)據(jù)備份和業(yè)務連續(xù)運行保護模型對比
傳統(tǒng)數(shù)據(jù)中心和云化數(shù)據(jù)中心在保護模型上，區(qū)別非常大。了解這些區(qū)別后，才有利于我們選擇合適的保護方案。
當前的云化數(shù)據(jù)中心數(shù)據(jù)備份容災現(xiàn)狀
1、用物理機時代設計的保護模型保護云
國內(nèi)外一些廠家產(chǎn)品都源于物理機保護的模型，延展到虛擬化領域。其基本的架構設計模型如下：
基本上就是一個簡單的集成架構，把備份軟件部署到服務器上，然后交付到客戶。增加了虛擬機備份支持，本質上，在保護架構設計上沒有特別變化。
2、保護容量固定
通常這類架構在底層選用的備份存儲容量上，很固定。廠家在做方案時候，通常會考慮預留較大的空間用于備份數(shù)據(jù)增長的需求。
這會帶來兩個問題，一是初次投入較高，二是無法適應云數(shù)據(jù)規(guī)模增長的需求。最終空間會用滿，這時候必須增加新的設備。增加新的設備，由于設備之間相互獨立。勢必會帶來維護、遷移和更多的數(shù)據(jù)存儲開銷。
3、備份策略模型笨重
傳統(tǒng)備份方案有全量、增量、差異備份方式。由于一直以來，考慮到底層存儲和各種情況導致的數(shù)據(jù)錯誤，廠商通常采用幾種方式結合的方案來保護物理機模型的備份數(shù)據(jù)。其中全量模型，會大幅度增加系統(tǒng)的存儲開銷，在云場景由于數(shù)據(jù)量大數(shù)十倍，顯然是不合適的。
4、恢復速度慢
物理機時代設計的數(shù)據(jù)恢復方案，通常考慮的是數(shù)據(jù)回寫恢復的方式。這種方式在數(shù)據(jù)規(guī)模不大的情況下，可以工作得很好。一旦數(shù)據(jù)規(guī)模很大的時候，這種方式恢復效率非常低。
5、容災粒度粗
在傳統(tǒng)物理機數(shù)據(jù)中心時代，關鍵業(yè)務要做容災保護，通常采用的是存儲級復制方案。這種方案，在物理機時代工作得很好。通常一些重要業(yè)務如數(shù)據(jù)庫等是獨享存儲資源的。
在云化時代，所有的業(yè)務都共享存儲，采用這種復制方案，顯然是缺少優(yōu)先級、重要性區(qū)分。在異地容災效率方面，不能很好地解決業(yè)務重要性和業(yè)務帶寬資源分配的關聯(lián)關系。
具備云化數(shù)據(jù)中心級保護能力的備份系統(tǒng)的八個特征
特征一、支持虛擬化在線全增量即時合成模式的備份
通過云平臺輸出的API來備份數(shù)據(jù)，而不是安裝客戶端去備份Guest虛擬機內(nèi)部數(shù)據(jù)。通過云平臺輸出的API來備份數(shù)據(jù)的兼容性好，數(shù)據(jù)一致性更能得到保障。
在備份模型選擇上，選用全增量模型備份是非常有必要。第一次采用全量備份，第2次以后采用增量備份方式，可以最有效的降低數(shù)據(jù)讀取量，減少網(wǎng)絡傳輸，最大程度提高備份系統(tǒng)的效率。同時系統(tǒng)可以根據(jù)增量數(shù)據(jù)即時合成為全量版本，用于快速恢復。
特征二、支持Scale Out模型的擴展方案
雖然可以采用插滿硬盤槽位（ScaleUp）或多臺組合的方案，來備份整個云數(shù)據(jù)中心。但這不是最佳實踐。這種方式會大幅度提高運維管理難度。人為的分割和遷移數(shù)據(jù)、任務。規(guī)模越大，這種方案越難用。到了上千節(jié)點的規(guī)模，涉及數(shù)百TB到PB級數(shù)據(jù)，一般的方案需要多臺設備（10臺到20臺不等）組合到一起，這種方案幾乎難以實際運用。
應云而生的是Scale Out的橫向擴展模型。簡單來說，就是一組一組地擴展，而組與組之間可以無縫融合成一個大組。所有組內(nèi)的服務器節(jié)點數(shù)據(jù)都是共享的。另外，系統(tǒng)也能自動平衡內(nèi)部的數(shù)據(jù)和任務分布。數(shù)據(jù)存儲和任務處理性能，同步提升。
Scale Out模型理論上能達到無上限的數(shù)據(jù)存儲能力和保護能力。
特征三、集群范圍的全局數(shù)據(jù)處理消重壓縮能力
不少的備份廠家產(chǎn)品是支持數(shù)據(jù)消重技術，但由于架構設計的原因，也僅僅是在單套系統(tǒng)內(nèi)部。單套系統(tǒng)保護的云主機規(guī)模有限，重刪效果也大大降低。
對于高度重復的云化數(shù)據(jù)中心來說，備份系統(tǒng)具備集群范圍的消重壓縮能力，是一個關鍵指標，一些情況甚至高達90%的重復比例。如果用傳統(tǒng)的方案，會投入數(shù)倍的成本來存儲重復的數(shù)據(jù)。對于一些數(shù)千個云節(jié)點的大規(guī)模云平臺，這將是巨大的投入。
特征四、批量并發(fā)即時恢復能力
如果還是按照現(xiàn)有的傳統(tǒng)數(shù)據(jù)恢復方案，對于高度敏捷的云平臺，慢如蝸牛的恢復速度，顯然是不能容忍的。即時恢復，就是采用先在數(shù)分鐘內(nèi)（最短時間）應急恢復業(yè)務，然后再在線遷移。
批量即時恢復能力要求備份系統(tǒng)能夠識別和支持并發(fā)的隨機IO流，并能很好的支持并發(fā)頻繁的隨機IO讀寫需求。
特征五、多節(jié)點對等任務并行執(zhí)行能力
云平臺天生就是節(jié)點數(shù)量多，數(shù)據(jù)量大。
對于備份系統(tǒng)，是否能并行處理任務顯得非常重要。否則是無法有效、即時保護好整個云平臺?，F(xiàn)有的方案還未準備好去支持數(shù)以百計的并行備份任務。
云平臺的備份系統(tǒng)，不僅要求能夠保護更多的任務，同時應該能夠具備在集群備份系統(tǒng)內(nèi)部，任務可以在失敗后，跨節(jié)點執(zhí)行，以滿足更高的可靠性要求。
特征六、無限制版本管理能力
內(nèi)置無限制的版本管理能力，可以有效提高云平臺數(shù)據(jù)應用能力。無論1個月前、2個月前、3個月前的數(shù)據(jù)，都可以得到有效的恢復、復制、克隆等。
區(qū)別與云自己的快照，該能力可以基于任何歷史點執(zhí)行任意多次的恢復、克隆、讀寫等。
特征七、細粒度恢復和數(shù)據(jù)復制能力
備份系統(tǒng)既能夠備份整體云主機（虛擬機）數(shù)據(jù)，也需要能夠執(zhí)行文件級的數(shù)據(jù)恢復能力，根據(jù)業(yè)務情況組合使用。
對于執(zhí)行異地容災的場景，任務級粒度復制數(shù)據(jù)，可以有效降低帶寬的使用，優(yōu)先保護好重要業(yè)務。
特征八、備份系統(tǒng)能夠輸出管理API
備份系統(tǒng)能夠輸出管理API，可以更加容易管理生產(chǎn)系統(tǒng)和備份系統(tǒng)。輕松集成在云管理平臺，或企業(yè)IT集中管理平臺。使得整個備份流程更加容易根據(jù)企業(yè)需求自動化統(tǒng)一管理。
關于云化數(shù)據(jù)中心備份容災選擇常見的幾個誤區(qū)
1、支持了虛擬機備份就是云架構的備份系統(tǒng)
支持虛擬機備份是基本條件，而通過云平臺輸出的備份API來備份虛擬機系統(tǒng)是云架構的備份系統(tǒng)的必要條件。
云架構備份系統(tǒng)工作是否良好，除了能支持基本的備份外，備份速度是否高，備份效率是否高，是否能快速恢復業(yè)務、是否能支持API對接等，都是需要考慮的。
2、過度依賴品牌，品牌越知名越放心
在傳統(tǒng)以物理機為基礎構建的數(shù)據(jù)中心，以品牌來選擇是合情合理。很多廠家的方案都是超過十年以上的研發(fā)，積累了大量的數(shù)據(jù)備份容災實踐。
尤其是一些一線大品牌，甚至超過20年的歷史，對數(shù)據(jù)庫、操作系統(tǒng)、小型機以及各種變形的高可用架構的保護，都非常擅長。
但在云化數(shù)據(jù)中心時代，由于IT架構的變化很大，大品牌擅長的兼容性、可靠性、性能、備份模型全都優(yōu)勢不再，一切從零開始。大公司、創(chuàng)新品牌都是從同一起點出發(fā)。誰起步早？誰更專注？誰就越有優(yōu)勢，誰就能最早適應客戶的云場景。
3、備份軟件安裝在客戶機系統(tǒng)里（Guest OS）
在客戶機操作系統(tǒng)里面安裝客戶端的方案，這是保護物理機的方案。如果一臺宿主機通過云化系統(tǒng)虛擬出10個客戶機系統(tǒng)，就需要安裝10個客戶端。這種方式，運維管理復雜，也額外會占用更多的系統(tǒng)資源。
這種方案，對客戶端的設計會提出更高的要求。直接拿備份物理機的軟件過來在客戶機內(nèi)部部署，這是最差的方案。
4、備份系統(tǒng)的容量按照物理機應用數(shù)據(jù)模型估算
根據(jù)應用數(shù)據(jù)的規(guī)模和增長，來確定保護容量是傳統(tǒng)數(shù)據(jù)中心保護方案常用的方案。云化時代，需要重新根據(jù)系統(tǒng)和應用數(shù)據(jù)兩個維度來估算備份系統(tǒng)的容量，才能達到最好的保護和應用效果。
5、不考慮平滑的擴容方案
在傳統(tǒng)數(shù)據(jù)中心，備份系統(tǒng)配置的容量一般能很好支持3年以上的運行，所以擴容不是最需要考慮的要素。在方案的選擇上，擴容不是最迫切的需求點。
而在云化時代，數(shù)據(jù)增長與變化的速度會很快。半年到一年的擴容周期是非常正常。因此拿已有的經(jīng)驗去確定方案，后期的成本更高，系統(tǒng)升級、擴容、遷移等管理就很復雜。
后記
在云時代，數(shù)據(jù)保護和管理的應用場景已經(jīng)在發(fā)生革命性的變化，但很多用戶和行業(yè)從業(yè)者還停留在傳統(tǒng)架構中來思考和選擇解決方案，這勢必將更多的云環(huán)境下的數(shù)據(jù)置于無有效保護的險境之中。
