CN103530170B - 在虚拟机环境中提供硬件虚拟化的系统和方法 - Google Patents

Abstract

用于在虚拟机环境中提供硬件虚拟化和资源管理的系统和方法。根据一个实施例，应用程序服务器环境包括计算机系统、应用程序服务器，和虚拟机（例如，Java虚拟机或JVM）。根据一个实施例，虚拟化层被设置在每一物理机处，包括用于在机器上划分多个虚拟机的管理程序。执行层运行单一的基于Java的应用程序，尽可能高效集中运行该应用程序。根据另一个实施例，该系统包括两个主要部件：第一，代替常用操作系统的低级执行环境；以及第二，高级资源代理，用于负责将各新的虚拟机分发给上述各层，并用于监控正在运行的虚拟机的当前资源的使用。

Description

在虚拟机环境中提供硬件虚拟化的系统和方法

本申请是申请日为2007年8月7日、发明名称为“在虚拟机环境中提供硬件虚拟化的系统和方法”的中国专利申请200780033514.5的分案申请。

版权声明

本专利文件公开的一部分包括受版权保护的内容。当专利文件或专利公开中的任意一个的复制出现在专利和商标局专利文件或记录中时，该版权所有者对此没有异议，而对于其他任何情况都保留全部版权。

优先权声明

本发明申请要求于2006年8月7日提交的美国申请号为60/821,673的临时专利申请“SYSTEM AND METHOD FOR PROVIDING HARDWARE VIRTUALIZATION IN A VIRTUALMACHINE ENVIRONMENT”、以及于2007年8月7日提交的美国申请号为11/835,307号专利申请“SYSTEM AND METHOD FOR PROVIDING HARDWARE VIRTUALIZATION IN A VIRTUAL MACHINEENVIRONMENT”的权益，通过引证将其结合于此。

技术领域

本发明大体涉及操作系统、应用程序服务器、和虚拟机，更具体地涉及用于在虚拟机环境中提供硬件虚拟化和资源管理的系统和方法。

背景技术

当今的许多任务关键商业应用程序已经被开发出来并被部署在基于Java的应用程序服务器（包括，例如，符合Java2企业版或J2EE规格的应用程序服务器）上。这些应用程序通常被部署在单售主RISC计算机和服务器上，以及其他昂贵的硬件平台上。由于缺乏竞争力，不认为易于得到且低成本的基于PC的服务器适于替代能以这些构造使用的高性能Java虚拟机（JVM）。最新的虚拟机环境，诸如BEA系统公司的JRockit产品，能够解决这个问题就在于可以优化这些虚拟机以用于使Java应用程序能够在低成本、基于标准的平台上以提高的可靠性和性能来运行的各种环境（包括基于PC的环境）。JRockit虚拟机是为功率需求服务器侧Java应用程序、提供较好性能、可管理性、和可靠性特别优良设计的虚拟机的一个实例。

然而，尽管当前虚拟机产品（product offering）善于提供软件虚拟化，但是，至今很少能够以低层硬件或操作系统水平支持虚拟化，或在虚拟机水平对资源进行管理，然而，仍然允许应用程序服务器控制或参与虚拟化进程。

发明内容

本文中公开了用于在虚拟机环境中提供硬化虚拟化和资源管理的系统和方法。根据实施例，包括计算机系统、应用程序服务器、及虚拟机（例如，Java虚拟机或JVM）的应用程序服务器环境被扩展为提供从应用程序服务器环境中的较高层到系统实际处理能力（power）的接口，从而可以以机器独立的方式来进行处理的分配。软件层被放置在虚拟机和提高虚拟化Java执行系统的效率的硬件之间。根据该实施例，该系统包括两个主要部件：第一，低级执行环境，其代替常用操作系统；以及第二，高级资源代理，用于负责将各新的虚拟机分发给上面的层，并用于监控正在运行的虚拟机的当前资源的使用。以此方式，低层物理机可以被划分来支持多个JVM。此外，关于CPU和其他资源分配，可以在系统内部设置目标，并且该系统可以适当地分配多个JVM。

附图说明

