慧与(中国)赵华:从IT/CT融合看下一代网管

各位来宾,大家早上好,我叫赵华,来自慧与(中国)有限公司,我们的名字叫HPE,我所在的部门是CMS,全称是通信及媒体解决方案事业部。这个部门是整个HPE在中国实施SDN/NFV的主体部门。

刚才听大家讲了很多关于下一代网络怎么演进,刚才移动的王所长也谈到下一代网管,他们也有这方面的一些想法。实际上我们看到整个网络的变化非常迅速,但是从这十几年来看,整个的网管变化并不是很大。但是站在SDN/NFV的角度来看,将来的网管实际上是跟我们未来的网络和未来的业务深度重合在一起,它已经成为网络和业务的一部分。站在这个角度来讲,我们再看我们未来的业务是IT和CT融合业务,刚才谈了很多云网融合,云网重合只是一个例子,将来互联网企业以及电信企业实际上会有更深层次的合作。从这个角度来讲,互联网能给我们带来什么启发,IT和CT融合,我们怎么来看下一代网络,这是我今天想讲的主题。

首先我们来看一下,要讲下一代网管,我们看下一代网络将来会怎么演进。这里面跟大家分享一下比较新的观点,关于下一代网络价值的新观点,来自于AT&T,今年年初发布的,他的Domain2.0谈的什么概念,我们将来在云化的数据中心上能够随心所欲的像云服务一样开通我们的电信服务,他未来的网络3.0,他称之为Indigo,下一代的网络平台不仅仅是一个智能的管道,将来更加是一个能够支持我们创建未来的数据驱动的新型社区的平台。怎么理解,他所谓的数据驱动的新型社区不是我们简单的是由个人组成的社区,将来的社区是一个由不同的组织能够组合在一起的新型社区,这些组织他们最大的作用和价值是能够把他们各自的数据都放到这个平台上,然后这个平台能够提供机器学习、大数据分析、增强智能等等这一系列的工具,AT&T的目标是帮助这个社区创建、验证、部署各种各样的微服务在这上面,从而帮助他们致力于去解决未来复杂的分析型的问题。这是AT&T最新发布的对未来网络新的价值定位。这个价值定位让我想起我们现在很多互联网公司,这些伟大的互联网公司他们的价值定位也是一样的,他们想做的是做一个由数据驱动的平台型公司,我们看到Facebook、Linkin、BAT,本质上来讲都是数据驱动的平台型公司,未来的运营商我们是不是也可以做到这样的定位,这是值得我们思考的,也是我们看下一代网络最终怎么转型的这么一个新的思路。这也是我们谈下一代网管的基本出发点,网络将怎么变决定了我们网管怎么去做。

基于SDN/NFV技术,我们谈的电信业务,业务实现很复杂,和我们现在互联网来比,互联网业务看起来实现起来比电信业务要容易,他们之间有什么本质的区别,将来我们这个网络上,互联网业务和我们电信业务会做深度融合,这个融合将来怎么管理,他们之间是否有本质的区别,如果我们认为他们之间的区别其实是不存在那么我们的管理是不是可以有一种统一的新的思路,这是我谈这个问题的出发点。

怎么解决这个问题,有一句话说得很好,软件工程有一个基本的理论,如果有两个问题,这个问题解决不了,我们试图从额外的一个更高程度的抽象层次来看这个问题怎么解决。从一个更加抽象的层次来看,主流的互联网业务,它是基于微服务的,这些微服务可以部署在分布式的云平台上。这些业务我们从抽象的层次来看可以分为四层,对于互联网业务来讲,主要的工作是在于云平台、微服务和应用层,连接层它并不是很关心。每层会部署每层的功能,比如在云平台会有Docker,在微服务层会有各种各样的服务化的组件,在应用层会把这些服务组件从应用调动的角度组合成一个业务的应用,我们叫做功能层。但是每一层还有一个管理的组件,在管理组件来讲,在云平台层,我们谈Docker的部署上有OpenStack,有kubernetes,微服务层次可以分为两层,一层叫微服务管控平台,再往上一层,如果做整个应用的管理,实际上也是有微服务应用和业务的编排层面的功能,这些功能可能大家目前应用的不是很广泛,Netflix推出来的Conductor可以看一下,微服务业务编排器。这是我们谈的主流的互联网抽象模型的架构。

