评估一个云平台的SLA,授权转发

零代价修复服务器内核缺陷 UCloud内核热补丁技术揭秘

7月18日,由InfoQ主办的ArchSummit全球架构师峰会在深圳拉开帷幕,此次会议重点选择了6个当前最受关注的领域,包括:游戏、电商、移动互联网等等。UCloud作为国内专注服务上述垂直领域的云服务商,受邀参加了本次大会。会上,UCloud资深工程师邱模炯还以《UCloud云平台的内核实践》为主题,给大家揭开了UCloud云平台内核技术的神秘面纱。其中,“UCloud内核热补丁技术”更是引发了全场架构师们的极大关注。

如何零代价修复海量服务器的Linux内核缺陷?

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

而在今天的云计算时代,一台宿主机往往运行多个云主机,每一次重启不管是主动升级还是被动死机,都意味着中断其上运行的所有云主机。因此,宿主机内核缺陷的修复更加棘手。

而作为一个支撑着上万家企业用户IT基础架构的云服务商,UCloud云平台上的海量宿主机又是如何修复内核缺陷的呢?

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

UCloud 内核热补丁技术揭秘

UCloud的热补丁技术基于多年前的开源ksplice加以定制优化而来,通过加载一个特殊准备的热补丁模块来修复内核。其过程如下图所示:

图片 1

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

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

UCloud对开源Ksplice的优化主要在以下三个方面:

支持高版本内核

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

允许热修复频繁调用的函数

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

减少业务中断时间

ksplice是在stop_machine后替换二进制指令的。虽然单次stop_machine对业务造成的中断在一毫秒左右,但有些频繁使用的内核函数需要大量重试才能碰到合适的热补丁时机,于是会造成最长达上百毫秒的中断。UCloud在此做过一点优化,使得业务中断时间控制在十毫秒级别。

海量服务器环境下热补丁技术可用来零代价且无副作用地修复内核缺陷,而且内核开发也因热补丁能走得更远更好。以前因为缺乏辅助分析手段和惧怕内核BUG,即使适合在内核实现的特性也被告诫移到用户态实现,然而有了热补丁,相关观念也可以适当调整,内核开发也可以更加大胆和跳脱。

UCloud内核热补丁技术揭秘 7月18日,由InfoQ主办的ArchSummit全球架构师峰会在深圳拉开帷幕,此次会议重点选择了...

云主机在可用性上也是单点。分布式系统追求的是怎么样去避免单点故障,但是我们现在看到各种分布式技术里面,它没有办法有效地解决云主机这个性能和可用性单点。所以我们现在尽可能地去挖掘单台物理器的性能的极限,还有可用性的极限。

2. 服务器运行时间久了,故障率会随之提升

对于云平台厂商,可以监控这一切故障发生前的征兆,并主动采取措施,通过热迁移手段避免云主机受影响。

如果说UCloud用户此间的感受是「还没开始,就已经结束」,但对于UCloud技术团队来说,却是一场非常精彩的技术实战。现在,我们将此战的过程和经验分享给大家,希望能给各位技术人带来一点启发:

在这些因素里边,我个人认为内核技术是最关键的。为什么呢?内核是个承上启下的东西。

虚拟化层和宿主机内核的故障率如何降低?

这主要通过自主掌控虚拟化层和宿主机内核,这整套内核来实现。

当不可预知的技术问题突然降临,当承载着用户梦想的业务面临巨大的风险,云服务商能否抗住压力,确保产品和服务真正的高可用性,技术团队能否在第一时间给到用户足够的支持,以及有没有足够的技术积淀来精准迅速的定位及解决问题,我们相信,或许这些才是真正重要的。

邱模炯:UCloud内核团队现在不到十个人。大家觉得不到两百人的公司为什么需要十个人的内核团队,是不是太多了?相反我觉得人数少了,应该再多一些。你想我们十人服务上万家客户,分给每个客户只有0.1个人,对不对。而我们的客户,他们也要追求稳定性,追求数据的可靠性,内核技术对他们也很重要。

本文根据高效运维系列微信群的嘉宾分享整理并发布。「高效运维」公众号作为本系列群的官方唯一公众号,原创并独家首发。OneAPM 授权转发。

近日,一个潜伏了11年名为“毒液(VENOM)”的高危漏洞被发现,该漏洞被认为比Heartbleed(心脏出血)更加可怕,因为使用该漏洞能让攻击者逃离虚拟机,访问并监视控制宿主机,并通过宿主机的权限来访问控制其他虚拟主机,从而影响到全球各大云服务商的数据安全。

InfoQ:你在演讲中提到内核工作的第二个目标是提升性能,包括IO加速模块,将IO读写顺序化记入Cache盘组,然后获得IOPS的性能还是非常高的。但是它是不是可能会对数据可靠性有影响?你们做过持续很长时间的测试,它的表现怎么样?

服务器硬件质量如何提升?

服务器硬件故障率的影响因素有厂商品牌、机型、服务器运行时间、以及部件型号的故障率。

这里的工作需要海量服务器来做,比如上万台才有意义,而几百上千台意义不大。

这里有一张图,体现我们可以主动采取部分措施。

图片 2

邱模炯:稳定性和可用性两个概念本来是很接近,说说我的看法。

##引言

很多朋友对云平台可用性有所担心,认为用物理机更加放心。今天我想就这个话题抛出个人看法。希望对大家有参考意义。先抛出结论:

从业务程序的角度,云主机的可用性可以做到比物理机高,即故障率更低(可用性和故障率接近但不是一个概念,为了便于阐述,下面只讨论故障率)。

我见过很多客户抱怨云主机的故障率。同时,我也见过并且帮好几个使用物理机的客户解决问题:

