Larry Zhang's Blog

浅谈下一代的企业级虚拟化

VMware将虚拟化引入x86平台已经有10个年头了，虚拟化逐渐走向成熟，成为整个IT业界的新亮点。关于虚拟化的版本升级，我们可以看到IDC有如下的看法：

如果按照上图对虚拟化版本的定义，VMware已经远远走过了虚拟化2.0，已经走到了虚拟化3.0。目前我们有些竞争友商甚至还处在虚拟化1.0的阶段。

 一般来看，VMware根据自己的经验，将虚拟化分成三代，目前VMware已经进入到第三代的虚拟化：架构管理和高可用。具体细节见下图。

当然，具体到某个用户，VMware通过我们的用户部署总结，可以看到用户部署虚拟化的路线图如下。从该图可以清晰显示一般用户的部署虚拟化的规律，从小面积试用，到逐步扩展，最后走向基于虚拟化的数据中心架构，充分享受虚拟化带来的一系列好处。

为了更好理解虚拟化的功能模块，VMware将虚拟化分成如下的三个层次，到目前为止，VMware的产品已经很好覆盖了虚拟化的每个层次，最大限度帮助用户节约成本，提高效率。我们很多竞争友商还处于虚拟化平台构建阶段，仍然没有走向虚拟化架构。

VI3虚拟存储层最佳实践

为一个虚拟环境配置存储资源需要经过几个抽象层，用户需要将此视作一个堆栈以便按照完整的路径成功完成配置。用户首先会在存储阵列中看到多个关于存储资源配置方式的选项；接着会在 ESX Server 级别看到若干关于存储资源编址和配置方式的选项；然后在虚拟机级别又会看到多个决定虚拟磁盘分区和编址方式的选项。由于存储堆栈中这三层的每一层都存在多个配置选项，而且相互之间的区别并不明显，因此用户很容易搞不清楚实际存在怎样的虚拟到物理映射关系。本文的目的就是详细说明这些选项和相关术语，从而帮助用户理解这些选项之间的复杂关系。

存储虚拟堆栈概述

由于 ESX Server 能够对存储资源进行编址并为虚拟机提供虚拟磁盘，因此在引入存储虚拟设备之前就已经有几个混合的虚拟层了。即使没有实际的存储虚拟设备，这些存储虚拟层也有助于减轻管理工作、提高资源利用率（即，减少已分配但未使用的存储资源），以及提供更加灵活的配置选项。VMware 的虚拟机文件系统（Virtual Machine File System，VMFS）所带来的好处可以在虚拟环境中发挥很大的作用。

图 1 是一个简单示意图，显示了 Virtual Infrastructure 3 环境中虚拟机的存储技术堆栈的三个层。最下面的是存储阵列层，由多个物理磁盘（显示为逻辑磁盘）组成。存储阵列层的上面是操作系统层，在虚拟环境中被 ESX Server 所占据。这一层采用逻辑单元号（logical unit number，LUN）的方式对 VMFS 卷中的存储资源进行编址。堆栈的顶端由虚拟机层占据，这一层通过将 ESX Server 识别到的存储资源的一部分分配给虚拟机的虚拟磁盘来对存储资源进行编址。

配置存储阵列层

在存储阵列中，有多个用于配置存储资源的选项。通常，存储管理小组需要确定所需的 LUN 大小和保护级别。某些情况下，他们还会询问用户所需的性能级别。

RAID-1 和 RAID-5 是通常所提供的保护选项。还有一个选项是连接多个磁盘组成单个 LUN，也就是说该 LUN 将会占据多个磁盘并在这些磁盘上进行分散读写。大多数情况下，主机 OS（在本文中为 ESX Server）并不知晓为 LUN 所提供的 RAID 保护级别。主机 OS 也不知道逻辑 LUN 与其物理组件之间存在何种关系。

配置 ESX Server 层

在 ESX Server 系统中存储空间显示为带有 LUN 的卷，就网络连接存储而言，即 NFS 卷。ESX Server 会在发现一个 LUN 后将其当成一个存储目标来对待。此后，ESX Server 会将该 LUN 当作一个裸磁盘映射（raw disk map，RDM）的裸磁盘来进行编址，或者当作一个 VMFS 卷或一个多区域 VMFS 卷中的一个区域来进行管理。

作为一个 RDM 时，整个 LUN 通常由单个虚拟机（Virtual Machine，VM）进行编址，不能被分区或被当作多个虚拟机的分段来编址。要获得小于 LUN 容量的 RDM，方法之一是只对 LUN 的部分空间进行编址以便用于指定的 VM，但这样做会损失或浪费掉 LUN 的剩余空间。如果使用这种方法，当您有一个 100 GB 的可用 LUN，而 VM 仅需要一个 50 GB 的 RDM 时，该 LUN 的一半空间就会被浪费。为单个 VM 分配一个单独的 LUN（可通过为单个 VM 分配一个 RDM 或一个 VMFS 卷实现）就是我们所说的“隔离存储”。

作为 VMFS 卷的一部分时，LUN 会成为一种可以用作多个 VM 或多个 ESX Server 的合并/群集存储池的存储资源。这种配置（“合并存储”）是可集中管理且可按需增加容量的大容量存储池的一部分，因而可以提高存储资源的利用率和灵活性。图 3 显示了相对于隔离存储，合并/共享存储池的几点优势。

ESX Server 虚拟机将其虚拟磁盘文件存储在经过特殊格式化的逻辑容器（即数据存储区）中，数据存储区可以存在于不同类型的物理存储设备中。可以使用 Virtual Infrastructure （VI）Client 来创建数据存储区，数据存储区可以使用一个或多个物理设备上的磁盘空间。在 ESX 3.x Server 中，数据存储区可以是 FC 磁盘、iSCSI 磁盘、NFS 或 ESX Server 的本地磁盘。

图 4 显示了为 ESX Server 配置存储资源时可以进行的所有选择。如果使用本地存储，用户将无法利用启用 VMware Distributed Resource Schedule（DRS）和 High Availability（HA）所需的 VMotion 功能。然而，如果使用共享存储，用户可以从 VMFS、RDM 或网络连接存储（Network-Attached Storage，NAS）几个选项中进行选择。实际上，单个 ESX Server 经过配置可以同时访问位于这三种不同选项上的数据存储区。此外，如果使用的是 VMFS，用户还可以从 FC SAN 存储或 iSCSI SAN 存储中进行选择。

配置虚拟机层

通过创建虚拟磁盘（VMDK），用户可以将 ESX Server 识别到的存储资源的一部分分配给虚拟机，从而在虚拟机中实现存储资源的编址。用户可以通过编辑虚拟机设置（属性）分配一个新的磁盘或为现有磁盘分配更多空间。如果 RDM 是首选的访问方法，用户还可以选择指向一个现有的 RDM。使用现有的 VMFS 卷创建一个虚拟磁盘时，用户需要选择为该 VDMK 分配哪个数据存储区中的空间。对于要在群集中两个或两个以上 ESX Server 之间移动（例如通过 Vmotion 和 HA 功能移动）的虚拟机，群集中的所有节点必须都能识别到该数据存储区。

为了在虚拟环境中使用磁盘而对其进行识别和格式化的具体步骤因操作系统而异。另外，在客户操作系统级别，也有多种不同的方法可将已在底层进行了扩容的磁盘识别为大容量磁盘。这种配置超出了本文的讨论范围，在此不做介绍。

结语

在虚拟环境中配置存储需要综合考虑很多相互依赖的因素：有些是物理元素，有些是抽象元素。将不同的存储虚拟级别看成一个由多个互不相同的层组成、层与层之间线性关联（这种关联关系对于每个层来说未必可见）的堆栈，可以使设置过程变得简单明了。按照从存储阵列到 ESX Server 再到虚拟机的步骤执行操作，用户可以正确无误地完成虚拟存储配置。

在VMware Fusion里安装Windows虚拟机实录

张振伦,VMware大中华区技术总监

去年6月12日，VMware在美国正式发布了其首款面向MAC用户的产品：VMware Fusion 1.0，而这款产品也将在今年的8月份正式投放市场。为了让用户能够更深入认识VMware Fusion，特将VMware Fusion平台中安装Windows XP的过程步骤详细介绍如下。为了不显得突兀，在此首先列举了VMware Fusion 1.0的关键特性：

