有一些逻辑问题可能会妨碍你对一些大型负载进行虚拟化。像 VMware ESXi和微软Hyper-V这样的hypervisor会限制虚拟机的规模。
尽管虚拟化技术提供了诸多优势，但是其并非适合于所有负载。
在过去十年，很多文章都曾经宣称企业现在应该实现完全虚拟化了。这些文章的理论基础在于虚拟化已经是一种十分成熟的技术，并且现在能够对几乎所有负 载完成虚拟化，甚至包括那些大型的资源密集型应用。还有一些文章争论称虚拟化只不过是迁移到公有云环境之前的一种过渡方式。不论这些文章表达怎样的观点， 但是有些负载应该继续运行在物理硬件当中。在这篇文章当中，我将会列举一部分这样的负载类型，并且讨论对这些负载进行虚拟化是否有意义。
1.负载太大导致虚拟化失败
正如上面所提及的那样，服务器虚拟化技术已经足够成熟，甚至能够对非常大规模的资源密集型负载顺利完成虚拟化。然而对这种类型负载进行虚拟化的问题在于，如何实现容错机制。
设想这样一种情况，你所在的企业拥有一种非常关键、并且异常消耗资源的数据库应用，现在其运行在物理集群当中，能够防止服务器级别的故障。
不论是否进行虚拟化，我们都应该使用故障转移集群来保护负载。可以在虚拟服务器环境当中创建一个虚拟机集群，或者使用主机级别的集群功能，如果发生主机故障可以将虚拟机(自动实时迁移到另外一台虚拟化主机当中。然而这种方式存在一种问题，就是资源消耗。
服务器虚拟化的前提就是所有虚拟机共享一个物理硬件资源池。异常消耗资源的负载可能会占用大量服务器资源，因此如果目标主机上已经运行了任何其他负 载，那么资源密集型应用非常有可能无法完成故障转移过程。因此对于现在的情况来说，将这种负载运行在物理硬件当中更加实际，除非有非常紧迫的业务需求要对 这个负载进行虚拟化(比如为最终迁移到云中做好准备)。
2.资源密集型负载
在之前的部分我已经从故障转移集群的角度对资源密集型负载进行了讨论。然而，还有一些逻辑问题可能会妨碍你对一些大型负载进行虚拟化。像 VMware ESXi和微软Hyper-V这样的hypervisor会限制虚拟机的规模。比如，它们会限制分配给虚拟机的vCPU和内存数量。当然，只有极少数的、 非常大型的虚拟机才会超过这种限制，但是这种限制是真实存在的，如果你正在考虑将要进行虚拟化的负载足够大，那么有可能正好遇到这种限制。
3.硬件依赖关系
在决定是否进行虚拟化之前，你还应该考虑负载对于物理硬件的依赖性。硬件依赖性存在多种形式。比如，我最近看到一个应用程序在底层明确规定只能使用一种非常特定的主机总线接口卡。这种依赖关系将会妨碍特定应用程序在虚拟服务上正常工作。
你可能会遇到的另外一种硬件依赖关系和版权保护相关。有些应用程序会检查机器是否插入了USB闪存盘或者校验处理器的序列号，以防止应用程序被非法复制。对于使用物理硬件作为复制保护机制的应用程序来说，通常不能对其进行虚拟化。
4.罕见或者不支持的操作系统
你可能还会发现不可能虚拟化那些运行有非常罕见的、超过运行生命周期或者不被支持操作系统的服务器。不仅hypervisor厂商不能支持这些操作 系统，并且像MVware Tools和Hyper-V Integration Services这样的组件也只能支持特定的操作系统类型。
对于虚拟化那些运行过期操作系统的服务器来说，实际上只有两种观点。一种想法是建议永远不要在hypervisor上运行不被支持的操作系统;而另外一种观点会让你继续进行操作，将服务器进行虚拟化能够降低对于过期物理硬件的依赖性。
我曾经虚拟化一台运行Windows NT的服务器，即便Windows NT没有位于hypervisor厂商的官方支持列表当中。尽管虚拟化过程比我想象的还要复杂，但是最终还是成功完成了，企业终于能够将这台配置古老硬件的服务器退役了。
5.物理存储方面的依赖关系
你可能希望避免虚拟化某种负载的最后一个原因是一些负载对于物理存储具有依赖关系。公平来说，Hyper-V 和 VMware都拥有自己的方式能够将虚拟机连接到物理磁盘上。比如在Hyper-V当中，物理存储就被作为一种iSCSI直通磁盘。
尽管hypervisor厂商完全支持直通磁盘，但是使用这种方式有可能使得备份流程更加复杂。如果从主机层级创建备份，那么我所见到的大多数Hyper-V备份应用程序都不支持对直通存储进行备份。
在我看来，现在不应该对所有负载都进行虚拟化。但是要记住，虚拟化技术也在不断发展，现在不适合虚拟化的服务器并不意味着在一年或者两年之后，依然不能对其进行虚拟化。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
