云平台虚拟化高可用性实践 附PPT

Posted 2021-05-02 云技术实践

本文根据5月5日 UCloud内核及虚拟化研发部资深专家 吴志勇于〖KVM社区&UCloud技术微信群〗线上分享内容整理而成。欢迎关注〖KVM社区 & UCloud〗线上系列分享。

⚠注：为了能够给您带来更好的收获，我们诚挚邀请您参与我们的问卷调查。我们将在填写反馈的同学中随机抽取20名，赠送价值100元的图灵购书卡，可在图灵社区购买任意图书，截止时间5月10日。

如需填写反馈，您可以点击文末“阅读原文”，或将如下链接复制到浏览器打开。

http://form.mikecrm.com/RVhHgk

讲师介绍

吴志勇

UCloud内核与虚拟化团队资深工程师
主要负责UCloud自有专利版权的磁盘I/O加速模块设计与研发工作，在Linux内核与KVM虚拟化方面拥有近10年经验。曾就职于阿里云、IBM与红帽等公司，负责KVM vmfork、guest磁盘扩容、QEMU I/O throttling等项目的设计与研发工作。

演讲提纲

本次主要围绕 UCloud 云平台虚拟化高可用性实践和经验进行分享。内容包括问题与挑战 和 虚拟化平台高可用性实践两大部分。

1. 问题与挑战

2. 虚拟化平台高可用性实践：

• KVM模块高可用性

• QEMU高可用性

• LIBVIRT高可用性

• 宿主机高可用性

问题与挑战

对于一个拥有成千上万台服务器的公司，Linux内核缺陷导致的死机屡见不鲜。让工程师们纠结的是，到底要不要通过给服务器升级内核来修复缺陷？因为，升级意味着服务器重启、业务中断以及繁重的准备工作；不升级则担心服务器死机，同样造成业务中断和繁重的善后工作。

在今天的云计算时代，一台宿主机往往运行多个云主机，每一次重启不管是主动升级还是被动死机，都意味着中断其上运行的所有云主机。因此，宿主机内核缺陷的修复更加棘手。作为一个支撑着上万家企业用户IT基础架构的云服务商，UCloud云平台上的海量宿主机又是如何修复内核缺陷的呢？

如果按照传统的重启方式来修复，那么无论是对于UCloud或是用户，都意味着繁重的运维和业务中断。但是，通过“内核热补丁技术”——即给运行中的内核打上二进制补丁，UCloud已经做到了零代价免重启修复海量服务器的内核缺陷！目前为止，UCloud对所发现的上游内核 10+ 个缺陷全以热补丁方式修复，累计数万台次，无一例失败且无任何副作用，理论上避免了相应次数的宿主机重启及所隐含的云主机业务中断。“内核热补丁”这项技术在UCloud已经成熟。

虚拟化平台高可用性实践

UCloud 虚拟化平台高可用性主要从KVM模块高可用性、QEMU高可用性、LIBVIRT高可用性和宿主机高可用性四个方面来实现的。

1. KVM模块高可用性

KVM模块高可用性主要是从热补丁技术和远程热迁移来实现的。

1.1 热补丁技术

a） 主流热补丁技术

Ksplice

这是一套在原地 （即在运行时）对内核应用补丁的工具，它不需要重新引导。
提供现有的内核、它的源代码和一个或多个统一差异文件（统一差异文件是内核补丁的规范形式），Ksplice 就会把内核中现有的错误对象代码替换为新的对象代码。Ksplice可以替换程序代码和数据结构。
2009年07月01日，Ksplice Uptrack发布， Linux无需启动更新内核。Ksplice被称为使Linux更安全、可靠、稳定的革命性解决方案，系统补丁、内核更新等均可以无缝更新，无需重启直接完成。

Oracle公司已把Ksplice的功能列入该公司Oracle Linux 产品付费用户的基本服务项目，同时，原本Ksplice提供多款Linux操作系统免停机更新技术的业务亦将终止，将成为甲骨文的独家服务，作为甲骨文在企业Linux操作系统市场的差异化策略一环。

Kpatch

已经进入内核上游主线，kpatch属于Redhat公司，原理和前面讲的ksplice很接近。最大的区别在于二进制指令替换，stop_machine停止所有CPU执行后ksplice直接修改，而kpatch则借助ftrace机制来触发替换。目前的实现上，kpatch有较大局限性，不支持对模块打热补丁，不支持函数静态变量等。

Redhat 目前已经以 GPLv2 许可发布了 kpatch 的源代码，其主要包含以下 4 个组件：
1.) kpatch-build: 用来将 source diff patch 转换成 hot patch module；
2.) hot patch module: 包含替代函数及原始函数元数据的内核模块；
3.) kpatch core module: 为 hot patch 注册新的函数以用于替换提供接口的内核模块；
4.) kpatch utility: 允许用户管理 hot patch 模块的命令行工具。

