通過Windows Server 2012提高虛拟化環境下的高可用性

虛拟化環境高可用簡述

通常情況下，在虛拟化環境中伺服器會提供一種基礎的高可用環境，即在各實體主機節點之間建構叢集，然後對需要保護的虛拟機的啟用高可用；但是這種高可用環境一般隻能檢測實體環境的故障，例如實體主機當機等，并且恢複的操作方式是将故障實體主機上的虛拟機選擇另外一台可用的叢集實體節點啟動，好一些的叢集政策通常還會加入對選擇啟動節點的“資源尺寸”進行測量，并采用優化的方式在叢集内的剩餘節點啟動等方式。無論怎樣，該方法針對的隻是實體資源監控而非虛拟機資源；是以有些虛拟化廠商提供了可以通過在VM中插入插件的方式，并通過虛拟化層與該插件的“心跳”确定VM的存活狀态，進而實作對虛拟機的監控；例如，如果虛拟化層發現該受檢測的虛拟機無法連接配接，那麼将采用嘗試在該實體節點重新開機虛拟機的方式意圖恢複該VM及其上的應用，但這種方式局限性也很明顯，因為虛拟層監控的是VM而不是應用本身。如果該應用還可以正常對外提供服務，但由于VM插件故障造成無法通信造成虛拟化嘗試以損失該應用的狀态的方法重新開機VM，這個代價是相當不可以接受的。

是以有些虛拟化廠商通常提供以下兩種替代方案：

通過API方式擴充對VM内部應用的監控并實作與虛拟化層控制政策的調用

在VM之間實作對共享存儲的連接配接，并實作客戶機叢集Guest Cluster。

說到客戶機叢集Guest Cluster和主機叢集Host Cluster，這裡不妨做個簡單的比較來看看兩種叢集方式的優缺點：

主機叢集 Host Cluster

客戶機叢集 Guest Cluster

作業系統狀态

虛拟機移動性

應用程式監控和控制

應用程式在虛拟機間的移動性

備用資源開銷

額外的存儲配置

（為虛拟機配置設定存儲）

從上表中可以看到，雖然主機叢集方式可以節省備用節點的資源，節省為虛拟機單獨配置設定存儲的管理成本；但是由于缺乏對虛拟機内部資源監控，還是很少被一些關鍵應用所采用。而客戶機叢集方式建構較為複雜，尤其是存儲層面，而且還會有備援實體資源的浪費情況。

那麼有沒有一種相對兩全其美的方案呢？

在即将推出的Windows Server 2012中，給出了一個良好的答案。針對主機叢集方式提供了Failover Cluster的虛拟機監控功能，允許虛拟化層監控運作在虛拟機内部的應用健康狀态，并可以根據此狀态進行故障恢複操作。

具有這個功能後，在虛拟機内運作的應用，無論是SQL Server，Exchange，Lync或是IIS，隻要健康狀态出現問題，都可以通過與虛拟化層通信的通道觸發相應的故障恢複操作。

也正是因為這個非常有意義的功能，本文将提供較為詳細的步驟和建構方式描述Windows Server 2012下的虛拟化環境下如何通過Failover Cluster實作該功能。

配置虛拟機監控的前提條件

在配置虛拟機監控之前，必須先通過“故障轉移群集管理器”進行如下一些關鍵配置：

配置VM上的客戶機作業系統

客戶機作業系統必須是運作Windows Server 2012的虛拟機

客戶機作業系統和運作虛拟機的Windows Server 2012主機是相同的域或建立了主機域的信任關系的域成員。

給管理客戶機的叢集管理者賦權

運作故障轉移群集管理器的管理者必須是在客戶機VM的本地管理者組的成員。（當然我們在試驗中可以采用域管理者來完成）

在客戶機啟用虛拟機監控防火牆政策

打開Windows防火牆配置界面

打開客戶機的虛拟機監控

選擇“允許一個應用程式或功能通過Windows防火牆”

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346743950LVLi.png"></a>

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346743957r2iy.png"></a>

當然我也很建議采用Powershell完成上述工作，要知道我是很喜歡指令行的，哈。方法很簡單，打開Powershell界面，運作Set-NetFirewallRule  -DisplayGroup "Virtual Machine Monitoring" -Enabled True。

在故障轉移叢集完成配置虛拟機監控

如果你做過一次一定不會覺得這個配置很麻煩，呵呵。隻需要在故障轉移叢集中完成幾個操作即可：

在故障轉移叢集的控制台，在角色目錄下右鍵點選需要在主機叢集中監控的虛拟機

在更多操作中選擇配置監控選項

之後就可以通過服務下拉清單選擇需要通過Failover Cluster監控的服務或應用了。

拿一個正在運作的服務作測試，這裡我們選擇Print Spooler服務。( 服務清單是從程序清單裡面拿到的名稱，當然通過Powershell修改是最友善的方式  Add-ClusterVMMonitoredItem –VirtualMachine GuestVM1 -Service spooler )

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346743970zwb5.png"></a>

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_13467439908wB0.png"></a>

虛拟機監控的工作方式和測試流程

我們首先來看一下Windows下服務的恢複方式，見下圖

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346743998n7j2.png"></a>

可以看到在第一次服務失敗和第二次服務失敗時，系統對服務自身采用的恢複方法預設是重新啟動；第三項則是系統不采用任何操作，是以将恢複方式交給了外部主機叢集的監控操作處理。

現在我們來模拟一下第一，第二次的應用故障，通過指令行 Get-Process spoolsv | Stop-Process, 可以在伺服器管理器觀察到第一二次停止程序，服務會自動進行重新開機恢複。但是當我們第三次模拟故障時，可以看到VM自動重新啟動了。

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346744004VOvK.png"></a>

回到故障轉移叢集，我們可以觀察到此時觸發了一個事件錯誤ID 1250

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346744012wqNy.png"></a>

如果我們使用微軟的System Center Operation Manger（SCOM）的話，我們可以利用這個錯誤ID在激發System Center Service Manger/Ochestrator等客戶化恢複流程。

而如果通過故障轉移叢集控制台觀察虛拟機運作狀态的話，可以看到虛拟機的狀态為應用程式關鍵狀态。

可以通過Powershell獲得該虛拟機的資源資訊 Get-ClusterResource “GuestVM1” | fl StatusInformation

虛拟機在Failover Cluster中的故障恢複政策為：

嘗試在叢集中的同一個實體節點中重新開機該故障虛拟機

如果仍然出現應用關鍵錯誤，則嘗試在叢集中的另外一個節點中嘗試啟動該虛拟機。

關于虛拟機監控的故障轉移政策，可以通過虛拟機設定中的配置來設定：

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_134674402128TU.png"></a>

<a href="http://3387405.blog.51cto.com/attachment/201209/4/3377405_1346744033nbBj.png"></a>

上述實驗在我的測試環境中測試完成，感覺還是很不錯的；作為客戶機環境的叢集有益的補充，相信Windows Server 2012的該功能将在企業級資料中心的“雲”環境中大展拳腳。

本文轉自 翟老貓 51CTO部落格，原文連結：http://blog.51cto.com/3387405/981916，如需轉載請自行聯系原作者