TM Forum ODA - 打开云原生IT与网络架构的钥匙

2022-07-28 951
电信行业引领了信息化时代,是数字化时代的排头兵,电信IT从业务支撑者变成了业务使能者,成为运营商全面赋能数字化社会的工具。近年来,NFV在核心网规模应用,通过统一的操作原语实现了5G切片等创新场景,给无线领域带来了新的变革,电信软件如何适应数字化趋势,构建一个开放、符合云原生要求、支持零操作运维的软件架构? 


TM Forum ODA提供了答案,下面我们来介绍一下。

1


整体架构

 
面向数智驱动、泛在连接和虚实相生的新通信时代,电信IT面临着许多挑战:如何引导生态发展,并充分利用生态中的供应商、集成商和咨询公司来实现敏捷业务能力?如何简化IT架构,提高自动化运维水平,降低系统集成成本和运维成本?

TM Forum作为一个全球产业组织,迄今成立时间超过34年,在全球拥有超过800家的会员,通过行业经验、最佳实践和行业标准来推动电信行业的领先发展。针对电信行业的这些挑战,TM Forum推出了ODA(Open Digital Architecture)开放数字框架,从工具、代码、知识、标准等来构建一个面向未来的IT蓝图,ODA主要包含五个部分:

//业务架构 (Business Architecture)
包含支持高效、敏捷运营的关键业务流程多层模型(eTOM),实现业务能力映射和价值流映射。

//系统架构(Information System Architecture)
包含支持松耦合的功能架构和数据架构(SID),能够在运营商、供应商及其他合作伙伴之间提供标准的信息定义。

//实施架构 (Implementation Architecture)
包含50多个REST-based的Open API,可以实现IT系统标准化的互操作性;支持重用和简单集成的ODA组件,同时标准化的数据模型亦可帮助实现AI运维。

//部署和运行时环境 (Deployment & Runtime Environment)
通过Canvas来支持即插即用的ODA组件的运行,提供标准技术框架和DevOps支持,并且经由实验室测试环境持续部署验证。

//治理(E2E Governance)
提供相关的原则、设计指南、元数据,以及覆盖架构全生命周期的敏捷管理工具。

通过这五个部分的相互配合,运营商可以像搭积木一样搭建符合云原生要求,支持自动化运维的数字化IT系统其中ODA Component是这整个框架的核心。整个架构示意图如下:

图片关键词

2


ODA部署实施


ODA部署实施架构主要由两个关键元素组成:Canvas和ODA组件,其关系如图所示:

图片关键词

Canvas提供了一个ODA组件运行环境,对外可以与CI/CD平台对接,支持DevOps发布流程,比如:自动化的组件部署和更新,并为应用提供了一个标准化的、支持云原生的运行环境,支持容器化、微服务应用的编排部署,并提供各种非功能性服务,比如服务注册、API治理、监控/日志等可观测性服务以及统一安全认证、事件总线等。Canvas是基于各种云原生组件构建,为云原生应用而设计,比如编排引擎使用Kubernetes,事件格式采用CloudEvent协议等,不过这些组件都是可按需替换的。Canvas的整体示意图如下:

图片关键词

ODA组件是经过标准化的应用,像乐高积木一样拥有标准的对接和管理接口,支持通过Open API相互连接,实现零配置(ZeroTouch),可拔插方式在Canvas中运行。ODA提供了一种标准的六边形元数据描述格式,将应用的数据模型标准化为五类属性,包含核心功能(暴露的API接口和依赖的API接口)、事件通知、安全接口、环境要求、运维管理,为自动化的对接和管理提供了标准化的信息。ODA组件的示意如下:

图片关键词

另外,TM Forum还提供了ODA组件地图,对电信领域中的组件进行了标准化的划分,用于替代TAM。约定了标准化的部件和对接的Open API,实现系统解耦,方便供应商的产品开发和运营商的采购,各生态参与方可以对功能范围快速取得一致理解,并降低对接成本。

图片关键词
图片关键词

3


ODA Zero-Touch流程介绍


下面我们以某运营商需要上线一个CPC组件为例来讲解一下ODA下的整个部署流程。假设运营商已经拥有了一个ODA Canvas平台。



第一步,运营商可以到ODA的组件市场查询并选择某个供应商的组件,在经过商务等环节之后,获得了相应的ODA组件软件包(Helm Charts)。