ü       无缝集成Windows和Unity：VMware Fusion通过Unity可以让我们直接在Mac台式机上运行Windows XP的应用，提供了完整的Mac键盘快捷键和在Mac OS X中的浏览功能。VMware Fusion启动调色板提供了对所有Windows应用的访问能力；

ü       自动集成Boot Camp：VMware Fusion自动侦测已经存在的Boot Camp安装，可以让 Mac OS X和Windows XP或Vista一起运行，不需要多余的配置；

ü       支持3D图像加速：该功能让我们可以直接运行DirectX 8.1的应用，直接从Windows XP虚拟机中玩DirectX 8.1的游戏；

ü       Mac最完整的硬件支持：VMware Fusion通过虚拟SMP来支持双核和双CPU的机器，也支持64位的操作系统，包括Windows Vista。VMware Fusion也支持Mac机器里最大的内存，可以运行尽可能多的虚拟机，增加我们的生产率；

ü       快照/备份：VMware Fusion可以使用快照功能来抓取和保存正在运行的虚拟机状态，让我们可以在虚拟机故障时快速回滚到原来的稳定状态；

ü       集成VMware Converter：我们可以在Windows PC里运行VMware Converter，然后迁移Windows机器到Mac平台上，作为虚拟机运行；

ü       广泛的产品兼容能力：无论是在VMware Server、VMware Infrastructure 3还是VMware Workstation里创建的虚拟机，都可以在Mac平台上运行；

ü       方便性：“电池直通”让我们可以在虚拟机里直接监控Mac机器里的电池寿命。任何非Mac虚拟机里都支持Mac SuperDrive CD和DVD的读写；Windows共享Mac机器的网络连接，可以在Airport/WiFi和有线网之间自由切换； 我们可从其他的虚拟机里同时查看Mac的环境。

下面我们就VMware Fusion里安装Windows XP虚拟机的过程实录。首先打开VMware Fusion窗口，打开虚拟机创建窗口，如下所示。然后点击按钮<New>新建虚拟机。

出现建立新虚拟机的向导窗口，如下所示。然后点击按钮<Continue>

出现操作系统选择向导窗口，如下所示。选择操作系统为Microsoft Windows，操作      系统版本为Windows XP Professional，然后点击按钮<Continue>

出现虚拟机命名窗口，如下所示。我们将该虚拟机命名为“Easy Install Demo”，      然后点击按钮<Continue>。

然后出现虚拟磁盘配置窗口，如下所示。默认状态下，虚拟磁盘建立的时候是很    小的文件，根据需要不断自动扩大。我们在此选择的是20GB的文件，这并非实际文    件的大小，而是虚拟磁盘能够利用的最大空间。我们在此选择8GB作为虚拟磁盘文     件的最大值，仅为示例。

在此，点击<Advanced disk options>高级磁盘选项，可以看见如下的三个选项：

ü      Allocate all disk space now：分配所有的磁盘空间给虚拟磁盘，选择此选项可以确保性能很好，但是会用光所有的磁盘空间。如果您不担心磁盘空间的浪费，可以选择该选项；

ü      Split disk into 2GB files：将磁盘分割成2GB的磁盘文件。如果要将虚拟机文件备份到CD或DVD上，或者复制到另外不支持超过2GB大小文件的文件系统时，只能选择此选项；

ü      Use an existing virtual disk：使用已经存在的Fusion虚拟机的文件。

在此演示中，我们上面的三个选项都保持默认值。然后按<Continue>按钮继续。

然后出现Windows Easy Install窗口，显示如下。输入Windows用户名、密码，同时输入Windows安装许可证。

另外，此处的<Enable File Sharing>打开，该选项可以允许Windows虚拟机直接访问Mac的根目录。

点击按钮<Continue>。

出现安装完成的窗口，如下所示。然后选择使用操作系统安装盘还是操作系统安装镜像文件进行Windows安装。这里选择从光盘进行直接安装，然后按<Finish>按钮继续。

紧接着出现如下的Windows安装窗口，可以看到Windows XP在虚拟机里安装时的许可证激活提示，按<OK>按钮。

接下去我们可以看见虚拟机启动，VMware Fusion里的Windows Easy Install向导可以自动完成以下所有的安装，整个过程大概需要45分钟或更多的时间。

下面开始出现我们熟悉的Windows XP Professional安装窗口，只需要根据屏幕提示进行安装即可。Windows Easy Install向导可以协助完成大部分的安装工作。

配置Windows里面的用户信息，窗口如下所示。

启动已经安装的Windows XP，进行最后的配置工作。显示的窗口如下：

Windows Easy Install向导会自动安装VMware Tools。VMware Tools优化了显卡的显示功能，并且加入了Balloon Driver等内存管理功能，可以显著改善虚拟机的性能。点击<Next>往下一步。

最后，配置和调整显示比例，从而完成了Windows XP Professional的全部安装工作，最后的一个窗口如下。

VMware单个虚拟机的故障监控和重置

自从发布VI3 3.5以来，VMware HA开始实验性支持单个虚拟机故障的监控，并且基于你预先设置的方式的进行故障处理，这个新的模块称为虚拟机故障监控模块。虚拟机故障监控可以处理来宾操作系统的故障。

关于虚拟机故障监控模块

由于虚拟机故障监控是实验性支持，因此默认是关闭的。如果你启用了该功能，VMware HA将开始检测虚拟机是否可用。VMware HA通过VMware Tools收集到的心跳信息来决定虚拟机的可用性。

每一台虚拟机中的VMware Tools每秒钟发送一次心跳信息，虚拟机监控模块每20秒检测一下心跳。如果心跳在用户指定的时间内没有收到，虚拟机监控模块就认为该虚拟机发生故障，就会重置该虚拟机。

虚拟机故障监控模块可以自己分辨出来是虚拟机打开，但是心跳中止；还是虚拟机关闭、迁移走了。它也可以区分是虚拟机太忙导致心跳丢失还是真的发生了虚拟机故障，因为虚拟机故障监控模块可以判断出在特定时间段心跳的次数为零。

当然，虚拟机故障监控模块工作的基础是该来宾操作系统里已经安装了VMware Tools，没有安装VMware Tools的虚拟机，该模块无法监控。

使用虚拟机故障监控模块

你可以为整个群集配置虚拟机监控模块，当然，该虚拟机群集必要先启用VMware HA，否则没法进行监控。当然，你没法创建一个支持虚拟机故障监控的群集，你要先创建一个普通群集，然后更改它的配置。

具体如何来配置虚拟机故障监控模块呢？下面是具体的步骤：

1.      登陆到VMware VI客户端，在Inventory栏，选择需要监控的群集，点击鼠标右键；

2.      选择Edit Settings；

3.      如果该群集没有启用VMware HA，在General选择Enable VMware HA；

4.      在接下来选择Advanced Options

5.      在出现的选项里输入合适的值，然后点击OK。

该页目前支持的选项解释如下：

如果你没有进行任何配置，说明das.vmFailoverEnabled仍然是false。如果虚拟机故障监控已经启用，这些选项你都没有进行配置的情况下，所有的选项都会使用默认配置。

配置实例

下面的实例是某个虚拟机故障监控的配置情况。

该配置说明：

1.      在Virtual Center Server上已经启用了虚拟机故障监控模块；

2.      如果60秒或更长时间内不能收到该群集的心跳，VMware HA将重置该虚拟机

3.      每台虚拟机允许240秒时间来启动稳定其心跳。该时间用来进行虚拟机启动和VMware Tools重置；

4.      如果一天中虚拟机故障达到或超过3次，VMware HA就不再进行虚拟机重置。

当然，目前虚拟机故障监控模块仍然处于试验阶段，因此没提供明确的系统管理员通知。

－微软的下一代虚拟化产品Hyper-V 2.0

Bink Nu本周所写的博文很好的介绍了Hyper-V的未来，Hyper-V已经发布了4个月了，很多人都开始谈论（某些人已经开始期待）Hyper-V 2.0。根据最新的报告和微软公开的网站介绍，Hyper-V 2.0将在2010年随着Windows Server 2008 R2一起发布。对不起，微软的粉丝们，你必须再次漫长等待。从Hyper-V 1.0发布时多次延期，我相信你已经习惯等待了。下面是微软确认的Hyper-V 2.0的新功能列表，同时也表明微软推出这些功能多么晚。

