Focus    前瞻洞察
前瞻洞察
算力网络架构演进的思考
文 | 新华三集团解决方案部 孟丹

摘要:

算力网络将原本割裂的云网深度融合起来,是运营商网络架构持续演进的选择。本文通过对云计算技术发展的介绍,推导出算力网络的必然性,再介绍算力网络集中式架构和分布式架构的异同,并就构建算力网络的关键技术进行阐述,最后对算力网络的发展进行了展望。

关键词:

算力网络;集中式架构;分布式架构;算网大脑;算力路由;算网度量

1 算力网络背景

算力网络领域,标准先行于实践,2019年8月第一篇算力网络文稿在CCSA立项。经过几年持续技术研讨,业界已经形成一定共识,目前算力网络已经成为国家战略性新兴产业研究的方向之一。

算力网络是由云计算的架构变迁引入的。云计算为企业和个人提供了一种弹性灵活、易维易建且性价比高的IT建设新选择,云最开始是以集中式形态出现的,数以千计的服务器集中在一个地理范围内,以池化、资源可高度复用共享的方式提供各类IaaS、PaaS、SaaS服务。但集中高挂的云资源池并不适用于所有场景,比如对低时延、大带宽有诉求的用户,因此云计算演变为集中-边缘多级协同架构。云计算的不同层级提供不同的服务质量,集中云可以提供大通量高算力服务,边缘云可以提供低时延大带宽低算力服务。如何同时兼顾云提供的算力能力和接入点到云的网络指标,给用户选择最合适的云,算力网络技术就是一种合适的选择。

在算力网络概念提出之前,已经有了云网融合的提法,云网融合更侧重于云,网络仅提供可达性,而算力网络则是将算力和网络并列,同时兼顾。

算力网络本质上是一个生态系统,涵盖用户、应用、算力、网络等多个要素,通过算网调度平台把各要素串联起来。作为算力供给方和算力需求方之间的桥梁,这个平台要真正发挥作用,必须有丰富的应用生态,明确的算网度量、动态的调度策略,否则算力网络就是空中楼阁,难以发挥作用。

图1 算力网络架构

算力网络架构可以划分为三层。最底层是算力网络基础设施层,提供算力基础设施和网络基础设施。算力一般先支持自有的算力系统,后续不断扩展,对第三方算力也进行纳管。网络则从骨干网/城域网向下不断渗透,将各类接入网也纳入管辖范畴。

中间是算力网络控制层,起到承上启下的作用,一方面将算力信息和网络信息存储起来,另一方面根据应用需求对算网进行综合决策,选择合适的算力资源池,并打通网络路径。

最上层是算力网络服务层,提供开放能力给各类算网应用。

2 算力网络架构

算力网络包括集中式和分布式两种架构。

集中式算力网络中算网调度平台是中枢,由它来分别获取算力使用情况和网络拓扑及质量情况。当应用有算网请求时,由算网调度平台进行集中决策,兼顾应用的算力请求和网络要求,选择合适的云资源池,并打通网络承载路径,将应用流量牵引过来。

图2 集中式算力网络架构

分布式算力网络中算网调度平台功能弱化,更侧重运维和分析功能。网络边缘节点会感知下挂的云资源池内算力使用情况,并通过路由协议在网络域进行通告。当应用有算网请求时,用户侧网络设备可以根据本地算网信息进行决策,选择合适的云资源池并打通网络承载路径。

我们一般把分布式架构下网络设备上新增的这部分功能称为算力路由功能,此时网络设备不再是单纯的网络流量承载,在其上已经融合进了算力因素。

图3 分布式算力网络架构

集中式方案相对简单,对网络承载设备没有额外技术要求,网络并不感知算力,但算网调度平台做为方案的核心,在大规模算网部署时将成为性能瓶颈,对于算网服务请求的响应相对缓慢。分布式方案中网络感知了算力,算力和网络是一体内生的,对于算网请求的响应会相对快速实时,但同时也要求网络承载设备增加算力感知及同步能力,并能响应算网服务请求,增加了网络承载设备的技术难度。

目前集中式架构的算力网络方案相对成熟,运营商均有自研产品。分布式架构的探索还在进行中,目前在标准领域、原型方面有一定成果。

3 算力网络关键技术

算力网络包含一些关键技术,其中算网度量是最基础的,相当于定义了供需双方沟通的语言。明确好度量定义后,通过算网感知获取系统中的算力信息和网络信息,形成内部的决策依据。之后算网应用会发出算网请求,平台进行算网调度提供合适的算网服务。

