ONAP 技术详解与应用实践 (41):ONAP 架构设计 3.1.4

阅读数:1 2020 年 1 月 5 日 18:02

ONAP技术详解与应用实践(41):ONAP架构设计 3.1.4

(DevOps 一体化设计)

内容简介
这是一本系统剖析 ONAP 的书籍,也是理论性与实战性兼具的网络自动化实践指导书!
本书详细全面地介绍了网络自动化的挑战和发展趋势,以及 ONAP 的概况、架构设计理念、设计原则、各模块实现细节、关键特性、应用场景和案例实践等。通过本书读者可以深入理解 ONAP,提升对网络自动化及相关领域的认知。
作者及其团队成员均是是华为网络开源领域的专家,长期参与社区的治理、贡献和回馈,致力于通过产业协作,打造统一的平台,降低集成成本,加快新技术导入,助力新一代网络运维系统升级。从另一个侧面说,本书是华为在网络开源领域的深刻洞察和见解,书中分享了华为参与网络开源的实践经验,是电信网络转型的重要参考。
本书共分为四大部分:
准备篇(第 1~2 章) 帮助读者梳理网络自动化的挑战和历史,分享了业界先进理念和经验,详细介绍了 ONAP 平台的版本能力以及与标准和开源组织的协同;详细描述了在三种环境(物理服务器、私有云环境、公有云环境)下安装部署 ONAP 的方法。
架构设计篇(第 3 章)系统介绍了 ONAP 在设计之初的目标与设计理念,从全局角度帮助读者了解 ONAP 当前架构是如何形成的,各个模块是如何划分的,最终又是如何保证系统质量的,在这个过程中开发人员分别有哪些考虑。具体包括模型驱动、DevOps、微服务化与云原生等,同时对 ONAP 数量众多的组件,从架构角度进行了归类和介绍。
关键项目篇(第 4~7 章),关键项目篇从架构角度将 ONAP 分为 ONAP 设计态组件、运行态组件、闭环组件和公共组件四部分,每个部分又包含若干项目。本书详细介绍了每个项目的功能描述、API 接口关系、关键特性、未来规划特性及开发指南等。这部分可帮助读者深入理解 ONAP 核心。
应用场景和案例实践篇(第 8~10 章),首先介绍了 ONAP 社区到 R3 版本为止的五个场景蓝图,以及基于 ONAP 来解决网络自动化和业务闭环的问题方法;然后以 CCVPN Usecase 为例,介绍 ONAP 支持一个新业务场景的设计思路、建模方法、工作流设计、闭环设计等;最后系统介绍了社区的测试认证项目 OVP、包括其发展路标、认证服务模式及未来构想。

在软件开发生命周期中,遇到了两次瓶颈。第一次瓶颈是在需求阶段和开发阶段之间,针对不断变化的需求,对软件开发者提出了高要求,后来出现了敏捷方法论,强调适应需求、快速迭代、持续交付。第二个瓶颈是在开发阶段和构建部署阶段之间,大量完成的开发任务可能阻塞在部署阶段,影响交付,于是有了 DevOps(Development 和 Operation 的组合词)研发运营一体化。DevOps 是一组文化、流程与工具整合后的统称,基于敏捷与精益的理念,从业务和整个价值链角度,推动组织优化软件交付方式,从敏捷开发,走向敏捷运维和敏捷业务。

DevOps 是一种重视“软件开发人员(Dev)”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使构建、测试、发布软件能够更加快捷、频繁和可靠。DevOps 提倡打破孤岛,促进开发和运维之间高度协同,在实现小批量迭代交付、增量式发布、高频率部署、快速闭环反馈的同时,提高生产环境中软件部署及运行的可靠性、稳定性、可伸缩性和安全性。

DevOps 的三大原则:

  1. 基础设施即代码(Infrastructure as Code)

DevOps 的基础是将重复的事情使用自动化脚本或软件来实现,例如 Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等。

  1. 持续交付(Continuous Delivery,CD)

持续交付是在生产环境中发布可靠的软件并交付给用户使用。持续部署则不一定交付给用户使用,其涉及两个时间—TTR(Time to Repair,修复时间)和 TTM(Time To Market,产品上线时间)。要做到高效交付可靠的软件,需要尽可能减少这两个时间。部署可以有多种方式,比如 Blue/Green Deployment(蓝绿部署)、Rolling update(滚动部署)、金丝雀部署等。

  • 蓝绿部署:意指有两套系统,一套是正在提供的服务系统,标记为“绿色”;另一套是准备发布的系统,标记为“蓝色”。两套系统都是功能完善且正在运行的系统,在独立集群环境中运行,一次只有一个系统对外提供服务,另一系统用于发布前的验证、修改等(不干扰用户)。升级过程中不停止老版本,在新环境中部署新版本,然后进行测试,确认没问题后,将流量切到新版本,然后再把老版本升级到新版本。优点是可减少发布时的中断时间,能够快速撤回发布(切换环境即可)。
  • 滚动部署:一般是取出一个或者多个服务器对其停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本。它相对于蓝绿部署,更加节约资源—不需要运行两个集群、两倍的实例数。可以部分部署,例如每次只取出集群的 10% 进行升级。
  • 金丝雀部署:又称灰度发布,这和蓝绿部署有点像,但可以进一步规避风险。强调阶段性升级或切换,而不用一次性从蓝色版本切换到绿色版本。即:在生产环境的基础设施中小范围地部署新的应用代码。一旦应用签署发布,只有少数用户会路由到它,此时多数用户业务流量仍流向老版本。在此过程中观察影响,如果没有错误发生,新版本可以逐渐推广到整个基础设施。当前这种部署方式被云服务提供商,比如网游公司广泛采用,以验证用户对新特性的接受情况。当然这种方式主要挑战在于如何设计一种方法以便路由部分用户到新应用。发布示意如图 3-3 所示。

ONAP技术详解与应用实践(41):ONAP架构设计 3.1.4

图 3-3 金丝雀部署 / 灰度发布示意

注释:矿井中的金丝雀
17 世纪,英国矿井工人发现,金丝雀对瓦斯气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;而当瓦斯含量超过一定限度时,人类毫无察觉但金丝雀可能已毒发身亡。因此当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”,以便在危险状况下紧急撤离。

  1. 协同工作(Culture of Collaboration)

开发者和运维人员必须定期进行密切合作。开发应该把运维人员理解成软件的另一个用户群体。协作有如下几个建议:

  • 自动化(减少不必要的协作);
  • 小范围(每次修改内容不宜过多,减少发布的风险);
  • 统一信息集散地(如 Wiki,让双方能够共享信息);
  • 标准化协作工具(比如 Jenkins)。

ONAP 构造了完整的 CI/CD 环境,包括:所有项目都采用 Docker 容器发布,并统一采用 OOM 实现部署管理(短期还同时支持 Heat 部署方式),采用 JIRA 跟踪所有问题,采用 Jenkins 实现持续部署管理。

ONAP技术详解与应用实践(41):ONAP架构设计 3.1.4

购书地址 https://item.jd.com/12536723.html?dist=jd

评论

发布