CN112236752A - 用于改进软件容器性能和隔离的方法和系统 - Google Patents

Abstract

在一个实施例中，一种方法包含：实现基于内核的隔离层，在基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核，以及在软件容器中执行一个或多个用户进程。该方法由基于云的处理平台、企业处理平台或包含多个处理设备的其他类型的处理平台执行，其中每个这样的处理设备包含耦合到存储器的处理器。库操作系统例示性地以与在软件容器中执行的一个或多个用户进程的特权级别相同的特权级别在软件容器中运行。库操作系统被例示性地配置为结合将系统调用转换为相对应的函数调用来支持一个或多个用户进程的二进制的自动翻译。

Description

用于改进软件容器性能和隔离的方法和系统

优先权声明

本申请要求2018年4月11日提交的题为“用于改进软件容器性能和隔离的方法和系统(Method and System for Improving Software Container Performance andIsolation)”的序列号为62/656,051的美国临时专利申请的优先权，其全部内容通过引用并入本文。

政府支持声明

本发明是在国家科学基金会(NSF)授予的合同号：CSR-1422544、CNS-1601879、CSR-1704742、1053757和0424422；由国家标准与技术研究院(NIST)授予的合同号：60NANB15D327和70NANB17H181；以及由国防高级研究计划局(DARPA)授予的合同号：FA8750-10-2-0238、FA8750-11-2-0256和D11AP00266下在政府支持下完成的。政府在本发明中拥有某些权利。

技术领域

本领域通常涉及信息处理系统，并且更具体地，涉及在这种系统中使用的软件容器。

背景技术

容器已经成为打包应用的优选方法，并且是无服务器架构和许多其他类型的处理平台中的关键组件。同时，随着管理程序充当外内核以及许多库操作系统(OS)被提供或正在开发中，外内核架构正获得越来越多的关注。外内核由于其较小的可信计算基(TCB)和攻击面而具有优越的安全隔离特性，而库OS可以针对特定的应用进行定制。不幸的是，这两种趋势目前彼此不兼容。当前的库OS缺乏运行现代应用容器所需要的二进制兼容性以及对多个进程的支持。

发明内容

例示性实施例提供了改进的软件容器，在本文中被称为X-容器。在一个或多个实施例中的X-容器架构中，X-容器与作为库OS的专用Linux内核一起在X-内核上运行，例示性地使用虚拟机管理程序和主机操作系统中的一个来实现。X-内核是在本文中更一般地被称为“基于内核的隔离层”的示例。所得的X-容器布置例示性地支持未修改的多处理应用，并自动动态地优化应用二进制替换。在一些实施例中，与未修改的Linux相比，这种类型的X-容器有利地提供了在系统调用开销方面的大幅度减少，同时在网络基准测试上也显著优于库OS(像Unikernel和Graphene)。

在一个实施例中，一种方法包含：实现基于内核的隔离层，在基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核，以及在软件容器中执行一个或多个用户进程。该方法由基于云的处理平台、企业处理平台或包含多个处理设备的其他类型的处理平台执行，其中每个这样的处理设备包含耦合到存储器的处理器。

库操作系统例示性地以与在软件容器中执行的一个或多个用户进程的特权级别相同的特权级别在软件容器中运行。

在一些实施例中，库操作系统被例示性地配置为结合将系统调用转换为相对应的函数调用来支持一个或多个用户进程的二进制的自动翻译。

本发明的这些和其他例示性实施例包括但不限于系统、方法、装置、处理设备、集成电路以及计算机程序产品，该计算机程序产品包含其中包含软件程序代码的处理器可读存储介质。

附图说明

图1示出了例示性实施例中的包含实现X-容器的基于云的处理平台的信息处理系统。

图2示出了例示性实施例中的包含实现X-容器的企业处理平台的信息处理系统。

图3示出了例示性实施例中的X-容器的示例布置。

图4示出了包括如本文所公开的利用X-容器的架构的各种架构中的隔离边界。

图5示出了例示性实施例中的使用不同数量的X-容器的两个应用的替代性配置。

图6示出了例示性实施例中的在一个或多个X-容器中实现的二进制替换的示例。

图7示出了在例示性实施例的评估中使用的软件栈的示例。

图8至图12是示出在例示性实施例上执行的评估的结果的图。

具体实施方式

本发明的实施例可以例如以信息处理系统的形式实现，该信息处理系统包含计算机网络或网络、客户端、服务器、处理设备和其他组件的其他布置。本文将详细描述这种系统的例示性实施例。然而，应当理解的是，本发明的实施例更普遍地适用于多种其他类型的信息处理系统和相关联的网络、客户端、服务器、处理设备或其他组件。因此，如本文所用的术语“信息处理系统”旨在被广义地解释为涵盖这些布置和其他布置。

图1示出了例示性实施例中的实现X-容器的信息处理系统100。系统100包含多个用户设备102-1、102-2、……、102-N。用户设备102被配置为通过网络105与基于云的处理平台104进行通信。

用户设备102中的一个或多个可以各自包含例如膝上型计算机、平板计算机或台式个人计算机、移动电话或另一类型的计算机或通信设备，以及多个这样的设备的组合。在一些实施例中，用户设备102中的一个或多个可以包含相应的计算节点，这些计算节点例示性地在一个或多个处理平台(可能地可能包括基于云的处理平台104)上实现。

假设系统100的各个元件之间的通信发生在图中由网络105共同表示的一个或多个网络上。网络105可以例示性地包括例如全球计算机网络(诸如互联网)、广域网(WAN)、局域网(LAN)、卫星网络、电话或电缆网络、蜂窝网络、使用无线协议(诸如WiFi或WiMAX)实现的无线网络、或者这些和其他类型的通信网络的各个部分或组合。

基于云的处理平台104是在本文中更一般地被称为“处理平台”的示例，该处理平台包含多个处理设备，每个处理设备包含耦合到存储器的处理器。处理设备中的一个或多个可以各自包括多个处理器和/或多个存储器。

处理平台的给定的这种处理设备的处理器可以以任何组合包含例如微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、中央处理单元(CPU)、算术逻辑单元(ALU)、图形处理单元(GPU)、数字信号处理器(DSP)或其他类似的处理设备组件，以及其他类型和布置的处理电路系统。

处理平台的给定的这种处理设备的存储器可以以任何组合包含例如电子存储器(诸如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)或其他类型的RAM)、只读存储器(ROM)、闪存或其他类型的非易失性存储器、磁存储器、光存储器或其他类型的存储设备。

存储器例示性地存储程序代码以便由进程执行。这种存储器是在本文中更一般地被称为其中包含程序代码的“处理器可读存储介质”的示例。

包含这种处理器可读存储介质的制品被认为是本发明的实施例。如本文所用的术语“制品”应该理解为排除暂时的、传播的信号。

在其他实施例中，可以实现包含处理器可读存储介质的其他类型的计算机程序产品。

此外，本发明的实施例可以以集成电路的形式实现，该集成电路包含处理电路系统，该处理电路系统被配置为实现与实现如本文所公开的X-容器相关联的处理操作。

基于云的处理平台104或本文公开的其他处理平台的给定的处理设备通常将包括除了上述处理器和存储器之外的其他组件。例如，给定的处理设备例示性地包括网络接口，该网络接口被配置为允许处理设备通过网络105与其他系统元件通信。这种网络接口例示性地包含一个或多个常规收发器。

本实施例中的基于云的处理平台104更具体地利用运行在物理基础设施114上的虚拟化基础设施112来实现多个X-容器110。物理基础设施114例示性地包含多个上述类型的处理设备，每个处理设备包含至少一个处理器和至少一个存储器。例如，在一些实施例中，物理基础设施包含裸机主机或其他类型的计算机或服务器。一些实施例中的虚拟化基础设施112包含虚拟机管理程序，尽管实现X-容器110不需要管理程序。因此，在其他实施例中，虚拟化基础设施112可以被消除。

图2的信息处理系统200代表一个可能的替代性实施例，其不包括虚拟化基础设施(诸如虚拟化基础设施112)。在系统200中，企业处理平台204直接在物理基础设施214上实现多个X-容器210，消除了X-容器210和底层物理基础设施214之间的任何管理程序或其他虚拟化基础设施，后者例示性地被实现为裸机主机或其他类型的计算机或服务器。系统200的其他元件通常在其他方面与前面结合图1的系统100描述的那些元件相同。

应当理解的是，分别在图1和图2中示出的系统100和200的特定布置仅通过例示性示例的方式呈现，并且许多其他布置是可能的。

例如，尽管这些实施例在相应的基于云的和企业处理平台中实现X-容器，但是可以使用多种附加的或替代性处理平台，诸如物联网(IoT)平台和网络功能虚拟化(NFV)平台。

