虚拟化把事物从一种形式改变为另一种形式. 计算机的虚拟化使单个计算机看起来像多个计算机或完全不同的计算机.
虚拟化技术也可以使多台计算机看起来像一台计算机. 这叫做服务器聚合(server aggregation)或网格计算(grid computing).
首先我们回顾一下虚拟化技术的历史.
虚拟化技术的历史
虚拟化技术不是一个新的主题实际上, 它已有40年的历史. 最早使用虚拟化技术的是IBM 7044计算机, 它是基于MIT(麻省理工学院)为IBM704计算机开发的分时系统CTSS(Compatible Time Sharing System), 和曼彻斯特大学的Atlas项目(世界最早的超级计算机之一), 首次使用了请求调页和系统管理程序调用.
硬件虚拟化
IBM早在1960年就认识到虚拟化技术的重要性, 于是开发了型号为Model 67的System/360主机. Model 67主机通过虚拟机监视器(VMM, Virtual Machine Monitor)虚拟所有的硬件接口. 在早期的计算中, *** 作系统被称做Supervisor. 能够运行在其它 *** 作系统之上的 *** 作系统被称做hypervisor(名称首次出现在1970年).
VMM直接运行在底层硬件上, 允许执行多个虚拟机(VMs). 每一个VM(虚拟机)运行自己的 *** 作系统实例 -- 早期时候称为CMS, 或会话监视系统(CMS, Conversational Monitor System). 然后VM继续发展. 今天你能够在System z9主机上发现VM, 它能够向后兼容, 甚至是System/360.
处理器虚拟化
另外一个早期使 用的虚拟化技术, 仿真处理器, 也叫做P-code(or pseudo-code)机. P-code是一种机器语言, 运行在虚拟机上而不是实际的硬件. 知名的P-code语言在1970年由加州大学圣地亚哥分校的Pascal系统项目组开发. 它可以把Pascal程序编译成P-code代码, 然后在具有P-code功能的虚拟机上运行. P-code程序具有高度可移植性, 能够运行在任何具有P-code功能的虚拟机上.
1960年的BCPL语言(基本组合程序设计语言, Basic Combined Programming Language)也使用了同样的概念, 它是C语言的前身. 编译器首先把BCPL代码编译成一个中间机器代码: O-code. 然后, O-code被编译成目标机器代码. P-code模型已被广泛使用到各种编译器当中, 从而为编译器移植到新的主机架构提供了复杂性.(通过一个中间语言分成前端和后端).
Java虚拟机(JVM)
Java虚拟机也采用了P-code模型. 从而我们可以简单通过移植JVM程序到新架构的机器上来广泛发布Java程序.
指令虚拟化
近来频繁出现的虚拟化概念: 指令虚拟化, 也叫做二进制翻译. 在这个模型中, 虚拟指令被动态翻译成底层硬件的物理指令. 程序执行后, 代码一段一段地被翻译. 如果出现分支, 一套新的代码指令将被引入和翻译. 这十分类似于缓存 *** 作, 指令块从内存移动到本地的快速缓存内存中执行.
近来Transmeta公司设计的Crusoe中央处理器使用了该模型. 二进制翻译由Code Morphing专利技术实现. 类似的一个实例, 全虚拟技术通过使用动态生成代码扫描来发现和重定向特权指令(解决特殊处理指令集中的问题).
虚拟化技术的类型
现在不只存在一种虚拟化技术. 事实上有多种方法可以使用不同层次的抽象来实现同样的结果. 本章介绍Linux上三种最常用虚拟化技术的优点和弱点. 业届有时使用不同的术语来描述同一个虚拟化技术. 为了保持连续性, 下面使用的术语参考了其它的术语.
虚拟化技术和游戏
一篇虚拟化技术的文章如果没有提到复合式大型电玩模拟器(MAME)就不是一篇完整的文章. MAME, 就如名字一样, 是一个能够模拟以往arcade游戏的机器模拟器(全部). 做一个补充, 整个机器是被虚拟的, 包括声音和图形还有控制硬件. MAME是一个非常棒的应用程序, 你也可以通过仔细阅读源码来了解它是如何实现的.
硬件模拟器
无可否认, 最复杂的虚拟化技术是硬件模拟器. 在这个方法中, 首先在主机系统上创建硬件VM, 然后模拟硬件的功能, 如图1显示:
图1. 硬件模拟器: 使用VM模拟需要的硬件
正如你可能猜到, 硬件模拟器的主要问题是速度极慢. 因为每一个指令在底层硬件都需模拟, 所以速度慢了100倍. 高保真模拟还包含了循环校验, 用于模拟CPU的管道和缓存行为, 实际速度会慢了1000倍.
硬件模拟有自己的优点. 比如, 使用硬件模拟, 你能够在基于ARM处理器的主机上模拟运行基于PowerPC未经任何修改的 *** 作系统. 你甚至能在每个不同模拟处理器上运行多个虚拟机.
模拟器和开发
硬件模拟器最有意思的一个应用是firmware(固件)和硬件协作开发. firmware开发人员无需等待最新硬件的推出, 他们可以使用目标硬件的虚拟机来验证实际代码中的许多概念.
全虚拟化
全虚拟化(Full virtualization), 也称为原始虚拟化技术, 是另一种虚拟化方法. 该模型使用虚拟机协调客户 *** 作系统和原始硬件(见图2). 这里"协调"是一个关键词, 因为VMM在客户 *** 作系统和裸硬件之间用于工作协调. 一些受保护的指令必须由Hypervisor(虚拟机管理程序)来捕获和处理. 因为 *** 作系统是通过Hypervisor来分享底层硬件.
图2. 全虚拟化: 使用Hypervisor分享底层硬件
全虚拟化的运行速度要快于硬件模拟, 但是性能方面不如裸机, 因为Hypervisor需要占用一些资源. 全虚拟化最大的优点是 *** 作系统没有经过任何修改. 它的唯一限制是 *** 作系统必须能够支持底层硬件(比如, PowerPC).
老机器上的Hypervisors
一些老的硬件如x86, 全虚拟化遇到了问题. 比如, 一些敏感的指令需要由VMM来处理(VMM不能设置陷阱). 因此, Hypervisors必须动态扫描和捕获特权代码来处理问题.
半虚拟化
半虚拟化(Paravirtualization)是另一种类似于全虚拟化的热门技术. 它使用Hypervisor(虚拟机管理程序)分享存取底层的硬件, 但是它的客户 *** 作系统集成了虚拟化方面的代码. 该方法无需重新编译或引起陷阱, 因为 *** 作系统自身能够与虚拟进程进行很好的协作.
图3. 半虚拟化: 通过客户 *** 作系统分享进程
上面提到过, 半虚拟化需要客户 *** 作系统做一些修改(配合Hypervisor), 这是一个不足之处. 但是半虚拟化提供了与原始系统相近的性能. 与全虚拟化一样, 半虚拟化可以同时能支持多个不同的 *** 作系统.
*** 作系统级的虚拟化
最后一个我们需要了解的虚拟化技术是 *** 作系统级的虚拟化(Operating system-level virtualization), 它使用不同于上面的虚拟化方法. 该技术在 *** 作系统之上虚拟多个服务器, 支持在单个 *** 作系统上简单隔离每一个虚拟服务器(见图4).
图4. *** 作系统级的虚拟化: 隔离单个服务器
*** 作系统级的虚拟化需要修改 *** 作系统内核, 它的优点是具有原始主机的性能.
为什么虚拟技术如此重要?
在了解当今主流的linux虚拟化技术之前, 我们先来看虚拟化技术的优点.
从商业角度来看, 使用虚拟化技术有非常多的原因. 不过大多是用于服务器加固. 简单来说, 如果你能够在单个服务上虚拟多个系统, 这样少数的几台计算机显然能够节省耗电, 空间, 冷却和管理开支. 考虑到确定服务器利用状况的困难, 虚拟化技术支持动态迁移(Live Migration). 动态迁移允许 *** 作系统能够迁移到另一台全新的服务器上, 从而减少当前主机的负载.
虚拟化技术对开发人员来说 也非常重要. Linux内核占用了一个单一的地址空间, 这意味内核或任何驱动程序错误都能导致整个 *** 作系统停止工作. 而通过虚拟化你可以运行多个 *** 作系统, 如果其中一个系统由于错误而宕机, Hypervisor和其它的 *** 作系统不会受到任何影响. 这对调试内核来说就如同调试用户空间程序一样.
Mark Shuttleworth在十几年前发起了Ubuntu inux项目,现在他在Canonical(一家提供Ubuntu支持服务的公司)主管战略和用户体验。他认为新一轮的服务器虚拟化浪潮与前一轮不太相同。在他的指导下,Canonical和其他的Linux机构一样,在其发布版本中先是Xen Hypervisor,接着是KVM然后继续支持Docker,成功地赶上了虚拟化的几轮潮流。当Eucalyptus是用的可计算云控制器时该公司成为排头兵,而当业界开始支持另一个开源项目- OpenStack而且OpenStack做为Linux的首选被部署到多个公有云上时,他们也迅速地转向OpenStack。Docker及其软件容器方式完全类似于虚拟化并且让云计算服务商为之癫狂,但是让Shuttleworth兴奋的是另一种称为Linux容器 (缩写为LXC)的技术及与之相应的称为LXD的Hypervisor。LXD是由Canonical开发的一个后台进程来管理这些容器并且提供了或多或少与开源的Xen及KVM、微软的Hyper-V或者VMware的ESXi这些服务器虚拟化Hypervisor类似的功能。
Shuttlworth向The Next Platform表示:“我们相信这是十年来对Linux虚拟化最大的突破,你可以看到我们对此是多么兴奋”。
LXC容器的想法和初期的工作都是由Google完成的,容器化应用程序已经在其基础架构上运行了超过十年时间,而且据说每天会启动超过20亿的容器。Canonical和其他大约80个组织已经开始致力于LXC的商业化,因为LXC最初并不是一个对用户很友好的技术。商业化是为了让其具有常见服务器虚拟化的观感和体验,尽管它使用的是非常不同且简化的技术。
“对于容器,很多人并不了解的是我们用来配置容器的系统其实可以用很多种方法来做虚拟或者模拟”,Shuttleworth解释说”有时你希望模仿看起和Docker类似的东西,而有时你又想模拟其他的东西。就LXC而言,我们想要创建容器的途径是创建假想的主机,而不是运行 *** 作系统的主机或者构成一个 *** 作系统的所有进程。这与Docker所作的完全不同,虽然它们都使用相同的底层原语,但是创建了不同的的东西。LXC的宗旨是不借助硬件虚拟化来创建虚拟机“
说起Docker,它在早期是基于LXC的但是现在它有了自己的抽象层,它更像一个运行在文件系统之上的单个进程,就好比你启动了主机但并没有运行 Init和所有构成 *** 作系统的进程而是直接运行数据库或者其他的东西,然后在一台主机上启动多个容器并把它们一起置于其中。通过LXC及其LXD守护进程,Canonical希望保持拥有一个完整Debian、CentOS、Ubuntu或其他Linux *** 作系统的感观。
“在LXC 1.0中,常见的情景是程序员说:“给我创建这个容器”。现在我们做法接收代码然后将其纳入LXD守护进程来管理,因此并不需要由程序员去创建每一个容器,我可以拥有上百个虚拟机并且与LXD守护进程进行通信来进行统一管理,因此我所拥有的虚拟机集群与你使用VMware ESXi hypervisor所构建的类似。把LXC打包到一个守护进程中就使得它变成了一个hypervisor。什么是ESXi?它基本上是一个 *** 作系统,你可以通过网络跟它通信并且让它给你创建一个虚拟机。通过LXD,你可以跟一个运行LXC的主机说给我创建一个运行CentOS的新容器。这成为一个集群的导引机制。”
LXD也提供了另一个重要功能:它是运行的在两台不同物理主机上的一个软件,从而使得LXC实例能够在主机间在线地迁移。
程序员都追求简洁而且他们喜欢保持事物有序和整洁。在某种程度上,只是因为硬件虚拟化的成本很高就不得不把程序部署到多个主机上已经成了一个痛点。现在,你可以快速地在一台主机上运行多个程序而没有这些开销并且始终保持他们的原始状态和隔离。
本周,Canonical发布了首次包括LXD hypervisor的LXC 2.0 beta版本。在本月将要发布的Ubuntu Server 15.10的更新中就包括这两个组件,而Canonical也通过统一步骤把LXC 2.0反推入Ubuntu Server 14.04 LTS(LTS是Long Term Support的缩写)的服务器版本。LTS版本每两年发布一次而且具有五年的支持生命期。由于它的稳定性有保证,所以70%的客户都在生产环境中运行 Ubuntu服务器的LTS版本。据Shuttleworth说,包含LXD hypervisor的LXC 2.0生产级别版本将在明年亮相,根据命名方案的建议可能就在二月或者三月最迟到4月就与新的企业级版本 – Ubuntu Server 16.04 LTS一同发布。负责Ubuntu产品和战略的Dustin Kirklan对TheNext Platform说,从下一个LTS版本开始,在每一个Ubuntu Server中就会缺省安装LXC和LXD组件,这样每个主机都可以运行几十到几百个容器 –IBM在最大的使用POWER处理器的服务器上甚至可以运行数千个容器。
相比于依靠硬件虚拟化的常规虚拟机,LXC容器具有两个巨大的优势:一台主机上可以打包的容器数量和这些容器的启动速度。尽管为了在一台硬件上用不同的容器运行不同的Linux需要一些额外的工作,但是由于LXC其实就是用Linux运行Linux,所以不需要虚拟什么。
“这在性能方面前进了一步,而在密度方面的改进则是巨大的”,Shuttleworth无不得意地说:“而这对于低延迟、实时型的应用程序具有显著的改善。在云计算环境中这类事情都变得容易处理了,当然过去他们可不是这样。如果你的云平台运行了LXC,很快高性能计算可以搞定了、云计算平台上的实时计算也可以搞定了,而且如果你是一个需要低传输延迟的电信运营商的话,那么NFV(网络功能虚拟化)也可以搞定了。在这些需要巨大资金投入的领域,人们真的希望使用云计算和虚拟化,而LXC使其成为可能。这是非常令人振奋的”
Shuttleworth说LXC容器在密度方面可以达到诸如EXSi、Xen或KVM这类使用虚拟机的hypervisor的14倍,而且 LXC和LXD组合在开销方面却只占基于硬件虚拟化的Hypervisor的20%不到。对于空闲的负载而言,VM和LXC容器就和大多数VM和物理主机所作的一样大部分时间在等待。对于繁忙的VM而言,LXC容器则能够提供明显要好得多的I/O吞吐量和更低的延迟。因此,对于空闲的主机你专注于整合,而对于繁忙的主机你专注于吞吐量和延迟。而且由于Hypervisor和VM的特定开销可以释放出来用于实际工作,所以你可以得到大约20%的性能提升。
现在已经开始对LXC及LXD组合进行基准测试。在上周东京召开的OpenStack峰会上,Canonical LXD开发团队的Tycho Andersen展示了一些在虚拟化环境中的测试基准,其中一个是使用Hadoop TeraSort测试而另一个是对Cassandra NoSQL数据存储的压力测试。这两个测试中,主机运行的是在峰会期间发布的最新OpenStack “Liberty”云控制器和同样刚发布的Ubuntu 15.10. 15.10,它既有KVM也有LXD hypervisor和各自的虚拟机和容器。这些服务器配备了24核和48GB内存,一个控制器负责管理OpenStack而其他三台用作基本的计算节点。
在TeraSort测试开始的时候,在三台主机上LXC和KVM的表现基本一致,但是当OpenStack/Hadoop集群中的主机数量随着数据集的规模增长后,两种不同的虚拟化手段在性能方面的差异开始显现。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)