Kgraft

属于SuSE，原理与上面2种方法也基本一样，主要的差异有两点：
1.）热补丁生成方法不同；
2.）热补丁打入内核过程里kgraft用到了RCU渐进方法。得益于RCU方法，kgraft无需像ksplice和kpatch一样调用stop_machine并检查线程栈的冲突。不过它的缺点也缘于RCU，涉及到数据结构改变时，kgraft更难通过编写辅助代码打入热补丁，这限制了kgraft的应用范围。

有关kpatch和kgraft的详细情况请分别参考Redhat和SuSE网站的技术资料。

除了免重启修复，热补丁还用于内核开发过程的性能分析和故障定位。比如，加上性能统计代码生成热补丁，就可以在线分析感兴趣的性能问题；加入额外调试代码捕捉运行中内核的异常。这些非常有用，更是海量服务器里捕捉不可重现内核异常的不二法宝。由于热补丁不需要重启服务器，既可打入也可撤销，所以不会有副作用。

b） UCloud热补丁技术

UCloud 热补丁技术是基于ksplice加以定制优化而来，通过加载一个特殊设备的热补丁模块来修复内核。

在介绍UCloud的热补丁技术工作过程之前，先简单的介绍一下Ksplice的工作原理：

Ksplice热补丁模块由ksplice程序编译生成，包含有缺陷的二进制指令和修复后的二进制指令（这些二进制按函数级别组织）；模块加载后，自动定位到内核的缺陷处并以修复指令动态替换缺陷指令。

UCloud的热补丁技术工作过程如下：

1. 首先获取一份运行中内核对应的源码并编译出二进制，称为pre对象；打上源码补丁再次编译，称为post对象。而运行中的内核二进制称为run对象。post和pre逐条指令比较并找出存在差异的函数，之后把这些差异合并为内核模块形式的热补丁。

2. 创建好的热补丁模块在加载到内核时还会做些检验工作：对比pre和run对象。只有通过检验才能成功加载进内核。pre-run比较的目的是为了辨别编译过程差异是否过大以致于不能打入post对象的热补丁；更重要的是，从pre-run差异中提取的关键信息才能把post对象的热补丁顺利打入运行中内核。

3. 热补丁模块加载到内核后，便自动进行内核修复。也就是使用热补丁中的二进制指令替换有缺陷的二进制指令。这里ksplice利用了Linux内核的stop_machine机制：停止所有CPU的执行，只留下主CPU进行二进制指令替换。值得注意的是，stop_machine后如果发现任何一个线程栈的内容与热补丁存在冲突，就需要退出指令替换以避免系统崩溃。所以并非所有热补丁都能打入内核，有些频繁使用的内核函数（如schedule, hrtimer相关）就无法热补丁，重试次数再多也无济于事。

ksplice同时支持对内核和模块进行热补丁，也支持热补丁后叠加热补丁，灵活方便。不过也存在一些缺陷：stop_machine期间整个系统处于中断状态，虽然单次中断小于1ms，但有些时候多次重试的累计中断也不小；另外，有些频繁使用的函数无法打入热补丁。

C） 对Ksplice的优化

UCloud对开源ksplice的优化主要在以下3个方面：

1. 支持高版本内核
   热补丁技术与内核紧密耦合。不同版本的内核在指令结构体，符合表结构体和一些特性上（比如早期内核没有ftrace）有所不同，直接影响热补丁成败。UCloud研究了各版本内核的区别，使得同一份ksplice支持各个版本的Linux内核。值得一提的是，解决了ftrace与ksplice不兼容的问题。

2. 允许热修复频繁调用的函数
   不管什么样的热补丁技术，两种类型的内核函数难以热补丁：频繁使用的内核函数如schedule, hrtimer；经常处于线程栈内核部分顶部的函数，如sys_poll, sys_read。UCloud更改了ksplice相关内核代码和用户态工具，成功解除了这些限制，比如UCloud现网服务器已打入了三个hrtimer热补丁。

3. 减少业务中断时间
   ksplice是在stop_machine后替换二进制指令的。虽然单次stop_machine对业务造成的中断在一毫秒左右，但有些频繁使用的内核函数需要大量重试才能碰到合适的热补丁时机，于是会造成最长达上百毫秒的中断。UCloud在此做过一点优化，使得业务中断时间控制在十毫秒级别。
   海量服务器环境下热补丁技术可用来零代价且无副作用地修复内核缺陷，而且内核开发也因热补丁能走得更远更好。以前因为缺乏辅助分析手段和惧怕内核BUG，即使适合在内核实现的特性也被告诫移到用户态实现，然而有了热补丁，相关观念也可以适当调整，内核开发也可以更加大胆和跳脱。

1.2 远程热迁移