• 微软Live Migration – 是VMware VMotion的部分，VMware从2003年将VMotion推向市场（微软落后7年)
• 集群文件系统 －是VMware VMFS的部分，VMware从2001年推出VMFS（微软落后9年）
• 32颗逻辑处理器 －VMware从2006年开始支持（微软落后4年）
• 虚拟磁盘热添加 －VMware在2006年从ESX 3上开始支持（微软落后4年）
• 虚拟磁盘热卸载 － VMware今天不支持（下一代的产品将提供）
• SLAT (内存虚拟化) – VMware今天已经提供对AMD RVI和Intel EPT 的支持(微软落后2年)
• 动态内存 － VMware从2001年就开始支持(微软落后9年)

这说明了微软落后于VMware目前正在销售的技术5到6年。当然，如果你愿意为今天VMware已经拥有的技术再等两年，你将因为没有及时采用虚拟化而浪费了你的金钱。并且谁能说微软不会在最后关口舍弃某些你在等待的很重要的功能呢？就象之前微软舍弃了很多功能一样。

重要的是，你不需要等待产品路线图，所有微软产品路线图上的功能在今天的VMware产品VMware ESX上都已经具备，并且VMware的产品已经获得了成千上万的用户的验证。建议今天你就可以下载VMware的测试版开始使用。

本文译自：http://www.mikedipetrillo.com/mikedvirtualization/2008/10/hyper-v-20---mi.html

我们一定记得：功能全面的“瘦客户”PC机曾经风靡一时，一度成为桌面计算中的主力军，纵横驰骋在各种应用领域，在多种情况下都实现了良好的性价比。但很多时候瘦客户机却不是理想的解决方案，这也是近些年瘦客户PC机离家出走的原因所在。我们可以轻松罗列常见瘦客户PC机的“四宗罪”。

瘦客户PC机的“四宗罪”

1.  难于管理：PC机硬件和用户分布广泛，而且用户在访问桌面环境时的位置无关性要求越来越高。在这种情况下，集中化的PC机管理极其困难。而且PC机桌面的标准化难度可谓路人皆知，其中的原因就在于PC机硬件的多样化，再加上用户也需要经常修改桌面环境。

2.  高昂的总体拥有成本：虽然PC机硬件成本相对较低，但却常常抵不过高昂的PC机管理与支持成本。软件部署、更新以及打补丁都属于随时都要进行的PC机管理工作。由于需要针对各种各样的PC机配置进行部署测试与审核，这种管理实属劳动密集型工作。缺乏标准化，因此需要支持人员亲临现场来提供故障处理支持，同样也提高了支持成本。

3.  难于实现数据保护与保密：如何确保PC机上的数据能够成功得到备份，如何在PC机故障或者文件丢失时能够对这些数据进行恢复，这个问题实在棘手。即使数据成功地得到了备份，PC机的失窃风险仍然会威胁到重要数据的保密性。

4.  资源利用效率不高：PC机本质上具有分布性，难于通过资源共享的方式来提高利用率、降低成本。这样PC机的利用率一般都不到百分之五——远程办公室要求重复性配置桌面基础设施，并且移动办公人员可能还需要复杂的远程桌面解决方案。

到目前为止，世界上的公司 PC机大约有 5.5 亿台。这个数字正在以每年约 10% 的速度递增。基于服务器的计算（终端服务、虚拟桌面和刀片 PC）约占这一市场的 1-2%。

为了找到很好的瘦客户PC解决方案，很多公司进行了探索，推出了一些相关的解决方案，包括终端服务、刀片PC、Web方式或VMware VDI等。通过下表，可以清晰理解各种PC解决方案的优缺点：

通过以上的表格，VMware VDI(Virtual Desktop Infrastructure)解决方案脱颖而出，成为推动瘦客户机荣归故里的巨大动力。

VDI让瘦客户机荣归故里

由于传统解决方案的各种缺点，越来越多的企事业单位都在针对多种情况来评估并实施瘦客户机的替代方案。尤其是企业单位出于资源集中化以及提高桌面计算基础设施可管理性等目的，已经尝试在服务器系统上存放桌面镜像。而采用虚拟桌面基础设施建立起基于服务器的桌面解决方案，则正在逐渐解决台式机面临的种种挑战，同时还实现适用性、可管理性、总拥有成本以及灵活性的最优化。借助于虚拟桌面基础设施，在采用ESX Server软件实现了虚拟化的服务器上，可通过虚拟机来驻留完整的桌面环境——操作系统、应用程序和配置。管理员可采用VMware VirtualCenter，在自身的环境中集中管理所有虚拟机。最终用户则可从PC机或者瘦客户机上使用远程显示软件来访问自身的桌面环境。

采用虚拟桌面基础设施，管理员可以：

l        建立起与硬件无关的桌面环境

l        在同一系统上同时运行多台虚拟机，且系统上虚拟机相互独立、隔离

l        借助于模板，只需几分钟时间即可设立新的虚拟机

目前，业界最为领先的虚拟化巨头VMware也因此成为最为领先的虚拟桌面解决方案供应商之一：牵着瘦客户机的手，大踏步走向瘦客户机的新辉煌。

虚拟桌面解决方案的种种好处

有大量的客户已经采用VMware虚拟桌面基础设施实现了桌面解决方案，并从中看到了种种好处，例如：

1.       提高可管理性：通过VMware VirtualCenter可实现桌面环境设立、配置、资源管理和工作负荷管理的集中化与简单化。

2.        简化部署：借助于模板，桌面管理员只需几分钟的时间即可部署出新的、与硬件无关的标准化桌面虚拟机，并且可在部署过程中使用更多的自动化操作。

3.        更高的灵活性：用户可从一台客户机访问多个桌面环境，并可从任意一台连接完毕的客户机上访问自己的桌面环境。管理员瞬间即可对那些当前未处于使用状态的桌面环境完成归档和丢弃操作，而且从中回收的资源马上就能得到重用。

4.        提高数据保护能力：管理员可采用现有的数据中心备份过程来确保可靠的桌面备份。虚拟机的硬件无关性大幅度简化了桌面恢复。而且所有数据都驻留在数据中心，这样数据安全保障也得到了简化。

5.        提高资源利用率：通过在一台服务器上运行多个桌面环境，客户可有效地实现硬件资源的归集共享，并且可灵活地实现计算资源的重用以及桌面环境计算资源的动态分配。

6.        降低成本：虚拟桌面基础设施可实现桌面计算资源的集中化以及桌面硬件的标准化，这样企业即可降低桌面支持复杂度以及桌面支持成本。

以服务器为基础并采用VMware虚拟桌面基础设施建立起的桌面解决方案，可谓传统瘦客户机的真正换代技术，将为企事业单位带来更大的可管理性、更低的桌面总体拥有成本、更高的利用率以及对关键数据更好的保护。创建了“安全计算环境”，VMware VDI将让您：

1.      包含一个完整的系统：操作系统、应用软件和数据，这些可以从未管理和非保密“主机”计算环境中隔离；

2.      在任何工业标准 PC 上不做任何修改就能够运行；

3.      在一个完全安全的受控环境内执行 IT 策略。

美国时间12月11日，VMware公司正式发布了Virtual Infrastructure 3 3.5，从而VMware的虚拟架构正式过渡到下一代VI3 3.5。关于VI3.5的新特性，可以参考我的另外一篇文章，地址为http://virtualman.blog.51cto.com/200540/52355。而您也可以从VMware的官方网站正式下载3.5的测试版，下载地址http://www.vmware.com/download/vi/。具体可以下载的build版本如下图所示：

VI3 3.5测试模式无需License

为了方便用户的测试，VMware从3.5开始引入了测试模式，也就是：如果您仅仅想测试VMware VI3 3.5，安装的时候不需要输入任何的License，您就拥有了60天的免费试用期。安装好VI3 3.5后的60天之内，VMware的产品可以正常运行，所有的功能和服务都可以正常运作。

当然，如果您选择了安装license，而您的license文件有问题或者没有license文件，您仍然可以将VMware VI3 3.5重新更改回测试模式。

ESX上如何启用测试模式？

1.      首先，从Virtual Center里，转到“Configuration”标签，转到“Licensed Features”；

2.      点击“Edit…” 到“License Source”，如下图所示。在对话框里，选择 “Use Evaluation Mode”；

3.      当你选择了测试模式后，会跳出一个对话框提示您还有多少天将要过期，如下图所示；

4.      至此，您已经将ESX Server的运行模式更改为测试模式了。

