虛擬化與儲存端遠端複製的整合，讓實現自動災難復原環境更容易

伺服器虛擬化技術成熟後，給災難還原（Disaster Recovery）的建置帶來全新的視角，讓備援系統的建置擺脫了硬體規格的束縛。而藉由VMware Site Recovery Manager（SRM）之類的虛擬平臺管理工具，搭配底層儲存設備提供的遠端複製（Remote Replication）功能，更能實現自動化的復原程序，並大幅簡化備援系統在管理、測試方面的複雜性，讓x86平臺的災難備援架構進入一個新的時代。

認識災難還原的兩大基本需求：執行服務與複製資料

直接了當地說，災難還原的基本需求只有兩個——（1）災難發生時，如何讓備援站點接手主站點的工作；（2）平時如何讓主站點與備援站點的資料維持一致。前者牽涉到的需求是如何讓服務在異地備援站點上正常地啟動執行，後者則牽涉到如何定期或連續地把資料從主站點抄寫到備援站點上。

讓備援站點接手工作

要讓備援站點接手主站點的工作，前提是備援站點的系統具有執行主站點應用程式的能力，在過去，這個需求就意味著必須在備援站點建置一套與主站點一模一樣的硬體設備與軟體授權。雖然這的確能保證備援站點的系統執行能力，但無論對於成本，還是日後的維運管理來說，都是很大的負擔。

而在伺服器虛擬化盛行的今日，就不再有這種困擾。藉由虛擬平臺的模擬，可讓伺服器的物理實體，與邏輯上呈現給外界的服務設備脫鉤。換句話說，只要有足夠的硬體資源，便可將備援站點的系統模擬成與主站邏輯上相同的系統，而不用管實際上的設備廠牌型號。

再考慮到備援站點通常不承擔平日的線上服務工作（除非是兩站點互為備援的架構），硬體設備的負擔相對較輕，因此在備援站可以一套較為高檔的實體設備，以虛擬化的方式同時充作主站多臺系統的備援，達到整併備援站機房的目的，以便節省建置與管理成本。

更進一步的架構，便是在備援站點以外，連主站點也一起導入虛擬化，藉由全面虛擬化的架構，實現更為彈性的硬體資源分配利用，更充分的發揮硬體投資的效率。

讓主站與備援站資料維持一致

要讓備援站點及時接手主站點的工作，除了備援站點的軟硬體須能執行與主站點一樣的服務外，還得讓備援站點擁有一份與主站點相同的資料，才能正常地帶起服務。

而要讓備援站點擁有與主站點相同的資料，便得依靠遠端複製工具的協助，將資料從主站點抄寫到備援站點。

就執行複製工作的層級來看，遠端複製工具可分主機端、網路端與儲存端。

（1）主機端複製：也就是透過在主機上安裝複製軟體，將主機上特定區域的資料經網路複製到指定的遠端位置。對於虛擬化環境來說，所謂的主機端又可分為（1）實體機器層：在實體機器上安裝複製軟體，可複製整臺實體機器上所有運行的虛擬機器資料；（2）虛擬機器層：在模擬出來的虛擬機器上安裝複製軟體，可複製特定虛擬機器上的資料；（3）應用程式層：針對虛擬機器上執行的應用程式，利用這些應用程式內建或另外安裝的軟體執行複製工作，可複製特定虛擬機器上特定應用程式的資料。

（2）網路端複製：透過特定的網路設備（如閘道器等），將主站上流經該網路設備的資料流自動複製一份，然後經網路送到備援站點上另一臺網路設備，最後再送到備援系統上。

（3）儲存端複製：無論哪種環境，資料的本體都是位於儲存設備上，對於建置有儲存區域網路（SAN）的環境來說，前端所有主機的資料都是位於後端的網路儲存設備上。因此可利用儲存設備內建的遠端複製功能，直接將資料經網路傳送到備援站的同型儲存設備上。

三種遠端複製架構同樣都能完成「將資料從主站送到備援站」的工作，作法雖有異，目的卻是殊途同歸。然而對於伺服器虛擬化環境來說，並不是三類架構都同樣適用。

伺服器虛擬化的基本概念，便是充分應用伺服器閒置的硬體資源，利用虛擬化將原來只有30～40%不到的資源利用率，提高到80～90%以上，以免運算資源閒置從而造成浪費。

這也就是說，經過虛擬化以後的環境，主機硬體的處理能量通常已被使用到一個高點，顯然的，此時如果要在主機上執行複製工作，便不適合選用主機端的複製產品。

主機端複製軟體在此的問題是必須消耗主機資源，但在虛擬化環境中，實體主機硬體資源的使用已相當緊繃，若有多個虛擬機器同時發起複製作業，很可能會造成主機的運作發生癱瘓。

