亚马逊ec2哪个系统好用(亚马逊ec2实例教程)

编者按：

本文是AWS Re:Invent 2019上关于NITRO系统的核心演讲，演讲者是AWS Principal Engineer Ravi Murty。NITRO是AWS的云主机EC2的底层技术支撑，可以说是云计算这些年来最大的创新。NVIDIA的DPU和Intel的IPU，都是对标AWS Nitro系统的。

后续文字内容是根据演讲内容进行的总结，作为参考。

增强的新一代亚马逊EC2：深度理解NITRO系统

这是AWS Re:Invent 2019上关于NITRO系统的核心演讲，演讲者是AWS Principal Engineer Ravi Murty。

CMP303中CMP意思是AWS的计算相关的幻灯片及演讲，303是本演讲的代号，AWS还有很多相关的演讲。

这次演讲包含四部分：

• 第一部分，NITRO概述。会讲到Nitro系统是如何工作的，并深入了解Nitro的基本原理，以及Nitro在EC2中的作用。
• 第二部分，为了更好的服务客户，Nitro过去一年持续不断的创新。
• 第三部分，会介绍AWS近期发布的一些EC2实例类型。如果理解了Nitro系统的原理，就会理解EC2实例类型的本质。
• 最后，会讲解对AWS云计算运维管理非常重要的，随着AWS云主机规模的持续扩大，如何管理EC2机群。

这是跟本次演讲有关的一些内容，包括：

• CMP334：深度理解亚马逊 EC2中的100G网络和EFA
• CMP322：深度理解基于基于ARM CPU（AWS Graviton）的EC2实例
• CMP302：AWS前哨：扩展AWS在预配置环境方面的经验
• CMP321：Expedia如何把计算的成本降低10%，基于AMD实例
• CMP338：深度理解AWS Nitro安全，用于运行于EC2的应用程序
• SEC310：AWS EC2实例元数据服务的安全最佳实践

1 NITRO系统概述

Nitro系统是2017年底发布的，到现在（演讲的Re:Invent 2019）有两年了。之后发布了C5实例。实际上，Nitro相关的工作已经持续多年，最开始是从2013年逐步迭代研发的。

扩展：关于Nitro的迭代，可以参考软硬件融合公众号文章：NITRO系统——AWS EC2虚拟化加速平台。

AWS持续不断的优化创新EC2已经10年多了，从性能和安全的角度来看，通过软件堆栈的平台做一些简单的事情，后来逐步形成了Nitro。从2017年引入Nitro系统，2018年发布C5时重新定义了Nitro。基于Nitro系统，AWS推出了大量的实例和实例特性和功能。2019年，AWS持续扩大了实例类型的数量以及更多的功能和特性。

Nitro是从2013来一年持续不断的开发，首先是2013年发布的增强型网络或ENA，这是第一次专门做网络的Nitro卡。

但在更高级别上，Nitro系统的确是定制的硬件、定制的软件和一个定制的Hypervisor。Nitro系统是由三个重要但独立的组件组成：

• 首先是一系列Nitro卡，每张卡聚焦一个功能，如VPC网络卡、AWS弹性块存储卡、实例本地存储卡以及系统控制卡。
• 第二个重要组件是Nitro hypervisor。市场现有的虚拟机Hypervisor和AWS运行于EC2的Hypervisor都比较臃肿，AWS在KVM基础上做了一些裁剪，完成内存和CPU分配，使得虚拟机可以达到几乎裸金属的性能。
• 最后一个，是Nitro的安全芯片。Nitro安全芯片是AWS自研的，它将使整个EC2平台真正的安全，硬件可信根实际上是在服务器的主板上。

Nitro不仅仅是一张卡，而是一系列卡。有用于VPC的卡，有用于EBS的卡，有用于本地存储的卡，还有一个用于系统控制的卡，系统控制卡是物理的可信根。

这些卡是完全不同的，比如Nitro网络卡一端连接的是x86或ARM的CPU，一端连接的是网络。而本地存储卡，则一边与SSD通信，一边与主机通信。

实际上，有四种不同的卡，但他们构建在相同的ASIC芯片上。

用于VPC的Nitro卡，物理形态上像一个普通的网卡，不同的是，它是为专门支持VPC而构建的。这张卡支持ENA服务，如果把这张卡放在一台服务器上，在操作系统中将看到一张ENA网卡，会加载ENA网卡驱动。

并且为了支持用户的网络数据传输，在卡里要支持VPC，这样我们需要对所有的包进行封装和解封装。

这张卡还实现了安全组，限制器和路由等机制。限制器的主要作用是确保所有的实例，不管是在哪个区域，性能和体验都是一致的。

