VMware服務器虛擬化中的熱備與恢復技術

顧景民　時陽

【摘 要】本文介紹了vmware ESXI虛擬化集群技術以及vmware虛擬服務器的備份和恢復。

【關鍵詞】虛擬化；VMware；ESXI；HA；SRM；備份；恢復

1 服務器虛擬化技術

服務器虛擬化技術是當下流行的一種技術，是指通過虛擬化技術將一臺計算機虛擬為多臺邏輯計算機。在一臺計算機上同時運行多個邏輯計算機，每個邏輯計算機可運行不同的操作系統(tǒng)，并且應用程序都可以在相互獨立的空間內(nèi)運行而互不影響，從而顯著提高計算機資源的利用率。

在虛擬化技術出現(xiàn)之前，每臺主機只能使用一個操作系統(tǒng)，在同一主機上運行多個應用程序通常會發(fā)生沖突，而采用部署多個應用中間件的方式，將有可能導致主機系統(tǒng)資源利用率降低，硬件成本高昂而且不夠靈活。通過采用虛擬機技術，將管理操作系統(tǒng)和應用程序有效分離，分別作為單一的個體運行。并且應用程序都可以在相互獨立的空間內(nèi)運行而互不影響，從而顯著提高計算機的工作效率?？梢詫崿F(xiàn)IT資源的動態(tài)分配、靈活調(diào)度、跨域共享，提高IT資源利用率，使IT資源能夠真正成為社會基礎設施，服務于各行各業(yè)中靈活多變的應用需求。

2 利用VMware HA工具實現(xiàn)服務器的熱備

VMware，Inc是一家可以提供服務器、桌面虛擬化的解決方案公司，在虛擬化和云計算基礎架構領域處于全球領先地位，所提供的、解決方案可通過降低復雜性以及更靈活、敏捷地交付服務來提高IT效率。VMware眾多虛擬化技術中，HA不僅可以實現(xiàn)虛擬機的熱備，還可以實現(xiàn)虛擬機的集群，資源的動態(tài)分配。

VMware HA將一組物理主機合并為一個具有共享資源池的群集，HA監(jiān)控群集中的所有主機。一旦某臺主機發(fā)生故障，VMware HA會立即響應，并在另一臺主機上重新啟動受影響的虛擬機。每一臺VMware ESXI服務器配有一個HA代理，持續(xù)不斷地檢測群集中其他主機的心跳信號。ESXI主機每隔五秒就會通過服務主機的網(wǎng)絡連接發(fā)送心跳信號。假如某臺ESX主機在連續(xù)三個時間間隔后都還沒有發(fā)出心跳信號，那么該主機就被默認為發(fā)生了故障或者與網(wǎng)絡的連接出現(xiàn)了問題。在這種情況下，原本在該主機上運行的虛擬機就會自動被轉移到群集中的其他主機上。反之，如果一臺主機無法接收到來自群集的其他主機的心跳信號，那么該主機便會啟動一個內(nèi)部進程來檢測自己跟群集中其他主機的連接是否出現(xiàn)了問題。如果真的出現(xiàn)了問題，那么就會中斷在這臺主機上所有正在運行的虛擬機，并啟動預先設定好的備用主機（圖1）。

圖1

VMware HA的群集具有以下功能：

（1）當虛擬主機發(fā)生硬件故障時，將為故障切換容量范圍內(nèi)所有正在運行的虛擬機提供自動故障切換?？梢栽跓o需任何人員干預的情況下自動檢測服務器故障和重啟虛擬機。

（2）VMware HA可以提供動態(tài)的、智能的資源分配和虛擬機優(yōu)化。

（3）VMware HA支持易于使用的配置和使用Virtual Center進行監(jiān)控。HA確保該容量總是可用的（在指定的故障切換容量限制內(nèi)），以便重啟所有受服務器故障影響的虛擬機（基于為虛擬機配置的資源預留）。

（4）不間斷地監(jiān)控容量利用率，并“預留”備用容量以便能夠重啟虛擬機。當未發(fā)生故障時，虛擬機可以完全利用備用故障切換容量。采用VMware HA后，對于虛擬主機的維護工作將減少50%以上，同時利用HA的資源監(jiān)控和分派功能在較短的時間內(nèi)了解具體應用對資源的要求。

3 利用VMware SRM實現(xiàn)災難恢復

VMware vCenter Site Recovery Manager（SRM）是一個業(yè)務連續(xù)性和災難恢復解決方案，可以計劃、測試和執(zhí)行一個站點（受保護站點）和另一個站點（恢復站點）之間 vCenter 虛擬機的恢復。它提供了用于災難恢復管理、無中斷測試和自動化故障切換的功能，可以自動在服務器群和災難恢復站點之間進行自動化故障轉移，也可以在兩個包含活動工作負載的站點之間的故障切換。使用SRM能實現(xiàn)恢復計劃的設置、測試和執(zhí)行等關鍵要素的簡化和自動化（圖2）。

圖2

使用SRM實現(xiàn)災難恢復的流程如下：

（1）設置恢復基礎架構：SRM將指導用戶完成連接到遠程站點和正在使用的存儲復制軟件這一過程。另外，還可將生產(chǎn)資源（包括計算和網(wǎng)絡資源）映射到恢復站點上的相應資源。