算网度量:作为一个拉通供需双方的平台,首先要有一套双方均认可的度量标准。网络类的网因子可以包括带宽、时延、抖动、丢包率、可靠性等。算力类的算因子度量指标要按服务层次进一步划分,IaaS类算力可以通过CPU核数、内存可用容量、存储可用容量等指标衡量,PaaS类算力需根据服务类型定义不同的度量指标,比如数据库通过QPS/TPS、消息队列通过每秒处理的消息数来衡量等。SaaS类度量也要按服务类型细分,如音频编解码能力、视频编解码能力、业务会话数、业务繁忙状态等。

集中式和分布式架构均采用相同的算网度量标准。

算网感知:算力网络需要对算力信息和网络信息进行感知并记录,作为决策时的参考依据。

集中式架构下,算网调度平台需要获取云内算力使用信息,可以采用订阅式被动方式获取,也可以采用周期性主动方式获取,同时算网调度平台也可以从网络域获取到网络拓扑信息。如果算网规模较大,一方面可以通过调度平台弹性可扩展的架构来支撑,另一方面可以按多级调度平台方式部署,依靠软件实现的功能相对灵活。

分布式架构下,和云资源池接口的网络设备首先获取到云内的算力使用情况,然后通过路由协议在域内进行泛洪,此时网络设备相互传递的信息除了网络拓扑、路由可达、网络链路外,还额外增加了算力信息。

算网请求:由对算力和网络同时有诉求的算网应用发起算网请求。不是所有的应用都需要算力网络,对时延、带宽不敏感的应用完全可以按原有的模式只构建在云计算之上,网络只是作为可达性配套而已。算网应用在表述算力网络需求时应遵循算网度量指标,和供给侧匹配。

集中式架构下,算网请求由算网应用向算网调度平台发起,两者之间一般通过RestAPI接口交互,接口中明确了应用关注的算力信息和网络信息。从根本上说,只有应用才清楚自己对算力的网络的诉求,因此算力网络需要应用深入参与,应用是有一定改造工作量的。

分布式架构下,算网请求直接包含在应用的流量中,携带算网请求可以有不同的实现方式,如果应用能做改造,应用可以通过扩展头的方式携带算力和网络诉求,但此类改造需要操作系统的配合,有一定技术难度。另一种方式可以预先定义若干算网服务模板,以不同的服务ID对外提供,应用携带不同的服务ID表述自己的算网请求。

算网调度:算力网络收到应用发起的算网请求后,结合算网感知阶段收集到的算力信息和网络信息,结合动态配置的调度策略,选择最匹配的云资源池。

集中式架构下,算网调度平台解析算网请求,进行算网决策,选择最匹配的云资源池,打通应用接入点到云资源池之间的承载路径,同时通过各种引流技术将应用流量引入承载网络中。

分布式架构下,应用发起算网请求后,用户侧网络边缘节点解析应用流量携带的算网请求,在内部首先做服务ID到算网请求明细需求的映射,然后进行算网决策,选择最匹配的云资源池,打通应用接入点到云资源池之间的承载路径,同时通过各种引流技术将应用流量引入承载网络中。

4 算力网络展望

目前算力网络的研究还在向更深更广的方向延伸。

算力方面,从集中式云计算到云边协同的边缘计算,不同层级的云资源池共同提供算网服务。未来算力可能再往下延伸到端侧,各类泛在算力的存在可以做为现有云边资源的补充,算力网络也可以相应向下延展,但端侧算力的可信、度量、认证需要持续分析,避免引入安全风险。另外,算力度量在IaaS层比较容易达成共识,但在PaaS和SaaS层由于服务类型多样,服务特征不同,度量指标需要算网调度平台和应用共同制定,还会经过比较长的周期。

网络方面,目前开发重点集中在城域汇聚核心之上的网络,未来算力网络要继续向下延伸到接入网。同时基于路由协议发布算力信息是一个基本共识,但要想实现多厂家网络设备之间的互通,需要运营商牵头定义好详细的协议报文格式,需要经过业界充分讨论。

生态方面,算力网络是应用的支撑平台,没有应用算力网络是没有生命的,但让应用愿意基于算力网络做定制开发,得有足够的利益驱动。如何让各方在算力网络的演进中持续共赢是一个需寻长期推动、重点关注的方向。

IETF作为IP网络领域最权威的标准组织,2023年3月份成立的cats工作组专注于算力路由的研究,新华三集团也积极参与标准的写作和推进,会在标准领域发出更多声音。

关闭