我相信，服務器集群的最大優點是它可以主將VM從一個主機遷移到另外一個主機。這樣的話，就可以提高服務器和應用系統的運行時間。

 

　　在我的環境中，當內存不足、CPU負載偏高或者虛擬主機遇到較高的I/O壓力時，我會收到警報。如果我不能確定真正的原因或者系統需要重啟，我就可以主動將VM遷移到集群內的其他主機。

 

　　如果這是一個單機，或者說，在主機重啟期間，VM不可以關閉;如果重啟之后，問題依然存在，我就不得不延長VM的停機時間直到我找到了問題的起因。但是，在虛擬主機集群中，VM就可以被遷移到其他的主機直到問題解決。

 

 

　　因為集群中的主機監控著所有VM的活動，因此，當一個節點失效時，失效節點的負載就會被指派到另外一個替代的主機。如果需要較長時間解決失效主機的故障，只要替代它的健康主機有足夠的資源，VM就會正常工作。

 

　　在我的環境中，如果一個主機失效，VM會自動遷移到另外一個節點。雖然遷移的過程并不平滑，但工作負載自動變化幾乎沒有停頓。

 

 

　　我在一個7*24的組織中工作，因此，打補丁和升級工作就必須采取非常嚴格的管理。正常情況下，協調1—2臺物理主機的停機時間已經比較困難，而要關閉位于同一個物理主機的30多個VM的復雜性就會呈指數增長。

 

　　自從切換到單機之后，我妻子就不用擔心我要在周日早上1：00-6：00去升級虛擬主機，那個時候，我可以呆在家里休息。利用虛擬主機集群，當某個主機打補丁和重啟的時候，其上的VM遷移到替代的主機。打完補丁，VM再遷移到原來的主機。這樣，就允許我們在早上極短的時間內，不用停掉整個系統，完成集群的升級。

 

 

　　雖然主機集群環境有令人矚目的優點，但它同樣存在一些實施和管理上的缺點。

 

 

　　配置復雜可能是集群的最大缺點。建立集群框架、管理主機間的連通性、配置共享存儲都不是簡單的任務，可能涉及到組織內部多個團隊。你可能不害怕增加的復雜度，然而，很大程度上，都是技術性的工作;但是，隨著復雜度的增加，你可能會遺漏某些東西從而影響系統的穩定性。

 

 

　　升級到更新版本的產品和硬件組件也可能引起困難。因為，虛擬主機集群連接多個系統，各組件間發生著大量的、復雜的交互。

 

　　以更新主機上的多路徑I/O(MPIO)驅動為例，該操作會影響整個集群。首先，它影響節點轉移邏輯單元號(LUN)到其他節點的效率。同時，在更新MPIO驅動之前，集群中所有主機的HBA卡的Firmware都需要升級。如果FW不用升級，那也必須首先安裝HBA卡的驅動。

 

　　如果是單機，這可以通過1-2次重啟解決。在集群環境中，協調多個虛擬主機服務器則較為困難。升級實際的虛擬主機軟件一定是一個具有挑戰性的任務，因為集群節點的交互以及不同軟件版本支持(比如，SCVMM、Protection Manager等)。

 

　　一般情況下，廠商會為這些復雜升級提供詳細的、一步一步的操作操作指南;同時，大多數情況下，都會比較順利。

 

 

　　成本是另外一個主要的考慮因素。要實現一個虛擬主機集群環境，你需要復制部分基礎架構并同時保持虛擬機與主機的比例。此外，大部分廠商的實現需要一個SAN或者獨立的磁盤子系統。開源iSCSI或者廉價的磁盤陣列可能是個精明的選擇，但這些選項可能存在性能和穩定性的問題。

 

　　以我的經驗，在重要的基礎架構組件上選擇廉價的路線會產生問題，造成絆腳石。就因為選擇了一個特殊的配置能夠工作并不意味著就滿足了項目目標。如果管理部門對成本感到擔憂，你可以解釋給他們虛擬主機集群環境可以提高正常運行時間、提供更好的服務。依我看，如果正確實施，這種配置就完全對得起付出的成本。

 

　　最后，每個組織不得不判斷虛擬主機集群環境是否適合自己業務系統模式。雖然虛擬主機集群環境引入配置的復雜度、升級問題和潛在的額外成本，但是，你的環境可以從加強的服務器或者應用系統可用性和更好的管理上獲益。盡管有潛在的困難或不利因素，但是，我相信實施虛擬主機集群所付出的努力和成本是值得的。

 

　　以上就是本文對服務器虛擬化技術的優缺點的分析，希望本文對大家會有些許的幫助。