论文地址：Firecracker：无服务器应用程序的轻量级虚拟化，Agache等人，NSDI’20

    最后，NSDI的20篇论文向公众开放（截至上周），这是一篇多么好看的论文。上周我们看了几篇有预印本的论文，今天我们要看的是今年收成最令人期待的论文之一：亚马逊的Firecracker。

    FireCracker是为AWS Lambda和AWS Fargate提供动力的虚拟机监视器（VMM），自2018年起在AWS投入生产。Firecracker是开放源代码的，而且有许多项目也使得在AWS环境之外的工作变得容易，包括Weave Firekube（免责声明：Accel是Weaveworks的投资者）。Firekube的存在是因为现有的替代方案（虚拟化、容器或特定于语言的vm）都不能满足AWS环境中多租户效率和强隔离的综合需求。
    传统的观点是，在安全性强、开销大的虚拟化和安全性弱、开销最小的容器技术之间有一个选择。这种权衡对于公共基础设施提供商来说是不可接受的，他们既需要强大的安全性，又需要最小的开销。

    隔离方法
    AWS Lambda的第一个版本是使用Linux容器构建的。同一客户的多个功能将在一个VM中运行，不同客户的工作负载将在不同VM中运行。因此，容器提供了功能之间的隔离，而虚拟化提供了帐户之间（更强的）隔离。这种方法对打包效率造成了一些限制，还需要在安全性和代码兼容性之间进行容器权衡，这取决于允许容器进行的syscalls类型。
    现代的商品服务器最多可以包含1TB的RAM，而Lambda函数只需要128MB。因此，您需要在服务器上使用多达8000个函数来填充RAM（由于软分配的缘故，在实践中需要更多）。这也使得任何解决方案对每个功能（每个隔离单元）的开销都非常敏感。

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

    • 强隔离（在同一硬件上有多个功能，防止权限提升、信息泄露、隐蔽通道和其他风险）。
    • 在一台机器上以最少的浪费运行数千个功能的能力
    • 接近本机性能
    • 支持任意Linux二进制文件和库，无需更改代码或重新编译
    • 快速启动和拆除功能
    • 软分配支持，即每个函数只消耗其所需的资源（达到其限制），而不是实际拥有的资源量。

    container的问题

    • 主机上的容器共享一个操作系统内核，依赖内核中内置的隔离机制进行保护。
    • 容器的安全性依赖于syscall限制这一事实代表了安全性和兼容性之间的权衡。
    • 一个真实的容器环境可能需要访问数百个sys调用，以及/proc和/sys内核接口。syscalls的一个解决方案是将一些内核功能移到用户空间中，留下一个较小的表面积来保护。这有助于防止特权升级，但是/proc和friends的丰富性意味着保护不受秘密通信渠道的影响仍然是一个挑战。

    firecracker-fig-1.jpeg

    语言VMs的问题
    特定于语言的vm，比如V8隔离，在AWS Lambda用例中是不起作用的，因为Lambda和Fargate需要能够支持任意的二进制文件。

    虚拟化的问题
    虚拟化面临着密度、管理费用和启动时间方面的挑战。像unikernels这样的方法可以帮助解决这个问题，但是AWS要求能够运行未修改的代码，再次排除了这些问题。通用虚拟机监控程序和虚拟机监视器（vmm）也相当大，这导致了大量的可信计算基础（TCB）。KVM+QEMU的流行组合运行超过100万行代码，需要多达270个惟一的系统调用。

    Firecracker设计
    我们刚刚研究的所有现有方法都涉及到AWS不希望做出的权衡。通过专门为无服务器和容器应用程序构建爆竹，可以简化假设，开辟新的设计点。
    为一组明确的目标开发VMM，并且在这里我们可以对来宾的属性和需求进行假设，这比开发一个适合所有用途的VMM要容易得多。这些简化的假设反映在Firecracker的设计和实现中。
    我们真正想要的是虚拟化的隔离特性，以及容器的轻量级开销。“从隔离的角度来看，最引人注目的好处是，它将安全关键接口从操作系统边界移动到硬件和相对简单的软件支持的边界。”。
    因此，Firecracker的核心是一个新的VMM，它使用Linux内核的KVM基础设施来提供支持现代Linux主机以及Linux和OSv客户机的最小虚拟机（microms）。它大约有50 Kloc的锈迹，也就是说，代码占用空间明显更小，而且使用的是一种安全的语言。在任何可能的情况下，Firecracker都会使用Linux中已经内置的组件（例如，用于块IO、进程调度和内存管理，以及TUN/TAP虚拟网络接口）。通过针对容器和无服务器的工作负载，Firecracker只需要支持有限数量的模拟设备，很多都比QEMU少（例如，不支持USB、视频和音频设备）。virtio用于网络和块设备。鞭炮设备提供的内置速率限制器足以满足AWS的需要，尽管仍然比Linux cgroup的灵活性低得多。
    我们在Firecracker中实现了性能限制，其中有一个令人信服的原因：在设备仿真中实施速率限制允许我们强烈控制来宾可以使用的VMM和主机内核CPU时间量，并且我们不信任来宾实现其自己的限制。在我们没有令人信服的理由向Firecracker添加功能的地方，我们使用了主机操作系统的功能。
    除了VMM之外，Firecracker还公开了一个REST API，用于配置、管理、启动和停止microms。

    如果您正在考虑在生产环境中部署Firecracker（而不仅仅是使用AWS销售的环境），那么对于生产主机的当前侧渠道缓解最佳实践，有详细的指导和建议。

    将Firecracker集成到AWS中
    在AWS Lamba内部，每个月都有数十万名用户使用微型Firecracker为数万亿次活动提供服务。Worker Manager将传入的请求路由到workers，将给定函数的粘性路由到少数主机。Lambda工作器提供了许多插槽，每个插槽用于在一个microm中对单个函数的许多串行调用。如果当前没有可用于所请求功能的时隙，则Placement服务将使用基于时间的租赁来分配时隙。

    firecracker-fig-2.jpeg

    每个工作节点都有数百或数千个MicroVMs。为每个microm启动一个Firecracker微管理进程，负责创建和管理microm、提供设备仿真和处理出口。与microm的通信是通过TCP/IP套接字进行的。

    firecracker-fig-3.jpeg

    一个Jailer在Firecracker周围安装了一个包装器，在Firecracker引导客户机之前，将Firecracker放进一个限制性的沙箱中。

    生产经验
    Firecracker微秒开机时间在100毫秒左右，如果还包括150毫秒的API调用处理时间。

    firecracker-fig-5-6.jpeg

    内存开销非常低，大约为每MicroVM 3MB（相比之下，云管理程序为13MB，QEMU为131MB）。
    firecracker-fig-7.jpeg

    目前Firecracker的弱点是阻塞IO性能。Firecracker（和云管理程序）的IOPS限制在13000左右（4kB时为52MB/s），而同一硬件的读取IOPS可以超过340000（4kB时为1GB/s）。

    firecracker-fig-8-9.jpeg

    作者预计，这一领域将有重大改进，但由于硬件尚未完成支持数千个临时vm的任务，因此与PCI pass-through提供的近乎裸机的性能之间的差距不会完全消除。

    内存和CPU超额订阅率已测试高达20倍，没有问题，并使用了高达10倍的生产率。

    最后一句话
    除了短期的成功，Firecracker还将成为未来虚拟化领域投资和改进的首选，包括探索虚拟化技术的新领域。我们很高兴看到容器社区拿起了Firecracker，并且相信有一个很好的机会从Linux容器转移到虚拟化，作为整个行业容器隔离的标准。