11 Cloud Computing

云计算的兴起解决了性能领域中的一些问题，同时也带来了其他问题。云通常建立在虚拟化技术之上，允许多个操作系统实例或租户共享一个物理服务器。这意味着可能存在资源争用：不仅来自其他进程，这在Unix中是常见的，而且还来自其他整个操作系统。隔离每个租户的性能影响至关重要，同样重要的是识别由其他租户引起的性能不佳。
本章讨论了云计算环境的性能，并分为三个部分：
背景介绍了一般云计算架构及其性能影响。
操作系统虚拟化是指由单个内核管理系统，创建相互隔离的虚拟操作系统实例。本节以SmartOS Zones为例进行了实现。
硬件虚拟化是指由一个虚拟机管理程序管理多个客户操作系统，每个操作系统都运行自己的内核，并具有虚拟化设备。本节以Xen和KVM为例进行了介绍。
示例技术用于讨论不同类型虚拟化的性能特性。关于它们的使用的完整文档以及其他虚拟化技术的使用，请参阅它们各自的在线文档。
不使用虚拟化的云环境（仅裸机系统）可以视为分布式系统，并使用前面章节描述的技术进行分析。对于虚拟化系统，本章补充了之前介绍的材料。
11.1 Background
云计算允许将计算资源作为服务交付，从服务器的小部分扩展到多服务器系统。根据安装和配置的软件堆栈量的不同，有各种类型的云计算。本章重点介绍最基本的类型：基础设施即服务（IaaS），它提供操作系统作为服务器实例。示例IaaS提供商包括亚马逊网络服务（AWS）、Rackspace和Joyent。
服务器实例通常是虚拟化系统，可以在几分钟内（或分钟的一部分）创建和销毁，并立即投入生产使用。通常提供云API，以便可以通过另一个程序自动进行这种配置。
总结云术语，云计算描述了一个动态配置框架，用于服务器实例。多个服务器实例作为物理主机系统的客户运行。这些客户也称为租户，术语“多租户”用于描述它们对邻居的影响。主机由云运营商管理。租户由购买它们的客户管理。
云计算对于许多性能主题具有影响：价格/性能比、架构、容量规划、存储和多租户。这些在以下各节中进行了总结。
11.1.1 Price/Performance Ratio
有许多公共云提供商销售云服务器实例，通常按小时计价，价格基于实例的内存（DRAM）大小，8 G字节实例的成本大约是1 G字节实例的八倍。其他资源，如CPU，按内存大小进行调整和定价。结果可能是一个具有一致价格/性能比的价格，一些折扣可以鼓励使用更大的系统。
一些提供商允许您支付额外费用以获得更大的CPU资源分配（“高CPU实例”）。其他资源使用情况也可能被货币化，例如网络吞吐量和存储。
11.1.2 Scalable Architecture
传统上，企业环境使用垂直可扩展性方法来处理负载：构建更大的单一系统（大型机）。这种方法有其局限性。计算机可以构建到的物理大小存在实际限制（可能受到电梯门或货柜的大小限制），随着CPU数量的增加，CPU缓存一致性的困难也在增加。解决这些限制的方法是在许多（也许是小型）系统之间分散负载，这称为水平可扩展性。在企业中，它已经被用于计算机农场和集群，特别是高性能计算（HPC）领域。
云计算也基于水平可扩展性。图11.1显示了一个示例环境，其中包括负载均衡器、Web服务器、应用服务器和数据库。

每个环境层由一个或多个并行运行的服务器实例组成，可以添加更多实例来处理负载。实例可以单独添加，或者架构可以划分为垂直分区，其中由数据库服务器、应用服务器和Web服务器组成的一组作为单个单元添加。
在并行执行中最难的层是数据库层，这是由于传统的数据库模型，其中一个数据库实例必须是主数据库。这些数据库的数据，例如MySQL，可以逻辑上分割成称为分片的组，每个分片由自己的数据库（或主/备份对）管理。更近期的数据库架构，例如Riak，可以动态处理并行执行，将负载分散到可用的实例上。
由于每个服务器实例的大小通常很小，例如，1 G字节（在具有128 G字节及更多DRAM的物理主机上），可以使用细粒度的缩放来实现最佳的价格/性能，而不是事先投资于可能大部分闲置的庞大系统。
11.1.3 Capacity Planning
在企业环境中，服务器可能是一个重要的基础设施成本，无论是硬件成本还是可能持续多年的服务合同费用。新服务器投入生产可能需要数月时间：审批、等待零件供应、运输、安装机架、安装和测试等过程都需要耗费时间。容量规划非常重要，这样可以购买适当大小的系统：容量太小会导致失败，容量太大则成本高昂（而且，对于服务合同而言，可能会成本高昂多年）。容量规划还可以帮助提前预测需求增长，以便及时完成冗长的采购程序。
云计算则大不相同。服务器实例价格低廉，几乎可以立即创建和销毁。公司可以根据实际负载需要增加服务器实例，而不是花费时间规划可能需要的内容。这也可以通过云API自动完成，根据性能监控软件的指标进行。小型企业或初创企业可以从一个小实例发展到数千个，而无需像在企业环境中一样进行详细的容量规划研究。
对于不断增长的初创企业，另一个要考虑的因素是代码变更的速度。网站通常每周或甚至每天更新生产代码。一个需要数周时间的容量规划研究，因为它是基于性能指标的快照，可能在完成时已经过时。这与运行商业软件的企业环境不同，后者可能每年只变更几次。
在云中进行容量规划的活动包括：
- 动态大小调整：自动添加和删除服务器实例
- 可扩展性测试：购买一个大型云环境，以便测试可扩展性与合成负载（这是一个基准测试活动）
在考虑时间限制的同时，还有潜力进行可伸缩性建模（类似于企业研究），以估计实际可伸缩性如何达不到理论水平。
动态调整大小
自动添加服务器实例可以解决对负载快速响应的需求，但也存在过度配置的风险，如图11.2所示。例如，DoS攻击可能会表现为负载增加，触发昂贵的服务器实例增加。应用程序更改可能导致性能回退，需要更多实例来处理相同的负载，这也存在类似的风险。监控是验证这些增加是否合理的重要手段。

一些云服务在负载下降时也可以缩减其规模。例如，2012年12月，Pinterest报告称通过在非工作时间自动关闭其云系统，将成本从每小时54美元降低到每小时20美元[1]。类似的即时节约也可能是性能调优的结果，其中减少了处理负载所需实例的数量。
一些云架构（参见第11.2节，操作系统虚拟化）可以在有空闲资源的情况下即时分配更多CPU资源，采用一种称为突发的策略。这可以不增加额外费用，并旨在通过在此期间提供缓冲区来帮助防止过度配置，以检查增加的负载是否真实且可能持续。如果是这样，可以提供更多实例，以便未来保证资源。
这些技术中的任何一种应该比企业环境要高效得多，特别是那些选择处理服务器寿命内预期峰值负载的固定大小的环境；这样的服务器可能大部分时间处于空闲状态。
11.1.4 Storage
一个云服务器实例通常具有一些本地存储，从本地磁盘提供临时文件。这种本地存储是易失性的，在服务器实例被销毁时会被销毁。对于持久性存储，通常会使用独立的服务，该服务以以下形式为实例提供存储：
- 文件存储：例如，通过NFS协议的文件
- 块存储：例如，通过iSCSI协议的块
- 对象存储：通过API提供，通常基于HTTP协议
这些存储都是网络附加的，网络基础设施和存储设备都与其他租户共享。因此，性能可能比使用本地磁盘要不可靠得多。这两种设置都在图11.3中示出。

