本文要介绍的是 2020 年 NSDI 期刊中的论文 —— Firecracker: Lightweight Virtualization for Serverless Applications1,该论文实现的 Firecracker 能够在宿主机上提供轻量级的虚拟化支持。很多开发者在今天都会选择使用 Serverless 的容器和服务以为了减少系统的运维开销、提高硬件的资源利用并实现快速的扩缩容,然而 Serverless 的场景却对容器的隔离性、安全性以及性能都提出了更高的要求。
当利用相同的硬件为多个租户提供服务时,我们期望不同的工作负载可以在最小化额外开销的情况下保证安全和性能上的隔离。然而在过去很长一段时间内,大多数的观点都认为在强安全性和低延迟之间我们只能二选一。
图 1 - 安全性和低延迟
虚拟化技术可以提供较强的安全性但是会引入较大的额外开销,而容器技术与之相反,它提供了弱安全性保证以及较小的额外开销。在这种前提下,公有云和私有云都会根据需求做出了自己的选择:
不同租户之间的隔离性永远都是公有云首先要考虑的问题,租户之间存在一些资源的竞争有时还是可以接受的,但是没有客户能够接受花钱购买的服务可能受到其他租户的攻击。
图 2 - Firecracker
这篇文章介绍的 Firecracker2 是新的虚拟机监视程序(Virtual Machine Monitor、VMM),它可以同时提供强安全性保证和较低的额外开销,目前为 AWS 函数和计算引擎提供支持,支持数百万的工作负载和每个月数万亿的请求。
Firecracker 可以为运行的工作负载提供良好的兼容性、性能、具有极低的额外开销并且可以在单个主机上支持上千个函数,但是这些都不是这篇文章要关注的重点,我们在这里展开介绍论文中提到的几种隔离机制。
图 3 - 隔离选项
Linux 容器、语言特定的隔离机制和虚拟化技术是今天比较常见的几种隔离选项,我们在这里花一些时间简单介绍它们三者的异同。
Linux 的容器组合了内核的多种功能提供运维和安全上的隔离性,其中包括:
容器往往依赖系统调用上的限制来保证安全性,很多容器的运行时都会在系统调用上做文章来保证安全性,例如 Google 的 gvisor 3就在用户空间模拟一些系统调用,这能明显地减少内核需要提供的能力。
另一个用于隔离工作负载的常用技术就是编程语言的虚拟机了,例如 Java 虚拟机(Java Virtual Machine、JVM)以及运行 Javascript 的 V8 引擎。这种通过牺牲灵活性和兼容性以获得安全性的方式在一些场景下还是比较适合的,Chrome 的底层引擎 Chromium 就为每个网站单独分配进程资源防止网站访问不相关的信息造成安全问题。
现代的虚拟化技术都会使用硬件提供的功能保证虚拟硬件、页表和操作系统内核的隔离性。虽然虚拟化技术能够解决安全性的问题,但是这个世界的问题很多都是按下葫芦浮起瓢,重量级的虚拟化技术也会带来下面的挑战:
图 4 - 虚拟化技术的挑战
Firecracker 选择更加安全的语言 Rust 并使用 50,000 行代码实现最小可用的虚拟机监控程序以替代 QEMU,新的 VMM 会与 Linux 的内核虚拟机(Kernel Virtual Machine、KVM)一起为不同的工作负载提供运行环境。
Firecracker 作为虚拟机监控程序,它依赖 Linux 的内核虚拟机(KVM)提供最小的虚拟机 MicroVM,这主要因为 Linux 的组件提供了正确的功能、性能以及设计,绕过这些组件会带来巨大的实现成本,同时也会增加运维工程师理解新系统的成本并影响运维工作。
这篇论文详细地分析了 Firecracker 的性能,以启动时间为例,预先配置版本的启动时间在 100 ~ 150ms,而没有预先配置的 Firecracker 启动时间大约为 150 ~ 250ms;除了提供毫秒级别的启动时间之外,Firecracker 仅需要 3MB 的内存额外开销,这可以显著地提升单机的部署密度。虽然 Firecracker 在启动时间和额外开销上都有着不错的表现,但是它的 I/O 吞吐量与其他系统相比却差很多。
图 5 - I/O 吞吐量
值得注意的是,论文中提到 Firecracker 在测试环境中超售二十倍资源,在生产环境中超售十倍资源都没有带来任何问题。看起来 AWS 的函数引擎 Lambda 的确可以带来相当高的利润,果然想要赚钱就是要把一份资源当成十份甚至二十份来卖。
本文转载自:面向信仰编程
领取专属 10元无门槛券
私享最新 技术干货