1、引言

　　云計(jì)算是一種新型的業(yè)務(wù)模式，能夠?yàn)閿?shù)據(jù)中心廠商節(jié)約能耗，提高設(shè)備利用率，并突破傳統(tǒng)服務(wù)模式開展多樣化的創(chuàng)新商業(yè)服務(wù)模式；用戶可以不用自己購(gòu)買IT固定資產(chǎn)，而通過(guò)VDC (Virtual Data Center，虛擬數(shù)據(jù)中心)服務(wù)提供商按需租用自己所需的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)資源，并可隨時(shí)隨需擴(kuò)展、新增、停租資源。

　　云計(jì)算基礎(chǔ)設(shè)施即服務(wù)IaaS(Infrastructure as a Service)業(yè)務(wù)模式最典型的應(yīng)用場(chǎng)景是虛擬數(shù)據(jù)中心，該業(yè)務(wù)模式的出現(xiàn)將計(jì)算機(jī)系統(tǒng)的維護(hù)進(jìn)行了細(xì)分，由服務(wù)供應(yīng)鏈的各方各司其職：用戶只需考慮其自身應(yīng)用基于虛擬環(huán)境的部署架構(gòu)，VDC服務(wù)提供商只需考慮將硬件資源池化并保證服務(wù)可用性，硬件廠商只需考慮底層設(shè)備對(duì)虛擬化環(huán)境的支持和優(yōu)化。維護(hù)重點(diǎn)細(xì)分之后，應(yīng)對(duì)風(fēng)險(xiǎn)的責(zé)任也就細(xì)分了。因此云計(jì)算環(huán)境下的災(zāi)難應(yīng)對(duì)并不是服務(wù)供應(yīng)鏈中只有某一方需要考慮的問題，而是需要各方基于各自責(zé)任范圍形成協(xié)調(diào)一致的措施，這樣才能在災(zāi)難來(lái)臨時(shí)最大程度的減小損失。

　　本文探討了云計(jì)算IaaS服務(wù)提供商和用戶應(yīng)對(duì)災(zāi)難的策略，并提出了一種VDC容災(zāi)架構(gòu)。

　　2、災(zāi)難的定義和分類

　　根據(jù)原國(guó)務(wù)院信息化工作辦公室的定義，災(zāi)難是指由于人為或自然的原因，造成信息系統(tǒng)運(yùn)行嚴(yán)重故障或癱瘓，使信息系統(tǒng)支持的業(yè)務(wù)功能停頓或服務(wù)水平不可接受、達(dá)到特定的時(shí)間的突發(fā)性事件，通常導(dǎo)致信息系統(tǒng)需要切換到備用場(chǎng)地運(yùn)行。根據(jù)這一定義，災(zāi)難不僅指海嘯、地震等自然災(zāi)害，還包括其它任何由無(wú)法預(yù)知的原因引起的服務(wù)不可用。IT服務(wù)的失效能夠直接導(dǎo)致企業(yè)實(shí)現(xiàn)核心價(jià)值的關(guān)鍵業(yè)務(wù)系統(tǒng)受到重創(chuàng)。例如，銀行的ATM機(jī)失效、網(wǎng)站的網(wǎng)頁(yè)無(wú)法訪問、證券的交易系統(tǒng)失靈、數(shù)據(jù)中心的網(wǎng)絡(luò)阻塞等，最終將導(dǎo)致致命的傷害，造成不可挽回的損失。

　　我們將災(zāi)難進(jìn)一步細(xì)分，按照人為因素的多少分為以下三類：

　　(1)非人為自然災(zāi)難：海嘯、地震等區(qū)域毀滅性災(zāi)難；

　　(2)人為非技術(shù)性災(zāi)難：火災(zāi)、停電、人員損失等局部臨時(shí)性災(zāi)難；

　　(3)人為技術(shù)性災(zāi)難：設(shè)備故障、邏輯缺陷、人為操作失誤等可優(yōu)化災(zāi)難。

　　3、VDC業(yè)務(wù)各方需應(yīng)對(duì)的災(zāi)難

　　對(duì)于VDC業(yè)務(wù)來(lái)說(shuō)，應(yīng)對(duì)第一、第二類災(zāi)難主要依托預(yù)先制定的容災(zāi)預(yù)案；應(yīng)對(duì)第三類災(zāi)難主要依托密集型的技術(shù)干預(yù)，服務(wù)架構(gòu)越復(fù)雜，引起第三類災(zāi)難的風(fēng)險(xiǎn)環(huán)節(jié)就越多，但與第一、第二類災(zāi)難不同的是，第三類災(zāi)難可通過(guò)整改措施轉(zhuǎn)變?yōu)椤耙淮涡詾?zāi)難”，降低重復(fù)發(fā)生的可能性。

　　VDC服務(wù)提供商和VDC用戶都會(huì)面臨以上三類災(zāi)難，但各自的應(yīng)對(duì)和預(yù)防措施不同。

