计算虚拟化详解

1. 虚拟化发展演进

1.1 虚拟化里程碑

如图1，计算虚拟化发展有几个关键节点。虚拟化技术最早60年代中期年在IBM大型机上实现，当前主流大型虚拟化有IBM Z/VM与KVM for Z Systems。80年代IBM与HP开始研究面向UNIX小型机虚拟化，当前主流的有IBM PowerVM与HP vPar，IVM等。1999年VMware推出针对x86 服务器虚拟化，当前主流x86虚拟化有VMware ESXi、Microsoft Hyper-V，以及开源的KVM和Xen。2006年Intel和AMD推出硬件辅助虚拟化技术Intel-VT，AMD-V将部分需要通过软件来实现的虚拟化功能进行硬件化，大幅提升虚拟化的性能。容器作为一种更加轻量的应用级虚拟化技术，最早于1979年提出，不过2013年推出docker解决了标准化与可移植等问题，目前已成为最流行的容器技术。基于x86服务器的虚拟化技术对云计算发展发挥了重要作用，接下来将重点介绍。

图1：虚拟化技术里程碑

1.2 虚拟化架构演进

计算虚拟化通过虚拟化管理程序（Hypervisor或VMM）将物理服务器的硬件资源与上层应用进行解耦，形成统一的计算资源池，然后可弹性分配给逻辑上隔离的虚拟机共享使用。 如图2、基于VMM所在位置与虚拟化范围可以分三种类型：

1) 宿主型（Type II）：在早期虚拟化产品中，VMM运行在宿主机的Host OS上（如Windows），对硬件的管理与操作需要经过Host OS处理与限制，系统运行开销、效率与灵活性都不太好。主要的产品有VMware Workstation, Windows Virtual PC 2004，Xen 3.0之前的版本等。

2) 裸金属（Type I）：VMM直接运行的物理硬件上（少了Host OS），可直接管理和操作底层硬件，运行效率和性能较好，是当前主流的虚拟化类型，如开源的KVM、Xen 以及VMware ESXi、Microsoft Hyper-V等。

3) 容器（应用级）：容器是一种更加轻量的应用级虚拟化技术，将应用的可执行文件及其所需的运行时环境与依赖库打包，实现一次构建，到处运行的目标。相比虚拟化，容器技术多了容器引擎层（如Docker），但上层应用无需与Guest OS绑定，可以实现秒级部署、跨平台迁移，灵活的资源分配，弹性调度管理等优势。容器、微服务与DevOps为云原生的三大要素，是推动企业技术中台建设与微服务化转型不可或缺的组件。

图2：计算虚拟化逻辑架构

2. 虚拟化系统原理

2.1 x86 CPU特权级别

x86架构的操作系统直接运行在硬件上，分为内核态和用户态。为了保障系统安全性、隔离性与稳定性，指定了4种特权级别的运行状态Ring0 – Ring3，其中Ring 0是内核态，运行OS内核，权限最高，可执行特权指令（对系统资源进行管理与分配等）或执行敏感指令，（如读写时钟、控制中断、修改内存页表、访问地址重定位系统，以及所有IO指令等）。Ring3是用户态，运行用户应用程序，只能执行费特权指令；需要执行特权或敏感的特权指令时通过系统调用方式从Ring3用户态切换到Ring0内核态，内核完成相关操作后再切换返回。Ring 1、Ring2保留使用。

2.2 全/半/硬件辅助虚拟化

虚拟化在原有OS系统Kernel模式、User模式的基础上新增虚拟机的Guest模式。Guest模式可执行用户程序代码，Guest模式发起特权指令时，在全虚拟化、半虚拟化以及硬件辅助虚拟化场景下，处理方式与效果完全不同，如图3。

全虚拟化（Full Virtualization）

VMM完整模拟了底层硬件， GuestOS无需做任何修改即可运行。用户应用运行在Ring3，普通指令可以直接发送到底层执行。GuestOS运行在Ring 1执行特权指令时触发CPU异常，运行在Ring 0的VMM捕获异常，进行二进制翻译BT（Binary Translation）和模拟执行，返回GuestOS以为指令正常执行。该过程对VMM系统管理开销，指令执行复杂度与性能都有影响。ESXi属于全虚拟化。

半/超虚拟化（Para virtualization）