远程热补丁主要应用背景：软件存在严重缺陷，但由于是长时间运行且有状态的服务，传统的更新升级、重启服务不能满足需求。应用热补丁技术可以在软件运行中，以极短的时间动态修复缺陷，不需要重启服务。

主要有两个技术优势：

1. 通过提高单机虚拟机密度，可节省成本；

2. 可进行客户无感知的故障处理或软件升级。

图：远程热迁移 工作原理

2. QEMU高可用性

QEMU主要是从本地热迁移和进程热补丁来实现的。

   

2.1 本地热迁移

严格来说，这是一种基于本地热迁移技术进行QEMU软件的热升级，主要是通过本地热迁移的方式将运行在老版本虚拟化软件中的虚拟机迁移到新版本的虚拟化软件中，从而达到虚拟化软件升级的目的。

本地热迁移的基本过程如下：

   

2.2 进程热补丁

   

进程热补丁一种在不重启Linux进程的条件下，对该进程的代码段进行热升级。进程热补丁，主要应用背景：软件存在严重缺陷，但由于是长时间运行且有状态的服务，传统的更新升级、重启服务不能满足需求。应用热补丁技术可以在软件运行中，以极短的时间动态修复缺陷，不需要重启服务。

    图：进程热补丁 工作原理

3. LIBVIRT高可用性

   

4. 宿主机高可用性

    
以上就是所有的分享内容，谢谢大家。

Q&A

由于提问的内容太多，无法一一在这里统一发出，本文截取部分QA问题与大家进行分享，稍后会将完整QA发送至提问的同学邮箱，感谢大家的支持：）

Q1:关于stop_machine UCloud在此做过一点优化，使得业务中断时间控制在十毫秒级别。具体是怎么做的？

答：中断时间长短主要取决于补丁函数冲突次数。优化主要集中在减少冲突发生的概率，以前可能反复很多次扫描都不能将补丁打入，使其能一次打入。

Q2:如果要给使用非常频繁的内核代码进行修复，是不是就无法使用热补丁的方式了？因为，经常会被中断。

答：这是所有的热补丁技术都面临的困难，需要通过改进热补丁技术，甚至修改内核运行行为本身以规避中断。好在这种情况很罕见，目前我们还没遇到无法打入补丁的内核逻辑。

Q3:进程热补丁具体怎么做到？对于所有的进程都可以应用吗？比如，php，mysql这些，都可以吗

Q4:UCloud 的热补丁技术，其他云厂商有同类功能吗？比较起来如何？

答：我们了解到后面其他厂商也逐渐具备这样的技术。不同厂商可能在质量和效果上略有区别，不过这需要长期的运营数据支撑，暂无法比较。

Q5:不知道进程热补丁与内核热补丁是什么关系？进程热补丁依赖于内核热补丁？

答：没有什么关系，进程热补丁主要使用与应用程序，而内核热补丁主要是用于内核问题的修复。 两者不存在依赖关系。

Q6:什么版本的内核开始支持热补丁？打热补丁有什么需要注意吗？

答：理论上所有内核版本都可以通过热补丁进行免重启修复。如果你选择的内核版本比较新，它本身可能就已经集成kpatch热补丁技术，你就可以很便捷地使用。但如果是较早版本，需要自己实现，或者ksplice支持较早版本。

Q7:我想在x86上 装openstack，然后KVM放在openpower里，然后用x86下的openstack框架去管理openpower里KVM的虚拟机可行吗？

答：我们的理解是可以的。UCloud并未使用openstack管理虚拟机，我们未实践过。

Q8:本地热迁移 与你下一步的不考内存热升级不是一个事吗？阿里好像是不考内存的，本地热迁移

答：不是一回事的。我们提到的本地热迁移是基于迁移机制，只不过源和目的机器都是同一台，需要进行内存拷贝的。阿里的不了解，可能是另一种做法，我们也有一些相关的考虑，比如通过修改内核达到不拷贝内存的目的，甚至不迁移而进行程序环境的替换等。不同做法有不同风险和不同收益，本地热迁移是我们目前稳定运营的手段，能有效解决问题。

Q9:热补丁在操作工程中会影响宕机吗？

答：热补丁本身也是内核代码，如果出了什么BUG也是会宕机的。所以，风险是存在的。但通常足够的验证可以避免风险，目前为止尚未发现因热补丁导致异常。

10:  KVM on x86，虚拟机相应硬件配置怎么合理化分。

答：虚拟机硬件配置的划分和虚拟机管理策略相关，不在本话题范围内。展开讲比较冗长，有兴趣可以单独联系我们。

11:  这个应用程序如果要支持热布丁技术是不是也需要做改造？改造量有多大？

答：不需要改造。

下期预告

相关阅读：

欢迎报名：云计算存储技术峰会.成都站

 

更多详情请扫描活动下方二维码参与报名！

云计算存储技术峰会.成都站

干货 |  技术 | 交流 | 分享