服务器 频道

4ms运行?基于Xen的虚拟机性能边界在哪

  【IT168 资讯】我们是否可以通过容器的效率来改进vm(虚拟机)的效率?在今天的论述中,具体研究了基于Xen(开放源代码虚拟机监视器)的虚拟机性能的边界。发现并消除了在启动大量轻量级vm(包括单核和最小的Linux VMs)时遇到的瓶颈。由此产生的系统被称为LightVM,并具有最小的unikernel镜像,可以以4ms运行VM。相比之下,Linux上的fork和exec大约需要1ms。在同一系统上,Docker容器从大约150毫秒开始运行。

  这些结果是在LightVM 客户虚拟机是unikernel时获得的。你可能只是在特定的情况下创建了一个unikernel。(本文中一个有趣的例子是基于Micropython的unikernel,可用于支持无服务器功能执行)。此外,还创建了一个称为TinyX的自动构建系统,用于创建针对运行单个应用程序的简约Linux VM镜像。与Docker相比,如果我们查看TinyX VM的启动时间,则每个内核的性能非常接近约250个虚拟机或容器。

  在这一点上,Docker开始将其边缘化,因为即使是由TinyX创建的空闲最小的Linux发行版也确实会运行一些临时的后台任务。

  Xen与虚拟机有何关系,瓶颈在哪里?

  如下图所示,限制虚拟化的可扩展性和性能的最大的单一因素是客户虚拟机的大小。要生成该图表,从unikernel虚拟机从内存盘启动,将不同大小的二进制对象注入到未压缩的镜像文件中。所有的这些效果影响都是由镜像的大小决定的。

  所以如果想要快速启动,那么镜像的大小就会变得十分重要。在本文中,小编使用Mini-OS来创建各种unikernel。480KB未压缩,并且运行在3.6MB的RAM,这个unikernel是用于测试可能的VM的内存消耗的下限。

  基于Mini-OS制作自己的unikernel镜像可能比许多人准备做的还要更多,因此也创建了Tinyx。

  Tinyx是一种自动化的构建系统,可以创建针对运行单个应用程序的最小化的Linux VM镜像。 该工具本质上是一个VM,它由一个极简的、基于Linux的分布式系统和一个优化的Linux内核组成。它提供了一个高度专业化的内核,具有非常好的性能但需要将应用程序移植到极简操作系统,以及一个完整的通用OS VM,它支持大量应用程序,但可能会带来一些性能开销。

  Tinyx创建的内核镜像大小是典型的Debian内核的一半,运行时内存使用率显著减少(Tinyx为1.6MB,Debian为8MB)。

  使用这样的小型虚拟机镜像,我们可以在启动大量虚拟机时探测Xen本身的行为。在面对1000位客户时,以下是Debian最小安装的启动和创建时间,以及对同一硬件的比较:Docker容器和简单的进程创建。

  当我们不断创建虚拟机时,创建时间会显著增加(注意对数刻度):分别使用42s、10s和700ms创建千分之一的Debian,Tinyx和unikernel 的客户。

  随着VM的大小的减少,创建时间将占据绝大部分,从而获得可用性。为了理解所有的时间都花在哪里,团队仪表化了Xen来揭示这张照片:

  XenStore交互和设备创建占主导地位。其中,设备的创建开销是相当稳定的,但是XenStore的开销超出线性增长。

  我们的目标是实现VM启动时间与流程启动时间达到相当。Xen没有为此目标而设计,正如前面部分的结果所示,这些问题的根源不仅仅在于低效率代码。例如,XenStore的一个基本问题是其集中式的,类似文件系统的API,在虚拟机创建和启动过程中使用起来太慢,需要数十个中断和特权域过渡。

  当设计首次创建时,很难设想有人能启动1000位访客的虚拟机!

  LightVM使用一个叫noxs的精简驱动程序(用于“no XenStore”)重新设计Xen控制平面,可以替代XenStore,并允许通过共享内存直接与前端和后端驱动程序进行通信。

  标准Xen中的设备创建最终会调用bash脚本,这是一个缓慢的过程。 LightVM将二进制守护程序替换为执行预定义设置的二进制守护进程,而不需要FORK指令或bash脚本。

  性能

  此外,LightVM可以在30毫秒内保存一个VM,并在20ms恢复它。标准Xen分别需要128ms和550ms。

  Unikernel内存使用非常接近Docker容器,Tinyx则需要更多,但在1000位客人中只有22GB。这只是当前服务器RAM的一小部分。

  vm的CPU使用率也可以与容器相媲美,只要将vm缩减为只包括必需的功能:

  用例

  这里介绍了LightVM +轻量级虚拟机的四个不同的用例。

  在所有这些场景中,使用容器将有助于性能提升,但会削弱隔离,而使用完整的vm将提供与轻量级vm相同的隔离,但性能较差。

  ·每个移动用户的个人防火墙,在移动网关或近蜂窝基站(移动边缘计算- MEC)中运行。这里使用了一个ClickOS unikernel镜像,8000个防火墙可以运行在64核AMD机器上。在这种情况下,一台运行LightVM的单一机器就可以为单元中的所有用户运行个性化的防火墙,而不会成为瓶颈。

  ·在移动端计算中的即时服务实例化(类似于JITSU)。

  ·高密度TLS终止于CDNs,这需要内容提供商的长期保密密钥。因此,需要在不同的内容提供者的代理之间进行强大的隔离。

  ·创建一个轻量级的计算服务,如AWS Lambda。对于这个用例,他们使用基于Micropython的unikernel来运行用Python编写的计算。启动和执行一个函数需要大约1.3 ms。当系统被故意强调的时候,比测试机器能够处理的请求会更多,服务时间就会直线上升,直到大约800个vm为止。

  我们展示的用例表明,对轻量级虚拟化有真正的需求,并且可以在par或优于容器的情况下模拟实现良好的隔离和性能。

0
相关文章