Virtual Center如何启用测试模式？

1.      从下拉菜单Administration > VirtualCenter Management Server Configuration…，在“License Server”里，选择“Evaluate VirtualCenter Server”；

2.      您就可以看见如下的弹出窗口…

3.      接着您就可以看见右上角的地方现实还剩余的测试天数，如下图所示。

4. 至此，您已经将VirtualCenter的运行模式更改为测试模式了。

－半虚拟、全虚拟和硬件辅助虚拟化

从1998年开始，VMware创造性的将虚拟化引入x86平台，通过二进制翻译（BT，Binary Translation）和直接执行的模式，让x86芯片可以同时运行不同的几种操作系统，并且确保性能、稳定性和安全性。 从那时起，数以万计的企业已经从虚拟化中获得了极大的收益。但是，关于虚拟化的几种实现方式，引起了很多误解，为此，希望通过此文澄清几种虚拟化道路的优缺点，以及VMware公司对几种虚拟化之路的支持情况。图1总结了x86虚拟化技术的进展情况，从VMware的BT最近的内核部分虚拟化和硬件辅助虚拟化。

1. x86虚拟化概览

所谓x86服务器的虚拟化，就是在硬件和操作系统之间引入了虚拟化层，如图2所示。 虚拟化层允许多个操作系统实例同时运行在一台物理服务器上，动态分区和共享所有可用的物理资源，包括：CPU、内存、存储和I/O设备。

图2. x86架构上的虚拟化层

近年来，随着服务器和台式机的计算能力急剧增加，虚拟化技术应用广泛普及，很多用户已经在开发/测试、服务器整合、数据中心优化和业务连续性方面证实了虚拟化的效用。虚拟架构已经可以将操作系统和应用从硬件上分离出来，打包成独立的、可移动的虚拟机，从来带来了极大的灵活性。例如：现在可以通过虚拟架构，让服务器7x24x365运行，避免因为备份或服务器维护而带来的停机。已经有用户在VMware平台上运行3年而没有发生任何的停机事件。

对于x86虚拟化，有两种常见的架构：寄居架构和裸金属架构。寄居架构将虚拟化层运行在操作系统之上，当作一个应用来运行，对硬件的支持很广泛。相对的，裸金属架构直接将虚拟化层运行在x86的硬件系统上，可以直接访问硬件资源，无需通过操作系统来实现硬件访问，因此效率更高。VMware Player、ACE、Workstation和VMware Server都是基于寄居架构而实现的，而VMware ESX Server是业界第一个裸金属架构的虚拟化产品，目前已经发布了第四代产品。ESX Server需要运行在VMware认证的硬件平台上，可以提供出色的性能，完全可以满足大型数据中心对性能的要求。

为了更好的理解x86平台虚拟化，在此简要介绍一下部件虚拟化的背景。虚拟化层是运行在虚拟机监控器（VMM，Virtual Machine Monitor）上面、负责管理所有虚拟机的软件。如图3所示，虚拟化层就是hypervisor直接运行在硬件上，因此，hypervisor的功能极大地取决于虚拟化架构和实现。运行在hypervisor上的每个VMM进行了硬件抽取，负责运行传统的操作系统。每个VMM必须进行分区和CPU、内存和I/O设备的共享，从而实现系统的虚拟化。

图3. Hypervisor通过VMM管理虚拟机

2. CPU虚拟化

根据原来的设计，x86上的操作系统需要直接运行在裸机上，因此默认拥有和控制所有的硬件。如图4所示，x86架构提供了四种特权级别Ring 0、1、2和3，通过这四种级别来控制和管理对硬件的访问。通常，用户级的应用一般运行在Ring 3级别，操作系统需要直接访问内存和硬件，需要在Ring 0执行它的特权指令。为了虚拟x86架构，需要在操作系统下面运行虚拟化层，由虚拟化层来创建和管理虚拟机，进行共享资源分配。而有些敏感指令不能很好的进行虚拟化，它们在Ring 0以外级别执行时，会出现不同的结果。如何在运行时捕获和翻译这些敏感指令成为x86虚拟化的一大挑战，使得x86架构虚拟化最初是不可能的。

图4. x86架构虚拟化前的特权级别

VMware在1998年成功克服了这个难点，开发出了BT技术，从而将操作系统移到Ring 3的用户模式运行，而VMM运行在Ring 0级别实现隔离和性能提升。尽管VMware通过BT技术实现的全虚拟化已经成为默认的业界标准，超过2万家的VMware用户都在这种技术的支持下可靠、高效运行，但整个业界还没有统一定义的行业标准，因此每家公司都在自由发挥，来试图解决这个技术难点，不同的方案都有自己的优势和劣势。
到今天为止，有三种典型的技术来解决x86虚拟化的难题：  

 通过BT实现的全虚拟化

 操作系统帮助下的虚拟化，也叫半虚拟化

 硬件帮助的虚拟化

a. 技术1 – 通过BT实现的全虚拟化

VMware可以通过BT和直接执行技术的结合来实现任何x86操作系统的虚拟化。如图5所示，BT可以翻译核心指令来代替那些不能虚拟化的指令，通过翻译后的指令直接访问虚拟硬件。同时，所有用户级指令还是可以直接在CPU上执行来确保虚拟化的性能。每个VMM为每个虚拟机提供完整的硬件支持服务，包括虚拟BIOS、虚拟设备和虚拟内存管理。

图5. BT实现x86架构虚拟化

BT和直接执行技术的结合实现了全虚拟化，此时客户操作系统可以通过虚拟化层从物理硬件上完全抽取出来，客户操作系统感知不到是否发生了虚拟化，完全不需要进行修改。全虚拟化是迄今为止唯一不需要硬件或操作系统协助来进行敏感和特权指令虚拟化的技术，Hypervisor可以翻译所有的操作系统特权指令，并保存在缓存里备用，而用户级的指令完全可以全速直接执行。

全虚拟化提供了最好的虚拟机隔离和安全性，简化了客户操作系统迁移和移植能力。VMware ESX Server就是通过全虚拟化技术来实现的最好案例。

b. 技术2 – 半虚拟化

该文中我们将Para-Virtualization翻译为半虚拟化。Para是来自希腊语的英语前缀，意指“和”、“在边上”、“一道”等。因此，“半虚拟化”指得是客户操作系统和hypervisor之间的通讯如何提高性能和有效性。如图6所示，半虚拟化需要修改操作系统内核，替换掉不能虚拟化的指令，通过超级调用（hypercall）直接和底层的虚拟化层hypervisor来通讯，hypervisor同时也提供了超级调用接口来满足其他关键内核操作，比如内存管理、中断和时间保持。

图6. 操作系统协助的x86架构虚拟化

半虚拟化和全虚拟化不同，全虚拟化不需要修改上面的操作系统，敏感的操作系统指令直接通过BT进行处理。半虚拟化的价值在于降低了虚拟化的损耗，但是半虚拟化的性能优势很大程度上依赖于运行的负载。由于半虚拟化不支持未修改的操作系统(例如： Windows 2000/XP)，它的兼容性和可移植性差。在实际的生产环境中，半虚拟化也会导致操作系统支持和维护的艰难，因为半虚拟化往往要深入修改操作系统内核。开源的Xen项目是半虚拟化的代表，它可以通过修改Linux的内核来实现CPU和内存的虚拟化，通过定制的操作系统驱动来实现I/O的虚拟化。

为了实现全虚拟化，需要构建复杂的BT技术，这往往比直接修改客户操作系统来启用半虚拟化更艰难。VMware实际上已经在产品中使用了半虚拟化的一些技术，来构建VMware Tools和优化虚拟设备驱动。VMware tools服务为VMM Hypervisor提供了 一个后门服务，用来同步时间、记录日志和客户操作系统关机等。Vmxnet是半虚拟化的I/O设备驱动程序，它可以和hypervisor共享数据结构。这些半虚拟化技术的应用改善了设备的兼容能力，提高了数据吞吐速率，降低了CPU利用率。需要重点澄清的是：VMware tools 服务和vmxnet设备驱动并不是CPU半虚拟化解决方案，它们紧紧对客户操作系统进行了微小的、非关键的修改，并不需要修改客户操作系统内核。

面向未来，VMware也在帮助开发虚拟化版的Linux来支持半虚拟化技术的进步，更进一步的细节，我们将在后面进行探讨。

