您的位置:  首页 > 技术杂谈 > 正文

字节跳动提出KVM内核热升级方案,效率提升5.25倍!

2022-11-10 15:00 https://my.oschina.net/u/6150560/blog/5590922 字节跳动SYS Tech 次阅读 条评论

作者介绍:Fam Zheng,字节跳动STE团队内核工程师,Linux 和 QEMU 开源贡献者和社区维护者。10 年系统工程师工作经验,关注 Linux 内核、虚拟化、性能等领域。当前主要负责 KVM 虚拟化研发和系统性能优化工作。

介绍

作为云计算最重要的底层基础之一,KVM 虚拟化软件在现代的数据中心中应用非常广泛。基于 KVM 的 hypervisor 包括了构成宿主机的软硬件,共同为虚拟机中的应用程序提供高性能的 CPU、内存和 IO 设备等资源。在大规模部署的生产环境中,作为云服务提供商(Cloud Service Provider),如何从技术上保证软硬件的可运维性,一直是大家重点关注的问题。

为了给用户提供稳定、安全、高效并且功能丰富的云资源,IaaS 的底层软件必须能够支撑软硬件的各种运维需求。例如,在偶然出现一些难以避免的硬件故障时,需要能够把虚拟机及时热迁移到健康的宿主机;或者,在软件安全漏洞或功能缺陷被修复后,能够通过热升级,及时部署上线到生产环境中。

然而实现用户无感知地热迁移和热升级,却是一个复杂的系统工程问题。因为 KVM 虚拟化涉及众多不同层次的组件、诸多特性和灵活可选的组合方式,其中不乏一些非常复杂的软硬件技术例如 SR-IOV、Linux内核、QEMU、DPDK、KubeVirt 或者 OpenStack 等,系统总体架构复杂度很高。而且这些软硬件模块各自都有复杂的接口和内部状态,在不影响虚拟机正常运行的情况下,要做到宿主机软件的热升级和热迁移,还需要做一些针对性的设计或改造。同时,作为云计算底座的一部分,它们也需要紧密的配合才能完成预期的功能。特别是对于内部状态处理能力要求非常高的热升级功能,更需要深入、全面的打通。

目前,在各个开源社区(如 Linux,QEMU,CloudHypervisor 等)和各大云计算公司,都在积极的尝试对 KVM 的热升级支持进行研发,也是历年各大技术峰会的一个重要研讨主题。字节跳动技术团队从实际场景出发,相应地对热升级问题进行了深入分析,与开源社区紧密合作,从多个角度做出了深度探索并取得了进展。

在今年 9 月份举行的虚拟化领域全球技术峰会 KVM Forum上,字节跳动系统技术与工程团队(System Technologies&Engineering,简称STE团队)公布了相关的技术成果:首次提出一种在KVM热升级场景中透明支持PCI直通设备的方案,能够显著降低内核热升级的实现成本。通过对 host 内核和 QEMU 的扩展和改进,可以做到不依赖于特定硬件修改或者 guest 配合的热升级,支持 PCI 直通设备。同时,在性能方面,也通过深入的分析和优化,将一次内核热升级所需的最少时间(downtime)从 1000ms 降低至160ms,效率提升 5.25 倍

本文将整理回顾 KVM Forum 大会中分享的主要技术方案,以飨读者。

KVM Forum 会议演讲视频链接:

Preserving IOMMU States During Kexec Reboot:https://share.weiyun.com/Mz3Wk6v8

关注【字节跳动SYS Tech】公众号,后台回复“PPT”即可获取本次分享的PPT材料

IOMMU 状态保持

PCI 设备直通在当前数据中心的 KVM 虚拟化场景中广泛应用,能够为虚拟机中的应用提供高性能的 IO 设备。同时,直通设备的使用也为云计算底层软件设施的运维带来了一些复杂度。

其中,对热升级和热迁移的兼容性是 PCI 直通设备的一大难点。这是因为热升级或热迁移操作依赖于对虚拟机状态的提取、保持、传输等操作,而 PCI 直通设备的状态数据对于宿主机侧的 hypervisor 是不透明的。因此在 IaaS 的实践中,往往需要对使用了直通设备的虚拟机进行特殊处理。例如,通过定制的 SR-IOV 硬件,实现PF 管理 VF 状态的逻辑;或者在虚拟机中运行特殊的驱动程序和 agent 进程,通过guest 在过程中的协同配合来完成热迁移或热升级操作。