其他示例包括根据平台即服务(PaaS)模型、软件即服务(SaaS)模型、基础设施即服务(IaaS)模型和/或功能即服务(FaaS)模型实现的平台，以及企业应用容器平台、无服务器计算平台、微服务平台和基于云的本地应用平台，以及其他通用云计算或企业计算基础设施。更一般而言，X-容器可以在可受益于其安全性和性能优势的任何平台上实现。

在实现X-容器110或210时，系统100或200被例示性地配置为实现在本文中被称为“基于内核的隔离层”的内容。X-容器110或210中给定的一个被例示性配置为基于内核的隔离层上的软件容器。给定的X-容器包括作为库操作系统的专用操作系统内核，并且一个或多个用户进程在给定的X-容器中执行。在一些实施例中，基于内核的隔离层更具体地相对于X-容器的专用操作系统内核以X-内核的形式实现。X-内核可以更具体地包含虚拟机管理程序或主机操作系统的至少一部分。在其他实施例中，可以使用其他类型的基于内核的隔离层。

图3示出了信息处理系统300的一部分，其包含例示性实施例中的X-容器310的示例布置。在这个示例中，X-容器310更具体地包含第一X-容器310-1、第二X-容器310-2和第三X-容器310-3，所有这些容器在X-内核312上实现。

如上所述，在一些实施例中，X-内核可以包含虚拟机管理程序(例如，Xen)。例如，这种类型的给定的实施例中的X-内核312可以使用图1的虚拟化基础设施112的一个或多个虚拟机管理程序来实现。虚拟机在本文中也被称为各个VM。

在其他实施例中，X-内核312可以包含主机操作系统的至少一部分。例如，在这种类型的实施例中，可以使用Linux内核或Windows OS内核来实现X-内核。这样的实施例例示性地直接在图2的物理基础设施214上运行。

仅通过示例的方式，第一X-容器310-1包含单个用户进程，第二X-容器310-2包含两个用户进程，并且第三X-容器310-3包含三个用户进程。可以使用不同数量和布置的X-容器及其相应的相关联进程(或多个相关联进程)。

图3实施例中的X-容器310中的每个包含作为库操作系统(在图中表示为X-LibOS)的相对应的专用操作系统内核。X-LibOS例示性地是从指定类型的单一操作系统内核转换而来。X-LibOS以与在X-容器中执行的一个或多个用户进程的特权级别相同的特权级别在X-容器中运行。X-LibOS被例示性地配置为结合将系统调用转换为相对应的函数调用来支持一个或多个用户进程的二进制的自动翻译，如将在本文别处更详细描述的那样。

如上所述，X-内核312上的X-容器310中的每个包括单独的专用操作系统内核作为其相对应的X-LibOS实例。不同组的一个或多个用户进程在X-容器310中的相应X-容器中使用它们相应的X-LibOS实例来执行。因此，在X-容器310中的任何一个中执行的用户进程与在X-容器310中的其他X-容器中的每个中执行的用户进程安全地隔离。

相应的X-容器310的X-内核312和X-LibOS实例不需要全部利用相同类型的操作系统。例如，X-内核312和X-LibOS实例中的给定的一个可以使用不同类型的相应的第一操作系统和第二操作系统来实现。

在一些实施例中，在X-内核312上配置X-容器310中的给定的一个以包括作为其X-LibOS实例的专用操作系统内核进一步包含提取现有软件容器的容器映像，以及在X-内核312上配置X-容器时利用所提取的容器映像作为虚拟机映像。在这种类型的布置中，X-内核312上的X-容器可以包含现有软件容器的包装版本。在这样的实施例中，现有软件容器的一个或多个用户进程被例示性地允许作为X-内核312上的给定的X-容器中的一个或多个用户进程执行，而不需要对那些一个或多个用户进程进行任何修改。

不同类型的X-容器310可以在不同的实施例中实现。例如，在一些实施例中，X-容器310被实现为在本文中被称为半虚拟化的X-容器或PV X-容器的内容，其中库操作系统和一个或多个用户进程以用户模式运行。这种类型的一些实施例例示性地将X-内核312实现为其他的标准虚拟机管理程序或操作系统内核的修改版本。

作为另一示例，在其他实施例中，X-容器被实现为在本文中被称为硬件辅助的虚拟化X-容器或HV X-容器的内容，其中库操作系统和一个或多个用户进程在硬件辅助的虚拟机内以内核模式运行。这种类型的一些实施例将X-内核312实现为标准虚拟机管理程序或操作系统内核。在这种类型的其他实施例中，也可能对虚拟机管理程序或操作系统进行一些修改。

图3中示出的示例X-容器架构为软件容器提供了改进的性能和隔离。在一些实施例中，X-容器架构将传统的单一操作系统内核(诸如Linux内核)转变为X-LibOS实例，该实例以与X-容器中的一个或多个用户进程相同的特权级别运行。不同X-容器的隔离由最小可信计算基和内核攻击面保护。

与传统的容器实施方式不同，X-容器隔离对最近发现的影响过去20年中制造的大多数英特尔处理器的熔毁CPU错误不敏感。例示性实施例可以用于减轻由这种漏洞和其他安全问题引起的容器隔离的问题。

在一些实施例中，X-容器被例示性地配置为自动将系统调用指令翻译成函数调用，这使得能够支持完全的二进制兼容性，因为在一些实施例中，现有容器可以在X-容器中运行，而无需任何修改。

与常规方法相比，X-容器表现出增强的隔离。例如，所公开的布置防止给定主机上的受损容器将同一主机上的其他容器置于危险之中。X-容器为现有应用提供安全的容器隔离，以及解决紧急容器安全问题(诸如上述的熔毁漏洞)的解决方案。

如上所述，在例示性实施例中，X-容器通过使用用于X-内核的虚拟机管理程序或操作系统内核(例如，充当所谓的“外内核”)来解决这些和其他问题。传统的单一操作系统内核(诸如Linux内核)被例示性地转换为库OS，并且它以相同的特权级别与一个或多个用户进程一起运行。

用户进程的二进制可以动态地被修补，以将系统调用转换为函数调用，以获得最佳性能和完全的二进制兼容性。

通过提取容器磁盘映像并将其用作虚拟机映像，可以将现有的Linux容器(例如，Docker、LXC)自动包装到X-容器中。

X-容器架构可以用于支持来自相互不信任的用户的程序的安全隔离和高效执行的公共容器云或无服务器计算平台，以及用于多种其他基于云的处理平台或企业处理平台。

如前所提及那样，在一些实施例中，X-内核和X-LibOS实例可以基于不同的操作系统类型来实现。例如，X-内核可以基于Xen实现，并且X-LibOS可以基于Linux内核实现。

在一些实施例中，X-容器架构利用被修改为充当高效LibOS的Linux内核，以便提供对现有应用和内核模块的完全兼容性，而管理程序或操作系统内核可以被用作外内核以运行和隔离X-容器。

每个X-容器例示性地托管应用，该应用具有基于Linux内核的专用且可能定制的LibOS。X-容器可以支持一个或多个用户进程，其中一个或多个用户进程以相同的特权级别与LibOS一起运行。为了资源管理和兼容性，不同的进程仍然具有它们自己的地址空间，但是它们不再提供彼此之间的安全隔离，因为进程用于并发性，而X-容器提供隔离。

X-容器架构在运行时期间自动优化应用的二进制，以通过将昂贵的系统调用重写为更便宜的函数调用、重写到LibOS中来改进性能。与本地Docker容器相比，X-容器具有高得多的原始系统调用吞吐量，并且对于其他基准测试而言，该X-容器与本地容器竞争或优于该本地容器。

X-容器架构也优于专用于容器和无服务器服务的架构。例如，我们已经在X-容器、Unikernel和Graphene上用NGINX运行了wrk网络基准测试。在该基准测试下，X-容器架构具有与Unikernel相当的性能，并且具有约为Graphene的两倍的吞吐量。然而，当运行PHP和MySQL时，X-容器架构表现出比Unikernel好得多的性能。

虽然在一些实施例中，X-容器架构利用了Linux的许多软件基础，但是设计和实施方式必须解决各种挑战。例示性实施例包括多个不同的示例设计。在第一示例设计中，我们在Xen之上以用户模式与用户进程一起运行Linux内核。这需要对Xen管理程序进行大量修改，但不需要特殊的硬件支持。事实上，这种设计可以在裸机上和公共云中的虚拟机内部两者运行。在第二示例设计中，我们以内核模式与利用硬件虚拟化支持的Linux内核一起运行用户进程。这种设计可以在任何管理程序上运行，并且仍然安全地隔离不同的容器。在这两种情况下，只有Linux的依赖于架构的部分需要修改。

