专栏首页SDNLAB网络转型中的设备硬件形态选择初探

网络转型中的设备硬件形态选择初探

引言

江湖,武侠门派众多,武功众多,不一样的武功,有着不同的境界,同一种武功,随习武者悟性与天资的不同,武功境界也是参差不齐。从讲究招式,中规中距,到旁门左道,剑走偏锋;从天下之术,皆为我用,到盖世神功,深不可测;从武学宝典,出神入化,到自创武功,自成一派,不一而足。‍

网络,即江湖,亦如是。接着上一篇大道至简——迈向融合的未来网络,继续来聊下网络设备流派及网络转型之下硬件形态选择问题。网络江湖门派错综复杂,盘根错节,试图进行框架科普介绍,详细深入研究,待后续另开专题展开。

万物互联的核心即网络,网络赖以工作的原理倒也简单:传输 + 路由交换,但网络的庞大复杂却无与伦比。按照接入层次及业务领域,网络全貌大体如下:

上图基本涵盖了所有领域,其任一领域,如有线接入网,继续展开,可呈现大体如下拓扑:

上图任一层级随着逐步的聚焦深入,网络会暴露各式各样的网络设备,以至于单单是设备名称就足以让人抓狂。

一方面,随着新型业务层出不穷的涌现,在已有庞杂的网络上展开新的业务,甚至开拓新的领域,无论是运营商,还是设备商,还是芯片厂商都面临巨大挑战。网络全貌图中标红的领域为当前的热点领域,这里面有在传统业务领域基础上发生的变革,如在传统UnderLay之上进行OverLay的SD-WAN变革,也有革命性的采用新架构的SDN WAN。也有两者兼具的复杂演进,如BRAS向vBRAS的演进,既有设备形态上的变化,又波及网络架构转控分离的革命。更有彻底革命性变化,如5G网络的诞生,形成端到端的革命,从终端设备到基站,基站到骨干网,从移动通信到固定宽带,从实体网元到NFV网络切片,均为颠覆性的存在。

另一方面网络设备市场空间巨大,却被为数不多的几家厂商把控,面对如此巨大的蛋糕,只要沾边的厂商都想分一杯羹,形成了种种不同的抱团社区。面对纷繁复杂的变化,好在网络的演进方向清晰而明确。其中虽有运营商和设备商的角逐,传统芯片厂商和新兴芯片厂商的较量,网络的总体演进奔着解耦,开放,可编程的方向演进。

网络设备演进方向

纵观整个产业的发展,在过去的三十年中,互联网已经变得非常商业化,企业网络的协议和技术已经发生了变迁。但是我们也应该看到,虽然作为互联网中坚力量的以太网和TCP/IP协议栈显然是开放的,但是交换芯片和交换机制造商都对内部的组件讳莫如深。在过去几十年里,他们也很享受这种全盘控制给他们心理上、技术上和经济上带来的快感。领先交换芯片制造商(如Broadcom,Mellanox Technologies,Barefoot,Cavium和Innovium)详细谈论他们的技术。但与我们从全球CPU制造商那里获得的技术相比,他们公开的技术太肤浅。而且交换机的元件也没有像我们可以从任何一台OEM或ODM想要组装的服务器上那样被详细地列出。传统设备商如思科,华为等,让他们深度公开技术,更是难上加难。

网络设备的演进,基本围绕针对传统网络设备的解耦进行,进行解耦的方法动作,也逐渐清晰,具体体现为如下三层解耦:

1.网络系统软件解耦

  • 借力开源,可持续发展
  • 社区化协作,高效研发

2.软硬件解耦

  • 硬件标准化,提供更多选择
  • 掌控软件,沉淀研发运维能力

3.芯片解耦

  • 避免芯片锁定
  • 通用跨芯片平台

完成三层解耦,依赖的关键技术框架为SDN/NFV。网络设备完成架构转型,最终形成业务系统设计复杂,而灵活可弹性扩展;转发器尽量简单,业务无关形成融合,且可编程。

设备商流派

通过解耦从传统芯片厂商那里,完成芯片级替换革命,其方向和过程将曲折而漫长,涉及到技术和市场等多方面因素,角色可大体做如下划分:

传统网络设备商:现有网络中,传统设备既有者,如华为,思科等,占据了绝对市场空间,面对网络转型考虑的是如何维护既得分额,同时不丢失新兴市场。面对浩浩荡荡的解耦趋势,传统设备商不得不将固守多年的设备为用户提供开发接口;不得不拥抱开源社区,通过贡献源码,搅局开源社区,引导社区向自己方向发展。以至于FD.io,OpenDayLight,ONOS,Open vSwitch等开源社区,到处可见传统设备商身影;不得不折中两手准备,一方面主力推传统设备,一方面做新兴设备拓展。

