摘要：基本的災難恢復是行之有效的。但也存在一定的不確定性，甚至因此有供應商虛報和過分夸大虛擬化的興起對于災難恢復的影響。

隨著服務器虛擬化的到來，有些人聲稱災難恢復(DR)和保持業務連續性(BC)能夠更的容易實現了，甚至認為這些都是屬于過去的事情了。

這種情況的出現是很容易理解的。現如今，與任何一名虛擬化管理員交流時，都會談到使用傳統的備份和磁帶的想法和理念似乎已經是一個遙遠的記憶了。

自虛擬化技術采用初期開始，我們就已經看到高可用性集群和諸如vMotion等功能的引進，似乎解決了大部分數據保護方面的需求。

但是，如果仔細推敲，我們就會發現這些說法是有些夸張的。

定義災難恢復

能夠確定一個定義的基準總是好的。而且，這在災難恢復規劃方面也是相當有必要的——讀者可以以便了解全面的指南。災難恢復和保持業務連續性在其各自的定義方面稍有不同：

· 業務連續性描述的是確保業務持續運作的過程。

· 災難恢復描述的是在某次災難襲擊后恢復服務的過程。在大多數情況下，企業將希望盡可能的避免這種情況，或者至少將其可能性降至最小化。

目前，在災難恢復和保持業務連續性方面，還有兩大被廣泛應用的定義。即恢復時間目標(RTO)和恢復點目標(RPO)——二者都為數據恢復確立了一個服務水平：

· 恢復時間目標確定了將業務恢復到正常運營狀態的預期或目標時間。一個零RTO意味著服務必須立即恢復，或者沒有中斷。一小時的RTO需要在一小時內恢復應用程序至正常使用狀態。

· 恢復點目標則表示的是必須將服務恢復至歷史時期的某點。一個零RPO意味著服務必須從那一歷史時間點開始，所有數據均必須恢復，不能丟失(針對銀行應用程序是必須的)。而24小時的RPO則意味著只需恢復到昨天的數據即可(可用于測試/開發環境)。

制定一套災難恢復計劃

在理想的情況下，所有的應用程序應該恢復至RTO等于零，且RPO等于零，但從可行性和成本方面來看則是站不住腳的。

相反，任何災難恢復和保持業務連續性規劃都應該始于建立災難場景，對災難場景的重要性和影響進行評估，并將其應用到每款應用程序中。例如，故障場景包括：

· (火災、停電、洪水、地震)造成的損失或損害。

· (火災、水災、危險災害、化學事件、輻射)造成無法訪問基礎設施。

· (心懷不滿的員工或網絡攻擊)犯罪行為或惡意傷害。

· (軟件錯誤，升級失敗，數據損壞)造成系統或應用程序故障。

我們可以評估每款應用程序發生故障失敗所造成的影響，并用它來決定我們的RTO/RPO服務級別目標(SLO)。同樣，這里也有一些例子：

· 電子郵件系統的停機影響——高沖擊;RTO = 30分鐘，RPO =零。

· 銀行核心應用程序的停機影響——關鍵性沖擊;RTO =零，RPO =零。

· 隔夜報告程序的停機影響——低影響;RTO=4小時，RPO = 24小時。

在今天這樣一個永遠在線的世界中，大多數面向客戶的應用程序預計都將需要保持24/7全天候的運行。這會降低一定的SLO，但應用程序的設計可以通過從后端功能分離前端接入訪問來盡量減少。

顯然，無論一款應用程序是否已經被虛擬化，其技術是否獨立，業務恢復的要求必須首先確立。事實上，應該始終由企業的業務部門來提供他們具體需求方面的指導，而不是讓IT強加標準，這一直是傳統的經營運作模式。

虛擬化如何幫助災難恢復

虛擬化將服務器的物理資源抽象成邏輯結構，代表硬盤，網卡、磁盤控制器。處理器、內存和網絡端口以配置文件中的參數來表示，硬盤則用本地或共享存儲的文件來表示。