　　3.1VDC提供商需要應(yīng)對(duì)的災(zāi)難

　　一個(gè)配置準(zhǔn)確、正常運(yùn)營(yíng)的VDC能夠讓租戶通過(guò)云管理平臺(tái)在15分鐘內(nèi)獲得所申請(qǐng)的資源，并且可以隨時(shí)按需關(guān)閉、新增和擴(kuò)展虛擬服務(wù)器，這是VDC提供商IaaS服務(wù)的基本特點(diǎn)。其服務(wù)架構(gòu)可以分為資源層、業(yè)務(wù)層、展現(xiàn)層，其中任何一層都有出現(xiàn)異常的可能，具體可以表現(xiàn)為：

　　(1)資源層設(shè)備損壞(三類災(zāi)難都可能引起)；

　　(2)資源層網(wǎng)絡(luò)受培；

　　(3)資源層主機(jī)系統(tǒng)故障；

　　(4)業(yè)務(wù)層調(diào)度邏輯錯(cuò)誤；

　　(5)業(yè)務(wù)層拒絕服務(wù)；

　　(6)展現(xiàn)層拒絕服務(wù)；

　　(7)其它無(wú)法預(yù)知的技術(shù)故障。

　　以上這些異常每一種都會(huì)引起服務(wù)不可用。架構(gòu)中各模塊之間有相互依賴邏輯，一處技術(shù)故障經(jīng)常會(huì)引起“連鎖反應(yīng)”，導(dǎo)致多個(gè)環(huán)節(jié)異常，增加系統(tǒng)管理的復(fù)雜度，從而導(dǎo)致服務(wù)不可用時(shí)間的延長(zhǎng)。

　　三類災(zāi)難的發(fā)生雖然不可預(yù)知，但通過(guò)執(zhí)行預(yù)先制定的容災(zāi)預(yù)案，VDC提供商可以將由非人為自然災(zāi)難和人為非技術(shù)性災(zāi)難引起的服務(wù)間斷控制在最小范圍。技術(shù)性災(zāi)難則需要VDC提供商通過(guò)自身的技術(shù)力量準(zhǔn)確定位、排除，并對(duì)服務(wù)架構(gòu)進(jìn)行鞏固和預(yù)防。災(zāi)難的應(yīng)對(duì)直接影響VDC服務(wù)的可靠性和穩(wěn)定性，是其服務(wù)質(zhì)量的關(guān)鍵因素，也是VDC實(shí)現(xiàn)服務(wù)級(jí)別協(xié)議SLA(Service Level Agreement)管理的關(guān)鍵因素之一。

　　3.2VDC用戶需要應(yīng)對(duì)的災(zāi)難

　　對(duì)于3.1節(jié)描述的災(zāi)難，VDC服務(wù)提供商有完備的應(yīng)急和應(yīng)對(duì)措施，VDC用戶在此基礎(chǔ)上可充分利用云服務(wù)資源申請(qǐng)的自動(dòng)、快捷、方便，進(jìn)一步為自身應(yīng)用設(shè)置靈活的容災(zāi)策略。然而另有一些災(zāi)難因素是VDC提供商無(wú)能為力的，用戶必須考慮跨VDC提供商的災(zāi)備方案來(lái)解決，這些因素包括：

　　(1)VDC提供商轉(zhuǎn)變經(jīng)營(yíng)策略，不再提供云計(jì)算服務(wù)，所有設(shè)備移作他用；

　　(2)VDC提供商宣告破產(chǎn)，所有設(shè)備去向不明。對(duì)于此類災(zāi)難的用戶應(yīng)對(duì)措施將在5.2節(jié)詳細(xì)描述。

　　4、云提供商應(yīng)對(duì)災(zāi)難的措施

　　4.1基礎(chǔ)設(shè)施要求

　　資源層是云計(jì)算服務(wù)架構(gòu)的最底層，為了面對(duì)不可預(yù)知的災(zāi)難，VDC提供商必須準(zhǔn)確了解各有關(guān)基礎(chǔ)設(shè)施資源的特性，并在合適的位置設(shè)置合適的基礎(chǔ)設(shè)施資源。

　　4.1.1網(wǎng)絡(luò)是關(guān)鍵

　　云計(jì)算以網(wǎng)絡(luò)為依托，網(wǎng)絡(luò)通暢是云計(jì)算服務(wù)的根本保障。VDC服務(wù)區(qū)域內(nèi)部的物理主機(jī)連接(本地網(wǎng))、跨域調(diào)度的連接(主干網(wǎng))、對(duì)外提供服務(wù)的業(yè)務(wù)連接(外網(wǎng))是不同層次的網(wǎng)絡(luò)，各自的流量帶寬要求不同，發(fā)揮的功能也不同。所有資源的調(diào)度、備份算法、容災(zāi)策略都運(yùn)行在滿足各自需求的網(wǎng)絡(luò)上，網(wǎng)絡(luò)異常造成的擁堵輕則影響用戶體驗(yàn)，重則導(dǎo)致服務(wù)中斷。以下以亞馬遜云計(jì)算服務(wù)曾經(jīng)出現(xiàn)的事故來(lái)說(shuō)明這一點(diǎn)。