通常通过使用内存缓存经常访问的数据来减轻网络存储访问的增加延迟。
一些存储服务允许在需要可靠性能时购买IOPS速率（例如，AWS EBS Provisioned IOPS卷）。
11.1.5 Multitenancy
Unix是一种多任务操作系统，旨在处理多个用户和进程访问相同资源的情况。由BSD、Solaris和Linux后续添加的功能提供了资源限制和控制，以更公平地共享这些资源，并提供了可观察性，以便在涉及资源争用的性能问题时进行识别和量化。
云计算不同之处在于整个操作系统实例共存于同一物理系统上。每个客户端都是其自己独立的操作系统：客户端无法观察到同一主机上其他客户端的用户和进程——这将是一种信息泄露——尽管它们共享相同的物理资源。由于资源是在租户之间共享的，性能问题可能是由于有噪声的邻居而引起的。例如，同一主机上的另一个客户端可能在您的高峰负载期间执行完整的数据库转储，从而干扰您的磁盘和网络I/O。更糟糕的是，邻居可能正在通过执行故意饱和资源的微基准测试来评估云提供商，以找到它们的极限。
针对这个问题有一些解决方案。多租户效应可以通过资源管理来控制：设置提供性能隔离（也称为资源隔离）的操作系统资源控制。这就是针对系统资源的每租户限制或优先级的设置：CPU、内存、磁盘或文件系统I/O以及网络吞吐量的使用。并非所有的云技术都提供了所有这些功能，尤其是磁盘I/O限制。ZFS I/O调节是专门为Joyent公有云开发的，用于解决有噪声的磁盘邻居问题。
除了限制资源使用外，能够观察多租户争用可以帮助云运营商调整限制，并更好地平衡可用主机上的租户。可观察性程度取决于虚拟化类型：操作系统虚拟化或硬件虚拟化。
11.2 OS Virtualization
操作系统虚拟化将操作系统分区为行为类似于独立客户端服务器的实例，并且可以独立于主机进行管理和重启。这些为云客户提供高性能的服务器实例，为云运营商提供高密度的服务器。操作系统虚拟化的客户端示例如图11.4所示，使用Solaris Zones的术语。

这个图中显示了全局区域；这指的是主机操作系统，它可以看到所有的客户区域（也称为非全局区域）。
这种方法起源于Unix的chroot(8)命令，该命令将一个进程隔离到Unix全局文件系统的子树中（改变顶级目录，“/”）。1998年，FreeBSD将其进一步发展为FreeBSD jails，提供作为其自己服务器的安全隔间。2005年，Solaris 10包括了一个名为Solaris Zones的版本，具有各种资源控制。通过OpenSolaris和后来的SmartOS，区域已经投入到Joyent公共云的生产中。最近，对Linux进行了操作系统虚拟化项目，包括lxc Linux容器和OpenVirtuozzo（OpenVZ）。OpenVZ由Parallels, Inc.支持，并需要一个修改过的Linux内核。
与硬件虚拟化技术的关键区别在于只运行一个内核。这具有以下优点：
- 对于客户端应用I/O几乎没有性能开销，因为客户端应用可以直接对主机内核执行系统调用。
- 分配给客户端的内存可以完全用于客户端应用程序——没有额外的内核税，无论是来自操作系统的hypervisor还是其他客户端内核。
- 有统一的文件系统缓存——主机和客户端不会进行双重缓存。
- 所有客户端进程都可以从主机进行观察，允许调试它们之间的交互（包括资源争用）的性能问题。
- CPU是真正的CPU；自适应互斥锁的假设仍然有效。
但也存在缺点：
- 任何内核恐慌都会影响所有客户端。
- 客户端无法运行不同的内核版本。
为了运行不同的内核版本和不同的操作系统，您需要硬件虚拟化（在第11.3节，硬件虚拟化中有介绍）。操作系统虚拟化可以在一定程度上满足这种需求，通过提供替代的系统调用接口。一个例子是Solaris lx Branded Zones，它在Solaris内核下提供了Linux系统调用接口和应用环境。
以下部分描述了操作系统虚拟化的具体内容：开销、资源控制和可观察性。这些内容基于一个经历了多年生产使用的公共云（也很可能是全球最大的操作系统虚拟化云）：Joyent SmartOS 实现的 Zones。这些信息通常适用于所有操作系统虚拟化的实现，大部分差异在于资源控制的配置方式。例如，Linux lxc 容器可以使用 cgroups，用法类似于这里描述的用法。
11.2.1 Overhead
了解何时可以期望虚拟化引入性能开销，何时不可以，对于调查云性能问题至关重要。这种性能开销可以通过描述 CPU 执行开销、执行 I/O 的开销以及来自其他租户的影响来概括。
CPU
当线程在用户模式下运行时，CPU 执行开销为零。不需要同步仿真或模拟——线程直接在 CPU 上运行，直到它们被让出或被抢占。
虽然不经常调用——因此不受性能影响——从内核中列出系统状态等活动可能会产生一些额外的 CPU 开销，因为其他租户的统计信息被过滤。这包括通过状态工具（例如，prstat(1M)、top(1)）读取 /proc，这些工具遍历所有进程条目，包括其他租户，但仅返回过滤后的列表。这项工作的内核代码，来自 pr_readdir_procdir()，如下所示：

这是在当前系统上进行的测量，发现每 1,000 个进程条目额外花费 40 微秒。对于不经常发生的活动，这个成本是可以忽略的。（如果成本更高，内核代码将被更改。）
I/O
I/O 开销为零，除非已配置了额外的功能。为了让虚拟化的基本功能正常工作，软件栈中不需要额外的层次。这在图 11.5 中有所体现，该图比较了 Unix 进程和 Zones 的 I/O 路径。

以下显示了两个内核堆栈跟踪（使用 DTrace 获取）以传输网络数据包为例，分别是主机（裸机）和一个客户端（虚拟机）的：