（2）創(chuàng)建恢復計劃：SRM提供了直觀界面，可幫助用戶針對基礎架構的各種故障切換情形和不同部分創(chuàng)建恢復計劃。用戶可以將虛擬機掛起或關閉，以釋放資源供恢復過程使用。用戶還可以指定虛擬機的啟動順序，設置自動執(zhí)行用戶定義的腳本，并能根據(jù)需要確定暫?；謴瓦^程的位置。

（3）測試恢復計劃：SRM通過使用存儲陣列的快照功能并將虛擬機連接到用戶的隔離測試網(wǎng)絡，自動在恢復站點上創(chuàng)建無中斷且隔離的測試環(huán)境。它會自動執(zhí)行要在實際故障切換時使用的恢復計劃，并在測試完成后清除測試環(huán)境。測試結果可保存起來，以便隨時查看和導出。

（4）自動執(zhí)行故障切換：一旦管理員從VMware vCenter Server啟動了恢復計劃，SRM即會自動執(zhí)行恢復計劃中的步驟，以確?；謴瓦^程的執(zhí)行與當初的設計完全一致。管理員可以了解整個執(zhí)行過程。但為了保證災難恢復的有效性及可操作性，在部署SRM之前，首先必須對如下關鍵的問題進行仔細地規(guī)劃，否則將嚴重影響SRM恢復的有效性。

3.1 虛擬機布置

對于VMware SRM，簡單地將所有的虛擬機存儲在一個SAN當中是遠遠不夠的。對于成功的SRM部署，虛擬機在存儲區(qū)域網(wǎng)絡（SAN）中的位置也是十分重要的。

為什么虛擬機位置十分重要？首先，虛擬機位置可以影響SAN的復制。VMware SRM依賴于SAN提供的復制技術。VMware SRM不能管理或者提供這種技術；它需要的只是其可用、恰當配置和可操作性。大多數(shù)SAN復制技術在邏輯單元號（LUN）層進行復制，意味著只能以整個LUN決定是是否復制。這樣的結果是，組織必須確保需要通過VMware SRM保護的虛擬機被存放于同一個可被復制的LUN當中（否則SRM將不能提供保護）。一些組織可能會在第一次安裝和配置SAN復制時考慮解決虛擬機放置問題。如果沒有，就需要在安裝SRM之前解決這個問題。可以使用VMwareStorage VMotion實現(xiàn)在沒有宕機的情況下將虛擬機在數(shù)據(jù)存儲間進行遷移。

其次，虛擬機位置重要的原因是VMware SRM在操作時需要同時移動整個LUN（或者數(shù)據(jù)存儲）。在SRM故障轉移過程中，有些虛擬機不能同時進行移動，就需要將它們放置于不同的數(shù)據(jù)存儲當中。只有當災難恢復過程中，位于同一個數(shù)據(jù)存儲的所有虛擬機可以同時進行故障轉移的情況下，才可以將虛擬機放置于同一個數(shù)據(jù)存儲當中。同樣，Storage VMotion可以在沒有產(chǎn)生宕機的情況下將虛擬機移動到恰當?shù)臄?shù)據(jù)存儲之中。

為了解決這個注意事項，組織需要在文檔中明確規(guī)定虛擬機在SAN中的存儲位置。一旦位置被確定下來，就需要對一些虛擬機進行遷移，比如將虛擬機移動到可復制的LUN之中，實現(xiàn)通過VMware SRM進行保護。直到SRM實施過程中才會進行另一部分必要的遷移。擁有這些文檔可以簡化之后的遷移過程。

3.2 規(guī)劃災難恢復計劃

VMware SRM可以為非虛擬化資源提供集成特性，比如運行腳本來控制網(wǎng)絡設備。VMware SRM的正確定位為：災難恢復策略中的一個組成部分。組織仍然必須定義災難恢復事件，比如怎樣才能構成一個合格的災難恢復事件，組織仍然必須定義多個角色來表明災難事件中的任務分配。VMware SRM不能替換這些角色，但是VMware SRM需要組織這些定義來使得這項技術可以適用于災難恢復策略。尋求以技術作為策略的組織最后會發(fā)現(xiàn)很難達到項目的成功準則。

雖然VMware SRM提供了服務器群資源整合功能，但SRM只是企業(yè)中一個全面的災難恢復戰(zhàn)略的一部分。仍然需要一個為數(shù)據(jù)中心余下的物理機器制定一個完善的災難恢復計劃。用戶必須明確定義災難恢復事件以及處理災難事件相關的各種角色和任務，并將這些內(nèi)容與SRM結合起來，以便使SRM能根據(jù)企業(yè)的實際需求制訂模型化的災難恢復戰(zhàn)略。

4 總結

利用VMware技術實現(xiàn)服務器的虛擬化，以及熱備和恢復，充分發(fā)揮了服務器的硬件性能，能夠在確保企業(yè)投入成本的同時，提高運營效率，節(jié)約能源降低經(jīng)濟成本和空間浪費，對于發(fā)展迅速，成長規(guī)模大的用戶來說，可以通過服務器虛擬化技術帶來更多的經(jīng)濟效益。

【參考文獻】

[1]Whats New in VMware Data Recovery 2.0 Technical Whitepaper[M].VMware：Jul 12，2011.

[責任編輯：王楠]