　　亞馬遜互聯(lián)網(wǎng)絡(luò)服務(wù)(Amazon Web Service，簡(jiǎn)稱“AWS”)，服務(wù)區(qū)域內(nèi)部的主機(jī)連接分為兩類，一類為高性能的、高吞吐能力的連接彈性計(jì)算云(Elastic Comute Cloud，簡(jiǎn)稱“EC2”)和彈性存儲(chǔ)塊(Elastic Block Store，簡(jiǎn)稱“EBS”)的業(yè)務(wù)網(wǎng)，另一類為穩(wěn)定的、低吞吐能力的連接EBS和容災(zāi)存儲(chǔ)的備份網(wǎng)。2011年4月21日，AWS維護(hù)工程師為北美某服務(wù)區(qū)域的EBS擴(kuò)容，在設(shè)備與網(wǎng)絡(luò)相連時(shí)，誤將EC2與EBS之間的連接接入備份網(wǎng)，同時(shí)造成了業(yè)務(wù)和備份服務(wù)的網(wǎng)絡(luò)阻塞，由此觸發(fā)了一系列的災(zāi)難；

　　(1)因業(yè)務(wù)擁堵直接造成該服務(wù)區(qū)的虛擬機(jī)(VM)無(wú)法響應(yīng)對(duì)塊存儲(chǔ)的讀寫操作，用戶無(wú)法新建虛擬機(jī)；

　　(2)因備份服務(wù)的網(wǎng)絡(luò)擁堵直接導(dǎo)致13%的容災(zāi)存儲(chǔ)被擠下線；

　　(3)網(wǎng)絡(luò)設(shè)置恢復(fù)后，因容災(zāi)備份的觸發(fā)，起初無(wú)法找到備份副本的EBS大面積同時(shí)啟動(dòng)副本重建，備份網(wǎng)絡(luò)再次擁堵；

　　(4)容災(zāi)存儲(chǔ)消耗過(guò)快，無(wú)法找到備份所需存儲(chǔ)資源的EBS始終處于重新尋找資源(re-mirroring)的狀態(tài)中；

　　(5)調(diào)度服務(wù)器接收不到EBS的備份反饋，進(jìn)程無(wú)法釋放，進(jìn)程數(shù)很快占滿，開始拒絕接收新的調(diào)度服務(wù)，導(dǎo)致其它服務(wù)區(qū)域的請(qǐng)求不被響應(yīng)。

　　AWS花了3天時(shí)間將該連鎖反應(yīng)導(dǎo)致的異常數(shù)據(jù)量減小到了0.2%，1周的時(shí)間讓系統(tǒng)完全恢復(fù)正常運(yùn)作。由此給AWS帶來(lái)的經(jīng)濟(jì)損失為故障服務(wù)區(qū)域10天的營(yíng)業(yè)額(AWS為補(bǔ)償用戶作出的決策)；故障發(fā)生期間給用戶帶來(lái)的損失是無(wú)法估量的，期間有數(shù)10個(gè)網(wǎng)站用戶的站點(diǎn)無(wú)法啟動(dòng)和被訪問。

　　當(dāng)然，這里不是暗示在VDC架構(gòu)設(shè)計(jì)的時(shí)候在所有的網(wǎng)絡(luò)連接上都使用高速、高吞吐量的設(shè)備，而是強(qiáng)調(diào)在做組件架構(gòu)、制定容災(zāi)策略的時(shí)候需要充分考慮網(wǎng)絡(luò)能力以及制定合理的業(yè)務(wù)響應(yīng)邏輯方案來(lái)應(yīng)對(duì)出現(xiàn)網(wǎng)絡(luò)擁堵的情況。

　　4.1.2主存儲(chǔ)與容災(zāi)存儲(chǔ)的存儲(chǔ)模式區(qū)別

　　業(yè)務(wù)數(shù)據(jù)和容災(zāi)數(shù)據(jù)對(duì)底層存儲(chǔ)的需求不同，使用的存儲(chǔ)設(shè)備也不同，表1列舉了業(yè)務(wù)存儲(chǔ)(主存儲(chǔ))和容災(zāi)存儲(chǔ)的需求區(qū)別。
 

　　用戶日常業(yè)務(wù)需要的、VDC提供IaaS服務(wù)必不可少的物理存儲(chǔ)設(shè)備即為主存儲(chǔ)，主存儲(chǔ)提供模板庫(kù)和彈性存儲(chǔ)服務(wù)。模板庫(kù)中的鏡像數(shù)據(jù)為一次寫多次讀，允許刪除，連續(xù)I/O的需求可高達(dá)幾十GB；彈性存儲(chǔ)為用戶數(shù)據(jù)，多次讀多次寫，允許刪除，連續(xù)I/O的需求不固定。為達(dá)到最佳的用戶體驗(yàn)，主存儲(chǔ)需要最快的磁盤和最快的與計(jì)算服務(wù)相連的網(wǎng)絡(luò)。

