Amazon AWS的Nitro软硬件系统，给了业界最大的一个创新点。DPU/IPU都可以认为是这件事情的延续。本文重点介绍AWS如何从传统的虚拟化逐步迭代到完全硬件虚拟化的NITRO系统。

站在（计算机）虚拟化的视角：

• 云计算场景，为了充分利用硬件的资源和性能，需要虚拟化技术，可以说虚拟化是云的基础功能。计算机主要包括CPU+Mem+I/O，因此虚拟化性能优化也主要就是这三者。

• 最开始的虚拟化都是软件模拟虚拟化，性能很差。后来Intel VT-x和AMD-V技术解决了CPU和内存的完全硬件虚拟化，提升了整个虚拟化系统的性能。这个时候，虚拟化技术解决了CPU和Memory的性能优化，只剩下I/O依然是软件虚拟化或类虚拟化。

• 接着，PCIe SR-IOV技术以及Intel VT-d的Pass Though等CPU的技术协助，共同实现了I/O的完全硬件虚拟化。

• I/O完全硬件虚拟化，引起了复杂的连锁反应：以前在Hypervisor侧的Backend Workload（用于支撑云计算的IaaS基础功能，如虚拟网络OVS、分布式存储Client等），此刻没法进行处理，势必要跟着I/O接口一起，offload到硬件中（I/O接口可以看做是qemu的接口emulator offload到硬件接口）。

• 未来，软硬件融合的虚拟化技术会持续演进迭代，最终进化到大家现在听到的DPU/IPU等概念的基础设施硬件加速平台。

AWS EC2虚拟化：Nitro介绍

布伦丹格雷格, 2017年11月29日

http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html

云计算的硬件虚拟化已经取得了长足的进步，使用VT-x、SR-IOV、VT-d、NVMe 和 APICv 等技术提高了性能。在Netflix，我们一直在使用这些技术，因为它们已可用于AWS EC2云中的实例类型。最新的AWS Hypervisor Nitro提供全新的硬件辅助管理程序，该Hypervisor易于使用，且具有接近裸机的性能。这是云计算中令人兴奋的发展：硬件虚拟化现在速度很快。

我已经用上图总结了EC2中管理程序的开发。这些列显示了实例性能的维度，按照Netflix 典型工作负载的重要性排序（CPU 绑定是最重要的）。此表的行是虚拟化类型，单元格显示虚拟化类型并按预期性能着色。

您可能首先注意到，随着时间的推移，绿色从左侧悄悄渗入。这是刻意的工程：首先优化最重要的工作负载。每个维度都经历了以下阶段：

1. 软件虚拟化：

   虽然这可以支持未经修改的Guest操作系统，但许多操作是模拟的并且速度很慢。

   应用程序的运行速度可能会慢2到10倍，甚至更糟。

2. 类虚拟化（Para-Virtualization）：

   Hypervisor提供高效的hypercall，Guest操作系统使用驱动程序和内核修改来调用这些Hypercall。

   它使用软件以及Hypervisor和Guest之间的协调来提高性能。

   我希望有 10% 到 50% 的可衡量开销（取决于 PV 类型和工作负载）。

3. 硬件虚拟化：

   硬件支持虚拟化，接近裸机速度。

   我预计会有 0.1% 到 1.5% 的开销。

我将按时间顺序总结图中的每一行：

1. 完全模拟

还记得 1998 年的原始 VMware x86 Hypervisor吗？令人惊讶的是，在处理器具有硬件辅助虚拟化（英特尔VT-x和AMD-V）之前，我们其实可以对 x86 进行虚拟化。硬件辅助虚拟化功能是在 2005 年和 2006 年添加的。

第一个 x86  Hypervisor使用仿真和二进制转换来进行特权操作，例如系统调用和页表操作。这具有显着的性能成本，尤其是对于I/O密集型工作负载。第一印象持续了很久，我们对引入硬件的虚拟化技术，通常的影响都是“缓慢”。但那是 20 年前的事了，我认为这种Hypervisor类型从未在 EC2 上运行过。

