ONAP 技术详解与应用实践 (5):网络自动化挑战及 ONAP 介绍 1.2.2

阅读数:1 2020 年 1 月 1 日 17:46

ONAP技术详解与应用实践(5):网络自动化挑战及ONAP介绍 1.2.2

(互联网企业的网络自动化实践)

内容简介
这是一本系统剖析 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、包括其发展路标、认证服务模式及未来构想。

大型互联网企业建设和维护着一张覆盖全球、连接大量数据中心的网络。他们一般开发自己的自动化平台来运维网络,以降低故障、提升效率。

Google 的 DevOps 理念的核心是用软件来自动化重复的工作,从而使运维者的精力可以主要用来开发软件。Facebook 和 Alibaba 的自动化工具比较类似,都是采用模型驱动的方式来自动化网络配置。

互联网企业的理念和技术思路对电信产业有借鉴意义,故这里进行简单介绍。

  1. Google 的 DevOps 运维实践

Google 的产品和服务是全球部署的,通常没有时间和人力像其他组织一样手动维护系统,因此 Google 更倾向于在其系统中实现自动化。Google 的运维团队把大部分时间用于开发自动化平台。

Google 认为自动化的价值在于一致性、平台性和自愈性。

  • 一致性:体现在自动化系统可以无数遍地、一致性地执行范围明确且步骤已知的程序。而任何个人或者群体在执行数百次重复动作过程中,不可能保证每次都以相同的方式进行,因为没有人能像机器一样永远保持一致。不一致性会导致错误和疏漏,以及其他可靠性问题。这在电信行业尤为重要。
  • 平台性:是指自动化的系统可以提供一个可以扩展的、广泛适用的平台。一个平台可以将错误集中化,修改一个错误就意味着该错误被永远修复。一个平台更容易被扩展,从而执行额外的任务,这显然比给人赋能并让人去执行更容易。此外,平台通过越来越多的可视化手段,可以暴露自身的各项指标,帮助人们发现流程中的细节,并在过程中衡量这些细节和指标。
  • 自愈性:采用自动化系统解决常见故障,由于平台对问题和故障可以自动感知,故平台可以基于已有经验或者预置策略实现常见故障自动化修复。这样可以明显降低常见故障的平均修复时间(MTTR)。在 Google 的基础设施中,自动化系统应用广泛,能够快速响应对服务的变化和支持。
  1. Facebook 的自动化平台 Robotron

Robotron 主要是在业务发放方面,将运维人员的运维意图自动翻译成异构的设备配置。除了配置之外,Robotron 还承担管控的角色,即需要实时掌控网络的配置部署情况,防止网络的部署与规划产生偏差。如图 1-2 所示,Robotron 的功能覆盖于整个网络的管理周期:网络设计→配置生成→部署→监控。

ONAP技术详解与应用实践(5):网络自动化挑战及ONAP介绍 1.2.2

图 1-2 Robotron 架构说明

Robotron 信息完全依赖于 FBNet 抽象层,FBNet 将对整个网络,包括网络物理或逻辑组件,进行面向对象的建模,比如设备、端口、链路、IP 地址等。基于这个网络抽象模型对象,运维人员可进行网络设计(Network Design)、配置生成(Config Generation)、部署(Deployment)和监控(Monitoring)。

  • 网络设计:主要是确定各种网络资源对象的拓扑和关联关系,设计的输出是对目标网络的抽象。
  • 配置生成:基于网络设计的输出,配置生成模块可以根据设备的厂商和型号信息,自动生成设备的配置脚本。这个模块要针对不同的设备类型来开发对应的配置生成模块。
  • 部署:部署是配置下发的工作流,为了消除配置下发的风险,需要完成设备初始状况的比较确认、配置任务的原子化(同一个时间段只有一个操作)、配置的校验、配置的回滚等工作。
  • 监控:监控是通过收集设备的实时配置,生成网络的实际状态,以确认网络配置被正确下发,确认网络运行状态与抽象层相符合。

从 Robotron 平台我们可以学习到抽象建模和 Top-Down 的思路,用抽象模型来表述目标配置,用 Top-down 的方式来生成具体的配置。

  1. 阿里 NetCraft 网络配置自动化实践

阿里开发的 NetCraft 主要是为了解决网络变更的配置问题,以降低人工操作引起的故障。NetCraft 也用模型的方式来描述网络的配置。阿里认为网络模型要满足四个要素:

  • 可解释性:网络模型的可描述性,即要深入到网络的方方面面,包括连通性、协议层,只有信息足够全,才是高质量的模型。
  • 互操作性:网络模型要能方便地转换为网络配置,反之亦然。这个是基于意图网络模型的技术底座。
  • 灵活性:操作粒度要原子化,并支持下发、回滚等操作,只有将业务意图解构为足够细的原子化操作,才能保证自动化工作的平滑切换。
  • 独立性:网络模型要能屏蔽多厂商之间的差异。

NetCraft 网络模型的关键设计就是其多图层机制。NetCraft 的设计思路是将网络自下而上划分为多个图层:最底层是物理层,包含网络设备的物理链接关系,可以包含设备名称、LLDP、ETH-Trunk 信息;物理层之上是 IP 层,包含接口的 IP 地址信息;再之上是各种协议图层,如 BGP、OSPF、ISIS、MPLS。NetCraft 会为所有的路由协议单独构建一个图层。不同图层之间的关联是通过设备接口、设备自身等图层间共享的实体实现的,BGP 和 OSPF 图层之间通过 IP 图层的三层 IP 接口相关联的。

在属性定义方面,NetCraft 和 Robotron 一样,所有的属性都是依存于网络图层中的各种实体。NetCraft 的这种多层图机制易于理解,能达成良好的可解释性。

NetCraft 的架构如图 1-3 所示。

ONAP技术详解与应用实践(5):网络自动化挑战及ONAP介绍 1.2.2

图 1-3 NetCraft 架构设计

网络操作者的主要工作是设计目标网络模型(Target Network Model),配置生成器(Configuration Generator)负责解析目标网络模型,并结合预定义的配置模板,将目标网络模型转换为对应的设备配置命令。迁移规划器(Transition Planner)根据目标模型要修改的配置,计算上述多个图层之间的配置依存关系,通过精心设计的业务编排来达成业务的平滑部署。配置下发(Configuration Executer)结合目标配置和切换规划,进行具体配置的逐步下发,每下发一步都会检测网络状态,如果异常则回滚。模型生成器(Model Generator)将配置逆向解析回运行网络模型(Running Network Model),用于网络诊断工作。

可以看到,NetCraft 同 Robotron 的整体架构和思路是非常类似的,都是 Top-down 的思路。NetCraft 的多层网络建模和关联关系建模也值得借鉴。

ONAP技术详解与应用实践(5):网络自动化挑战及ONAP介绍 1.2.2

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

评论

发布