他们没有专业团队及大规模环境,对于复杂点的软硬件故障几乎束手无策,有时甚至解决的过程把小问题变成大问题。

这也是我今天分享这个话题的动力。下面进入正题,下图是云主机和物理机软硬件层次对比:
图片 3

影响云主机故障率的主要因素有:

  • 服务器硬件质量
  • 宿主机内核
  • 虚拟化层(KVM+QEMU 或 Xen)
  • Linux 内核(承载业务程序)

影响物理机故障率的主要因素有:

  • 服务器硬件质量
  • Linux 内核(承载业务程序)

从上面的对比看,云主机比物理机故障率貌似要高,因为虚拟化层和宿主机内核非常复杂,引入额外的故障率。这是直觉,而且很有道理:

AWS 去年就因为虚拟化层内核的安全漏洞大规模重启了物理机,多数 AWS 用户受影响。虚拟化层和宿主机内核的 BUG 也会同样造成宕机及重启。

那为什么还说云主机故障率可以低于物理机呢?

备注:这里我是从终端用户的角度看的,“从厂商购买的”物理机,来对比「从云平台购买的」云主机。

原因在于:简单来说,云平台厂商往往管理几万几十万台物理服务器,并有比较专业的基础运维团队和内核团队,可以在故障率上做大量的工作,以达成这样的效果:

  1. 虚拟化层和宿主机内核的故障率接近 0。这两层是内核,通过内核优化来达到;
  2. 服务器硬件质量可以不断提升;
  3. 承载业务程序的 Linux 内核,云平台可以帮助用户进行维护。并解决 BUG,修复安全漏洞等。

有人会说,我自己购买的物理机也能做上述优化,效果比云主机更好。 真的是这样的么?现实情况是:

绝大部分公司管理的服务器数量不多,不足以建立相应的团队;同时因为服务器数量少(比如不到万台),做软硬件优化的环境不理想。

下面就上述要点展开。

此消息一出,业界震惊。各大厂商纷纷紧急提供修复补丁或者发布安全公告。这需要用户停机升级而中断业务。所幸的是,该漏洞入侵门槛较高,尚未出现逃逸虚拟机的攻击工具。但是,该漏洞的理论风险非常大,不少用户表示相当担心。

可用性是指一段时间内这个系统可以正常运行的时间是多少。

2. 免重启热补丁技术

这是指通过二进制指令修改的方式修改 Linux 内核达到修复的目的。

结合自主维护 Linux 内核,如果发现了 BUG 并制作修复补丁后,可以免重启应用到生产环境的 Linux 内核里。

这点目前主流 Linux 厂商不提供。但云平台厂商可以自己做。

图片 4

InfoQ:所以其实你们认为云主机完全不出故障是一个可以实现的目标?

3. 热迁移技术

特殊情况下的热迁移,可规避尚未完全定位的内核问题。

这三点的综合效果,使得某些云厂商,因为内核原因造成的宕机低到可以忽略。几万台服务器半年可以减少到一两次。

可能有些早期用户应该比较有感觉,几年软件宕机不少,给客户推送的故障报告不时就和内核有关,但经过一年半载的工作后,现在几乎没有了。

然而,UCloud用户的业务却丝毫没有受到影响。在UCloud免重启的热补丁技术的保护下,「毒液」漏洞在第一时间内被系统静默修复,用户全程无感知,似乎该漏洞从来没有在这个世界上出现过一样。

邱模炯:对。除非出现一些不可抗力,比如说一个机房、一台服务器突然断电,那我是没有办法。

##观点总结

简要总结一下本文的主要观点:

  1. 云主机相比物理机,虚拟化层和宿主机内核的额外复杂性及故障率可以被优化至接近 0 即可以忽略。

  2. 服务器硬件故障,云平台可以不断降低其故障率,主要手段通过内核隔离硬件故障、热迁移规避故障隐患,以及监控故障率并主动下架不良厂商机型等。

图片 5

上述这些工作都需要非常专业的运维团队和内核团队才能实施,如果没有足够大的服务器数量是很难开展的。

而大型云厂商往往管理几万、几十万服务器,因此具备这样的条件。也因此,云主机故障率能低于物理机(当然,如果什么都不做,云主机故障率一定是高于物理机的)。

本文系 OneAPM 工程师编译整理。想阅读更多技术文章,请访问 OneAPM 官方博客。

【编辑推荐】

邱模炯:你说的对,大家提到云平台,非常容易想到有个大的分布式系统,有分布式存储、分布式网络。

1. 自主维护Linux内核

商业 Linux 发行版(如 RHEL6.X)的内核其实有不少 BUG,因为内核太庞大、太复杂,BUG 修之不尽而且不断涌现,只要内核有人在改动,更多的 BUG 就还在路上。

但我们自己维护的 Linux 内核,我们可以迅速修复并应用进实际环境,不像商业 Linux 要等待较长的发布周期。

我们还可以预先研究别人犯过的错误,把更新补丁打入现在的内核;还可以屏蔽不必要的特性和改动避免 BUG 的引入。

简单讲,自主维护内核很灵活,最终质量不低于商业 Linux 发行版。国内有海量服务器的公司如腾讯和阿里都运行自主维护的 Linux 内核。

结语

大公司为什么需要内核团队?因为他们有很多的服务器。UCloud也有大量的服务器,我们目前有万台级别的服务器。公司是否需要内核团队,其实是由服务器的数量、数据中心的规模,以及我们的客户是否需要来决定的。

编辑

  • 徐凯强@和信-北京(内容收集、发布)

图片 6

本文由必威发布于必威-运维,转载请注明出处:评估一个云平台的SLA,授权转发

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。