VMM只模拟了部分底层硬件，需要修改GuestOS对特殊指令进行处理后才能正常运行。GuestOS运行在Ring 0，执行特权指令时，通过Hypercall直接调用VMM的设备接口来执行内核操作，支持异步和批处理。此时无需捕获异常或设备模拟执行，大幅降低系统处理开销与性能损耗。在Xen系统中，PV Guest属于半虚拟化（面向开源的Linux，部署时需安装PV Driver），HVM Guest 属于全虚拟化（面向Windows，不可修改，需要借助硬件辅助虚拟化 ）。

硬件辅助虚拟化

Intel VT-x和 AMD-V是x86 平台的两种硬件辅助CPU虚拟化技术，引入了新的运行模式和操作指令。VMM运行在VMX Root模式，GuestOS运行在VMX Non-root模式，两种模式可互换。GuestOS需要执行特权指令时通过VMCALL调用VMM的服务，系统自动挂起GuestOS，切换到Root模式执行，该过程叫VM Exit。VMM也可以调用VMLaunch或VMResume指令切换到Non-root模式，系统自动加载运行GuestOS，该过程叫VM Entry。通过硬件辅助虚拟化，既解决了全虚拟化的系统开销与性能损耗，也避免了半虚拟化下修改GuestOS的麻烦与兼容性问题，目前主流虚拟化产品都支持。而Intel等公司联合推出的数据开发套件DPDK（Data Plane Development Kit）、存储性能开发套件SPDK（Storage Performance Development Kit）等技术目标是的借助Intel网络，处理，存储等技术显著提高处理效率和性能，目前已被AWS、阿里云等厂商积极应用。

图3：虚拟化系统原理

2.3 CPU/内存/IO虚拟化

从服务器组件维度，分为CPU虚拟化、内存虚拟化、以及I/O虚拟化。CPU虚拟化的目标是保障CPU资源的合理调度以及VM上的指令能够正常高效的执行，第4部分已对CPU虚拟化原理进行说明。

内存虚拟化目标保障内存空间的合理分配、管理，隔离，以及高效可靠地使用。全虚拟化中为每个VM维护一个影子页表（Shadow Page Table），记录虚拟化内存与物理内存的映射关系，VMM将影子页表提交给CPU的内存管理单元MMU进行地址转换，VM的页表无需改动。半虚拟化采用页表写入法，为每个VM创建一个页表并VMM注册。VM运行过程中VMM不断管理和维护该页表，确保VM能直接访问到合适的地址。硬件辅助内存虚拟化有Intel扩展页表EPT（Extend Page Table）和AMD 嵌入页表NPT（Nested Page Table）。EPT/NPT是内存管理单元MMU的扩展， CPU硬件一个特性，通过硬件方式实现GuestOS物理内存地址到主机物理内存地址的转换，比影子页表的系统开销更低，性能更高。

I/O虚拟化的目标是保障VM的IO隔离与正常高效的执行。全虚拟化通过对磁盘和网卡IO设备模拟，每次IO通过异常陷入Trap到VMM来执行，如ESXi。半虚拟化中可通过前端Front-end和后端Back-end驱动的方式实现，比如Xen在Dom U（Guest OS）中安装前端IO驱动，同时在管理虚拟机Dom 0中安装后端IO驱动。硬件辅助IO虚拟化有Intel VT-d与AMD IOMMU。VMM将IO 设备分配给特定GuestOS，数据直接写入设备，减少VMM参与IO处理，提升了性能。同时每个设备在系统内存中都有一个专用区域，只有对应的GuestOS才能访问，增强了系统安全性与可用性。

表1：虚拟化主要技术

3. 主流虚拟化对比

当前主流的x86虚拟化技术有开源的KVM、Xen，以及VMware ESXi、Microsoft Hyper-V。图4展示了几种虚拟化架构，主要差别在于虚拟化核心任务的执行组件有所不同。

ESXi 虚拟化的核心任务都是通过ESXi内核完成。Xen的CPU和内存虚拟化通过Xen内核完成，磁盘与网络IO虚拟化，以及虚拟化管理与调度由主机上最先启动的管理VM Dom0完成；Dom U就是用户VM，其中HVM Guest（Windows）是全虚拟化，PV Guest（Linux）是半虚拟化。Hyper-V架构Xen的架构非常相似，Xen中的Dom0角色在Hyper-V 叫做Parent Partition。Hyper-V采用微内核，VMM运行在ring -1（根模式），设备驱动和GuestOS运行在Ring0，所以Hyper-V内核比较轻量，安全性和性能上有一定优势。作为Linux的一个内核模块，KVM 架构更加不同，CPU和内存虚拟化通过KVM内核完成，磁盘与网络IO虚拟化通过QEMU完成，每个VM是一个QEMU进程，由Linux进程调度器管理。