在一些实施例中，X-容器架构包含基于外内核的容器架构，该架构与Linux容器兼容，并且提供了具有竞争性的或优于本地Docker容器以及其他LibOS设计的性能和隔离。而且，这种架构支持容器的安全隔离，而不牺牲兼容性、可移植性或性能。

如本文所公开的X-容器可以用于打包和分发软件组件，并作为无服务器和微服务架构中的基本构建块，从而提供诸如可移植性(因为开发人员可以在一个容器中装载应用及其所有依赖项，然后该容器可以在公共云以及私有云中的任何地方运行)以及性能(因为与虚拟机相比，容器可以在毫秒内被引导而具有可忽略的开销)之类的优点。在其他实施例中，X-容器支持多种其他用例。

从上述内容显而易见的是，在例示性实施例中，与常规方法相比，X-容器提供了显著的优势。例如，X-容器提供了基于库OS的新的安全模型，与常规方法相比具有显著改进的性能和隔离。我们支持共享相同库OS的多个进程，这是一大类容器的重要特征。利用我们的方法，我们将Linux内核本身转变为库OS，从而提供100％的兼容性。例示性实施例仅在我们第一次看到系统调用时重定向它们，并且然后将它们自动转换为函数调用以优化后续执行。例示性实施例允许运行现有的未修改的容器，同时也自动优化二进制以获得性能。而且，这种实施例具有显著减少的攻击面和TCB，并且因此安全得多。多种不同的实施方式是可能的，包括没有硬件虚拟化支持的实施例。

本文公开的这些和其他例示性实施例的上述各方面仅通过示例的方式呈现，并且不应被解释为以任何方式进行限制。

现在将参考图4至图12描述关于例示性实施例的操作的附加细节。

支持多个用户和进程的现代OS支持各种类型的隔离，包括内核隔离和进程隔离，该内核隔离确保进程不能损害内核的完整性，也不能读取被保持在内核中的机密信息，该进程隔离确保一个进程不能轻松访问或损害另一进程。

保护内核隔离的成本可能很高。用于访问内核代码的系统调用比到库中的函数调用慢几个数量级。而且，为了消除内核和用户模式代码之间的数据依赖性，通常在输入输出(I/O)堆栈中执行数据复制。同时，存在将越来越多的功能推入到OS内核中的趋势，并且抵御对内核的攻击变得越来越困难。现代单一OS内核(诸如Linux)已经成为具有复杂服务、设备驱动程序和系统调用接口的巨大代码库。验证如此复杂的系统的安全性是不切实际的，并且新的漏洞不断被发现。

进程隔离也类似地存在问题。首先，这种类型的隔离由于其实现和实施的方式通常依赖于内核隔离。但也许更重要的是，进程不仅仅是旨在用于安全隔离。它们主要用于资源共享和并发性支持，并且为了支持这一点，现代OS提供了跨越隔离的接口，包括共享内存、共享文件系统、信令、用户组和调试挂钩。这些机制暴露了较大的攻击面，这给依赖进程进行安全隔离的应用造成了许多漏洞。

例如，Apache网络服务器产生具有相同用户ID的子进程。通过利用调试接口(诸如ptrace)或proc文件系统，受损的进程可以轻松访问其他进程的内存。在没有小心配置的情况下，受损的进程还可能访问共享文件系统，并从配置文件或者甚至数据库中窃取信息。最后，存在特权升级攻击，其允许黑客获得根特权，以便在不损害内核的情况下击败大多数进程隔离机制。

事实上，很少有现有的多客户端应用依赖进程来隔离相互不信任的客户端，特别是，它们没有为每个客户端指定进程。很多甚至根本不使用进程。例如，流行的生产系统(诸如NGINX网络服务器、Apache Tomcat、MySQL和MongoDB)使用事件驱动模型或多线程来代替多处理。多进程应用(诸如Apache网络服务器)使用进程池来实现并发性，而不是安全性，使得每个进程具有多个线程，并且可以重复使用来服务不同的客户端。这些应用在应用逻辑中实现客户端隔离，利用诸如基于角色的访问控制、认证和加密等机制。

然而，存在例外。SSH守护进程依赖进程隔离来隔离不同的用户。而且，如果在同一内核上存在多个应用使用相同的MySQL守护进程，内置到MySQL中的进程隔离和客户端隔离的组合为应用提供了安全性，以防某些应用受损，因为每个应用对MySQL表现为不同的客户端。

本文公开的例示性实施例涉及重新思考隔离边界，如现在将参考图4进行描述的那样。

进程对于资源管理和并发性是有用的，但是理想情况下，安全隔离应该与进程模型脱离。事实上，已经引入了其他隔离机制。

图4示出了各种替代性架构中的隔离边界。容器隔离在内核之上分离命名空间，使得每个容器看起来都是该内核的自己的实例化。然而，所使用的技术本质上与进程隔离相同，因为可以用容器实现的任何隔离可以不用容器来实现。它没有解决内核是由于许多可用的系统调用而具有大的攻击面的较大且易受攻击的TCB的问题。

从安全角度来看，在各个虚拟机(VM)(每个虚拟机都有其自己的专用内核)中运行容器是可能的解决方案。TCB现在由具有小得多的攻击面的相对较小的管理程序组成。不幸的是，由于冗余资源消耗和隔离边界，开销很高。尽管如此，这现在是多租户容器云的实际解决方案。为了应对这种解决方案的高成本，更多的实验系统(诸如Unikernel、EbbRT、OSv和Dune)是被设计用于在VM内部运行的轻量级OS内核替代方案。不幸的是，由于缺乏二进制级兼容性，它们不能很好地支持现有应用。而且，通常它们只能支持单进程应用

在微内核架构中，大多数传统的OS服务与应用进程一起在单独的用户进程中运行。这种架构可以提供二进制兼容性。然而，由于不同的应用共享那些OS服务，受损的OS服务会破坏应用之间的隔离，使得不会减少TCB和攻击面。而且，系统调用开销往往很大。

本文的例示性实施例中的X-容器架构为应用之间的安全隔离提供了改进的范例。例如，在一些实施例中，架构基于外内核架构，具有较小的内核攻击面和较低的系统调用开销。单个X-容器可以有多个进程，例如用于资源管理和并发性，但是单个X-容器中的那些进程并不彼此隔离。相反，用户和/或应用通过为不同的用户和/或应用产生单独的X-容器而彼此隔离。消除X-容器内的隔离可以将系统调用开销降低到函数调用的开销。

如上所述，在例示性实施例中，X-容器使用基于具有完全二进制兼容性的标准OS内核的X-LibOS。在一些实施方式中，X-LibOS源自Linux，并且只需要对Linux的依赖于架构的部分进行更改。使用标准内核的优势很多。例如，Linux高度优化并且是成熟的，并且正在被活跃的社区开发。X-容器充分利用了这种优势，但依赖于小得多的X-内核进行隔离。在一些实施方式中，X-内核源自Xen。

如前所述，不同的应用应该放置在不同的X-容器中。图5在涉及各自使用MySQL数据库的两个应用的例示性实施例的上下文中示出了这一点。图5包括三个部分，表示为图5(a)、图5(b)和图5(c)。

一种选择是为每个应用创建X-容器，再加上专用于MySQL的第三X-容器，如图5(a)所示。也就是说，这个选择将MySQL视为它自己的隔离应用。MySQL内部含有访问控制逻辑，用于安全地分离两个应用的表。

更安全的配置将创建MySQL的两个实例，每个应用一个实例，每个实例在其自己的X-容器中运行，导致总共四个X-容器，如图5(b)所示。这将消除MySQL实施方式内对访问控制逻辑的依赖，并且因此严格提高配置的安全性。此外，这个选择将提供更好的可定制性，MySQL服务器和支持它们的操作系统内核两者都是如此。

然而，请注意图5(b)中的每个应用具有其自己的MySQL实例的方式。每个应用依赖其MySQL实例来持久存储其数据并正确响应查询，而相反，每个MySQL实例都是专用的，并且不会由于被其自己的应用损害而丢失任何东西。因此，我们可以安全地仅部署两个X-容器，每个容器都含有应用逻辑及其专用的MySQL实例，如图5(c)所示。这个选择提供了比图5(a)和图5(b)中分别示出的三个或四个X-容器配置好得多的性能。

对于在X-容器(或者一般意义上的容器)上运行的应用，我们可以考虑两种威胁：外部威胁和内部威胁，并且这些威胁可能相互串通。一种外部威胁是由被设计用于破坏应用逻辑的消息构成的。这种威胁可以被应用和操作系统逻辑抵御，并且对于标准容器和X-容器相同。另一种外部威胁可能试图突破容器的隔离屏障。在标准容器的情况下，这种隔离屏障由底层通用操作系统内核提供，该内核具有较大的TCB，并且由于大量的系统调用具有较大的攻击面。相比之下，在例示性实施例中，X-容器依赖于专用于提供隔离的相对较小的X-内核进行隔离。它具有较小的TCB和少量的相对容易保护的管理程序调用。我们认为，X-容器相比于标准容器提供对外部威胁的严格意义上更好的防护。