这两者是相同的。如果有额外的层次，通常会在堆栈中出现额外的帧。
对于文件系统访问，可以配置区域挂载在回环文件系统上，而回环文件系统本身则挂载在主机文件系统上。这种策略用于稀疏根区域模型：一种在区域之间共享只读文件（例如，/usr/bin）的方法。如果使用回环文件系统，会产生一小部分文件系统 I/O 的 CPU 开销。
其他租户
其他正在运行的租户的存在可能会对性能产生一些影响，这些影响与虚拟化技术无关：
- CPU 缓存的命中率可能较低，因为其他租户正在使用和逐出缓存条目。
- CPU 执行可能会被中断，因为其他租户设备（例如，网络 I/O）正在执行中断服务例程。
- 其他租户可能会争夺系统资源（例如，磁盘、网络接口），这些资源正在被其他租户使用。
最后一个因素由资源控制进行管理。尽管这些因素在传统的多用户环境中存在，但它们在云计算中更为普遍。
11.2.2 Resource Controls
虽然操作系统虚拟化基础设施管理邻居之间的安全性，但资源控制则管理性能。表11.1描述了资源控制的范围，并以 Joyent 公共云配置的 SmartOS Zones 作为示例。这些被分类为限制和优先级，由云运营商或软件按照每个客户的要求进行设置。
限制是资源消耗的上限值。优先级引导资源消耗，根据重要性值平衡邻居之间的使用情况。根据需要使用其中任何一个——对于某些资源，这意味着两者都使用。

CPU
由于 OS 虚拟化的客户端可以直接“看到”系统上的所有物理 CPU，因此有时可以允许其使用 100% 的 CPU 资源。对于大部分处于空闲状态的 CPU 的系统而言，这使得其他客户端可以利用该 CPU，特别是用于处理短暂的需求高峰。Joyent 将这种能力称为 bursting；它帮助云客户在不需要昂贵的过度配置的情况下应对短期的高需求。
CPU 上限
上限可以限制客户端的 CPU 使用，防止 bursting，并以总 CPU 百分比的形式表达。一些客户端更倾向于使用此功能，因为它提供了一种一致的性能预期，可以简化容量规划。
对于其他客户端，根据 Joyent 的默认设置，CPU 上限会自动增加到客户端预期份额的多倍（例如，增加到八倍）。这允许客户端在 CPU 资源可用时进行 bursting。如果客户端持续进行 bursting 几小时或几天（通过监控确定），则可以鼓励客户端升级客户端规模，以便可靠地分配已消耗的 CPU，而不是依赖 bursting。
当客户端不知道自己正在进行 bursting 并可能持续数周时，这可能会导致问题。在某个时刻，另一个需要大量 CPU 的租户到来，也利用了空闲的 CPU，给第一个租户留下的可用资源减少，这将导致性能下降，可能会让第一个租户感到不满。这种情况类似于连续一个月乘坐经济舱，但幸运地总是有整排座位给自己使用，然后你登上一趟满员的航班。
可以通过禁用 bursting 来控制期望，就像在空余座位上放置土豆袋一样，以确保没有乘客习惯于有额外的空间。您的客户可能更希望您通过告知他们正在进行 bursting，而不是禁用此功能来管理期望。
CPU份额
份额可以通过公平份额调度器（FSS）来合理分配 CPU 资源。份额可以任意分配，用于计算在给定时间内繁忙客户端将获得的 CPU 量，计算公式如下：
客户端 CPU = 所有 CPU × 客户端份额 / 系统上总的繁忙份额
考虑一个系统，有 100 份额分配给几个客户端。在某一时刻，只有客户端 A 和 B 需要 CPU 资源。客户端 A 有 10 份额，客户端 B 有 30 份额。因此，客户端 A 可以使用系统上总 CPU 资源的 25%：所有 CPU × 10 /（10 + 30）。
对于 Joyent，每个客户端被分配的份额数量等于其内存大小（以 MB 为单位，因此与支付的价格相关）。大小翻倍的系统成本是之前的两倍，因此获得两倍的 CPU 份额。这确保了 CPU 资源在需要它们并为其支付的人之间公平分配。
CPU 上限也用于限制 bursting，以防期望过高。
内存容量
有两种类型的内存资源，每种都有自己的资源控制策略：主内存（RSS）和虚拟内存（VM）。这些也使用资源控制设施，由 resource_controls(5) man 页面描述，提供了一组可调参数用于资源控制。
主内存
限制主内存比听起来更棘手——强加硬限制与期望相违背。一旦 Unix 系统使用的主内存超过可用量，它就会开始分页（参见第七章，内存）。
在 SmartOS 中，这种行为通过 per-zone 管理守护进程 zoneadmd 中的一个线程来复制到客户端。它根据其内存资源控制 zone.max-physical-memory 提前分页客户端。它还通过延迟限制页入，以允许页出进行追赶来维持目标内存大小。
这个功能之前是由资源限制守护进程 rcapd 执行的，它是所有区域的单个进程（在有许多区域时无法扩展）。
虚拟内存
虚拟内存的资源控制属性是 zone.max-swap，在分配（malloc()）期间同步检查。对于 Joyent，这设置为主内存大小的两倍。一旦达到限制，分配将失败（“内存不足”错误）。
文件系统I/O
为了解决来自吵闹邻居的磁盘I/O问题，在ZFS中通过一项名为I/O限制的功能来控制I/O，该功能由Joyent的Bill Pijewski开发。这类似于针对CPU的FSS，它为区域分配份额，更公平地在租户之间平衡I/O资源。
它的工作原理是按比例限制正在执行最多磁盘I/O的租户，以减少他们与其他租户的竞争。实际的限制机制是在I/O完成之前向用户空间注入延迟。在这个时间点，线程通常已经阻塞等待I/O完成，额外延迟的注入会导致稍微较慢的I/O。
文件系统容量
本地文件系统有一个硬容量限制：由映射存储设备提供的总可用空间。通常希望将此容量划分给系统上的客户端，可以通过以下方式实现：
  有限大小的虚拟卷
  支持配额的文件系统（例如ZFS）
网络文件系统和存储也可以为文件系统容量提供限制，对于云服务提供商来说，这通常与定价挂钩。
磁盘I/O
当前的SmartOS区域通过对文件系统的访问来控制磁盘I/O。请参阅前文的文件系统I/O部分。
网络I/O
由于每个区域都配置有自己的虚拟网络接口，因此可以使用dladm(1M)中的maxbw（最大带宽）链路属性来限制吞吐量。通过flowadm(1M)可以更精细地控制网络I/O，它可以设置maxbw和优先级值，并且可以根据传输类型和端口匹配流量。Joyent目前不限制网络I/O（所有基础设施均为10 GbE，并且通常有大量带宽可用），因此只在网络中存在滥用者时手动设置这些资源控制。
11.2.3 Observability
使用操作系统虚拟化技术，默认情况下允许每个人都可以看到一切；必须施加限制以防止意外的安全泄漏。这些限制至少包括：
  作为客户端，/proc仅显示客户端中的进程。
  作为客户端，netstat仅列出客户端拥有的会话信息。
  作为客户端，文件系统工具仅显示客户端拥有的文件系统。
  作为客户端，无法通过区域管理工具列出其他区域。
  作为客户端，无法检查内核内部（没有DTrace fbt提供者或mdb -k）。
