记录鞭炮微病毒。 我们采用两种流行的方法来隔离多用户工作负载：虚拟机和容器。 我们压缩两种方法中的最佳方法，尽可能简化，在实际高负载下进行测试。 结果，我们获得了可以在数百毫秒内启动的虚拟计算机的不可渗透的隔离。 该解决方案在AWS Lambda和Fargate的支持下运行，每秒可在云中运行数百万个无服务器功能和容器。 它被称为鞭炮。
可以在
OpenSource中使用此微虚拟化工具。 如果您的任务需要多租户隔离（例如，您决定创建自己的云），那么鞭炮就是您所需要的。
亚马逊网络服务架构师
Vasily Pantyukhin讨论了Firecracker架构，AWS Lambda如何使用它，并将其与替代解决方案进行了比较，并提供了集成示例。
免责声明：以下所有内容都是Vasily的个人观点，可能与Amazon Web Services的立场不符。公共云的自然特征
多租户是公共云的基本属性之一。
有人将此术语翻译为“多租户”或“多用户环境”。 但是从我的角度来看，这并不能反映本质。 多租户是指不同的用户及其负载生活在相同的物理基础结构上，在彼此之间共享它，但彼此之间一无所知。 对于多用户工作负载，多租户的区别在于从根本上对资源隔离和对其进行访问的要求更加严格。
公有云固有的另一个特性是高负载。
相信我，对于AWS，这是一个巨大的负担！ 屏幕截图是真实数据的示例。 我不会说这几百万只“鹦鹉”被测量了多长时间以及在哪个区域进行测量，但这不是紧急情况，而是我们的常规操作模式。
事实证明存在一定矛盾。 一方面，我们需要使用户尽可能孤立。 另一方面，我们必须确保很高的生产率和资源利用率。 改进一个通常会导致另一个的局限性。 如何找到一个妥协，甚至更好的方法，以在各个方面获得最大收益？
虚拟机还是容器？
有两种可能有效的基本方法。 这些是虚拟机和容器。 每个都有其优点和缺点。
虚拟机的主要缺点是它们需要
很长时间才能加载 。 启动机器通常需要数十秒，甚至数分钟。 但是virtualoks有一个优点-它们
将混凝土负载彼此
隔离 。 从这两种观点来看：
- 一台虚拟机无法访问另一台计算机上的数据时的安全性 ；
- 资源 ，当我订购8 GB的内存时，我希望该RAM是我的，并且没有人可以要求支付我为其支付的资源。
容器则相反：它们是轻量的，因此
装载非常快。 它们可以轻松地水平缩放。 但是，作为公共云提供商，我们无法使用其中一项功能。 它们使用
共享内核-OS内核在所有容器之间共享 。
可以说容器不安全吗？ 不，即使存在严重漏洞。
我认为，今天正确的“焊接”容器可以提供足够的安全性。
问题是不同的-共享内核从根本上不能保证将来的某个时候不会出现破坏租户隔离的漏洞。 即使从理论上讲，公共云也负担不起。
还有另一个矛盾，必须寻求解决方案。 最简单的方法是从妈妈（一台虚拟机）和爸爸（一台容器）中获取最好的东西，穿越并获得
融合的东西。 实际上，我们做到了。 原来是鞭炮。
爆竹已经投入生产。 在同样大量的关键服务中，例如，AWS Lambda（无服务器功能）和AWS Fargate（无服务器容器）。
旧的AWS Lambda的问题
AWS Lambda是无服务器功能服务。 我们采用Java，Go，Python或其他语言编写函数，然后将其放入Lambda中，并神奇地执行了该函数。 不必分配和管理资源。 以前是如何实现的？
对于每个AWS账户，分配了一个或多个单独的EC2虚拟机以隔离属于不同租户的功能。 这样的虚拟机即使不执行任何操作也会消耗资源。 假设我们每10分钟运行一次函数，并且它像常规Lambda一样在200毫秒内执行。 事实证明，在一小时内EC2机器仅使用了几秒钟。 而且，即使在运行时，它也不会消耗所有可用资源-置于底板之下。 这真是无利可图。
您如何解决回收问题？
从头开始开发自己的鞭炮解决方案。 从报告标题可以明显看出：)
要开始开发新产品，您需要一项技术任务。 它有很多文本，但是如果仅选择含义，则会得到以下内容。
- 由KVM作为管理程序提供支持 。 与AWS一起工作的人都知道我们有两个最喜欢的管理程序。 旧版VM在Xen上运行。 自2017年底以来，KVM一直生活在所有汽车的引擎盖下。
- 它会尽快启动。 在参考硬件上，要求是在125毫秒内完全加载微虚拟。
- 最小化虚拟化开销 。 在参考体系结构中，一台Firecracker微型虚拟机仅消耗5 MB的内存。
- 最密集启动的可能性 。 设计参数-每秒每核心5个微病毒的满载。 对于AWS Lambda之类的服务，此要求至关重要。 功能必须迅速起飞，锻炼并消亡，以释放下一个资源。
- 重新订阅的可能性 。 这是一个机会-不必使用它。 实际上，这是虚拟资源的分配程度大于物理上可用的程度。 这意味着服务器具有16 GB的RAM，并且您同时在其上运行4个虚拟机，每个虚拟机都确保其具有8 GB的内存。
内置鞭炮的AWS Lambda
新版本的AWS Lambda有哪些更改？ 从最终用户的角度来看，没有任何改变。 在生产中向更新的体系结构的迁移是完全透明的，并且对于消费者而言是不可见的。 Lambda功能寿命很短-很容易做到。
现代建筑是什么样的？
现在，最低层不是虚拟机，而是物理裸机。
这样的服务器可以充分利用CPU的所有功能，例如Intel VT。 在更高级别使用虚拟化时，这提供了其他好处。
最重要的是内核中带有KVM模块的
主机OS 。 上面启动了带有自己的
来宾操作系统的 鞭炮微病毒。 好的，他们已经实现了AWS Lambda服务本身的组件。
以前，我们为每个使用Lambda功能的客户分配了利用率低的单独EC2虚拟机。 新方法允许您仅在真正需要时才运行轻量级微虚拟。 相互隔离鞭炮资源可以使我们在具有最大密度的通用硬件上执行此操作。 资源利用得到根本改善。
盒子里有什么？
我答应了装箱，所以让我们看一下爆竹的主要组成部分，分别考虑每个组成部分，然后将它们放在一起。
设计原则
当我们第一次开始讨论鞭炮的开发时，我们同意遵守两个原则。
摆脱不必要的一切。 为什么经典虚拟机加载缓慢？ 特别是因为代码过载。 他们必须支持大量的旧设备。 但是，为什么要仿真一种十年前没人使用过的设备？ 因此，没有必要，我们消除了所有不必要的东西。 我们解决了一个狭窄的特定任务，任何无助于解决此问题的功能都被认为是不必要的。
摆脱多余的一切，专注于一项任务。
简化剩余的内容。 即使剩下的也应该尽可能简单。
他们写了什么？
爆竹用时髦的Rust书写是因为：
- 它使您可以编写更安全的代码 ，尤其是在内存方面；
- 性能和开销可与现代C ++相提并论；
- Rust 已使用了很长时间，自2015年以来， Rust 已编写了许多很棒的高负载解决方案。
铁
我再说一遍-爆竹需要在真实的硬件上安装。 作为参考配置，选择了i3.metal裸机。
注意：该报告于2019年4月上旬。当时，仅支持Intel平台。 他们在5月添加了对AMD的alpha支持，并在6月添加了ARM。 AMD可能比英特尔便宜一些，ARM支持为使用多租户物联网提供了有趣的机会。如果您在AWS中订购了i3.metal或其他裸机，则对于实验而言，它的配置将过于强大且昂贵。 因此，如果您决定在其上安装Firecracker，请不要忘记在实验后还清这些机器。 否则，该月底会取得不错的成绩。
有便宜的选择吗？ 是的，您可以在虚拟环境中启动Firecracker。 但是现在不再在AWS中-我们基本上不支持EC2上的嵌套虚拟化。 但是您可以在GCP，Azure，DigitalOcean中进行操作，也可以使用Proxmox，Parallels，VMware Fusion。 如果您遵守这些要求，特别是根据来宾操作系统的内核版本，一切都会正常进行。
核心
解决方案的基本要素是KVM内核模块。
以防万一，我将KVM是什么作为题外话。 这不是整个虚拟机管理程序，而只是其中的一部分。 它的主要任务是
设置虚拟处理器 （vCPU）和
启动虚拟机 。
但这还不足以进行全面的工作。 除了处理器之外，还需要其他一些设备。 它们的仿真发生在用户空间中。
虚拟机
为了至少显示基本设备，您需要另一个组件-虚拟机管理器（VMM）。 在爆竹之前，主要的VMM选项是QEMU。
我们认真考虑了使用QEMU的可能性，但决定开发自己的“自行车”。 有几个原因。
发展管理 。 QEMU是一种大型成熟产品，具有超过一百万行代码。 要进行更改，您需要查看太多的源代码。 许多人参与开发和开发决策。
安全性 QEMU可以模拟很多设备。 这就是为什么它具有相当大的攻击面的原因。 我们的任务是制造微虚拟的。 从安全角度来看，我们必须最小化攻击面。
需要实施新功能。 QEMU具有良好的代码。 这是一个成熟的产品，其中已经捕获了所有明显的错误。 但是以目前的形式，QEMU功能仍然不适合我们-我们将不得不增加很多。 从这个角度来看，QEMU和新产品中的新代码将具有相同的质量。 因此，特殊的胜利是行不通的。
装置
爆竹实现了VMM，该VMM用于模拟设备。 我们模拟以下设备：
- 主控台 尽管可以将其关闭，但它是有用且必要的事情。
- 琴键 我们制作了一个棘手的键盘-仅带有一个“重置”按钮。 我们完全不相信可能会在Firecracker中运行的那些操作系统的软件“重置”。 因此，他们制造了铁。
- 用于磁盘和网络的Virtio驱动程序 。 Virtio是一种非常原始的设备。 本质上，这是一个“环形缓冲区”。 来宾系统将一些内容写入缓冲区，单击该调用，然后主机系统通过文件从该缓冲区读取数据。
在某些情况下，例如，为了与容器集成，我们仍然需要能够代表常规网卡基本功能的网络设备。 Virtio不太适合这里，太简单了。 因此，对于网络，我们使用另一个设备
-Vsock 。
好吧，我们还需要控制资源消耗的能力。
速率限制器对此负责。
有设备。 但是如何管理和配置微病毒呢？ 管理API将在这里为我们提供帮助。
管理学
亚马逊有几个牢不可破的基本原则。 其中之一是，任何服务都只能通过API相互通信。 这些是您用作用户的外部服务还是我们的内部服务都没有关系。 一项服务不会直接转到另一项服务的数据库，这是不会发生的，它是被禁止和惩罚的。 Firecracker API线程仅用于通过REST API访问微病毒的设置和功能。
我们遵守Open API规范，因此您可以使用Swagger。
元数据
有这样一种邪恶-硬编码。 这是将一些数据直接缝到代码中的时候，例如，访问另一个资源的登录名和密码。 当然，这是不允许的。 我们需要定期在微虚拟内部传输一些数据。 这是通过
元数据服务完成的。
我们通过套接字将所需的信息传递给IMDS元数据交易。 要在微虚拟内部获取此信息，您需要使用REST API请求
http://169.254.169.254/latest/meta-data 。 AWS用户已经知道此神奇IP。 同样，微型病毒可以获取有关其自身配置的详细信息。
日志
至关重要的是，在她去世之前，必须将微病毒原木扔到外面。 这是通过常规Unix
FIFO完成的 。
额外的绝缘
孤立虚拟机的主要优点。 看来这应该足够了，但是我们走得更远。 以防万一，要在生产中运行，建议
再铺一层称为
Jailer的绝缘层。
这些是标准的预防措施：
- 用于隔离进程的名称空间 ；
- seccomp-用于系统调用的防火墙的类似物；
- 当然，也是每个人最喜欢的chroot。
与其他服务整合
是否有基于鞭炮的现成解决方案？ 当然可以
OSV
该操作系统经过专门设计，可以仅运行一个应用程序。 因此，她使用内存和调度程序进行了非常简单的组织工作。 功能强大且易于管理的OS现在
可以在Firecracker上运行 。
装箱的
我们还与容器进行了集成。 如果您已经与他一起工作，那么您只需花费很少的精力即可启动用Firecracker包装的用于隔离的容器。
代替普通的垫片，使用集装箱指的是爆竹垫片。 它已经通过安装在微虚拟内部的代理来管理runc。
经过检查，可以正常工作 。
卡塔容器
当我们首次宣布爆竹时，最受欢迎的客户问题之一是：
-已经发明了隔离容器的机制-这就是Kata容器。 你为什么不使用它们？ 为什么要发展自己的？-Kata与QEMU合作，但我们不想与QEMU合作。 因此，我们决定自己做饭。但是结果很有趣。 卡塔（Kata）开发人员会见了鞭炮开发人员，并同意进行整合。 因为每个人都认为这是一个巨大的优势。
Kata Containers v1.5已经支持QEMU和Firecracker。
事实证明，我们不竞争，而是和谐相处。 在带有v1.12的Kubernetes中，您可以将runtimeClassName定义为Kata FC或Kata QEMU，并以适当的隔离度运行容器。
如何选择适合您的应用的保温材料-爆竹或QEMU？ 我个人认为，
重要的是您的申请是
宠物还是牛 ？
带有QEMU的Kata是宠物的解决方案。 QEMU是一个大型的多功能系统。 潜在地，它可以为您喜欢的宠物提供更多的支持和治疗选项。
鞭炮适合在重物负载的情况下使用。 如果您的无状态应用程序最初是为灵活的水平缩放而设计的，则一个或多个容器的故障并不重要。 提供可靠的绝缘，它使您能够快速加载所需数量的新容器以替换发生故障的容器。
结果如何？
我们从矛盾开始。 解决矛盾似乎是“我们和您自己”的方法，介于两者之间的某些方法将使每个人都满意。 但是经验表明，不必折衷。
我们为自己设定了开发新解决方案的目标，在该解决方案中，解决狭窄任务不需要多余的东西。 尽可能简化我们使用的一切也很重要。 我想相信我们并没有妥协，而是一个可靠的解决方案，它使您可以快速而密集地启动数千种微病毒，而无需牺牲它们的隔离性。
我们已经在一些服务的生产中使用了Firecracker。 我们获得的主要优点是提高了服务利用率。 这样可以节省很多钱。 我们与客户分享了部分节余。 例如，在推出Firecracker之后，AWS Fargate无服务器容器的价格在2019年1月下降了35-50％。 好处是肉眼可见的，因此毫无疑问，我们将继续开发该产品并与开源共享最佳实践。 Firecracker已经开始与其他解决方案集成的事实表明社区对此的兴趣正在增长。
如果您在描述中有一个想法或最终产品，其中包含“多租户隔离”一词-这清楚地表明您应该尝试使用Firecracker微病毒。
该报告完美地说明了我们在Ontiko会议上努力遵循的原则-从说俄语的专家那里获得世界经验。 重点不仅在于可能的语言障碍，还在于在文化中我们习惯于共享技术细节。 在11月，瓦西里（Vasily） 将再次以HighLoad ++ 表演 ，例如，来自Facebook的Artemy Kolesnikov ，来自Oracle的Vittorio Cioe ，当然还有来自Percona的Petr Zaitsev 。 我们还将提供英文报告， 订阅时事通讯-我们将告诉您何时将新报告添加到40个接受的报告中。