分析：虚拟化并不适用于高性能计算？

这是一个非常有趣的现象--新技术在诞生之初，往往会被人们视作包治百病的良药。这似乎正应验了那句老话："锤子在手，看什么都是钉子"。从某些方面看，我认为虚拟化技术已经成了一把锤子，人们正四处为其寻找钉子（或看上去像钉子的东西）。最近便有很多人认为，高性能计算或许是虚拟化锤子的又一颗钉子。

我本人对虚拟化技术并无批驳之意，因为它确实为专注企业级运算的数据中心节约了大量成本，从这个角度看，它完全称得上是一项革命性新技术。虚拟化技术之所以能在企业中发挥如此大的作用，原因之一在于目前企业对硬件的利用率不高（多数不超过50%）。而在高性能计算领域，硬件利用率往往会超过 90%。

有趣的是，在高性能计算中，即使硬件利用率突破了90%，也经常会发生大量任务列队等待合适资源的情况，计算需求仍然居高不下。资源管理器一般会以合理的方式安排工作，以便最充分地利用硬件资源，但某些情况下，可能没有足够的空闲资源来执行任务，这时管理器会一直保留该项任务，直到获得执行这项任务的必要资源。最终，硬件利用率似乎无法达到100%（如90%左右），而实际计算需求却远远高于100%。

因此，在高性能计算中利用虚拟化技术来整合未被充分利用的资源，进而提高计算效率的想法并不可行。一个简单的事实是，几乎所有高性能计算系统都要处在全负荷或已被过量预订的状态（如果您见过未被充分利用的高性能计算系统，请一定和我联系，我认识一大批渴望计算缩短周期的人J），但这并不意味着虚拟化技术在高性能计算领域就毫无用处。

虚拟化技术在高性能计算领域的潜在应用

我认为，虚拟化技术具备改善高性能计算的潜力，这集中体现在以下三个方面：首先，我们可以利用计算节点上的虚拟化硬件执行用户选定的分配任务。听上去似乎有些不可思议，但实际上，一个典型的集群中往往存在一组几乎完全相同的计算节点。也就是说，它们在任何方面都不存在差别（包括硬件和软件环境）。不过有些时候，您运行的应用可能是针对特定操作系统或内核，或是存在某种软件依赖关系，计算节点上的资源无法满足其需求。这时您会怎么做？

此时，人们往往会为此类应用创建单独的集群，以满足其特定的软件需求。不过这样做要付出相当高的代价。如果某家企业共部署了6项软件需求各不相同的应用，那么他们是不是就得构建六个不同的集群？有没有其它更好的办法呢？

虚拟化技术对此的解决之道是利用虚拟机（VM）来运行相应软件。在此情景中，那些节点会在计算节点上运行主机操作系统（相当于在计算节点上运行管理程序）。当用户向资源管理器提交任务时，可以自行指定希望在任务中使用的操作系统或内核等组件。在任务执行过程中，资源管理器会通知计算节点运行所需的软件，并将相应软件安装在虚拟机（VM）内。接下来，任务会在虚拟机上运行，处理完毕后，虚拟机被关闭，节点继续执行下一任务。如果这个设想得以实现，您就能在单个节点上混合运行Linux和Windows应用，或是将其用于需要特定操作系统（不在集群内）的其它应用。但世界上没有免费的午餐，这种美好的设想也不例外。

问题的关键是那些在虚拟机内运行、且需要访问IO和网络等硬件的应用。我们不妨假设一下，这些高性能计算应用很可能并行并在多个节点间运行（很可能使用MPI）。如果这些在虚拟机中运行的应用需要通过访问高速网卡来发送消息，就必须首先向主机操作系统发出请求，然后由其代表虚拟机与网卡进行通信。这种以主机操作系统为中介的通信方式不仅会降低系统性能，还会极大地增加通信延迟。访问节点内硬盘时也会遇到这种情况。据我所知，因使用高速网卡造成的性能损失应该在50%左右（即，在虚拟机中运行使用高速网卡的代码时会出现50%的性能损失）。最近情况有所改善，下降幅度已降至30%。同时，很多公司表示，他们可以通过驱动程序来支持虚拟机直接访问硬件。但截至目前，我还没有看到此类驱动程序的任何性能指标评测（早在两年前就有一家公司宣称拥有了原生的性能驱动程序，但时至今日都没有发布过任何性能指标评测）。因此，虚拟机访问硬件方面的困难确实限制了这种设想的实现。

另一个有望改善高性能计算的虚拟化技术设想是，将某个节点中运行的进程"移动"到其它节点。在VMWare领域，这个设想需要靠Vmotion（在Xen和其它虚拟化工具中采用其它名称）来实现。具体而言，就是将虚拟机从一组物理硬件移动至其它硬件环境，同时保持虚拟机的正常运行。很多人表示，如果发现任务中的某个节点即将出现故障，他们就愿意采用这种办法。但实际上，我们似乎并不能轻易地在即将出现故障的节点上找到某项任务，并在该节点真正出现故障前将这些任务移走。但移动虚拟机的想法或许能在维护方面发挥一定作用。也就是安排一些专门用于维护的节点，然后在维护窗口打开时将虚拟机移动至这些节点执行维护任务。不过总的来说，在运行高性能计算任务时移动虚拟机的做法还是存在一些问题。

我们再假设，即高性能计算的处理对象多为基于MPI的代码。其中一个问题是，MPI代码应当与内核"捆绑"，以期实现最佳性能（人们总是希望得到更高的性能）。但在VMWare环境下，最好不要将进程捆绑到特定内核，因为目标节点与源节点之间可能并不匹配，这会导致进程无法移动。另外还有人指出，固定进程会限制虚拟机的移动。

也许更重要的是，当人们移动虚拟机时，必须中止网络中所有的消息传送（收发），并且同时中断该虚拟机在移动过程中的一切IO流量。只有这样才能移动虚拟机。此外，人们还必须将来自源节点的消息和IO流量移动到目标节点。这对虚拟机来讲的确是个难题。最近的一次测试已成功地将某个执行本地IO操作的单个节点移动至其它节点。整个虚拟机移动过程共耗费了20多分钟。但假设测试的任务须在多个节点间运行，同时还必须完成消息传送，另外可能还得进行一些IO 操作，在此情况下，移动虚拟机的复杂性可能远远超出想象。由此看来，移动虚拟机并非是高性能计算的首选。

最后一个设想是利用虚拟机来充当检查点或重新启动应用。长期以来，人们就一直设想在高性能计算中实现独立于应用本身的检查点/重新启动功能。检查点主要是指代码进程的快照，用于捕获节点的计算状态。人们使用检查点，是希望在节点出现故障以及应用无法工作时，从最近一个检查点重新启动应用。如果没有检查点，应用就只能从初始状态重新启动。

当应用在虚拟机（虚拟机只是一种软件）上运行时，您就可以利用虚拟化技术轻松地创建检查点。您只需少量的准备工作，就能创建出虚拟机状态检查点，并将其写入存储设备。不然您还是要面对同样的问题，即在创建检查点之前使虚拟机保持"安静"。

最基本的问题是，如何在创建检查点之前使系统处于"安静"模式。这要求事先进行很多准备工作，包括停止处理器及其当前任务、终止所有的消息传送和 IO操作、清空所有缓冲区等等，然后将虚拟机状态以文件形式转储至存储设备。曾有几家公司尝试在集群中实施这一设想，但都以失败告终。目前，又有一家公司开始进行这类尝试。不过从根本上看，这是一个相当难解决的问题。