基于SPDK-vhost的云原生KubeVirt虚拟化IO的优化方案(二)
科技
科技
2024-01-17 12:00
上海
在上一篇文章《基于SPDK-vhost的云原生KubeVirt虚拟化IO的优化方案》中我们分享了在云原生KubeVirt场景中引入SPDK-vhost从而加速虚机中IO存储性能的方案，本文将在此方案基础上介绍对云原生虚机的热迁移（Live Migration）、热恢复（Live Recovery）特性的支持，并分享我们基于Intel开源的Workload Service Framework[1]在超融合系统下对集成该方案的多虚机集群部署及性能测试。（本文基于KubeVirt v0.58.0进行讨论） 虚拟机热迁移技术能够在不中断虚机中的服务的情况下在服务器之间实时迁移虚拟机，该技术对于实现云服务中心负载均衡，提升管理效率有着至关重要的作用。KubeVirt定义了名为VirtualMachineInstanceMigration的CRD以支持虚机的迁移，下图为一个迁移对象的YAML文件示例。 图1中的vmiName字段为需要进行迁移的VM名称，部署该迁移对象声明后，针对目标VM的迁移将会被触发。 如图2所示，在KubeVirt中，假设我们在Node A部署了一台VM,将其迁移到Node B的流程总体如下：2. virt-controller通过informer机制监听迁移事件，若有pending的迁移事件且目标pod不存在，则调用apiServer在目标Server(Node B)中创建virt-launcher pod。3. Node A和Node B上的virt-handler会分别创建source migration proxy和target migration proxy两者通过unix socket以及TCP connection建立通信，从而将源VM的数据迁移到目的VM。 4. 在Node A上，virt-launcher最终调用libvirt的migration API(virDomainMigrateToURI3)异步进行VM的迁移，因此，和libvirt的VM migration一样，KubeVirt也支持对各类迁移参数的配置，如memory拷贝策略，迁移安全性检查等，具体参数可参考KubeVirt API[4]。 5. 在Node A上，virt-handler 检查迁移是否完成，并调用API server更新VM的迁移状态。 6. Node A和Node B上的virt-handler开始清除VM migration的相关资源。 在SPDK-vhost IO优化方案中支持虚拟机热迁移 回顾SPDK-vhost IO优化方案可以知道，我们引入了spdkVhostBlkDisk类型的块设备，使得KubeVirt能够通过SPDK-vhost接口为VM提供加速的block 功能，另一方面，上文介绍了KubeVirt迁移VM最终会调用libvirt的migration API，因此，首先我们需要探究libvirt对SPDK-vhost设备热迁移的支持。 图3为libvirt中vhost-user disk的XML文件，其中disk类型为vhostuser；source type字段指定了chardev的类型，该字段目前只支持unix；reconnect字段指定了设备是否自动恢复连接。SPDK vhost本身已经支持热迁移功能，详细介绍可参考《SPDK Vhost对Live Migration的支持》。libvirt 7.1.0版本开始已经支持了SPDK vhost-user类型的定义，并且能够支持设备的热迁移。 KubeVirt中使用VirtualMachineInstance对象管理一个虚拟机，通过Converter模块将虚拟机对象的配置参数传递到一个名为Domain的结构体中，结构体的DomainSpec字段定义了与libvirt XML文件相匹配的各种虚机配置，其中与libvirt中disk类型相对应的字段如图4所示：因此，我们在KubeVirt的Converter模块中增加SPDK-vhost接口，使得vhost类型设备的定义能够传到DomainSpec中的Disk对象中，最终就能够转化为如图3所示的XML形式，从而对使用SPDK-vhost IO优化的虚拟机支持了如图1所示的热迁移（从集群中的某一个server迁移到另一个server）。 在SPDK-vhost IO优化方案中支持设备热恢复 在维护基于SPDK-vhost方案的云服务的过程中，有时我们会不可避免地需要中断SPDK进程进行设备升级等操作，因此，我们需要集成SPDK-vhost 设备热恢复功能，从而实现更高效灵活的后端存储在线升级。该功能的具体介绍可以参考《SPDK Vhost在线恢复：让I/O飞一会儿》。 SPDK-vhost热恢复功能需要SPDK侧与QEMU侧的配合，由于相关patch都已合入，我们可以方便地在基于KubeVirt云原生的SPDK-vhost IO优化方案中集成该功能。在QEMU命令行中，我们需要在启动VM时给SPDK-vhost设备增加reconnect=1参数从而支持设备热恢复，该参数在KubeVirt中对应DiskSourceReconnect结构体，因此，我们需要在自定义的SPDK-vhost接口中为该结构体赋值，如图5所示，其中Timeout为设备尝试恢复的最大时间。与上一篇文章中的对比测试一样，我们同样使用基于Intel WSF (Workload Service Framework)框架搭建的端到端全栈式Workload，Workload的最新release版本[2]已支持虚机的批量部署测试，我们在三节点超融合集群中部署多虚机（每个虚机挂载一个虚拟卷）及rook-ceph(2副本)，对SPDK-vhost IO优化方案和KubeVirt原有的内置VirtIO方案进行性能对比测试如下： 如图6和图7所示，以VirtIO方案为基准对测试数据做归一化处理，可以看到在测试集群中部署3到90个虚机时，SPDK-vhost方案对于4k随机读及1M顺序读场景均有一定程度的性能提升。上一篇文章中我们详细介绍了Intel开源的WSF测试框架，WSF仓库中包含一系列完整，独立，可单独执行的workload， 囊括AI，网络，存储，安全等行业类型的软件栈和使用场景。Intel计划会在每个季度做一次workload的发布和更新，最新的一次是23.4的版本[3], 该release一共新增了8个workload，并更新4个workload，包括HAProxy, Nginx DLB, Calico VPP, Istio Envoy forward Proxy, Edge-Ceph-VirtIO, FFMPEG x264, Spark, Cassandra, MongoDB, Kafka, Malconv and Istio Envoy 。各workload最新release的具体介绍可以查看WSF 23.4 Release Note。 https://github.com/intel/workload-services-framework [2] Edge-Ceph-Virtio Workload: https://github.com/intel/workload-services-framework/tree/v23.4/workload/Edge-Ceph-VirtIO https://github.com/intel/workload-services-framework/tree/v23.4 https://kubevirt.io/api-reference/v0.58.0/definitions.html#_v1_migrationconfiguration https://spdk.io/doc/vhost.html