c. 技术3 – 硬件辅助虚拟化

硬件厂商面对虚拟化都相当热情，他们都投入了大量的精力来开发新的特性来简化虚拟化技术的应用。第一代的虚拟化增强包括Intel Virtualization Technology (VT-x)和AMD的AMD-V，这两种技术都为CPU增加了新的执行模式root模式，可以让VMM运行在root模式下，而root模式位于Ring 0的下面。如图7所示，特权和敏感指令自动在hypervisor上执行，从而无需BT或半虚拟化技术。客户操作系统的状态保存在VT-x（Virtual Machine Control Structure，虚拟机控制结构）中或AMD-v(Virtual Machine Control Block，虚拟机控制块)。支持Intel VT和AMD-V的CPU从2006年开始推向市场，因此只有新的系统包含了这些硬件辅助的虚拟化功能。

图7.硬件辅助的x86架构虚拟化

由于hypervisor到客户操作系统转换的损耗和严格的编程模式要求，第一代的硬件辅助虚拟化性能并不理想，VMware的BT技术很多时候性能更好。第一代硬件辅助虚拟化为编程留了很小的空间，降低了软件的灵活性，增加了hypervisor到客户操作系统转换的损耗，正式基于此，VMware仅仅在很少的情况下利用了第一代的硬件辅助虚拟化，比如，在Intel平台上支持64位操作系统的时候，VMware使用了Intel的VT-x。

3. 内存虚拟化

除了CPU虚拟化，下一个关键是内存虚拟化，通过内存虚拟化共享物理系统内存，动态分配给虚拟机。虚拟机的内存虚拟化很象现在的操作系统支持的虚拟内存方式，应用程序看到邻近的内存地址空间，这个地址空间无需和下面的物理机器内存直接对应，操作系统保持着虚拟页到物理页的映射。现在所有的x86 CPU都包括了一个称为内存管理的模块MMU（Memory Management Unit）和TLB(Translation Lookaside Buffer)，通过MMU和TLB来优化虚拟内存的性能。

图8. 内存虚拟化

为了在一台机器上运行多个虚拟机，需要增加一个新的内存虚拟化层，也就是说，必须虚拟MMU来支持客户操作系统。客户操作系统继续控制虚拟地址到客户内存物理地址的映射，但是客户操作系统不能直接访问实际机器内存。VMM负责映射客户物理内存到实际机器内存，它通过影子页表来加速映射。如图8所示，VMM使用TLB硬件来映射虚拟内存直接到机器内存，从而避免了每次访问进行两次翻译。当客户操作系统更改了虚拟内存到物理内存的映射表，VMM也会更新影子页表来启动直接查询。MMU虚拟化引入了虚拟化损耗，第二代的硬件辅助虚拟化将支持内存的虚拟化辅助，从而大大降低因此而带来的虚拟化损耗，让内存虚拟化更高效。

4. 设备和I/O虚拟化

最后一个模块是设备和I/O虚拟化，也就是如何管理和路由物理设备和虚拟设备之间的I/O请求。

图9. 设备和I/O虚拟化

基于软件的I/O虚拟化和管理为设备管理带来了新的特性和功能，让设备的管理更容易。就拿网络为例，通过虚拟网卡和交换机可以在一台物理机上不同虚拟机之间建立虚拟网络，而这不会在物理网络上产生任何的流量；网卡teaming允许多个物理网卡绑定成一个虚拟机网卡，提供了很好的容错能力，同时保持了同一MAC地址。I/O虚拟化的关键是保持虚拟化优势的同时，尽量降低虚拟化给CPU造成的负担。

Hypervisor虚拟化物理硬件，为每台虚拟机提供一套标准的虚拟设备，如图9所示。这些虚拟设备高效模拟常见的物理硬件，将虚拟机的请求发送到物理硬件。该硬件标准化的过程也让虚拟机标准化，让虚拟机更容易在各种平台上自由移动，而无需关心下面实际的物理硬件类型。

5. 目前几种x86虚拟化技术对比总结 

VMware目前利用了以上三种的虚拟化技术，或者用在生产上，或者用在开发实验室，在性能和功能之间找到平衡。下表是三种虚拟路线的总结比较，可以看到它们的优劣，从而可以取长补短，对三种虚拟化路线进行科学选择。

1. 通过BT实现的全虚拟化今天仍是主流

BT支持下的全虚拟化目前仍然是主流，是今天就可以部署的最可靠的虚拟化技术。VMware的虚拟化也在Windows和Linux操作系统环境下提供最高的性能，同时提供了丰富的企业级功能和管理性。通过BT，除了在Intel CPU上不支持64位的客户操作系统， VMware可以在生产环境下支持全虚拟化和硬件辅助虚拟化，并且性能良好。

BT支持下的全虚拟化在未来的几年内将继续保持良好发展势头，不需要更改操作系统，通过高级BT来提高性能。当然，硬件辅助虚拟化也将慢慢走向成熟，推进虚拟化性能不断提升。

2. 硬件辅助虚拟化是未来方向，但是目前性能仍然没有达到预期

去年Intel和AMD发布的硬件辅助虚拟化硬件辅助虚拟化的第一步，通过硬件辅助虚拟化，可以移除BT或对操作系统的修改。就像Xen利用的那样， As Xen has 这些初期的功能将建立hypervisor变得简单了很多，再也不需要借助BT或者修改操作系统了。Xen利用这些硬件辅助功能来实现Windows虚拟化，但是性能很差，远不如VMware的BT虚拟化或者XenLinux的半虚拟化。第一代硬件辅助虚拟化部署了苛刻的编程模式，将hypervisor到客户操作系统的损耗大大提高了，这使得第一代硬件辅助虚拟化的性能低于VMware的BT虚拟化实现。VMware正在同Intel和AMD一起努力，来增强未来硬件虚拟化的设计，进一步提高硬件辅助虚拟化的灵活性和性能。

第二代的硬件虚拟化将提供更高的性能，大大降低虚拟化损耗。AMD和Intel都已经发布了他们的产品路线图，包括硬件支持内存虚拟化(AMD NPT和Intel EPT)和硬件支持设备和I/O虚拟化(Intel VT-d和AMD IOMMU)。

计算密集的负载已经可以通过BT运行在虚拟化平台上，部署NPT/EPT将无需影子页表，而影子页表直接消耗系统内存，为此进一步显著改善虚拟化性能。将来的CPU对虚拟化支持进一步增强，这将推动硬件辅助虚拟化的广泛应用，但不要期望革命性的变化。处理器在进行着快速的升级换代，处理器速度的提升对虚拟化密度和性能的影响预期将远高于硬件辅助对虚拟化的优化。

半虚拟化技术的进步预期不会带来性能进一步巨大提升，而硬件辅助虚拟化的深化，将通过对CPU、内存和I/O的虚拟化，预期会有很大的性能提升，而未来的hypervisor将会普遍支持硬件辅助虚拟化，也就是说硬件辅助虚拟化将成为hypervisor的默认配置，从而带来虚拟化的性能、管理性的进一步改善。 

3. Xen的CPU半虚拟化带来了性能优势的同时，增加了维护成本

Xen经常将半虚拟化定位为第二代的虚拟化，而将VMware的虚拟化技术标记为第一代虚拟化技术。实际上，半虚拟化是很老的、有用的虚拟化技术，它可以为某些负载带来很好的性能，但一般都会增加维护成本。我们不否认在客户操作系统里安装虚拟化管理应用和设备驱动能提高虚拟化性能，但是数据中心用户必须清晰认识到半虚拟化的性能优势和运行修改过的客户操作系统而花费的大量维护成本之间的厉害冲突。半虚拟化带来的性能提升依赖于运行的负载，大多数用户应用可能因此性能提高很少，很少情况下能达到接近物理机的性能。

Xen的第一大挑战就是处理器的半虚拟化不能支持未经修改的操作系统，很多情况下就不能使用这种方式，比如操作系统本来不允许修改（如Windows），或者有时候需要某种特定版本的Linux。实际上，大多数的数据中心都不愿意将自己的生产应用运行在开源Hypervisor上修改过内核的Linux操作系统中。另外，大量的内核修改会导致客户操作系统和hypervisor之间的数据结构依赖性，该操作系统因此会没法运行在其他的hypervisor或裸物理机上。