图1示出了根据本发明一个实施例的包括虚拟机的应用程序服务器环境的示例。

图2示出了根据本发明一个实施例的分层虚拟机构造的示例。

图3示出了根据本发明一个实施例的多层域环境的示例。

图4示出了根据本发明一个实施例的可以如何将虚拟层用于共用计算环境中的示例。

图5示出了根据本发明一个实施例的连同资源代理的裸机（bare metal）域的示例。

图6示出了根据本发明一个实施例的连同JVM代理服务器的裸机域的示例。

图7示出了根据本发明一个实施例的虚拟机环境部件的逻辑图。

图8示出了根据本发明一个实施例的用于使用虚拟化的方法的流程图。

具体实施方式

本文中公开了用于在虚拟机环境中提供硬件虚拟化和资源管理的系统和方法。根据实施例，包括计算机系统、应用程序服务器、及虚拟机（例如，Java虚拟机或JVM）的应用程序服务器环境被扩展为提供从应用程序服务器环境中的较高层到系统实际处理能力的接口，从而可以以机器独立的方式来进行进程的分配。软件层被放置在虚拟机和提高虚拟化Java执行系统的效率的硬件之间。根据该实施例，该系统包括两个主要部件：第一，低级执行环境，其代替常用操作系统；以及第二，高级资源代理，用于负责将各新的虚拟机分发给上面的层，并用于监控正在运行的虚拟机的当前资源的使用。以此方式，低层物理机可以被划分来支持多个JVM。此外，关于CPU和其他资源分配，可以在系统内部设置目标，并且该系统可以适当地分配多个JVM。

术语

本文中使用了下列术语。

域：运行在管理程序层顶部的操作系统实例。多个域可以彼此不知道地运行在同一机器上。域在本文中还可以称作客户操作系统（OS）、客户（guest）、或VM。

裸机域：根据本发明一个实施例的运行虚拟层、虚拟机和应用程序的域。（例如，在一个实施例中，裸机域包括裸机操作系统（OS）层加诸如JRockit JVM的JVM，加应用程序）。裸机域在本文中还可以称作BM域。

节点：网络中的物理机或物理计算机。

网格计算：一组一起工作一解决一个计算问题的多个节点。

共用计算：允许多个应用程序在多个物理机上有效运行的系统或环境。共用计算环境允许对各应用程序指定高级策略以帮助系统决定将哪个（些）特定应用程序列入优先地位。共用计算环境还允许用户为系统部署新的应用程序；为每个应用程序提供高级策略和/或保证；监控应用程序和机器的状态；处理指定应用程序的资源使用的快速增长；供应系统升级；以及提供高可用性。

图1示出了包括虚拟机的且可以以本发明一个实施例的方式来使用应用程序服务器环境的示例。如图1所示，应用程序服务器环境10包括应用程序服务器14（例如，由BEA系统公司开发的WebLogic服务器产品，或其他类型的应用程序服务器），以及虚拟机16（例如，还是由BEA系统公司开发的JRockit JVM，或其他类型的虚拟机）。图1还示出了常用在应用程序服务器环境中的可选部件，例如，开发环境18、用户集成部件20、或线程集成部件22。后面这些可选部件分别包括WebLogic Workshop、WebLogic Portal、和WebLogic集成部件，其中的每一个都是由BEA系统公司开发的。需要的话，还可以将其他部件添加至该环境。

图2示出了根据本发明一个实施例的虚拟机构造的更详细的示例。如图2所示，诸如JRockit JVM的典型的虚拟机16包括用于管理系统中运行的线程的线程管理部件；用于管理诸如垃圾收集的过程的存储管理部件18；代码生成部件22；以及Java模型部件24。典型的虚拟机还提供外部接口28用于对虚拟机进行管理。尽管图2示出了JRockit产品，但是很显然，在本发明的精神和范围内，还可以使用除了JRockit实现以外的其他虚拟机。

为了能够有效的进行应用程序虚拟化，就需要相应的有效硬件资源虚拟化。这使得提供诸如挂起、动态配置（live provisioning）、和动态迁移的功能是可能的。根据本发明的一个实施例，添加了抽象的额外层。这使得虚拟机被移动至相对更接近下层硬件。