弹性块存储的Nitro卡，看起来就是一个PCIe板卡，插到服务器上，会看到标准的NVMe控制器，会加载NVMe驱动。当操作系统给EBS的Nitro卡发送存储访问时，内部机制会劫持这个访问，并将其打包成网络请求。当采用EBS的分布式存储时，就要用到EBS的Nitro卡。

EBS远程存储和本地存储不一样的是，本地存储随着实例的消亡而消亡，而远程存储则可以在新的实例重新挂载。

EBS的Nitro卡是EBS的数据平面，需要支持加解密的功能。

从NVMe到远程存储，需要有协议的支持，例如NVMeoF类似的协议。

很多客户喜欢用本地实例存储，本地存储位于服务器本地，不跨网络。本地存储一般用于数据暂存，而不是长久的存储数据。

在第一代EC2上是提供实例的本地存储的，这个时候主要是基于磁盘，虽然磁盘的访问带宽受限，但至少好于网络带宽，因此本地存储有存在的价值。后来，随着网络带宽升级到10G，这个时候，分布式的弹性存储就变得更有吸引力，因此在这一时期，AWS在一些机型上取消了本地存储。再后来，基于NVMe的SSD存储开始流行，这个时候本地的存储带宽变得非常的好，这个时候，AWS在新的机型上，也就又恢复了实例的本地存储。

此外，因为SSD盘存储磨损的可能，需要通过驱动监视功能去了解磁盘的磨损情况。

Nitro控制器卡实际上是整个系统背后的大脑，它负责跟其他Nitro卡进行协作，它暴露了一个被动的API接口供其他卡访问。

当用户启动一个实例时，Nitro控制器卡与其他卡一起准备需要的东西，存储、网络等，并且与在Host侧的Lite Hypervisor通信，与安全芯片协调，然后实例才能运行起来。

AWS经过深思熟虑，实现了一个全新的芯片，这个芯片专门负责安全。

考虑一个典型的服务器，处理CPU、PCIe设备之外，还有一些微控制器，例如BMC。这些微控制器上会运行一些代码，c或者汇编，通常这些代码存储在服务器主板的某个闪存设备里。按照通常的操作，要想更新这些底层固件的时候，通常是通过ssh到操作系统，然后执行固件更新操作。

但是，如果你运行在一个虚拟实例里，你要更新存储在闪存的固件，Hypervisor会拒绝这些访问。

如果是在裸机实例，用户操作系统可能会修改这些微控制器的固件，我们要避免这种情况发生。

一种解决方案是采用UEFI安全启动。就是系统从一个已经签名和认证的小块程序开始，然后不断的检测是否签名正确，正确后才跳转到新的程序块执行。依此类推，这是一个链式加载的过程。如果整个过程有程序被篡改，则启动失败。这个太复杂了，更新很复杂，维护很复杂。

因此，AWS采取了新的方式，实现了一个独立的安全芯片。当操作系统通过总线更新闪存时，会被拒绝。

如果启动一个裸金属实例，则不存在Lite Hypervisor。如果启动的是一个虚拟机实例，则是基于Lite Hypervisor运行的，Lite Hypervisor基于KVM，KVM是Linux的一部分，Lite Hypervisor不需要systemd或busybox，并且不需要sshd。因为，完全不允许通过ssh的方式访问Lite Hypervisor。

Lite Hypervisor是非常薄的一层，把很多不需要的功能拿掉了。很多功能都卸载到了Nitro卡，因此，在物理CPU上运行的工作非常轻量的。

这带来了两个好处：一个是安全，因为我们知道在Nitro Lite Hypervisor上运行的是什么。另一个好处是出色的性能。

这里是一个案例，客户需要构建一个非常严格要求的应用程序，例如实时性的要求，需要在50ms? 内进入数据包。在虚拟机上运行延时会非常紧张。最低下的红色线是裸金属实例，可以看到延迟是非常非常低的。而黄色线，则是上一次虚拟机实例，可以看到70%的时候就超过了SLA线。而采用了Nitro系统的新一代的虚拟机实例，则是由一个非常恒定的延迟，在一个非常高的百分位上是一致的。

原因则是Lite Hypervisor超级的薄，很多工作卸载到了卡上，在Lite Hypervisor几乎不做事情。所以，也称之为一个静态的Hypervisor。称为静态Hypervisor的原因是它永远不做任何事情，只有实例请求它时才工作，之后继续保持静止。

2 NITRO使得EC2更加快速的创新

因为有了Nitro系统，加快了AWS创新的步伐。例如，基于GPU的实例，以及支持推理的实例，都是基于Nitro系统的。AWS 2017年以来推出的所有实例，都是基于Nitro的。并且，Nitro支持在不同架构的创新。因此，在Intel x86架构之外，还有了AMD架构和ARM架构。