尽管很多Linux版本开始将半虚拟化捆绑到操作系统内核里，部署使用半虚拟化操作系统的服务器仍然会增加维护成本和降低灵活性。就象很多公司已经发现半虚拟化的XenLinux不适合企业级应用， 许多虚拟化厂商基于开源Xen而开发的虚拟化产品本身已经放弃了Linux半虚拟化。比如Virtual Iron，他们已经声明半虚拟化走向死亡，已经专注基于硬件辅助的全虚拟化开发，来支持未经修改的操作系统。

这导致了Xen的第二个竞争挑战。Xen 3.x最近紧紧引进了硬件辅助全虚拟化来支持未经修改的操作系统(比如：Windows)。VMware的BT技术十分复杂，性能远高于Xen第一代的硬件辅助全虚拟化，Xen厂商完全没法和VMware竞争，包括性能、可靠性、易于管理等方面。但今天经常引起一些误解：很多厂商说他们的Linux半虚拟化性能优势明显，而很多用户认为他们可能并不需要修改操作系统内核，其实这是非常错误的。

当然，VMware也发现对于某些特定的负载，处理器的半虚拟化确实可以大幅提高性能，但是等到第二代硬件辅助出现之后，半虚拟化的性能优势还很难说清楚，性能提升可能会下降、甚至消失，这已经成为一个悬念。

在VMware看来，处理器半虚拟化的最大问题是对操作系统的修改，这会导致该操作系统对特定hypervisor的依赖性。对于Xen来说，部署深度半虚拟化将带来对hypervisor的极大依赖性，操作系统的内核紧密链接到hypervisor的实现，这带来严重的兼容性问题，因为此时的XenLinux不能在其他的hypervisor上运行，甚至根本没法直接运行在物理硬件上，从而导致必须维护更多的Linux版本。另外，半虚拟化只适用于新的、开源操作系统，因为对操作系统内核的修改需要操作系统厂商的支持。最后，对hypervisor的依赖性会拖累该操作系统内核的更新。

4. VMware的透明半虚拟化可以平衡性能优势和维护成本

图1. 通过VMI实现的透明半虚拟化

Xen致力于部署修改Linux内核的半虚拟化的时候，VMware正在致力于标准接口的建立来应用操作系统辅助半虚拟化的同时，使得操作系统维护成本不至于增加很多。2005年，VMware提出了透明半虚拟化接口VMI（Virtual Machine Interface，虚拟机接口）的建议标准，建议将VMI作为客户操作系统和hypervisor之间的标准通讯接口。

如图1所示，VMI是位于hypervisor和半虚拟化操作系统之间的接口层，透明半虚拟化保证了同一半虚拟化的操作系统内核可以运行在任何兼容的hypervisor或物理裸机上。它从设计上将所有的VMI调用分成两类，直接内部指令用于裸设备访问，间接调用客户操作系统和hypervisor之间的VMI层，两种方式都确保了性能优异，同时维护性和扩展性也通过VMI的独立性来维持。由于VMI-Linux可以运行适当版本的间接层，使得VMI层可以支持不同的hypervisor。

VMware继续和Linux社区保持很好的沟通，一起来开发半虚拟化接口，以支持多种不同的hypervisor。2006年，VMware发布了开源VMI规范，在渥太华Linux大会上的VMI建议推进了Linux社区paravirt-ops接口的开发。paravirt-ops接口规范由IBM、VMware、Red Hat和XenSource组成的联合小组共同开发，它包含了很多VMI里面提出的概念，来支持透明半虚拟化。通过这个接口，半虚拟化的Linux操作系统可以运行在任何兼容paravirt-ops接口的hypervisor上。VMware积极致力于paravirt-ops客户操作系统接口的开发，从Linux内核2.6.20开始，paravirt-ops已经成为官方Linux内核的一部分。版本2.6.22内核也包括了VMI后端来补充paravirt-ops接口。通过这个同一的规范，Linux操作系统厂商和ISV都只需要支持单一的内核，虽然进行了半虚拟化，但是没有影响性能或者可维护性，这将大大改善半虚拟化的兼容性。

为了让业界体验这个规范，VMware在Workstation 6.0里已经开始尝试性支持VMI，在寄居架构支持半虚拟化的操作系统。该版本的Workstation实现了从2005年开始和Linux社区讨论的透明半虚拟化接口。你也可以下载完整版的VMware Player虚拟机监控器，它也可以支持主流厂商的半虚拟化Linux内核。VMware想通过VMware Player和Workstation里对半虚拟化的尝试性支持，来让开发人员感受VMware的半虚拟化技术实现。

由于这次尝试性支持是基于寄居的虚拟架构，因此并不是来演示半虚拟化的性能，但它可以演示大量消耗CPU负载性能的提升。接下去VMware将会在我们的hypervisor产品上支持半虚拟化，到那时能就可以尽情体验基于标准的半虚拟化带来的CPU和I/O性能的提升。等到半虚拟化操作系统正式投入商业应用，VMware就会在所有的虚拟架构产品线上支持半虚拟化的操作系统。

5. VMware通过多模式VMM架构来确保性能和灵活性

很多虚拟化公司由于资源的限制，他们的产品都只支持一种虚拟化战略。他们一般都专注于自己的虚拟化实现优势，而很少考虑自己的劣势和功能缺陷，这因此产生了很多的误解。而VMware作为业界翘楚，所有的产品都将各种新的虚拟化技术整合在自己的产品中，以平衡性能、可靠性、功能性和易于管理性。同时，VMware也和业界伙伴紧密合作，不断开发完善虚拟化的生态系统。

图2. 多模式VMM架构

VMware提供了灵活的多模式VMM架构来支持每个虚拟机，如图2所示。VMware可以根据不同的负载来选择不同的模式来达到最优性能。在VMware的产品线中应用了同样的VMM架构，包括ESX Server、VMware Player、VMware Server、Workstation和ACE。

今天的负载可以通过32位的BT VMM、64位的BT VMM或者VT-x来实现，从而获得性能最优化，将来的负载将可以运行在同时支持AMD-V+NPT和VT-x+EPT的32/64位的VMM上。VMware提供了灵活的架构来支持新的虚拟化技术，而多模式的VMM利用了BT、硬件辅助和半虚拟化技术，针对不同负载和处理器的组合来选择最为合适的运行模式，从而达到性能最优化。硬件辅助将逐渐走向成熟，并将广泛支持各种不同的负载。

6. 结论

实际上，VMware正在尝试不同的虚拟化技术来提升虚拟化性能，BT、硬件辅助和半虚拟化都是比较有效的x86虚拟化技术，但是他们的价值和重要性仍然在变化中。VMware从1998年开始引领虚拟化的革命，到今天为止仍然继续引领虚拟化业界和标准的发展。未来虚拟化的将会出现基于标准的半虚拟化实现，半虚拟化的操作系统应该可以运行在不同的hypervisor平台或物理裸机上，通过硬件辅助来管理CPU、内存和I/O设备，从而在提升性能的同时，确保兼容性和可管理性。

今天，VMware的虚拟化技术已经被财富100强的所有企业和财富1000强的84％的企业部署应用。在整个虚拟化业界，VMware产品今天仍然在性能、可靠性、稳定性、易于管理性、安全性、支持能力、功能性和合作伙伴生态系统方面领先于所有其他的厂商。

企业级用户在选择虚拟化产品时，要充分考虑虚拟化架构的价值。VMware的专业销售、服务团队可以为企业提供足够的支持来帮助企业认清自己的需求，通过整合评估、ROI工具、案例分析等，企业级用户将更为准确了解虚拟化能够为他们带来的巨大好处和实际收益。

看到外界非常关注 Oracle 在虚拟环境中的表现，我们感到十分高兴。Oracle 在 VMware ESX 上的优越表现一直是我们的秘诀之一。这种优越表现绝非偶然，因为我们对 VMware ESX Server 体系结构做了大量功能和性能优化工作，特别是在数据库支持方面。

在此，我将向大家介绍一下确保我们获得最佳数据库性能的 10 大重要因素。以下是其中几项性能优势：

• 接近本机系统的性能：Oracle 数据库与物理系统的性能几近相似
• 超强的数据库 I/O 扩展性：VMware ESX Server 的精简虚拟化管理程序层每秒能够驱动 63,000 次数据库 I/O 操作
• 多核扩展：使用 SMP 虚拟机和多个数据库实例进行纵向扩展
• 巨大的内存容量：可扩展的内存容量 - 每个数据库 64 GB；每台主机 256 GB