主机操作员可以查看一切：主机操作系统和所有客户端中的进程、TCP会话和文件系统。而从主机上，可以直接观察客户端活动 —— 而无需登录到每个客户端。
以下部分演示了主机和客户端可用的可观测工具，并描述了分析性能的策略。SmartOS及其可观测工具用于展示操作系统虚拟化应该提供的信息类型。
主机
当登录到主机时，可以使用前几章介绍的工具检查所有系统资源（CPU、内存、文件系统、磁盘、网络）。在使用区域时，有两个额外因素需要考虑：
每个区域的统计信息
资源控制的影响
检查每个区域的统计信息有时会提供一个-Z选项。例如：

第一列显示区域名称（被截断以适应）。
prstat(1M)命令也支持-Z选项：

顶部部分（被截断）通常显示一个进程列表，最消耗CPU的进程在顶部。底部部分是每个区域的摘要，显示以下信息：
SWAP：区域虚拟内存大小总计
RSS：区域驻留集大小总计（主内存使用量）
MEMORY：主内存消耗，作为系统范围资源的百分比
CPU：CPU消耗，作为系统范围资源的百分比
ZONE：区域名称
这是一个用于云计算的系统（称为计算节点），托管了超过十几个动态创建的区域。每个区域都有一个自动生成的UUID作为其区域名称（如b8b2464c……）。
zonememstat(1M)工具显示每个区域的内存使用情况：

这包括：
CAP(MB)：配置的资源控制限制
NOVER：区域超出限制的次数
POUT(MB)：已分页出的数据总量，用于保持区域处于其限制之内
POUT(MB)中的值增加通常表明客户端的应用程序配置错误，尝试使用超出客户端可用内存的内存量，因此应用程序正在被rcapd或zoneadmd分页出去。
其他资源控制（CPU、ZFS I/O限制和网络限制）的信息可以从kstat(1M)和prctl(1)中获取。
如果需要，还可以从主机执行进一步的分析，包括检查客户端应用程序的调用堆栈和内部。主机管理员可以识别任何性能问题的根本原因，而无需登录客户端。
客户端
客户端应仅看到其进程和活动的特定详细信息。经过修改以实现此功能的可观察性工具被称为“区域感知”。/proc文件系统，如ps(1)和prstat(1M)所使用的，仅包含该区域的进程，使这些工具成为区域感知的工具。
只要不泄漏私有细节，客户端可以观察共享系统资源。例如，客户端可以直接观察所有物理CPU和磁盘（mpstat(1M)、iostat(1M)），以及系统范围的内存使用情况（vmstat(1M)）。
例如，在查看空闲区域的磁盘I/O时：

对于刚接触操作系统虚拟化的人来说，这可能有些令人困惑——为什么磁盘忙碌？这是因为iostat(1)显示的是物理磁盘，包括其他租户的活动。此类命令称为系统范围命令（即不是区域感知的）。
要仅检查此区域引起的磁盘使用情况，可以检查来自VFS级别的统计信息：

这证实了该区域（几乎）处于空闲状态——每秒读取4.5K字节（这可能是由文件系统缓存，不引起任何磁盘I/O）。
mpstat(1M)也是系统范围的：

它显示所有物理CPU，包括其他租户的活动。
prstat -Z 摘要是显示客户端 CPU 使用情况的一种方法（当从非全局区域运行时，其他客户端不会列出）：

还有来自 kstat 的计数器，显示 CPU 使用情况以及限制。
最终，这种物理资源的可观察性为客户端提供了有用的性能分析统计信息，这些信息可能有助于排除某些类型的问题（包括嘈杂的邻居）。这与硬件虚拟化有着重要的区别，后者将物理资源隐藏在客户端中。
策略
前几章介绍了针对物理系统资源的分析技术，包括各种方法论。这些可以供主机操作员遵循，而在一定程度上也适用于客户端，但要记住之前提到的限制。对于客户端来说，通常可以观察到高级资源使用情况，但无法深入到内核中。
除了物理资源外，资源控制所施加的云限制也应由主机操作员和客户端租户检查。由于这些限制在物理限制之前就出现了，因此更有可能生效，可以首先进行检查。
由于许多传统的可观测性工具是在资源控制出现之前创建的（例如，top(1) 和 prstat(1M)），它们默认不包含资源控制信息，用户可能会忘记用其他包含这些信息的工具来检查它们。下面是检查每种资源控制的一些评论和策略：
CPU：对于容量，可以将当前 CPU 使用情况与容量值进行比较。遇到容量时，线程在可运行状态时会等待，这可以观察到作业调度的延迟。一开始可能会感到困惑，因为物理系统可能有大量空闲 CPU。
内存：对于主内存，检查当前使用量是否超过限制。一旦达到限制，将从 zoneadmd 进行页面出。这可能会被注意到为匿名页面和线程在数据错误中花费的时间。一开始也可能会感到困惑，因为系统页面调度器可能没有激活（vmstat 中看不到 sr），而物理系统可能有大量空闲内存。
文件系统 I/O：高 I/O 率可能会被限制，导致平均延迟略微增加。可以通过使用 vfsstat(1M) 工具观察到这一点。
文件系统容量：这应该与任何其他文件系统一样可观察（包括使用 df(1M)）。
磁盘 I/O：参见文件系统 I/O。
网络 I/O：检查当前网络吞吐量是否超过带宽限制，如果已配置。遇到限制会导致网络 I/O 延迟增加，因为租户会被限制到其容量。
对于 SmartOS Zones，已开发了一种 USE 方法清单，首先分析资源控制，然后是物理资源。
监控软件
应该注意的是，许多为独立系统编写的监控工具尚未开发支持操作系统虚拟化。试图在客户端中使用这些工具的客户可能会发现，它们似乎可以工作，但实际上显示的是物理系统资源，基于这些工具一直以来所基于的相同计数器。在没有支持观察云资源控制的情况下，这些工具可能会错误地报告系统有余地，而实际上它们已经达到了资源限制。它们也可能显示高资源使用率，实际上是由于其他租户所致。
11.3 Hardware Virtualization
硬件虚拟化创建系统虚拟机实例，可以运行完整的操作系统，包括它们的内核。硬件虚拟化的类型包括以下几种：
全虚拟化 - 二进制翻译：提供一个完整的虚拟系统，由虚拟化的硬件组件组成，可以安装未修改的操作系统。VMware 在 1998 年为 x86 平台率先实现了这一技术，它在需要时使用直接处理器执行和二进制指令翻译的混合方式。通常情况下，由于服务器整合带来的节省，性能开销是可以接受的。
全虚拟化 - 硬件辅助：提供一个完整的虚拟系统，由虚拟化的硬件组件组成，可以安装未修改的操作系统。这使用处理器支持更有效地执行虚拟机，特别是在 2005-2006 年引入的 AMD-V 和 Intel VT-x 扩展。
半虚拟化：提供一个虚拟系统，其中包含一个接口，供客户操作系统通过超级调用有效地使用主机资源，而无需对所有组件进行全虚拟化。例如，启用定时器通常涉及多个特权指令，必须由超级调用器模拟。这可以简化为半虚拟化客户机的单个超级调用。半虚拟化可能包括客户操作系统使用半虚拟化网络设备驱动程序，以更有效地将数据包传递给主机中的物理网络接口。虽然性能有所提高，但这取决于客户操作系统对半虚拟化的支持（历史上 Windows 并未提供）。
另一种类型，混合虚拟化，当某些情况下半虚拟化调用更有效时，同时使用硬件辅助虚拟化，旨在提供最佳性能。半虚拟化最常见的目标是虚拟设备，例如网络卡和存储控制器。
虚拟机由 hypervisor 创建和执行，hypervisor 可以是软件、固件或硬件实现。
硬件虚拟化的客户机如图 11.6 所示。

