1、引言
云計算是一種新型的業(yè)務模式，能夠為數(shù)據(jù)中心廠商節(jié)約能耗，提高設備利用率，并突破傳統(tǒng)服務模式開展多樣化的創(chuàng)新商業(yè)服務模式；用戶可以不用自己購買IT固定資產(chǎn)，而通過VDC (Virtual Data Center，虛擬數(shù)據(jù)中心)服務提供商按需租用自己所需的計算、存儲、網(wǎng)絡資源，并可隨時隨需擴展、新增、停租資源。
云計算基礎設施即服務IaaS(Infrastructure as a Service)業(yè)務模式最典型的應用場景是虛擬數(shù)據(jù)中心，該業(yè)務模式的出現(xiàn)將計算機系統(tǒng)的維護進行了細分，由服務供應鏈的各方各司其職：用戶只需考慮其自身應用基于虛擬環(huán)境的部署架構，VDC服務提供商只需考慮將硬件資源池化并保證服務可用性，硬件廠商只需考慮底層設備對虛擬化環(huán)境的支持和優(yōu)化。維護重點細分之后，應對風險的責任也就細分了。因此云計算環(huán)境下的災難應對并不是服務供應鏈中只有某一方需要考慮的問題，而是需要各方基于各自責任范圍形成協(xié)調一致的措施，這樣才能在災難來臨時最大程度的減小損失。
本文探討了云計算IaaS服務提供商和用戶應對災難的策略，并提出了一種VDC容災架構。
2、災難的定義和分類
根據(jù)原國務院信息化工作辦公室的定義，災難是指由于人為或自然的原因，造成信息系統(tǒng)運行嚴重故障或癱瘓，使信息系統(tǒng)支持的業(yè)務功能停頓或服務水平不可接受、達到特定的時間的突發(fā)性事件，通常導致信息系統(tǒng)需要切換到備用場地運行。根據(jù)這一定義，災難不僅指海嘯、地震等自然災害，還包括其它任何由無法預知的原因引起的服務不可用。IT服務的失效能夠直接導致企業(yè)實現(xiàn)核心價值的關鍵業(yè)務系統(tǒng)受到重創(chuàng)。例如，銀行的ATM機失效、網(wǎng)站的網(wǎng)頁無法訪問、證券的交易系統(tǒng)失靈、數(shù)據(jù)中心的網(wǎng)絡阻塞等，最終將導致致命的傷害，造成不可挽回的損失。
我們將災難進一步細分，按照人為因素的多少分為以下三類：
(1)非人為自然災難：海嘯、地震等區(qū)域毀滅性災難；
(2)人為非技術性災難：火災、停電、人員損失等局部臨時性災難；
(3)人為技術性災難：設備故障、邏輯缺陷、人為操作失誤等可優(yōu)化災難。
3、VDC業(yè)務各方需應對的災難
對于VDC業(yè)務來說，應對第一、第二類災難主要依托預先制定的容災預案；應對第三類災難主要依托密集型的技術干預，服務架構越復雜，引起第三類災難的風險環(huán)節(jié)就越多，但與第一、第二類災難不同的是，第三類災難可通過整改措施轉變?yōu)椤耙淮涡詾碾y”，降低重復發(fā)生的可能性。
VDC服務提供商和VDC用戶都會面臨以上三類災難，但各自的應對和預防措施不同。
3.1VDC提供商需要應對的災難
一個配置準確、正常運營的VDC能夠讓租戶通過云管理平臺在15分鐘內獲得所申請的資源，并且可以隨時按需關閉、新增和擴展虛擬服務器，這是VDC提供商IaaS服務的基本特點。其服務架構可以分為資源層、業(yè)務層、展現(xiàn)層，其中任何一層都有出現(xiàn)異常的可能，具體可以表現(xiàn)為：
(1)資源層設備損壞(三類災難都可能引起)；
(2)資源層網(wǎng)絡受培；
(3)資源層主機系統(tǒng)故障；
(4)業(yè)務層調度邏輯錯誤；
(5)業(yè)務層拒絕服務；
(6)展現(xiàn)層拒絕服務；
(7)其它無法預知的技術故障。
以上這些異常每一種都會引起服務不可用。架構中各模塊之間有相互依賴邏輯，一處技術故障經(jīng)常會引起“連鎖反應”，導致多個環(huán)節(jié)異常，增加系統(tǒng)管理的復雜度，從而導致服務不可用時間的延長。
三類災難的發(fā)生雖然不可預知，但通過執(zhí)行預先制定的容災預案，VDC提供商可以將由非人為自然災難和人為非技術性災難引起的服務間斷控制在最小范圍。技術性災難則需要VDC提供商通過自身的技術力量準確定位、排除，并對服務架構進行鞏固和預防。災難的應對直接影響VDC服務的可靠性和穩(wěn)定性，是其服務質量的關鍵因素，也是VDC實現(xiàn)服務級別協(xié)議SLA(Service Level Agreement)管理的關鍵因素之一。
3.2VDC用戶需要應對的災難
對于3.1節(jié)描述的災難，VDC服務提供商有完備的應急和應對措施，VDC用戶在此基礎上可充分利用云服務資源申請的自動、快捷、方便，進一步為自身應用設置靈活的容災策略。然而另有一些災難因素是VDC提供商無能為力的，用戶必須考慮跨VDC提供商的災備方案來解決，這些因素包括：
(1)VDC提供商轉變經(jīng)營策略，不再提供云計算服務，所有設備移作他用；
(2)VDC提供商宣告破產(chǎn)，所有設備去向不明。對于此類災難的用戶應對措施將在5.2節(jié)詳細描述。
4、云提供商應對災難的措施
4.1基礎設施要求
資源層是云計算服務架構的最底層，為了面對不可預知的災難，VDC提供商必須準確了解各有關基礎設施資源的特性，并在合適的位置設置合適的基礎設施資源。
4.1.1網(wǎng)絡是關鍵
云計算以網(wǎng)絡為依托，網(wǎng)絡通暢是云計算服務的根本保障。VDC服務區(qū)域內部的物理主機連接(本地網(wǎng))、跨域調度的連接(主干網(wǎng))、對外提供服務的業(yè)務連接(外網(wǎng))是不同層次的網(wǎng)絡，各自的流量帶寬要求不同，發(fā)揮的功能也不同。所有資源的調度、備份算法、容災策略都運行在滿足各自需求的網(wǎng)絡上，網(wǎng)絡異常造成的擁堵輕則影響用戶體驗，重則導致服務中斷。以下以亞馬遜云計算服務曾經(jīng)出現(xiàn)的事故來說明這一點。
亞馬遜互聯(lián)網(wǎng)絡服務(Amazon Web Service，簡稱“AWS”)，服務區(qū)域內部的主機連接分為兩類，一類為高性能的、高吞吐能力的連接彈性計算云(Elastic Comute Cloud，簡稱“EC2”)和彈性存儲塊(Elastic Block Store，簡稱“EBS”)的業(yè)務網(wǎng)，另一類為穩(wěn)定的、低吞吐能力的連接EBS和容災存儲的備份網(wǎng)。2011年4月21日，AWS維護工程師為北美某服務區(qū)域的EBS擴容，在設備與網(wǎng)絡相連時，誤將EC2與EBS之間的連接接入備份網(wǎng)，同時造成了業(yè)務和備份服務的網(wǎng)絡阻塞，由此觸發(fā)了一系列的災難；
(1)因業(yè)務擁堵直接造成該服務區(qū)的虛擬機(VM)無法響應對塊存儲的讀寫操作，用戶無法新建虛擬機；
(2)因備份服務的網(wǎng)絡擁堵直接導致13%的容災存儲被擠下線；
(3)網(wǎng)絡設置恢復后，因容災備份的觸發(fā)，起初無法找到備份副本的EBS大面積同時啟動副本重建，備份網(wǎng)絡再次擁堵；
(4)容災存儲消耗過快，無法找到備份所需存儲資源的EBS始終處于重新尋找資源(re-mirroring)的狀態(tài)中；
(5)調度服務器接收不到EBS的備份反饋，進程無法釋放，進程數(shù)很快占滿，開始拒絕接收新的調度服務，導致其它服務區(qū)域的請求不被響應。
AWS花了3天時間將該連鎖反應導致的異常數(shù)據(jù)量減小到了0.2%，1周的時間讓系統(tǒng)完全恢復正常運作。由此給AWS帶來的經(jīng)濟損失為故障服務區(qū)域10天的營業(yè)額(AWS為補償用戶作出的決策)；故障發(fā)生期間給用戶帶來的損失是無法估量的，期間有數(shù)10個網(wǎng)站用戶的站點無法啟動和被訪問。
當然，這里不是暗示在VDC架構設計的時候在所有的網(wǎng)絡連接上都使用高速、高吞吐量的設備，而是強調在做組件架構、制定容災策略的時候需要充分考慮網(wǎng)絡能力以及制定合理的業(yè)務響應邏輯方案來應對出現(xiàn)網(wǎng)絡擁堵的情況。
4.1.2主存儲與容災存儲的存儲模式區(qū)別
業(yè)務數(shù)據(jù)和容災數(shù)據(jù)對底層存儲的需求不同，使用的存儲設備也不同，表1列舉了業(yè)務存儲(主存儲)和容災存儲的需求區(qū)別。
用戶日常業(yè)務需要的、VDC提供IaaS服務必不可少的物理存儲設備即為主存儲，主存儲提供模板庫和彈性存儲服務。模板庫中的鏡像數(shù)據(jù)為一次寫多次讀，允許刪除，連續(xù)I/O的需求可高達幾十GB；彈性存儲為用戶數(shù)據(jù)，多次讀多次寫，允許刪除，連續(xù)I/O的需求不固定。為達到最佳的用戶體驗，主存儲需要最快的磁盤和最快的與計算服務相連的網(wǎng)絡。
容災存儲可直觀理解成主存儲的副本，備份/復制一般按照固定的間隔進行，一次寫多次讀，有刪除操作，連續(xù)I/O的需求一般為幾十GB，速度要求不高，但必須要求穩(wěn)定可靠。容災存儲和主存儲之間的網(wǎng)絡不要求快速，但需要相對均勻的流量。
此外，為優(yōu)化存儲設置，還可以從文件系統(tǒng)、存儲格式等方面為主存儲和容災存儲設定不同的機制。為主存儲進行合適的RAID設置，保證性能穩(wěn)定的同時降低成本；為容災存儲設置專門支持的文件系統(tǒng)，通過時間戳、作者信息等附加屬性實現(xiàn)同名文件的版本區(qū)分，通過壓縮、除重策略實現(xiàn)存儲空間的節(jié)省。
4.2容災策略要求
容災的目的是在主數(shù)據(jù)發(fā)生故障以后，通過利用容災存儲的冗余數(shù)據(jù)來恢復應用。容災策略的受益可以量化成其為用戶挽回的直接和間接的損失。當容災收益大于部署成本時，就值得去實施這個容災策略。
4.2.1備份/復制的機制
據(jù)備份一般是指利用備份軟件把數(shù)據(jù)從磁盤備份到磁帶或磁盤進行離線保存。備份數(shù)據(jù)的格式是磁帶格式，不能被業(yè)務系統(tǒng)直接訪問。在原數(shù)據(jù)被破壞或丟失時，備份數(shù)據(jù)必須由備份軟件恢復成可用數(shù)據(jù)，才可讓數(shù)據(jù)處理系統(tǒng)訪問。
數(shù)據(jù)復制是指利用復制軟件把數(shù)據(jù)從一個磁盤復制到另一個磁盤，生成一個數(shù)據(jù)副本。這個數(shù)據(jù)副本是業(yè)務系統(tǒng)直接可以訪問的，不需要進行任何的數(shù)據(jù)恢復操作，這一點是復制與磁盤到磁盤(D2D)備份的最大區(qū)別。復制又可以分為同步復制、異步復制、增量復制。
采用何種備份/復制機制取決于系統(tǒng)對RPO(Recovery Point Objective s，恢復點目標)的要求，為滿足不同RPO，備份/復制機制的實現(xiàn)成本有很大的差異，RPO直接決定了備份/復制機制的啟動間隔。一份有效的容災副本是災難來臨時使癱瘓的業(yè)務系統(tǒng)恢復正常工作的必要條件。為不使災難導致主數(shù)據(jù)和容災數(shù)據(jù)同時失效，往往采用異地備份的模式。在備份/復制運行時，需要做到不影響業(yè)務系統(tǒng)的服務性能，這就要求合理的利用備份時間窗口，在系統(tǒng)相對不繁忙的時段進行備份或復制。對于5 x 8的非關鍵系統(tǒng)，備份時間相對較大，但對于7 x 24的主系統(tǒng)來說，備份時間窗口就很小，需要通過加快備份速度和實現(xiàn)在線復制來解決。
最常見的RPO接近于1天的應用，可以采用每周一次全量備份、每天一次增量備份的策略。如此獲得的備份副本更新頻率為1天，一旦主數(shù)據(jù)失效，都能夠恢復至1天以前的數(shù)據(jù)。這個備份機制對一些要求比較高的信息是完全不可接受的。通過增量復制策略可以滿足更小的RPO，但增量復制也是一種非實時的復制方式，它依然需要依靠一定的策略(數(shù)據(jù)變化量閾值、日歷安排等)來啟動，增量復制可以結合快照技術有效保證數(shù)據(jù)的一致性。
對于RPO接近于0的關鍵業(yè)務應用，可以采用異步復制的策略。異步復制在向主機返回寫請求確認信號之后實時進行，是一種實時復制模式，因此又叫異步鏡像，異步鏡像對于連接業(yè)務系統(tǒng)和容災中心的鏈路帶寬要求理論上只需達到“日新增數(shù)據(jù)量/(24×3600 x 8)”即可。異步鏡像的優(yōu)勢在于用相對一般的網(wǎng)絡帶寬和QoS滿足接近于0的RPO，但由于復制機制的原因，無法有效的保證數(shù)據(jù)的一致性。
對于RPO要求嚴格為0的應用，災備策略需要投入的成本最高，需要采用同步復制的模式。同步復制是在向主機返回寫請求確認信號之前實時進行的，也叫同步鏡像。為有效的保證數(shù)據(jù)一致性，需要關閉主機緩存，并需要在業(yè)務系統(tǒng)和容災中心之間采用光纖直連、波分設備的網(wǎng)絡部署。
復制機制有基于主機和基于存儲之分�；谥鳈C的復制一般由安裝在主機上的復制軟件來實施，會影響主機系統(tǒng)的性能；基于存儲的復制由存儲設備控制器或虛擬化存儲管理平臺執(zhí)行，它獨立于主機，不會對主機系統(tǒng)的性能造成影響。對于VDC來說，所有的服務都需要基于網(wǎng)絡提供，備份/復制由于執(zhí)行機制的不同，可以不占用物理主機資源，但必然會占用網(wǎng)絡資源。這就需要將業(yè)務網(wǎng)絡和災備網(wǎng)絡分離，并實行合理的網(wǎng)絡監(jiān)控機制。2011年4月21日，AWS的服務中斷事故除了人為因素之外，也由于容災邏輯中對網(wǎng)絡連接監(jiān)測的不合理導致備份策略后續(xù)大量的重鏡像執(zhí)行，造成了擁堵。
4.2.2高可用和負載機制
高可用和負載均衡都是需要在本地網(wǎng)部署，需要保證各主機之間秒級間隔的頻繁互通，因此面向的應用場景僅針對主機失效，無法應對自然災難以及停電、火災等非技術災難。
高可用可以保證主機系統(tǒng)能夠提供24小時的不間斷服務，在主機發(fā)生故障時，備機能夠自動及時檢測到故障，并接管主機發(fā)生故障的服務(可以是主機的全部服務，或者僅發(fā)生故障部分的服務)；當備機故障時，主機檢測到故障并發(fā)送通知給管理員，以便進行即時維護。負載均衡的特點在于能夠分攤大流量的數(shù)據(jù)，將密集的服務請求下放到若干個相互獨立的主機上。任一主機失效并不影響所提供服務的連續(xù)性。
在VDC的云計算服務中，可以考慮在服務模塊的單點故障處部署高可用，在瓶頸處部署負載均衡，詳見6節(jié)。
5、用戶應對災難的應急措施
VDC災備的目標是laaS服務的連續(xù)性，即資源申請、監(jiān)控、賬單查詢等業(yè)務模塊的正常運行，而對于虛擬機本身不提供災備機制。因此為了達到最佳用戶體驗，用戶除了按就近原則選擇地理位置最近的服務區(qū)域部署自己的虛擬機外，還需要根據(jù)自身的需要制定合適的容災策略，這些容災手段是無法由VDC代勞的。
5.1同一云服務提供商不同服務區(qū)之間的容災策略設置
VDC的跨域資源調度需要占用大量的網(wǎng)絡資源，出于成本考慮，一般VDC提供商不主動提供用戶數(shù)據(jù)的跨域備份/復制。然而對于用戶而言，跨域的異地副本是實現(xiàn)其本身數(shù)據(jù)高可用的保障。異地副本包括虛擬機鏡像模板、存儲。VDC提供商一般會提供若干個標準的虛擬機鏡像模板，每個用戶都能基于這些標準模板建立自己的虛擬機。用戶對虛擬機可以進行個性化的配置和調整，刪除多余的程序、關閉多余的服務端口，以優(yōu)化自身部署的應用。一個健康的用戶虛擬機應包含除數(shù)據(jù)以外的所有服務模塊及所需的運行時環(huán)境。當這樣的虛擬機設置、調試完成，投入使用后，用戶需要對該虛擬機鏡像做備份，將其作為個性化的模板，并保證這個模板在所有的服務區(qū)域內都具備獨立的副本。這樣才能保證在任何時候，在任-N務區(qū)域，用戶都能快速創(chuàng)建相同的個性化虛擬機實例。通過如此靈活設置的個性化模板可以使得VDC上用戶自身服務的RTO遠小于基于物理主機的RTO。
對于存儲而言，用戶需要自行設定跨服務區(qū)域的備份和復制策略，在衡量自身服務的RPOS~成本后進行實際部署，部署方式與4.2.1節(jié)的描述類似，這里不再贅述。
5.2不同云提供商之間的容災
跨不同VDC提供商的容災策略考慮的是應對單一VDC提供商業(yè)務停止的風險。物理災難發(fā)生頻率較小，但經(jīng)營模式、業(yè)務范圍的變化隨時隨地都在發(fā)生，因此用戶應用的部署及災備策略應該考慮到VDC提供商層面的冗余。
5.2.1主、備提供商之間服務的依賴關系
選取備用提供商的原則應與選取主提供商的原則一致，需要充分考慮其能夠提供的服務能力，而且主、備提供商之間不存在業(yè)務上的相互依賴關系。如果備用提供商的物理設施依賴于主提供商，那么當主提供商的云計算服務終止后，備用提供商的服務會受到連帶的影響，對云計算服務的用戶來說就失去了容災的意義。因此在選取備用提供商時，用戶應該考慮以下原則：
(1)主、備VDC提供商之間不存在相互的物理設施租賃業(yè)務；
(2)主、備VDC提供商的基礎設施供給不依賴于完全相同的直屬廠商，即每一個VDC提供商僅依靠其“獨有”的直屬設備廠商都有能力搭建出能夠提供完整服務的Iaas服務架構。
5.2.2基于主、備提供商的容災策略
5.2.2.1使用備用提供商做備份
這里所說的備份僅指數(shù)據(jù)備份，有關備份間隔的選定
與4.2.1節(jié)描述的原則一致。這里需要注意的是，不同VDC提供商的存儲文件系統(tǒng)不一定相互兼容，這就需要選擇符合自己需求的備用提供商。即當需要使用恢復策略時，從備用提供商的存儲服務中獲取的備份副本能夠及時并完整的傳輸至主提供商，并且能夠被主提供商服務中建立的虛擬服務器識別并準確的讀取。
5.2.2.2使用備用提供商切換部署
對于使用Iaas服務的用戶來說，能夠在需要的時候在備用VDC提供商處搭建起虛擬運行環(huán)境提供對外服務是選擇備用提供商的主要目的。在這個場景中，可以認為主VDC提供商的服務已經(jīng)完全癱瘓，已無法從中讀取出任何的信息，包括虛擬機的配置、模板以及用戶數(shù)據(jù)等。為了在備用VDC提供商的IaaS環(huán)境中預先做好可以啟動業(yè)務環(huán)境的所有準備，用戶需要考慮以下幾個方面：
(1)備用提供商支持的文件系統(tǒng)，同5.2.2.1節(jié)；
(2)在備用提供商處的數(shù)據(jù)備份，同5.2.2.1節(jié)；
(3)備用提供商支持的虛擬機操作系統(tǒng)需要符合用戶所需運行時的環(huán)境；
(4)用戶在主VDC提供商處做的每一次系統(tǒng)更新都要及時地反映在備用提供商中，具體表現(xiàn)為系統(tǒng)更新后虛擬機模板的更新，不同VDC提供商的的虛擬機模板不一定兼容，這需要用戶手動在備用VDC環(huán)境中做獨立的更新；
(5)為主、備VDC提供商的服務部署監(jiān)控。
這里所說的監(jiān)控包含三個方面：調用vDc服務平臺API獲取的有關虛擬機的全局監(jiān)控、各虛擬機實例的性能監(jiān)控、用戶自身部署服務的監(jiān)控。通過這三方面的監(jiān)控用戶才能夠第一時間做出在備用VDC提供商處啟用服務的決策。需要注意的是，由于監(jiān)控的目的是為了及時發(fā)現(xiàn)和預防主提供商所提供的服務失效，因此監(jiān)控程序本身應該部署在相對主、備提供商獨立的環(huán)境中，由此來保證VDC提供商的服務不影響監(jiān)控程序的正常運行。
6、VDC的容災架構建議
無論是VDC提供商還是VDC用戶，容災策略部署的目的在于能夠在災難降臨時在RTO限定范圍內恢復至限定的RPO狀態(tài)，因此各方“嚴謹”的容災策略都應該做定期的演練，以便及時發(fā)現(xiàn)問題并進行補救，最大程度的降低人為技術性災難。這里給出一個可供VDC提供商參考的容災架構。
搭建完成的IaaS服務架構是部署容災策略的前提，IaaS架構圖如圖1所示。
圖1中所示的云控制器、節(jié)點控制器均為單點故障，為提升VDC的服務可用性，可以為其設置高可用技術，集群控制器需要匯總所有主機的網(wǎng)絡負載，形成帶寬瓶頸，因此可以設置負載均衡架構。此外，整個云平臺的元數(shù)據(jù)庫也建議使用高可用進行部署，如圖2所示。
在架構上，模板庫的作用范圍為整個節(jié)點，或整個服務區(qū)域，彈性存儲的作用范圍為整個集群。在各自的作用范圍內，VDC提供商應當保證數(shù)據(jù)的可用性，并且模板庫、彈性存儲的調用對上層的用戶透明。例如AWS的簡單存儲服務(Simple Storage Service，簡稱“S3”服務)雖然可用性不高(即經(jīng)常出現(xiàn)無法連接或服務不可用的現(xiàn)象)，但可以保證用戶數(shù)據(jù)不丟失。在服務區(qū)域內部，VDC提供商的物理設備鏈接是相對穩(wěn)定的本地網(wǎng)，稍加設置即可最小化備份占用的業(yè)務帶寬。對于跨域存儲的備份，由于需要占用成本相對較高的主干網(wǎng)帶寬，因此VDC提供商不自動為每個用戶提供異地容災，但可以設置容災通道由用戶自行定制使用。對于用戶而言，只需為備份時占用的網(wǎng)絡流量和備份副本占用的存儲空間付費即可。在具備完善的物理設備支撐的同時，容災策略的觸發(fā)算法也至關重要。AWS的事故正是由于容災觸發(fā)算法的邏輯不嚴密導致了連帶性的服務中斷，先前的人為操作失誤恰好暴露了觸發(fā)算法的漏洞，AWS才得以設法鞏固其業(yè)務邏輯。一般來說，基于不可靠設備建立的穩(wěn)定存儲系統(tǒng)都需要依賴于LOCKSS策略，因此當副本減少時，容災策略會自動觸發(fā)副本重建程序。導致副本邏輯丟失的誘因有多種，最具代表性的是存儲介質物理損壞和存儲介質網(wǎng)絡請求不響應。重建副本的途徑如果依賴于其誘因，就會出現(xiàn)死循環(huán)。AWS因為網(wǎng)絡擁堵導致部分備份副本被擠下線，容災策略檢測到副本邏輯丟失時自動觸發(fā)本地網(wǎng)范圍內的存儲搜索并建立新的副本，大量的副本重建指令同時觸發(fā)使得已經(jīng)擁堵的網(wǎng)絡資源更加擁堵，不但更加惡化了容災策略，也使得正常業(yè)務遭受了影響。
正如AWS官方聲明所言，如果沒有維護工程師的誤操作，容災觸發(fā)算法的這一邏輯缺陷將始終存在，并且很難在日常的容災演練中發(fā)現(xiàn)。這就說明邏輯的完善需要在實踐中慢慢積累，現(xiàn)在看似嚴密的策略也會存在一些尚未暴露的缺陷，無論是VDC提供商還是VDC用戶，都需要在IaaS服務的使用過程中不斷的完善、鞏固各自的容災策略。
7、總結
為了應對自然災難、人為非技術災難和人為技術性災難，VDC提供商和VDC用戶都需要部署各自自身的容災策略。對于VDC服務提供商來說，需要在物理資源如存儲、網(wǎng)絡、云管理平臺的服務模塊等層面設置可行的容災和負載策略；對于VDC用戶，除了依賴于提供商的災備策略外還需要應對VDC提供商終止服務的風險，采取多提供商的策略。
當然，為了使IaaS服務和部署在IaaS服務上的應用穩(wěn)定持續(xù)的運行，除了容災策略以外，安全策略的部署也是很重要的一部分，這涉及到VDC機房本身的IDC安全，以及虛擬層的安全，這是VDC的IaaS服務建設中必須重點考慮的一部分。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：淺析云計算IaaS服務的災難應對策略
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/1083974415.html
相關文章