我们一直持续地下大气力优化 Oracle 在 VMware 产品上的性能，因为它已是最常用的虚拟化应用程序之一。融合了多项先进优化措施的 ESX 3.5 版本即将发行，这是我们迄今为止推出的最棒的数据库平台。

在本篇博客文章中，我将为大家介绍数据库应用程序（如 Oracle 产品）的独特和专有特性，并向大家展示 ESX Server 在此类工作负载下的运行能力。

数据库的本质

数据库具有多种独特的属性，例如较大的内存占用空间。这样，数据库要进行顺畅的虚拟化就略显复杂了。然而，实践证明这也是一种机会，因为我们可以专门针对这些特定的属性进行优化。

• 巨大的内存容量：数据库使用大量的内存来对其存储数据进行高速缓存。大容量高速缓存是衡量数据库性能极为重要的一个标准，因为它通常可使物理 I/O 操作的次数减少 10-100 倍。
• 高性能数据块 I/O：数据库使用固定大小的数据块写入和读取数据。这些 I/O 通常较小，频繁发生于少量文件或设备中。
• 以吞吐量为中心：数据库通常会有大量的用户同时进行操作，因此具有多个逻辑或物理处理器的系统便可以使这些用户自然并存并充分受益。

理解和量化虚拟性能

量化虚拟系统的性能时，首先应衡量延迟和吞吐量，其次是资源的使用率。例如，如果一个物理系统正在以每分钟 10000 个事务、每个事务 500 毫秒的延迟运行，则与该物理系统性能相同的虚拟系统也应该以可接受的延迟标准提供同样水平的吞吐量。其次应该是资源使用率的衡量指标，通过这一指标可以衡 量要取得同样水平的性能需要额外使用多少物理资源。有些时候我们过于简单地仅去考虑 CPU 资源，然而现实中我们需要配备的内存和 I/O 却是更加昂贵的资源。随着时间的推移，内存和 I/O 资源的使用率变得越来越重要，原因是多核 CPU 会使每个处理器内核的成本继续降低，而内存的成本却一直居高不下。

对于 Oracle 而言，更重要的一点是纵向扩展能力，即通过虚拟化管理程序充分利用多核 CPU、大容量内存以及 I/O 吞吐量来支持后端存储阵列中大量的磁盘。

数据库性能认识误区

对于虚拟化数据库，通常存在以下几点认识误区：

• 虚拟数据库具有很高的系统开销：就延迟和吞吐量而言，虚拟数据库的运行速度能等于或接近物理系统。对于常见的数据库而言，虚拟化开销很小 – 在 VMware ESX Server 中所测量到的 CPU 开销低于 10%。

• 数据库的 I/O 操作过多无法进行虚拟化：通常情况下，数据库会产生大量小的、随机的 I/O 操作，其理论值可能达到虚拟化管理程序层的 I/O 数量极限。然而，VMware ESX 的精简虚拟化管理程序层每秒可以驱动 63,000 多次数据库 I/O 操作，等同于 600 多个硬盘的 I/O 吞吐量。这样的 I/O 极限值，即使是用于 x86 系统上最大的数据库也绰绰有余。

• 虚拟化只能用于较小的、无关紧要的应用程序：ESX 虚拟化管理程序非常强健 - 很多客户的基于 ESX 的系统已经连续正常运行了两年多的时间。此外，ESX 虚拟化管理程序一直非常稳定，即便在资源过度使用时亦是如此。

我们不能奢望通过一个快速的解决方案使数据库与很多种实际的应用程序完美兼容 – 只有通过长时间地致力于研究众多用户在实际数据库工作中获得的教训，并且在虚拟化管理程序体系结构中应用这些教训，才能获取优异的性能。

下面让我们简要了解一下虚拟化管理程序中可确保数据库获得优异性能的一些特性。

1：VMware ESX 的高性能 I/O

I/O 系统的吞吐量和延迟对于在线事务处理系统的性能来说至关重要。由于事务数据库系统是针对数据集中随意位置的不同小数据项进行操作的，因此应测量随机 I/O 吞吐量（以每秒钟的 I/O 操作数为测量标准），而非带宽（MB/s）。

图 1：VMware ESX I/O 驱动程序模型

由于逻辑上虚拟化管理程序驻留在客户虚拟机数据库和后端存储之间，因此很重要的一点就是虚拟化管理程序的 I/O 能力可以纵向扩展且不会超出任何性能限额，并且不能产生可察觉延迟。如图 1 所示，VMware ESX 的 I/O 子系统使用直接的驱动程序模型，以使由虚拟堆栈引起的延迟最小化。这是可能的，因为 I/O 请求可以由同一个处理器（相对于发出请求的虚拟机）进行内处理。在其他体系结构中，当 I/O 由一个重量级域 0 或父分区进行代理时，会产生大量的延迟和 CPU 开销。

在随机存取模式下，Oracle 数据库通常会产生许多 4 KB 或 8 KB 的小型 I/O 操作。对于这类 I/O 操作，一个典型的磁盘每秒可处理的 I/O 操作数介于 100 到 200 之间（具体值取决于磁盘的转速）。然而在实际操作中，最好不要使一个驱动器每秒处理的 I/O 数超过 100 个。VMware ESX 3.5 虚拟化管理程序的吞吐量已经得到了显著的提升，可持续以每秒 60,000 多个 I/O 操作数的速度运行，相当于 600 多个磁盘的吞吐量。

                           图 2：随机 I/O 吞吐量
4-CPU 数据库平均量对比 VMware ESX 3.5

VMware 对其客户的 15,000 个 Oracle 服务器进行的调查研究结果表明：对于加载的 4 处理器系统，每秒的平均 I/O 数为 1280 个，大约是 15 个磁盘的吞吐量。由于一些工作负载吞吐量要求比其他工作负载高，有些工作负载的吞吐量要求是突发性的，因此必须要备有充足的预留量。即便是对于要求最高的 数据库，ESX I/O 子系统的吞吐量能力也是绰绰有余的。

2：使用 Virtual SMP 进行纵向扩展

VMware ESX 可以通过两种方式来利用多个物理处理器：通过多个虚拟机进行横向扩展；通过纵向扩展每个虚拟机来使用多个物理处理器。VMware ESX 提供的 Virtual SMP 功能允许每个客户虚拟机最多有 4 个处理器，物理系统最多有 64 个处理器。

图 3：Virtual SMP

由于数据库工作负载通常会有大量的用户同时进行操作，这些用户是完全并行的，并且可以毫不费力地同时处理多个任务。

Oracle 能够利用 VMware Virtual SMP 扩展性能，从而超出每个虚拟机单处理器的能力。为了说明这一点，我们通过 Oracle Database 10g 版本 2 进行了几个基准测试，使用的是流行的 SwingBench 在线事务处理工作负载。图 5 显示的是在单个虚拟机上增加处理器时 Oracle 的吞吐量。基准测试测量了事务的吞吐量，结果表明随着额外处理器的增加，吞吐量提高了 94%。恰巧，这与我们在本机系统上看到的扩展量完全一致，这很可能是硬件和数据库扩展带来的结果。

图.5：VMware Virtual SMP 针对单个 Oracle 10g R2 实例的扩展情况

进行整合的关键要求之一是对于多个数据库实例的良好扩展性。为了显示这一点，我们在 VMware ESX Server 3.5 上运行了多个 Oracle 10G 实例。图 4 显示了在运行开放源 DVDstore 数据库基准测试时，VMware ESX 平台的扩展情况。该基准测试是以客户端－服务器模式运行的，因此我们可以专注于数据库层。在此研究中，我们在 7 个双处理器 SMP Linux 虚拟机（每个虚拟机皆具有自己的数据库实例）中运行了该基准测试。我们很快将在 Vroom 中发布该基准测试的详细信息。

图 4：16 核 Sun x4600 M2 上 VMware ESX 中多个数据库实例的扩展情况

3：利用大容量内存进行纵向扩展

Oracle 数据库会消耗大量内存。主要是在内存中缓存预编译的 SQL 查询和来自磁盘的数据块。

