UCloud 邱模炯:为什么内核是云平台稳定性的关键

  • 杨赛

2014 年 9 月 24 日

话题:LinuxQCon云计算DevOpsArchSummit

评估一个云平台的 SLA,一般以可用性、数据可靠性为主要指标,而因为单机稳定性存在天花板以及云计算系统的集群属性,谈及云计算 SLA 时讨论的重点主要在分布式系统而非单机。但在今年ArchSummit 大会上,UCloud 资深工程师邱模炯的分享《Linux 内核在 UCloud 云平台上的实践》则主要着眼于单机上的云主机稳定性,UCloud 广泛应用的 Linux 内核热补丁技术可以实现宿主机不重启的情况下完成内核升级,从而避免对上面云主机的业务中断。

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

嘉宾简介

邱模炯,UCloud 资深工程师,2007 年研究生毕业于北京大学计算机系,之后分别在 VMware、腾讯工作过,目前供职于 UCloud。技术经历上以 Linux 内核、虚拟化技术和数据中心自动化运维等方面为主。热爱服务器和数据中心的各种技术,研发和运维兼顾,硬件和软件兼顾,底层和应用兼顾。

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

InfoQ:云平台的稳定性是怎么定义的?它跟我们说的“可用性”是否是一个概念?它从整体的统计角度和从用户的角度,分别意味着什么?

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

稳定性是指持续一段时间内一个系统不出故障的概率,也可以把它转化为“一段时间内系统有多少次故障”。

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

举个例子,比如说一个小时内一个系统出了 10 次故障,但每次故障只要十秒钟就恢复了,那么这一个小时就一百秒出问题。另一个情况是,我一个小时内出一次故障,这一个故障花了半小时。这两个谁更严重?从稳定性的角度来讲,前面一个更严重,虽然它故障的时间只有一百秒;从可用性的角度来讲的话,后面一个更加严重一些,因为一个小时有半个小时都不能工作。这是关于稳定性、可用性的概念。

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

InfoQ:你们在内部,如何把稳定性目标转化为可监控、可量化的指标?

邱模炯:从研发角度来看,稳定性和可用性同样的重要。我们不能说把一次故障时间尽量的压缩,比如压缩到十秒内,然后我们就可以一个小时内打扰用户十次,这样对用户业务也同样会产生很大的影响。

稳定性这个指标以云主机为例,我们会统计它的宕机次数,宕机次数反映稳定性,相对于宕机累计的时间则反映可用性。

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

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

所谓承上,就是上面有云管理平台、虚拟化,而虚拟化技术跟内核技术也是紧密相关的。内核就像地基一样,地基不稳,上面就是搭空架子。

所谓启下是说,因为硬件有不可避免的故障率,总是会有问题,但是我们可以通过内核技术去降低硬件的故障率。我们还可以通过内核的工作去减少运维的工作量。比如我们在 UCloud 开发了热补丁技术,做到免重启修复内核。如果没有热补丁技术,每次内核升级不但运维非常痛苦,因为他要重启所有机器;而且用户也会被打扰,一重启,用户云主机就中断了。但是热补丁技术解决了这个问题:运维很 Happy,不用重启机器了,用户也很 Happy,他感受不到中断。

InfoQ:你这个观点挺有意思,因为一般我们听到的观点是说,云计算用分布式系统加上自动化的运维模式,去除单点,把底层故障对系统造成的影响隐蔽掉,这个关注点在于故障预测、快速的自动恢复。是什么原因造成你们的关注点不同?

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

但分布式存储追求的是什么?我们平时为了提升性能,为了数据可靠性,往往通过分布式系统里边的一些技术,比如说通过写多份去避免单份失效,通过集群去解决总体性能。

但是云主机这个基础产品,在性能上面是单点:因为一台特定的云主机只能来自于一台物理服务器。

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

UCloud 的团队成员主要是来自于国内顶级的互联网公司,所以对于分布式系统方面非常有经验,大家想到的第一印象的东西——分布式系统、分布式存储、SDN 网络——我们已经具备深厚的技术背景,已经把这方面做得很好了。所以我们进一步要把这个事情从良好做到优秀,就要挖掘内核。我们越做,越觉得内核在这里边起到的作用非常关键。

你刚刚提到我们做内核工作是要去提升它的稳定性和可用性。我们做这些工作,追求的是:云主机永远不要宕机。听起来好像有点夸张,其实我们已经非常接近这个目标了。

云主机的宕机有几个因素影响:一个是内核不稳定,另一个是下面的硬件故障,主要是这两个。内核不稳定,我们有热补丁技术给它修复,宿主机内核还是云主机内核都可以。至于下面的硬件——特别是内存,内存是硬件宕机故障的大头,那我们通过内核技术把内存硬件故障给隔离开,避免它引发宕机。

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

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

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

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

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

用户是我们的核心资产,UCloud 以用户为中心,从用户角度看待我们的产品。我们的研发、产品的工作都是围绕我们的用户而作的。

我们的用户需要那么高的 IOPS,怎么办?用 SSD。但是,虽然现在厂商认为 SSD 已经非常稳定了,过去还是发生过一些事件,导致 SSD 盘的数据丢失。SSD 盘数据丢失和我们平时那些机械盘数据丢失是不同的概念,SSD 盘要是坏了一个点,就有可能整个盘的数据没法恢复。所以说,我们是从数据可靠性的角度来做这项工作,不光是性能。

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

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

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

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

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

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

Linux 内核是开源的,UCloud 的内核成果从开源中吸取,从开源中发展。UCloud 不但掌握内核,而且发展内核,最终是希望把内核成果回馈给我们的用户,我们的业界同行。以后希望通过类似 InfoQ 的活动,把我们的实践与思考不断地反馈给大家。

LinuxQCon云计算DevOpsArchSummit