Skip to main content
开放网络的先行者与推动者—星融元
加入我们技术支持(Support)  TEL:(+86)4000989811

技术分享-P4可编程平台+DPU的负载均衡实现思路


关注星融元


在选择硬件还是软件负载均衡方案时,务必根据实际的场景去考量。我们总结衡量负载均衡性能的关键指标,主要有以下几条:会话表项容量、新建并发处理数量、转发性能。

硬件负载均衡的优势:高性能,功能全面,打包提供安全功能

在定制处理器上运行的独立负载均衡服务器。硬件负载均衡一般都支持全局负载均衡并提供全面的、复杂的负载均衡算法,功能强大;并且基于专用的处理器,吞吐量也能做到很高,可以支持单机百万以上的并发。此外硬件负载均衡往往具备防火墙、防DDOS等安全功能。

硬件负载均衡的问题:昂贵、灵活性差、扩展性差、无法被云平台统一管控

支持硬件负载均衡的专用设备是一个封闭的盒子,当需要进行动态扩容/网络改造时会非常不灵活。举个例子,目前有很多上云的业务希望用云管平台统一管理起来。但是如果是用封闭的硬件负载均衡方案,就无法做到灵活的统一管控。另一个更为实际的因素,价格。专用硬件负载均衡设备价格昂贵,大多数用户负担不起。以F5 的设备为例,一台比较低端的设备在市场价格可达到 30 万左右,如果还需要进行高可靠部署,成本就是翻倍的。

IB交换设备图

软件负载均衡的优势:可在标准硬件上运行,低成本,良好的扩展性

软件负载均衡的问题:性能差、部分情况配置复杂、部署在服务器上大量消耗了服务器性能

显而易见,性能上达不到专用硬件的性能。在做这种软件负载均衡的情况下需要考虑各种各样的接口,业务的配置,这会是非常复杂的情况。并且所有基于软件的负载均衡实现方式都需要部署在我们服务器上,也就意味着消耗服务器 CPU 的性能,造成了我们各种各样的一个厂商成本上升。

基于P4+ DPU可编程平台的的负载均衡实现思路

1、P4+DPU的可编程开放硬件平台(需配合用户自研负载均衡软件)

  • 可提供千万级的会话表项和百万级的高并发
  • 相比专用的负载均衡设备,在设备成本上有非常大的缩减
  • 管理平面、控制平面和数据平面全部可与CloudOS对接

P4+DPU的可编程开放硬件平台

P4+DPU的可编程开放硬件平台的转发过程

负载均衡实现概要

有一个新请求过来,设备首先会去查表,如果命中就直接走硬件的快速转发;如果没有命中就会把请求上送到智能业务处理卡(GHC卡),由其进行转发。与此同时它还会把相关信息发送给CPUCPU会生成详细的会话表项,并把表项的摘要下发到交换芯片中,交换芯片在数据流下次进来的时候直接转发,从而实现智能快速转发和慢速转发的结合。

