怎样借助openEuler 2003 LTS版本构建企业级效劳器操纵体系

为使社区参与者快速使用及开发出自己的操作系统,此次分享将为您详解openEuler LTS 20.03版本的关键技术。

1、社区主线欢迎任何新特性,有趣的idea,实验性质的功能,对于这些特性,可以随着社区主线进行演进和孵化,只需要遵守社区技术委员会制订的流程就可以了。

2、把社区主干上的软件集合成可以下载,安装使用的发行版是社区发行版的作用,社区Release是提供给个人开发者,爱好者等使用,鼓励新技术的使用和集成。

3、而LTS版本的软件选择和集成是要经过严格流程的,通过更为详细的测试和质量加固,使其成为一个可以被商用合作伙伴真正做商用发布的Release。

因此,如果在openEuler有更好的idea欢迎放在社区主线上,如果是相对成熟的功能和特性,可以集成到社区Release中,对于LTS则需要非常谨慎,任何往LTS版本中核入的特性必须是成熟稳定并且可商用的即社区主线、社区版本以及LTS版本之间的关系。

openEuler社区版上发现的任何问题,如果影响主线和LTS版本,也需要回合到主线和LTS版本上。

如果在openEuler的LTS版本上发现了相应的问题,也需要回合到主线上,或者回合到还在维护周期内的社区版本。

一些商用企业选择长维护周期,长周期对于企业客户来讲相对比较有利,有利于业务的维护。但是如果维护周期过长,由于整个生态系统中软件的变化非常快,这将导致特性回合变得非常困难,反而会在一定程度上影响系统的质量和稳定性。

比较短的维护周期可以减少维护工作量,有利于版本快速演进,新特性的加入,但是会导致软件基线变化比较大,不利于硬件兼容性和软件兼容性的稳定。

经过综合的考虑,openEuler的社区release的维护周期定为半年,LTS版本的维护周期为四年,LTS版本的四年维护周期兼顾了版本的稳定性和社区快速演进这两个因素。为商用客户,OSV或基于openEuler发布商用的厂商提供稳定的版本基线。LTS版本维护周期内可以享受到漏洞的补丁、漏洞的回合等特性。

对于LTS版本,允许将openEuler或者上游社区的一些特性回合到LTS版本,但是回合有一个原则,回合的功能不能破坏API和ABI。该原则是保证对于企业客户的接口稳定性,保持南向和北向的生态兼容性。

LTS的关键特征就是要维护南向和北向的兼容性生态,因此保持稳定的API和ABI是LTS版本的重要特征。

构建openEuler社区目的是为了帮助第三方厂商更容易的构建商业操作系统和生态系统,OSV厂商可以基于openEuler的LTS做商业OS发行版。OSV也可以选择基于社区版本来构建,甚至在主线上拉出自己的分支构建也可以。但基于LTS版本会帮助OSV节省很多的工作量,我们希望能够和OSV共同构建openEuler LTS,将LTS版本做成行业内稳固的底座。

OSV可以基于LTS添加自己的独特特性,构建差异化竞争力。这些差异化的竞争力可以存在于厂商自己的发行版本中。

openEuler社区并不要求将OSV的发行版中的差异化竞争力回合到社区,但我们鼓励OSV把好的特性贡献到LTS社区,让LTS版本更稳定、具备更强大的能力。这是openEuler社区对于OSV和第三方厂商的倡议。

在社区主线上中会有社区的版本,在某一个社区版本之上会构建LTS版本,对于任何BUG和CVE漏洞坚持主线,版本之间双向回合,特性可以在主线上开发,演进,待特性成熟以后落实到下一个版本周期中。

openEuler计划支持多种体系架构,这次发布的LTS版本支持两种体系架构,X86和ARM。对于体系架构来讲,openEuler社区是非常开放的,我们欢迎任何ISA、任何的体系架构加入到社区中。可以透漏的一点是,很快会有一个全新的体系架构加入到openEuler的大家庭中。