2. Xen PV 3.0

（对于 Xen，有许多不同的可能配置，包括一些我遗漏的配置。我将这个包括在内，因为它有助于讲述虚拟化的故事。）

进入类虚拟化，最初在Xen中引入，其中Guest已被修改以了解Hypervisor并进行高效的Hypercall。在此配置中，AMI和引导是paravirt (PV)，内核进行超级调用而不是特权指令，系统使用 paravirt 网络和存储驱动程序。这提供了性能改进，但特权操作（系统调用和页表事件，这也会减慢 I/O）仍然存在显著的开销——尽管它比以前更快，所以也许我应该将 CPU 单元着色为黄色而不是红色. 这是在 CPU 和内存（Intel VT-x、AMD-V）的处理器硬件虚拟化之前。

EC2 上的第一个实例是这样配置的，m1.small。

3. Xen HVM 3.0

这一行显示了更新的Hypervisor配置，运行在具有 CPU 和内存硬件虚拟化 (VT-x) 的处理器上，并为网络和存储设备使用 paravirt 驱动程序。AMI 和引导现在是 HVM。中断和定时器还没有被半虚拟化。我还开始将“主板和启动”涂成绿色，因为尽管软件虚拟化，这种类型的实例可以比裸机启动得更快。

4. Xen HVM 4.0.1

此配置启动HVM并使用PVHVM 驱动程序。这些驱动程序也称为HVM 上的PV，它们是使用HVM功能的准虚拟驱动程序。虽然这是使用HVM AMI，但为了帮助区分它，我在驱动程序之后将这些实例称为“PVHVM”。这改善了某些类型的工作负载，包括中断和计时器。

由于两个原因，这里的事情开始变得混乱。与其掩饰这些细节，不如让我深入了解一下：

• 混淆的第一个来源是AMI类型。

  AWS EC2对 PV 和 HVM 使用不同的映像类型和启动过程，如Linux AMI 虚拟化类型页面所述。

  然后人们开始将正在运行的实例称为 PV 或 HVM，但它比这更复杂，因为 HVM 可以启动然后运行paravirt 驱动程序 (PV)，也可以在 HVM 驱动程序 (PVHVM) 上运行 paravirt。

  我们在 EC2 上使用的大多数（或全部）“HVM”实例都是带有 PVHVM 驱动程序的HVM。

• 混淆的第二个来源是性能。

  早期的“HVM”版本没有使用那么多的paravirt，甚至可能比“PV”慢，导致许多人推荐“PV”而不是“HVM”。

  这个建议很快就过时了。

  这有点令人困惑，我在 2014 年写了一篇关于这个的文章：

  Xen Modes。

当我在 2014 年加入 Netflix 时，我们已经开始从 PV 过渡到 HVM (PVHVM)。我来自容器世界，预计会忙于处理硬件虚拟化的开销和 PV 与 PVHVM 等细节，但我发现工作负载已经在这些实例上运行得非常快。这是因为我们的大部分工作负载都受CPU和内存的限制，它们已经在硬件中进行了虚拟化。但并非所有工作负载：有些是网络绑定（代理）和存储绑定（数据库）。

5. Xen AWS 2013

从 2013 年开始，一些 EC2 实例类型开始支持网络接口的硬件虚拟化：单根 I/O 虚拟化 (SR-IOV)。第一个是c3。AWS 将此称为增强型网络。这最初是通过 ixgbe 驱动程序使用的，速度高达 10 Gbps，然后是 ena 驱动程序，速度高达 25 Gbps。

我的同事 Amer Ather 负责测试它并使其在 Netflix 工作，并发布了他的一些结果：在公共云实例上每秒 200 万个数据包。感人的！有了网络性能解决方案，下一个目标就是存储。

6. Xen AWS 2017