这显示了两种类型的hypervisors [Goldberg 73]：
Type 1 直接在处理器上执行，而不是作为另一主机的内核级或用户级软件。Hypervisor管理可以由特权客户（在此系统中表示为第一个：编号为0）执行，该客户可以创建和启动新的客户机。Type 1 也被称为本地hypervisor或裸金属hypervisor。这个hypervisor包含了自己的CPU调度器用于客户机VMs。
Type 2 由主机操作系统内核执行，可能由内核级模块和用户级进程组成。主机操作系统具有管理hypervisor和启动新客户机的权限。这个hypervisor由主机内核调度器调度。
硬件虚拟化有许多不同的实现。关键示例包括：
VMware ESX：首次发布于2001年，VMware ESX是用于服务器整合的企业产品，并且是VMware vSphere云计算产品的关键组件。其hypervisor是在裸金属上运行的微内核，第一个虚拟机被称为服务控制台，可以管理hypervisor和新的虚拟机。
Xen：于2003年首次发布，Xen起源于剑桥大学的一个研究项目，后来被Citrix收购。Xen是一种类型1的hypervisor，为了高性能而运行paravirtualized客户机；后来增加了对硬件辅助客户机的支持，以支持未修改的操作系统（Windows）。虚拟机被称为域，最高权限的是dom0，从中管理hypervisor并启动新域。Xen是开源的，可以从Linux启动。（曾经存在适用于Solaris的版本；但是，Oracle现在更倾向于Oracle VM Server。）亚马逊弹性计算云（EC2）和Rackspace Cloud基于Xen。
KVM：由Qumranet开发，2008年被Red Hat收购。KVM是一种类型2的hypervisor，作为内核模块执行。它支持硬件辅助扩展，并且为某些设备（在客户操作系统支持的情况下）使用para虚拟化以获得高性能。为了创建完整的硬件辅助虚拟机实例，它与一个名为QEMU（Quick Emulator）的用户进程配对。QEMU最初是由Fabrice Bellard编写的高质量开源类型2的hypervisor，通过二进制翻译。KVM是开源的，并已移植到illumos和FreeBSD。Joyent公共云的Linux和Windows实例使用KVM（SmartOS实例使用OS虚拟化）。Google还使用KVM驱动Google计算引擎。
以下各节描述了硬件虚拟化的主题：开销、资源控制和可观测性。这些因实现方式而异，而不仅限于先前列出的三种。请查看您的实现以了解具体情况。
11.3.1 Overhead
硬件虚拟化是由hypervisor以各种方式实现的。这些硬件虚拟化技术在客户操作系统尝试访问硬件时会增加开销：命令必须从虚拟设备转换为物理设备。在研究性能时必须理解这些转换；它们可能因硬件虚拟化的类型和实现方式而异。这些差异可以通过描述CPU执行、内存映射、执行I/O以及其他租户的影响来概括。
CPU
总的来说，客户应用程序直接在处理器上执行，CPU密集型应用程序接近裸金属系统的性能。在进行特权处理器调用、访问硬件和映射主内存时可能会遇到开销。
以下是不同的硬件虚拟化类型：
二进制翻译：识别并翻译在物理资源上运行的客户内核指令。在硬件辅助虚拟化出现之前，使用了二进制翻译。在没有硬件虚拟化支持的情况下，VMware采用的方案涉及在处理器ring 0中运行虚拟机监视器（VMM），并将客户内核移动到以前未使用的ring 1中（应用程序在ring 3中运行，大多数处理器提供四个ring）。由于一些客户内核指令假设它们在ring 0中运行，因此为了从ring 1中执行，它们需要被翻译，调用VMM以应用虚拟化。这种翻译是在运行时执行的。
Para虚拟化：在客户操作系统中必须虚拟化的指令被替换为对hypervisor的超级调用。如果客户操作系统被修改以优化超级调用，使其意识到自己正在虚拟化的硬件上运行，性能可以得到提升。
硬件辅助：在硬件上运行的未修改的客户内核指令由hypervisor处理，后者在低于ring 0的ring级别运行VMM。与翻译二进制指令不同，客户内核特权指令被强制转移到更高特权的VMM，后者可以模拟特权以支持虚拟化。硬件辅助虚拟化通常是首选的，取决于实现和工作负载，而Para虚拟化用于提高某些工作负载的性能（特别是I/O），如果客户操作系统支持的话。
作为实现差异的示例，VMware的二进制翻译模型经过多年的优化，正如他们在2007年所写的那样：
由于高的hypervisor到客户机转换开销和严格的编程模型，VMware的二进制翻译方法目前在大多数情况下优于第一代硬件辅助实现。第一代实现中的严格编程模型几乎没有余地来灵活管理hypervisor到客户机转换的频率或成本。
可以将客户和hypervisor之间的转换率以及在hypervisor中花费的时间作为CPU开销的度量进行研究。这些事件通常被称为客户退出，因为虚拟CPU在发生这种情况时必须停止在客户内部执行。图11.7显示了与在KVM中的客户退出相关的CPU开销。

该图显示了客户退出在用户进程、主机内核和客户之间的流动。在处理退出时花费在客户之外的时间是硬件虚拟化的CPU开销；处理退出所花费的时间越多，开销就越大。当客户退出时，一部分事件可以直接在内核中处理。那些无法处理的事件必须离开内核并返回到用户进程；这与内核可以处理的退出相比，会引发更大的开销。
例如，在Joyent使用的KVM实现中，这些开销可以通过其客户退出进行研究，这些退出在源代码中映射到以下函数（来自kvm_vmx.c）：

虽然这些名称简洁，但它们可能提供了客户调用到hypervisor的原因，从而产生CPU开销的想法。
一个常见的客户退出是halt指令，通常由空闲线程调用，当内核找不到更多工作要执行时（这允许处理器在被中断之前以低功耗模式运行）。它由handle_halt()（kvm_vmx.c）处理，这里包含了相关代码的概念：

该代码调用kvm_emulate_halt() (kvm_x86.c)：

