Firecracker

渗透技巧 2年前 (2022) admin
388 0 0

Firecracker: Lightweight Virtualization for Serverless Applications

今天和大家分享的论文是Firecracker: Lightweight Virtualization for Serverless Applications,作者是来自Amazon Web Services的工程师Alexandru Agache等人。

Introduction

Serverless computing模式在部署和管理软件方面越来越流行,无论是在公有云服务还是内网环境中。其优势在于管理成本低,可扩展性强,事件源和流数据高度集成等。Serverless computing与容器相比允许多租户在大量工作负载之间共享服务器,而在毫秒级内配置新功能和容器的能力允许在需求变化时在不同负载之间快速切换配置。然而,多租户场景的一个重要挑战是工作负载之间的隔离安全性以及性能影响。Linux上的典型容器,如Docker和LXC容器,它们靠内核中的cgroup,namespace,seccomp bpf等隔离机制提供不同负载间的隔离,但它们对单个OS内核的依赖意味着代码兼容性欠缺。针对这一问题,本文提出FireCracker,保留KVM但完全替换掉QEMU来构建新的VMM,设备模型和用于管理配置MicroVM的API。FireCracker每个容器仅占用不到5M的内存开销,引导开销仅有125ms,并且允许每个主机每秒创建多达150个MicroVM。

Design

相比于传统为每个用户创建一个虚拟机,本文认为新的VMM设计应该有强隔离性,低开销,高性能,高兼容性,快速切换和软分配等特性。FireCracker是一个虚拟机监视器,它使用Linux内核的KVM虚拟化基础来提供最小的虚拟机MicroVM,支持现代Linux主机和Linux OS。FireCracker提供基于REST配置的API,磁盘,网络和串行控制台的设备仿真,以及网络和磁盘吞吐量和请求速率的可配置速率限制。每个MicroVM运行一个FireCracker进程,为安全隔离提供了一个简单的模型。

Firecracker

设备仿真

FireCracker为容器和功能负载提供了有限数量的仿真设备,包括网络和块设备,串行端口和部分i8042支持。其中串行端口和i8042仿真驱动较简单,网络和块设备模拟使用virtio工具来实现。处于安全考虑,FireCracker使用支持用于存储的块设备,而非文件系统直通。

API设计

Firecracker进程通过Unix套接字提供REST API,用于配置、管理、启动和停止MicroVM。提供API使我们能够更仔细地控制MicroVM的生命周期。本文之所以选择REST,是因为客户机几乎适用于任何语言生态系统,它对于我们的目标开发人员来说是一个熟悉的模型,并且因为OpenAPI允许我们提供一个机器可读的API规范。相比之下,典型的Unix命令行参数方法不允许在创建进程后将消息传递给进程,也不存在用于指定结构化命令行参数的通用机器可读标准。Firecracker用户可以使用自己选择的语言使用HTTP客户端或使用curl等工具从命令行与API交互。RESTAPI用于指定来宾内核和引导参数、网络配置、块设备配置、来宾机器配置和cpuid、日志记录、度量、速率限制器和元数据服务。大多数配置都提供了通用的默认值,因此在最简单的情况下,在VM启动之前只需要配置来宾内核和一个(根)块设备。要关闭MicroVM,只需终止Firecracker进程,或在来宾内部重新启动即可。与Firecracker的其余部分一样,rest API有意保持简单和最小,尤其是与类似的API(如Xen的Xenstore)相比。

部署

Lambda是一种响应事件运行函数的计算服务,提供了许多内置语言运行时,允许函数作为实现特定语言运行时接口的代码片段提供。它还支持HTTP/REST运行时API,允许以任何语言开发实现此API的程序,并作为二进制文件或捆绑包与语言实现一起提供。Lambda函数在沙盒中运行,沙盒提供了最小的Linux用户空间和一些常见的库和实用程序。创建Lambda函数时,它们会配置内存限制和处理每个单独事件的最大运行时间。

Firecracker

调用流量通过Invoke REST API到达前端,在那里请求经过身份验证并检查授权,并加载函数元数据。前端是一个扩展的无共享车队,任何前端都能够处理任何功能的流量。客户代码的执行发生在Lambda工作队列上,但为了提高缓存本地性、实现连接重用并分摊移动和加载客户代码的成本,单个函数的事件被粘性地路由到尽可能少的工作队列。Worker Manager跨不同的物理基础架构在少量主机之间复制单个功能(或一组功能)的粘性路由信息,以确保高可用性。一旦Worker Manager确定了要在哪个Worker上运行代码,它就建议调用服务将有效负载直接发送给Worker,以减少往返。Worker Manager和Worker还实现了一个并发控制协议,该协议解决了大量独立调用服务对共享的Worker池进行操作所产生的竞争条件。

Firecracker

Evaluation

本文使用FireCracker v0.20.0与Qemu v4.2.0进行比较,在EC2 m5d上进行实验评估,它具有两个Intel Xeon Platinum 8175M处理器,348GB RAM和4个850GB本地磁盘,OS为ubuntu 18.04.2,内核为4.15.0-1044-aws。首先对启动引导时间做了实验对比分析,引导时间是指VMM进程fork和VM内核fork其init进程之间的时间。

Firecracker

接下来是对内存开销的测试,内存开销定义为VMM使用的内存与MicroVM实际分配内存之间的差异:

Firecracker

最后是VMM在磁盘和网络方面的性能测试。

Firecracker

Conclusion

本文提出了FireCracker,一个针对无服务器和容器工作负载优化的VMM,并兼顾性能,安全,隔离等目标。


原文始发于微信公众号(COMPASS Lab):Firecracker

版权声明:admin 发表于 2022年10月29日 上午11:22。
转载请注明:Firecracker | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...