【www.hj8828.com】观点 | 为什么说云主机比物理机故障率更低?

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

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

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

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

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

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

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

UCloud 内核热补丁技术揭秘

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

www.hj8828.com 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. 免重启热补丁技术

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

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

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

我昨天还想了想,过去至少连续三个月,我都没有收到任何一起宿主机内核引发宕机的报警短信。

##引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面就上述要点展开。

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

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

邱模炯:我们不光是测试,我们已经在生产环境下面稳定运营了快一年,从来没有发现过可靠性的问题。相反,其实我们恰恰是从可靠性的角度来做这项工作的。

作者介绍

邱模炯
UCloud
平台开发中心总监,北京大学计算机系研究生毕业,擅长操作系统、虚拟化和数据中心自动化等云平台的基础技术。

国内的内核人才确实比较稀缺。现在我们收简历,能收到一大堆做分布式系统、或者做前端开发的简历,但是很少收到内核人才的,即使收到,也很少说对云平台有非常深的认识和钻研,因为云平台也很新。但内核技术对于云平台技术又非常关键,考虑到这个情况,UCloud大概一年半之前就开始建内核团队,现在正在发挥非常重要的作用。

3. 硬件宕机和部件缺陷关系很大

我们的统计发现,部件种类里,硬盘故障故障率最高,其次内存硬件、RAID
卡等。

对于硬盘故障,可以通过 RAID
方式规避。对于内存硬件,可以通过内存故障隔离等内核手段,大幅度减少其硬件故障造成的宕机及影响。

总的来讲,通过上述这些工作,云平台厂商可以让服务器硬件故障率逐步降低。其实,可以做的更多,篇幅原因就不讲了。而这样的工作,对于没有海量环境的公司是很难做的,效果也不佳。

另外,云平台厂商可以替用户修复云主机内核的 BUG
和安全漏洞,降低内核故障率。

我们在这方面做了一些工作,内核版本会及时更新,关键漏洞会提供免重启热补丁修复包。

这两个指标都是用户可以感知的:稳定性关系到给用户带来的打扰次数,可用性关系到用户的业务能够保持正常运行的时间。我们现在对云平台的可用性一般会设置一个量化指标,比如UCloud对外的服务,云主机的可用性是99.95%,存储的可用性比如说是四个九、五个九。而另一方面,很少有人在量化指标里去提稳定性,大家更关心的是可用性的概念。

3. 热迁移技术

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

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

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

InfoQ中文站编辑跟邱模炯进行了一次交流,了解UCloud关注单机稳定性背后的原因。

1. 服务器故障率和厂商机型关系密切

我们可以监控各厂商机型的故障率,主动下架比较差的,从而提升总体质量。

一般来说,小厂的服务器故障率会高一些,但大厂即使
DELL、联想的个别机型也会有较高故障率。

这主要和机型设计和生产质量管控有关,就不阐述了。我们能做的是选择故障率低的厂商和机型。

影响稳定性、可用性的因素,涉及到整个云平台技术方方面面。从上往下看整个云平台技术,首先是一个云管理平台——如OpenStack这样的平台,然后是虚拟化技术——也是云平台的一个核心技术,下面是Linux内核,然后是硬件——云平台最终是把数据中心的硬件、资源给池化,然后卖给用户,所以涉及到硬件技术。然后,我们这么多的硬件,我们的内核、虚拟化、云管理平台,我们要怎么样运维它。这些方面都影响稳定性、可用性,哪个环节做得不好都会导致稳定性、可用性的下降。

1. 自主维护Linux内核

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

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

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

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

邱模炯:数据可靠性有一个量级的提升,性能是两个量级的提升:对于IOPS机械盘一般是一百到两百,我们把它提升到两万到三万。

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

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

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

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

www.hj8828.com 3

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

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

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

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

编辑

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

InfoQ:能有一个量级的提升吗?

##观点总结

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

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

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

www.hj8828.com 4

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

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

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

InfoQ:最后一个问题是有关内核人才这方面。国内的内核人才其实比较稀缺,而UCloud现在还算是一个初创企业。你们怎么去评估自己维护内核团队是不是划算这件事情?

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

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

邱模炯是2014年10月QCon上海大会《扩展性、可用性和高性能》专场的出品人。