在实际的负载均衡场景中,往往存在着非常定制化的开发需求。X-T系列硬件平台可提供一款针对开放、可编程网络构建的底层操作系统(AsterNOS-Framework,它作为一站式的综合开发环境,以轻量化的SONiC为内核,将三种异构硬件单元(x86/ARM/P4 Switch ASIC)融合成一个完整的网络系统,可为开发者大大缩短开发周期。

相关链接:https://asterfusion.com/product/x3-t/

2、Helium DPU网卡(Server in Server,卸载服务器上的软件负载均衡)

  • 高性能DPU芯片,多核ARM64、集成多个硬件加速协处理器,拥有百G级的网络连接能力
  • 智能网卡的外挂扩展内存可解决四七层负载均衡对会话表容量的要求
  • 卸载OVS+负载均衡释放服务器集群性能,降低服务器集群压力

卸载服务器上的软件负载均衡

除了标准的Linux以外,Helium DPU网卡还可提供底层基座操作系统FusionNOS-Framework和DPDK开发套件,客户可以此为基础,直接开发上层应用程序。基于x86开发的各种DPDK应用、VPP应用和一般Linux驱动应用,仅需要简单编译就可以迅速移植到Helium DPU网卡上。

提供底层基座操作系统FusionNOS-Framework和DPDK开发套件

各种DPDK应用、VPP应用,仅需简单编译就可以迅速移植到Helium DPU网卡

相关链接:https://asterfusion.com/product/helium_dpu/

相关文章

SONiC/SAI诞生这么些年,为何开放网络依旧难以落地和普及?


关注星融元


在开放网络这一新型的交付模式下,行业需要的是一种新型的技术供应商,一个服务全生态的,专业、可靠的合作伙伴,并且基于标准的开放网络规范,为行业交付高可用的企业级产品和服务,弥补当下存在于开源项目和实际生产应用之间难以跨越的鸿沟。

我们都知道,想要高效利用云中的各类资源,需要云变得更灵活、更有弹性、更易于运维。这对云中的网络设备提出了更为具体的要求,例如开放接口、软件定义、模块化构建、快速迭代等等。

然而传统封闭的网络方案是围绕着特定厂家的硬件和软件来搭建的,难以适应生产环境中快速变化的市场需求。于是,各大云巨头开始尝试用更加创新的方式构建起了更加定制化的云数据中心网络,逐渐有了我们所说的开放、解耦的网络解决方案。当前比较主流的开放网络方案便是微软发起的 SONiC/SAI项目,已经有越来越多的企业和组织选择基于SONiC的开源NOS和开放的硬件交换机,构建他们的自己云数据中心。

以前,各类企业/组织采用封闭的网络解决方案构建支撑自己业务的网络基础设施,往往需要与供应商协商产品Roadmap,或开发/变通复杂的解决方案,为此花费了很多的时间和资源。

现在,开放网络的特性天然有助于加速新特性的落地和新方案的快速验证。并且正因为SONiC和硬件交换机充分解耦,各类用户在网络设备上的选择上也变得更加自主可控,他们可以根据实际去选择不同类型的网络硬件平台来开发验证新的网络功能,而不是把自己的业务构建在专有的硬件或者特定的芯片上,从而避免了被单一厂家的产品方案所锁定。

开放网络,机遇与挑战并存的广阔天地

我们或许需要上升到产品交付模式的改变才能更好剖析开放网络兴起给业界带来的巨大变化。

传统交付模式和开源交付模式的对比图

在传统的交付模式下,

技术创新和价值创造呈现出单一的链式传递:设备制造商对接上游供应商,最终用户只需要跟着选定的设备制造商的产品和解决方案缓慢升级。我们可以想见,在数据中心业务高度市场化,各类创新业务快速发展的今天,这种看似稳定简单的模式埋藏诸多隐患,某种意义上犹如温水煮青蛙。

而开放网络的交付模式则类同网状结构,

整个生态以开源组织和项目为中心,围绕着各大开放网络软件制造商、白盒厂商以及最终用户。参与技术创新的角色不再局限于各类软硬件供应商,而是扩展到了最终用户。在该模式的理想状态下,只要具备一定技术能力的终端使用者都能基于实际需求自主开发各类网络功能和应用,并且这种技术创新也会以不同形式反哺到开源组织和项目中,共同促进整体生态和行业的蓬勃发展。

开放网络技术的诞生给市场提供了一个区别于传统方案的,更加灵活、自由、开放的选择,从而带来更大的技术创新空间和机会。

为未来欢欣鼓舞的同时,我们也必须承认理想和现实之间的差距——正是从“链式”到“网式”的转变,使得各方需对接的角色大大增多:芯片供应商,以及终端用户不再只是面对设备制造商,还要面对网络软件和解决方案厂商以及各种开源组织和项目。这无疑是对业界各类参与者提出了更多、更大的挑战。

阻碍开放网络方案落地和普及的主要原因

具体而言,现阶段有以下因素较为明显地阻碍了以SONiC/SAI为代表的开放网络技术在生产环境的落地和普及。

1、网络开发相对小众,开放网络存在较高的技术门槛

如果想要使用开源NOS(即便是SONiC/SAI),你可能不光需要掌握传统的网络协议、网络设计能力,还要同时具备更为现代的NetDevOps、嵌入式软件开发技术,甚至是设备底层硬件知识等等。一层层的技术门槛拦住了很大一部分有变革之心的企业,与此同时这也解释了为何目前大规模使用开放网络的场景仍然集中于技术大牛云集的互联网头部大厂之中,开放网络的技术红利未能惠及到更为广泛的客户群。

不仅仅是最终用户,上游制造商也在承接着开放网络抛出的新课题。各大硬件/芯片厂商需要从以往的面向芯片的设计转变为面向实际的业务应用,同时还需要增加额外的投入来实现SAI;除了数据平面外,厂商们还要解决很多与Platform相关的课题(如Platform Driver Development Framework,Open Network Linux Platform,私有API…等等),并且保证多芯片平台的实现一致性(因各厂家对SAI的理解程度不一致、接口的完成度也差别很大,导致不同特性在不同芯片平台上存在很多差异)。对于开源NOS厂商,开源NOS核心组件平均1~2年的迭代速度,远快于传统商用NOS的5~8年,这也是对生态内成员技术能力的巨大挑战。而我们熟知的传统大厂,在其成熟庞大的主营业务线之外会在开放网络领域真正投入多少呢?这点可能还需要细细探讨一番。

2、社区生态不完善,开源产品闻起来香,用起来苦不堪言

  • 几乎所有开源项目的“通病”:社区版软件功能集受限,稳定性差,文档有限,缺乏持续的技术支持,维护升级长路漫漫
  • 本质还是受限于技术能力,大部分尝试使用开源产品的用户其实只能拿社区版将就着,对于二次开发显得有心无力,使用体验大打折扣
  • 少数有能力修改的用户,不一定会把修改贡献到社区,大多数时候各自为政,如果算下重复造轮子的人力物力投入,业务交付效率不一定高

虽然在路标规划、项目管理、质量保证上,前文提及的SONiC/SAI开源项目和一般的开源项目相比已经有很大的改进,但仍存在以下无法忽视的问题:

项目规划的流程图

  • 企业个性化需求难以被接纳
  • 方案讨论和评审时间长
  • Pull request时间不可控

以上种种都导向了这样的结论:单凭社区开源项目支撑,行业用户的实际需求难以得到保障。

如何破局?

我们认为:在开放网络这一新型的交付模式下,行业需要的是一种新型的技术供应商,一个服务全生态的,专业、可靠的合作伙伴,并且基于标准的开放网络规范,为行业交付高可用的企业级产品和服务,弥补当下存在于开源项目和实际生产应用之间难以跨越的鸿沟。——而这,正是星融元正在做的。

开放网络的新型交付模式

星融元自成立之初便选定了SONiC,凭借着百人规模的SONiC开发团队在开放网络领域的深度参与和持续耕耘,已经围绕着我们的企业级SONiC发行版 – AsterNOS 构建了软硬芯一体的开放网络解决方案。

  • 在NOS层面,我们基于标准的Linux、SONiC和SAI做了大量面向生产网络的功能增强,并将多年积累的研发成果不断迭代,最终为用户提供的是一个功能强大,简单易用的NOS——AsterNOS,一套NOS支持从云到园区各类网络场景。

AsterNOS的基本能力

AsterNOS的性能图

  • 为了让AsterNOS真正在实际生产网络中发挥出极致性能,我们针对不同的场景为其适配了不同芯片能力,自主设计了全开放架构的硬件平台,推出了面向不同行业和应用的可编程交换产品和解决方案。

星融元硬件、AsterNOS及开放云网应用图

星融元Asterfusion一直是国内外主要开源社区的积极参与者和贡献者,期待与行业伙伴和用户共同探讨开放网络时代的无限可能。

  • 对于希望使用原生SONiC的企业用户,星融元提供全面的技术与咨询服务,帮助用户在选定的硬件平台上快速地完成开源、开放云网络系统的构建与部署;
  • 对于希望使用一站式解决方案的用户,星融元可以基于AsterNOS、可编程交换硬件平台、Asteria SDN云网控制器,以及易用的操作界面、全套的手册、完善的支持,提供Turn-key方式的交付与部署,帮助用户轻松享受新一代的云网络技术为IT系统带来的快速与便捷。

相关文章

替代IB交换机,如何选择数据中心100G低时延网络设备?


关注星融元


对比IB专网,基于以太网的 RDMA(或 RoCE)可能是目前性价比最高的方案了,我们唯一要解决的难题就是如何构建出一个无损以太网环境。CX-N系列超低时延交换机提供不输专用IB交换机的性能,可帮助构建承载RDMA应用的高性价比融合无损以太网。

2010年后,数据中心的业务类型逐渐聚焦为三种,分别是高性能计算业务(HPC),存储业务和一般业务(通用计算)。这三种业务,对于网络有着不同的诉求。

  • HPC业务:分布式计算集群,多节点进程间通信对于时延要求非常高
  • 存储业务:对通信可靠性的要求非常高,网络需要实现绝对的0丢包
  • 一般业务:规模巨大,要求网络低成本、易扩展

一般业务的需求,或许传统以太网还能勉强应付,但一旦面向的是高性能计算和存储业务,则实在难以为继。存储从硬盘驱动器(HDD)发展到固态驱动器(SSD)和存储类内存(SCMs),使得存储介质延迟缩短了 100 倍以上;算力也从通用CPU发展到各类支持并行计算的分布式GPU、专用AI芯片等等…反观网络却越发成为数据中心性能提升的瓶颈——通信时延在整个存储的E2E(端到端)时延中占比已经从10%跃迁到60%以上。

试想宝贵的存储资源有一半以上的时间是在等待通信空闲;昂贵的处理器,也有一半时间在等待通信同步…这滋味怎一个“酸爽”了得!

为什么如此虐心虐肺?——这可能需要从传统的TCP/IP协议说起了。
在典型的IP数据传输中,当网络流量以很高的速率交互时,发送和接收的数据处理性能会变得非常的低效,这其中主要有两个原因。

首先,处理时延高:TCP协议栈在收/发报文时,需要做多次上下文切换,每次切换需耗费5μs~10μs左右时延;多次数据拷贝,严重依赖CPU进行协议封装,协议栈本身就有数十微秒的固定时延。

其次,消耗CPU:TCP/IP还需主机CPU多次参与协议栈内存拷贝。网络规模越大,网络带宽越高, CPU在收发数据时的调度负担越大,导致CPU持续高负载。当网络带宽达到25G以上(满载),绝大多数服务器,至少50% CPU资源将不得不用来传输数据。

面对传统TCP/IP协议栈的低效,RDMA技术应运而生

这里我们不妨先回过头来看看数据中心网络流量传输的实际情形。

当前,越来越多的新兴业务应用建设于公有云之上。终端用户看似简单的一个访问行为,会在数据中心内部产生一系列连锁反应——数据信息在web应用服务器,大数据分析服务器,存储服务器、运营数据显示系统之间一通传递之后,最终才会将访问结果推送到终端,这就导致数据中心网络中的东西向流量剧增,甚至占据了80%的网络带宽,出现了大量的远程内存访问需求。

TCP/IP数据传输与远程直接内存访问的对比

与TCP/IP数据传输相比,远程直接内存访问(Remote Direct Memory Access, RDMA) 可以让数据直接从一台服务器的存储器传输到另一台服务器,无需中央处理器、CPU缓存的干预。这样不仅节省了大量CPU资源,同样也提高了系统吞吐量、降低了系统的网络通信延迟,尤其适合在大规模的并行计算机集群网络中应用。据测算,用 RDMA代替 TCP/IP 进行通信,使得网络化 SSD 存储的 I/O 速度提高了约 50 倍。

我们很容易注意到,应用程序执行RDMA读取/写入请求时的确是走了捷径,但是网络传输侧的压力却依旧存在。

云计算时代的数据中心不断抛出“既要又要还要”的复杂网络需求,有人曾经为此构建了类似这样的网络——

  • 低时延的IB(InfiniBand)网络:用于高性能的分布式计算网络
  • 无丢包的光纤通道(Fiber Channel)网:用于存储区域网络(SAN)
  • 低成本的以太网(Ethernet):用于一般的IP业务网

IB专网的架构图

各取所长,看起来很完美对不对?

非也!

IB专网和FC专网的性能很强,但是价格昂贵,是以太网的数倍。而且,两种专网需要专人运维,会带来更高的维护成本。

我们暂且拿IB专网细说一番:InfiniBand是一种封闭架构,交换机是特定厂家(目前主要是Mellanox)提供的专用产品。要构建这样的无损网络,服务器需要专用的IB网卡,专用的IB交换机,价格一般是普通网络设备的五到十倍,相应的还会带来配套设施成本增加(如线缆、模块、监控、电耗等);而且,IB是私有协议,无法做到与其他网络设备互通互访。另外IB 专网运维依赖原厂,故障定位困难,且解决问题时间较长,网络的升级也取决于Mellanox产品发布的进度,无法做到和业界统一。

存储网络(SAN)创建FC专网的情况也与之类似,尽管性能和扩展性都不错,但仍旧需要专用设备。

综合以上,无论从建设成本还是运维角度来看,上述方案都并非是一个最佳选择。

RDMA究竟需要怎样的网络?

RDMA各类网络技术的比较(via.ODCC智能网络无损技术白皮书 2021)

通过上表我们不难看出,基于以太网的 RDMA(RoCE)可能是目前性价比最高的方案了。这种情况下,我们唯一要解决的难题就是:如何构建出一个适合RDMA传输的以太网环境,让RDMA真正发挥出极致性能。

网络传输好比是快递运输。如果遇到了堵车,一定时间内运量就会大幅减少,运输效率大大降低,如果还不小心弄丢了包裹就需要重新发货,耗时更多。这就是我们常说的网络拥塞和丢包。

  • 一般来说,数据中心内部发生网络拥塞有如下技术原因:
  • 上下行非对称设计。网络设计通常采用非对称的方式,上下行链路带宽不一致(即,收敛比)。当交换机下联的服务器上行发包总速率超过上行链路总带宽时,上行口就会出现拥塞。
  • ECMP。数据中心多采用Fabric架构,并采用ECMP来构建多条等价负载均衡的链路,通过设置HASH因子并HASH选择一条链路来转发,该过程没有考虑所选链路本身是否有拥塞,所选择的链路流量饱和时,就会发生网络拥塞。
  • TCP Incast。当服务器向一组节点发起请求时,集群中的节点会同时收到该请求,并且几乎同时做出响应,从而产生了“微突发流”,如果交换机上连接服务器的出端口缓存不足就会造成拥塞。

丢包对网络数据传输性能的影响也是巨大,如下图所示[1] :0.1%的丢包率,将导致RDMA吞吐率急剧下降;2%的丢包率,会使得RDMA的吞吐率下降为0。

丢包对网络数据传输性能的影响

我们需要 “0丢包、低时延、高带宽”的无损以太网,但这绝非易事

  • 0丢包:会抑制链路带宽,导致低吞吐,同时会增加大流的传输时延;
  • 低时延:降低交换机队列排队,容易导致低吞吐;
  • 高带宽:保持链路高利用率,容易导致交换机的拥塞排队,导致小流的“高时延”。

云计算时代下,你需要怎样的数据中心基础网络设备?

从上述“0丢包、低时延、高带宽”三大要素出发,落到实际层面上便对承载云基础网络的交换机提出了以下具体要求。

1. 支持构建无损以太网的关键技术

  • 流量控制技术 – 用于解决发送端与接收端速率匹配,做到无丢包;
  • 拥塞控制技术 – 用于解决网络拥塞时对流量的速率控制问题,做到满吞吐与低时延
  • 流量调度技术 – 用于解决业务流量与网络链路的负载均衡问题,做到不同业务流量的服务质量保障。

星融元CX-N系列超低时延交换机,支持传输RoCE流量和面向数据中心的高级网络功能(如:PFC、ECN、ETS、DCBX),并通过PFC死锁预防机制、VLAG以及先进的拥塞控制算法等,帮助构建高可靠的无损以太网。
【演示视频在线观看:PFC、ECN…】

2. 设备本身具备尽可能低的转发时延

在设备转发时延方面,我们以采用业界领先的可编程超低时延交换芯片的星融元CX532P-N以太网交换机,对比Mellonox的SB7700 IB交换机进行了对比测试。
结论是:星融元超低时延以太网交换机的端到端性能,可全面超越IB交换机。

星融元CX-N系列与IB测试的数据对比图

3. 全盒式设备提供高密度接口,组网灵活易扩展

得益于高密度高性能端口的规格设计,我们可以从容地选用不同规格的CX-N系列云交换机搭建出Spine-Leaf架构*的两层网络,以实现大规模计算/存储集群的接入与承载。

Spine-Leaf架构相对传统三层组网架构,具有无阻塞转发、可扩展性强和网络可靠性高等优势。而且在这样的网络架构中,任何两台服务器之间的通信不超过三台交换机,进一步降低了网络流量的转发时延。

CX-N系列产品的规格表

4. 存储+高性能计算+一般业务三网合一,SDN智能运维

存储+高性能计算+一般业务三网合一,SDN智能运维

(此外值得一提的是,CX-N系列超低时延交换机搭载的是星融元为云计算时代设计开发的开放网络操作系统,它以标准的Linux、SONiC和SAI为内核,可与第三方云管平台无缝融合,并且提供Cisco风格的命令行;该交换机的硬件平台也全面遵从OCP所制定的开放性原则,涉及的技术标准和开发规范完全开放,确保用户拥有的是一个完全透明的开放系统。)


[1] Zhu, Y., H. Eran, D. Firestone, C. L. M. Guo, Y. Liron, J. Padhye, S. Raindel, M. H. Yahia and M. Zhang,Congestion Control for Large-Scale RDMA in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication (SIGCOMM ’15), London, United Kingdom, 2015.
[2]https://www.odcc.org.cn/download/p-1437654565852237825.html ODCC智能无损网络技术白皮书
[3]https://info.support.huawei.com/info-finder/encyclopedia/zh/%E6%99%BA%E8%83%BD%E6%97%A0%E6%8D%9F%E7%BD%91%E7%BB%9C.html
[4]https://blog.csdn.net/SDNLAB/article/details/88746460

相关文章

数据中心网络自动化运维面临的6大挑战


关注星融元


EMA(Enterprise Management Associates,企业管理协会)近期发表了《数据中心网络自动化的未来》的调查报告,在对359名来自企业、云供应商和网络服务提供商的IT网络从业者的访问中发现:48%的受访人所在公司所使用的数据中心网络自动化解决方案中仍有部分是依赖于手工收集数据的——云管理员必须手动查询单独的系统来寻找他们需要的数据,以便用网络自动化工具来做出变更。

其中更有超过86%的公司预计未来两年内,用于数据中心网络自动化的预算还将增加;但只有23%的受访者对他们接下来的自动化战略充满信心。

让我们从报告结果出发看看推动数据中心网络运维自动化的不同阶段中,各行业的资深从业者们都面临着哪些挑战?

规划和评估阶段

各系统工具之间的协同配合

根据调查,39%的技术团队最为关注网络自动化工具如何与其他工具和管理系统互动。这是因为网络基础设施和运营团队通常有多种工具来管理网络,包括数据中心网络自动化的多种工具。除此之外,其他团队例如存储、安全、应用和DevOps等都在用他们自己的工具集来管理数据中心运营的各个方面。网络团队必须要考虑他们的自动化工具如何与其他工具和团队交互。

预算和成本控制

许多企业(37%)表示,他们在规划预算和了解与数据中心网络自动化相关的成本方面有很大困难。EMA认为,自动化计划的复杂性是造成成本不明确的原因。大多数受访人表示,自己所在公司和组织既购买商业自动化工具,又有自己开放的自动化软件,很难预测要实施和维护这一系列工具所需的成本是多少。

部署阶段

基础网络设备的配置复杂低效

在推动实施数据中心网络自动化时,44%的组织在网络基础设施问题上大费周章。数据中心的网络设备和其他组件往往还有很多历史遗留问题,使得这项工作变得更加困难。例如,旧设备可能缺乏API,于是自动化团队不得不通过效率更低的的命令行脚本来配置设备。

更麻烦的是,生产网络中往往有多个版本的供应商的网络操作系统(NOS),而每个NOS版本在命令行(CLI)语法上可能有细微的差别,这就造成了更大的复杂性。不少网络工程师表示,他们有些设备上的API在应用范围、功能和质量等方面都非常局限。

与整体应用交付系统的集成

近一半(44%)的企业认为,难点在于将他们的自动化pipeline集成到整体应用服务交付系统中。这其实与规划阶段的第一个难点相呼应了。

使用阶段

数据权限和质量问题

在使用自动化时,有42%受访人认为数据权限和质量是主要问题。数据是网络自动化的命脉,工程师需要有关网络状态的数据(如设备指标和流量等)来了解需要执行哪些变更。他们还需要有关配置标准和安全策略的网络数据,依据这些信息去更改网络,并保证其稳定运行。但许多企业都在数据存储库上遇到了难题。

网络变化带来的不确定性

有40%的受访者担心网络变化会影响现网的应用行为和性能。正如来自一家价值500亿美元的咨询公司的一名网络架构师所言,”把新的网络配置一键推送给成千上万的盒子并不难,但要是这个配置是错误的,你就GG了” 。


附录:数据中心网络自动化运维相关工具

Ansible与AsterNOS SDK

Ansible – 红帽Redhat https://www.redhat.com/zh/technologies/management/ansible

在市面上各类网络自动化工具中,红帽公司的Ansible极具代表性。它能够将运营环境中大量的重复性工作以“Playbook”的方式进行自动化,从而为管理员降低工作负载,提升工作效率。Ansbile不需要被管理对象(服务器或网络设备)安装任何客户端,而是通过标准的SSH通道进行交互,所有需要被管理对象执行的命令和返回给服务器的结果都在这个标准通道中传递。Ansible的这种架构在很大程度上降低了自身的运维与管理复杂度。

AsterNOS – 星融元Asterfusion 

AsterNOS是一款基于SONiC的企业级发行版网络操作系统。

星融元(Asterfusion.com)为AsterNOS开发了符合Ansible标准的AsterPlaybook,通过AsterPlaybook,Ansible服务器能够快速、便捷地完成自动化运维。 同时,对于任何以容器模式运行在AsterNOS内部的第三方应用,也能完全融入到基于Ansible的DevOps环境中去。

面向NetDevOps的开发环境

更重要的是,AsterNOS还拥有一套面向NetDevOps的开发环境(AsterNOS SDK

运维工程师可以通过AsterNOS SDK所提供的REST API和/或System API自动化地、高效地运维网络,甚至开放自己的网络应用。

对应用系统访问情况的高效审计

例如:对应用系统访问情况的高效审计

在网络中,访问控制一般是通过ACL(Access Control List,访问控制列表)实现的。AsterNOS支持ACL功能,并且能够提供所有ACL被命中过的统计数据;AsterNOS SDK所提供的REST API中,包含对ACL各个字段和统计数据的访问接口,通过调用这些接口,即可直接获得ACL的这些信息用以分析。
AsterNOS支持ACL功能,并且能够提供所有ACL被命中过的统计数据

伪代码:

伪代码展示

相关文章

它,边缘计算/雾计算场景下的“迷你神器”?


关注星融元


在1U、半机架宽的整机空间中,它能提供与基于 x86 的服务器相似的处理能力,但成本、功耗和占用空间都要更低。

从边缘计算说起

假如“雾计算”这个说法对你有点陌生,那我们不如还是从热门点的“边缘计算”说起吧,其实他俩差不太多!

本质上说,边缘计算和云计算都是为了处理数据的计算问题而诞生的,只是两者实现的方式不同。谈及边缘计算的优势,就要讲到这个逃不过的”典中典”案例——无人驾驶。为了实现“无人驾驶”的目标,一台这样的汽车会有成百上千个传感器,每驾驶8个小时它们就会产生数十TB的数据。然而这些数据大多数并不重要,如果将其全量传输到云端无疑是对宝贵带宽的极大浪费。另外,无人驾驶要求系统必须对数据进行实时的反应,从道路安全的角度上来说低延时的重要性不言而喻。  

边缘计算则正好解决了这个问题:在靠近数据源头的位置对数据进行初步处理,经过计算后只把重要的计算结果传到云端,从而大大节约了带宽资源。同时还能利用边缘算力实时地分析和处理一部分关键数据,降低了延迟。

边缘计算

根据Gartner的报告[1],到 2029 年,全世界可能有多达 150 亿台物联网(IoT)设备连接到企业基础架构。这些设备都将生成大量原始运营数据,部署场景遍布各行各业,他们都需要进行转换、汇总和分析,以便于进行实时的网络运维管理以及后续的大数据分析。

雾计算是什么?

从字面意义解读,“雾”是比“云”更贴近地面的存在。对应的,夹在云数据中心和各类接入设备之间的就是网络的边缘层,即所谓的“雾”。

根据Cisco 的定义[2],“雾计算”主要使用边缘网络中的设备。这些设备可以是传统网络设备(比如早已部署在网络中的路由器,交换机,网关等等),也可以是专门部署的本地服务器。

而“边缘计算”侧重于“雾计算”中“局域网内处理能力”的理念,也就是说,它比“雾计算”离资产硬件更近一些。一个可能不甚精确的类比:如果说“边缘计算”是把算力下沉到类似于无人驾驶汽车这样的终端之上,那么“雾计算”就是在无人驾驶公路边构建的微型服务站。两者根据不同需求分别向云端上报信息。

相对于云端的集中式计算,使用这类分散在边缘的算力有着如下显著优势:

  • 低延迟:数据是在靠近数据源处理的,与遥远的云或数据中心相比,它们减少了来回发送数据所需的时间,可以实时或接近实时地进行分析。
  • 低带宽消耗:数据处理发生在边缘,也不需要高带宽来处理和发送数据。
  • 容错性高:暂时失去与云端的连接也没有问题,边缘本身具备算力,依旧可以继续工作。

让雾接上 “ 地气 ”

传统观念中,我们好像习惯把网络视为连接各项资源的纯粹的“管道”,相比于存储和计算的飞速发展,网络仿佛缺少了一种面向业务的想象力。

可如果把格局打开,让边缘网络叠上算力buff,我们能做什么呢?

OK,现在我们就以这款ET1600来看看,“雾”是如何“接地气”的…

星融元ET1600系列开放计算平台基于 Marvell OCTEON SoC(多核ARMv8 处理器)

与其说是边缘网络设备,其实我更愿意称其为“ARM架构的白盒服务器”

在1U、半机架宽的整机空间中,它能提供与基于 x86 的服务器相似的处理能力,但成本、功耗和占用空间都要更低。

  • 高性能智能业务处理单元:内置的网络专用协议处理器,可支持对采集流量进行灵活的数据包解析、报文编辑、协议处理等操作
  • 最多8 x 1GE copper接口、2 x 10GE SFP+接口和4 x 1GE SFP接口、1 USB 3.0
  • ET1600系列采用了业界领先的低功耗芯片组和先进的板级设计工艺;在保证芯片拥有高速处理性能的同时,其典型功耗仅为30W
  • 采用精简的硬件架构设计并使用成熟通用的处理芯片,整个系统通过严苛的环境试验,可稳定地工作在0~40℃环境中

如何把它耍起来呢?我们浅举几例实际应用。

比如,作为出口网络防火墙。

当发生链路故障时, ET1600可以直接连接到出口网络,因为它包含一组 Bypass 端口,可以直接绕过故障链路,而不会造成断点。运行网络操作系统后,ET1600可以支持安全流量控制功能。作为硬件防火墙的ET1600可以缓解软件防火墙带来的网络性能低下的问题,同时也具有成本低、功耗低、体积小等优点。

当ET1600搭载了用于深度业务处理的智能可视操作系统FusionNOS后…

1、网络可视化(NPB)前端

ET1600可进行流量聚合、分发、过滤、数据包预处理等功能,简化后端分析系统中的数据包处理,提高网络可视化系统的整体运行效率。

2. 安全态势感知前端

ET1600交换机可作为前端探针,根据IP、TCP、UDP等协议从采集的流量中提取元数据;它还可以为后端大数据系统提供Kafka格式的日志,用于完整的网络安全分析。

迷你神器的背后…更重要的是基于ARM的开放计算生态

FusionNOS-Framework是星融元Asterfusion为客户预装在像ET1600这样(以ARM为核心)的硬件平台上的底层基座操作系统。客户可以在其上直接开发上层应用程序来满足快速演进的市场需求。如果已经有现成的x86上应用软件,仅需简单编译便可迅速部署。

FusionNOS-Framework 为开放计算的开发者提供了一个开箱即用、灵活敏捷的基础开发环境,帮助开放计算的系统供应商快速、高效地完成所定义产品从概念验证、开放直到上线运维的完整过程。

除了ET1600,星融元还有性能更高的开放计算平台ET3000A系列,以及算网融合硬件平台X3-T系列。

相关文章

如何通过带内网络遥测(INT)技术实现精细实时的网络运维?


关注星融元


星融元通过提供AFF(Asteria Fabric Foresight)云网智能遥测系统搭配可编程云网交换机产品,构建了一套遵循INT技术的解决方案,能够在不影响设备的性能和功能的情况下,实现更高精度的网络数据监控;在转发业务流量的同时,将网络的即时性能、状态、参数收集并记录下来,在网络的出口发送给运营分析系统,用来精准分析物理网络的健康状况,让运维人员快速、精准地掌握全网设备的实时运行状态,帮助提升响应速度和运维效率。

带内网络遥测 VS. 传统网络运维模式

1、传统网络——基于CLI、SNMP机制的被动运维模式

在INT技术出现之前,数据中心多采用SNMP、NetFlow、sFlow之类的协议进行网络数据的采集监控。

1、SNMP(Simple Network Management Protocol,简单网络管理协议) :可以采集到网络设备的CPU、内存、日志等信息,但缺点是无法采集到网络数据流量,无法判断链路拥塞情况。这种Pull拉取式的模式已无法满足当今云数据中心需求。SNMP本质是工作在设备内部的一个 server,snmp 的 客户端要定期地到这个 server 里面去拿指定的数据。 server 是运行在设备的控制面,如果要通过控制面去采集一些数据面的信息的话,会导致设备的性能大打折扣。

2、NetFlow、sFlow:后续出现的高级采集协议,有NetFlow、sFlow等,可以实现网络数据流量的采样和推送,但其推送的是原始数据,不能直观地显示网络情况;而且是按照一定比例采集的,不能反映整个网络链路的流量全貌,所以不能预测流量和拥塞,sFlow通过设定的采样比采集端口数据,采样比越大,收集的数据量越少,采样比越小,收集的数据量越多越详细。缺点也很明显,采集的流量在端口流量比较小的情况下,反映网络状况不是很准确,尤其是在端口各种流量比较丰富的情况下,就可能会漏掉部分流量。

  • 通过拉(pull)模式来获取设备的监控数据,故障定位缓慢;
  • 采集精度粗略,只能做到分钟级别的采集,监控到的网络节点数据并不准确;
  • 缺乏对设备队列状态信息的查询,故障定位不详细

这种被动响应的网络监控方式,故障定位迟缓、粗略,使得管理效率越来越低,已无法跟上时代的步伐,满足不了数据中心云网络运维需求。

2. 带内网络遥测(INT,In-band Network Telemetry)——更实时、全面、精细的运维模式

INT是通过数据面业务进行网络状况的收集、传送、上传的。通过名称我们可以看出两个技术关键点。“带内”意味着可以从传输网络内部收集信息,而不是通过额外搭建的业务网以及实际端口收集;“遥测”,表现在测量网络的数据并且远程上报的特点。对比上述传统技术,INT的特点优势一目了然:

  • INT采用主动推(push)模式:制定完规则后,网络设备主动推送运维人员所需要的数据。
  • INT无需控制层面干预:采集过程无需控制层面干预,减轻设备负担。
  • INT可实现纳秒级时间戳:INT协议本身支持纳秒级时间戳从而采集的数据精度高。
  • INT实现快速响应:在数据平面芯片内部进行采集,响应时间非常快。

目前,INT已成为了当代大型数据中心运营的关键组成部分,能实现整网的流量可视化,通过对网络设备的数据进行远程高速采集和监控,提供更实时、更全面和更精细的网络监管能力,从而帮助加速网络故障排除、预测网络容量增长和评估网络性能的潜力。

INT如何实现?

1、INT的头部报文格式

正确类型的遥测数据使网络运营商能够主动解决网络盲点并保持其业务系统高效运行。所以,我们不妨先了解下INT的头部报文格式。

INT的头部报文格式

  • Ingress-port(9bit):报文入端口号
  • Egress-port(9bit): 报文出端口号
  • Queue_id(5bit):报文出端口队列号
  • Queue_occupany(19bit):队列占用率
  • Timestamp(32bit): 报文出端口时间戳

INT的头部报文格式

  • D(1bit):指原始报文是否在本交换机被Drop
  • Q(1bit):指原始报文出队列上是否存在拥塞
  • F(1bit):指INT采集是否是通过ACL匹配识别
  • Seq_number(32bit):该报文计数,报文发送INT数据的个数
  • Timestamp(32bit): 报文入端口时间戳

2、INT数据包的传递

知悉了头部数据包内容,下面我们看下带内网络遥测架构数据包的传递过程。

INT数据包的传递

在带内网络遥测架构中,交换设备转发处理携带遥测指令(Telemetry instructions)的数据包。当遥测数据包经过该设备时,这些遥测指令告诉具备网络遥测功能的网络设备应该收集并写入何种网络状态信息。

一般来说,一个INT过程涉及3个功能节点:

  • 交换机-1充当INT source,负责指出需要收集信息的流量和要收集的信息
  • 交换机-2作为支持INT遥测的设备
  • 交换机-3作为终点负责将收集到的信息上报给监控设备或者系统

通过上述信息,我们不难发现:INT可以精准地描述一个报文在交换机里的运作情况。这是传统的遥测技术比如Snmp,sFlow所无法实现的,它体现的是网络在转发业务那一瞬间最真实的情况,在当今数据中心呈现“高速率、大规模、多接入、不可预期”的特点下,INT技术无疑更加满足运维人员的实际需求。

星融元基于可编程交换芯片的INT方案

星融元通过提供AFF(Asteria Fabric Foresight)云网智能遥测系统 搭配可编程云网交换机产品,构建了一套遵循INT技术的解决方案,能够在不影响设备的性能和功能的情况下,实现更高精度的网络数据监控;在转发业务流量的同时,将网络的即时性能、状态、参数收集并记录下来,在网络的出口发送给运营分析系统,用来精准分析物理网络的健康状况,让运维人员快速、精准地掌握全网设备的实时运行状态,帮助提升响应速度和运维效率。


SSL加密原理

  1. 精细运维:纳秒级别的监控粒度、一针见血反映网络状况。
  2. 快速定位:远程预警方式快速告知客户详细网络故障信息。
  3. 释放资源:采用订阅上报机制,通过设备的交换芯片转发INT流量,不占用设备CPU开销

星融元SSL/TLS解密:高性能计算模块加持,解密监控得心应手


关注星融元


采用模块化设计,提供可选的SSL解密解决方案(NSA解密模块),从而有效的解决了行业或企业用户在访问HTTPS情况下的网络可视化问题。NF2000系列高级业务处理引擎提供基于硬件的加解密引擎,单引擎可以支持高达29K TPS处理能力以及10~20Gbps的流量解密能力。

为什么需要SSL解密?

SSL/TLS是一个安全通信框架,上面可以承载Http协议或者SMTP/POP3协议等。Https经由Http进行通信,但利用SSL/TLS来加密数据包。当前网络环境下,Https的业务已经得到了越来越广泛的应用。

来自Chrome所统计到的受Https保护的流量

如图所示是来自Chrome所统计到的受Https保护的流量,Https已经成为大势所趋。然而其中隐含的安全问题也日益突出——随着SSL/TLS协议更多地应用在政务信息安全、支付体系加密、企业网站稳定、API接口与APP之间,很多隐藏在Https中的不法行为和安全威胁无法被发现,这使得监管变得更加困难。

业务不可视,埋下安全隐患

某些安全设备可能无法解密和检测SSL/TLS流量,成为企业的安全盲点。导致这些加密流量直接游走在整个网络中,无法被监视到。

以防火墙为例,若客户端与服务器之间使用的是Https,那么任何数据都已经变为加密数据,防火墙上的相关的安全内容的功能可能都不会生效。例如,反病毒功能主要是依靠识别支持的协议,从流量中提取特征在病毒库中进行特征匹配之后,进行相关的安全内容的检查;以及某些IPS生效的原理也与之类似,是靠收集来的巨大的签名特征库去对相关的流量进行审查。所以若数据被SSL层加密,像上述这类安全功能便都形同虚设了。

目前,网络中大约有50%的安全攻击会通过SSL通道进行,很多传统的安全设备都将会面临严重的挑战——只有将这些加密流量解析出来才能让安全设备很好的防御,SSL解密方案的重要性可见一斑。

具体到技术实现的角度上,我们接下来详细看看SSL加密和解密之间的联系。

SSL加密原理

SSL加密原理图

SSL通过握手过程在客户端和服务器之间协商会话参数,并建立会话。会话包含的主要参数有会话ID、双方的证书、加密套件(密钥协商算法、对称加密算法和摘要算法等)以及主密钥(master secret)。通过SSL会话传输的数据,都将采用该会话的预主密钥生成的主密钥和加密套件进行加密、计算MAC等处理。

握手过程如下:

  1. 客户端给服务器端发送协议版本、客户端支持的加密算法、一个随机数。
  2. 服务器端选择加密算法,并向客户端发送一个服务器数字证书和一个随机数。
  3. 客户端使用数字证书中的公钥,将随机数加密发送给服务器。
  4. 服务器使用私钥对随机数解密。
  5. 服务器端和客户端通过事先协商好的加密算法,对这三个随机数进行加密生成“主秘钥“即对称加密的秘钥,用于接下来整个对话过程的加密。

如何针对SSL协商进行解密

对应上述SSL协商过程,解密原理如图所示:

SSL协商过程
SSL协商过程

首先是要提取到对应位置的数据。比方说在图中所述的协商过程中若能提取到客户端随机数、服务器端的随机数、加密的预主密钥的信息,提取到这三个信息后,如果带有服务器的私钥的话,这时候就可以解析出预主密钥了。

有了预主密钥、客户端随机数、服务器端随机数,我们就可以计算出整个通信过程中所用到的主密钥。

有了主密钥之后,我们便可以对整个SSL加密协商过程进行操作。

星融元智能网络可视交换机,内置高性能计算模块支撑SSL解密,实现网络安全流量解密监控

星融元的智能网络可视交换机系列设备,可将内置的高性能计算模块,定义为NSA模块。NSA模块有多种部署模式,可实现对流量的多种负载均衡处理从而给予后端分析工具定制化的流量。NSA在能够获取到服务器端CA证书的情况下,达到可以解密客户端和服务器端的通信过程,完成解密监控的需要。

全流量解密监控示意图

1、灵活的部署模式,满足多种场景需求

提供旁路解密部署方案和串接解密部署方案,支持重建解密后的数据流,满足金融、政务、校园等多种实际应用场景。旁路部署模式下,不会对原有通信过程造成任何影响。

2、可进行SSL卸载加速

提供高度稳定、安全、可靠的硬件和软件解决方案。将关键功能(安全、压缩、虚拟化、随机数生成)组合到高性能、低功耗芯片中。

3、性能强大,具备多样功能

吞吐量可达到数万级,高性能处理单元灵活应对大流量场景,提供2Gbps~100Gbps的单机解密监控方案,灵活进行解密后TCP端口设置,并能计算TCP序列并且修复TCP/IP效验和。最新的安全算法支持,满足下一代应用程序的安全加速需求

星融元NF系列智能可视交换机采用模块化设计,提供可选的SSL解密解决方案(NSA解密模块),从而有效的解决了行业或企业用户在访问HTTPS情况下的网络可视化问题。NF2000系列高级业务处理引擎提供基于硬件的加解密引擎,单引擎可以支持高达29K TPS处理能力以及10~20Gbps的流量解密能力。

相关文章

全栈可编程的P4交换机,星融元诠释开放网络的“豪华铁三角”


关注星融元


P4可编程交换机用来做什么?

  • 简化网络,降低复杂度,扩展表项空间
  • 快速增加新的网络特性——快速开发和验证新协议、隧道或封装处理(如DCE、私有云VXLAN、 ETH+MPLS+PW+ETH+PPPoE+IP、两层VXLAN等)/ NFV加速(LB、DDoS、NAT等)/ 新的拥塞控制算法
  • 帮助实现INT带内网络遥测,从而追溯每个数据包的转发过程——网络包走了哪条路径?依据哪条规则选择的这条路径?在每一跳的节点逗留了多长时间?有哪些其他的流在共享这条物理链路?

传统的网络交换机 ——封闭黑盒,不可编程

  • 处理协议固定
  • 表项空间写死
  • 业务流程固化

传统的交换芯片

设备所支持的协议,表项空间和转发逻辑在出厂时就已经固定了,当网络中有新的协议、隧道封装和转发逻辑,现有设备无法做到灵活支持,用户便只能选择更换设备。

基于SDN的尝试,有限的开放网络——Openflow带来的控制平面可编程

  • 控制平面可编程
  • 数据平面不可编程

OpenFlow 的SDN控制器相当于SDN的“大脑”,由它通过OpenFlow协议指导Openflow交换机设备的转发。不过这里的表不再是普通的IP五元组,而是整合了网络中各个层次的网络配置信息,由一些关键字和执行动作组成的灵活规则。

OpenFlow实现原理
OpenFlow实现原理

OpenFlow实现原理:OpenFlow流表的每个流表项都由匹配域(Match Fields)、处理指令(Instructions)等部分组成。流表项中最为重要的部分就是匹配域和指令,当OpenFlow交换机收到一个数据包,将包头解析后与流表中流表项的匹配域进行匹配,匹配成功则执行指令。

所以通过OpenFlow SDN控制器给设备下发流表,我们可以修改和变更网络定义和实时策略了。

但设备所支持的协议和字段仍然是在出厂时已经确定,我们只能根据现有的协议来定义流表项,无法支持新的协议。

对于不断更新变化的应用场景和协议类型来说,Openflow并没有彻底解决特定用户的业务创新需求。反倒是因为匹配字段增多(随着OpenFlow的升级迭代,所支持解析的字段从12增加到了45个)让匹配效率和表项空间占用的缺陷暴露得更加明显。

星融元的“全栈可编程”——将网络可编程进行到底,让网络真正服务于业务

P4硬转发

1、可编程线速硬转发:P4交换芯片——打开了封闭的数据平面

可编程线速硬转发:P4交换芯片——打开了封闭的数据平面

全端口、全流量、全线速转发可编程交换芯片加速新业务验证、部署和上线,与传统ASIC相比,周期缩短可达95%

  • 资源可编程
  • 转发逻辑可编程
  • 协议解析可编程

P4可编程芯片可以用来做什么?

  1. 简化网络,降低复杂度,扩展表项空间

  2. 快速增加新的网络特性——快速开发和验证新协议、隧道或封装处理(如DCE、私有云VXLAN、ETH+MPLS+PW+ETH+PPPoE+IP、两层VXLAN等)/ NFV加速(LB、DDoS、NAT等)/ 新的拥塞控制算法

  3. 帮助实现INT带内网络遥测,从而追溯每个数据包的转发过程——网络包走了哪条路径?依据哪条规则选择的这条路径?在每一跳的节点逗留了多长时间?有哪些其他的流在共享这条物理链路?

2、可编程控制面:基于SONiC的网络操作系统+x86通用CPU的云原生环境

  • 标准Linux+容器架构的开放环境
  • 各类网络控制协议(控制面功能)容器化,如需增加新的控制功能模块,只需增加新的容器
  • 可集成第三方NetDevOps运维工具
  • 向上提供Rest API ,可无缝集成控制器和Openstack、Vmware等云管平台

基于SONiC的网络操作系统+x86通用CPU的云原生环境

3、VPP&DPDK可编程软转发:高性能计算单元(DPU模块)+容器化部署环境

高性能计算单元(DPU模块)+容器化部署环境

  • 承载各种虚拟网络功能,打造开放的网络生态
  • 多核高性能处理器+大容量内存:可用于千万级会话状态处理、下游流量缓存、流量加解密等
  • 易移植的开放网络开发环境:通过所提供的底层基座操作系统,客户可以不用考虑底层支撑框架,直接开发上层应用程序,原先x86上运行的各种软件功能仅需要简单的重新编译就可以加载运行

“铁三角”豪华套餐:可编程、全开放、高性能的星融元P4可编程交换机

可编程、全开放、高性能的星融元P4可编程交换机

  • 可编程ASIC:让网络适应业务,而非业务适应网络,快速定制
  • 开放标准:业界通用标准架构,无锁定
  • X86控制 & ARM业务处理:一次开发,自由迁移,投资保护,大幅提升算力
  • 敏捷易用:简单易用的开发环境,加速产品迭代节奏
  • 标准内核:标准的Linux/ONIE/SONiC/P4Runtime,无锁定
  • 无缝运维:完全重用既有的运维团队、知识栈、工具

星融元全线可编程产品线——面向未来网络,承载创新需求

应用一:云数据中心/超融合私有云的网络部署

云数据中心/超融合私有云的网络部署

应用二:打造开放的网络生态

打造开放的网络生态

基于SONiC的容器能力拓展,自由扩展控制面能力,轻松实现NetDevOps

  • 基于容器架构的网络操作系统支持自开发/第三方应用
  • 全面支持DevOps,支持运行在星融云网络上的自开发/第三方应用自动化运维工具

算网融合,基于高性能计算单元可部署各种虚拟化网络功能

  • 可编程交换芯片:基本网络功能,自动化流量牵引和编排
  • 高性能业务处理单元:提供标准的容器环境,可以加载各种网络应用,打造网络领域的“Android”生态
  1. Stateful LB、IPSec、SSL、应用层安全网关、vFW、vIPS、vWAF…
  2. DPI、Netflow、IDS、NPM、APM、 元数据提取、流量捕获…

应用三:定制化的数据面重构

  • 基于状态的负载均衡功能的卸载,为数据中心服务器减负
  • 基于业务的精准化、实时化、可视化的带内网络遥测技术
  • 无穷大的微浪涌吸收能力,构建零丢包的云网络
  • 5G UPF……

应用四:DPU网卡卸载服务器负载

  • 卸载OVS同时集成第三方应用
  • SSL解密卸载加速
  • ……

相关文章

DPU架构高性能智能网卡(SmartNIC)- 星融元


关注星融元


智能网卡 (SmartNIC) 技术的价值

智能网卡SmartNIC 技术的核心目的就是以比普通CPU低得多的成本实现对各种虚拟化功能的支持。

后摩尔时代,CPU算力增长无法跟上数据中心网络传输的增长速度,而且在高带宽和更加新型的传输体系下,网络功能处理同时也越发复杂。VXLAN等Overlay协议,以及OpenFlow、Open vSwitch(OVS)等虚拟交换技术的引入,使得基于服务器的网络数据平面的复杂性急剧增加;网络接口带宽的增加意味着在软件中执行这些功能会给CPU资源造成难以承受的负载,留给运行应用程序的CPU资源很少或根本没有。

传统网卡固定功能的流量处理功能无法适应SDN、云和虚拟化部署的需要,市场对网络功能卸载到可编程硬件的需求愈发急迫

智能网卡的功能价值是:在服务器侧引入智能网卡,可以将网络、存储、操作系统中不适合CPU处理的高性能数据处理功能卸载到硬件执行,提升数据处理能力,释放CPU算力。(例如:OVS卸载/VXLAN终结、TCP卸载、GRE/GTP等隧道封装/解封装、可靠UDP、5G UPF加速等;安全加速如IPSec、SSL、XDP/eBPF、vFW/vLB/vNAT、DPI、DdoS防御等;存储加速如NVMe-oF(TCP)、压缩/解压缩等。)

Helium DPU智能网卡的照片

智能网卡(SmartNIC)在公有云数据中心/IDC,超算、高性能存储等场景的应用

目前来说最广泛应用的行业是公有云服务商,因为其本身具有自研能力,通过大规模部署智能网卡,降低CPU开销,提升网络性能;另外在金融行业、以及有AI、超算集群,高性能存储需求的行业,通过提升服务器网络转发性能,降低网络时延。

网络功能卸载

不少采用混合SDN方案的数据中心IDC,例如中国移动IT云和网络云,面向不同业务提供虚拟机或裸机部署能力,面向虚拟化场景,引入智能网卡突破提升vSwitch转发性能和数据处理能力;面向裸机场景,引入智能网卡构建弹性裸金属服务。

存储功能卸载

存储功能卸载包括云盘挂载卸载和高性能存储协议卸载,前者通过支持virtio-blk,提高存储访问灵活性和安全性;后者面向边缘计算视频加速、CDN等场景,进一步提升存储协议处理性能,构建端到端低时延网络。

运维能力卸载

当前硬件交换机及vSwitch实现仍存在限制,采样性能及精细化程度受限。引入智能网卡,将vSwitch采样点下沉到服务器智能网卡,实现真正实现业务端到端网络可视化,降低CPU消耗。

传统的智能网卡(SmartNIC)和DPU架构的智能网卡(DPU网卡)区别

HeliumDPU网卡的硬件优势

1. 传统的网卡基于ASIC硬件架构实现,仅实现数据链路层和物理层的功能,由端系统CPU负责处理网络协议栈中更高层的逻辑,CPU按照网络协议栈中传输层、路由层的逻辑,负责数据包的封装和解封;网卡则负责更底层的数据链路层帧的封装和解封,以及物理层电气信号的相应处理。

2. 智能网卡在硬件架构的实现上主要有ASIC、 FPGA、SoC、DPU等架构,其中ASIC、 FPGA主要是实现转发面的卸载;而SoC、DPU可以实现控制面和转发面的全卸载。DPU(Data Processing Unit)是以数据为中心构造的专用处理器,采用软件定义技术路线支撑基础设施层资源虚拟化,支持存储、安全、服务质量管理等基础设施层服务。DPU智能网卡是一个具有加速能力并可卸载服务器(或存储服务器) CPU 功能的网络适配器。DPU 智能网卡使用其板载的处理器,来执行任何加密/解密、防火墙、TCP/IP 和HTTP 网络处理不同任务的组合,非常适合于高流量的网络服务器。

3. 星融元Asterfusion自主研发的Helium DPU卡是基于高性能DPU芯片设计,符合PCle及以太网协议,提供PCle x 16 Gen4.0通道接口并支持高达100Gbps多功能业务处理能力。此外还提供了底层基座操作系统FusionNOS-Framework和开发套件;客户可以此为基础,直接开发上层应用程序,从而加速应用的开发和移植进度。

Helium DPU智能网卡的照片

Helium DPU智能网卡:网络加速、安全加速、存储加速

HeliumDPU智能网卡的架构图

Android生态系统与网络开放生态的对比图

相关文章

解开能力封印,白盒交换机上的网络应用开发如此简单


关注星融元


在云网络的新需求引领之下,“开放式交换机”(白盒交换机/白牌交换机)开始崭露头角——白盒交换机抛弃了传统网络”黑盒”设备的封闭锁定,可以支持各类第三方操作系统和软件在其上运行,而SONiC经过了近十年的市场反复淘洗,如今几乎成为了开源网络操作系统的首选 。

当网络同计算和存储一样,用成本更加可控的标准化硬件和高度软件定义的方式解除了曾经被“封印”住的能力,网络也会像存储和计算一样与云融为一体,为云中的产品业务的高效率开发和运营注入强劲动力,承载更多创新可能。

走向开放灵活,白盒交换机承载无尽可能

尽管软件定义网络 (SDN)、网络功能虚拟化 (NFV) 和SD-WAN等技术概念的产生、发展与实践,已经使得网络更加智能,但是网络设备若仍停留在传统的封闭锁定的“黑盒”时代,依旧是难以满足云计算时代下云管理平台对网络提出的更高需求(如开放接口、软件定义、模块化构建、快速迭代等等)。如此一来,本应是云计算三大基础设施之一的“云网络”,却游离在云的统一管理之外,成为了限制云计算自身发展的瓶颈。

在新需求引领之下,“开放式交换机”(白盒交换机)开始崭露头角——白盒交换机抛弃了传统网络”黑盒”设备的封闭锁定,可以支持各类第三方操作系统和软件在其上运行,而SONiC经过了近十年的市场反复淘洗,如今几乎成为了开源网络操作系统的首选。

SONiC(Software for Open Networking in the Cloud)和与其伴生的SAI(交换抽象接口)是由微软(Microsoft)在近年来主导的两个在开放网络领域的开源项目。类似于今天的Windows/Linux操作系统能够运行在任何第三方基于标准设计的PC/Server硬件之上,SONiC/SAI网络软件系统能够运行在任何符合标准的开放式交换机之上,允许用户在网络设备上进行标准化的网络功能应用开发。就像在服务器上可以基于标准Linux的平台和工具来进行开发一样,网络也更加变得灵活,从而能够快速地满足生产场景的功能需求。

我们可以想见到这样的未来:当网络同计算和存储一样,用成本更加可控的标准化硬件和高度软件定义的方式解除了曾经被“封印”住的能力,网络也会像存储和计算一样与云融为一体,为云中的产品业务的高效率开发和运营注入强劲动力,承载更多创新可能。

白盒交换机的能力图

开放的云网络,这么近又那么远

开放网络掀起的白盒化浪潮已经到来。 据Gartner 2021年调查显示,SONiC 已经大规模部署在包括AT&T、 Microsoft Azure、Google、Facebook(Meta)、阿里、腾讯等在内的运营商和大型互联网企业数据中心生产场景。从 2020 年到 2021 年,Gartner 客户对 SONiC 的兴趣同比增长 87%。由于这种快速扩大的客户兴趣和商业生态系统,SONiC 很有可能在未来三到六年得到更广泛的部署。 正是因为顺应了云计算、软件定义、开源开放的趋势,到2020年,全球开放式(白盒)交换机的出货量已经占到了总量的约三成。

硬件白盒化对比图

当然,无论从数量还是体量上来看,目前SONiC社区内的玩家绝大多数都是最近这些年爆炸式增长的巨型互联网/云计算公司。正因为这类公司自身的业务都依托于云计算或正在往该方向转型,在构建云计算平台时是他们率先发现了传统网络的局限性,而他们恰恰又具备强大的技术能力,因此就直接绕过传统网络设备供应商,按照自己的需求对网络进行改造,甚至是自研。

SONiC生态合作伙伴的截图

图片来自:https://sonic-net.github.io/SONiC/

反观那些对云计算、云网络有着同样旺盛需求的传统企业用户,因为不具备与上述“大厂”同等的技术能力,所以仍然被禁锢在传统网络技术的体系中,无法享受开源开放的新一代云网络技术给产业发展带来的红利。 说到这里,你是否觉得开放网络是个只有云巨头才能“玩得转”的游戏?对于一般传统企业用户而言,通向未来的开放网络的大门难道就这样关上了?

星融元AsterNOS SDK:帮助云的使用者享受开放网络的红利

星融元数据技术有限公司是国内最早加入SONiC社区的成员之一,相比于社区内各大互联网/云计算公司巨头,星融元在开放网络领域的研究和投入则更为聚焦。 星融元专注于提供基于SONiC的网络操作系统(AsterNOS)的SDK能力和整机交付能力——通过为SONiC增加对不同交换芯片、对控制面协议扩展上的支持等等,让我们的用户和合作伙伴像Android和iOS开发APP一样简单地实现交换机上的应用,将网络能力真正开放出来,帮助使用者从各个方面享受开放网络的红利。

AsterNOS的能力图

型号为CX532P-N产品图片型号为CX312P-48Y-N的产品图片

基础网络功能即服务(NFaaS)

——供使用者按需调用,快速构建开放网络应用

AsterNOS将已经支持的各种基础网络功能(例如L2/L3转发、路由管理、ACL等)封装成了“服务”

AsterNOS将已经支持的各种基础网络功能(例如L2/L3转发、路由管理、ACL等)封装成了“服务”

高度软件定义的网络功能

——提供REST API和System API,助力高效的运维开发

提供REST API和System API,助力高效的运维开发

  • Rest API:满足对AsterNOS网络能力的配置和控制需求(运行状态查询、网络配置的增加删除调整)
  • System API:深度调用AsterNOS基础网络能力,完成高级网络开发

标准化的开发环境

——简化开发难度,为NetDevOps提供支持

为NetDevOps提供支持

无缝融合OpenStack / K8s云

——让云中的应用也能够轻松、快捷地调用基于AsterNOS的开放网络能力

无缝融合OpenStack / K8s云

Aster-Neutron-Plugin和Aster-CNI是AsterNOS SDK的重要组成部分,它们分别运行在OpenStack和Kubernetes环境中,接管云操作系统对网络标准接口的软件调用,并将这样的调用转化为对运行着AsterNOS的网络的操作与控制。

拥抱丰富多彩的开源社区示意图

  • 整体软件架构的开放彻底打开传统网络操作系统的封闭性
  • 基础网络功能的开放彻底摒弃传统网络操作系统的黑盒化
  • 面向开源生态的开放全面拥抱丰富多彩的开源社区

相关文章

对星融元产品感兴趣?

立即联系!

返回顶部

© 星融元数据技术(苏州)有限公司 苏ICP备17070048号-2