运营商:随着自身利益空间不断被互联网厂商压缩,避免自己被管道化,要自主掌控自身命运,对网络设备的革命极为迫切,亟待实现三层解耦,实现厂商互操作,设备标准化。要做到这点,运营商不断推动进行三层解耦测试,网络转型方案试点,如vBRAS,SD-WAN,MEC,5G等试点。同时,积极创建和参与开源社区,和传统设备商进行方案方向角逐,ONAP,CORD,Stratum,凤凰项目等风起云涌。

新兴设备商:在传统网络中从未或很小占据市场空间,在网络转型中极力附和运营商,拥抱新兴框架,谋求网络彻底革命,以实现弯道超车,打开市场。新兴小厂商无任何负担,在新兴事物推动上较为积极。和运营商合作撬开市场,存在较多机遇。

转发芯片厂商:无论网络怎么转型,只要采用实体硬件转发,均离不开转发芯片,他们只需做好转发芯片的可编程能力,唯一的挑战来自于摆脱流量硬件卸载,纯软转发。该领域涉及:ASIC,NP,智能网卡,FPGA,P4等芯片厂商。面对可编程挑战,智能网卡,FPGA,P4正逐步成为新宠。

x86厂商:以其灵活的业务编程能力,同时借助NFV趋势,推动纯软转发势不可挡,如火如荼的FD.io,DPDK,VPP,Open vSwitch等开源社区可见一斑。

厂商流派的不同,侧重的硬件形态不同,硬件形态不同意味着强耦合和定制化。这里我们可以理解三层解耦的难度之大,转控分离南向关键接口的难以标准化。

下面按照解耦开放程度,依次介绍下设备商流派。

传统网络设备

最典型的传统数通设备厂商,如思科,华为,Juniper等。基本都采用了ASIC芯片及NP处理器。系统软件和硬件无法解耦,彻底捆绑,无法为用户提供编程能力,提供的是全套固定能力产品。

其关键在于硬件和软件的接口API层,是专有的,无法公开,无法标准化,形成一套封闭的系统。在开放趋势下,厂商不得不进行妥协,一定程度上开放编程接口,但效果甚微。

SDN化设备

SDN化趋势不可阻挡。原生的SDN思想非常理想,也最具革命性,典型如ONOS社区,南向接口只采用Openflow,Netconf等,业界叫做狭义SDN。传统设备商无法丢弃已有产品,已有蛋糕,同时又无法阻挡SDN大势,便采用传统数通协议完成SDN化,实现转控分离,于是南向接口复杂而广博了许多,如BGP-LS,PCEP,BGP等都出现了,业界称之为广义SDN,典型如OpenDayLight社区。SDN化设备实际上可以涵盖所有设备商流派,便于区分这里狭义特指传统设备的SDN化。传统设备商多采用该方式,实现自身传统设备向SDN架构的支持。传统设备商依托市面上强大的市场占有率,是成功的搅局者,逐步将最初狭义SDN空间压缩,以至于寸步难行。无论南向接口方面,还是硬件芯片生态层面,原生狭义SDN,很少商用,多停留在研究层面。

服务器形态设备

世界上现有的路由交换制造商可以从服务器(server racket)上学到一些东西。实际上,他们也的确这样做。打破网络设备的捆绑封闭,最值得借鉴的应该是PC或服务器行业,做到全面解耦。

硬件形态,规格参数严格标准化,通过操作系统OS驱动屏蔽硬件差异,实现业务应用的硬件无关,平台无关。直接引入至路由交换领域,采用标准服务器可否直接做网络设备?当然可以,但存在性能瓶颈,故而DPDK开源后大热。围绕转发业务层面,VPP,Open vSwitch等受热捧。

在软转加速方面,DPDK无法绕过,它源于Linux一直被诟病的转发性能问题,相信Linux内核后续会融入DPDK机制或对内核进行深度优化。DPDK在用户态通过CPU主动轮询方式托管接替了Linux内核被动中断机制,据说性能可提升10倍以上,但需要CPU主动轮询,无论报文多少都需要空转CPU。这意味着随着设备吞吐量的增加,需要线性堆加CPU进行绑定转发处理。CPU厂商可大量出货CPU,不得不说这是一个蛋糕点,或许大家能够猜测到厂商将DPDK开源的意义。Linux内核转发和DPDK转发处理路径对比如下:

