即使虛擬化逐步成熟，高可用性HA仍然是集群裡最難懂的組件之一。服務器集群能啟動高可用性，它是一個hypervisor功能，當虛擬機崩潰時能限制宕機時間。VMware vSphere、Microsoft Hyper-V and Citrix XenServer都提供了高可用性功能，減輕虛擬架構中的災難恢復任務。
太多的人在沒有理解高可用性的情況下實施虛擬化項目。更糟的是，管理員在服務器集群實施期間忽視高可用性，導致現在發現它從解決問題的方案變成需要解決的問題。
事實上，高可用性能解決一些列問題。它就是一個簡單的服務，無論你使用何種hypervisor，在主機發生故障後重新啟動虛擬機。持續的可用性是個理想目標，但是虛擬機仍然經歷一些宕機。
高可用性通常與熱遷移相關，如XenMotion、vMotion，但實際上不是，我曾見過在第一次主機發生故障後，服務器集群裡出現大量問題，由於混淆了這兩個概念。
高可用性技術越來越智能，但是要注意下面的問題可能使你的服務器集群崩潰。
DNS如何影響高可用性
與VMware HA結合，域名服務器（DNS）分辨率會成為嚴重的問題。要允許服務器集群節點相互通信，VMware對DNS分辨率擔負重要責任。通常，這不是問題。但如今很多的IT人員已經習慣DNS是個服務的概念，不需要進行管理。
這種不干預政策的部分原因在於Windows的動態DNS功能。許多管理員沒有像以前那樣花心思對待DNS，因為動態DNS現在自動執行多數任務。但是VMware服務器沒有使用動態DNS。
如果在服務器集群中使用VMware HA，確保你的管理網絡IP地址和相關的主機名都進入到DNS。在進行變更或添加附件到虛擬環境中時，需要進行手動操作與維護。如果DNS沒有正確配置，VMware會出現明顯的提示說明，但是如果發現得太晚就容易忽略這個提示。
多站點服務器集群中的DNS分辨率
DNS分辨率問題也會影響多站點Hyper-V集群。Hyper-V的Windows Failover Clustering服務現在能跨子網。在某些方面，這種架構很好，因為你不再需要使用復雜的網絡技術跨不同的地點管理。但另一方面，故障轉移到第二個站點的虛擬機通常需要處理新的子網。
從服務器方面來說這不是大問題，但對於客戶端就造成問題。客戶端配置的是存活時間值，決定緩存DNS報道需要多久。故障轉移後這些報道就過時了。在物理的災難恢復中，通常不是問題，因為你可能需要處理更多重要的問題，如“數據中心正在崩潰！”但在虛擬架構中，當虛擬機偶然遷移到另一個可替換站點時就會出現問題。
高可用性問題不專門出現在Hyper-V集群中。在不同的子網啟動虛擬機的災難恢復的服務器集群都會經歷類似的問題。
故障恢復命令的重要性
DNS問題凸顯了服務器集群管理中故障恢復命令重要性這個事實。一些服務器集群組織故障恢復命令比其他的好。例如VMware HA讓服務器集群自己處理故障恢復命令。其他的如Hyper-V，管理員手動決定發生故障後虛擬機往哪遷移。
你不想看到的是虛擬機移到不合適的服務器集群節點，如移到多站點集群的另一端，或者超載的節點。特別注意你的故障恢復命令，確保平衡集群負載。
發生主機隔離該怎麼做？
當服務器集群主機仍然在線時就會出現主機隔離，但它已不能與其他節點通信。主機隔離的問題在於隔離的主機仍然運行虛擬機。在VMware HA隔離事件中，這些虛擬機通常運行在不同的虛擬交換機上，不會受到隔離的影響。集群可能想將這些虛擬機故障恢復到隔離區之外，但是如果一台隔離的主機缺少虛擬機的磁盤文件就不能實現。
有幾種方式修復這個問題。很明顯，將隔離的主機重新召回來在線是最佳方案。但是如果不能這樣做，你需要關閉虛擬機，讓存活的集群節點能故障轉移這些虛擬機。注意高科用性解決方案的隔離響應設置，確定哪個設置能滿足你的特別需求。在主機發生隔離時，許多功能允許你選擇繼續運行或者關閉虛擬機。
高可用性是虛擬架構中的有用組件，但是不能在服務器集群中繞開重要的設置來管理讓人興奮的負載均衡功能。否則，就會出現許多棘手的問題。
