亚马逊Firecracker: 专门针对无服务器应用的轻量虚拟化,云计算下一个发展新趋势 - acolyer

20-03-08 banq

不同于Docker容器或JVM等语言VM,亚马逊Firecracker专门致力于无服务器应用的轻量虚拟化。Firecracker是支持AWS Lambda和AWS Fargate的虚拟机监视器(VMM),自2018年以来已在AWS上投入生产。Firecracker是开源的,并且有许多项目使在外部环境下轻松工作变得容易。 之所以存在Firekube,是因为现有的替代方案(虚拟化,容器或特定于语言的vm)都无法满足AWS环境中多租户效率和强隔离的组合需求。

隔离方法

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

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

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

  • 高度隔离(在同一硬件上具有多种功能,可以防止特权提升,信息泄露,秘密通道和其他风险)。
  • 能够在一台机器上运行数千个函数,而浪费最少
  • 接近本机性能
  • 支持任意Linux二进制文件和库,而无需更改代码或重新编译
  • 快速启动和拆卸功能
  • 软分配支持,每个功能仅消耗其需要的资源(达到其限制),而不消耗其实际有权使用的资源。

容器的问题

主机上的容器(如Docker)共享单个OS内核,这依赖于内核中内置的隔离机制来提供保护。容器依赖syscall限制其安全性这一事实表示在安全性和兼容性之间进行权衡。

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

语言VM的问题

特定于语言的VM(例如V8隔离)在AWS Lambda情况下不能作为启动器,因为Lambda和Fargate需要能够支持任意二进制文件。

虚拟化的问题

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

Firecracker的设计

我们刚刚研究的所有现有方法都涉及到AWS不想进行的权衡。通过专门为无服务器和容器应用程序构建Firecracker,可以简化假设,从而开辟新的设计点。

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

因此,Firecracker的核心是一个新的VMM,它使用Linux内核的KVM基础结构来提供最少的虚拟机(MicroVM),支持现代Linux 主机以及Linux和OSv 。Rust大约为50kloc,即使用安全的语言,大大减少了代码占用量。

Firecracker尽可能利用Linux内置的组件(例如,用于块IO,进程调度和内存管理以及TUN / TAP虚拟网络接口)。通过针对容器和无服务器工作负载,Firecracker只需要支持有限数量的仿真设备,而数量要少于QEMU(例如,不支持USB,视频和音频设备)。virtio用于网络和块设备。Firecracker设备提供了足以满足AWS需求的内置速率限制器,尽管如此仍然比Linux cgroups灵活得多。

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

将Firecracker集成到AWS中

在AWS Lamba Firecracker MicroVM内部,每月为数十万客户提供数万亿个事件。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)。

总结

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

点击标题见原文。

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

                   

1