图3示出了根据本发明一个实施例的多层域环境的示例。如图3所示，计算环境30包括物理计算机硬件或计算机32。该计算机可以是物理服务器、计算机、网络设备、或等同类型的计算或处理设备。计算环境包括代替典型的操作系统而在逻辑上位于处理设备顶部的虚拟化层34。根据一个实施例，虚拟化层包括执行层部件38（本文中也称作“裸机层”），和管理程序层部件40或管理程序层。当前可得到的管理程序层部件的实例包括Xen管理程序和VMWare管理程序。根据其他的实施例，还可以使用其他的管理程序层和管理程序层部件。

管理程序层插入在服务器的硬件和操作系统之间。这提供了允许每个物理服务器运行一个或多个虚拟服务器的抽象层，并有效地将操作系统及其应用程序与下层物理服务器分离。一旦已经创建了虚拟服务器镜像，其就可以运行在任意服务器上。基于同样的原理，多个虚拟服务器可以同时共享单个物理服务器或机器。实际结果是增加了整个服务器的利用，而同时满足了接收确保任何特定应用程序层性能标准的资源保证。

如进一步在图3中示出的，虚拟机16在逻辑上位于虚拟化层之上。根据一个实施例，然后在虚拟机之上的层处提供资源代理36、或一组资源代理服务模块。资源代理由应用程序服务器14和其他应用程序使用，以使用由虚拟化层提供的服务。

在一些实施例中，通过为局域网中Java应用程序提供硬件虚拟化服务可以将上述系统用作整个共用计算环境的一部分。当用在共用计算环境的上下文中时，可以提供允许网络应用程序与虚拟机连接的服务。在共用计算或多虚拟机环境中，可以提供的服务的实例包括：在网络环境中某处创建新的虚拟机或JVM的能力；资源保证，诸如最小和最大CPU、内存、或网络带宽使用；资源计量和系统温度调节装置功能；当应用程序需要更多或更少这些资源时，动态增加或减少资源的能力；诸如挂起至磁盘或从磁盘重新开始运行的应用程序（本文中称作“冻干”）的特征；克隆“冻干”应用程序的能力（类似于Unix fork-like功能，即，以新的例程特定值来例示克隆的应用程序；以及将运行的例程移动至另一计算机以进行计划的系统维护的能力。

图4示出了在共用计算环境50中可以如何使用虚拟化层的实施例的示例。如图4所示，应用程序可以使用应用程序虚拟化特征52（包括，例如，上述的资源代理服务模块或共用计算服务）来经由应用程序服务器云56来访问下层硬件虚拟化层54。根据一个实施例，应用程序服务器可以是WebLogic服务器环境，其还可以提供其他高级的服务器特征（诸如企业群集）。

图5示出了根据本发明一个实施例的连同资源代理的裸机域的示例。根据一个实施例，资源代理向应用程序服务器和在其上运行的其他软件应用程序提供子服务。这些子服务可以包括例如：获得新的JVM；提供运行在服务器上的JVM；计量特定JVM的资源；以及控制JVM的资源。根据一个实施例，用于JVM创建的主部件是资源代理68（如上所述），在该示例中，资源代理跟踪机器60、62中的哪一个可用于在其上创建新的虚拟化层例程。根据一个实施例，资源代理经纪（resource broker agent，简称RBA）64、66位于每个机器上。根据其他实施例，不需要物理机和经纪之间的任何一对一的映射，例如，单一的经纪可以覆盖多个物理机。资源代理经纪负责JVM例程70、72、74的局部创建，即，作为经纪来创建和管理同一物理机上的JVM的操作。从第一机器到第二机器或整个群集的所有外部通信首先经过资源代理，然后向相应的资源代理经纪发送请求。在此方式中，资源代理就像一个经纪池，并跟踪哪个特定经纪控制哪个特定机器，而该特定机器还具有完成来自应用程序请求的必需的可用功率。

