摘要：虚拟化产生的与日益精细的资源配置相反的趋势是所谓的服务器聚合。Taneja认为，把服务器聚合在一起的能力实际上是用许多物理的系统创建一个大型的虚拟机。

　　服务器在线2月12日报道这是一个非常有趣的现象--新技术在诞生之初，往往会被人们视作包治百病的良药。这似乎正应验了那句老话："锤子在手，看什么都是钉子"。从某些方面看，我认为虚拟化技术已经成了一把锤子，人们正四处为其寻找钉子(或看上去像钉子的东西)。最近便有很多人认为，高性能计算或许是虚拟化锤子的又一颗钉子。
　　
　　我本人对虚拟化技术并无批驳之意，因为它确实为专注企业级运算的数据中心节约了大量成本，从这个角度看，它完全称得上是一项革命性新技术。虚拟化技术之所以能在企业中发挥如此大的作用，原因之一在于目前企业对硬件的利用率不高(多数不超过50%)。而在高性能计算领域，硬件利用率往往会超过90%。
　　
　　有趣的是，在高性能计算中，即使硬件利用率突破了90%，也经常会发生大量任务列队等待合适资源的情况，计算需求仍然居高不下。资源管理器一般会以合理的方式安排工作，以便最充分地利用硬件资源，但某些情况下，可能没有足够的空闲资源来执行任务，这时管理器会一直保留该项任务，直到获得执行这项任务的必要资源。最终，硬件利用率似乎无法达到100%(如90%左右)，而实际计算需求却远远高于100%。
　　
　　因此，在高性能计算中利用虚拟化技术来整合未被充分利用的资源，进而提高计算效率的想法并不可行。一个简单的事实是，几乎所有高性能计算系统都要处在全负荷或已被过量预订的状态(如果您见过未被充分利用的高性能计算系统，请一定和我联系，我认识一大批渴望计算缩短周期的人J)，但这并不意味着虚拟化技术在高性能计算领域就毫无用处。
　　
　　虚拟化技术在高性能计算领域的潜在应用
　　
　　此时，人们往往会为此类应用创建单独的集群，以满足其特定的软件需求。不过这样做要付出相当高的代价。如果某家企业共部署了6项软件需求各不相同的应用，那么他们是不是就得构建六个不同的集群？有没有其它更好的办法呢？
　　
　　虚拟化技术对此的解决之道是利用虚拟机(VM)来运行相应软件。在此情景中，那些节点会在计算节点上运行主机操作系统(相当于在计算节点上运行管理程序)。当用户向资源管理器提交任务时，可以自行指定希望在任务中使用的操作系统或内核等组件。在任务执行过程中，资源管理器会通知计算节点运行所需的软件，并将相应软件安装在虚拟机(VM)内。接下来，任务会在虚拟机上运行，处理完毕后，虚拟机被关闭，节点继续执行下一任务。如果这个设想得以实现，您就能在单个节点上混合运行Linux和Windows应用，或是将其用于需要特定操作系统(不在集群内)的其它应用。但世界上没有免费的午餐，这种美好的设想也不例外。
　　
　　问题的关键是那些在虚拟机内运行、且需要访问IO和网络等硬件的应用。我们不妨假设一下，这些高性能计算应用很可能并行并在多个节点间运行(很可能使用MPI)。如果这些在虚拟机中运行的应用需要通过访问高速网卡来发送消息，就必须首先向主机操作系统发出请求，然后由其代表虚拟机与网卡进行通信。这种以主机操作系统为中介的通信方式不仅会降低系统性能，还会极大地增加通信延迟。访问节点内硬盘时也会遇到这种情况。据我所知，因使用高速网卡造成的性能损失应该在50%左右(即，在虚拟机中运行使用高速网卡的代码时会出现50%的性能损失)。最近情况有所改善，下降幅度已降至30%。同时，很多公司表示，他们可以通过驱动程序来支持虚拟机直接访问硬件。但截至目前，我还没有看到此类驱动程序的任何性能指标评测(早在两年前就有一家公司宣称拥有了原生的性能驱动程序，但时至今日都没有发布过任何性能指标评测)。因此，虚拟机访问硬件方面的困难确实限制了这种设想的实现。
　　
　　我们再假设，即高性能计算的处理对象多为基于MPI的代码。其中一个问题是，MPI代码应当与内核"捆绑"，以期实现最佳性能(人们总是希望得到更高的性能)。但在VMWare环境下，最好不要将进程捆绑到特定内核，因为目标节点与源节点之间可能并不匹配，这会导致进程无法移动。另外还有人指出，固定进程会限制虚拟机的移动。
　　
　　也许更重要的是，当人们移动虚拟机时，必须中止网络中所有的消息传送(收发)，并且同时中断该虚拟机在移动过程中的一切IO流量。只有这样才能移动虚拟机。此外，人们还必须将来自源节点的消息和IO流量移动到目标节点。这对虚拟机来讲的确是个难题。最近的一次测试已成功地将某个执行本地IO操作的单个节点移动至其它节点。整个虚拟机移动过程共耗费了20多分钟。但假设测试的任务须在多个节点间运行，同时还必须完成消息传送，另外可能还得进行一些IO操作，在此情况下，移动虚拟机的复杂性可能远远超出想象。由此看来，移动虚拟机并非是高性能计算的首选。
　　
　　最后一个设想是利用虚拟机来充当检查点或重新启动应用。长期以来，人们就一直设想在高性能计算中实现独立于应用本身的检查点/重新启动功能。检查点主要是指代码进程的快照，用于捕获节点的计算状态。人们使用检查点，是希望在节点出现故障以及应用无法工作时，从最近一个检查点重新启动应用。如果没有检查点，应用就只能从初始状态重新启动。
　　
　　当应用在虚拟机(虚拟机只是一种软件)上运行时，您就可以利用虚拟化技术轻松地创建检查点。您只需少量的准备工作，就能创建出虚拟机状态检查点，并将其写入存储设备。不然您还是要面对同样的问题，即在创建检查点之前使虚拟机保持"安静"。
　　
　　最基本的问题是，如何在创建检查点之前使系统处于"安静"模式。这要求事先进行很多准备工作，包括停止处理器及其当前任务、终止所有的消息传送和IO操作、清空所有缓冲区等等，然后将虚拟机状态以文件形式转储至存储设备。曾有几家公司尝试在集群中实施这一设想，但都以失败告终。目前，又有一家公司开始进行这类尝试。不过从根本上看，这是一个相当难解决的问题。
　　
　　总结
　　
　　从某种程度上讲，虚拟化技术能够有效减少服务器数量并提高剩余服务器的利用率，的确为企业的IT实施带来了一场革命。然而，人们错误地把它当成了万灵丹，希望它可以应用于一切可能的IT领域(包括高性能计算在内)。在我看来，虚拟化技术或许可以通过以下三种途径来影响高性能计算：
　　
　　1.利用虚拟化技术选择操作系统分配和/或其它软件需求，并指定合适的计算节点来运行相应软件。
　　
　　2.利用虚拟化技术将进程从某个节点(源节点)移动至其它节点(目标节点)。
　　
　　3.利用虚拟化技术轻松创建检查点。
　　
　　以上三种设想看似简单，实际上却很难在高性能计算中实现。第一种设想能够提供任务所需的操作系统或分配资源，引起了很多人的兴趣，但目前这样做会造成性能损失;第二种设想是在节点间移动虚拟机，这在高性能计算中很难实现，因为许多应用都要大量用到网络和/或存储(IO);而第三种设想，即利用虚拟机快速创建检查点也存在相同的网络和/或存储依赖问题，因此很难应用于高性能计算中。
　　
　　因此，从目前的情况来看，虚拟化技术尚无法在高性能计算领域占据一席之地。尽管我们并不能由此断定未来情况不会发生变化，但目前虚拟化技术要进入高性能计算领域尚需时日。我很遗憾地说，高性能计算并不是虚拟化大锤所寻找的那颗钉子。
　　
　　责任编辑：雨熙