此外，Nitro系统还支持实现各位不同规格的裸机产品，2019年就推出了一堆裸金属实例类型。

同时，Nitro还能支持很多新的特性和能力。因此，当客户想定制一个功能时，我们能非常快速的响应。

Nitro系统，也使得可以为Nitro，只维护一套通用的代码库。

2018年，重构了一些实例类型，2018年推出了A1实例，是基于ARM架构的。A1是虚拟机实例，运行在Lite Hypervisor之上。A1裸机实例，则没有Lite Hypervisor。

基于AMD的裸机或虚机实例类型。

以及Intel最新处理器平台Cascade Lake的实例类型。

AWS在构建任何一个产品的时候，都会倾听客户的需求。如果客户任务很有趣，AWS就会仔细的考虑和评估。

2016年的时候，VMware找到AWS，希望提供裸金属机器，来部署VMware虚拟化环境，这样就可以把VMware云迁移到AWS。

之后，这些机型都对所有人开放。

有些客户的业务需要在没有Hypervisor的环境中运行，或者有些不能在虚拟机环境运行以满足许可要求，或者因为性能的原因不能在虚拟机中运行。

基于全新的用于VPC的Nitro卡，实现了100Gbps的网络，在一些网络增强的实例类型中提供。

100Gbps的网络非常有用，它是构建很多HPC场景的必须。HPC场景，通常要解决一个规模庞大的问题，例如对全球天气进行建模，然后把它分散在很多个节点上，每个节点是问题的一个子集，当各自完成工作后，需要非常快速的大规模数据的交换，这就需要非常快速的网络。

HPC场景，需要高带宽低延迟的网络，因此AWS定义了全新的EFA，弹性的Fabric适配器。

基于新的用于VPC的Nitro卡，实现了对EFA的支持，专用于HPC场景的高性能低延迟网卡。

在软件层，集成了Libfabric高性能计算库，实现消息的传递。

而在网卡内部，则支持SRD协议。SRD是AWS定义的一套高性能的，相比RoCEv2更优的一套高性能网络协议，并在VPC的Nitro卡里实现了它。

并且，在AWS Linux或其他一些Linux的发行版本中，不管在用户态还是内核态、虚拟机或者裸金属机，AWS都提供了EFA网卡功能的支持。

对HPC场景来说，需要在不同的计算节点快速而大量的进行数据传输交互，因此对高带宽低延迟的网络非常的敏感。

支持EFA和不支持EFA的软件堆栈区别：

• 主要是在传统的协议栈是基于TCP/IP的，需要从把数据从用户空间传输到内核空间，整个协议栈要更重一些。这就是传统的应用程序所经历的整个协议堆栈。
• 而EFA协议栈则直接从应用程序通过Libfabric送到EFA网卡中，不需要经过内核空间。并且在网卡中还有SRD技术进行进一步优化。

上图是一个流体力学仿真的案例。

理想的来说，如果采用一定数量的CPU核进行计算，需要20秒；如果能够采用两倍数量的处理器Core，则计算时间减半到10s；如果是四倍，则需要5s。这是完美的横向扩展。

从图中可以看到，采用EFA技术之后，整个计算集群的效率衰减是非常低的。

EFA蓝色线之后的显著衰减，主要是由于整个流体力学仿真程序本身对更大规模的支持不够，数据集也不够多的缘故。

AWS还引入了基于Nitro系统的异构加速实例。

当用户启动一个裸金属机或虚拟机时，加速实例的GPU都是完整分配给用户使用的，这类实例是ML和图形密集处理的最优选择。

存储优化型实例，提供最优价格的本地存储，适用于大量数据的IO密集型场景。

AWS outposts是AWS的混合云解决方案，Nitro的软件和硬件在底层提供了技术支持。用户可以将Outposts安置在自己的数据中心。使用AWS标准的API和标准的AWS服务。

3 管理EC2机群

AWS在持续增长，在全球有22个地域和69个可用区，可用区是物理上分开的一个个的数据中心。

这么多的可用区，这么多的服务器，需要添加NITRO卡需要安装Lite Hypervisor，还有Intel AMD的x86以及ARM等不同的CPU架构。每天都有很多这样的重复工作需要做。

因此需要在软件层面，对这些工作进行管理，需要快速的软件分发机制。

在更新Nitro卡和Lite Hypervisor的时候，不影响客户的业务。

为了保险起见，一个区域一天之内只处理一个可用区。

软件更新主要是NITRO Hypervisor和每个NITRO卡的软件。

（正文完）

长按扫描二维码加“软硬件融合”技术讨论群：

回复“加群”加入软硬件融合技术交流群，

回复“介绍PPT” 下载软硬件融合技术介绍PPT。