最近，NSDI'20论文已向公众开放，我查看了上周提供预印本的几篇论文，今天我将简述一下今年最令人期待的论文之一：亚马逊的Firecracker。

https://firecracker-microvm.github.io/

Firecracker是支持AWS Lambda和AWS Fargate的虚拟机监视器（VMM），自2018年以来已在AWS上投入生产。Firecracker是开源的，并且有许多项目使在外部环境下轻松工作变得非常容易，AWS环境也包括Weave Firekube。之所以存在Firekube，是因为现有的替代方案（虚拟化，容器或特定于语言的vm）都无法满足AWS环境中多租户效率和强隔离的组合需求。

传统观点是，在具有强大安全性和高开销的虚拟化与具有较弱安全性和最小开销的容器技术之间可以选择，这种权衡对于需要强大安全性和最小开销的公共基础架构提供商来说是不可接受的。

0x01  隔离方法

AWS Lambda的第一个版本是使用Linux容器构建的。同一客户的多个功能将在单个VM中运行，而不同客户的工作负载则在不同的VM中运行。因此，容器在功能之间提供了隔离，而虚拟化则在帐户之间提供了更强隔离。这种方法在打包效率上施加了一些限制，并且还需要基于允许进行的syscall容器类型在安全性和代码兼容性之间进行折衷。

现代的商用服务器最多可以包含1TB的RAM，而Lambda可以使用的内存仅为128MB。因此，服务器上最多需要8000个功能来填充RAM（由于软分配，实际上更多）。这也使任何解决方案对每个功能（每个隔离单元）的开销非常敏感。

理想的隔离解决方案将具有以下属性：

· 高度隔离（在同一硬件上具有多种功能，可以防止特权提升，信息泄露和其他风险）。

· 能够在一台机器上运行数千个功能而浪费最少

· 接近本机性能

· 支持任意Linux二进制文件和库，而无需更改代码或重新编译

· 快速启动和拆卸功能

· 软分配支持，每个功能仅消耗其需要的资源（达到其限制），而不消耗其实际有权使用的资源。

容器提权问题

主机上的容器共享单个OS内核，这依赖于内核中内置的隔离机制来提供保护。

容器依赖syscall限制其安全性这一事实表示在安全性和兼容性之间进行权衡。

一个现实的容器环境可能需要访问数百个sys调用，以及/proc和/sys内核接口。一种用于系统调用的解决方案是将某些内核功能移入用户空间，从而保留较小的表面积以确保安全。这有助于防止特权升级，但是和/proc的丰富性意味着防止隐蔽的通信仍然具有挑战性。

VM的语言问题

特定语言的VM（例如V8隔离）在AWS Lambda用例中没有启动器，因为Lambda和Fargate需要能够支持任意二进制文件。

虚拟化的问题

虚拟化在密度，开销和启动时间方面面临挑战。诸如unikernels之类的方法可以帮助解决此问题，但是需要再次要求AWS能够运行未修改的代码将这些问题排除在外。通用管理程序和虚拟机监视器（VMM）也非常大，从而导致了庞大的可信计算库（TCB）。KVM + QEMU的流行组合可运行超过100万行代码，并需要多达270个唯一的系统调用。

0x02  Firecracker的设计

我刚刚分析的所有现有方法都涉及到了AWS。通过专门为无服务器和容器应用程序构建Firecracker，可以简化假设，从而开辟新的设计点。

与制定适用于所有用途的VMM相比，为一组清晰的目标开发VMM以及我可以对guest的属性和要求进行假设的方法要容易得多。这些简化的假设反映在Firecracker的设计和实现中。

我真正想要的是虚拟化的隔离特性，以及轻量级的容器开销。“ 从隔离的角度来看，最引人注目的好处是它将安全性至关重要的接口从OS边界转移到硬件和相对简单的软件所支持的边界 ”。

因此，Firecracker的核心是一个新的VMM，它使用Linux内核的KVM基础结构来提供最少的虚拟机（MicroVM），支持现代Linux 主机以及Linux和OSv  guest。Rust大约为50kloc，即使用安全的语言，大大减少了代码占用量。Firecracker尽可能利用Linux内置的组件（例如，用于IO块，进程调度和内存管理以及TUN / TAP虚拟网络接口）。通过针对容器和无服务器工作负载，Firecracker只需要支持有限数量的仿真设备，而数量要少于QEMU（例如，不支持USB，视频和音频设备）。virtio用于网络和块设备，Firecracker设备提供了足以满足AWS需求的内置速率限制器。

除VMM之外，Firecracker还公开了用于配置，管理，启动和停止MicroVM的REST API。

如果你正在考虑在生产环境中部署Firecracker（而不只是使用AWS出售的Firecracker），这里有详细的指南和建议。

https://github.com/firecracker-microvm/firecracker/blob/master/docs/prod-host-setup.md

0x03  将Firecracker集成到AWS中

在AWS Lamba Firecracker MicroVM内部，每月为数十万客户提供数万亿个项目。Lambda worker提供了许多插槽，每个插槽用于MicroVM中单个功能的多次串行调用。如果当前没有空间可用于所请求的功能，则位置服务将使用基于时间的租赁分配空间。

每个工作栈运行数百或数千个MicroVM。每个MicroVM都会启动一个Firecracker MicroManager进程，负责创建和管理MicroVM，提供设备仿真以及处理出口，与MicroVM的通信是通过TCP / IP套接字进行的。

0x04  Firecracker 优缺点对比

Firecracker MicroVM的启动时间大约为100毫秒，如果还包括API调用处理时间，则启动时间为150毫秒。

内存开销非常低，每个MicroVM约为3MB（相比之下，Cloud Hypervisor为13MB，QEMU为131MB）。

Firecracker当前的弱点是块IO性能。Firecracker（和Cloud Hypervisor）限于大约13,000 IOPS（4kB时为52 MB / s），而相同的硬件能够超过340,000读取IOPS（4kB时为1GB / s）。

作者预计将在这一领域进行重大改进，但由于硬件尚未完成支持数千个临时VM的任务，因此PCI直通所提供的接近裸机性能的差距将无法完全消除。

经过测试，内存和CPU的超额分配比率最高可达20倍，并且使用的生产比率高达10倍。

除了短期的成功外，Firecracker还将成为未来在虚拟化领域进行投资和改进的动力，包括探索虚拟化技术的新领域。很高兴看到Firecracker被容器社区所采用，并相信有很大的机会从Linux容器过渡到虚拟化，这是整个行业中容器隔离的标准。

本文翻译自：https://blog.acolyer.org/2020/03/02/firecracker/如若转载，请注明原文地址：