虚拟化与高性能计算是天然的矛盾?

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

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

我本人对虚拟化技术并无批驳之意,因为它确实为专注企业级运算的数据中心节约了大量成本,从这个角度看,它完全称得上是一项革命性新技术。

虚拟化技术之所以能在企业中发挥如此大的作用,原因之一在于目前企业对硬件的利用率不高(多数不超过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操作、清空所有缓冲区等等,然后将虚拟机状态以文件形式转储至存储设备。曾有几家公司尝试在集群中实施这一设想,但都以失败告终。目前,又有一家公司开始进行这类尝试。不过从根本上看,这是一个相当难解决的问题。

总结

从某种程度上讲,虚拟化技术能够有效减少服务器数量并提高剩余服务器的利用率,的确为企业的IT实施带来了一场革命。 然而,人们错误地把它当成了万灵丹,希望它可以应用于一切可能的IT领域(包括高性能计算在内)。在我看来,虚拟化技术或许可以通过以下三种途径来影响高性能计算:

利用虚拟化技术选择操作系统分配和/或其它软件需求,并指定合适的计算节点来运行相应软件。

利用虚拟化技术将进程从某个节点(源节点)移动至其它节点(目标节点)。

利用虚拟化技术轻松创建检查点。

以上三种设想看似简单,实际上却很难在高性能计算中实现。第一种设想能够提供任务所需的操作系统或分配资源,引起了很多人的兴趣,但目前这样做会造成性能损失;第二种设想是在节点间移动虚拟机,这在高性能计算中很难实现,因为许多应用都要大量用到网络和/或存储(IO);而第三种设想,即利用虚拟机快速创建检查点也存在相同的网络和/或存储依赖问题,因此很难应用于高性能计算中。

因此,从目前的情况来看,虚拟化技术尚无法在高性能计算领域占据一席之地。尽管我们并不能由此断定未来情况不会发生变化,但目前虚拟化技术要进入高性能计算领域尚需时日。我很遗憾地说,高性能计算并不是虚拟化大锤所寻找的那颗钉子。

【编辑推荐】

  1. 服务器虚拟机备份实战
  2. Hyper-V 虚拟化技术专题
  3. 虚拟化的“赤壁之战”
  4. 服务器虚拟化
责任编辑:张存 来源: 网界网
点赞
收藏

51CTO技术栈公众号