

英语原文共 8 页,剩余内容已隐藏,支付完成后下载完整资料
KVM、Xen和Docker:基于ARM的NFV和云计算性能分析
摘要-----
虚拟化技术是一种成熟的技术,它通过虚拟机的概念提供计算资源和成本优化以及实现合并、隔离和硬件抽象。近来,通过分享操作系统资源和简化部署应用程序,容器越来越流行 替代虚拟化特定的用例。因此,如今这两家技术正在为云计算提供虚拟化实例,网络功能虚拟化(NFV),高性能计算(HPC)、航空和自动化平台。在本文中,最重要的开源虚拟机管理程序(KVM and Xen)和容器(Docker)的解决方案是基于正在服务器中迅速崛起的ARM体系结构进行比较。包括在本文中的广泛的系统和输入/输出(I/O)的性能测量,表现出更好的性能的工作负载和请求/响应网络;相反,由于他们的缓存机制,虚拟机管理程序有更好的表现在大多数的磁盘I/O操作和TCP流的基准。
Ⅰ序言
近几年来虚拟化技术已被广泛应用在x86架构的服务器市场,最近甚至台式机/笔记本电脑的环境。如今,在基于ARM的嵌入式系统虚拟化也蓄势待发,可以优化硬件资源,提高能源效率,确保应用程序隔离[ 1 ]。在最新的ARM架构的虚拟化支持扩展用例在嵌入式系统中,如在云计算、网络功能虚拟化(NFV),高性能计算(HPC)系统以及航空和自动化。事实上,对于ARMv7和ARMv8架构虚拟化的硬件支持的引入促使管理程序开发ARM处理器如基于内核的虚拟机(KVM)和Xen。在不同的应用程序中共享硬件资源的另一种方式是通过容器。不同于虚拟机管理程序创建硬件的虚拟实例,容器提供了一个更轻量级的机制来共享一个单一的操作系统(OS)。在一个容器中运行的应用程序认为它的一个拷贝不共享访问操作系统。换句话说,容器虚拟化操作系统的同事虚拟机管理程序的虚拟化硬件资源。容器存在几十年,但需要定制的内核来执行,这在过去的日子里阻止了它们的普及,直到以2008为基础的容器完全支持的主流内核开始。因为容器不需要一个完整的操作系统拷贝,他们被誉为低开销和系统资源消耗。然而,容器被认为是比虚拟机管理程序更容易受到安全威胁,但是在这方面有改进的空间。此外,容器受不能够运行不同的操作系统或内核的限制。
本文针对ARM平台提出了两个开源虚拟机管理程序和一个开放源码的容器性能的比较研究。在这项研究中使用的硬件目标是Arndale [ 2 ]开发板,配备了基于三星的Exynos 5250 SoC两ARMv7 Cortex-A15处理器,包括虚拟化、大物理地址扩展(LPAE)。选择了两个众所周知的,在开源社区支持的虚拟机管理程序KVM和Xen;选择容器的解决方案是在Linux系统中越来越受欢迎的Docker。
本文组织如下:第二节提供了一个先进的描述所选择的虚拟化解决方案,这一基准研究的对象,即,KVM在ARM,Xen在ARM和Docker。第三节提供的不同进行基准测试的描述细节。在第四节中,对实验结果进行展示和讨论。最后,第五节介绍了相关的工作,而第六节的结论是包装和潜在的未来方向。
Ⅱ虚拟机管理程序和容器
A.管理程序
虚拟机管理程序,也被称为虚拟机管理器(VMM),在多个虚拟机之间或用户共享的实机的硬件资源(VM)。通过虚拟化系统资源,如CPU,内存和中断,他们平均同时运行多个操作系统。更好的性能和VM执行额外的隔离是通过自从近十年[ 3 ]包括x86架构的就包括的硬件虚拟化扩展。以类似方式,几年前ARM已经推出了自己的硬件虚拟化扩展,允许虚拟机管理程序,如KVM和Xen提供ARM平台上的高效的虚拟化。
1)KVM /ARM:KVM最初是x86 2007以来建立的开源虚拟机管理程序,然后移植到ARM架构2012。作为其对应的x86,KVM的ARM版集成在Linux内核中,从而有利于重用许多Linux的功能,如内存管理、CPU调度。而KVM x86并入内核版本Linux内核2.6.20的主线,在ARM端口KVM是发布在Linux内核3.9版本[ 4 ]虚拟开放系统和ARM有开源社区的支持。就如同在[ 5 ]的描述,由于x86和ARM虚拟化扩展结构的差异,而KVM在x86上完全可以驻留在内核,KVM在ARM不得不被分割成两部分。事实上,一个ARM上的解决方案完全建立在KVM主机内核需要在ARMs Hyp模式下的重要的和侵入性的修改内核的执行。这不考虑在便携性和性能方面的可行性并且太侵入内核本身。因此在ARM实现KVM已经分为所谓的Highvisor和Lowvisor。Highvisor在于ARMs内核空间和处理大多数的虚拟机管理程序的功能。Lowvisor驻留在HYP模式并负责实施隔离,处理程序陷阱和执行世界开关(上下文执行开关虚拟机和主机之间)。虽然这一机制意味着Highvisor和虚拟机之间的陷阱,需要两个额外的陷阱,在Lowvisor HYP模式,结果表明[ 5 ],即没有产生显著的性能开销。这个执行的根本利益,相比于裸机管理程序如Xen、KVM是基于ARM的移植到一个新的ARM平台成为无缝的,提供的平台能够运行Linux版本高于3.9。 由于ARM平台通常是建立在一个非标准的方式和Linux几乎支持所有最近的ARM平台,这是KVM在便携性和易用性方面的一个关键的增益。
类似于x86,KVM在ARM不提供自己的机器或装置模型。机器和设备的抽象 对于KVM虚拟化模型太具体,并且使得管理程序不必要的变得复杂。相反,KVM依赖如快速仿真器的用户空间工具(QEMU)[ 6 ]和kvmtool--用于模仿访客的硬件设备和实例化虚拟机。在KVM样式的访客由宿主视为正常的POSIX进程,用QEMU(用户空间模拟)驻留在主机用户利用KVM利用硬件虚拟化扩展。QEMU和KVM能够运行完全虚拟化的未修改的访客不一定要求有一个准虚拟化层。在虚拟环境中运行遗留操作系统时,这是一个重要的好处。然而,由于仿真被认为显著增加开销,KVM还支持通过virtio 进行I/0虚拟化 [ 7 ]。Virtio为需要在客户内核启用网络、块和气囊装置提供驱动程序,相应的后端驱动程序运行在用户空间的主机(例如QEMU或kmvtool)。
图1a显示KVM在ARM体系结构
- KVM/ARM 结构
2)Xen在ARM:2003最初,Xen的x86版本,是支持全虚拟化和半虚拟化的访客[ 8 ]裸机管理程序。移植到ARM 时Xen做了大量的代码和架构变化。在提供类似的性能时Xen在ARM的代码的大小小很多。在ARM,Xen的代码减少到一个类型的访客使用半虚拟化驱动和ARM虚拟化扩展。大多数的QEMU软件栈已经去除,使完全虚拟化不可能。这意味着试图运行专有的解决方案时,移植操作系统的Xen成为一个问题。然而,Linux和FreeBSD的分布是由Xen和相关的半虚拟化的前端和后端可以在相应的内核很容易激活。
Xen系统管理程序驻留在HYP模式,提供CPU、内存、中断和定时器功能虚拟化[ 9 ]。Xen 管理程序层的顶部每个事件都是作为一个访客放在不同的域中执行。最有特权的域称为Dom0,负责管理其他虚拟机放置在DomU的访客。Xen通过一个给定的设备树发现硬件和通过生成压平装置树分配未使用的设备给Dom0,这样做Dom0可以以本地方式启动。Xen通过生成的设备树向dom0声明它的存在和限制Dom0资源。Dom0为其附属设备运行本地的驱动和启动一套准虚拟化后端驱动程序。在DomUs,相应的前端驱动程序运行的是为了让他们访问的虚拟化设备。另外,目前,一些从用户空间提供的半虚拟化的后端由QEMU提供。为了提高安全性和隔离性,Xen提供了可能性运行特权的客人与运行一个特定的设备驱动程序和相应的后台只有本地范围。最后,Xen toolstack运行控制领域的一个普通用户空间进程(Dom0)可用于管理特权的域。
ARM硬件虚拟化扩展添加Hyp的模式--将核心从管理程序分离的模式。通过建立一个基于HYP模式下的独立的虚拟机管理程序,Xen在ARM可以充分利用虚拟化扩展而无需额外的开销。Xen有比KVM更好的访客表现潜能,然而,这样的实现有一个额外的工作,移植Xen在每一个新的ARM [ 9 ]。
图1b显示了Xen的ARM体系结构。
(b)Xen在ARM 结构
B. 基于Linux的容器
共享一个共同的内核时容器提供独立的用户空间实例。基于Linux的容器管理工具,如LXC(Linux容器)和Docker,使用Linux的控制组(cgroups)和命名空间技术分别提供资源管理[10]和隔离[11]的容器实例之间。
类似于Linux的进程,cgroups分层组织,孩子cgroups继承他们父母的属性。主要的区别在于,不同于进程,cgroups不是同一棵树的一部分,他们中的许多可以同时存在。每个cgroups可以用来管理一组进程的资源。例如CPU或内存可以被限制在最低。因此,cgroups可以用来调整和限制一个容器的资源。此外,cgroups也被用来终止容器内所有过程。但是,由于Linux容器只共享一个内核,所以存在一个问题,在容器内运行的进程,不知道它们的资源的限制,并且可以查看系统的所有资源[ 12 ]。
有6个Linux的命名空间可以通过克隆系统调用访问。Linux为网络,挂载点,用户和组,进程ID和主机名提供了命名空间。这些命名空间可以获得可用于提供隔离不属于同一命名空间的一部分进程之间不相同的命名空间的一部分系统资源。基于Linux的容器使用命名空间提供之间的隔离自己,例如使用用户命名空间,对容器内的用户权限容器外的是不扩展的 [ 13 ]。
存在两种类型的容器,操作系统容器和应用程序容器。OS容器是运行初始化系统,应用程序容器运行一个单一的应用程序。运行单个应用程序的优点是减少不必要的管理过程分配的资源。然而,这取决于使用的情况,它可能是更好的选运行一个完整的操作系统容器。
1)Docker:Docker出现在2013由于其完整性和易于部署短时间内变得很受欢迎。Docker是一个容器管理工具。它最初是建立在LXC容器提供包装容器中应用的一种简单方法。不同于创建OS容器的LXC,Docker主要管理单一的应用程序容器。即使LXC和其他管理工具依然是靠Docker,0.9以后的版本,Docker引入像LXC一样是一个包装的Linux cgroups和命名空间的lib容器。
Docker利用统一文件系统映射器(Docker0.7之后)或先进的多层次的统一文件系统(AUFS)。一个统一的文件系统提供了一个分层的文件系统。它允许使用一个文件系统作为容器的基础。该文件系统的基础是只读的,并且在它的顶部添加一个写入层,以便使容器可以从原来的文件系统中提交更改。容器运行时修改文件系统的提交是从主机上完成的。但是,如果没有提交,则不保持对原文件的修改。统一文件系统允许多个容器使用相同的操作系统映像的基础,同时允许容器有自己的文件。这样的实施结果在一个显着的存储增益,并允许更快地部署的容器。每一个新版本的容器文件系统是一个变化是与前一个的区别。这使得有可能跟踪的所有变更之间的提交,完全作为版本控制系统操作。最后,Docker提供公共注册中心,并支持能够推动映像的私人机构。这些注册表提供各种Linux基映像以及准备使用的软件,如数据库或网络服务器[ 14 ]。高层Docker可以在图1c看到。
(c)Docker 结构
III.基准的应用
本节说明了用来衡量KVM,Xen和Docker的性能开销不同的基准测试程序与非虚拟化的Linux主机相比较。
A. Hackbench
Hackbench创建给定数量的可调度的实体,可以通过套接字或管道沟通。Hackbench的输出对应了它们发送数据的时间。测量和报告了系统调度和中央处理器的性能[ 15 ]。本文采用版本0.87的实时测试的Hackbench。
B.Byte-unixbench
Byte-unixbench是一个测试系统的各方面性能的目的标准套装。除了为每一个下面提到的基准应用程序提供的原始成绩结果,它还产生一个整体的指标值。Byte-unixbench能够处理SMP系统包括图形性能测试,对于这些本文都是略。本研究采用byteunixbench5.1.3。
1)Dhrystone:在1894年由Rheinhold P. Weicker开发,Dhrystone是CPU性能的代表。测试的重点是测量每秒执行的指令数的整数计算。即使Dhrystone有已知的弱点[ 16 ],由于它的流行还是包括在这个研究中。
2)基准测试程序:基准测试程序衡量浮点运算速度。与Dhrystone类似,基准测试程序参照是一种合成的基准,这意味着它是设计来模仿一些常见的程序集的处理器使用率。
3)较好的吞吐量:这个测试提供了一个测量,进行每秒execl最大呼叫数。exec()函数族用一种新的过程映像替换当前过程映像。
4)管的吞吐量和基于管的环境切换:在管吞吐量测试每秒的次数,一个进程可以写512个字节到一个管,并读取它们返回。基于管的环境切换测试是测量时间的次数,可以通过一个管交换一个增加的整数。
5)进程创建:此测试与内存带宽性能相关。它计算了一个过程可以走多少次岔路,并获得子进程,立即退出。每次创建一个进程,内存就必须分配。
6)Shell脚本:对于这个测试,计数每分钟的进程可以启动和获得一组并行的脚本的副本的时间。这些Shell脚本将一系列转换应用到数据文件中。
7)系统调用开销:这里输入和退出内核的成本都被测量。这些环境切换是通过一系列的系统调用getpid触发。
C.IOzone
性能测试软件IOzone 用于 benchmarks文件系统。从读,写,重读,重写,反向读,读文件,写文件,重读文件随机读写,分析读入,记录重写等方面测试文件I/O读写性能。[ 17 ]。
D
剩余内容已隐藏,支付完成后下载完整资料
资料编号:[29437],资料为PDF文档或Word文档,PDF文档可免费转换为Word
您可能感兴趣的文章
- 饮用水微生物群:一个全面的时空研究,以监测巴黎供水系统的水质外文翻译资料
- 步进电机控制和摩擦模型对复杂机械系统精确定位的影响外文翻译资料
- 具有温湿度控制的开式阴极PEM燃料电池性能的提升外文翻译资料
- 警报定时系统对驾驶员行为的影响:调查驾驶员信任的差异以及根据警报定时对警报的响应外文翻译资料
- 门禁系统的零知识认证解决方案外文翻译资料
- 车辆废气及室外环境中悬浮微粒中有机磷的含量—-个案研究外文翻译资料
- ZigBee协议对城市风力涡轮机的无线监控: 支持应用软件和传感器模块外文翻译资料
- ZigBee系统在医疗保健中提供位置信息和传感器数据传输的方案外文翻译资料
- 基于PLC的模糊控制器在污水处理系统中的应用外文翻译资料
- 光伏并联最大功率点跟踪系统独立应用程序外文翻译资料