　　容災(zāi)存儲(chǔ)可直觀理解成主存儲(chǔ)的副本，備份/復(fù)制一般按照固定的間隔進(jìn)行，一次寫多次讀，有刪除操作，連續(xù)I/O的需求一般為幾十GB，速度要求不高，但必須要求穩(wěn)定可靠。容災(zāi)存儲(chǔ)和主存儲(chǔ)之間的網(wǎng)絡(luò)不要求快速，但需要相對(duì)均勻的流量。

　　此外，為優(yōu)化存儲(chǔ)設(shè)置，還可以從文件系統(tǒng)、存儲(chǔ)格式等方面為主存儲(chǔ)和容災(zāi)存儲(chǔ)設(shè)定不同的機(jī)制。為主存儲(chǔ)進(jìn)行合適的RAID設(shè)置，保證性能穩(wěn)定的同時(shí)降低成本；為容災(zāi)存儲(chǔ)設(shè)置專門支持的文件系統(tǒng)，通過(guò)時(shí)間戳、作者信息等附加屬性實(shí)現(xiàn)同名文件的版本區(qū)分，通過(guò)壓縮、除重策略實(shí)現(xiàn)存儲(chǔ)空間的節(jié)省。

　　4.2容災(zāi)策略要求

　　容災(zāi)的目的是在主數(shù)據(jù)發(fā)生故障以后，通過(guò)利用容災(zāi)存儲(chǔ)的冗余數(shù)據(jù)來(lái)恢復(fù)應(yīng)用。容災(zāi)策略的受益可以量化成其為用戶挽回的直接和間接的損失。當(dāng)容災(zāi)收益大于部署成本時(shí)，就值得去實(shí)施這個(gè)容災(zāi)策略。

　　4.2.1備份/復(fù)制的機(jī)制

　　據(jù)備份一般是指利用備份軟件把數(shù)據(jù)從磁盤備份到磁帶或磁盤進(jìn)行離線保存。備份數(shù)據(jù)的格式是磁帶格式，不能被業(yè)務(wù)系統(tǒng)直接訪問。在原數(shù)據(jù)被破壞或丟失時(shí)，備份數(shù)據(jù)必須由備份軟件恢復(fù)成可用數(shù)據(jù)，才可讓數(shù)據(jù)處理系統(tǒng)訪問。

　　數(shù)據(jù)復(fù)制是指利用復(fù)制軟件把數(shù)據(jù)從一個(gè)磁盤復(fù)制到另一個(gè)磁盤，生成一個(gè)數(shù)據(jù)副本。這個(gè)數(shù)據(jù)副本是業(yè)務(wù)系統(tǒng)直接可以訪問的，不需要進(jìn)行任何的數(shù)據(jù)恢復(fù)操作，這一點(diǎn)是復(fù)制與磁盤到磁盤(D2D)備份的最大區(qū)別。復(fù)制又可以分為同步復(fù)制、異步復(fù)制、增量復(fù)制。

　　采用何種備份/復(fù)制機(jī)制取決于系統(tǒng)對(duì)RPO(Recovery Point Objective s，恢復(fù)點(diǎn)目標(biāo))的要求，為滿足不同RPO，備份/復(fù)制機(jī)制的實(shí)現(xiàn)成本有很大的差異，RPO直接決定了備份/復(fù)制機(jī)制的啟動(dòng)間隔。一份有效的容災(zāi)副本是災(zāi)難來(lái)臨時(shí)使癱瘓的業(yè)務(wù)系統(tǒng)恢復(fù)正常工作的必要條件。為不使災(zāi)難導(dǎo)致主數(shù)據(jù)和容災(zāi)數(shù)據(jù)同時(shí)失效，往往采用異地備份的模式。在備份/復(fù)制運(yùn)行時(shí)，需要做到不影響業(yè)務(wù)系統(tǒng)的服務(wù)性能，這就要求合理的利用備份時(shí)間窗口，在系統(tǒng)相對(duì)不繁忙的時(shí)段進(jìn)行備份或復(fù)制。對(duì)于5 x 8的非關(guān)鍵系統(tǒng)，備份時(shí)間相對(duì)較大，但對(duì)于7 x 24的主系統(tǒng)來(lái)說(shuō)，備份時(shí)間窗口就很小，需要通過(guò)加快備份速度和實(shí)現(xiàn)在線復(fù)制來(lái)解決。

