前言
KVM forum 2019上,作者和同事的演讲主题是《How KVM-based Hybrid Deployment Powers Bytedance’s Biggest Day Ever》。
在这里详细展开一下,介绍一下基于KVM虚拟化的混合部署。下文的脉络大约是:
1,业务背景
2,为什么使用KVM虚拟化方案
3,在使用KVM虚拟化方案的过程中,我们做了那些改进
4,基于KVM虚拟化的混合部署方案取得了怎样的效果
业务背景
对象存储服务(OSS)是典型的IO密集型的业务,对CPU&MEM、甚至是网络消耗都比较低,在存放冷数据的服务器上,CPU的使用率甚至不足5%。
典型的在线业务一般是网络应答式,接收网络请求,处理后返回结果,一般是CPU/MEM密集型,IO消耗一般是业务写log,网络流量一般也不高。
可见,二者的业务特征具有一定的互补性,可以尝试把两种业务进行混合部署。
为什么选择虚拟化
混合部署一直以来都是一个长期讨论、实践的主题。之前,有很多基于cgroup/docker的混合部署的文章和总结也给我们提供了大量的参考,其中有技术改进、最佳实践以及对未来的思考等等。然而,作者所在的团队最终选择了KVM虚拟化方案,原因是KVM虚拟化提供了更高的隔离性,总结如下。CPU的隔离性问题
写一段代码,16线程并行执行,配置cgroup为4 CPU的quota。使用top -d 1查看,可以发现CPU的消耗基本在400%左右。我们使用脚本收集数据,以1s为粒度,可以看到效果如下:
如果把时间粒度改成10ms收集一次,可以看到如下效果:
由此可见,Linux本身的调度基于tick实现,cgroup可以保证在一个相对较长的实践范围内实现比较好的CPU限制,但是在较细的粒度上是无法保证的。(详细代码和数据可以参考前文《Cgroup CPU Quota技术的不足》)。
我们继续以MySQL为例,在server端启动mysqld进程,在client端启动sysbench压测。同时启动上述的示例代码,设置quota是4 CPU,理论上来说,在12 CPU的服务器上,应该不会对mysql的性能产生非常大的影响。然而实验效果如下:
在19s ~ 29s之间,mysqld的TPS发生了比较剧烈的抖动。
对比实验KVM,启动一台4 vCPU的虚拟机,在虚拟机内部运行上述的示例进程,监控qemu进程的CPU消耗,无论在1s还是10ms级别,CPU消耗始终不会超过400%。TPS有所降低,但是非常稳定。
收集延迟的PCT99在虚拟机中更加稳定,对比如下:
调度模型对比
作者知道的几种在线业务模型:
python业务:由于python是单线程模型,有的业务会选择使用CGI模型,fork起来多个进程(通常是1K量级)。也有python框架实现了异步IO,会启动较少的进程。还有会调用c库,创建起来多个线程。
golang业务:多协程下面有多线程。
java业务:多线程,锁住大块内存。
C/C++业务:多线程,有可能伴随着大量的内存分配/回收。
当然还有更多的不知道的业务场景,由于无法预测在线业务的类型,也无法预测在线业务的workload,就很难有一种适配所有场景的进程隔离方式和内核调度策略。在虚拟化场景下,调度模型就会变得非常简单:在宿主机上仅仅有有限的vCPU线程,通常一个36核的虚拟机仅仅有36个vCPU线程、一个QEMU主线程、有限个数的IO thread、vnc thread等不到50个thread。取得的效果是把大约1K以上的业务Task转换成了大约50个虚拟机的Task。
把复杂的业务调度模型放到虚拟机内部中去,在通过一定的CPU亲和性隔离,宿主机上运行的OSS业务的QoS很容易获得了调度上的保证。内存模型对比
在Linux服务器上,通常有文件映射(page cache)、匿名映射、free memory、slab内存,内核管理这些内存,维持着各个NUMA node的各个zone的内存分配/回收。且有了cgroup的内存管理之后,内存管理的复杂度进一步提升。
在cgroup/容器隔离的场景下,由于上文提到的业务类型很多,导致服务器上的内存模型相当复杂,且难以预测。
在KVM虚拟化场景下,则会变得简单,对于一台虚拟机,仅仅使用匿名映射,且PC-RAM内存可以使用大页,尤其是HugeTLB隔离出来的内存不再受到Host上的buddy system管理,Host上的内存管理成本几乎没有任何的影响。
磁盘IO的隔离对比
Linux目前无法很好的支持page cache隔离(最新的Linux upstream上开始有些支持,但是效果不好。且目前的LTS版本中都没有支持),page cache隔离不好就很难做好磁盘的IO隔离。
另外,还有一些隐式的竞争,在mysql使用的数据库的分区(EXT4)上,删除一个较大的文件,mysql的TPS会发生一次抖动,效果如下:
尽管删除一个文件,不会涉及到文件的数据IO,但是因为删除inode,修改了meta data,EXT4会记录journal,而一个文件系统分区只有一个journal线程,这里是串行执行会成为瓶颈。大一些的文件通常会大一点的meta data,会使用较长的时间。在这段时间内,mysql的Create/Update/Delete操作都可能涉及到meta操作,就会产生抖动。
在虚拟化的场景,可以使用裸磁盘分区通过Block访问的方式提供给虚拟机使用。Host上将不再需要文件系统的参与,甚至可以给虚拟机挂载远程盘。同时QEMU对虚拟块设备的IO限速有很好的支持,通过bandwidth和IOPS两个维度的限速,可以让Host进程对盘的访问依然稳定。
同样的测试场景在虚拟机中的表现很好,mysql的TPS和延迟几乎看不到差异。网络IO的隔离对比
在cgroup/容易的场景下,OSS和业务进程共享整个Host服务器的内核和网卡硬件。目前内核还不能有效的控制每个进程/一组进程的网络IO的bandwidth和PPS。例如在线业务在拉取docker镜像的时候,会有一个大的网络IO的突刺,OSS的QoS有可能会受到影响。甚至在线业务使用过多的本地端口会影响OSS对外部服务的访问。
在虚拟化场景下,使用SR-IOV的方式分配出来一个网卡的virtual function,把VF透传给虚拟机,对VF进行硬件的bandwidth和PPS限速,且Host和Guest分别是两个完全独立的网络协议栈,二者之间没有任何干扰。稍微麻烦一点的地方就是需要额外配置TOR,控制好分配的IP。当然,使用overlay网络也是可行的。内核版本的差异对比
在cgroup/容器场景下,因为共享同一个内核,所以必须使用相同的内核版本。对于OSS,一般对kernel版本要求不高,且希望稳定不间断的运行。而对于在线业务,尤其是涉及到cgroup/容器之后,对内核版本通常有更高版本的要求。
在虚拟化场景下,Host可以在不做改动的情况下,动态加载kvm的kmod到内核中,启动虚拟机。在虚拟机中,可以运行任何版本的内核,甚至windows。
对虚拟化的改进 --- kvm-utils
在混合部署的场景下,Host通常是在线运行的,且不能升级内核/kmod。但是debug依然是必要的,为此,开发了kvm-utils工具,用来分析虚拟化的性能问题。kvm-utils的debug功能基于kprobe,可以动态的安装/卸载。分析vm-exit功能的效果如下:
分析wrmsr exit的效果如下:
kvm-utils还包含microbenchmark功能,能够测试PIO/MMIO/TIMER/IPI的消耗的时钟周期。软件很快将会开源在https://github.com/bytedance。
使用kvm-utils可以帮助分析很多性能问题,例如:
例子一,业务侧反馈说gettimeofday消耗的时间比正常偏高,kvm-utils可以发现PIO变多了。分析下来发现Guest内部的时钟源异常导致。因为关掉了kvm-clock,希望使用tsc作为默认时钟源,但是因为缺少了tsc reliable的参数,导致guest里面误认为tsc不稳定,自动切换到了acpi-pm导致的问题。
例子二,虚拟机内部的业务的QPS低于物理机,kvm-utils发现wrmsr TSC DEADLINE vm-exit超过了1M/s。后来发现是tcp的拥塞算法使用了bbr设置了太多的timer导致。对虚拟化的改进 --- nohlt_list
作者使用的环境下,Host上有48个CPU,其中12个预留给OSS业务,于是启动了36 vCPU的虚拟机。
网卡VF有8队列,在虚拟机内部通常把中断亲和性绑定到CPU 0~7上。每秒钟大约150K ~ 500K左右的网络中断。那么平均单核每秒的中断数量大约在20K~60K左右,这样的数据量不足以让vCPU 0~7一直处于忙碌状态,所以vCPU进程需要执行idle任务,从而运行HLT指令而发生vm-exit。下一个网络报文到达VF后,vCPU将会被Posted-Interrupt Wakeup Event唤醒,重新进入none-root模式。
不断的HLT退出到PIW唤醒导致虚拟机处理中断的延迟不稳定,业务的延迟也会有偶尔的抖动。
当前内核中支持nohlt或者idle=poll模式,就会让所有的vCPU一直处理polling模式,不会执行HLT指令退出,但是这也意味着在Host上看到所有的vCPU thread都是100%的CPU消耗状态,这对于混合部署来说是不友好的。同时,这种polling会损害 CPU的另外Hyper-Thread的性能。
为此,作者开发了nohlt_list功能:允许一部分CPU跑在polling模式,配置内核启动参数如下:
linux ... irqaffinity=0-7 nohlt_list=0-7
只配置处理网卡中断的vCPU(0~7)跑在polling模式,在Host上只看到8个vCPU线程跑在800%,对于整机的48个CPU来说,不是太大的问题,同时虚拟机内部处理网络中断的延迟是稳定的。业务表现上PCT99也有所改善。
Patch: https://lkml.org/lkml/2019/5/22/164
PIW数据的测试效果,随机选择1K的服务器,对于没有启用nohlt_list的情况,多数服务器每秒会产生20K~100K的PIW:
对于启用了nohlt_list的场景,所有的服务器上都只有很少的PIW,实际上多数都是0。
对虚拟化的改进 --- 用户进程
例子一,atop是Linux上一个监控软件,在作者的工作环境中,深受大家喜爱。然而atop会自动收集Instruction Per Cycle的信息。收集IPC信息需要使用PMU,在虚拟化场景下,虚拟机中使用vPMU会造成wrmsr/rdpmc的vm-exit,就会看到虚拟机的vm-exit每隔一段时间就会发生一次抖动(默认是10s)。为此,作者修改了atop程序,让atop在启动阶段自动检测运行环境,如果是在虚拟机中,则默认关闭IPC收集功能,当然也可以通过配置强制enable/disable。
patch在https://github.com/Atoptool/atop/commit/16abcac132eec4755373aa673389e67219488844
例子二,jemalloc是一个高性能的用户态内存管理库,有一些cache型的业务会使用jemalloc代替glibc的ptmalloc。但是jemalloc的decay特性会调用madvise(void *addr, size_t length, MADV_DONTNEED),而这个操作会触发TLB shootdown(上文《[Linux][mm]TLB shootdown和读取smaps对性能的影响》一文中有更多的描述),TLB shootdown在虚拟化上的成本要高于物理机,所以cache型的业务的QPS和延迟通常要略差于物理机上的表现。简单粗暴的办法是最好关闭掉decay功能,性能会接近物理机。
取得的效果
如上文所说,OSS服务器的CPU利用率普遍不高,随机选择了7K服务器,在晚高峰九点到十点左右收集CPU数据绘制分布图,大部分的服务器的CPU使用率在10%以内,还有部分服务器的CPU使用率在20%以内:
使用了KVM虚拟化混合部署的方案之后,几乎所有的CPU使用率都得到了很大的提升:
在CPU利用率提高的同时,额外超分配出来的百万量级的CPU得到了充分的使用。得益于KVM虚拟化的强隔离性,Host上的OSS业务几乎没有任何的损耗,而Guest内部的在线业务的性能也逐渐接近物理机,在性能调优之后,性能在一些场景下要好于某云计算大厂的虚拟机。