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

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

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

(网络自动化演进的挑战)

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

自贝尔于 1876 年 2 月 14 日在美国专利局申请电话专利权,这一百多年来电信基础设施网络飞速发展。时至今日连接超过 50 亿移动用户的电信行业已彻底改变了世界。它让我们彼此相连,带给我们娱乐、传递给我们新闻,给予我们灵感。长期以来,电信运营商都是引领社会数字化的弄潮儿,是自动化的引领者。近年以来,互联网服务商,尤其是公有云巨头们凭借强大的软件能力,实现了高度自动化的基础设施运维模式,大大提升了劳动生产率。相对而言,运营商们的网络运维和运营模式却变化不大,自动化水平不高,效率提升不明显,在同 OTT 争夺未来 ICT 基础设施服务市场的竞争中处于不利地位。主要原因为:

(1)受组织架构和技术水平等的限制,如今的电信网络仍然主要靠人工来管理,自动化程度不高。

大量工作需要人来手动完成,导致业务发放时间长,业务无法及时上市;运行过程中故障平均恢复时长让用户无法忍受。这些都影响了网络敏捷和终端用户体验。

一方面,运营商在部署新业务时,往往需要数月甚至更长的时间,这严重影响了电信业务的创新效率;另一方面,在网络运维中心,工程师们不仅每天监控着成千上万的告警,还要创建故障单来跟踪问题的解决过程。运维工程师必须经过专业培训才能使用软件系统执行日常任务。他们未必清楚如何增强软件以适应不断变化的需求,还可能受限于不支持定制功能的软件。由于手动操作的单调性和重复性,常年累月,运维人员会失去动力,枯燥的工作会导致严重的运维人员流失。

依赖重复的手工流程体现在:操作人员要么把相应的步骤写入手册,要么将其形成个人知识库。但即便手册说明足够详细,操作人员经验足够丰富,依赖手工流程也容易出错。不精准的分析和不正确的配置所带来的风险极高,甚至可能会带来服务中断、收入损失和客户流失等问题。

(2)烟囱式的运维模式使得网络无法全生命周期统一管理,网络运维不可视,故障无法实时感知。

运营商目前使用的大多数运维支撑软件(OSS)都是基于封闭的软件架构设计的。这些架构基于不同领域部署,从而形成一个个运维孤岛,使得软件变更周期不可控,新业务的上市时间长,网络跨域故障无法快速修复。可以毫不夸张地说:“我们使用的是 21 世纪的 4G 网络、光纤网络,甚至 5G 商用已经此起彼伏,但网络自动化程度在某种意义上还停留在 20 世纪。我们很多的运维工具和手段让人感觉身处石器时代。”

运维组织的层级化、地域化严重阻碍了网络自动化程度。例如,通常有三个层级的客户服务和网络运维,这也是烟囱式软件和流程式烟囱的一个表现,并且在级与级之间存在大量的手动切换。典型的运维模式是按照国家、省、地市等行政地域来进行的,网络虽然全程全网打通,信令可达,但是运维指令是被局限在这些行政区域之内的,严重依赖人为协调、沟通、审批等工单流程,实际上是无法自动化完成一条跨省电路实施的。除去基本的语音业务以外,其他业务在不同区域的业务体验、运维体验也都是不连续的,最终导致用户在不同地域会明显感觉到差异。

(3)网络扩容的计划模式难以适应业务的变化,难以实时响应业务诉求。

随着业务种类、数量的快速变化,对网络本身的弹性也提出了更高的要求。资源的自动扩缩可以有效节省成本,比如在业务的低谷期可以将资源降下来,在业务高峰期可以自动扩容。每年的春晚以及其他一些大型活动期间,在短时间内会召回大量平时不活跃的用户,给网络带来数倍于日常的流量。可以说网络的重大事件服务保障堪比一场重大战役,需要调动各种资源并准备各种预案以应对。

另外,突发业务诉求和流量变更也往往需要运营商网络随之快速适配。但现实中,大部分业务仍然无法实现按需调整。业务能否按需调整直接关系到已有客户的黏性和新客户的拓展。总体来说,目前这样的弹性调配在运营商网络中还很难完全自动化实现。

(4)运营支持系统复杂且支离破碎,缺乏统一平台和框架,导致网络转型难以成功。

面对越来越复杂的业务,面对越来越多样化的用户需求,从初期机房中的几十台设备发展到如今庞大的数据中心,单靠人工已经无法满足技术、业务、管理等方面的要求。自动化、架构优化、过程优化等降低运维成本的因素越来越被人们所重视。

从 2000 年开始,运营商已开启网络转型之路。然而,转型并不容易。由于种种原因,超过 80% 的转型最终无法完全实现既定目标。全球一大批运营商接连开展了一波又一波的转型实践,但是目前为止,还没有走出一条清晰且公认成功的转型之路。

从运维管理支撑系统角度来看,无论是早期的 ITU-T 的 TMN 的五层模型,还是后来 TMF(电信管理论坛)的 NGOSS 的 eTOM 模型,以及再后来演化的 ZOOM 模型等,带给产业界的依然是各种烟囱林立的、割裂的、定制化的信息孤岛,而且年复一年积累下来,每个大型电信运营商无不积累了数百套甚至上千套这样的系统,它们每个都有具体的用途,但没有一个人能把全部系统的关系说清楚,更谈不上自动化打通各系统间的数据流和业务流。这也是转型不容易的原因之一。

面对电信产业的众多挑战,要提高成本效益和质量,运营商需要探索创新的自动化模式。电信运营商参考其他行业的优秀自动化实践,包括 OTT 厂商、云服务提供商、标准产业组织和开源产业组织,希望从其他行业汲取经验,以便建立更加敏捷的网络自动化模式。在自动化的基础上,还可以引入 AI,增加更多网络智能化及网络自动驾驶的能力。

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

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

评论

发布