　　最常見的RPO接近于1天的應(yīng)用，可以采用每周一次全量備份、每天一次增量備份的策略。如此獲得的備份副本更新頻率為1天，一旦主數(shù)據(jù)失效，都能夠恢復(fù)至1天以前的數(shù)據(jù)。這個(gè)備份機(jī)制對(duì)一些要求比較高的信息是完全不可接受的。通過(guò)增量復(fù)制策略可以滿足更小的RPO，但增量復(fù)制也是一種非實(shí)時(shí)的復(fù)制方式，它依然需要依靠一定的策略(數(shù)據(jù)變化量閾值、日歷安排等)來(lái)啟動(dòng)，增量復(fù)制可以結(jié)合快照技術(shù)有效保證數(shù)據(jù)的一致性。

　　對(duì)于RPO接近于0的關(guān)鍵業(yè)務(wù)應(yīng)用，可以采用異步復(fù)制的策略。異步復(fù)制在向主機(jī)返回寫請(qǐng)求確認(rèn)信號(hào)之后實(shí)時(shí)進(jìn)行，是一種實(shí)時(shí)復(fù)制模式，因此又叫異步鏡像，異步鏡像對(duì)于連接業(yè)務(wù)系統(tǒng)和容災(zāi)中心的鏈路帶寬要求理論上只需達(dá)到“日新增數(shù)據(jù)量/(24×3600 x 8)”即可。異步鏡像的優(yōu)勢(shì)在于用相對(duì)一般的網(wǎng)絡(luò)帶寬和QoS滿足接近于0的RPO，但由于復(fù)制機(jī)制的原因，無(wú)法有效的保證數(shù)據(jù)的一致性。

　　對(duì)于RPO要求嚴(yán)格為0的應(yīng)用，災(zāi)備策略需要投入的成本最高，需要采用同步復(fù)制的模式。同步復(fù)制是在向主機(jī)返回寫請(qǐng)求確認(rèn)信號(hào)之前實(shí)時(shí)進(jìn)行的，也叫同步鏡像。為有效的保證數(shù)據(jù)一致性，需要關(guān)閉主機(jī)緩存，并需要在業(yè)務(wù)系統(tǒng)和容災(zāi)中心之間采用光纖直連、波分設(shè)備的網(wǎng)絡(luò)部署。

　　復(fù)制機(jī)制有基于主機(jī)和基于存儲(chǔ)之分�；�于主機(jī)的復(fù)制一般由安裝在主機(jī)上的復(fù)制軟件來(lái)實(shí)施，會(huì)影響主機(jī)系統(tǒng)的性能；基于存儲(chǔ)的復(fù)制由存儲(chǔ)設(shè)備控制器或虛擬化存儲(chǔ)管理平臺(tái)執(zhí)行，它獨(dú)立于主機(jī)，不會(huì)對(duì)主機(jī)系統(tǒng)的性能造成影響。對(duì)于VDC來(lái)說(shuō)，所有的服務(wù)都需要基于網(wǎng)絡(luò)提供，備份/復(fù)制由于執(zhí)行機(jī)制的不同，可以不占用物理主機(jī)資源，但必然會(huì)占用網(wǎng)絡(luò)資源。這就需要將業(yè)務(wù)網(wǎng)絡(luò)和災(zāi)備網(wǎng)絡(luò)分離，并實(shí)行合理的網(wǎng)絡(luò)監(jiān)控機(jī)制。2011年4月21日，AWS的服務(wù)中斷事故除了人為因素之外，也由于容災(zāi)邏輯中對(duì)網(wǎng)絡(luò)連接監(jiān)測(cè)的不合理導(dǎo)致備份策略后續(xù)大量的重鏡像執(zhí)行，造成了擁堵。

　　4.2.2高可用和負(fù)載機(jī)制

　　高可用和負(fù)載均衡都是需要在本地網(wǎng)部署，需要保證各主機(jī)之間秒級(jí)間隔的頻繁互通，因此面向的應(yīng)用場(chǎng)景僅針對(duì)主機(jī)失效，無(wú)法應(yīng)對(duì)自然災(zāi)難以及停電、火災(zāi)等非技術(shù)災(zāi)難。

　　高可用可以保證主機(jī)系統(tǒng)能夠提供24小時(shí)的不間斷服務(wù)，在主機(jī)發(fā)生故障時(shí)，備機(jī)能夠自動(dòng)及時(shí)檢測(cè)到故障，并接管主機(jī)發(fā)生故障的服務(wù)(可以是主機(jī)的全部服務(wù)，或者僅發(fā)生故障部分的服務(wù))；當(dāng)備機(jī)故障時(shí)，主機(jī)檢測(cè)到故障并發(fā)送通知給管理員，以便進(jìn)行即時(shí)維護(hù)。負(fù)載均衡的特點(diǎn)在于能夠分?jǐn)偞罅髁康臄?shù)據(jù)，將密集的服務(wù)請(qǐng)求下放到若干個(gè)相互獨(dú)立的主機(jī)上。任一主機(jī)失效并不影響所提供服務(wù)的連續(xù)性。

　　在VDC的云計(jì)算服務(wù)中，可以考慮在服務(wù)模塊的單點(diǎn)故障處部署高可用，在瓶頸處部署負(fù)載均衡，詳見6節(jié)。