第三层是虚拟化层,这层对整个企业市场来讲非常重要,特别是云场景来讲非常重要,也就是通常说的IaaS底座。

由下至上,从芯片到内核到虚拟化到技术化到容器构成全四层的技术全栈,openEuler会关注性能、可靠性和安全这三个方面。同时会重点对这三个方面进行优化和加强,这是整体的LTS版本的特点。

华为公司过去十几年做了大量的开源工作,对于内核、虚拟化、容器、ARM生态等方面做了非常多的贡献,例如内核每年的patch贡献量超过3000,在全球排进了前五名。因此,对于openEuler, 我们的原则非常简单,那就是Upstream First。例如在内核中做一个特性,最终如何能合入到openEuler的版本中呢?

尽可能的先提交到上游内核社区中,被kernel社区所接纳,openEuler社区从内核社区pull到openEuler中,这样,相关的特性就能融入到到下一个发布版本中。因此任何特性开发建议先到最原始社区中,通过原始社区进入到openEuler社区。

有一些特性可能未必在短期内被社区接受,或者接纳很慢。对于这些特性,openEuler社区中会持开放态度做一些接纳,在openEuler作为特性提供给大家试用,也许这种特性在openEuler社区广泛使用后能加速被上游社区所接纳。

以上就是openEuler社区的基本开源策略。期望在国内形成这样一个氛围,鼓励参与社区,不只是openEuler,同时参与到openEuler的上游社区,共建社区繁荣。

安全方面的工作,比如ARM64下的hot patch是华为第一个在RAM生态中使能的。对于提升系统的可维护性、增强安全有非常大的作用,还有一些RAS的特性。

性能方面,无论是配套芯片还是应用程序,性能永远是追求的极致,内核在Spinlock、I/O、TLBI、ktask等都做了非常多的工作。

一个性能方面的例子:LTS版本中使能了Numa aware qspinlock,对一些case的性能提升可以达到50%以上,且随着核数的增加效果会越来越明显。

虚拟化是云的基础底座,openEuler希望能够成为最好的云的底座之一,特别是帮助鲲鹏成为优秀的虚拟化平台,虚拟化有三大基本件:KVM、Qemu、Libvirt,目前这三大件版本选择是KVM选择4.09,Qemu是4.0.1,Libvirt是5.5.0,openEuler在这三大件上除了质量增强、安全增强,也做了规格上增强,如:在鲲鹏芯片上KVM配合Qemu可以提供超大规格的虚拟机。

总体来讲,通过虚拟化团队的工作,现在鲲鹏芯片、鲲鹏服务器所拥有的虚拟化的能力完全不逊于其他任何的体系架构,以目前鲲鹏加上openEuler以及其他的软件可以构建完整的云基础平台。

容器是Cloud Native场景下最重要的基础部件,openEuler支持诸如docker这样的主流容器引擎。但是工程师总是喜欢重新发明轮子,我们又造了一个新轮子。

灵:iSula架构设计具备扩展性,可扩展容器网络、容器存储等,模块化的插件式设计,轻松完成定制化开发。

为什么要造一个新的“轮子”,因为我们相信容器将会run everywhere,新的iSula容器引擎目标是容器可适用于任何场景,期望打造一个从设备,到边缘计算节点,最终包含数据中心中有一个归一化的容器引擎方案。

当然,为什么再造一个“轮子”,从工程师的角度来说其实很简单,那就是:We Love To Do So,只有在不断迭代中才能使得相关的产业更进一步的快速发展。

当一个业务跑在复杂的OS之上,面临成千上万的参数,过往通过人的经验进行选择调整,既无法覆盖较大范围,也没有办法获得最优的效果,所以通过AI的引入,可以在众多参数中选择敏感参数集,通过AI训练可以找到对于特定应用的最佳参数组合,使得具体业务能够运行的更加高效,这是对于A-Tune来讲的第一个应用场景。

与之对。

未经允许不得转载:主机宝贝 » 怎样借助openEuler 2003 LTS版本构建企业级效劳器操纵体系

评论 抢沙发

评论前必须登录!