内部威胁是由依赖第三方库的应用形成的，或者如上面MySQL示例所示，是由部署在相同容器中的第三方服务形成的。在Linux容器中，应用信任Linux来实现不同用户帐户拥有的进程之间的隔离。X-容器显式地不在相同容器中的进程之间提供安全隔离。依赖进程之间的安全隔离屏障的应用应该使用标准的VM和Linux解决方案，或者重新组织应用使得冲突的进程在不同的X-容器中运行。后者将提供更好的安全性，但需要更多的实现工作量。

现在将描述X-容器的例示性实施例的附加设计和实现细节。

理想情况下，容器应该为运行应用提供安全且独立的环境。以下是设计用于安全运行应用容器的架构的关键原则：

1.自给自足性和可定制性：容器应该含有应用的所有依赖项。这不仅包括库、文件系统布局和第三方工具，而且包括OS内核。容器应该能够使用定制的OS内核，并加载其自己的内核模块。

2.兼容性：理想情况下，容器平台不应该要求对应用进行更改。二进制级兼容性允许用户立即部署容器，而无需重写或甚至重新编译他们的应用。

3.具有较小TCB的隔离：容器彼此应该被安全隔离。尽管共享特权软件来访问共享的物理资源是必要的，但是该软件必须是可信的，并且应该较小。

4.便携性：容器的关键优势是它们被一次性打包，并且然后可以在任何地方(包括裸机和虚拟化云环境)运行。

5.可扩展性和效率：应用容器应该是轻量级的，并且以较小的开销来执行。

在本文公开的X-容器的一些实施方式中，我们使用管理程序作为X-内核，并且我们将Linux内核分布修改为X-LibOS实例，该实例允许它以与应用相同的特权模式运行。我们更具体地描述以下两个示例实施方式：

1.半虚拟化(PV)的X-容器，其以用户模式运行X-LibOS和应用。这种实施方式例示性地需要修改管理程序(以内核模式运行)，但是它不需要特殊的硬件支持，并且可以被部署在裸机上以及部署在公共云中的VM中。

2.硬件辅助虚拟化(HV)的X-容器，其以内核模式运行X-LibOS和应用。这种实施方式例示性地需要硬件虚拟化支持，但是与未修改的管理程序一起工作。

对于上面的第一实施方式示例，我们已经将X-内核实施方式基于Xen。Xen是开源的，并且在Linux中对其半虚拟化接口的支持是成熟的。对于第二实施方式示例，我们使用具有硬件虚拟化的未修改的Xen作为X-内核，但是也可以使用其他管理程序。例如，我们已经在谷歌计算引擎的KVM上运行了HV X-容器。

两个实施方式示例提供了有利的特征。第一实施方式允许如何管理X-容器方面的更好的控制。例如，它允许在相同VM中安全地运行彼此隔离的多个X-容器。在单个高性能VM上运行多个X-容器将比在其自己的较小VM上运行每个X-容器表现得更好并且更具成本效益。而且，对于PV X-容器，支持Xen VM管理功能(诸如实时迁移、整合和内存扩大)作为附加好处；这些功能是在常规的Linux容器中得不到很好的支持的特征。

当硬件虚拟化可用时，第二实施方式往往具有更好的性能。但是，在虚拟化环境中，除非支持嵌套的硬件虚拟化，否则HV X-容器需要接管整个VM。公共云中的VM通常不会公开嵌套的硬件虚拟化。

对于本文描述的实验，我们从Linux内核4.4.44中导出了两个版本的X-LibOS。对内核的修改是在依赖于架构的层中进行的，并且对内核中的其他层是透明的。我们关注以x86-64长模式运行的应用。

使用Linux给了我们二进制兼容性，但是此外Linux内核也是高度可定制的。它具有数百个引导参数、数千个编译配置和许多细粒度的运行时调谐旋钮。由于大多数内核函数可以被配置为内核模块，并在运行时期间被加载，因此定制的Linux内核可以得到高度优化。例如，对于运行单线程的应用(诸如许多事件驱动的应用)，禁用多核和对称多处理(SMP)支持可以消除不必要的锁定和翻译旁视缓冲器(TLB)击落，这大大改进了性能。根据工作负载，应用可以使用不同的调度策略来配置Linux调度程序。对于许多应用来说，由于缺乏对内核配置的控制或不得不与其他应用共享内核，Linux内核的潜力没有得到充分开发。将Linux内核转变为LibOS，并将其专用于单个应用，可以释放所有这些潜力。

现在将更详细地描述上述PV X-容器的例示性实施例。我们实现了基于Xen半虚拟化(PV)架构的PV X-容器。PV架构使得能够在相同物理机上运行多个并发的Linux VM(例如PV访客或域-U)，而不支持硬件辅助的虚拟化，但是访客内核需要适度的更改才能与底层管理程序一起工作。在下文中，我们将回顾Xen的PV架构中的关键技术及其在x86-64平台上的局限性。

在PV架构中，Xen以最高特权的模式(内核模式)运行，并且访客内核和用户进程两者以较低的特权运行。可能影响安全隔离的所有敏感系统指令(诸如安装新的页表和更改段选择器)由Xen执行。访客内核通过执行超级调用来请求这些服务，这些服务在被服务之前由Xen验证。异常和中断通过高效的事件通道被虚拟化。

对于设备I/O，不是模拟硬件，而是Xen定义了更简单的分离驱动程序模型。存在访问硬件设备并多路复用设备以便其他域-U可以共享它的特权域(通常是域-0，即Xen在引导期间创建的主机域)。域-U安装了前端驱动程序，该前端驱动程序通过Xen的事件通道连接到域-0中相对应的后端驱动程序，并且使用共享内存(异步缓冲区描述符环)传输数据。

Xen的PV接口已经得到主流Linux内核的广泛支持，因为它是x86-32平台上最高效的虚拟化技术之一。因为内存分段保护有四种不同的特权级别(环-0到环-3)，所以我们可以在不同的特权级别上运行Xen、访客内核和用户进程以实现隔离。系统调用可以在没有Xen参与的情况下执行。然而，在x86-64平台上，PV架构面临着根本性的挑战。由于消除了x86-64长模式下的段保护，我们只能以用户模式运行访客内核和用户进程两者。为了保护访客内核不受用户进程的影响，访客内核需要被隔离在另一地址空间中。每个系统调用需要由Xen管理程序作为虚拟异常进行转发，并导致页表和TLB刷新的切换。这涉及到大量开销，也是为什么64位Linux VM现在更喜欢在硬件虚拟化而不是半虚拟化中运行完全虚拟化的主要原因之一。

现在将描述与消除PV X-容器中的内核隔离相关的各方面。

PV X-容器架构类似于Xen PV架构，一个关键的区别是访客内核(即X-LibOS)没有与用户进程隔离。相反，它们使用相同的段选择器和页表特权级别，使得内核访问不再需要在(访客)用户模式和(访客)内核模式之间切换，并且系统调用可以利用函数调用来执行。

这导致了复杂的问题：Xen需要知道CPU是处于访客用户模式还是访客内核模式，以进行正确的syscall转发和中断递送。Xen使用它可以维护的标志来实现这一点，因为所有用户内核模式切换由Xen处理。然而，在X-LibOS中，利用如本文所述的轻量级系统调用和中断处理，访客用户内核模式切换不再涉及X-内核。相反，X-内核通过检查当前堆栈指针的位置来确定CPU是在执行内核代码还是进程代码。与正常的Linux内存布局一样，X-LibOS被映射到虚拟内存地址空间的上半部，并由所有进程共享。用户进程内存被映射到地址空间的下半部。因此，堆栈指针中的最高有效位指示它是处于访客内核模式还是访客用户模式。

在半虚拟化的Linux中，页表中的“全局”位被禁用，使得不同地址空间之间的切换导致完全TLB刷新。这对于X-LibOS是不需要的，因此X-LibOS和X-内核的映射均具有设置在页表中的全局位。在运行在相同X-LibOS上的不同进程之间的切换不需要完全TLB刷新，这大大改进了地址转换的性能。不同X-容器之间的上下文切换确实会触发完全TLB刷新。

因为内核代码不再受保护，如果只存在一个进程，则内核例程就不需要专用的堆栈。然而，X-LibOS支持多个进程。因此，我们在内核上下文中仍然需要专用的内核堆栈，并且当执行系统调用时，从用户堆栈到内核堆栈的切换是必要的。

现在将描述与PV X-容器中的轻量级中断处理相关的各方面。