我们看基于ETSI NFV的架构,用同样的方式来看,也是用分层的抽象的概念组成,每一层也会有相应的功能层和管理层,业务层有业务编排管理,在NS层有网络服务和NFVO,在VNF层面,我们有各种各样的VNF能力以及VNFM/EMS,同样的架构,它在这个层面跟我们云的应用、互联网的应用本质上没有太大区别的,只是它更加复杂了。看一下大概会有哪些区别和共同点。它的共同点,我们可以站在一个分层抽象的角度来看,整个应用的实现、整个业务的实现,它是可以由不同的层的功能能够组合在一起实现的,每一层可以利用下层提供的功能,把它称之为资源,用下层提供的资源来实现我本层的能力或者本层的功能,同时把最后实现的成果再以抽象的方式向上层提供,我们称之为服务。每一层对上来讲是服务,对下层来讲会调用资源,通过这个来实现它的功能,这是一个本质的共同点。另外一个本质的共同点,我们在每一层里面,每一层完成这一层的功能实体和它的管理实体,这两个是高度统一的,我们的管理不是在一个上层的概念,而是说在同一层进行管理,服务功能和服务控制的一体化,是同层的,他们是缺一不可的,而不是作为一个Overlay的方式提供的。还有一个差一点,作为云计算的互联网应用和电信业务,本身是有很多区别这些区别不是本质的区别,但是有一些互相可以借鉴的东西,比如在业务层,互联网业务一般是在第七层进行交互,但是我们电信的业务很多是在L3、L2连接层的服务,同时再加上L4-L7层的交互。我们谈互联网业务,很多的生命周期管理是发生在开发平台、测试平台和生产环境之间的CI/CD的工作,整个电信的生命周期管理活动是体现在业务订单以后,会动态的进行整个生命周期服务的创建还有删除、扩缩容这个过程。互联网应用多租户的问题是通过业务层内部的逻辑解决的,而我们电信业务多租户概念是针对每个租户会有特定的业务实力的生成,当然它也会有一些共享的业务实力,是由这种复杂的状态组成的。刚才也看到,互联网业务的层和层之间的层次相对较少,基本上没有跨层的调用,反观CT,业务层比较多,NS层可以嵌套,可以调用NS作为内部的NS的服务,这是比较复杂的。虽然它是复杂的,但是它的本质共同点是最关键的。同时可以借鉴互联网的一些思路来解决我们目前碰到的这些问题,比如说我们怎么实现VNF的原生云化,实际上互联网的业务就会告诉你,我们会有主流的微服务的开发和管控的框架,你可以基于这个框架去做,就可以做到无状态,就可以做到随意的弹性伸缩、水平伸缩。另外一个例子,我们现在做VNF,网络里面可能有很多VNF,都要做初始化的配置,这些配置有没有更好的方式,Spring Cloud的配置管理有很好的思路,不光能够做所有微服务的配置,可以跨DevOps做不同的配置,实际在融合的角度有很多可以去借鉴的地方。

回到网管来看,刚才看到整个抽象模型里,最重要的是做层的管理实体,实际上所有的层管理实体集合在一起,最后完成的功能就是我们称之为网管要实现的功能。怎么来看这个层管理实体的实质,每一层有很多通用功能,包括我们对整个服务功能这一层功能的定义,我们会用模板来定义,对它进行服务上载的过程,整个服务上载以后生命周期的管理,包括创建、删除、弹性伸缩还有版本升级等,我们称为生命周期管理的操作,另外对性能、故障进行监控等等,我们看虚拟化层,看VNF层,看微服务层,实际上都会有同样的功能,这是我们可以去进一步思考怎么去融合这些功能,怎么互相借鉴。这里有个非常重要的观点,整个的服务,每一层的服务要向上层抽象出来,形成一个新的能力供上层调用,这种抽象的关键点,我们要屏蔽本层的细节差距,我是怎么实现的不要去关心,但是我提供给你什么样的能力,我们需要有一种更好的建模方式,这个重要性更重要的是体现在业务层,业务层我们需要一个更好的建模的工具,我们称之为意向式建模。意向式建模是一种对系统的建模和抽象的方式,这种方式的关键点是你不用去描述这个系统能做什么、怎么去做这件事情,而只需要描述它拥有哪些属性,如何实现这些属性你不用去关心。这个意向式建模有一种建模语言,这种建模语言类似于我们的编程语言的其中的一种,编程语言我们现在如果熟悉软件开发也会了解到,有很多是意向式的语言,最典型的例子,我们谈SQL语言,当你访问数据库获取一个结果的时候,不需要一条一条记录查,告诉数据库以后,数据库会有后台的DBMS去匹配,最后把结果告诉你。SQL语句就是典型的生命周期的语言,在这个层面建模,你只需要关心你想要什么,不需要关心他你怎么去做这件事情,这个技术在我们未来网管里面是非常关键的技术。