第二步,通过Kubernetes的Helm工具来部署这个软件包。Kubernetes会创建出对应的应用,启动相关容器,同时还会创建一个对应于此ODA组件的Kubernetes CRD自定义资源对象,比如本次安装创建了一个CPC Component的ODA CRD对象。


第三步,Canvas通过Kubernetes Operator扩展持续监听ODA CRD对象的创建,当发现新增了一个CPC CRD对象之后,自动获取到资源对象中的ODA组件的元数据信息,并根据这些信息自动触发对应的开通动作,比如为CPC创建若干个API的CRD对象,描述CPC所提供的Open API。


第四步,Canvas对API CRD对象也设置了监听,当发现系统有新增API之后,API Operator会采集API的详细信息,比如内部访问地址、安全认证协议等,并将这些API发送给API网关,由API网关进行API的注册和对外开通,并将API网关反馈的外网访问地址更新到API CRD对象中,这样即实现了组件的自动化开通。


不仅仅是API网关的开通,其他的比如安全中心的策略/证书自动下发等都可以利用这个机制来实现。ODA架构充分利用Kubernetes平台的扩展机制,基于事件并根据ODA组件的数据模型实现Zero-Touch零配置的运维能力。上述流程示意图如下:

图片关键词

4


ODA技术亮点


将软件模块化,像积木一样来组装系统的想法并不新鲜,TM Forum ODA架构与TAM、NFV等规范等相比,有许多不同和亮点:


ODA与TAM相比,不仅实现了组件在功能层面的模块标准化,还覆盖了组件的非功能性要求,ODA组件的数据模型包含了安全、依赖、管理操作等部分,覆盖到了应用部署和运维环节。


ODA不仅仅是设计态的规范,还提供了配套的、支持微服务、云原生的Canvas环境和CTK等工具,提供了一个完整的可运行的应用框架。


ODA基于云原生操作系统Kubernetes的Operator扩展机制,通过事件驱动和插件扩展实现零配置的自动化运维,与NFV相比,ODA一开始就是基于云原生理念来设计,更加轻量化和易落地。


ODA规范设计和验证过程采用了开源的模式来协作,通过建立ODL(Open Digital Lab)开放数字实验室,众多运营商和供应商一起参与对设计进行验证、反馈和改进,更加开放并具有可落地性。


5


实战ODA-CA


浩鲸科技是第一批加入ODA宣言的企业之一,在创立之初就积极加入到规范建立、推广和落地的行动中,同时也是ODA-CA(ODA Component Accelerator)项目的初创成员之一。ODA-CA项目在AWS上搭建了一套ODL环境来对相关规范和技术进行验证。在这个项目中,浩鲸科技开发并完成了Product Catalog、Product Order Capture等ODA组件的测试验证,并向Canvas开源社区贡献了API Gateway等Canvas平台组件。在今年9月即将于根本哈根举办的全球数字化转型峰会(DTW)期间,TMF将联合浩鲸科技共同发布电信域解决方案的ODA Map。

根据浩鲸科技多年的电信领域实践经验,ODA组件的开发,首先是支持Open API接口,其次是云原生改造,并支持运行到Kubernetes平台上,最后是按照ODA规范输出元数据描述文件。如果应用本身已经支持了OpenAPI和云原生,组件适配的工作量并不大,以浩鲸科技为例,1个月左右时间就完成了适配和测试。另外值得一提的是,作为一个开源社区,Canvas底座也是开放的,比如Kubernetes平台,无论是Rancher等商业版还是社区版都可以支持。也欢迎各方积极参与并贡献平台组件。

6


总结


ODA基于TM Forum多年的电信管理经验和最新的云原生技术,通过可复用、可编排的组件设计和可拔插、可扩展的运行底座,可以帮助运营商建立一个敏捷、云原生和零运维的数字化系统,提高供应商、运营商、集成商的协作效率,同时标准化的、开放的组件市场也可以吸引更多创新团队加入,建立更加丰富的生态。ODA采用了开源模式共建,并借助社区的反馈进行改进,因此欢迎更多的企业一同参与,丰富组件市场和平台插件。


图片关键词

王玉木

浩鲸科技云产品总监、

TM Forum Contributer

  • 拥有15y+电信行业基础架构研发经验,目前负责Cloud Native、DevOps相关平台研发。
  • TM Forum ODA、Docker等社区的Contributer,获得5+容器相关专利,通过系统架构师、CKA、DevOps Master等认证。
  • 阿里云云原生讲师。


官方微信公众号

九州官方网站 版权所有 2003-2023

苏ICP备10224443号-6       苏公网安备 32011402011374号