因此較好的作法，便是將複製作業的負擔，從前端主機卸載到儲存設備或網路設備上。這兩類設備都不會占用前端主機資源，因此更適合虛擬環境使用。

虛擬化平臺下，已出現自動化災難備援管理工具

有了虛擬化平臺，以及合適的遠端複製工具後，對於建置一套低成本、高效率的災難備援環境，便只欠一個「虛擬化災難備援管理工具」的東風。

以目前的x86虛擬平臺來說，虛擬機器的本體與資料，大多是以特定的檔案格式存放在底層的磁碟區上，或是利用原生裝置映射（Raw Device Mapping，RDM）的方式直接存取實體磁碟區。而遠端複製工具要做的，便是把這些特定格式的檔案，或是實體磁碟區複製到遠端站點的儲存設備上。

但光是把資料從主站複製到備援站，以及在備援站的虛擬平臺上設定好對應於主站的虛擬機器，仍不能使備援站發揮作用。在災難發生時，必須按預設程序一一啟動虛擬機器，並掛載上對應的磁碟區，才能真正讓備援站的虛擬機器開始工作，而這些程序過去都得依靠手動來執行，或者是透過撰寫大量複雜的Script來讓這些程序自動執行，不管哪種方式，對管理者來說都相當不便。

而VMware SRM這種管理工具，便是為了解決前述這些困難而出現。

剖析VMware SRM的架構與特性

VMware SRM是在VMware Infrastructure架構下，搭配儲存端（或閘道器端）遠端複製功能的一種災難備援管理工具。VMware SRM本身是安裝在VMware VirtualCenter上的外掛程式，搭配儲存廠商提供的Storage Replication Adapter（SRA）軟體，便可與底層的儲存設備溝通，完成災難復原的程序。

在SRM架構中，實際負責複製資料的是底層儲存設備的遠端複製軟體，SRM則是提供一個管理介面與政策設定工具，用於設定兩站點的備援關係，以及故障失效切換的執行程序。至於SRA軟體同樣也是安裝在VirtualCenter上，以作為SRM與儲存設備間的中介橋樑，如前所述，SRA是由個別的儲存廠商提供，每一款儲存設備都有專屬的SRA軟體。

SRM等同於把大量的Script包在一個易於使用的介面裡面，只要先為兩端點底層儲存設備的磁碟區，設定好鏡像複製關係，然後到VMware SRM介面中，設定對應於磁碟區的虛擬機器、災難復原程序，以及其他細節參數即可。

當災難發生時，管理者只要點選SRM介面中的Failover選項，SRM便會通知儲存設備的SRA軟體，接下來SRA軟體便會通知備援站儲存設備，將預設鏡像複本磁碟指派給備援站上指定的虛擬機器，然後開機啟動。

透過VMware SRM架構，在災難備援上可得到以下好處：

成本相對較低

SRM本身需要依處理器數量與售後服務等級收費，但儲存設備的SRA軟體是免費提供。對於已導入VMware環境、且購置了儲存設備遠端複製功能授權的用戶來說，利用SRM建置災難備援環境需要的開銷相對有限。

大幅簡化操作程序

由於SRM把大量手動程序自動化了，只要設定好備援環境虛擬機器與儲存設備的磁碟鏡像關係，透過預設的故障失效切換程序，只要用滑鼠點選幾個選項，系統就會自動完成災難復原動作，在備援站自動啟動相對應的虛擬機器，並掛載上對應的磁碟。

比起必須依照厚重還原執行手冊，以手動方式逐一執行還原程序的傳統作法，在SRM下只要妥當設定好預設程序，接下來幾乎能全自動化進行，因此減少了人為操作復原程序發生錯誤的可能，進而提高了災難復原的可靠性。

隨時可執行備援站測試驗證

過去對於IT管理部門來說，要執行一次備援站的測試演練可是一件大事，必須提前幾個月制定演練時程，屆時切斷主站與備援站間的複製關係，同時還得讓各個主要服務的負責人到場監督，並依厚重的執行手冊依序實施復原程序。不但勞師動眾，而且也得花費相當長的準備與執行時間，才能驗證備援系統能否正常運作。

而在導入VMware SRM架構後，由於備援站已經被虛擬化了，利用單一管理平臺就能監管多個服務的運行，加上虛擬平臺也提供了虛擬網路功能，因此管理者可隨時利用SRM介面上的Test選項，便能按照與正常Failover相同的程序執行備援站的測試演練，而不會影響到主站系統的運作。

新一代自動化備援機制的不足

雖然VMware SRM具備許多較傳統實體備援環境更出色的特性，但畢竟SRM目前只是一套剛剛發展出1.0版的系統，仍存在許多限制。

只支援一對一備援環境

