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