Xen和虚拟化技术.doc

Xen和虚拟化技术
发布日期:2005-8-2 12:29:14

现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机(VM: virtual machines),并且在每个虚拟机上各自运行单独的操作系统实例。这直接导致了虚拟机技术发展的又一个春天。在本文中,我们提出了Xen,一个高性能的用于资源管理的虚拟机监视器(VMM: VM monitor)。Xen能够支持的应用比如:server consolidation,co-located hosting facilities,distributed web services,puting platforms[12,16]和application mobility。
成功地对一台机器进行划分,使它能够支持多个操作系统的并发执行,这个过程具有很多的挑战。首先,虚拟机必须是彼此相隔离的:如果一个虚拟机的执行会影响另一个的性能,这是不可以被接受的。这一点在操作各个虚拟机的用户相互间并不信任的情况下显得特别重要。其次,它必须支持多种多样的不同操作系统以提供给各种异构(heterogeneity)的流行应用的支持(//这里的异构指的是应用开发依托的操作系统不同,因此在实现上也就有很大差异,使得应用并不能够跨平台移植,因为Xen不需要对应用程序进行修改,那么它就必须支持各种常用的操作系统;所谓流行的应用,就是那些大家常用的、必需的应用)。第三,由虚拟化技术引入的性能开销必须要小。
Xen操控(//host:操作和控制)的是常用的操作系统,但是需要对操作系统中的某些相关部分进行一些修改。在本文中描述和评估的Xen原型系统能够支持多个我们研发的XenoLinux guest OS实例的并发执行;每个实例都给出了和非虚拟化情况下的Linux 。目前,我们对Windows XP到Xen的移植还没有完全完成,但是已经能够运行简单的用户空间进程。BSD的工作也在进行中。
Xen使得用户能够动态地实例化一个操作系统以执行他们需要的应用。在XenoServer项目[15,35]中, exchange(//布置在这些场合中经济划算而且又具有战略意义的地方)的标准服务器硬件上配置了Xen。我们在启动一个新的虚拟机的时候需要执行许可控制(admission control),希望每个虚拟机能够以某种方式为它需要的资源付出代价。我们在其它文章中讨论过我们在这个方向上的思路和方法[21];现在这篇文章则将焦点关注于虚拟机。
现在有一些方法用于构建能够在共享的机器上操控多个应用和服务器(//server:这里提到的server应该是大规模应用的意思,比如数据库服务器)的系统。也许最简单的方法就是部署一个或多个运行着标准操作系统(如Linux或者Windows)的主机,然后允许用户们安装文件和启动进程—应用间的保护是由传统的操作系统技术提供的(//这里提到的做法,就是类似并行机性质的,各个节点都是独立的主机,但是一个应用可以在多个节点上面并行执行)。实验显示:由于要针对各个脱节(//supposedly disjoint:逻辑上脱节,指的是应用不具有连贯性/兼容性,所以针对每个应用都要单独配置一次,如果能想办法将前后有关联的应用放在一起执行,可以大大减少相关的开销,如配置开销,通信开销等等)的应用进行复杂的配置,这些配置过程导致的交互行为会使系统管理任务迅速成为时间消耗巨大的任务。
更重要的是,这样的系统不能够充分地支持性能隔离;某个进程的调度优先级,存储要求,网络通信量和磁盘访问等等特征都会影响到其它进程的性能。如果是在资源供应充足而且用户群体是限定(Lab平台实验)的情况下,这个系统还是可以接受的。但是当资源是供不应求的时候,或者用户间不相协作(//uncooperative:不相协作,比如用户间的需求有冲突,那么一定会互相影响的)的时候就不行了。一个解决这个问题的方法是改进对操作系统性能隔离的支持。这已经在resource containers,Linux/RK,QLinux和SILK中被或多或少地实现了。这些方法中存在着一个难点是难以确保所有的资源都能够正确地分配给有相应资源需求的进程。例如,缓冲区cache或者存储页面的替换算法导致的在应用间的复杂的交互行为(//比如存储页面替换的时候,某个进程的页面替换序列会干扰到其它进程的,要免除这个影响就需要有复杂的机制用于进程间的协调)。这就是存在于操作系统中的
“QoS干扰问题(QoS crosstalk)”。在低层采用多路执行技术能够缓解这个问题带来的影响,这已经在Exokerne和Nemesis操作系统中得到证明。在这些操作系统中,任务间无意识的或者不受欢迎的交互行为被最小化了。
我们使用了同样的基本