在Xen PV架构中，中断作为异步事件递送。存在由Xen和访客内核共享的变量，该变量指示是否存在任何事件待决。如果是这样的话，访客内核向Xen发出超级调用来递送这些事件。在X-容器架构中，当看到任何待决事件时，X-LibOS能够模拟中断堆栈帧，并直接跳转到中断处理程序，而无需首先陷入X-内核。

为了从中断处理程序返回，iret指令被用来一起复位代码和堆栈段、堆栈指针、标志和指令指针。中断也必须自动启用。但是在Xen PV架构中，虚拟中断只能通过写入到内存位置来启用，这不能与其他操作一起原子执行。为了在切换特权级别时保证原子性和安全性，Xen为实现iret提供了超级调用。在X-容器架构中，我们可以在用户模式下完全实现iret。

在用户模式下实现iret时存在两个挑战：首先，所有通用寄存器在跳回返回地址之前都必须被恢复，所以诸如堆栈指针和指令指针之类的临时值只能保存在内存中，而不能保存在寄存器中。其次，在不发出超级调用的情况下，虚拟中断就不能与其他操作一起原子启用。因此，操纵保存在内存中的临时值的代码必须支持可重入性。

有两种情况要考虑。当返回到在内核模式堆栈上运行的地点时，X-LibOS将包括返回地址的临时寄存器推送到目标堆栈上，并在启用中断之前切换堆栈指针，从而保证抢占是安全的。然后代码通过使用简单的ret指令跳转到返回地址。当返回到用户模式堆栈时，用户模式堆栈指针可能无效，因此X-LibOS将临时值保存在内核堆栈中以便进行系统调用处理、启用中断、并且然后执行iret指令。类似于iret，用于从系统调用处理程序返回的sysret指令经过优化，不会陷入内核模式。实现sysret更容易，因为它可以利用某些临时寄存器。

现在将更详细地描述上述HV X-容器的例示性实施例。如上所述，PV X-容器的通用性带来了通过超级调用执行所有敏感系统指令的成本，包括页表操纵和上下文切换。如果硬件虚拟化支持可用，则HV X-容器可以消除这一成本。

在具有硬件虚拟化支持的情况下，X-LibOS可以在内核模式下运行，并且直接执行大部分特权指令，这大大改进了页表管理和上下文切换的性能。主要的挑战也来自于在内核模式下运行用户进程。除了修改Linux内核中的内存和CPU管理组件使得用户进程可以在内核模式下运行，我们还需要更改处理中断和异常的方式。因为CPU直接在HV X-容器中递送中断和异常，所以X-内核无法控制处理它们的方式。x86平台上的默认行为是，当内核模式下存在中断或异常时，不会发生堆栈切换。这意味着中断处理程序可以直接在用户堆栈上执行，这打破了用户代码和内核代码中的基本假设：用户堆栈上的数据可能会受到损害，并且为了正确处理这种情况，Linux内核中的许多代码需要更改。

幸运的是，x86-64引入了新的中断堆栈切换机制，称为中断堆栈表(IST)，以强制对中断和异常进行堆栈切换。通过在中断描述符表(IDT)中指定标记，即使特权级别没有更改，CPU也将切换到新的堆栈指针。然而，在这种情况下，如果重新使用相同的堆栈指针，嵌套中断就会成为问题。我们通过在IST中指定临时堆栈指针来解决这个问题。在刚进入中断处理程序后，我们将堆栈帧复制到正常的内核堆栈中，使得相同的堆栈指针可以用于嵌套中断。

现在将描述与PV和HV X-容器中的轻量级系统调用相关的各方面。

在x86-64架构中，用户模式程序使用syscall指令执行系统调用，该指令将控制转移到处于内核模式的例程。X-内核立即将控制转移到X-LibOS，从而保证二进制级兼容性，使得现有的应用可以在X-LibOS上运行，而无需任何修改。

因为X-LibOS和进程两者以相同特权级别运行，所以直接调用系统调用处理程序更有效。然而，GS段的设置带来了挑战。Linux内核在GS段中存储每CPU变量。这个段由swapgs指令在进入内核以便进行每次系统调用时设置，并在返回用户程序之前重新设置。不幸的是，swapgs指令只在内核模式下有效。通过避免使用分段，可以更改每CPU的变量放置。但是为了保持对Linux内核的更改最小，我们替代地在进入或离开X-LibOS时禁用GS段切换，从而保持GS段一直有效。尽管x86-64应用可能会将FS段用于线程本地存储，但一般不会触及GS段。我们还没有看到需要定制化GS段的任何应用。

另一挑战来自启用轻量级系统调用的机制。X-LibOS在vsyscall页中存储系统调用入口表，其在每个进程中被映射到固定的虚拟内存地址。更新X-LibOS不会影响系统调用入口表的位置。使用该入口表，应用可以像大多数现有LibOS一样，通过修补源代码以将系统调用更改为函数调用，来优化X-容器的库和二进制。但是，它大大增加了部署复杂性，并且它无法处理没有可用源代码的第三方工具和库。为了避免重写或重新编译应用，我们在X-内核中为PV X-容器并且在X-LibOS中为HV X-容器实现了在线自动二进制优化模块(ABOM)。它自动动态地用函数调用来替换syscall指令。现场二进制替换存在许多挑战：

1.二进制级等价性：补丁指令的总长度不能更改，并且即使当应用代码跳转到补丁块的中间中时，程序也必须执行完全相同的功能。

2.位置无关性：我们只能调用存储在内存或寄存器中的绝对地址，而不能调用相对地址位移，因为对于不同的进程诸如glibc之类的库被加载在不同的位置。

3.最低性能影响：在加载应用时或运行时期间扫描整个二进制是不切实际的。

4.处理只读页：大部分二进制代码在内存中被映射为只读。二进制替换不能在X-LibOS中触发写入时复制机制，否则可能会为不同的进程创建相同内存页的多个副本。

5.并发性安全：运行不同线程或进程的多个CPU可以共享相同的代码。替换应该在不影响或停止其他CPU的情况下自动完成。

6.交换安全性：在替换期间可能发生内存交换。系统应该能够在不损害内存或导致高性能开销的情况下正确检测和处理它。

当接收到来自用户进程的syscall请求时，ABOM动态地执行二进制替换，从而避免扫描整个二进制文件。在转发syscall请求之前，ABOM检查syscall指令周围的二进制，以查看它是否匹配它识别的任何模式。如果是这样，ABOM暂时禁用CR-0寄存器中的写入保护位，使得在内核模式下运行的代码可以更改任何内存页，即使它在页表中被映射为只读。然后，ABOM用原子cmpxchg指令执行二进制补丁。由于每个cmpxchg指令最多可以处理八个字节，如果我们需要修改超过八个字节，为了并发性安全，我们需要确保二进制的任何中间状态仍然有效。该补丁对X-LibOS几乎是透明的，除了页表脏位将被设置为只读页。X-LibOS可以选择忽略那些脏页，或者将它们刷新到磁盘，使得将来不需要相同的补丁。

更大的问题是要处理交换安全。特别是在PV X-容器中，尽管内存交换的决定是由X-LibOS做出的，但是所有的页表操纵都是通过X-内核中的超级调用来完成的。X-内核可以锁定页表，以防止在二进制替换期间进行交换，但这可能会导致更高的性能开销。我们最终实现了二进制替换，如下所示：二进制替换在系统调用的上下文中运行，因此如果目标页面在替换之前被换出，则对页面的写入将触发页面错误。ABOM捕捉到这个页面错误，并继续转发系统调用，而不将其传播到X-LibOS的页面错误处理程序。下次当其被执行时，ABOM将尝试修补相同的位置。

图6示出了ABOM识别的三种二进制代码模式。为了执行系统调用，程序通常用mov指令在rax或eax寄存器中设置系统调用数量，然后执行syscall指令。syscall指令为2字节，并且mov指令为5或7字节，这取决于操作数的大小。我们用内存中存储有绝对地址的单个调用指令来替换这两条指令，这可以用7个字节实现。入口点的内存地址从存储在vsyscall页中的系统调用入口表中检索。二进制替换只需要对每个地点执行一次。

利用7字节替换，我们将两个指令合并为一个。在将rax寄存器设置到其他地方或发生中断后，程序很少会直接跳转到原始syscall指令的位置。在替换后，这将导致跳转到我们的call指令的最后两个字节，它们总是为“0x60 0xff”。这两个字节导致无效的操作码陷阱进入X-内核(PV)或X-LibOS(HV)。为了提供二进制级等价性，我们通过将指令指针向后移动到调用指令的开头来在X-内核(仅在PV的情况下)和X-LibOS中添加特殊的陷阱处理程序，以修复陷阱。我们只在一些操作系统的启动时期间看到过这种情况被触发。