根据一个实施例，资源代理是通用硬件抽象层。其可以以大量不同机器类型来使用。如果机器类型支持划分，则资源代理可以在需要时使用该功能来划分该机器。根据特定机器类型支持哪种特征，可以得到不同的高端功能。至少该功能应该允许以接近的资源使用目标（例如至少受限保证，受限共享和非迁移）在机器上创建新的JVM。

应该注意，尽管当将资源代理与执行层组合会使系统运行的更好，并且还将支持更大的特征范围，但是对于资源代理本身来讲，其自身不需要执行层（即，裸机层）来执行其多种操作。

应该注意，标准机，即，非虚拟机还可以被添加至资源代理，即使在这些情况下功能会减少。根据其他实施例，资源代理还可以包括对诸如Azul、Solaris Containers和其他管理程序堆栈的第三方系统的支撑。根据一个实施例，Xen域和VMWare客户也能够支持原裸机资源保证、资源共享、挂起、迁移、可热插拔、和虚拟文件系统。

JMV代理

图6示出了根据本发明一个实施例的连同可选JVM代理的裸机域的示例。如上所述，在一些实施例中，资源代理服务模块可以用作独立实体。然而，在这些实例中，不会获得与通过所有元件的组合提供的相同的资源共享和相同的资源保证。如图6所示，物理服务器机80可以在其上运行多个JVM。在一些实例中，由标准操作系统（OS）90来操纵JNI代码执行和实体设备驱动器访问。当运行在管理程序层96顶部时，建立执行层92、94以优化在其上运行的任一JVM86、88的执行。具体地，管理程序层/执行层组合支持数据的隔离和写时复制共享以减小运行在同一物理机上的多个JVM的足印。根据一个实施例，OS层上的JVM代理82、82被提供来允许经由OS调用执行层中的功能和服务。根据其他实施例，可以使用裸机执行层而无需JVM代理。

性能监控框架-CPU能力和CPU共享

如上所述，该系统的有用特征之一是响应于应用程序请求来分配可用资源的可靠性。根据一个实施例，CPU能力是应用程序消耗了或保证具有多少CPU时间的近似。该信息然后被用于在可用机器或其他物理硬件上分配JVM。根据一个实施例，所有测量结果的单位都被认为是估计值。这些测量结果然后被用作相对测量结果（即，200CPU能力单位约为100CPU能力单位计算能力的两倍）。对于一个物理机可以产生的单位的数量来说，通常是当前使用的所有虚拟机的确切总数加上空闲单位。在一个特定机器上，相对测量结果可能会比如果考虑通过若干不同机器工作地更好并且更有意义。具体地，两个机器越是不同就越不可能会有精确的相对测量结果。目标通常在于CPU能力应该可比得上不同机器间的最远扩展可能。

系统接口和功能

表1列出了根据一个实施例的由系统提供的一些接口和功能。这些功能允许高层应用程序创建JVM以及在若干个机器（包括在集群内）上分配资源。很显然，在其他实施例中，还可以提供其他的接口和功能。

根据一个实施例，系统可以请求和测量四种类型资源中的任一个或全部，然后其可以使用这些资源来将这些资源分配到合适的JVM上。这些可以包括：CPU能力测量（如上所述）；Java堆内存；网络带宽；以及磁盘I/O。其他的实施例可以提供其他类型的资源测量选项。

当请求CPU能力时，上面的层都可以设置最小量（即，必须保证可用的量）和权重。对于其他三种资源类型只能被指定最小量。基于权重所指导的先来先服务，可能提供过量。该设计选择根本上简化了优化空间，并使得服务器的布置更简单。该方法的根本原因是因为大多数的应用程序倾向于受处理限制或受内存限制（即，受内存限制如同在等待加载，不是如同需要更多的内存）。

根据一个实施例，内存堆被设计为在应用程序的需要进行请求时可展开，因此，通常不应指定最大堆尺寸。只有在系统在地址空间（其可以是完全不固定的）不足或物理内存不足时才发生内存不足错误（这可以通过移动至具有更多内存的逻辑单元、将同一机器上的VM移动至另一机器、或通过减少由其他VM使用的内存来解决）。

使用管理程序的好处