SRM只支援兩個站點的一對一備援，即使底層儲存設備支援多對一、或一對一對一的三站點備援架構，在SRM模式下也無法使用。

只能針對整個DataStore複製

SRM的複製是針對整個DataStore，而不能針對DataStore裡面的特定虛擬機器。但不同虛擬機器執行服務的重要性各有差異，很可能不是所有虛擬機器都必須在異地端建立對應的備援，若將優先性不高的虛擬機器也一併複製到異地端，顯然只是浪費頻寬。

固然RDM模式可避免這類問題，可讓一個實體磁碟機對應一個虛擬機器，但若虛擬機器的數量非常多，則磁碟區的畫分便會變得極為複雜，給管理帶來更多麻煩。

只能自動Failover，不能自動Failback

災難發生時，將原由主站負責的服務切換到備援站，只是災難復原程序的上半段。故障的主站點顯然不能置之不理，而當主站點修復後，還需透過Failback程序，將中斷期間的資料從備援站點回補到主站點，然後再恢復原來的主站點與備援站關係。

但目前的SRM只能自動執行將服務切換到備援站的Failover，對於反向的Failback程序，就只能依靠手動進行，透過儲存設備反向抄寫資料，然後掛載給虛擬機器。

當然前述限制只是暫時的，VMware在SRM的後續版本，應會陸續改善各類機制。

主流儲存端複製產品均支援VMware SRM架構

VMware SRM只是提供一個管理平臺與設定工具，災難備援中實際的資料複製必須依靠底層的儲存設備來執行，因此在這個環境中，一套支援SRM架構的儲存系統與其遠端複製軟體，是不可或缺的關鍵元件。

而要讓儲存設備融入SRM架構，則必須由儲存廠商為自身儲存產品分別撰寫搭配SRM用的SRA軟體。由於VMware身居x86虛擬化平臺的龍頭角色，當VMware在去年下半年宣布了SRM的架構後，很快就得到了幾乎所有主要儲存廠商的支持，紛紛為旗下的儲存產品線，撰寫了支援SRM架構的SRA軟體。因此目前各大廠的主要儲存產品線，都已能融入SRM架構，透過遠端複製功能協助災難備援環境的建置。

依VMware在2009年2月17日發布的《Site Recovery Manager Storage Partners》文件顯示，目前一共有12家儲存設備廠商、超過30款以上的產品系列可支援SRM架構，其中Dell Equallogic、EMC、FalconStor、HDS、HP、IBM與NetApp等7家的產品是臺灣企業環境較常見到的，我們將在附表與個別解決方案介紹中進一步說明。

儲存端複製產品有多種類型與多種傳輸模式（同步、非同步等）的區別，但由於儲存端複製是儲存設備的附加功能，選擇了一種儲存設備，也就決定了能用的遠端複製產品類型。因此選擇的餘地也有限。

但從另一方面來看，這問題又與儲存設備的位階，以及訴求的用戶類型有關，譬如說會購買中低階儲存設備的用戶，多半是財力有限的中小型企業，因此這類產品即使提供了同步複製模式也沒有太大意義，用戶不可能負擔得起同步複製的頻寬成本，必然都是以非同步模式為主；而有財力購置高階儲存設備的用戶，手上通常有須多關鍵性服務需要保護，不容許備援站的資料與主站點存在落差，同時也有能力負擔同步模式所需的高頻寬，此時同步模式的存在也才有實質作用。

 VMware SRM架構的6大元件說明 

資料來源：iThome整理，2009年3月

 VMware SRM的四大特性 

透過簡單介面自動執行

安裝SRM plug-in後，VI Client介面頂端的工作列便會多出一個SiteRecovery選項，搭配儲存設備提供的SRA軟體後，只要點選這個選項，便能進行災難復原相關程序的設定與執行。

隨時可執行備援系統測試驗證

設定好復原政策後，只要點選備援站點，就可看到工具列下方的Test選項。管理者可在任何時候按下Test，進行復原程序測試，備援站的虛擬機器可利用虛擬平臺的虛擬網路設定加以區隔，不會連接到實體網路上而干擾到主站的系統。

彈性的環境設定

在設定備援站環境時，為確保備援站在執行故障失效切換後，能具備承擔主要服務所需的效能，可預設將備援站本地端的一些虛擬機器，在備援系統啟動時自動停機，以把硬體資源空出，用於執行備援工作。

精確詳細的作業追蹤

SRM的執行介面提供了精細的追蹤狀態顯示，整個災難還原程序被分為11個主要步驟，各步驟又下分為數個子步驟，執行過程中，系統會清楚顯示目前的執行進度與狀況，利於管理者掌握還原程序。

【相關報導請參考「虛擬環境自動化災難備援解決方案採購大特輯」】