这些方法可以在一定程度上解决 PCI 直通设备的运维难题,但是带来了更高的研发成本、软件和配置的复杂度,也有可能会牺牲用户体验和 IO 性能。

技术 方案调研

在 KVM 中对 PCI 设备的直通需要通过 VFIO-PCI 接口来完成。VFIO-PCI 是 Linux 内核对 IOMMU 和 PCI 底层逻辑的抽象封装 API,提供给运行在用户态的 QEMU 或者其它 VMM(Virtual Machine Manager)软件来配置虚拟设备的 IO 映射关系,从而允许虚拟机内核驱动直接访问硬件资源,以达到较高的 IO 效率。

在热升级过程中,虚拟机的运行状态需要被稳定的保持在升级之前的状态,其中包括虚拟机的 CPU 状态(寄存器里的数据等)、内存数据、虚拟设备的接口状态和内部状态等。对于 PCI 直通设备来说,有2个思路:

  1. 设法提取设备的状态数据,备份在预先设计好的位置(如预留的内存或者磁盘),然后在热升级结束之前,从备份中恢复。提取备份的过程,一般称之为序列化;从数据中恢复状态的过程称之为反序列化。

<!---->

  1. 不提取设备状态数据,并在热升级过程中完全不改变设备状态。热升级完成后,虚拟机继续访问这个硬件设备。

前一种思路已经被证明是可行的方案,并且在某些较新的硬件中已实现,它的优点是不仅可以用来热升级,也可以用来热迁移;在热迁移过程中,虚拟机会被转移到不同的物理机上,也就不可能再使用同一个设备。但是,这个方式的缺点是必须有硬件支持,同时因为存在序列化、反序列化的操作,完成热升级所需时间较长。

我们对第二种情况进行调研和实验后发现,通过对 Linux 内核进行一些局部的修改,在 Intel IOMMU 上可以实现在热升级过程中,设备状态的完全隔离和保护,从而得到一个 PCI 透传设备的热升级通用支持方法。

解决方案

本文提出的方案主要包括三个部分。

改进一:通过在 hypervisor 中引入必要的静态页面分配,保证 kexec 重启过程中的状态保持。

静态分配主要有用户态和内核态两部分工作。其中,用户态的工作方式为:

  1. 虚拟机的 RAM 使用 memmap 方式分配,在 host 侧使用 DAX 的形式管理。 memmap 是一个内核参数,可以为物理内存分配不同的属性。其中 E820 type 12是一个 NVDIMM 类型(例如 memmap = 2G!6G)。

<!---->

  1. 这个类型的物理页,将不再被内核动态管理,而是作为“非易失性内存”来看待。在启动后,我们可以通过创建一个 DevDax 字符设备,mmap 到 QEMU 的地址空间。

<!---->

  1. DevDax 的创建可以使用系统调用,也可以用 ndctl 命令:
ndctl create-namespace -m devdax
  1. 该命令会创建一个类似 /dev/dax1.0 的字符设备。这个字符设备提供一个支持DAX(Linux内核提供的直接物理地址访问机制)的 mmap 接口,可以直接将物理内存映射到 QEMU 用户态。QEMU 命令行参数如下:
$qemu ... -object memory-backend-file,id=mem,size=2G,mem-path=/dev/dax1.0,share=on,align=2M \-numa node,memdev=mem
  1. 而后 QEMU 会通过 KVM 接口把这段预留内存用于填充 EPT 页表。

改进二:内核态的静态分配实现需要通过一个内核补丁来实现

  1. 我们在内核中引入了一个新的物理页管理器 KRAM,为其它模块提供2个分配页的函数接口。这两个接口的主要目的是提供静态物理页给硬件相关模块。

    • kram_get_fixed_page(area, index)
    • kram_alloc_page()

<!---->

  1. 在 E820 的 enum 中定义新的 type 用以预留物理页给 KRAM:memmap=:

<!---->

  1. 在 Intel 的 IOMMU 驱动模块中,使用 kram 接口来分配 root page 和 DMAR page。包括iommu_alloc_root_entryalloc_pgtable_page等函数中,将原本的alloc_pgtable_page替换成对 KRAM 模块的调用。