图4：主流虚拟化架构

表2： 主流虚拟化对比

4. 计算虚拟化产品

虚拟化只是底层硬件与上层应用的解耦，提供可灵活分配的技术资源池的底层技术，还需要与更多的组件（镜像、调度、存储、网络等）协同工作才能创建和管理虚拟机，提供完整的计算服务。以下对几种计算服务OpenStack、阿里云ECS与腾讯云CVM的内部架构进行简要说明。

4.1 OpenStack Nova架构

OpenStack是开源的云平台，通过不同的组件提供计算、存储、网络、数据库等多种云服务，其中计算服务Nova通过nova-API与其他组件通信，通过nova-compute对接不同的Hypervisor提供计算虚拟化服务。如图7 Nova架构与组件功能如下。

nova-api：接收并响应其他组件的API调用请求。

nova-scheduler：调度器，从队列中获取VM创建请求并选择运行VM的主机。

nova-compute：提供对接不同Hypervisor的API，如XenAPI for XenServer，libvirt for KVM，VMwareAPI for VMware等。

Queue：用于nova各组件间通信异步解耦的消息队列，基于RabbitMQ。

nova-database：保存系统创建或运行信息的数据库，包括镜像类型、实例、项目等。

nova-conductor ：作为nova-compute等组件与nova-database通信的中间节点，避免了直接访问DB带来的安全隐患，支持水平扩展。

nova-console/nova-consoleauth/nova-cert：提供控制台、用户认证授权与证书相关的服务。

图7：OpenStack Nova 组件图

4.2 阿里云ECS 架构

云服务器ECS（Elastic Compute Service）是阿里云提供的基于KVM虚拟化的弹性计算服务，建立在阿里云⻜天分布式操作系统上。ECS架构如图8，请求的主要调用流程为OpenAPI à 业务层 à 控制系统 à 宿主机服务，各组件的功能如下：

1） 宿主机服务：提供底层的计算资源池的物理服务器集群，支持KVM计算虚拟化，VPC网络虚拟化以及基于libvirt的虚拟化管控功能。

2） 飞天操作系统：阿里云自研的分布式云计算操作系统，提供分布式文件系统、任务调度和资源管理、远程过程调用、分布式协同、自动化部署与系统监控等服务。

3） 中间件层：Tair为ECS后端控制系统提供缓存服务、MQ提供虚拟机状态消息队列服务，ZK保障分布式系统组件通信的一致性。

4） 管控层：ECS后端控制系统负责计算、网络、存储等资源的调度管理，提供管控与状态数据库。镜像中心提供镜像导入、拷贝等管理服务；MetaServer负责实例的元数据管理。Admin Gateway提供运维管理时登录服务器的堡垒机。

5） API Proxy：根据请求参数将请求转发到对应的区域与组件。

6） 售卖管控：对产品上架售卖规格与状态信息的等业务运营策略的设置与存储。

7） 对外API网关：接收处理外部API请求，提供鉴权与转发等服务。

图8：阿里云ECS架构

4.3 腾讯云CVM架构

云服务器CVM（Cloud Virtual Machine）是腾讯提供的基于KVM虚拟化的弹性计算服务，建立在腾讯云自主研发的分布式资源管理调度系统vStation上。CVM架构如图9，在前端接入层，从租户端或运营端发起请求，在API Server上进行鉴权或参数校验，然后通过云API 传到层vStation，vStation执行资源管理调度，通过装箱算法找到合适的主机后，发送请求到物理集群层进行处理，同时vStation也调度其他关联组件（如镜像、存储、网络等）提供服务。 主要组件的功能如下：

API：对外提供HTTP服务，负责对外接收请求以及任务步骤分解。

MQ：组件之间通过MQ进行异步通信。

Dispatcher：控制MQ中任务总数，规避批量操作下进程阻塞导致系统异常。

Compute_access： 从MQ轮询compute任务并发送到主机上的compute处理，收集反馈任务结果。

Compute：部署主机上的代理，管理虚拟机的生命周期。

Scheduler：负责计算资源的权值计算，确定虚拟机最终落在哪个主机上。

Resource：执行资源扣减、退还相关操作，封装数据访问接口，提供虚拟机、母机等DB查询。

Image_access：负责与镜像模块通信，镜像导入，镜像同步等功

Network: 负责与网络模块通信如 IP 分配，MAC 计算，外网 IP 漂移等。

Volume：负责与存储设备 CBS 进行通信，分配云盘。

图9：腾讯云CVM架构