使用管理程序的好处典型地包括，管理程序在隔离方面做得很好，而操作系统（OS）进程在这方面做得不好。尤其是在进程水平难以保证对CPU最小量的要求。诸如节省系统的全部状态的挂起和重新开始的特征在OS层上的任意层也是很难的。问题在于其是具有系统状态的全部信息的仅有的层（例如，JVM可以能够跟踪打开的文件、映射的内存、原生代码中的线程等，但是在重新开始时JVM完全恢复状态是不可能的。动态迁移特征更简单：由于管理程序对硬件进行抽象，因此系统具有将运行着的系统迁移至另一逻辑单元的能力。通过JVM层之间的合作，穿过OS层到达管理程序层，这可以更有效地执行。使用管理程序还可以保证例如，可以使系统可用一定量的CPU时间，并且系统可以计量每个容器（container）正在使用多少CPU时间。

使用特定OS层的好处

在一些实施例中，使用了特殊的操作系统（OS）层。可以在许多个级（应用程序、应用程序服务器、JVM、OS）处进行内存共享。但是许多类型的共享在堆栈的某些层处执行得更有效。具体的，来自JVM和管理程序的组合支持的组合允许系统在不同JVM之间以反向叉（inverse-fork-like）方式共享内存。这意味着系统可以“在事实过后（after the fact）”告诉管理程序在不同的JVM之间一些页是相同的。管理程序于是可以以写时复制策略让这些页映射到相同的物理页。

此外，特殊的OS层使得能够执行之前不可能的一些功能，例如：OS将只处理一个进程，即运行应用程序的JVM；以及OS理解JVM并且在JVM和使得能够进行有效优化的OS之间进行精确的合作/通信。一些特征在没有OS级支持的情况下是不可能的，例如：

●在垃圾收集器在那些区中压缩时，通过使增变线程的一些页不能运行的无休止压缩；

●代替在时钟日程上旋转的精确的线程日程，该线程保持时钟。

特殊的OS层还通过OS层去除来产生一些有效性。去除OS层导致较少的暂停次数，在高连接过程期间较好的运行和低内存。

添加管理程序添加了额外的抽象级，还自然地使系统慢下来。通过去除操作系统，系统可以补偿该降慢并且可能会通过其来进行提高。通过使用管理程序以及具有作为客户OS之一安装的一般的操作系统，裸机可以避免为不同的设备写设备驱动器，并且其只是通过管理程序告诉具有操作系统的客户OS上的设备驱动程序的简单的裸机。

系统设计

根据一个实施例，系统包括资源管理服务，该服务包括作为其主要接口的Java接口。该接口的用户可以包括应用程序服务器、应用程序、和企业范围（enterprise-wide）应用程序（例如，群集应用程序）。一个实施例的实际Java API如附件A所示。

图7示出了根据本发明一个实施例的虚拟机环境部件的逻辑示意图100。虚拟化层理想地是尽可能的小。如图7所示，根据一个实施例，这减小至管理程序（例如，Xen或VMWare，或其他管理程序）的薄层、操作环境（例如，裸机执行层）的薄层、以及执行引擎（例如，JRockit或另一JVM）的fatter blob，所有的这些都运行非常大的应用程序（例如，WebLogic服务器或另一应用程序服务器、加上客户应用程序）。

在一些实施例中，假设了准虚拟化管理程序（即，在OS和管理程序之间存在合作，OS是知道管理程序的），则假设建立了OS层；然而，其他实施例可以使用合作的OS和管理程序。

图8示出了根据本发明一个实施例的使用虚拟化的方法的流程图。如图8所示，在步骤120中，系统接收来自应用程序（例如，应用程序服务器，或在应用程序服务器上运行的客户应用程序）访问资源的请求，该请求必须由JVM提供。在步骤122中，资源代理基于例如可用性或当前负载来确定哪个机器出的哪个资源代理经纪最适于处理该请求。在步骤124中，资源代理经纪使用虚拟化层创建或管理在该机器上运行的JVM，其中，虚拟化层包括执行层和管理程序。

附件A

下列代码限定了以本发明一个实施例使用的实际Java API。显而易见地是，在本发明精神和范围内的其他实施例中可以限定其他API。