如图6所示，9字节替换以两个阶段执行，其中它们的每个生成相当于原始二进制的结果。由于mov指令需要7个字节，我们直接用到syscall处理程序中的调用来替换它。我们可以保持原始syscall指令不变，以防程序直接跳转到该指令。但是我们利用到前面的调用指令的跳转来进一步优化它。X-LibOS中的syscall处理程序将再次检查返回地址上的指令是syscall还是调用指令的特定jmp。如果是，则syscall处理程序修改返回地址以跳过这个指令。

我们的在线二进制替换解决方案只处理syscall指令紧跟mov指令的情况。对于更复杂的情况，可以将一些代码注入到二进制中，并重定向更大的代码块。我们还提供了用于离线进行的工具。对于大多数标准库(诸如glibc)，默认的系统调用包装器通常使用图6中示出的模式。因此，本实施例足以优化关键路径上的大多数系统调用包装器。

现在将描述与PV和HV X-容器中的Docker映像的轻量引导相关的各方面。

X-容器没有VM磁盘映像，并且也不经历VM经历的相同的引导阶段。为了引导X-容器，X-内核用特殊的引导加载程序将X-LibOS加载到内存中，并直接跳转到X-LibOS的入口点。引导加载程序初始化虚拟设备，包括设置IP地址，并且然后在容器中产生进程，而不运行任何不必要的服务。如果需要的话，容器中的第一进程可以分叉附加进程。此外，在没有底层管理程序帮助的情况下，也可以由GNU GR和统一引导加载程序(GRUB)利用特殊的引导加载程序加载HV X-LibOS。这种方法使X-容器比典型的VM更小，并且启动更快。例如，我们能够在三秒钟内用单个bash进程产生新的Ubuntu-16 X-容器，内存大小为64MB。

因为X-容器支持二进制级兼容性，我们可以运行任何现有的Docker映像而无需修改。我们用Docker包装器将我们的X-容器架构连接到Docker平台。在主机X-容器中运行的未修改的Docker引擎用于提取和构建Docker映像。我们使用devicemapper作为存储驱动程序，其将不同层的Docker映像存储为精简配置的写入时复制快照设备。然后，Docker包装器从Docker中检索元数据、创建精简块设备、并将其连接到新的X-容器。容器中的进程然后利用专用的X-LibOS产生。

为了展示这些例示性实施例的各种优点，针对传统布置评估了上述某些例示性实施例的示例实施方式。

图7示出了在例示性实施例的这种评估中使用的软件栈的示例。在该图中，虚线框指示Docker容器或X-容器。实线指示特权级别之间的隔离边界。虚线指示库接口。

作为评估的一部分，我们在裸机上和公共云中的VM上均进行了实验。在裸机实验中，我们使用了连接到一台10Gbit交换机的四台戴尔PowerEdge R720服务器(两台2.9GHz英特尔Xeon E5-2690 CPU、16个内核、32个线程、96GB内存、4TB磁盘)。对于云环境，我们在亚马逊EC2北弗吉尼亚地区的四个VM中运行实验(m3.xlarge实例、2个CPU内核、4个线程、15GB内存和2个40GB SSD存储装置)。

作为基线，我们在裸机上和亚马逊HV机器中均运行了Docker容器平台。我们分别称这两种配置为Docker/本机/裸机和Docker/本机/云。我们将它们的性能与运行在单个Xen HV和PV域-U VM中的Docker容器以及与X-容器进行了比较。这导致了附加的六种配置：Docker/HV/裸机，Docker/PV/裸机，X-容器/HV/裸机，X-容器/PV/裸机，X-容器/HV/云以及X-容器/PV/云。图7示出了这些配置的各种软件栈。请注意，在这八种配置中，三种在云中运行，并且五种在裸机上运行。

运行本机Docker的主机(物理机或亚马逊EC2实例)使得Ubuntu 16.04-LTS安装有Docker引擎17.03.0-ce和Linux内核4.4.44。运行Xen VM的主机使得CentOS-6安装在域-0中，使得Ubuntu 16.04-LTS安装在域-U中并安装有Docker引擎17.03.0-ce、Linux内核4.4.44和Xen 4.2。运行X-容器的主机使用基于Linux内核4.4.44的X-LibOS和作为主机X-容器的CentOS-6。Docker容器使用默认的NUMA感知的Linux调度程序，同时打开IRQ平衡服务。域-0和主机X-容器配置有专用CPU内核，并且我们手动将IRQ平衡到不同的内核。其他VM或X-容器根据NUMA放置平均分配给其他CPU内核。

对于每组实验，使用相同的Docker映像。Docker引擎全部配置有device-mapper存储驱动程序。当运行涉及客户机或服务器的网络基准测试时，使用了单独的机器或VM。

因为在X-容器中运行的应用对X-LibOS具有完全的控制，所以当只有单个线程繁忙时，它们可以禁用对称多处理(SMP)和多核支持。在许多情况下，这种优化可以显著改进性能，从而消除并发性管理和TLB击落。在Docker容器中运行的应用不能进行这种优化，因为它需要根特权。在接下来的微基准测试和宏基准测试中，我们执行了单进程测试和多进程测试两者。对于单进程的情况，我们在X-LibOS中禁用了SMP支持。

对于本文描述的大多数实验，我们报告了五次运行的平均值，并示出了标准偏差。

我们用一组微基准测试评估了X-容器的性能。我们从Ubuntu16 Docker映像开始，并在其中运行UnixBench和iperf。Execl基准测试测量了exec系统调用的速度，该系统调用在当前进程上覆盖了新的二进制。文件复制基准测试测试复制具有不同缓冲区大小的文件的吞吐量。管道吞吐量基准测试测量管道中的读取和写入的吞吐量。基于管道的上下文切换基准测试测试两个进程与管道通信的速度。进程创建基准测试测量用fork系统调用产生新进程的性能。系统调用基准测试测试发出一系列系统调用(包括dup、close、getpid、getuid和umask)的速度。最后，iperf基准测试测试TCP传输的性能。对于并发性测试，我们在裸机实验中运行了4个副本，并且在亚马逊EC2实验中运行了2个副本，因为EC2实例只有两个CPU内核。

图8示出了各种图7配置相对于上述微基准测试的相对性能。图8包括四个部分，表示为图8(a)、图8(b)、图8(c)和图8(d)。

一般而言发现的是X-容器具有显著更高的系统调用吞吐量，因为我们把系统调用转变为轻量级的函数调用。对于单进程基准测试，我们通过禁用SMP支持来优化X-LibOS，并且因此X-容器显著优于Docker。与Docker/本机相比，X-容器/PV在进程创建和上下文切换方面有大量开销，特别是在虚拟化环境(诸如亚马逊EC2)中。这是因为进程创建和上下文切换涉及许多页表操作，这些操作必须在X-内核中完成。X-容器/HV消除了这一开销，并实现了比Docker/本机和Docker/HV/裸机两者更好的性能。在文件复制基准测试中，Docker/HV/裸机实现了比Docker/本机/裸机更好的性能，因为存在额外的磁盘缓存层。

我们还用两个宏基准测试评估了X-容器的性能，其中评估结果示出在图9中。图9包括四个部分，表示为图9(a)、图9(b)、图9(c)和图9(d)。NGINX网络服务器吞吐量的评估结果示出在图9(a)和图9(b)中，并且内核编译时间的评估结果示出在图9(c)和图9(d)中。

对于NGINX服务器，我们在所有平台上运行Docker映像NGINX:1.11。我们使用wrk基准测试来测试具有单个和多个工作进程的NGINX服务器的吞吐量。wrk客户端为NGINX服务器中的每个工作进程启动了10个线程和100个连接。在裸机上，Docker容器和X-容器使用桥接网络，并且可以直接连接到客户端。在亚马逊EC2上，他们使用了带有端口转发的私有网络。注意，X-容器/HV/云在EC2中接管了整个HVM，所以它可以访问网络而无需端口转发。对于内核编译测试，我们使用了Ubuntu-16.04Docker映像，并在其中安装编译工具。我们利用“微小”的配置编译了最新的4.10Linux内核。并发测试是通过在裸机实验中运行4个并行作业和在Amazon EC2实验中运行2个并行作业来执行的。

图9(a)和图9(b)示出了在裸机和亚马逊EC2上测量的NGINX网络服务器吞吐量。由于内核定制和降低的系统调用开销，X-容器始终优于Xen VM内的Docker容器。当运行单个工作进程时，通过禁用SMP支持，X-容器/PV/裸机和X-容器/HV/裸机被进一步优化，并且分别实现了比Docker/本机/裸机容器高5％和23％的吞吐量。在裸机上运行并发工作进程时，X-容器的性能与Docker/本机/裸机容器相当。在亚马逊EC2中，X-容器/HV/云实现了比Docker/本机/云高69％至78％的吞吐量，因为它接管了整个HVM，并且在没有端口转发的情况下运行。由于上下文切换开销，与Docker/本机/云相比，X-容器/PV/云在并发测试中有20％的性能损失。该结果表明，对于网络I/O密集型工作负载，X-容器的性能优于VM，并且在许多情况下甚至优于本机Docker容器。

