弹性计算的第一代虚拟化技术的痛点和思考有哪些？

这代技术的痛点和思考 ，如下图所示。

传统KVM 虚拟化系统导致CPU 计算特性损失

众所周知，IaaS 公共云技术的核心是Intel 至强处理器VT 等硬件辅助虚拟化技术（Hardware-assisted virtualization），配合主流虚拟化系统软件（KVM/Xen/VMware ESXi 等），实现了IaaS 弹性计算；客户则是通过ECS（或者 AWS EC2） 购买虚拟机（VM）形式的计算资源。

得益于高度成熟的虚拟化技术，VM 形式的计算资源“几乎”等价于客户线下的物理服务器资源，但是“几乎”并不是“ 完全”。一个典型的案例就是 Intel 至强处 理器的VT 硬件辅助虚拟化能力会被公共云服务提供商的虚拟化系统“消费掉”，客户无法在公共云VM 实例中再次部署虚拟化系统，致使传统OpenStack 和VMware based workload 无法在公共云部署。

客户希望用一套OpenStack/VMware 统一管理公共云线上资源和专有云线下资源，同时在控制面和数据面打通线上线下资源，在兼顾专有云数据安全、法律合规的基础上，充分利用公共云计算资源的弹性能力，但是由于Intel 至强处理器VT 硬件辅助虚拟化能力“被消费”，使得此种混合云技术很难在公共云实现。云原生安全容器创新依赖Intel VT 硬件辅助虚拟化能力输出，这是传统虚拟化无法解决的问题。

传统KVM 虚拟化系统导致资源争抢不可避免

以传统的KVM 虚拟化系统为例，双路Skylake（96 个HT）计算资源的虚拟化典型部署情况是：有8 个HT 部署网络虚拟化vSwitch 和存储虚拟化，对外售卖88 个HT 作为vCPU 计算资源。我们需要注意到，对外售卖的88HT vCPU 计算资源和8HT 网络/ 存储虚拟化是部署在同一组Skylake CPU 上的，那么如下共享资源争抢是不可避免的。

CPU DDR 带宽、LLC 等共享资源的争抢。在机头网络带宽迅速提升的当下， DDR 带宽、LLC 等资源争抢现象愈发突出。

半虚拟化（Para-virtualized） I/O 设备模型等资源争抢引入售卖CPU 抖动和售卖I/O 抖动。

存储和网络等I/O 内部层级化HQoS 难于实施。一般而言，层级化HQoS 是解决资源争抢的有效手段，电信级网络设备一般会部署HQoS 进行资源调度， 而HQoS 的典型部署方法需要通过芯片实现。

传统KVM 虚拟化系统导致I/O 性能瓶颈

传统KVM 虚拟化系统由（计算虚拟化）QEMU-KVM + （网络虚拟化）DPDK based vSwitch +（ 存储虚拟化）SPDK based I/O initiator 构成。

在Intel 引入VT 硬件虚拟化支持后，配合KVM、Xen 等虚拟化系统软件，由CPU 指令处理的数据面和KVM 等虚拟化系统软件形成了控制面及异常处理路径，此种软硬件协同设计既实现了CPU 和内存虚拟化的数据路径的最小开销，又保留了KVM 控制路径和异常处理路径的高度灵活性。

同处于数据路径的存储虚拟化和网络虚拟化虽然通过DPDK 和SPDK 等技术接近了软件优化的技术极限，但是仍然无法和芯片的加速性能媲美。特别是在网络吞吐向100GbE 演进的过程中，交换网络的带宽能力和Intel 至强处理器的处理能力间的差距逐渐拉大，在传统KVM 虚拟化系统下，通过DPDK、SPDK 等纯软件进行I/O 性能优化的瓶颈日渐凸显。

资料来源：《弹性计算—无处不在的算力》