与许多客户退出类型一样，代码保持简洁以最小化CPU开销。
这个示例从KVM_VCPU_KSTAT_INC()宏开始，该宏设置了一个kstat计数器，以便观察halt的频率。（这是从Linux版本移植过来的，该版本设置了一个内置计数器用于相同的目的。）剩余的代码执行了这个特权指令所需的硬件仿真。这些函数可以在hypervisor上使用DTrace进行研究，以跟踪它们的类型和退出的持续时间。
虚拟化硬件设备，如中断控制器和高分辨率定时器，也会产生一些CPU（和少量DRAM）开销。
Memory Mapping
如第7章内存所述，操作系统与MMU合作，从虚拟内存到物理内存创建页面映射，并将其缓存在TLB中以提高性能。对于虚拟化，将来自客户机到硬件的新内存页面映射（页面错误）涉及两个步骤：
1. 由客户机内核执行的虚拟到客户机物理的转换
2. 由hypervisor VMM执行的客户机物理到主机物理（实际）转换
然后，从客户机虚拟到主机物理的映射可以被缓存到TLB中，这样后续访问就可以以正常速度运行，而不需要额外的转换。现代处理器支持MMU虚拟化，以便已经离开TLB的映射可以在硬件中更快地被回收（页面漫游），而无需调用到hypervisor。支持这一功能的特性称为Intel上的扩展页表（EPT）和AMD上的嵌套页表（NPT）[9]。
如果没有EPT/NPT，提高性能的另一种方法是维护客户机虚拟到主机物理映射的影子页表，由hypervisor管理，然后在客户执行期间通过覆盖guest的CR3寄存器进行访问。采用这种策略，客户机内核维护其自己的页表，将其从客户机虚拟到客户机物理进行映射，就像正常情况下一样。hypervisor拦截对这些页表的更改，并在影子页中创建等效的映射到主机物理页面。然后，在客户执行期间，hypervisor将CR3寄存器重写为指向影子页。
内存大小
与操作系统虚拟化不同，使用硬件虚拟化时会有一些额外的内存消耗者。每个客户机运行自己的内核，消耗了一小部分内存。存储架构也可能导致双重缓存，即客户机和主机都缓存相同的数据。
I/O
虚拟化的一个关键成本是执行设备I/O的开销。与CPU和内存I/O不同，其中可以设置共同路径以以裸金属方式执行，每个设备I/O必须由hypervisor进行转换。对于高频率的I/O，例如10 Gbit/s的网络，每个I/O（数据包）的一小部分开销可能会导致性能的显著总体降低。
使用para虚拟化可以在一定程度上缓解I/O开销，其中客户机内核驱动程序已经修改以在虚拟化环境中有效运行，合并I/O并执行更少的设备中断以减少hypervisor的开销。
另一种技术是PCI直通，它直接将PCI设备分配给客户机，因此可以像在裸金属系统上一样使用。PCI直通可以提供可用选项中的最佳性能，但在配置具有多个租户的系统时会降低灵活性，因为某些设备现在由客户机拥有并且不能共享。这也可能使在线迁移复杂化。
有一些技术可以提高使用虚拟化的PCI设备的灵活性，包括单根I/O虚拟化（SR-IOV）和多根I/O虚拟化（MR-IOV）。这些术语指的是暴露的根复杂PCI拓扑的数量，以不同的方式提供硬件虚拟化。它们的使用取决于硬件和hypervisor的支持。
作为设备I/O的示例，Xen（类型1 hypervisor）和KVM（类型2 hypervisor）如图11.8所示。

GK是“guest kernel”，在Xen上的domU运行客户机操作系统。其中一些箭头表示控制路径，其中组件彼此通知更多数据已准备好传输，可以同步或异步地进行。数据路径在某些情况下可以通过共享内存和环形缓冲区实现。这些技术有各种变化。在此图中，两者都使用I/O代理进程（通常为QEMU软件），为每个客户机VM创建。
I/O路径中的步骤数，无论是控制还是数据，对性能至关重要：步骤越少越好。2006年，KVM开发人员将特权客户系统（如Xen）与KVM进行了比较，并发现KVM可以使用更少的步骤进行I/O（五个步骤对比十个步骤，尽管该测试是在没有para虚拟化的情况下进行的，因此不反映大多数现代配置）。
Xen通过设备通道提高其I/O性能——这是dom0和客户域（domU）之间的异步共享内存传输。这避免了在dom之间传递I/O数据时执行额外拷贝的CPU和总线开销。它还可以使用单独的dom来执行I/O，如第11.3.2节“资源控制”所述。
在任一情况下，可以使用para虚拟化的客户机驱动程序来改善I/O性能，该驱动程序可以为虚拟化的I/O路径应用最佳缓冲和I/O合并。
其他租户
与操作系统虚拟化类似，存在其他租户可能会导致CPU缓存变得不够热，当其他租户被调度和服务时，可能会发生客户机运行时的中断，包括设备中断。资源争用可以通过资源控制来管理。
11.3.2 Resource Controls
作为客户机配置的一部分，CPU和主内存通常会配置资源限制。Hypervisor软件也可能提供网络和磁盘I/O的资源控制。
对于类型2的Hypervisor，主机操作系统最终控制物理资源，并且除了Hypervisor提供的控制外，还可以应用来自操作系统的资源控制（如果有的话）到客户机上。
例如，Joyent配置KVM客户机在SmartOS Zones内运行，允许应用第11.2节“操作系统虚拟化”中列出的资源控制，包括ZFS I/O限制。这是KVM限制的补充，为控制资源使用提供了更多的选项和灵活性。它还将每个KVM实例封装在自己的高度安全的区域中，提供多重边界的安全保护，这种技术被称为双层虚拟化。
可用的选项取决于Hypervisor软件、类型以及对于类型2的Hypervisor，主机操作系统。请参阅第11.2节“操作系统虚拟化”，了解主机操作系统可能提供的资源控制类型。下面的部分将以Xen和KVM Hypervisor为例，描述资源控制。
CPU
CPU资源通常被分配给客户机作为虚拟CPU（vCPU）。然后由Hypervisor进行调度。分配的vCPU数量粗略地限制了CPU资源的使用。
对于Xen，可以通过Hypervisor的CPU调度器应用细粒度的客户机CPU配额。调度器包括（[Cherkasova 07]，[Matthews 08]）
- 借用虚拟时间（BVT）：基于虚拟时间分配的公平共享调度器，可以提前借用虚拟时间，以提供低延迟的实时和交互式应用程序执行
- 简单最早截止期优先（SEDF）：实时调度器，允许配置运行时保证，调度器优先考虑最早的截止期
- 基于信用的：支持CPU使用的优先级（权重）和上限，并在多个CPU间进行负载均衡
对于KVM，可以通过主机操作系统应用细粒度的CPU配额，例如，在先前描述的主机内核公平共享调度器中使用。在Linux上，这可以使用cgroup CPU带宽控制来实现。
无论是哪种技术，都存在对客户机优先级的限制。客户机的CPU使用通常对Hypervisor不透明，客户机内核线程优先级通常无法被看到或受到尊重。例如，Solaris内核定期使用后台fsflush守护进程扫描内存的情况可能与另一个客户机中的关键应用服务器具有相同的Hypervisor优先级。
对于Xen，CPU资源的使用可能会因在dom0中消耗额外CPU资源的高I/O工作负载而变得更加复杂。客户机域中的后端驱动程序和I/O代理可能单独消耗超过它们的CPU分配的资源，但这些资源没有被计入[Cherkasova 05]。一个解决方案是创建隔离的驱动程序域（IDDs），这将I/O服务隔离出来，以实现安全性、性能隔离和计费。这在图11.9中有所描述。