　　5、用戶應(yīng)對(duì)災(zāi)難的應(yīng)急措施

　　VDC災(zāi)備的目標(biāo)是laaS服務(wù)的連續(xù)性，即資源申請(qǐng)、監(jiān)控、賬單查詢等業(yè)務(wù)模塊的正常運(yùn)行，而對(duì)于虛擬機(jī)本身不提供災(zāi)備機(jī)制。因此為了達(dá)到最佳用戶體驗(yàn)，用戶除了按就近原則選擇地理位置最近的服務(wù)區(qū)域部署自己的虛擬機(jī)外，還需要根據(jù)自身的需要制定合適的容災(zāi)策略，這些容災(zāi)手段是無(wú)法由VDC代勞的。

　　5.1同一云服務(wù)提供商不同服務(wù)區(qū)之間的容災(zāi)策略設(shè)置

　　VDC的跨域資源調(diào)度需要占用大量的網(wǎng)絡(luò)資源，出于成本考慮，一般VDC提供商不主動(dòng)提供用戶數(shù)據(jù)的跨域備份/復(fù)制。然而對(duì)于用戶而言，跨域的異地副本是實(shí)現(xiàn)其本身數(shù)據(jù)高可用的保障。異地副本包括虛擬機(jī)鏡像模板、存儲(chǔ)。VDC提供商一般會(huì)提供若干個(gè)標(biāo)準(zhǔn)的虛擬機(jī)鏡像模板，每個(gè)用戶都能基于這些標(biāo)準(zhǔn)模板建立自己的虛擬機(jī)。用戶對(duì)虛擬機(jī)可以進(jìn)行個(gè)性化的配置和調(diào)整，刪除多余的程序、關(guān)閉多余的服務(wù)端口，以優(yōu)化自身部署的應(yīng)用。一個(gè)健康的用戶虛擬機(jī)應(yīng)包含除數(shù)據(jù)以外的所有服務(wù)模塊及所需的運(yùn)行時(shí)環(huán)境。當(dāng)這樣的虛擬機(jī)設(shè)置、調(diào)試完成，投入使用后，用戶需要對(duì)該虛擬機(jī)鏡像做備份，將其作為個(gè)性化的模板，并保證這個(gè)模板在所有的服務(wù)區(qū)域內(nèi)都具備獨(dú)立的副本。這樣才能保證在任何時(shí)候，在任-N務(wù)區(qū)域，用戶都能快速創(chuàng)建相同的個(gè)性化虛擬機(jī)實(shí)例。通過(guò)如此靈活設(shè)置的個(gè)性化模板可以使得VDC上用戶自身服務(wù)的RTO遠(yuǎn)小于基于物理主機(jī)的RTO。

　　對(duì)于存儲(chǔ)而言，用戶需要自行設(shè)定跨服務(wù)區(qū)域的備份和復(fù)制策略，在衡量自身服務(wù)的RPOS~成本后進(jìn)行實(shí)際部署，部署方式與4.2.1節(jié)的描述類似，這里不再贅述。

　　5.2不同云提供商之間的容災(zāi)

　　跨不同VDC提供商的容災(zāi)策略考慮的是應(yīng)對(duì)單一VDC提供商業(yè)務(wù)停止的風(fēng)險(xiǎn)。物理災(zāi)難發(fā)生頻率較小，但經(jīng)營(yíng)模式、業(yè)務(wù)范圍的變化隨時(shí)隨地都在發(fā)生，因此用戶應(yīng)用的部署及災(zāi)備策略應(yīng)該考慮到VDC提供商層面的冗余。

　　5.2.1主、備提供商之間服務(wù)的依賴關(guān)系

　　選取備用提供商的原則應(yīng)與選取主提供商的原則一致，需要充分考慮其能夠提供的服務(wù)能力，而且主、備提供商之間不存在業(yè)務(wù)上的相互依賴關(guān)系。如果備用提供商的物理設(shè)施依賴于主提供商，那么當(dāng)主提供商的云計(jì)算服務(wù)終止后，備用提供商的服務(wù)會(huì)受到連帶的影響，對(duì)云計(jì)算服務(wù)的用戶來(lái)說(shuō)就失去了容災(zāi)的意義。因此在選取備用提供商時(shí)，用戶應(yīng)該考慮以下原則：

　　(1)主、備VDC提供商之間不存在相互的物理設(shè)施租賃業(yè)務(wù)；

　　(2)主、備VDC提供商的基礎(chǔ)設(shè)施供給不依賴于完全相同的直屬?gòu)S商，即每一個(gè)VDC提供商僅依靠其“獨(dú)有”的直屬設(shè)備廠商都有能力搭建出能夠提供完整服務(wù)的Iaas服務(wù)架構(gòu)。

　　5.2.2基于主、備提供商的容災(zāi)策略

　　5.2.2.1使用備用提供商做備份

