在過去十年，很多文章都曾經宣稱企業現在應該實現完全虛擬化了。這些文章的理論基礎在于虛擬化已經是一種十分成熟的技術，并且現在能夠對幾乎所有負載完成虛擬化，甚至包括那些大型的資源密集型應用。還有一些文章爭論稱虛擬化只不過是遷移到公有云環境之前的一種過渡方式。不論這些文章表達怎樣的觀點，但是有些負載應該繼續運行在物理硬件當中。在這篇文章當中，我將會列舉一部分這樣的負載類型，并且討論對這些負載進行虛擬化是否有意義。

 [[141088]]

負載太大導致虛擬化失敗

正如上面所提及的那樣，服務器虛擬化技術已經足夠成熟，甚至能夠對非常大規模的資源密集型負載順利完成虛擬化。然而對這種類型負載進行虛擬化的問題在于，如何實現容錯機制。

設想這樣一種情況，你所在的企業擁有一種非常關鍵、并且異常消耗資源的數據庫應用，現在其運行在物理集群當中，能夠防止服務器級別的故障。

不論是否進行虛擬化，我們都應該使用故障轉移集群來保護負載。可以在虛擬服務器環境當中創建一個虛擬機集群，或者使用主機級別的集群功能，如果發生主機故障可以將虛擬機(自動實時遷移到另外一臺虛擬化主機當中。然而這種方式存在一種問題，就是資源消耗。

服務器虛擬化的前提就是所有虛擬機共享一個物理硬件資源池。異常消耗資源的負載可能會占用大量服務器資源，因此如果目標主機上已經運行了任何其他負載，那么資源密集型應用非常有可能無法完成故障轉移過程。因此對于現在的情況來說，將這種負載運行在物理硬件當中更加實際，除非有非常緊迫的業務需求要對這個負載進行虛擬化(比如為最終遷移到云中做好準備)。

資源密集型負載

在之前的部分我已經從故障轉移集群的角度對資源密集型負載進行了討論。然而，還有一些邏輯問題可能會妨礙你對一些大型負載進行虛擬化。像VMware ESXi和微軟Hyper-V這樣的hypervisor會限制虛擬機的規模。比如，它們會限制分配給虛擬機的vCPU和內存數量。當然，只有極少數的、非常大型的虛擬機才會超過這種限制，但是這種限制是真實存在的，如果你正在考慮將要進行虛擬化的負載足夠大，那么有可能正好遇到這種限制。

硬件依賴關系

在決定是否進行虛擬化之前，你還應該考慮負載對于物理硬件的依賴性。硬件依賴性存在多種形式。比如，我最近看到一個應用程序在底層明確規定只能使用一種非常特定的主機總線接口卡。這種依賴關系將會妨礙特定應用程序在虛擬服務上正常工作。

你可能會遇到的另外一種硬件依賴關系和版權保護相關。有些應用程序會檢查機器是否插入了USB閃存盤或者校驗處理器的序列號，以防止應用程序被非法復制。對于使用物理硬件作為復制保護機制的應用程序來說，通常不能對其進行虛擬化。

罕見或者不支持的操作系統

你可能還會發現不可能虛擬化那些運行有非常罕見的、超過運行生命周期或者不被支持操作系統的服務器。不僅hypervisor廠商不能支持這些操作系統，并且像MVware Tools和Hyper-V Integration Services這樣的組件也只能支持特定的操作系統類型。

對于虛擬化那些運行過期操作系統的服務器來說，實際上只有兩種觀點。一種想法是建議永遠不要在hypervisor上運行不被支持的操作系統;而另外一種觀點會讓你繼續進行操作，將服務器進行虛擬化能夠降低對于過期物理硬件的依賴性。

我曾經虛擬化一臺運行Windows NT的服務器，即便Windows NT沒有位于hypervisor廠商的官方支持列表當中。盡管虛擬化過程比我想象的還要復雜，但是最終還是成功完成了，企業終于能夠將這臺配置古老硬件的服務器退役了。

物理存儲方面的依賴關系

你可能希望避免虛擬化某種負載的***一個原因是一些負載對于物理存儲具有依賴關系。公平來說，Hyper-V 和 VMware都擁有自己的方式能夠將虛擬機連接到物理磁盤上。比如在Hyper-V當中，物理存儲就被作為一種iSCSI直通磁盤。

盡管hypervisor廠商完全支持直通磁盤，但是使用這種方式有可能使得備份流程更加復雜。如果從主機層級創建備份，那么我所見到的大多數Hyper-V備份應用程序都不支持對直通存儲進行備份。

在我看來，現在不應該對所有負載都進行虛擬化。但是要記住，虛擬化技術也在不斷發展，現在不適合虛擬化的服務器并不意味著在一年或者兩年之后，依然不能對其進行虛擬化。