IDDs的CPU使用情况可以进行监控，并且可以对客户机进行收费以反映这种使用情况。来自[Gupta 06]：
我们修改的调度器，SEDF-DC（SEDF-Debt Collector），周期性地从XenMon接收有关由IDDs代表客户机域进行I/O处理而消耗的CPU的反馈。利用这些信息，SEDF-DC限制了对客户机域的CPU分配，以满足指定的组合CPU使用限制。
在Xen中使用的一种较新的技术是存根域（stub domains），这些域运行着一个迷你操作系统。
内存容量
内存限制是作为客户机配置的一部分强加的，客户机只能看到设置的内存量。然后，客户机内核执行自己的操作（分页、交换）以保持在其限制范围内。
为了增加从静态配置中的灵活性，VMware开发了所谓的气球驱动程序[Waldspurger 02]。它能够通过在其中“膨胀”一个气球模块来减少运行中客户机所消耗的内存，该模块消耗客户机内存。然后，Hypervisor会将此内存收回，供其他客户机使用。气球也可以被放气，将内存返还给客户机内核使用。在此过程中，客户机内核执行其正常的内存管理例程以释放内存（例如，分页）。VMware、Xen和KVM都支持气球驱动程序。
文件系统容量
客户机从主机处获得虚拟磁盘卷，这些卷在客户机配置期间从存储磁盘池（使用ZFS）中创建，大小由所需大小确定。从这些磁盘卷中，客户机创建文件系统并管理其自己的空间，受配置卷大小的限制。执行此操作的确切细节取决于虚拟化软件和存储配置。
设备I/O
硬件虚拟化软件的资源控制历来专注于控制CPU使用量，这可以间接控制I/O使用量。网络吞吐量可以通过外部专用设备进行限制，或者在类型2的Hypervisor中，可以通过主机内核特性进行限制。例如，illumos内核支持网络带宽资源控制，理论上可以应用于客户机虚拟网络接口。Linux具有来自cgroups的网络带宽控制，可以以类似的方式使用。
Xen的网络性能隔离已经进行了研究，得出以下结论[Adamczyk 12]：
……当考虑网络虚拟化时，Xen的弱点是其缺乏适当的性能隔离。
[Adamczyk 12]的作者还为Xen网络I/O调度提出了解决方案，其中添加了用于网络I/O优先级和速率的可调参数。如果您使用Xen，请检查是否已提供此类或类似技术。
对于硬件虚拟化，磁盘和文件系统I/O技术也正在发展中。检查您的软件版本以了解可用内容，并且对于类型2的Hypervisor，还要检查主机操作系统提供了哪些资源控制。例如，Joyent的KVM客户机使用了早期描述的ZFS I/O限制技术对磁盘I/O进行限制。
11.3.3 Observability
可观察性取决于Hypervisor的类型和启动观察工具的位置。一般来说：
从特权客户机（类型1）或主机（类型2）：可以使用标准操作系统工具观察所有物理资源，并从I/O代理观察I/O。来自操作系统或虚拟化软件应提供每个客户机资源使用情况的统计数据。客户机内部，包括其进程，不能直接被观察。
从客户机：通常情况下，不可观察物理资源及其使用情况。可以看到客户机使用的虚拟化资源及其使用情况。从特权客户机或主机，可以在高级别上观察物理资源的使用情况：利用率、饱和度、错误、IOPS、吞吐量、I/O类型。这些因素通常可以按客户机进行表达，因此可以快速识别出资源使用量大的用户。不能直接观察执行I/O的客户机进程及其应用程序调用堆栈的细节。这些可以通过登录到客户机（如果授权且已配置了手段，例如SSH）并使用客户机操作系统提供的观察工具来观察。
为了确定客户机性能问题的根本原因，云操作员可能需要登录到特权客户机或主机和客户机，并从两者执行观察工具。由于涉及的步骤，追踪I/O路径变得复杂，并且可能还包括对Hypervisor和I/O代理的分析。
从客户机，物理资源使用可能根本无法观察。这可能导致客户机用户将神秘的性能问题归咎于被不可见的吵闹邻居使用的物理资源。为了让云客户放心（并减少支持工单），有关物理资源使用情况的信息（已编辑）可以通过其他手段提供，包括SNMP或云API。
以下部分展示了可以从不同位置使用的观察工具，并描述了性能分析策略。使用Xen和KVM演示虚拟化软件可能提供的信息类型。
特权客户机/主机
所有系统资源（CPU、内存、文件系统、磁盘、网络）应该可以使用前几章介绍的工具进行观察。
KVM
对于类型2的Hypervisor，客户机实例在主机操作系统中是可见的。例如，在SmartOS上使用KVM：

QEMU进程是KVM客户机，其中包括每个虚拟CPU的线程和用于I/O代理的线程。它们的CPU使用情况可以在上述prstat(1M)输出中看到，并且可以使用其他prstat(1M)选项（-mL）来检查每个虚拟CPU的使用情况。将QEMU进程映射到其客户机实例名称通常是通过检查它们的进程参数（pargs(1)）以读取-name选项来完成的。
另一个重要的分析领域是客户机虚拟CPU退出。发生的退出类型可以显示客户机正在执行的操作：特定虚拟CPU是空闲的、执行I/O还是执行计算。在Linux上，这些信息被收集并且可以通过debugfs文件系统访问，并且可以使用诸如perf(1)之类的工具。在SmartOS上，这些信息被收集在kstats中，并且可以使用kvmstat(1)工具进行总结。

前两个字段标识特定虚拟机内的虚拟CPU。其余列描述了退出的总数，并将它们分解成一般类别。最后几列描述了虚拟CPU上的其他活动。kvmstat(1)在其帮助消息中描述了这些列：
- pid：控制虚拟CPU的进程标识符
- vcpu：相对于其虚拟机的虚拟CPU标识符
- exits：虚拟CPU的虚拟机退出
- haltx：由于HLT指令而导致的虚拟机退出
- irqx：由于挂起的外部中断而导致的虚拟机退出
- irqwx：由于打开的中断窗口而导致的虚拟机退出
- iox：由于I/O指令而导致的虚拟机退出
- mmiox：由于内存映射I/O而导致的虚拟机退出
- irqs：注入到虚拟CPU中的中断
- emul：在内核中模拟的指令
- eptv：扩展页面表违规
虽然操作员可能不容易直接查看到虚拟客户机内部，但检查退出可以帮助您描述硬件虚拟化的开销是否会影响租户。如果您看到退出数量较少，而其中高比例是haltx，则说明客户机CPU相当空闲。另一方面，如果您有大量I/O操作，中断既被生成又被注入到客户机中，那么很可能客户机正在通过其虚拟网卡和磁盘进行I/O操作。
Xen
对于类型1的hypervisor，客户机的虚拟CPU存在于hypervisor中，并且无法通过特权客户机（dom0）使用标准操作系统工具进行查看。对于Xen，可以使用xentop(1)工具代替：

