基于SPDK-vhost的云原生Kubevirt虚拟化存储IO的优化方案

• 摘要

本文主要介绍针对云原生kubernetes虚拟化IO的应用场景，在Kubevirt中引入SPDK-vhost的支持，来加速虚机中IO存储性能。同时基于Intel开源的Workload Service Framework[1]平台集成部署一套端到端虚拟化IO的应用场景做基本的性能对比测试。

• 云原生Kubevirt虚拟化

在云原生时代，越来越多的业务开始逐步迁移到容器上来，容器也成为了一种不可或缺的资源发布和管理形式，同时由于场景的需求，有部分业务形态更适合运行在虚拟机，如何同时管控虚拟机和容器逐渐成为了云原生时代的主流需求，Kubevirt给出了完美的解决方案。VM在Kubernetes环境中的管理和部署工具Kubevirt是 Red Hat 开源的，是基于Kubernetes运行，具体的来说是基于Kubernetes的CRD（自定义资源）增加虚拟机的运行和管理相关的资源，特别是VM，VMI资源类型。用户可以在K8S环境中通过CRD进行增加关于虚拟机的资源类型，再通过部署VM.yaml的形式来创建虚拟机等一系列的操作。

图1：云原生Kubevirt架构介绍

如图1所示绿色模块是Kubevirt的原生插件和功能模块，在master上部署virt-controller和virt-api，virt-api是管理虚拟机资源及其运营管理的接口，而virt-controller则负责管理和监控VM实例对象及其关联的POD，其中virt-launcher POD就是virt-controller依据VM的配置文件来创建的。这里需要关注的是virt-launcher POD，每一个virt-launcher承载一个VM实例，其内部是通过libvirtd来管理虚拟机的生命周期。

• 引入SPDK-vhost加速Kubevirt虚拟化IO

在实际边缘计算和云计算应用场景中，不少客户使用云原生的Rook-Ceph来部署后端存储服务。以常用的block设备为例，用户在创建虚机之前，先通过PV/PVC向Rook-Ceph存储申请volume资源，在创建虚机的时候挂载到VM中，如下图2所示。这种Kubevirt虚机挂载使用Ceph block IO的本质是通过Ceph kernel rbd来提供block块设备，而Kubevirt的虚机则是使用传统的virtIO的前端和后端方案，实际的应用中，会带来频繁的用户空间和内核空间的切换，同时这种基于Qemu-KVM的半虚拟化的IO模型会伴随着大量KVM的VM EXIT和VM ENTRY事件，同时产生大量中断，这会带来不少系统资源的消耗和IO latency 的增大。

图2：Kubevirt VM在Ceph存储上的使用

集成SPDK-vhost到Kubevirt

众所周知，业界为了优化virtIO的虚拟化IO性能，而引入vhost的模型，以便减少频繁的用户空间和内核空间的切换和数据的拷贝。而在我们云原生虚拟化场景中引入了SPDK-vhost在空户空间的一种虚拟化IO优化的方案，基于KubeVirt中引入SPDK-vhost的deamonset模块来加速VM中block IO的访问，对于SPDK-vhost的具体细节可以参考SPDK官网介绍[2]。如下图3所示，我们针对Kubevirt中virt-launcher模块进行优化，加入spdk-vhost-user的接口功能，提供对SPDK-vhost的接口检测和通讯，以便在VMI实例中使用SPDK-vhost的接口给VM提供加速的block功能。同时，当在K8S集群中部署Kubevirt的时候我们同时会在集群中部署SPDK-vhost daemonset，在每个节点都会部署一个SPDK-vhost功能POD。而SPDK-vhost POD中的接口会相应的检测和并通过librbd链接到后端的Rook-Ceph，创建对应的SPDK rbd bdev 设备，再以此bdev设备创建vhost-block controller。基于此，当virt-launcher发起创建虚机的过程中，vhost-user接口模块会解析VM yaml文件中定义的块设备信息，并链接到SPDK-vhost POD 向该模块申请特定size的 block设备，而SPDK-vhost守护进程则会向Rook-Ceph申请对应的卷空间，一旦成功，则会在VM中成功看到虚拟磁盘，而此虚拟磁盘则是基于Ceph块设备通过SPDK-vhost加速之后提供的。

图3：引入SPDK-vhost的Kubevirt架构

下面介绍一下KubeVirt虚机的部署过程中SPDK-vhost功能的接口。如下图4所示，SPDK-vhost模块支持对Rook-Ceph的存储功能管理和链接，能够按需申请Ceph RBD存储卷，并在SPDK内部对应的创建rbd-bdev逻辑设备，再将bdev设备挂接到创建的vhost block controller上，而虚机中vdisk是通过共享内存的方式和SPDK-vhost做数据传输。在控制面，virt-launcher中的libvirt是通过链接SPDK-vhost所提供vhost socket来实现通讯。

图4：基于SPDK-vhost的Kubevirt VM的接口机制

