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

评估一个云平台的 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 的活动，把我们的实践与思考不断地反馈给大家。