字段包括：
- CPU(%)：CPU使用率百分比（多个CPU的总和）
- MEM(k)：主内存使用量（千字节）
- MEM(%)：系统内存的主内存使用百分比
- MAXMEM(k)：主内存限制大小（千字节）
- MAXMEM(%)：主内存限制占系统内存的百分比
- VCPUS：分配的虚拟CPU数量
- NETS：虚拟化网络接口的数量
- NETTX(k)：网络传输量（千字节）
- NETRX(k)：网络接收量（千字节）
- VBDS：虚拟块设备的数量
- VBD_OO：虚拟块设备请求被阻塞并排队的数量（饱和度）
- VBD_RD：虚拟块设备读取请求的数量
- VBD_WR：虚拟块设备写入请求的数量
xentop输出默认每3秒更新一次，并可以使用-d delay_secs选项进行选择。
高级可观测性
对于扩展的hypervisor分析，有许多选择。在Linux上，perf(1)提供了用于KVM和Xen的tracepoints，可用于调查各种事件。以下是Xen tracepoints的示例列表：

此外，还有xentrace(8)工具，它可以从hypervisor中检索固定事件类型的日志，然后可以使用xenanalyze查看。该日志可用于调查hypervisor和CPU调度程序的调度问题。
对于KVM，可以使用DTrace以自定义方式检查hypervisor的内部，包括kvm内核主机驱动程序和QEMU进程、主机内核调度程序、主机设备驱动程序以及与其他租户的交互。例如，以下DTrace脚本（kvmexitlatency.d [12]）的输出跟踪KVM客户机退出延迟，并为每种类型打印分布图：

在这个例子中，所有的退出都在64微秒及以下，大多数在2微秒到16微秒之间。
提升hypervisor的可观测性是一个持续的过程，工具如perf(1)和DTrace扩展了可见范围的极限。其中一个例子是CR3分析。
CR3分析
由于Intel的VT-x指令集支持硬件辅助虚拟化，每个虚拟CPU都有一个虚拟机控制结构（VMCS）。VMCS包含了虚拟CPU的寄存器状态的副本，DTrace可以查询这些状态。系统上的每个进程都有自己的地址空间和一组描述虚拟到物理内存转换的页表。这些页表的根存储在寄存器CR3中。通过使用DTrace的profile提供程序，您可以从客户虚拟机中对CR3寄存器进行采样。如果经常看到特定的CR3值，那么您就知道在客户虚拟机中有一个特定的进程在CPU上非常活跃。尽管目前无法将此CR3值映射为可读的内容（如进程名称），但其数值确实唯一标识了客户虚拟机中的一个进程，可以用于理解系统的一般趋势。
Joyent的Cloud Analytics中的图11.10是CR3样本的可视化示例，显示了两个CPU密集型进程的客户内核调度活动。
这种可视化是一个亚秒偏移的热度图，每秒用采样数据绘制垂直列。右侧是扭曲的棋盘格图案，显示了两个不同的CR3交替在CPU上，这是由于两个不同的客户进程。

Guest
来自虚拟机的视角，只能看到虚拟设备。最有趣的度量是延迟，显示了设备在虚拟化、限制和其他租户的情况下的响应方式。像百分比忙碌这样的度量指标在不知道底层设备是什么的情况下很难解释。
在Linux上，vmstat(8)命令包括一个用于CPU百分比被窃取（st）的列，这是一个虚拟化感知统计数据的罕见例子：

在这个例子中，测试了一个具有激进CPU限制策略的Xen虚拟机。在前4秒内，超过90%的CPU时间都在虚拟机的用户模式下，只有少部分被其他租户窃取。然后，这种行为开始迅速改变，大部分CPU时间被其他租户窃取。
策略
前几章已经介绍了针对物理系统资源的分析技术，这些技术可供物理系统管理员使用，用于寻找瓶颈和错误。还可以检查对客户虚拟机施加的资源控制，以确定客户虚拟机是否始终达到其限制，并通知并鼓励他们进行升级。如果管理员没有登录客户虚拟机，则可能无法识别更多问题，而这在进行任何严肃的性能调查时可能是必要的。
对于客户虚拟机，可以应用前几章介绍的分析资源的工具和策略，但需要记住，这种情况下的资源是虚拟的。由于虚拟化管理程序的未见资源控制或其他租户的竞争，某些资源可能没有达到其限制。理想情况下，云软件或供应商应提供一种方式，使客户能够检查修正后的物理资源使用情况，以便他们可以独立进一步调查性能问题。如果没有提供此功能，则可能需要根据I/O和CPU调度延迟的增加推断资源竞争和限制。这种延迟可以在系统调用层或客户虚拟机内核中进行测量。
11.4 Comparisons
比较技术可以帮助你更好地了解它们，即使你没有改变公司所使用技术的权力。本章讨论的三种技术在表11.2中进行了比较。

虽然随着这些虚拟化技术的不断发展，这张表会变得过时，但它仍然可以用来展示需要注意的事项，即使是在开发了完全新的不符合这些类别的虚拟化技术时也是如此。
虚拟化技术经常使用微基准测试进行比较，以确定哪种性能最佳。不幸的是，这种方法忽视了可观察性能力，而这可能是所有性能增益中最大的（通过识别和消除不必要的工作）。考虑以下常见情景：一个新的云客户错误配置了一个应用程序，导致它消耗了过多的主内存并被分页或交换出去。通过操作系统虚拟化，云管理员可以轻松地定位到这一问题（参见早期的zonememstat(1M)命令），他们还可以查看到负责的进程、应用程序的堆栈跟踪，以及通常也可以看到配置文件，从而在不登录到客户虚拟机的情况下识别根本原因。对于硬件虚拟化，云管理员只能看到来自客户虚拟机的磁盘I/O，这可能看起来像任何其他磁盘I/O，被误认为是正常活动。客户虚拟机已经用尽内存并正在进行分页或交换这一情况无法在不登录到客户虚拟机的情况下识别，而这需要进行身份验证。
另一个需要考虑的因素是维护复杂性。在操作系统虚拟化中，维护成本最低，因为只有一个内核需要维护。对于半虚拟化，维护成本很高，因为客户虚拟机操作系统必须提供半虚拟化支持，需要进行内核更改。
对于Joyent公共云，我们更喜欢使用操作系统虚拟化（Zones），因为它提供了高性能和可观察性能力，只要我们的客户应用程序可以在SmartOS上运行。当需要其他客户虚拟机操作系统（Linux、Windows）时，我们使用带有半虚拟化的KVM，知道对于I/O密集型工作负载，性能可能会较差。我们尝试过Xen，但已经将其替换为Joyent KVM端口。