对于新的方案的部署和实施流程如下图5所示，以Rook-Ceph为后端存储为例，用户需要在Kubernetes集群环境中预先部署Rook-Ceph和优化过的Kubevirt版本。同时确保SPDK-vhost daemonset正常部署到集群中(当前示例是将SPDK-vhost deamonset单独作为一个模块部署，没有和kubevirt的部署集成到一起)。SPDK-vhost POD中有接口会检测Root-Ceph的环境健康状态并建立链接。随后用户基于编写好的VM yaml文件部署虚机，通过virt-api的将创建VM的信息和资源申请传递给virt-controller，那么virt-controller则会创建virt-launcher POD以便在内部创建VM实例。如下图所示，virt-launcher会往本地node上SPDK-vhost POD发送创建volume的请求，SPDK-vhost POD则会通知Rook-Ceph创建相应的RBD image，成功之后会在SPDK-vhost POD中创建一个SPDK-vhost controller，同时返回结果给到virt-launcher，至此基于SPDK-vhost的block设备创建成功，那么virt-launcher则会正式通知libvirt创建虚机并挂载相应的virtual block设备。

图5：基于SPDK-vhost的Kubevirt VM的部署流程

如下图6所示，用户在创建虚机之前，需要在VM yaml文件中申明基于“spdkVhostBlkDisk”类型的块设备，并申请相应的卷容量。

图6：申请SPDK-vhost类型的块设备

性能的对比

我们基于Intel开源的WSF (Workload Service Framework，见下一节)框架搭建一套端到端的全栈式workload来对使用SPDK-vhost的虚拟化IO方案和使用Kubevirt内置virtIO方案做性能对比测试。这里采用的是一套三节点集群的存储超融合环境，部署2副本的Rook-Ceph在该集群中，同时在该集群中均匀的部署3个虚机，每个虚机挂载3个虚拟卷。该workload [3]的具体实现可以参考WSF git仓库中的代码和相应的手册。下面是对于使用Kubevirt内置的virtIO方案和加入SPDK-vhost的方案的性能对比。

图7：4K 的随机写的吞吐性能和时延对比

图8：4k 的随机读的吞吐性能和时延对比

如图7和图8所示，对测试数据做归一化处理，以virtio方案为基准，可以看到vhost方案对于4K的读写场景均有一定程度的性能提升，并且在某些场景中时延也能得到比较大的改善。

图9：1M Read & Write 带宽性能对比测试

而对比较大的IO，如图9所示，可以看到vhost方案相比原有的virtIO方案在1M的读写场景中也有性能提升，1M顺序读能提升11.52%，而对比1M的顺序写可以得到18.64%的性能提升。

• WSF 的介绍

WSF 全称Workload Service Framework [1], 是一套Intel开源的面向云原生，端到端的全栈式workload的集成开发，基准测试和调优的平台。该平台支持在不同环境中自动化的系统性的运行并测试workload的性能，目前可以支持在On-Prem和云服务厂商CSP上的实例上部署和性能测试，同时也支持多个硬件平台(比如Intel, AMD, ARM等) 的性能对比分析。

WSF 目前支持云原生应用场景中的几个主要的部署类型，如下图所示，其中包括纯Docker部署，Kubernetes的部署和基于Terraform的部署方式。其中Terraform的部署方式能有效的帮助我们将软件栈和workload部署到On-Prem和CSP 的云实例上。WSF中集成的workload是依据业界内常用的客户应用场景来实现，并对应的定义workload性能KPI测试标准，这不仅能够帮助芯片制造商来分析芯片在各种应用场景下的运行行为和性能状况，也能帮助行业客户在特定平台上部署和调优软件栈和工作负载。

图10：WSF 支持的几种部署后端

• WSF 最新的Release

WSF仓库中包含一系列的完整，独立，可单独执行的workload， 囊括AI，网络，存储，安全等行业类型的软件栈和使用场景。Intel计划会在每个季度做一次workload的发布和更新，最新的一次是23.2的版本[6], 主要更新如下内容：

• 新增Edge-Ceph-VirtIO workload,该workload是针对edge native的应用平台搭建端到端的虚拟化IO方案，以rook-ceph作为超融合块存储后端，基于KubeVirt引入spdk-vhost加速虚机IO性能

• 新增CM-xAPP-OpenVINO workload，该Workload是基于O-RAN网络架构开发的智能连接管理（CM）xApp，使用OpenVINO框架来优化5G用户关联和负载均衡，以提高用户设备（UE）的服务质量（QoS）要求。

• 新增OpenSSL3 workload，该workload中引入Intel® QuickAssist Technology (Intel® QAT)技术的硬件加速OpenSSL软件栈。

• 更新NGNIX workload: 升级OpenSSL的版本到OpenSSL3，同时加入Intel® QuickAssist Technology (Intel® QAT) 技术的硬件加速，来提升端到端的RPS整体性能。

参考和引用

• [1] WSF Repo: https://github.com/intel/workload-services-framework

• [2] SPDK Vhost的介绍：https://spdk.io/doc/vhost.html

• [3] Edge-Ceph-Virtio Workload: 代码链接

• [4] Kubevirt官网：https://kubevirt.io

• [5] Kubevirt repo：https://github.com/kubevirt/kubevirt

• [6] WSF V23.02版本：https://github.com/intel/workload-services-framework/tree/23.2

点击“阅读原文”链接，访问WSF对本文中提到的Workload和SPDK vhost的支持。

作者：张敏，朱永波，杨鼎，WE Team等