虚拟化技术

虚拟化技术的分类

x86平台指令集分为4个特权模式：Ring0 、Ring1、Ring2、Ring3、OS工作在Ring0级别，应用软件工作在Ring3级别，驱动程序工作在Ring1和Ring2

软件虚拟化：通过软件完全模拟cpu、芯片组、磁盘、网卡等计算机硬件。
全虚拟化：通过VMM截取guestos的ring 0特权指令，转译为宿主机的指令最终由物理设备处理。此时Guestos不知道自身运行在虚拟机环境。
半虚拟化：guestos将原先ring0级别的特权指令转换为supercall，仍旧和VMM交互但是不需要转译性能有所提升。但是需要修改OS内核，典型实现为XEN（dom0和domu）
硬件辅助虚拟化：intel退出的VT-x技术，避免了指令的转译（除了少数客户端指令），基于硬件进行处理效率较高。当前不仅CPU指令有硬件虚拟化方案，I/O通信也有硬件解决方案，称为VT-d；网络通信的称为VT-c
容器虚拟化：基于CGroups、Namespace对进程隔离，例如docker

aws ec2虚拟化发展

Amazon EC2 虚拟化技术演进：从 Xen 到 Nitro
在这里插入图片描述
按照时间顺序有如下发展轨迹

早期的Xen虚拟化。Xen 实现了虚拟机的CPU 和内存虚拟化，但是虚拟机的I/O 访问，包括网络和存储等，都是通过虚拟机中的前端模块和 dom0 中的后端模块通信。I/O路径太长，降低了I/O性能。dom0还会和业务虚拟机抢占宿主机资源，很难实现管理虚机和业务虚机之间的平衡，以及避免抖动
引入单根I/O虚拟化（SR-IOV），采用aws增强型网络（enhanced networking）（通过ixgbe驱动程序实现）
引入EBS的硬件虚拟化技术，将远端存储以NMVe形式呈现给虚拟机
发展增强网络实现为ENA（Elastic Network Adapter），使得虚拟机能够绕过内核和用户空间网络处理程序，直接操作网卡硬件。Nitro的首个专用硬件卡（完全的网络负载卸载硬件）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JaeKcH6e-1670333401554)(assets/image-20221206211252182.png)]
发展实例存储，Annapurna Labs研发的Nitro存储卡管理的SSD磁盘
替换Xeni架构，使用基于KVM的Nitro hypervisor 替换了Xen

Nitro技术

Nitro - Hypervisor + 网络/存储卡 + 安全芯片

Nitro卡

AWS Nitro 系统是模块化组件的集合，使用广泛的计算、存储、内存和网络选项来设计 EC2 实例（Nitro卡）

VPC Data Plane（用于VPC访问的Nitro卡）：通过PCIe附加到宿主机上的一块定制网卡，支持网络封包和解包、安全组、限速器和路由，网络加速等功能。实例通过ENA驱动和它通信。
EBS Data Plane（用于EBS卷访问的Nitro卡）：通过PCIe附加到宿主机上的一块定制卡。远端存储被以NVMe设备形式展现给实例，实例通过标准NVMe驱动程序访问该卡。支持卷加密、存储加速
Instance Storage Data Plane（用于实例存储访问的Nitro卡）：本地磁盘被以NVMe设备形式展现给实例，实例通过标准NVMe驱动程序访问这些磁盘。支持加密、限速器和本地磁盘监控
卡控制器（Card Controller）。提供API端点，负责协调所有Nitro卡、Nitro Hypervisor和Nitro安全芯片。利用Nitro安全芯片实现了Hardware Root Of Trust（硬件信任根），支持实例监控、计量和认证。它还为Nitro EBS卡实现了NVMe控制器。

Nitro 安全芯片

Nitro安全芯片整合到宿主机主板中，控制对所有非易失性存储的访问，持续监控和保护硬件资源，并在每次系统启动时独立验证固件。

Nitro hypervisor

Nitro hypervisor基于KVM位于极简化的定制的Linux 内核中，带有定制的VMM和小用户空间应用。只负责管理内存和CPU分配，将Nitro卡虚拟功能分配给实例，监控和计量硬件等，不再需要提供任何网络功能。

2017年hypervisor仍旧在宿主机上，2018年后hypervisor被集成到了硬件中

Firecracker

资料

深度解析：AWS Fargate 数据平面
Firecracker – 无服务器计算的轻量级虚拟化
深度解析 AWS Firecracker 原理篇 – 虚拟化与容器运行时技术
深度解析 AWS Firecracker 实战篇 – 一起动手点炮竹
Firecracker: Lightweight Virtualization for Serverless Applications
Firecracker：无服务器应用程序的轻量级虚拟化（翻译）

github

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

FireCracker是为AWS Lambda和AWS Fargate提供动力的虚拟机监视器（VMM）。Firecracker的核心是一个新的VMM，它使用Linux内核的KVM基础设施来提供支持现代Linux主机以及Linux和OSv客户机的最小虚拟机（microms）

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

firecracker作为一款轻量级虚拟机，仅提供了有限功能

firecracker和docker比较

Docker容器技术采用共享宿主机内核方式运行，利用内核特性实现对不同用户的命名空间进行隔离（6种方式），使用 CGroups进行硬件资源分配与限制，POSIX Capabilities进行 root 权限分割等。由于操作系统内核漏洞，Docker 组件设计缺陷，以及不当的配置都会导致 Docker 容器发生逃逸，从而获取宿主机权限。docker实现原理决定了容器的其隔离性、封闭性还是远远低于拥有独立 GuestOS 的虚拟机。而分配、管理、运维这些传统虚拟机与容器轻量、灵活、弹性的初衷背道而驰

firecracker能够为类似 AWS Lambda 和 Fargate 这样的服务提供高安全性、灵活性和效率的运行时环境

firecraker的优势

应用负载的隔离性。每个 MicroVM 内部仅运行一个应用容器，或者仅运行一个应用 Pod。而不同租户的不同应用之间，实现了虚拟化级别的隔离，每个应用不再共享 HostOS 内核，而是拥有独立的 GeustOS Linux 内核。
安全。抛弃 QEMU 使用的 C 语言，选择内存安全的 Rust 作为开发语言。基于 crosvm 使用极简设备模型，模拟尽可能少的必要设备，减小暴露的攻击面
高性能和低开销。Firecracker 取消了 SeaBIOS （开源的 X86 BIOS），移除了 PCI 总线，取消了 VGA 显示等等硬件模拟。GuestOS（MicroVM）使用定制过的精简 Linux 内核，裁剪掉对应的设备驱动程序、子系统等等