本发明可以使用根据本公开的教导的传统的通用或特殊数字计算机或微处理器。对软件领域中的技术人员显而易见的是，可以基于本公开的教导通过本领域的编程员来容易地准备适当的软件编码。

在一些实施例中，本发明包括计算机程序产品，该产品是包括其上存储的指令的存储介质（媒介），其中，指令可以用于对计算机进行编程来执行本发明的任意进程。存储介质可以包括但不限于任何类型的磁盘，磁盘包括软盘、光盘、DVD、CD-ROM、微小驱动器、和磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存设备、磁或光卡、纳系统（包括分子存储IC），或适于存储指令和/或数据的任何类型的介质或设备。

为了示例和说明的目的，已经提供了本发明的前述描述。并不是用于穷尽或将本发明限制于披露的精确形式。许多改进和变化对于本领域的技术人员来说是显而易见的。特别是，当在WebLogic应用程序服务器和JRockit产品的上下文中描述上述系统和方法的实施例时，很显然，可以以其他类型的应用程序服务器、JVM和虚拟机产品来使用这些系统和方法。类似的，当在Xen管理程序的上下文中描述上述实施例时，还可以使用其他类型的管理程序。选择并描述这些实施例是为了最好的说明本发明的原理及其实际应用，从而使得本领域的其他技术人员能够从各实施例以及通过适于预期使用的各改进来理解本发明。本发明的范围由所附的权利要求及其等同物限定。

Claims (8)

1.一种用于在虚拟机环境中提供硬件虚拟化的系统，包括：

计算机集群，包括多个计算机，每个计算机与资源代理经纪和虚拟化层相关联，其中，所述虚拟化层在逻辑上位于该计算机的顶部并且包括用于在该计算机上划分一个或多个虚拟机的管理程序；以及

逻辑上位于所述虚拟化层之上的资源代理，其跟踪每个资源代理经纪控制的一个或多个特定的计算机；

其中，资源代理被配置为

接收来自应用程序的访问由所述多个计算机之一提供的资源的请求，

确定哪一个资源代理经纪最适于处理所述请求，以及

将所述请求传送至所确定的资源代理经纪，

其中，所确定的资源代理经纪使用在相关联的计算机上的虚拟化层来创建新的虚拟机或分配现有的虚拟机来处理所述请求。

2.根据权利要求1所述的系统，其中，所述虚拟化层和所述资源代理根据对作出所述请求的应用程序的预定资源保证来分配请求。

3.根据权利要求1所述的系统，其中，所述管理程序是Xen管理程序。

4.根据权利要求1所述的系统，所述管理程序是VMware管理程序。

5.根据权利要求1所述的系统，

其中所述一个或多个虚拟机包括一个或者多个Java虚拟机(JVM)，

其中所述虚拟化层包括多个执行层部件，

其中每个JVM与其自己的执行层部件相关联，并且

其中每个执行层部件适于运行基于Java的应用。

6.一种用于在虚拟机环境中提供硬件虚拟化的方法，包括以下步骤：

接收来自应用程序的访问由多个计算机之一提供的资源的请求，每个计算机与资源代理经纪和虚拟化层相关联，其中所述虚拟化层在逻辑上位于该计算机的顶部并且包括用于在该计算机上划分一个或多个虚拟机的管理程序；

由逻辑上位于所述虚拟化层之上的资源代理确定哪一个资源代理经纪最适于处理所述请求；以及

使用虚拟化层传送所述请求至所确定的资源代理经纪；以及

在所确定的资源代理经纪处使用相关联的计算机上的虚拟化层来创建新的虚拟机或分配现有的虚拟机来处理所述请求。

7.根据权利要求6所述的方法，其中，所述虚拟化层和所述资源代理根据对作出所述请求的应用程序的预定资源保证来分配请求。

8.根据权利要求6所述的方法，

其中所述一个或多个虚拟机包括一个或者多个Java虚拟机(JVM)，

其中每个JVM与其自己的执行层部件相关联，并且

其中每个执行层部件适于运行基于Java的应用。