DPDK机制在一定程度上可提升转发性能,个人认为并不能从根本上解决问题,跨CPU访问,PCI总线限制等,都制约了其向更大吞吐量,性能要求更苛刻的领域应用。一言以蔽之,CPU设计初衷在计算密集业务处理,不擅长流量转发,仍依赖于外置实体路由交换设备进行流量卸载。集中服务器形态,提升吞吐性能,只能集成硬件芯片卸载流量。如采用智能网卡(Smart NIC),FPGA等。FPGA也可理解为智能网卡的一种实现方式。智能网卡有两个使命:

1.解放服务器昂贵的CPU计算资源,流量硬件卸载;

2.和服务器集成,实现可定制,提供裸金属服务器。

围绕三层解耦,目前市面上智能网卡各自为战,无统一接口标准,可编程能力层次不齐,这是智能网卡所面临的问题,继续深究会发掘只是将捆绑从设备层面转移到了转发网卡层面。事实上,这涉及到网络设备解耦的本质。关注上层业务灵活扩展,同时对吞吐量有一定的要求,但对三层解耦无过多要求,智能网卡不失为一种选择。

P4设备

尽管SDN化的设备有了一定的可编程能力,但其扩展仍旧是有限的,且进行私有扩展无法形成标准。于是衍生了完全可编程的SDN思想,即P4(Programming Protocol-Independent Packet Processors),它提供了一种芯片可编程语言,屏蔽底层硬件,硬件芯片提供对应能力接口即可,通过P4语言实现对流量的可编程处理。

P4芯片的可编程能力通过无差异的可编程逻辑单元实现,每个逻辑单元做匹配及处理动作,用户通过编程语言编排定义逻辑单元,实现整体的可编程。

P4联盟的开创者,两位SDN大师,普林斯顿的Jennifer Rexford和斯坦福的Nick McKeown,他们也是SDN整个领域的开创者。主流开源控制器ODL,ONOS等已支持P4,P4硬件芯片也有问世。抛开P4芯片厂商不谈,P4本身确实提供了一种很好的思路方向,个人认为是演进的方向,形式倒不一定是P4。

彻底革命派

围绕三层解耦,尽管运营商,设备商,芯片厂商都给出了SDN/NFV方案,但各厂商站在自身利益层面,基本上依旧各自为战,无法实现彻底解耦。比如采用标准服务器,是真正彻底解耦了,还是陷入了更为彻底的捆绑?服务器CPU,芯片是否解耦?和传统网络设备有无本质区别?这是个值得思考的问题。运营商,学术研究机构及互联网厂商的看法和动作或许更值得关注。Google,FaceBook等厂商源于自身业务爆炸式增长,面对雷打不动,铁板一块的传统网络设备,动了彻底革命之心。Googel的B4项目,FaceBook开源分布式网络路由平台Open/R,更主动推动OCP(Open Compute Project)。再看国内,阿里,腾讯,百度,京东,中国移动,中国联通最初六家单位成立凤凰项目,以不捆绑任何特定商用软件平台,实现网络设备自研。在成熟度及影响力上,这里想谈下FaceBook主导推动的OCP开源计算工程。它几乎涉及了网络设备的所有领域,它的变革思路,宏大,广博而彻底,值得借鉴。在网络设备领域,OCP做到硬件和网络操作系统NOS解耦的核心为ONIE(Open Network Install Environment),ONIE类似于PC电脑里的BIOS,提供设备硬件和网络操作系统之间的一层适配。

在裸金属服务器或白盒设备上,预装ONIE,通过ONIE可以安装不同厂商网络操作系统(NOS)。这点类似于标准服务器通过BIOS,可以引导安装Windows,Linux,FreeBSD等不同操作系统,这里可以再次印证网络设备借鉴服务器领域的发展方向。ONIE对下屏蔽硬件架构差异,目前支持ARM,x86,PowerPC架构;对上屏蔽不同操作系统。似乎平淡无奇,但确实关键一步,简直是巧夺天工。

ONIE可以理解为一套具备系统引导功能的微型操作系统,它管理网络设备的CPU,存储及原始的接口管理,但不具备转发能力。简单架构如下:

预装了ONIE的网络设备首次上电后,进行网络操作系统安装(如:SONiC,ONL等),其过程如下:

网络操作系统安装好之后,再次启动,系统引导至已安装的操作系统,而跳过ONIE,过程如下:

网络操作系统方面,ONL(Open Network Linux)值得一提,它作为OCP工程的一部分,旨在打造网络领域的开源标准Linux,目前已在CORD 和Stratum项目中有落地。ONL支持多种数据平面抽象接口:OF-DPA, OpenNSL 及 SAI。同时兼容大部分路由转发代理项目:FRRouting, Quagga, BIRD, Facebook FBOSS, Google gNOS以及 Azure SONiC。

本文分享自微信公众号 - SDNLAB(SDNLAB)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-05-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

推荐阅读

  • 「网安夜校」开课啦!多门网络安全课程开启限时优惠报名

    众志成城,共抗疫情。腾讯安全联合腾讯云大学、腾讯课堂启动「网安夜校」,为大家提供限时优惠的网络安全课程。欢迎网络安全从业者和信息安全专业学生报名参加学习,快速充电提升自我。

    腾讯安全
    安全培训腾讯云大学
  • Flink源码走读(一):Flink工程目录

    导语 | Flink已经成为未来流计算趋势,目前在很多大厂已经有了大规模的使用。最近在学习Flink源码,就想把自己学习的过程分享出来,希望能帮助到志同道合的朋友。开始阅读源码,说明读者已经对flink的基本概念有一些了解,这里就不再重复介绍Flink了。本文作为学习过程的第一章,首先对Flink的工程目录做一个解读,了解了工程下各个模块的作用,才能在遇到问题时准确定位到代码,进一步学习。

    2011aad
    大数据解决方案
  • Flink源码走读(二):Flink+Kafka实现端到端Exactly Once语义

    Flink通过Checkpoint机制实现了消息对状态影响的Exactly Once语义,即每条消息只会影响Flink内部状态有且只有一次。但无法保证输出到Sink中的数据不重复。以图一所示为例,Flink APP收到Source中的A消息,将其转化为B消息输出到Sink,APP在处理完A1后做了一次Checkpoint,假设APP在处理到A4时发生错误重启,APP将会重新从A2开始消费并处理数据,就会导致B2和B3重复输出到Sink中两次。

    2011aad
    大数据解决方案Kafka
  • kubernetes系列教程(十九)使用metric-server让HPA弹性伸缩愉快运行

    kubernetes监控指标大体可以分为两类:核心监控指标和自定义指标,核心监控指标是kubernetes内置稳定可靠监控指标,早期由heapster完成,现由metric-server实现;自定义指标用于实现核心指标的扩展,能够提供更丰富的指标支持,如应用状态指标,自定义指标需要通过Aggregator和k8s api集成,当前主流通过promethues实现。

    HappyLau谈云计算
    Kubernetes容器微服务微服务架构腾讯微服务平台 TFS
  • 三分钟入坑指北 🔜 Docsify + Serverless Framework 快速创建个人博客系统

    之前由于学摄影的关系,为了提高自己的审美,顺便锻炼下自己的英文能力,翻译了不少国外艺术类的 文章。最近一直想搭一个个人博客来存放这些内容,又懒得折腾建站,遂一直搁置。

    Aceyclee
    ServerlessHTML网站GitGitHub
  • NVM作为主存上对数据库管理系统的影响

    implications of non-volatile memory as primary storage for database management systems

    yzsDBA
    存储缓存数据库数据结构SQL
  • DevOps平台架构演进

    附最新架构图https://www.processon.com/view/5cbd897de4b0bab90962c435

    我思故我在
    DevOps 解决方案微服务架构架构设计
  • 【腾讯云AI小程序大赛】中山大学作品《小耳朵天使》

    ----------------------------------------------------------------------------------

    陈华山
    小程序 · 云开发小程序语音识别文字识别对话机器人
  • Kona JDK 在腾讯大数据领域内的实践与发展

    经常听人谈到 OpenJDK,那它到底是什么呢?相信大家都听说过 Java SE、ME、EE等规范, 通常意义上对 Open JDK 的定义指:Java SE规范的一个免费和开源参考实现。

    腾小云
    JDKJavaJVM大数据Oracle
  • 公告丨腾讯安全产品更名通知

    为了更好地为政企客户的安全保驾护航,腾讯安全即日起更新旗下身份安全、网络安全、终端安全、应用安全、数据安全、业务安全、安全管理、安全服务等八类安全产品的命名,致力于打造全栈安全产品“货架”,让客户选购安全产品/服务更加便捷,更快地找到合适的安全产品,从而对自身的安全建设“对症下药”。

    腾讯安全
    DDoS 防护应用安全 MS验证码(业务安全)应用安全(移动安全)漏洞扫描服务

扫码关注云+社区

领取腾讯云代金券