改进三:对 VFIO 设备简化,保证硬件状态不被干扰

在VFIO-PCI相关系统调用(VFIO_GROUP_SET_FLAGS)中,我们加入了一个新的标志位,用以在 QEMU 热升级过程中,跳过对VFIO-PCI设备的初始化和重置。

第二、三部分的相关代码将会在后续开源。

PoC 验证

目前我们在 QEMU 模拟环境中对上面的方案进行了实验。借助 KVM 在 Intel CPU上的嵌套虚拟化支持,和 QEMU 对虚拟 IOMMU 的支持,可以很快的启动一个测试环境:

$qemu -machine q35 -device intel-iommu,intremap=on-cpuhost... -device e1000e,netdev=guestnet

上面的命令启动的嵌套虚拟化的 L1,运行的是增加了 VFIO-PCI 热升级的内核。对 L1里安装的 QEMU 同样也加入了 CPR(Checkpoint Restore)和 VFIO-PCI 的扩展调用。

使用 VFIO-PCI 我们分配上面的虚拟 e1000e 网卡给 L2:

$qemu ... -device vfio-pci,addr=06.0,host={dev}

然后,通过 cpr-save -> kexec -> 启动qemu -> restore 的流程来热升级整个 L1。

在测试过程中采集到的时间记录如下:

从暂停虚拟机,到重启以后虚拟机恢复运行并在虚拟网络上继续发包,一共经过了 159ms。虚拟 e1000 网卡在这个过程中没有被 reset,始终保持运行状态。也就是说从外部或者应用视角来看,因宿主机热升级而导致的总响应时间,仅仅增加了不到 160ms 的时长,并且由于网卡的 rx 队列始终可用,在流量较低的情况下,也不会导致丢包和重传。相比之下,如果用内核和 QEMU 的主线版本来执行上面的流程,可以采用 savevm 到磁盘后 kexec 重启并 loadvm 的步骤。但是这样不仅不能支持VFIO-PCI设备,也会因为缺少各种优化(如:savevm/loadvm 需要复制虚拟机内存),产生 1000ms 以上的 downtime 延迟。

结论

在使用 VFIO-PCI 透传设备的宿主机上,部署了具有上述改进的 host 内核和 QEMU 等程序。在测试中,基于 QEMU 通用的 checkpointing and recovery(CPR)框架,我们现可以支持低损耗的 host 内核热升级动作。从暂停虚拟机,到重启进入新内核并继续执行虚拟机,整个过程可在 160ms 左右完成。

此技术方案可被应用在公有云和私有云的 IaaS 业务场景,具有很高的实用价值,能够显著降低运维成本,提高云的安全性,并优化运维过程中的虚拟机运行性能和客户体验。字节跳动系统与技术工程团队将会继续优化 Linux 内核和虚拟化软件,为数据中心持续提供安全、稳定、高效运行的系统软件。

此外,在 Virtio 设备标准,QEMU 热升级,Linux 启动时间,io_uring,kexec 等方面,团队也进行了深入的研究和优化。我们将会在本文和后续文章中持续分享相关技术和最新进展。

文章引用链接

CPR(Checkpoint Restore): https://patchew.org/QEMU/1658851843-236870-1-git-send-email-steven.sistare@oracle.com/

欢迎加入 STE 团队

字节跳动STE团队,一直致力于操作系统内核与虚拟化、系统基础软件与基础库的构建和性能优化、超大规模数据中心的系统稳定性和可靠性建设、新硬件与软件的协同设计等基础技术领域的研发与工程化落地,具备全面的基础软件工程能力,为字节上层业务保驾护航。同时,团队积极关注社区技术动向,拥抱开源和标准,欢迎更多同学加入我们,一起交流学习。扫描下方二维码了解职位详情,欢迎大家投递简历至huangxuechun.hr@bytedance.comwangan.hr@bytedance.com

扫码查看职位详情

您还可关注【字节跳动SYS Tech】公众号获取最新的招聘职位信息,团队长期招聘,北京、上海、深圳、杭州、US、UK 均设岗位,期待与你早日相遇,在字节共赴星辰大海!

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接