图9(c)和图9(d)示出了裸机和亚马逊EC2实例上的内核编译时间，其中较低的内核编译时间优于较高的内核编译时间。类似于NGINX实验，裸机上的单进程X-容器的性能显著优于本机运行或在VM中运行的Docker容器。我们在亚马逊EC2中没有看到类似的改进，我们怀疑这是由于另一层I/O调度。由于半虚拟化环境中的页表管理的高开销，PV X-容器的性能略微受到影响，从而使得操作(诸如fork和exec)减速。这个结果表明，对于CPU密集型工作负载，我们从轻量级系统调用中获得的性能优势是有限的，但是通过内核定制性能提高仍然是可能的。

还将X-容器的例示性实施例与Graphene和Unikernel进行了比较，其结果示出在图10中。图10包括三个部分，表示为图10(a)、图10(b)和图10(c)。

为了进行这些比较，我们在裸机上用NGINX网络服务器、PHP和MySQL数据库运行了wrk基准测试。Graphene用Ubuntu-16.04在Linux上运行，并且在没有安全隔离模块(其应该可以改进其性能)的情况下被编译。对于Unikernel，我们使用了Rumprun，因为它可以运行带有小补丁的那些应用(用MirageOS运行需要用OCaml重写整个应用)。Unikernel不支持在Xen HV中运行，所以我们只用PV模式对其进行测试。

图10(a)比较了为静态网页服务的NGINX网络服务器和单个工作进程的吞吐量。由于只有一个NGINX服务器进程在运行，我们通过禁用SMP来优化X-容器。X-容器实现的吞吐量与Unikernel相当，并且是Graphene的吞吐量的两倍多。

图10(b)示出了运行单个NGINX网络服务器的4个工作进程的情况。这是Unikernel不支持的，所以我们只与Graphene进行比较。在这种情况下，X-容器优于Graphene超过50％。Graphene的性能受到限制，因为在Graphene中，多个进程使用IPC调用来协调对共享的POSIX库的访问，这导致了大量开销。

我们结合图5评估了前面描述的场景，其中两个PHP CGI服务器连接到MySQL数据库。我们启用了PHP的内置网络服务器，并使用wrk客户端访问向数据库发出请求的页面(具有相等的读取和写入概率)。如图5所示，PHP服务器可以共享数据库，也可以有单独的数据库。Graphene不支持PHP CGI服务器，所以我们只与Unikernel进行比较。用不同的配置测量了两个PHP服务器的总吞吐量，其结果示出在图10(c)中。所有VM用一个CPU内核运行单个进程。在3-VM和4-VM配置下，X-容器优于Unikernel超过40％。我们认为这是因为Linux内核相比于Rumprun内核被更好地优化。进一步，X-容器支持在单个容器中运行PHP和MySQL，这对于Unikernel是不可能的。这种便利性也极大地有助于性能：X-容器的吞吐量约为Unikernel设置的吞吐量的三倍。

还进行了例示性实施例的可扩展性评估，其结果示出在图11中。

我们通过在一台物理机上运行多达400个容器来评估X-容器架构的可扩展性。对于这个实验，我们使用了带有PHP-FPM引擎的NGINX服务器。我们使用了webdevops/PHP-NGINX Docker映像，并用单个工作进程配置了NGINX和PHP-FPM。我们运行wrk基准测试来测量所有容器的总吞吐量。每个容器都有具有5个并发连接的专用的wrk线程，因此wrk线程和并发连接的总数随着容器的数量线性增加。

每个X-容器配置有单个虚拟CPU和128MB内存，同时通过禁用SMP支持来优化X-LibOS。应该注意的是，X-容器可以以较低的内存量(例如，64MB的内存)操作，但是128MB的内存大小对于引导400个X-容器来说足够小了。对于Docker/HV/裸机和Docker/PV/裸机，每个Xen VM分配了一个虚拟CPU和512MB内存(512MB是Ubuntu-16 OS的建议最小大小)。但是，由于物理机只有96GB内存，当启动超过200个VM时，我们不得不将VM的内存大小更改为256MB。我们发现VM仍然可以启动，但网络堆栈开始丢包。我们无法在Xen上正确引导超过250个PV实例或超过200个HV实例。

图11示出了所有裸机配置的累积吞吐量。我们可以看到Docker/本机/裸机容器对于较小数量的容器实现了更高的吞吐量。这是因为Docker容器之间的上下文切换比X-容器之间和Xen VM之间的上下文切换更便宜。然而，随着容器的数量的增加，Docker容器的性能下降得更快。这是因为每个NGINX+PHP容器运行4个进程：利用N个容器，运行Docker容器的Linux内核调度4N个进程，而X-内核调度N个虚拟CPU，每个CPU运行4个进程。这种分层调度被证明是将许多容器调度在一起的更可扩展的方法，并且在N＝400的情况下，X-容器/PV/裸机优于Docker/本机/裸机18％。

评估进一步展示了内核定制的附加性能优势，如现在将参考图12进行描述的那样。X-容器的例示性实施例实现了需要定制内核模块的应用容器。例如，X-容器可以使用软件RDMA(Soft-iwarp和Soft-ROCE两者)应用。在Docker环境中，这种模块需要根特权，并且将主机网络直接暴露给容器，这引起了安全问题。

我们用三个NGINX网络服务器和负载平衡器测试了场景。NGINX网络服务器各自被配置为使用一个工作进程。Docker平台通常使用用户级负载平衡器，诸如HAProxy。HAProxy是广泛部署在生产系统中的单线程、事件驱动的代理服务器。X-容器支持HAProxy，但也可以使用内核级负载平衡解决方案，诸如IPVS(IP虚拟服务器)。IPVS要求插入新的内核模块，并更改iptable和ARP表规则，这在没有根特权和对主机网络的访问的Docker容器中是不可能的。

在这个实验中，我们使用了HAProxy:1.7.5Docker映像。负载平衡器和NGINX服务器在相同物理机上运行。我们为每个X-容器配置了单个虚拟CPU，其中在X-LibOS中关闭了SMP支持，以获得优化性能。我们使用wrk工作负载生成器并测量总吞吐量。

图12比较了各种配置。带有HAProxy的X-容器平台实现了Docker容器平台的吞吐量的两倍。用使用NAT模式的IPVS内核级负载平衡，X-容器将吞吐量进一步提高了12％。在这种情况下，负载平衡器是瓶颈，因为它充当网络前端和NAT服务器两者。IPVS支持被称为“直接路由”的另一负载平衡模式。在直接路由的情况下，负载平衡器只需要将请求转发到后端服务器，而来自后端服务器的响应直接被路由到客户端。这需要改变iptable规则，并在负载平衡器和NGINX服务器中插入内核模块。用直接路由模式，瓶颈转移到NGINX服务器，并且总吞吐量提高到1.5倍。

应当理解的是，结合以上评估描述的特定X-容器实施例仅是示例，旨在展示例示性实施例的优点，并且不应被视为以任何方式进行限制。

应当理解的是，结合图1至图12示出和描述的特定布置仅通过例示性示例的方式呈现，并且许多替代性实施例是可能的。因此，本文公开的各种实施例不应被解释为以任何方式进行限制。在其他实施例中，可以利用用于实现软件容器的多种替代性布置。例如，可以使用其他类型的基于内核的隔离层来代替结合某些例示性实施例描述的特定X-内核布置。本领域技术人员还将认识到，在其他实施例中可以使用替代性处理操作和相关联的系统实体配置。

因此，相对于例示性实施例的实体，其他实施例可以包括附加的或替代性的系统元件。因此，在其他实施例中，特定的系统配置和相关联的软件容器和基于内核的隔离层实施方式可以变化。

如本文所述的给定处理设备或信息处理系统的其他组件被例示性地配置为利用包含耦合到存储器的处理器的相对应的处理设备。处理器执行存储在存储器中的软件程序代码，以便控制处理操作的性能和其他功能。处理设备还包含支持通过一个或多个网络进行通信的网络接口。

处理器可以以任何组合包含例如微处理器、ASIC、FPGA、CPU、ALU、GPU、DSP或其他类似的处理设备组件，以及其他类型和布置的处理电路系统。例如，如本文所公开的给定的处理设备可以使用这样的电路系统来实现。