　　這里所說(shuō)的備份僅指數(shù)據(jù)備份，有關(guān)備份間隔的選定

　　與4.2.1節(jié)描述的原則一致。這里需要注意的是，不同VDC提供商的存儲(chǔ)文件系統(tǒng)不一定相互兼容，這就需要選擇符合自己需求的備用提供商。即當(dāng)需要使用恢復(fù)策略時(shí)，從備用提供商的存儲(chǔ)服務(wù)中獲取的備份副本能夠及時(shí)并完整的傳輸至主提供商，并且能夠被主提供商服務(wù)中建立的虛擬服務(wù)器識(shí)別并準(zhǔn)確的讀取。

　　5.2.2.2使用備用提供商切換部署

　　對(duì)于使用Iaas服務(wù)的用戶來(lái)說(shuō)，能夠在需要的時(shí)候在備用VDC提供商處搭建起虛擬運(yùn)行環(huán)境提供對(duì)外服務(wù)是選擇備用提供商的主要目的。在這個(gè)場(chǎng)景中，可以認(rèn)為主VDC提供商的服務(wù)已經(jīng)完全癱瘓，已無(wú)法從中讀取出任何的信息，包括虛擬機(jī)的配置、模板以及用戶數(shù)據(jù)等。為了在備用VDC提供商的IaaS環(huán)境中預(yù)先做好可以啟動(dòng)業(yè)務(wù)環(huán)境的所有準(zhǔn)備，用戶需要考慮以下幾個(gè)方面：

　　(1)備用提供商支持的文件系統(tǒng)，同5.2.2.1節(jié)；

　　(2)在備用提供商處的數(shù)據(jù)備份，同5.2.2.1節(jié)；

　　(3)備用提供商支持的虛擬機(jī)操作系統(tǒng)需要符合用戶所需運(yùn)行時(shí)的環(huán)境；

　　(4)用戶在主VDC提供商處做的每一次系統(tǒng)更新都要及時(shí)地反映在備用提供商中，具體表現(xiàn)為系統(tǒng)更新后虛擬機(jī)模板的更新，不同VDC提供商的的虛擬機(jī)模板不一定兼容，這需要用戶手動(dòng)在備用VDC環(huán)境中做獨(dú)立的更新；

　　(5)為主、備VDC提供商的服務(wù)部署監(jiān)控。

　　這里所說(shuō)的監(jiān)控包含三個(gè)方面：調(diào)用vDc服務(wù)平臺(tái)API獲取的有關(guān)虛擬機(jī)的全局監(jiān)控、各虛擬機(jī)實(shí)例的性能監(jiān)控、用戶自身部署服務(wù)的監(jiān)控。通過(guò)這三方面的監(jiān)控用戶才能夠第一時(shí)間做出在備用VDC提供商處啟用服務(wù)的決策。需要注意的是，由于監(jiān)控的目的是為了及時(shí)發(fā)現(xiàn)和預(yù)防主提供商所提供的服務(wù)失效，因此監(jiān)控程序本身應(yīng)該部署在相對(duì)主、備提供商獨(dú)立的環(huán)境中，由此來(lái)保證VDC提供商的服務(wù)不影響監(jiān)控程序的正常運(yùn)行。

　　6、VDC的容災(zāi)架構(gòu)建議

　　無(wú)論是VDC提供商還是VDC用戶，容災(zāi)策略部署的目的在于能夠在災(zāi)難降臨時(shí)在RTO限定范圍內(nèi)恢復(fù)至限定的RPO狀態(tài)，因此各方“嚴(yán)謹(jǐn)”的容災(zāi)策略都應(yīng)該做定期的演練，以便及時(shí)發(fā)現(xiàn)問題并進(jìn)行補(bǔ)救，最大程度的降低人為技術(shù)性災(zāi)難。這里給出一個(gè)可供VDC提供商參考的容災(zāi)架構(gòu)。

　　搭建完成的IaaS服務(wù)架構(gòu)是部署容災(zāi)策略的前提，IaaS架構(gòu)圖如圖1所示。
 

　　圖1中所示的云控制器、節(jié)點(diǎn)控制器均為單點(diǎn)故障，為提升VDC的服務(wù)可用性，可以為其設(shè)置高可用技術(shù)，集群控制器需要匯總所有主機(jī)的網(wǎng)絡(luò)負(fù)載，形成帶寬瓶頸，因此可以設(shè)置負(fù)載均衡架構(gòu)。此外，整個(gè)云平臺(tái)的元數(shù)據(jù)庫(kù)也建議使用高可用進(jìn)行部署，如圖2所示。
 

