2019 年 4 月,Alibaba Cloud Linux 2 (Aliyun Linux 2) 正式开源。时至今日,已经走过三个月的里程。在这段时间内,这个刚诞生不久的为阿里云 ECS 环境定制优化的 Linux 操做系统发行版的装机量稳步上升。咱们常常接到内部和外部的客户咨询 Alibaba Cloud Linux 2 相关的问题,所以本文将重点介绍 Alibaba Cloud Linux 2 的特性更新;此外,咱们认为云计算业务中,操做系统的角色至关于“水和空气”的地位,平日里的存在近乎透明,而一旦出问题却使人难以忍受,所以除了了解特性列表,本文也将介绍 Alibaba Cloud Linux 2 开发过程当中的决策过程与质量保证细节,但愿更高的透明度能够加强用户的信心。html
图:Alibaba Cloud Linux 2 (官网产品名:Aliyun Linux 2) 在 阿里云 ECS 上过去一个月 vcpu 保有量增加示意图 (仅展现趋势,不表明绝对数值)
2019 年 4 月正式对外开源的 Alibaba Cloud Linux 2 是下一代 Alibaba Cloud Linux (官网产品名 _Aliyun Linux_)操做系统发行版,以 CentOS 七、社区长期支持版 (LTS) 内核、其余社区版用户态软件及阿里巴巴多个开源内部产品等多个来源为上游,为云上应用程序环境提供 Linux 社区的最新加强功能,在提供云上最佳用户体验的同时,也针对阿里云基础设施作了深度的优化和定制。linux
Alibaba Cloud Linux 2 开源的重要亮点是自带的阿里云云内核(Cloud Kernel),同时也是开放在 GitHub 上的 Alibaba Cloud Linux Kernel 项目[1],它是开发团队全体成员倾力打造的一款内核产品,旨在将阿里巴巴操做系统团队多年技术积累分享给社区,也欢迎志同道合的开发者一同参与内核开发协做,共同创造更加有益的价值。git
Alibaba Cloud Linux 2 的开发团队是阿里巴巴操做系统团队,前身是淘宝内核组,团队成员大可能是活跃在内核社区的开发者,九年来积累了深厚的操做系统和内核开发底蕴。github
Alibaba Cloud Linux 产品是阿里技术商业化和开源思想完美结合的范例。在阿里云 ECS 产品中做为官方镜像之一,Alibaba Cloud Linux 与 CentOS, Ubuntu 等社区发行版一同做为选项提供给客户,并为 ECS 环境定制了多项特性和性能优化;不只如此,Alibaba Cloud Linux 更天生带着开源的基因。开放源码是一种共享的黑客精神,从开放源码运动诞生至今,无数优秀的开源产品给数以百万计的软硬件产品和云产品提供了强大的基础系统底座支撑。站在这些巨人的肩膀上,咱们继承开源的精神,创造了 Alibaba Cloud Linux 产品,如今,又推出了 Alibaba Cloud Linux 2 操做系统发行版,并以相同协议开源,将咱们的工做成果回馈到社区。安全
Alibaba Cloud Linux 2 最主要的功能更新是内核更新,基于内核社区长期支持(LTS)的 4.19 版本定制,在 CPU、内存、文件系统、IO、网络、cgroup 等子系统上增长了大量适用于云场景的新特性、性能改进和重大缺陷修复,支持:性能优化
此外,和内核相关的功能和改进还有:服务器
过去三个月,Alibaba Cloud Linux 2 发布了两个镜像更新。最新版本的系统的镜像 ID 为 aliyun_2_1903_64_20G_alibase_20190619.vhd
。网络
在最初发布的版本中,咱们只容许用户经过 ECS 控制台购买的方式建立新的虚拟机。从 20190517 版本开始,咱们提供了可独立下载的系统镜像文件,用户能够更方便地基于 Alibaba Cloud Linux 2 系统镜像建立并使用本身的虚拟机。咱们但愿藉由此方式,让用户更积极地参与到 Alibaba Cloud Linux 2 的使用中。架构
当前的独立系统镜像文件为 qcow2 格式,运行时支持基于 QEMU/KVM 的虚拟化环境,在虚拟机中使用 virtio 驱动。独立镜像下载后初始化须要依赖 cloud-init
机制,详情请参考独立镜像说明文档[2]。框架
除了镜像迭代, Alibaba Cloud Linux 2 还持续保持系统 YUM 源的更新,用户能够在操做系统内经过 yum update
命令维持软件包的最新状态。
内核方面的更新,咱们持续基于社区 LTS 4.19 内核 rebase 代码,加上自研功能和 Bug 修复。每三到四个星期,咱们会快速迭代发布一个新的内核包。在迭代周期内,除了完成必要的稳定性测试,咱们也会积极修复内核BUG并反馈到内核社区。在接下来的章节会详述。
在操做系统发行版基础系统(BaseOS)功能方面,除了常规同步上游社区的修复与更新,咱们选择性地更新了多个用户态软件包,以匹配最新的内核功能及其余平常使用需求,而且对这些包进行了必要的测试和独立的维护。更新的软件包包括但不限于:crash
, e2fsprogs
, xfsprogs
, iproute
等。
此外,咱们还与阿里巴巴内部其余团队合做,持续将阿里巴巴的开源成果集成到 Alibaba Cloud Linux 2 中并输出给用户。目前集成并保持更新的阿里巴巴内部软件有:
Alibaba Dragonwell
: Ali-JDK 的开源版本,6月下旬刚刚发布 GA 版本,咱们及时跟进集成并完成了软件测试后,输出到 Alibaba Cloud Linux 2;PouchContainer
: 阿里巴巴开发的高效容器引擎;Dragonfly client
: 开源的基于P2P镜像及文件分发系统;Tengine
: 在 Nginx 的基础上,针对大访问量网站的需求,添加了不少高级功能和特性的 Web 服务器项目;aliyun-cli
: 开源的用于管理阿里云资源的工具;ossfs
: 用于将阿里云 OSS buckets 挂载到本地的工具;eBCC
: 社区版 BCC 的功能扩展。用户能够在操做系统内经过 yum install
命令直接安装对应的软件包。
Alibaba Cloud Linux 2 是一个创建在社区协做基础上的开源操做系统发行版项目,同时也很是重视回馈社区。
Cloud Kernel 是 Alibaba Cloud Linux 2 最重要的开源内核,也是在 GitHub 上的开源项目。如前所述,咱们保持三周到四周的迭代周期,在每一个迭代都保持对外推送最新开发补丁。在迭代开发过程当中,咱们屡次测得 4.19 版本 的 LTS 内核的 BUG,并及时向社区报告,或者经过定位将主线内核的修复移植回 LTS 内核,或者主动向社区提交补丁。
对于测试中发现的 LTS 内核 BUG,咱们首先会根据已划分的内核领域进行初步判断,若是难以直接定位,则会进行 bisect 寻找最有可能出现问题的代码。通过初步的分析以后,根据问题的难易程度,咱们会选择直接向社区提交修复补丁或者进行讨论。
有一种常见的状况是,某个内核 BUG 在主线内核中已经修复,可是因为种种缘由,该修复没有出如今 4.19 LTS 内核中,这种状况下,咱们会选择先将主线内核修复的代码 cherry-pick 到 Cloud Kernel 的开发分支中,而且向 4.19 LTS 内核的维护者、以及对应内核子系统的维护者发送一封 backport 请求的邮件,提示维护者及时将该修复移植回来。
截止6月30日,团队在开发 Cloud Kernel 过程当中,向内核社区提交并被接收的内核补丁有 19 个。此外,咱们还积极向知名的社区测试套件 LTP, xfstests 等项目贡献了多个修复补丁以及新测试用例。
除此以外,Cloud Kernel 还与 Intel 0-day 项目等开源项目达成合做,0-day 项目团队主动向 Cloud Kernel 推送了多个修复建议及补丁,均已被接受合入开发分支。
因为 Aliyun Linux 2 的内核须要运行在通用的 ECS 系统上,或者用户自定义的基于 QEMU/KVM 的虚拟机中,保持内核功能的通用性一直是咱们在增长 Cloud Kernel 功能时的原则。在开发自研内核功能时,咱们会对功能进行充分的评估,若是该功能的实现方式过于 Hack,或者引入该功能会形成内核维护成本急剧上升,咱们会从架构的完整性考虑而酌情放弃该功能的开发。下面是两个近期自研的内核功能的例子:
在4月份 GA 版本发布中,咱们提到了基于 cgroup-v2 的 cgroup writeback 功能是 LTS 4.19 内核的一项重要更新;发布后,咱们收到多个客户反馈,亟需此功能在 cgroup-v1 上的实现。在深刻分析以后,咱们意识到,cgroup writeback 功能天生适合 cgroup-v2 的平坦结构,却也不是不可能在 cgroup-v1 上实现。关键点在于在使用 cgroup-v1 时,须要人为保证对应的 blkcg 和 memcg 两个 cgroup 保持合理对应的映射关系。在梳理清楚 cgroup 映射关系限制条件后,咱们完成了 cgroup writeback v1 在 Cloud Kernel 上的实现,并在 GitHub 上发布[3] 对应的更新;同时为了保证用户对于使用时的映射关系约束有足够的了解,咱们在内核中默认将此功能保持关闭,并制做了相关文档[4]说明。
这个功能容许用户动态调整 TCP 链接的 TIME-WAIT 状态超时时间,容许其被设置为小于默认的 60s 值,从而在大量短链接应用中,提升应用性能。这个功能其实是早期版本的 Taobao Kernel 已经实现并对外提供的功能,在决定是否要将此功能在 Aliyun Linux 2 上从新移植一遍时,咱们从新评估了该功能的风险。在翻阅了 RFC 793 标准中 “The TCP Quiet Time Concept” 相关的概念后,咱们认为该功能不符合 TCP "Quiet Time" 的概念,在不知晓该风险的状况下使用可能会形成系统不稳定;可是因为该功能确实被客户须要,且功能结构、代码实现较为独立,维护成本和风险可控。因此咱们在内部实现时,显性备注了接口使用风险后,将功能在 GitHub 上发布[5]。
Alibaba Cloud Linux 2 使用了大量社区的功能,核心组件 Cloud Kernel 没有使用 Red Hat 内核版本,而是使用了基于内核社区 4.19 LTS 版本。众所周知,社区版的内核的稳定性一直为人所诟病,咱们在采用此版本内核时,也有同样的担忧。所以在研发过程当中,咱们对 Cloud Kernel 进行了积极的测试。
首先,得益于阿里巴巴操做系统团队中有多个内核子系统维护者、内核测试套件的维护者或前维护者,咱们对于开源社区主流的测试套件对内核子系统的覆盖率及测试细节掌握较为全面。经过这些开源测试套件,咱们发现了很多社区版内核的问题,并为社区贡献了多个补丁。
其次,在研发过程当中,咱们遵循“本身吃本身的狗粮”的原则,要求研发同窗自行完成单元测试用例开发,而且集成到内部测试平台中进行回归测试。在测试平台的选择上,基于研发开发测试代码的便利性原则,咱们选择了成熟的测试框架 Beaker[6],这是一个源自 Red Hat 的社区开源测试框架项目,能够很方便地集成测试代码,而且输出直观的测试结果。咱们将本身开发完成的测试代码放到 Beaker 测试平台上,进行自动化的每晚构建回归测试(Nightly Regression Testing)。在每一个迭代中,咱们也发现了很多内核回归缺陷,都及时向社区提交了补丁或者参与了修复讨论,为稳定 4.19 LTS 内核作出了本身的贡献。
此外,在阿里巴巴操做系统团队内部有专业的质量保证团队。质量保证团队的测试平台集成了 40多个测试套件,覆盖了功能性测试、性能测试、冒烟及稳定性测试等各方面。在 Alibaba Cloud Linux 2 迭代周期进入交付测试阶段,会由质量保证团队负责相关测试,测试结果通过 Review 经过后,则可进行迭代发布。
操做系统最近几个月成为了热门的话题,此时推出这样一篇介绍 Alibaba Cloud Linux 2 发行版的技术文章还显得比较应景。做为一个技术人,在平常的工做中,坚持技术的锤炼,乐于思考与分享,对操做系统和内核领域不断钻研,才能立足于瞬息万变的技术之潮中,而且游刃有余。
Alibaba Cloud Linux 2 由阿里巴巴操做系统团队负责开发,诚招有志之士参与,共同在云上操做系统领域探索更多的可能。简历可发至 caspar@linux.alibaba.com
本文为云栖社区原创内容,未经容许不得转载。