因此，備份虛擬機(VM)是復制一個文件副本和配置數據的一個簡單的情況。此外，可以實現遷移虛擬機到替代硬件，即使物理硬件是不相同的。這使得能夠更容易的管理硬件故障問題。虛擬化的功能解決了災難恢復和保持業務連續性在以下幾個方面的問題。

簡單的備份/恢復

恢復通常是基于創建一個備份和在一個災難恢復的情況下從這些備份副本恢復的需要。為了滿足這種需求，虛擬機管理程序所提供的功能，允許備份可以通過復制VM的內容。為了確保數據的完整性，虛擬機運行的代理軟件或工具在復制VM文件時停止或暫停I/O。

一個簡單的備份可以用來提供文件、應用程序或虛擬機級別的恢復，這取決于備份軟件的復雜性。備份整個虛擬機快照會影響一些系統允許存儲系統快照的功能，結合虛擬快照卸載處理工作，同時保持數據的完整性。

虛擬機遷移

雖然不是嚴格意義上的數據恢復過程，能夠在物理硬件之間動態地遷移虛擬機的能力減少了硬件故障的影響。VM遷移本身并不能防止服務器故障，但可用于當發生局部故障時遷移虛擬機，無論是在服務器或其它組件(例如網絡)。

虛擬機遷移也可以在當服務必須從一款硬件(為了維護)移除或為了減輕數據中心失敗的風險(如應對即將到來的風暴或颶風可能對數據中心運營的影響)時，作為一個控制過程。從這個意義上說，虛擬機遷移更類似于保持業務連續性，確保服務器繼續運行，即使是在發生潛在或實際事件的情況下。

高可用性/容錯能力

這些是管理程序的功能，使虛擬機能夠在硬件故障的情況下保持運行。提供了兩個層次的服務。高可用性監控虛擬機，并在服務器發生故障的情況下， 在替代硬件上重新啟動。這導致了一個小故障的應用程序重新啟動。其他在替代硬件運行ghost虛擬機映像，使得該映像在服務器發生故障的情況下成為生產服務的一體，一般沒有應用程序中斷。

當然，使用這些功能可能需要共享存儲硬件(用于存儲虛擬機的配置和數據)，同時也是收費的。一些供應商支持使用基于陣列的復制與高可用性/容錯功能相結合的能力。這使得硬件配置能夠跨越一個很短的距離(幾百米)，并創建一個Metro cluster。Metro cluster能夠減輕數據中心的中斷或嚴重的硬件故障，而無需部署復雜的應用程序集群。

連續備份

某些第三方應用程序使用虛擬化來攔截虛擬機的寫I/O，并 創建一個遠程備份映像。這個過程是異步發生的，并提供了在故障的情況下的虛擬機副本，可用于在主站點發生故障時加強故障轉移復制。使用這種系統的應用程序的RPO將取決于數據可以遷移到場外的速度。

應用程序彈性

正如所討論的那樣，虛擬化通過抽象物理硬件組件提供好處。在執行災難恢復/業務連續性時需要考慮的另一件事是在應用程序本身直接內置恢復功能。

應用程序的彈性是通過運行許多應用程序實例來實現的，每一款均可能失敗，當然也能夠通過替代硬件來重新啟動。這種設計是不直接依賴于虛擬化，但可以通過多個管理程序和硬件的配置來實現很好地工作。在未來，我們將看到業務連續性/災難恢復的彈性將借助container容器的使用來實現，這是一種應用程序虛擬化的形式，并已經開始在被廣泛采用。

參照諸如RTO和RPO等災難恢復/業務連續性原則，我們可以應用恢復選項以滿足應用程序的需求。有些應用程序會得到充分的高可用性/容錯能力，而其他應用程序可能只是使用虛擬機管理程序的快照進行備份。在某些情況下，持續備份或全高可用性/容錯能力與基于陣列的復制可以是合理的。其完全只是基于具體要求來應用技術。