2015 年，AWS推出了c4，它对 EBS 卷使用硬件虚拟化。这在 2016 年扩展到 x1.32xlarge 的实例存储设备。这最终在2017年使用i3 实例类型实现了存储优化实例类型，它使用了 SR-IOV 和 nvme 存储驱动程序。Amer 也对此进行了测试和部署，并分享了一些结果：AWS 云实例上的 300 万存储 IOPS。

这是一个伟大的发展，我一直在写一篇博客文章来描述这些新的实例类型：CPU、内存、网络和存储的硬件虚拟化。在我写完这篇文章之前，AWS 推出了 Nitro  Hypervisor。

7. AWS Nitro 2017

正如昨晚在 AWS re:Invent 上宣布的那样，并在今天 Anthony Liguori 的演讲（CMP332：视频）和Bare metal演讲（CMP330：视频）中进行了介绍，c5 实例类型使用名为 Nitro 的新Hypervisor。Nitro很轻。它基于 KVM 核心内核模块，但没有使用许多其他 KVM 组件，例如 QEMU。I/O 路径中也没有涉及 domO 或 IDD。直接metal接入。

图 Nitro 之前：I/O 通过 dom0 初始化

图 Nitro 之后：直接金属 I/O 访问 

Nitro 的目标是提供“与裸机无异”的性能。它不仅使用 SR-IOV 进行网络和存储 I/O 的硬件虚拟化（由 Annapurna labs 的定制芯片卡提供），而且它还具有中断的硬件虚拟化支持：使用posted interrupts和 APICv 来减少VM 退出的数量。提高中断性能被描述为硬件虚拟化性能的最后战场。

正如 Anthony 在他的演讲中所解释的，这些以前的硬件虚拟化开发是 Nitro 的组成部分。它们是零散推出的，以提高Nitro前系统的性能。Nitro 更易于使用，因为它默认使用所有这些技术。上图中的 c5 仅适用于 EBS，因此该图未显示临时驱动器的直接裸机访问（我们将在其他 Nitro 实例中看到）。

我一直在调查 Nitro 的开销，到目前为止发现它是微不足道的，通常不到 1%（很难衡量）。Nitro 的性能接近裸机。

我也对 Nitro 感到兴奋，因为它公开了所有 PMC 计数器。我之前发布了 EC2 的 PMC：测量 IPC，涵盖了最近暴露于 EC2 中某些实例类型的 PMC 架构集。那只是七个 PMC。在 c5 Nitro 实例上，您拥有数百个 PMC，可以真正详细分析低级 CPU 性能。这应该有助于找到 5%、10% 和更多的胜利。

c5s 是第一个使用 Nitro Hypervisor的机器类型，但也在 re:Invent 上推出了m5 实例类型，同样基于 Nitro。AWS 表示，最终大多数（或全部）实例将使用 Nitro Hypervisor，但新的 Bare Metal 实例除外。

8. AWS 裸金属机 2017

在 AWS re:Invent 上还宣布了：Amazon EC2 裸机实例，它们就是裸机服务器。0% 的性能开销。运行任何你喜欢的：Xen、KVM、容器。访问所有 PMC 和其他处理器功能。今天在 Matthew Wilson 和 Aaron Blasius 的一次演讲中对此进行了详细介绍。

AWS 为他们的 Bare Metal 平台起了一个名字：“Nitro 系统”。我之前为 c5 和 m5s 讨论过的“Nitro”是“Nitro Hypervisor”，它也在 Nitro 系统上运行。起初听起来有点混乱，但您可以听到 Matt 在 CMP330 演讲中使用这两个术语。。

9. 总结

我希望这张图现在更有意义，并总结了虚拟化开发之旅：

我会留下一个想法：Bare Metal 实例类型非常庞大（例如，72 个 CPU），您可能希望将它们分成多个云实例。你认为你可以设置一个管理程序以<1% 的开销来做到这一点吗？甚至容器也可能有隐藏的开销（比如 Docker 使用 overlayfs 或桥接网络）。我个人认为这是一个有趣而有趣的挑战，但我认为很难击败 Nitro。我想，对于大多数人来说，Nitro 正是他们想要的。