基于意向式建模,举一个例子来看,实际上我们基于意向式建模,不同业务的生命周期管理活动,比如要创建一个新的网络服务,或者要删除它,从本质上都变成一体的,我不需要建你不同的流程,意向式建模,我有一个最终的状态,这是我想要的一个理想的状态,这是在模型里面描述出来的,我现在的状态在没有生成实力之前是没有的,后台的引擎就可以自动去匹配这两个状态之间的差异,自动生成一系列的执行动作,让你去生成创建这个业务的实力。如果出了故障,这个服务如果说某一个业务组件出了故障,这个业务组件跟我最理想的状态之间,差一点只是在这一个业务组件上,它会自动匹配它的差异,去修复这一个业务组件。我们站在这个角度来谈,所有业务的生命周期管理的活动从本质上是一致的,我们不需要建立不同的业务开通的长流程去解决问题,这是一个观点。

另外一个观点,意向式建模这种业务模型尤其在业务层我们认为很关键的一点,尽可能在业务层做连续的抽象建模,只有在你真正需要去驱动设备或者驱动资源的时候,我们才去调用特定的后台的SDN控制器也好、EMS也好,还是我们包装出来的各种各样的微服务也好,跟底层的资源和设备驱动的连接点是我们建模最后的一个环节,我们不应该把这个环节放在整个模型的上层去做,所以我们叫基于意向式建模,建模的思路叫做连续抽象,在叶节点上做具体的配置操作。好处是模型能适应更多的设备和供应商的场景,同样一个VCP的业务如果去开通,我可以适配不同的具体的客户场景或者设备场景,甚至有可能原来某一个节点是虚拟的和物理的设备都可以互换的情况下,这种模拟的上层还是保持稳定的。HPE我们推出的Service Director业务编排管理器就具备这样的能力。

下一代网管还有很多典型的技术特征,这些技术特征融合了互联网的整个业务开发,还有整个电信对SDN/NFV的深度理解,它会是一个更加模型驱动的,它整个会引入大数据做故障的管理分析以及预期,我们叫做整个网络业务的分析,它会对这个服务进行开放,会用微服务的方式来构建它整个的组件,会采用DevOps的方式来设计和开发新的业务。

最后谈一下HPE对下一代网管的蓝图设想,设计态和运行态是我们都比较关心的,设计态,一个是VNF设计,怎么跟厂商一起采用DevOps方式去认证和设计整个VNF,这是一个生命周期。另外是业务和网络服务的设计,整个网络业务和整个网络服务,刚才我谈到了基于意向的建模模式是我们认为最重要的去实现业务建模的关键点。另外是OSS本身,它本身微服务化以后它的能力也是有一个能力的完善和设计的过程。设计态的东西跟我们在未来网管里面它的DevOps支撑平台是很重要的,要有相应的支撑平台去支撑它。底层我们可能现有的网管、现有的EMS,你可以用现有的接口,也可以做OSS的微服务化的改造,这是不同的选择。整个网管的核心就是业务编排层,我们站在业务编排的角度来看,实际上我们底层的所有的东西都可以称之为是它的资源,上层要用下层的资源去完成本层的功能,从广义上来讲,不管你是控制器也好,还是VNF也好,从这个角度看它就是资源,所以资源层是一层,上面的业务编排层是另外一层,这是我们一个大概的观点。

感谢大家,HPE在中国我们是一个中立的厂商,秉承开放集成的思路,也希望将来能够有更多的机会参与到整个中国SDN/NFV发展的大的进程中去,谢谢大家。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/18632.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于17-02-23
0