　　在架構(gòu)上，模板庫(kù)的作用范圍為整個(gè)節(jié)點(diǎn)，或整個(gè)服務(wù)區(qū)域，彈性存儲(chǔ)的作用范圍為整個(gè)集群。在各自的作用范圍內(nèi)，VDC提供商應(yīng)當(dāng)保證數(shù)據(jù)的可用性，并且模板庫(kù)、彈性存儲(chǔ)的調(diào)用對(duì)上層的用戶透明。例如AWS的簡(jiǎn)單存儲(chǔ)服務(wù)(Simple Storage Service，簡(jiǎn)稱“S3”服務(wù))雖然可用性不高(即經(jīng)常出現(xiàn)無(wú)法連接或服務(wù)不可用的現(xiàn)象)，但可以保證用戶數(shù)據(jù)不丟失。在服務(wù)區(qū)域內(nèi)部，VDC提供商的物理設(shè)備鏈接是相對(duì)穩(wěn)定的本地網(wǎng)，稍加設(shè)置即可最小化備份占用的業(yè)務(wù)帶寬。對(duì)于跨域存儲(chǔ)的備份，由于需要占用成本相對(duì)較高的主干網(wǎng)帶寬，因此VDC提供商不自動(dòng)為每個(gè)用戶提供異地容災(zāi)，但可以設(shè)置容災(zāi)通道由用戶自行定制使用。對(duì)于用戶而言，只需為備份時(shí)占用的網(wǎng)絡(luò)流量和備份副本占用的存儲(chǔ)空間付費(fèi)即可。在具備完善的物理設(shè)備支撐的同時(shí)，容災(zāi)策略的觸發(fā)算法也至關(guān)重要。AWS的事故正是由于容災(zāi)觸發(fā)算法的邏輯不嚴(yán)密導(dǎo)致了連帶性的服務(wù)中斷，先前的人為操作失誤恰好暴露了觸發(fā)算法的漏洞，AWS才得以設(shè)法鞏固其業(yè)務(wù)邏輯。一般來(lái)說(shuō)，基于不可靠設(shè)備建立的穩(wěn)定存儲(chǔ)系統(tǒng)都需要依賴于LOCKSS策略，因此當(dāng)副本減少時(shí)，容災(zāi)策略會(huì)自動(dòng)觸發(fā)副本重建程序。導(dǎo)致副本邏輯丟失的誘因有多種，最具代表性的是存儲(chǔ)介質(zhì)物理?yè)p壞和存儲(chǔ)介質(zhì)網(wǎng)絡(luò)請(qǐng)求不響應(yīng)。重建副本的途徑如果依賴于其誘因，就會(huì)出現(xiàn)死循環(huán)。AWS因?yàn)榫W(wǎng)絡(luò)擁堵導(dǎo)致部分備份副本被擠下線，容災(zāi)策略檢測(cè)到副本邏輯丟失時(shí)自動(dòng)觸發(fā)本地網(wǎng)范圍內(nèi)的存儲(chǔ)搜索并建立新的副本，大量的副本重建指令同時(shí)觸發(fā)使得已經(jīng)擁堵的網(wǎng)絡(luò)資源更加擁堵，不但更加惡化了容災(zāi)策略，也使得正常業(yè)務(wù)遭受了影響。

　　正如AWS官方聲明所言，如果沒有維護(hù)工程師的誤操作，容災(zāi)觸發(fā)算法的這一邏輯缺陷將始終存在，并且很難在日常的容災(zāi)演練中發(fā)現(xiàn)。這就說(shuō)明邏輯的完善需要在實(shí)踐中慢慢積累，現(xiàn)在看似嚴(yán)密的策略也會(huì)存在一些尚未暴露的缺陷，無(wú)論是VDC提供商還是VDC用戶，都需要在IaaS服務(wù)的使用過(guò)程中不斷的完善、鞏固各自的容災(zāi)策略。

　　7、總結(jié)

　　為了應(yīng)對(duì)自然災(zāi)難、人為非技術(shù)災(zāi)難和人為技術(shù)性災(zāi)難，VDC提供商和VDC用戶都需要部署各自自身的容災(zāi)策略。對(duì)于VDC服務(wù)提供商來(lái)說(shuō)，需要在物理資源如存儲(chǔ)、網(wǎng)絡(luò)、云管理平臺(tái)的服務(wù)模塊等層面設(shè)置可行的容災(zāi)和負(fù)載策略；對(duì)于VDC用戶，除了依賴于提供商的災(zāi)備策略外還需要應(yīng)對(duì)VDC提供商終止服務(wù)的風(fēng)險(xiǎn)，采取多提供商的策略。

　　當(dāng)然，為了使IaaS服務(wù)和部署在IaaS服務(wù)上的應(yīng)用穩(wěn)定持續(xù)的運(yùn)行，除了容災(zāi)策略以外，安全策略的部署也是很重要的一部分，這涉及到VDC機(jī)房本身的IDC安全，以及虛擬層的安全，這是VDC的IaaS服務(wù)建設(shè)中必須重點(diǎn)考慮的一部分。

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/

本文標(biāo)題：淺析云計(jì)算IaaS服務(wù)的災(zāi)難應(yīng)對(duì)策略

本文網(wǎng)址：http://www.oesoe.com/html/consultation/1083974415.html