数据库设计者花费了极大的精力来尽量避免进行磁盘 I/O。这是因为一个磁盘 I/O 的延迟要远远长于 CPU 处理一个事务的时间。例如，一个磁盘 I/O 需要等待 10 毫秒，而典型的事务只需占用 CPU 几毫秒。如果一个到磁盘的 I/O 能够被高速缓存在内存中，则可以在不到 1 毫秒的时间内调用。此外，由于磁盘很贵，通常情况下用于数据库的存储系统的成本更多地受其每秒所执行的 I/O 操作数的影响，而不是单纯的存储空间的影响。降低整体的磁盘吞吐量便意味着大幅降低系统的成本。

更大的内存空间可以帮助 Oracle 在内存中高速缓存更多的磁盘数据块。请看一个简单的例子：如果数据库系统正在使用内存来高速缓存其磁盘 I/O，并且高速缓存命中率达到 90%，这就意味着每 10 次访问操作，只有一次会导致物理 I/O。如果每秒的访问次数为 10,000，我们将会看到每秒 1,000 次 I/O 操作。如果增加内存将高速缓存命中率提高至 99%，则可以将 I/O 的发生率降低到 1%，从而使每秒的物理 I/O 数减至十分之一，即每秒仅 100 次 I/O 操作。

通常，在客户操作系统所使用的内存中，有 80% 以上是由 Oracle 磁盘数据块高速缓存占用的。基本的经验原则是数据库高速缓存大小应该是数据库大小的 5-10%，将内存容量增加一倍会使吞吐量大约提高 20%。显然这还与工作负载的多少有很大关系，但是您可以看到较大的内存可以帮助提高系统中其他区域的资源效率，因而就整体而言，内存越大越好。综合上述 原因，大容量内存对于数据库来说非常重要。VMware ESX 3.0 允许每个客户操作系统拥有 16 GB RAM，而 VMware ESX 3.5 则将此限制提高到了每个客户操作系统 64 GB。

由于通过工作负载整合可以从内部提高处理器利用率，因此我们可以将更多工作负载压缩到单个系统中。这意味着平均而言，每个物理处理器的平均内存要求 将是传统未虚拟系统的两倍。为了适应这些不断增长的要求，我们在 ESX 3.5 中大幅提高了内存扩展量，现在对于 Sun、IBM 和 Unisys 的最新高端系统，最高可以支持 256 GB RAM。

4：ESX 3.5 虚拟化管理程序的大页面功能

Oracle 数据库在 CPU 的 MMU 中使用大页面来优化内存性能已经有一段时日了。这一功能与操作系统的大页面功能配合使用，通常用于容纳数据库磁盘数据块高速缓存的较大共享内存分段。 Linux、Windows 和 Solaris 客户操作系统均支持大页面。通过大页面，Oracle 的性能一般会提高 5-20%，具体取决于处理器的类型和所配置内存的大小。

其他的 x86 虚拟化管理程序不提供虚拟的大页面功能，因此当数据库被虚拟化后无法使用该优化功能。ESX 3.5 虚拟化管理程序提供先进的大页面支持，允许数据库充分利用 CPU 的大页面功能。

5：ESX 针对不同内存体系结构系统进行的优化

当今许多备受关注的新硬件系统都是使用不同的内存体系结构实现的。这意味着并不是所有的内存都具有相同的速度，对比拓扑结构与处理器相近的内存和拓扑结构与处理器差异较大的内存，访问前者要比访问后者更快。

为确保最佳性能，VMware ESX 虚拟化管理程序在为客户操作系统分配内存时，将从与运行客户操作系统的 CPU 拓扑结构接近的物理内存中进行分配。

6：高性能的半虚拟化网络连接

半虚拟化是一个专有名词，指的是客户操作系统具有虚拟化管理程序的一些知识，并且能够利用这些知识对虚拟化管理程序的执行进行优化。VMware ESX 虚拟化管理程序在客户操作系统中使用半虚拟化网络连接驱动程序来提供高性能的网络连接。在客户操作系统首次启动时，这些驱动程序会通过 VMware 工具包被自动安装。不同于 CPU 半虚拟化，半虚拟化驱动程序不需要对客户操作系统进行任何更改，它们只是作为透明的新驱动程序进行安装。

6 - 多 NIC 的扩展情况

ESX 能够以线速驱动千兆位以太网，如文章多个虚拟机中的网络连接性能中所述。通过集成新的无状态卸载功能，例如大分段卸载 （large-segment-offload, LSO） 和巨型框架，ESX 3.5 的网络连接性能得到了很大提升，现在在 10 千兆位以太网上已接近线速（9.9 千兆位/秒）。

通过在多个 NIC 之间扩展，网络连接的性能可以提高从而超过一个 NIC 的性能。图 6 显示了添加多个 NIC 后千兆位以太网性能的扩展情况。

7：利用 VMware ESX 的页面共享功能来减少内存使用量

通过一个被称作透明页面共享的 功能，ESX 虚拟化管理程序可以安全地共享具有相同内容的物理内存。通过页面共享，虚拟化管理程序会分配一个单独的物理内存页面来对应客户系统中的多个页面，这样仅有 一份数据副本驻留在内存中。使用这一技术，所耗用的内存总量就会少于各部分的总和。虚拟化管理程序会确保绝对的安全性隔离，即如果一个客户操作系统修改了 一个页面，则该客户操作系统就会获得自己的专有副本。

可以通过多种方式使用此功能有效地节省 Oracle 所用的内存。如果有多个数据库实例在运行，则页面共享功能会自动共享操作系统和 Oracle 实例的代码部分。通常情况下，这会为每个虚拟机节省好几百 MB 内存。

当多个数据库正在共享相似的数据（如一个共享的参考表或者多个用于开发目的的数据库副本）时，ESX 可自动检测 Oracle 磁盘数据块高速缓存中相同的磁盘数据块，并安排对其进行共享。如此一来，各数据库实例以及各虚拟机之间就可以透明地共享数据库高速缓存内存映像。这会进一 步节省几十 MB（至少系统表会是相同的）到几 GB 的内存，具体取决于实例间相同磁盘数据的数量。

页面共享的另一个好处是，某些内存还可以在每个实例内部进行共享。这通常适用于零页面。

8：半虚拟化 CPU

图 7： 虚拟化技术

有多种技术可以用来虚拟化 x86 指令集，包括二进制转换、半虚拟化和硬件辅助。长期以来 VMware 虚拟化管理程序就一直使用二进制转换来为多种工作负载提供接近本机性能的虚拟化。CPU 半虚拟化或硬件辅助这两种方法可以用来为具有多个系统调用的工作负载提供小的优化，以及特定的内存优化。没有哪个方法是适用于所有工作负载的，在 VMware ESX 中，不同的方法被用于不同的工作负载。Ole Agesen 和 Keith Adams 在他们的论文（关于虚拟化性能）中解释了不同的技术。

VMware ESX 可以针对一些客户操作系统类型选择性地使用半虚拟化技术。在最近的研究中，我们在半虚拟化的 Linux 客户操作系统上使用 Swingbench 在线事务处理工作负载对 Oracle 10g R2 进行了测试。测试结果表明，采用半虚拟化 CPU 接口可使该数据库的性能提高 10%。

9：最佳的 Oracle-Windows 性能

由于所有关键的 CPU、内存和 I/O 虚拟化功能都处在虚拟化管理程序的可移植层中，因此 Windows 客户操作系统中 Oracle 的性能与 Linux 客户操作系统中 Oracle 的性能是相同的。Windows 上的 Oracle 能够利用大页面、SMP、I/O 扩展性以及高性能半虚拟化网络连接驱动程序。

对于 Linux、Solaris 和 Unix 管理员，这就意味着您可以根据最适合自己部署的工具而自由选择操作系统。对于 Windows 管理员，这意味着您可以完全放心地在 Windows 中运行 Oracle 数据库，您会获得同样水平的性能和可扩展性。

10：通用的 32 位和 64 位客户操作系统支持

为了在客户操作系统中使用超过 3.5 GB 的内存，需要将数据库配置为 64 位应用程序，并使用支持 64 位的操作系统。VMware ESX 允许 32 位和 64 位客户操作系统并存，这可以在需要时简化 64 位客户操作系统的部署。

总结

各位数据库管理员们，欲知 Oracle 在 VMware 产品上的性能表现，敬请关注 VROOM 中更多相关文章，最新的 Oracle portal 也值得期待，您可以在其中获取大量有关 Oracle 虚拟化的有用资料。此外，一个全新的 Oracle Discussion Forum 即将面世，您可以在论坛中畅谈您对 Oracle 性能的看法。虚拟数据库实现了前所未有的高性能！