存储器存储软件程序代码，以便由处理器在实现处理设备的部分功能时执行。存储这种程序代码以便由相对应的处理器执行的给定的这种存储器是在本文中更一般地被称为其中包含程序代码的处理器可读存储介质的示例，并且可以以任何组合包含例如电子存储器(诸如SRAM、DRAM或其他类型的随机存取存储器)、ROM、闪存、磁存储器、光存储器或其他类型的存储设备。

如前所提及那样，包含这种处理器可读存储介质的制品被认为是本发明的实施例。如本文所用的术语“制品”应该理解为排除暂时的、传播的信号。在其他实施例中，可以实现包含处理器可读存储介质的其他类型的计算机程序产品。

此外，本发明的实施例可以以集成电路的形式实现，该集成电路包含处理电路系统，该处理电路系统被配置为实现与在基于内核的隔离层上提供软件容器相关联的处理操作。

如本文所公开的信息处理系统可以使用一个或多个处理平台或其部分来实现。

例如，可以用于实现信息处理系统的至少一部分的处理平台的一个例示性实施例包含云基础设施，该云基础设施包括使用在物理基础设施上运行的管理程序实现的虚拟机。这种虚拟机可以包含通过一个或多个网络彼此通信的相应的处理设备。

在这样的实施例中，云基础设施可以进一步包含在管理程序的控制下在虚拟机中的相应虚拟机上运行的一组或多组应用。也可以使用多个管理程序，每个管理程序使用至少一个底层物理机来提供一组虚拟机。由一个或多个管理程序提供的不同组的虚拟机可以用于配置信息处理系统的各种组件的多个实例。

可以用于实现如本文所公开的信息处理系统的至少一部分的处理平台的另一例示性实施例包含通过至少一个网络彼此通信的多个处理设备。假设处理平台的每个处理设备包含耦合到存储器的处理器。

同样，这些特定的处理平台仅通过示例的方式呈现，并且信息处理系统可以以任何组合包括附加的或替代性的处理平台，以及许多不同的处理平台，其中每个这样的平台包含一个或多个计算机、服务器、存储设备或其他处理设备。

例如，代替包含虚拟机的虚拟化基础设施或除了该虚拟化基础设施之外，用于实现本发明的实施例的其他处理平台可以包含不同类型的虚拟化基础设施。因此，在一些实施例中，系统组件可以至少部分地在云基础设施或其他类型的虚拟化基础设施中运行是可能的。

因此，应当理解的是，在其他实施例中，可以使用附加或替代性元件的不同布置。这些元件的至少一个子集可以在公共处理平台上共同实现，或者每个这样的元件可以在单独的处理平台上实现。

而且，在信息处理系统中，计算机、服务器、存储设备或其他组件的许多其他布置也是可能的。这种组件可以通过任何类型的网络或其他通信介质与信息处理系统的其他元件通信。

如前所述，如本文所公开的系统的组件可以至少部分地以存储在存储器中并由处理设备的处理器执行的一个或多个软件程序的形式来实现。例如，本文公开的某些功能可以至少部分以软件的形式实现。

本文描述的信息处理系统的特定配置仅仅是示例性的，并且在其他实施例中给定的这样的系统可以包括除了那些具体示出的元件之外或者代替那些具体示出的元件的其他元件，包括在这样的系统的常规实施方式中常见的类型的一个或多个元件。

例如，在一些实施例中，信息处理系统可以被配置为利用所公开的技术来在其他环境中提供附加的或替代性的功能。

应该再次强调的是，如本文所述的本发明的实施例仅仅是例示性的。本发明的其他实施例可以利用除了在本文中描述的特定例示性实施例中使用的那些信息处理系统、网络和设备之外的多种不同类型和布置的信息处理系统、网络和设备来实现，并且在许多替代性处理环境中实现。此外，本文在描述某些实施例的上下文中做出的特定假设不需要应用于其他实施例。这些和许多其他替代性实施例对于本领域技术人员来说将是显而易见的。

Claims (22)

1.一种方法，包含：

实现基于内核的隔离层；

在所述基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核；以及

在所述软件容器中执行一个或多个用户进程；

其中所述方法由包含多个处理设备的处理平台执行，每个所述处理设备包含耦合到存储器的处理器。

2.根据权利要求1所述的方法，其中所述基于内核的隔离层相对于所述软件容器的所述专用操作系统内核以X-内核的形式实现。

3.根据权利要求1所述的方法，其中所述基于内核的隔离层包含虚拟机管理程序和主机操作系统中的一个。

4.根据权利要求1所述的方法，其中所述库操作系统是从指定类型的单一操作系统内核转换而来。

5.根据权利要求1所述的方法，其中所述库操作系统以与在所述软件容器中执行的所述一个或多个用户进程的特权级别相同的特权级别在所述软件容器中运行。

6.根据权利要求1所述的方法，其中所述库操作系统被配置为结合将系统调用转换为相对应的函数调用来支持所述一个或多个用户进程的二进制的自动翻译。

7.根据权利要求1所述的方法，其中在所述基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核进一步包含：

提取现有软件容器的容器映像；以及

在所述基于内核的隔离层上配置所述软件容器时，利用所提取的容器映像作为虚拟机映像；

其中所述基于内核的隔离层上的所述软件容器包含所述现有软件容器的包装版本。

8.根据权利要求7所述的方法，其中所述现有软件容器的一个或多个用户进程被允许作为所述软件容器中的所述一个或多个用户进程在所述基于内核的隔离层上执行，而不需要对那些一个或多个用户进程进行任何修改。

9.根据权利要求1所述的方法，其中在所述基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核进一步包含：在所述基于内核的隔离层上配置多个软件容器，其中所述多个软件容器中的每个包括作为库操作系统的单独的专用操作系统内核。

10.根据权利要求9所述的方法，其中在所述软件容器中执行一个或多个用户进程进一步包含在所述多个软件容器中的相应软件容器中执行不同组的一个或多个用户进程，并且其中所述不同组中的至少一个包含多个不同的用户进程。

11.根据权利要求10所述的方法，其中在所述多个软件容器中的第一软件容器中执行的所述不同组的一个或多个用户进程中的第一组与在所述多个软件容器中的第二软件容器中执行的所述不同组的一个或多个用户进程中的第二组隔离。

12.根据权利要求1所述的方法，其中配置所述软件容器包含将所述软件容器配置为半虚拟化软件容器，其中所述库操作系统和所述一个或多个用户进程以用户模式运行。

13.根据权利要求12所述的方法，其中实现所述半虚拟化软件容器在其上运行的所述基于内核的隔离层包含将所述基于内核的隔离层实现为其他的标准虚拟机管理程序或操作系统内核的修改版本。

14.根据权利要求1所述的方法，其中配置所述软件容器包含将所述软件容器配置为硬件辅助的虚拟化软件容器，其中所述库操作系统和所述一个或多个用户进程在硬件辅助的虚拟机内以内核模式运行。

15.根据权利要求14所述的方法，其中实现所述硬件辅助的虚拟化软件容器在其上运行的所述基于内核的隔离层包含将所述基于内核的隔离层实现为标准虚拟机管理程序或操作系统内核。

16.根据权利要求1所述的方法，其中所述基于内核的隔离层和所述软件容器的所述库操作系统使用不同类型的相应第一操作系统和第二操作系统来实现。

17.一种系统，包含：

处理平台，所述处理平台包含多个处理设备，每个所述处理设备包含耦合到存储器的处理器；

所述处理平台被配置为：

实现基于内核的隔离层；

在所述基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核；以及

在所述软件容器中执行一个或多个用户进程。

18.根据权利要求17所述的系统，其中所述处理平台被配置为在所述基于内核的隔离层上为相应的不同租户提供不同组的一个或多个软件容器，其中每个这样的软件容器包括作为库操作系统的专用操作系统内核。

19.根据权利要求17所述的系统，其中所述处理平台包含以下中的至少一个：

基于云的处理平台；

企业处理平台；

物联网(IoT)平台；以及

网络功能虚拟化(NFV)平台。

20.一种计算机程序产品，包含其中存储有一个或多个软件程序的程序代码的非暂时性处理器可读存储介质，其中所述程序代码在由包含多个处理设备的处理平台执行时，使得所述处理平台执行以下操作，每个处理设备包含耦合到存储器的处理器：

实现基于内核的隔离层；

在所述基于内核的隔离层上配置软件容器以包括作为库操作系统的专用操作系统内核；以及

在所述软件容器中执行一个或多个用户进程。

21.根据权利要求20所述的计算机程序产品，其中所述库操作系统以与在所述软件容器中执行的所述一个或多个用户进程的特权级别相同的特权级别在所述软件容器中运行。

22.根据权利要求20所述的计算机程序产品，其中所述库操作系统被配置为结合将系统调用转换为相对应的函数调用来支持所述一个或多个用户进程的二进制的自动翻译。

Images