没有合适的资源?快使用搜索试试~ 我知道了~
首页Xen和虚拟化技术学习指南
Xen和虚拟化技术学习指南
需积分: 9 11 下载量 131 浏览量
更新于2023-03-03
评论
收藏 77KB DOC 举报
现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机(VM: virtual machines),并且在每个虚拟机上各自运行单独的操作系统实例。这直接导致了虚拟机技术发展的又一个春天。在本文中,我们提出了Xen,一个高性能的用于资源管理的虚拟机监视器(VMM: VM monitor)。Xen能够支持的应用比如:server consolidation,co-located hosting facilities,distributed web services,secure computing platforms[12,16]和application mobility。
资源详情
资源评论
资源推荐
Xen 和虚拟化技术学习指南
1. 引言
现代计算机具有足够强大的能力来利用虚拟化技术支持多个虚拟机(VM: virtual machines),并
且在每个虚拟机上各自运行单独的操作系统实例。这直接导致了虚拟机技术发展的又一个春天。在本文中 ,
我们提出了 Xen,一个高性能的用于资源管理的虚拟机监视器(VMM: VM monitor)。 Xen 能够支持
的 应 用 比 如 : server consolidation , co-located hosting facilities , distributed web
services,secure computing platforms[12,16]和 application mobility。
成功地对一台机器进行划分,使它能够支持多个操作系统的并发执行,这个过程具有很多的挑战。
首先,虚拟机必须是彼此相隔离的:如果一个虚拟机的执行会影响另一个的性能,这是不可以被接受的。
这一点在操作各个虚拟机的用户相互间并不信任的情况下显得特别重要。其次,它必须支持多种多样的不
同操作系统以提供给各种异构(heterogeneity)的流行应用的支持(//这里的异构指的是应用开发依托
的操作系统不同,因此在实现上也就有很大差异,使得应用并不能够跨平台移植,因为 Xen 不需要对应
用程序进行修改,那么它就必须支持各种常用的操作系统;所谓流行的应用,就是那些大家常用的、必需
的应用)。第三,由虚拟化技术引入的性能开销必须要小。
Xen 操控(//host:操作和控制)的是常用的操作系统,但是需要对操作系统中的某些相关部分进
行一些修改。在本文中描述和评估的 Xen 原型系统能够支持多个我们研发的 XenoLinux guest OS 实例
的并发执行;每个实例都给出了和非虚拟化情况下的 Linux 2.4 中相同的应用二进制接口。目前,我们对
Windows XP 到 Xen 的移植还没有完全完成,但是已经能够运行简单的用户空间进程。移植 NetBSD 的
工作也在进行中。
Xen 使得用户能够 动态 地实 例化 一个 操作 系统 以执 行他 们需 要的 应用 。在 XenoServer 项目
[15,35]中,我们在 ISP 或者 Internet exchange(//布置在这些场合中经济划算而且又具有战略意义
的地方)的标准服务器硬件上配置了 Xen。我们在启动一个新的虚拟机的时候需要执行许可控制
(admission control),希望每个虚拟机能够以某种方式为它需要的资源付出代价。我们在其它文章中
讨论过我们在这个方向上的思路和方法[21];现在这篇文章则将焦点关注于虚拟机。
现在有一些方法用于构建能够在共享的机器上操控多个应用和服务器( //server:这里提到的
server 应该是大规模应用的意思,比如数据库服务器)的系统。也许最简单的方法就是部署一个或多个
运行着标准操作系统(如 Linux 或者 Windows)的主机,然后允许用户们安装文件和启动进程— 应用间
的保护是由传统的操作系统技术提供的(//这里提到的做法,就是类似并行机性质的,各个节点都是独立
的 主机 , 但 是一 个 应用可 以 在多 个 节 点 上 面并 行 执行) 。 实 验显 示 : 由于 要 针 对各 个 脱 节( //
supposedly disjoint:逻辑上脱节,指的是应用不具有连贯性/兼容性,所以针对每个应用都要单独配置
一次,如果能想办法将前后有关联的应用放在一起执行,可以大大减少相关的开销,如配置开销,通信开
销等等)的应用进行复杂的配置,这些配置过程导致的交互行为会使系统管理任务迅速成为时间消耗巨大
的任务。
更重要的是,这样的系统不能够充分地支持性能隔离;某个进程的调度优先级,存储要求,网络通
信量和磁盘访问等等特征都会影响到其它进程的性能。如果是在资源供应充足而且用户群体是限定(比如
计算网格或者 PlanetLab 平台实验)的情况下,这个系统还是可以接受的。但是当资源是供不应求的时
候,或者用户间不相协作(//uncooperative:不相协作,比如用户间的需求有冲突,那么一定会互相影
响的)的时候就不行了。一个解决这个问题的方法是改进对操作系统性能隔离的支持。这已经在
resource containers,Linux/RK,QLinux 和 SILK 中被或多或少地实现了。这些方法中存在着一个难
点是难以确保所有的资源都能够正确地分配给有相应资源需求的进程。例如,缓冲区 cache 或者存储页
面的替换算法导致的在应用间的复杂的交互行为( //比如存储页面替换的时候,某个进程的页面替换序列
会干扰到其它进程的,要免除这个影响就需要有复杂的机制用于进程间的协调)。这就是存在于操作系统
中的“QoS 干扰问题(QoS crosstalk)”。在低层采用多路执行技术能够缓解这个问题带来的影响,这已
经在 Exokerne 和 Nemesis 操作系统中得到证明。在这些操作系统中,任务间无意识的或者不受欢迎的
交互行为被最小化了。
我们使用了同样的基本方法来构建 Xen。Xen 就是以整个操作系统的粒度复用物理资源,它能够提
供在操作系统间的性能隔离。相对于进程级的资源复用,Xen 要允许一定范围内的 guest OS“和平”共存,
而并非去指定一个特殊的应用二进制接口(//如果限定了应用二进制接口,就意味着只能支持某个特定的
操作系统)。为了获得这种灵活性就必须付出一些代价 — 无论是在初始化过程(比如, boot 和 resume
与 fork 和 exec 的比较)中,还是在资源消费上,运行一个完整的操作系统与运行一个进程相比分量都要
重得多。
为了达到我们的能够支持多至 100 个被操控的操作系统实例的目标,我们认为这些代价是值得付出
的。付出这些代价后获得的系统允许单个用户在资源受控的形式下,直接运行那些不需要修改的二进制代
码或者二进制代码集合(例如,后端为 PostgreSQL 的 Apache 服务器)。更进一步的,因为用户能够
动态地精确创建他们的软件所需要的执行环境,所以这个系统也就提供了在非常高的层次上的灵活性。另
外,在各种服务和应用间的配置交互也是可以避免的(例如,每个 Windows 实例都有它们自己的寄存器
文件)。
本文的余下部分是这样组织的:第 2 部分解释了我们的虚拟化方法和 Xen 的工作概况。第 3 部分描
述了我们的设计和实现的关键特征。第 4 部分给出了使用业界标准的测试程序评估运行在 Xen 上的
XenoLinux 与单独的 Linux,VMware Workstation 和用户模式 Linux(UML)的性能比较结果。最后
的第 5 部分讨论了未来的工作并作了总结。
2. XEN:方法和概述
在传统的 VMM 中,虚拟硬件的功能是与底层机器上的真实硬件完全相同的。这种“完全虚拟化”
(full virtualization)的方法最显而易见的好处在于操作系统可以不经任何修改就直接在虚拟硬件上运
行,但是它也有很多缺点。特别是针对那些当前被广泛应用的 IA32(或者称作 x86)架构,这种方法带
来的缺陷更是不容忽视。
x86 架构的设计从来就不支持完全的虚拟化。如果要正确实现 x86 架构虚拟化,VMM 就必须能够
对某几条特定的“超级指令(supervisor instruction)”进行操作。但是,如果在没有足够特权的情况下
执行这些超级指令会导致“沉默的失败(//fail silently:如果特权级不够,那么会直接导致执行失败,不
会产生其它响应)”,而并非产生一个便于我们使用的陷阱(trap)。
另外,将 x86 架构中的 MMU 进行有效的虚拟化也是一件很困难的事情。这些问题是可以被解决的,
但是在解决的同时必须要付出操作复杂度增加和系统性能降低的代价。VMware ESX Server[10]需要动
态地重写那些被 VMM 操控的机器码部分,在其中有可能需要 VMM 干涉的地方插入陷阱操作(//在什么
地方插入陷阱操作,是在程序运行起来后才知道的,所以需要动态地重写相关代码)。因为务必要对所有
那些不能够引起陷阱的特权指令进行捕捉和操作,所以这种转换(//动态重写代码)要被应用于整个
guest OS 的内核(导致了相关的转换,执行和缓存等开销)。ESX Server 实现中采用的技术是建立系
统结构(system structure)(比如页表)的影子版本,通过为每一次“更新”操作设立陷阱来解决虚拟页
表和物理页表的一致性问题(//具体细节还是要看 ESX Server 的说明)。但是在处理“更新密集”型的操
作(如创建新的应用进程)的时候,该方法会带来高昂的开销。
除了 x86 架构非常复杂的原因,还有一些其它方面的争论反对“完全虚拟化”。其中值得一提的是,
被操控的操作系统在一些情况下需要接触到真实的资源。例如,提供真实时间和虚拟时间以允许 guest
OS 能够更好地支持“时间敏感”型的任务,还可以正确地操作 TCP 超时和 RTT 估算;给出真实的机器地址
以允许 guest OS 能够利用超级页(superpage)或者页染色(page coloring)等方法改进性能。
我们提出的虚拟机抽象能够避免完全虚拟化带来的种种缺陷。这种虚拟机抽象和底层硬件相似却并
不完全相同,因此被称之为“准虚拟化”(//paravirtualization:或者翻译为半虚拟化?后面译文沿用准虚
拟化)方法。这种方法虽然需要对 guest OS 进行一些改动,但是它能够改善性能。还有特别重要的一点
需要说明:准虚拟化方法不会对应用二进制接口(ABI)进行修改,因此用户也就不用修改那些在 guest
OS 上执行的应用程序。
我们进行的关于准虚拟化方法的讨论要遵循以下一些规则:
a.最基本的是要支持那些不经改动的应用二进制文件的执行,即用户不用对应用程序做针对 Xen 的
转换。因此我们必须虚拟化现有的标准 ABI 所需的全部体系结构特征。
b.很重要的一点是要支持完整的多应用操作系统。这就需要将在单个 guest OS 实例中的复杂的服
务器配置虚拟化(//例如,如果 guest OS 上配置了 ftp 服务,那么虚拟硬件就要打开相应端口)。
c.准虚拟化务必要有很高的性能。另外针对那些不协作(//uncooperative:这里的不协作是指硬件
架构不支持共享,所以才需要资源隔离)的机器架构,如 x86 架构,准虚拟化还需要能够提供很强的资
源隔离能力。
d.在协作(cooperative)的机器架构上,准虚拟化方法要能够完全地隐藏资源虚拟化带来的影响,
减少 guest OS 在正确性和性能上面临的风险。
请注意,我们在这里提出的准虚拟化的 x86 抽象的方法是与最近在 Denali 项目中提出的方法有很
大差异的。Denali 是为了支持数以千计的运行着网络服务的虚拟机而设计的。这些网络服务中绝大部分
是小规模的,不流行(//应用的不流行也就说明了运行该应用的环境比较少,所以只要针对这些相应的特
定环境作专门的虚拟化即可)的应用。与之相反的是,Xen 的设计最终要支持近 100 个运行着业界标准
应用和服务的虚拟机。由于设计目标的极大差异,我们不妨将 Denali 的设计选择和我们自己的设计规则
做一个有益的讨论。
首先,Denali 不需要关注现有的 ABI,因此他们的 VM 接口忽略掉了相关的架构特 征。例如,
Denali 并不完全支持 x86 的分段机制,但是这一点却是在 NetBSD,Linux 和 Windows XP 等操作系统
的 ABI 中都有提出并且被广泛使用。例如,线程库中经常会使用分段机制来寻址线程局部数据。
其次,Denali 的实现没有解决在单个 guest OS 中支持多个应用(application multiplexing)的
问题,也没有解决多地址空间的问题。应用被显式地链接到 Ilwaco guest OS 实例上,这么做在某种意
义上类似于之前在 Exokernel 中的 libOS[23]。因此每个虚拟机只能操控一个单用户单应用的没有保护
措施的所谓的“操作系统”。在 Xen 中,与之相反,每个虚拟机上能够操控一个真正的操作系统。这个操作
系统上能够安全地执行数以千计个不经改动的用户级进程。虽然 Denali 号称开发了一个虚拟 MMU 原型
能够对其在该领域有所帮助,但是我们没有看到公开的技术细节和评估报告。
再次,在 Denali 体系结构中,是由 VMM 执行全部的内存与磁盘间的页面调度的。这可能是与虚拟
层缺乏存储管理支持有关。由 VMM 完成页面调度是与我们的性能隔离目标相违背的:那些“有恶意”的虚
拟机可能会故意产生抖动行为,导致其它虚拟机的 CPU 时间和磁盘带宽被不公平地剥夺(//VMM 监控很
多 VM,各个 VM 上再跑操作系统,所以如果很多事情都放在 VMM 中做必然会影响到各个 VM;所以要
把一些事情放在上面的操作系统做来达到隔离性)。在 Xen 中,我们希望每个 guest OS 在其自己分配
到的内存空间和磁盘区域内执行它自己的页面调度(此前已经有 self-paging 的方法被提出)。
最后,Denali 为机器的全部资源虚拟了“名字空间”。这样的话,如果一个 VM 不能够“叫出”另一个
VM 下辖的资源的名字,那么该 VM 就不能够访问这些资源(例如,Denali 中的 VM 并不知道硬件地址,
它们只看得到 Denali 创建的虚拟地址)。与此相对,我们认为 hypervisor 中的安全访问控制已经足以
确保安全性;此外,就像之前讨论过的,当前在 guest OS 是否应该能够直接看到物理资源这一点上存在
着很热烈的关于正确性和性能的争论。
在后续的章节里,我们将描述 Xen 提出的虚拟机抽象,然后将讨论如何将一个 guest OS 作必要的
改动以适应 Xen。在这篇文章里我们定义了一些术语要提醒大家注意。例如,术语 guest OS 是指 Xen
能够操控的操作系统之一;术语 domain 是指一个运行中的虚拟机,在其上有一个 guest OS 在执行。
program 和 process 之间的区别和传统系统中的区别类似。我们称 Xen 本身为 hypervisor,因为它运
剩余13页未读,继续阅读
JimChen001
- 粉丝: 6
- 资源: 11
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- 27页智慧街道信息化建设综合解决方案.pptx
- 计算机二级Ms-Office选择题汇总.doc
- 单链表的插入和删除实验报告 (2).docx
- 单链表的插入和删除实验报告.pdf
- 物联网智能终端项目设备管理方案.pdf
- 如何打造品牌的模式.doc
- 样式控制与页面布局.pdf
- 武汉理工Java实验报告(二).docx
- 2021线上新品消费趋势报告.pdf
- 第3章 Matlab中的矩阵及其运算.docx
- 基于Web的人力资源管理系统的必要性和可行性.doc
- 基于一阶倒立摆的matlab仿真实验.doc
- 速运公司物流管理模式研究教材
- 大数据与管理.pptx
- 单片机课程设计之步进电机.doc
- 大数据与数据挖掘.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0