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

星融元深度合作SONiC社区,“一站式”SONiC网络解决方案赋能千行百业

更多相关内容


近日,星融元(asterfusion.com)正式加入成为Linux基金会下的SONiC社区会员单位成员,未来星融元将继续与SONiC 社区深度合作,为人工智能、云、企业数据中心和园区接入打造一个开放、可扩展和可编程的网络架构。

SONiC社区会员单位成员

星融元是中国最早参与SONiC社区并积极向社区贡献缺陷修复和软件特性代码的公司之一,自成立之初一直致力于开发基于 SONiC 的企业级操作系统。作为行业先驱,星融元已经在数据中心和二层接入交换机上实施了企业级 SONiC NOS——AsterNOS

几年来,随着研发队伍不断发展壮大,AsterNOS经过持续更新迭代,其软件特性和芯片支持不断完善扩充,在稳定性和易用性方面也实现了极大的改进,可同时部署于数据中心和园区网络,目前完成了数万个现场商业部署的拷贝。

AsterNOS的能力

SONiC是什么?

SONiC全称Software for Open Networking in the Cloud(云中开放网络软件),是一种基于 Linux 的开源网络操作系统 (NOS),可在多个供应商和 ASIC 的交换机上运行。全新理念、开放的架构让SONiC/SAI焕发出蓬勃的生命力,快速获得了云计算时代的全球用户、厂商的青睐,成为云计算时代构建网络软件系统的首选。

据Gartener报告,到 2025 年,全球40%运营超过 200 台交换机的大型数据中心网络的企业将在生产环境中部署SONiC,SONiC有望像Linux服务器操作系统一样,成为硬件供应商支持的标准化网络操作系统。

星融元的系列化SONiC开放网络产品

区别社区其他参与单位,星融元所提供的并非是纯白盒硬件或基于SONiC的纯软件产品,而是软硬一体的一站式开放网络解决方案,系列化的产品和方案让全球更为广大的数据中心和园区网络用户都能平等、便利地享用到开放网络所带来的技术进步。

AsterNOS已稳定支持从 1G 到 400G 的各种端口容量和多芯片平台,适用于公有云、私有云、园区接入、边界智能网关等多种应用场景。

星融元为云计算的各关键应用场景构建全栈网络

返回资源中心

DPDK和VPP是什么?

更多相关内容


在网络成为人们通信方式基础的今天,性能、吞吐量和延迟对于无线核心和接入、有线基础设施、路由器、负载平衡器、防火墙、视频流、VoIP 等应用越来越重要。DPDK 支持极快的数据包处理,使电信行业将移动网络骨干和语音等对性能敏感的应用迁移到云中成为可能。

DPDK是什么?

DPDK 是数据平面开发工具包(Data Plane Development Kit),DPDK是一款高性能的网络驱动组件,旨在为数据面应用程序提供一个简单方便的,完整的,快速的数据包处理解决方案。DPDK由各种库组成,用于加速在各种 CPU 架构上运行的数据包处理工作负载。主要技术有用户态、轮询取代中断、零拷贝、网卡RSS、访存DirectIO等。

DPDK 于 2010 年由英特尔公司创建,并以许可开放源代码的方式提供。2013 年,6WIND 在 DPDK.org 上建立了开源社区,促进了项目的持续扩展。从那时起,该社区的贡献者、补丁和贡献组织的数量一直在持续增长,目前已完成了 5 个主要版本,包括来自 25 个不同组织的 160 多人的贡献。DPDK 现在支持所有主流 CPU 架构和多个供应商的网卡,非常适合需要跨平台移植的应用程序。

DPDK的基本原理

DPDK的基本原理

随着云业务相关网络需求的飙升,Linux+x86单机网络IO瓶颈愈发明显,问题根源来自于网络业务的运行对CPU资源消耗占用,主流的解决方案都是旁路网卡IO,绕过内核直接在用户态收发包来解决内核的瓶颈。
如上图所示,区别于左侧传统的收发报文方式,DPDK的方式基于UIO(Userspace I/O)旁路数据,数据从网卡-DPDK轮询模式–DPDK基础库-业务,使之易于开发和维护,灵活性好,发生故障不影响内核运行。

VPP是什么?

VPP 平台是一个可扩展的框架,可提供开箱即用的高质量交换机/路由器功能。它是思科矢量数据包处理(VPP,Vector Packet Processing)技术的开源版本:一种可在商用 CPU 上运行的高性能数据包处理堆栈。

VPP 的优势在于其高性能、成熟的技术、模块化和灵活性以及丰富的功能集。VPP 技术基于经过验证的技术,该技术已帮助思科交付了超过 10 亿美元的产品。

VPP 平台是一个可扩展的框架

模块化、灵活、可扩展

VPP 平台建立在 “数据包处理图” 的基础上。这种模块化方法意味着任何人都可以 “插入 “新的图形节点。这使得可扩展性变得相当简单,同时也意味着插件可以针对特定目的进行定制。

自定义数据包处理图

自定义数据包处理图

插件如何发挥作用?运行时,VPP 平台从 RX 环中抓取所有可用数据包,形成数据包向量。对整个数据包矢量逐节点(包括插件)应用数据包处理图。图节点小而模块化。图形节点是松散耦合的。这使得引入新的图形节点变得容易。这也使得重新连接现有图形节点变得相对容易。

星融元Helium DPU 智能网卡对DPDK/VPP的支持

Helium DPU智能网卡所提供的软件开发套件(FusionNOS-Framework)包括三大部分,目前软件和场景都已开源。
开源地址:https://github.com/asterfusion/Helium_DPU

  • 标准的Linux内核,方便开发者安装应用相关的各种依赖,并且有大量可选的软件源。
  • 容器化的架构。我们可以打包运行环境和依赖到一个可移植的镜像中,实现轻量的资源隔离,做到一次编译,随处运行,并且每个实例的初始状态皆是一致的。
  • 额外提供的DPDK和VPP开发套件,加速软件快速移植,用户也可以很方便去拓展自己的应用。

Helium DPU智能网卡所提供的软件开发套件

产品链接:Helium DPU智能网卡:网络加速、安全加速、存储加速
更多资讯:讲座精华 | 深度分享星融元开源DPU技术与应用场景


本文参考:
https://wiki.fd.io/view/VPP/What_is_VPP%3F
https://cloud.tencent.com/developer/article/1198333
https://www.dpdk.org/about/

返回资源中心

真机测评:全开放架构400G交换机,超低时延以太网性价比之选!

更多相关内容


云计算、人工智能和 5G 的大规模增长促使对能够支持新型 400G 技术和架构的高带宽、可扩展解决方案的需求激增。

400G 的解决方案非常适合应对流量持续增长的大容量电信提供商、大型数据中心以及企业。与常规的100G解决方案相比,400G 光收发器模块的每个 RU 可提供 4 倍的高带宽——通过在更少的物理空间中提供相同的带宽,降低每比特成本。另一方面,在现网中引入400G交换机后总端口将会更少,管理起来也更容易。

星融元400G以太网交换机(CX-N系列)

CX732Q-N是星融元推出的一款400G以太网交换机产品,转发时延低至~400ns。

  • 32x400G QSFP-DD 端口,兼容40G/100G/200G,可实现平滑的升级过渡
  • 支持带内网络遥测:2x10G SFP+ 的INT端口为后端提供实时精准的遥测数据;基于可编程交换芯片实现,不占用CPU性能
  • 128G M.2 SSD
  • 5+1热插拔风扇,1+1电源

400G实拍照片

CX-N系列低时延云交换机型号一览

型号业务接口 交换容量
CX864E-N64 x 800GE OSFP,2 x 10GE SFP+102.4Tbps
CX732Q-N32 x 400GE QSFP-DD, 2 x 10GE SFP+25.6Tbps
CX664D-N64 x 200GE QSFP56, 2 x 10GE SFP+25.6Tbps
CX564P-N64 x 100GE QSFP28, 2 x 10GE SFP+12.8Tbps
CX532P-N32 x 100GE QSFP28, 2 x 10GE SFP+6.4Tbps
CX308P-48Y-N48 x 25GE SFP28, 8 x 100GE QSFP284.0Tbps

相关阅读:私有云网络的进化之路:与开放网络技术的完美融合

开放的软件架构——AsterNOS

包含CX732Q-N交换机在内的CX-N全系交换机都搭载了AsterNOS网络操作系统,它具备高度的功能定制和可扩展性,帮助实现网络运维自动化,可为云数据中心多业务融合、AIGC网络、高性能计算(HPC)、大数据分析等多种业务场景提供卓越的网络服务。

对比社区版SONiC,AsterNOS在以下方面做了大量功能补充和增强:

对比社区版SONiC,AsterNOS功能补充和增强

支持EVPN多归属

与MC-LAG 解决方案相比,EVPN Multi-homing不仅能更好地解决可扩展性和流量负载平衡方面的限制,还能提高 VXLAN 接入端的可靠性。

参阅:MC-LAG还是Multi-Homing?探讨网络通信高可用性的新选择

思科风格命令行

此外,AsterNOS 完全支持 Cisco风格的命令行模式,大大降低了运维端的学习成本。下面是我们在使用 AserNOS 的交换机上演示以不同的命令行模式(Cisco-like Klish/Linux Bash)配置 VLAN
AsterNOS配置界面

返回资源中心

AI应用对网络基础设施有哪些需求?

更多相关内容


网络性能的效率在确保人工智能应用程序有效运行方面起着至关重要的作用。这种效率决定了系统处理信息的速度,同时也影响着整体应用性能。

人工智能应用程序通常是数据密集型的,需要处理大量信息,因此需要在交换机、路由器和服务器等各种设备之间快速访问和快速传输。速度慢或延迟高的低效网络会干扰实时或接近实时的输入信号,从而缩短处理时间。应用程序的算法依赖于这些信号来识别对准确结果至关重要的特定模式。

当应用程序在网络基础设施上运行时,处理器通过处理器间传输与远程存储器交换信息。这种传输会大大减少延迟和带宽,最终限制应用程序的效率。中央处理器的处理速度与内存访问速度之间的差距越来越大,这给人工智能应用带来了被称为 “内存墙 “的挑战。

尽管 CPU 处理能力有了长足进步,但在提高内存访问速度方面的进展却相对缓慢。这一瓶颈限制了系统的整体性能。

人工智能内存墙问题与网络

在人工智能应用中,处理大型数据集是无可争议的必要条件。然而,这一过程却带来了潜在的绊脚石。由于带宽限制或此类系统特有的高延迟,在处理单元和内存系统等不同组件之间传输上述数据集的速度可能会很慢。

更复杂的是,现代计算机拥有独立的内存层,这些内存层在特定属性(如访问速度和容量)方面各不相同。在这些不同层级之间移动数据会导致内存墙问题,访问时间的增加会影响性能。

在缓存方面,有时会出现请求数据,但却无法在先前为快速检索而设计的缓存中找到数据的情况。这种故障会增加另一个导致瓶颈的问题,即缓存缺失。这种中断会导致严重的延迟,往往会造成系统整体性能的滞后。此外,如果多个处理单元或线程同时访问一个处理单元,就会出现资源争夺,导致效率降低。

不过,网络可以缓解这些问题。分布式系统可以通过将计算和数据分布到多个节点来使用网络资源。这种方法可以改善内存访问时间,减少内存墙问题对人工智能应用性能的影响。

在庞大的网络中,在不同节点间移动信息会产生过多的开销,而减少这些开销的一个有效方法就是采用包含远程直接内存访问(RDMA)的网络技术。

RDMA 实现了两个远程系统内存之间的直接数据传输,无需 CPU 参与。这一过程加快了数据传输,同时最大限度地减少了 CPU 的开销。就人工智能应用而言,RDMA 为优化内存访问开辟了途径,以最快的速度和最高的效率简化了网络各部分之间的通信。

例如,在分布式深度学习系统中,企业可以使用 RDMA 将数据从 GPU 调度到另一个 GPU 或异地存储设施,灵活性极高。RDMA 可以优化可用内存的使用,同时规避潜在的内存障碍,限制内存墙问题的影响。这种模式的转变对基于人工智能的应用具有重大影响,因为在人工智能应用中,无缝通信往往是性能平平与性能卓越的分水岭。

性能之外的网络需求

人工智能应用需要的不仅仅是令人印象深刻的网络性能。以下是网络可使人工智能应用受益的其他领域:

安全性

人工智能应用通常会处理敏感信息,如个人信息或金融交易。使用加密技术和身份验证控制等安全措施确保此类数据的保密性和完整性至关重要。

可扩展性

大规模分布式系统需要较高的可扩展性,因为它们是人工智能工具和快速响应时间的基础。使用软件定义网络等可快速扩展的技术,可确保人工智能应用根据需要无缝增长。

高速连接

大多数人工智能应用需要提供实时或接近实时的洞察和预测,因此保持高速连接至关重要。要正面解决这一问题,需要使用具有高可靠性和容错功能、冗余链路和故障转移机制的网络设计,以确保即使在出现问题时也能不间断地运行。

服务质量QoS

不同类型的信息可能需要不同程度的优先级。由于高优先级数据优先于其他数据,网络产品已发展到提供 QoS 功能。这些功能使应用能够在各种类型的数据流量之间分配网络带宽,并确保优先处理最关键的信息。

星融元AIGC承载网设计方案

AIGC承载网方案架构图AIGC承载网方案架构图


超低TCO、超高性价比

相较于IB方案,大幅度降低用户的网络TCO,同时确保超高性能

横向平滑扩容、1:1收敛无阻塞

无收敛的网络设计确保无阻塞的大容量网络,按需横向扩展

整网RoCEv2

基于CEE/DCB能力,提供可与IB媲美的性能和同样无损的网络服务

开放网络操作系统

星融元网络操作系统AsterNOS,SONiC企业级发行版,支持灵活的功能扩展、在线升级

无缝对接云管

AsterNOS 利用简单易用的REST API,可轻松让第三方的云平台/控制器快速纳管

专家级服务

专业、全面、可靠的研发、方案与服务团队,为客户提供小时级的快速响应服务

详情可参考:客户案例:高性能、大规模、高可靠的AIGC承载网络

智能网卡和人工智能应用

智能网络接口控制器(SmartNIC)等专用外设可帮助有效部署人工智能应用。SmartNIC 的一个关键功能是能够将网络处理从主机 CPU 卸载到专用硬件加速器。这可以减少 CPU 负载,同时为运行人工智能应用释放更多资源。

智能网卡使用硬件加速器来执行加密、压缩和协议处理等任务。这种方法还能加快数据传输,从而减少延迟,提高网络吞吐速度,从而加快数据传输,缩短处理时间。

使用智能网卡还能更轻松地解决所有人工智能应用面临的内存墙问题。智能网卡改变了服务器系统处理网络基础设施需求的方式。智能网卡能够承担通常会加重主机 CPU 负担的某些任务,这意味着性能大幅提升,尤其是在数据分析等内存密集型操作中。

将数据包过滤和流量分类任务卸载到 SmartNIC 的专用硬件上,而不是依赖于服务器 CPU 的通用架构,可有效降低服务器 CPU 的使用率,并获得更好的整体效果。此外,许多 SmartNIC 型号都具有本地缓存功能,这意味着无需进行冗长的网络传输,也减少了等待关键信息的时间。

基于开源DPU资源池,破解边缘云算力扩展难题 – 星融元Asterfusion

与其他类型的应用相比,人工智能应用有其独特的要求,对网络基础设施的吞吐量、延迟、安全性、可靠性和可扩展性提出了很高的要求。因此,企业可能有必要调整当前的数据中心网络基础设施,以支持这些需求。

返回资源中心

DCI互通原理简介——L3 DCI互联简介

更多相关内容


概要流程

Multi-Fabric方式的DCI中,L3不过墙互通的简要原理如图1所示。

在Server Leaf上:

  1. 将本地ARP转为BGP EVPN路由发布给DCI Leaf。

在DCI Leaf上:

  1. 本端DCI Leaf的VRF1与互通VRF3的RT值交叉,并下发路由策略,只放通互通的子网。
  2. 本端DCI Leaf学习本地Fabric内的路由,并修改路由下一跳为本地IP,封装为互通L3 VNI后发布给对端DCI Leaf。
  3. 对端DCI Leaf学习到发布的路由,修改路由下一跳为本地IP,封装为本地VNI后发布给Fabric内的其他Leaf。

L3 DCI不过墙互通简要工作原理

控制平面

控制平面

  1. Server Leaf1将学习到VM1的主机IP地址,并将其保存在L3VPN1实例路由表中,然后向DCI Leaf11发送BGP EVPN路由。
  2. DCI Leaf11收到Server Leaf1发送的BGP EVPN路由后,先解封装在L3VPN1实例中获取该路由中的主机IP路由,再将路由交叉到DCI所在的EVPN实例L3VPN3。
  3. DCI Leaf11进行BGP EVPN路由重生成,将路由下一跳修改为DCI Leaf11的VTEP地址,然后重新封装,封装上L3VPN3实例的三层VNI,源MAC地址为DCI Leaf11的MAC地址,并将重新封装后的BGP EVPN路由信息发送给DCI Leaf12。
  4. DCI Leaf12收到DCI Leaf11发送的BGP EVPN路由后,先解封装在L3VPN3实例中获取该路由中的主机IP路由,再交叉到Fabric2所在的EVPN实例L3VPN2中。
  5. DCI Leaf12进行BGP EVPN路由重生成,将路由下一跳修改为DCI Leaf12的VTEP地址,然后重新封装,封装上L3VPN2实例的三层VNI,源MAC地址为DCI Leaf12的MAC地址,并将重新封装后的BGP EVPN路由信息发送给Server Leaf2。
  6. Server Leaf2收到DCI Leaf12发送的BGP EVPN路由后,解封装后成功获取该路由中的主机IP路由。

转发平面

转发平面

  1. Server Leaf2收到VM2访问VM1的二层报文,检测到目的MAC是网关接口MAC,终结二层报文,通过VM2接入BD的BDIF接口找到对应的L3VPN实例,并在L3VPN实例的路由表中查找VM1主机路由,进入Server Leaf2到DCI Leaf12的VXLAN隧道,封装成VXLAN报文通过VXLAN隧道发送到DCI Leaf12。
  2. DCI Leaf12收到VXLAN报文后,解析VXLAN报文,通过三层VNI找到对应的L3VPN实例,并在L3VPN实例的路由表中查找VM1主机路由,进入DCI Leaf12到DCI Leaf11的VXLAN隧道,重新封装VXLAN报文(三层VNI是DCI Leaf11发送的VM1主机路由中携带的三层VNI、外层目的MAC是DCI Leaf11发送的VM1主机路由中携带的MAC)发送给DCI Leaf11。
  3. DCI Leaf11收到VXLAN报文后,解析VXLAN报文通过三层VNI找到对应的L3VPN实例,并在L3VPN实例的路由表中查找VM1主机路由,进入DCI Leaf11到Server Leaf1的VXLAN隧道,重新封装VXLAN报文(三层VNI是Server Leaf1发送的VM1主机路由中携带的三层VNI、外层目的MAC是Server Leaf1发送的VM1主机路由中携带的MAC)发送给Server Leaf1。
  4. Server Leaf1收到VXLAN报文后,解析VXLAN报文,通过三层VNI找到对应的L3VPN实例,并在L3VPN实例的路由表中查找VM1主机路由,根据路由信息转发给VM1。

返回资源中心

什么是DCI互联,为什么需要DCI互联

更多相关内容


什么是DCI?

数据中心互联(Data Center Interconnect,DCI) ,是一种跨数据中心实现网络互联互通的网络解决方案,具备灵活互联,高效安全,简化运维等特性,满足了数据中心之间高效数据交换、异地灾备等场景需求。

在云化数据中心,网络资源通过虚拟化技术形成资源池,实现业务与物理网络解耦,通过网络虚拟化,物理网络资源可以被分成多个虚拟网络资源,从而提高网络资源的使用效率。

虚拟网络资源根据业务需求进行分配和调度,可以更好地利用网络资源。此外,虚拟网络资源的快速部署和迁移可以提高业务的灵活性和可用性。

我们对DCI的需求迫切吗?

伴随着用户业务规模的扩大和范围的增加,用户可能需要在多个地理位置建立数据中心以满足业务需求。这些数据中心需要进行互联和资源共享。一些应用程序可能需要在多个数据中心之间进行迁移、复制、备份等操作,而另一些应用程序可能需要快速在不同的数据中心之间进行负载均衡和容灾切换。

具体诉求如下:

  • 业务跨DC部署:客户某些业务可能是跨DC部署的,比如客户可能会针对某大型网站划一个独立的VPC,这个VPC可能会跨多个DC,所以在这个VPC内部流量就有跨Fabric互通的需求,同时路由和防火墙需要进行隔离。
  • 业务之间的互通:客户针对不同的业务会划分不同的VPC,不同VPC可能会部署在不同的DC中,业务之间如果有互通的需求,就要求VPC之间能跨DC进行L3互通(VPC之间互通一般为L3互通,如果需要L2互通则需要将VM划分到同一个VPC中)。
  • 业务容灾/多活:业务容灾和多活主要分为两种方式,首先针对比较新的业务系统,客户自己可以通过GSLB(全局负载均衡)的方式进行容灾和多活,具体方式是两个DC同时部署相同的业务,业务相同同时IP地址不同,这样两套系统可以进行容灾处理。这种方式对网络没有什么特别的诉求,但是针对比较旧的一些系统,会要求迁移到容灾中心后,IP地址不能变化,这种情况下,就需要支持跨DC的二层互通。

多归接入为了解决这些问题,Asterfusion推出了跨DC解决方案Multi-Fabric使用VXLAN、BGP-EVPN等技术对L2和L3网络进行扩展。这样,用户的应用程序就可以在多个数据中心之间进行迁移、负载均衡、容灾切换等操作,而无需担心网络问题,帮助管理多个数据中心之间的网络和资源,提高业务的可扩展性和可靠性。

返回资源中心

企业园区网络云化改造,机箱式核心交换机或将消失?

更多相关内容


核心交换机在企业网络中承担了哪些作用?

核心交换机是一种高容量的交换机,作为通往广域网(WAN)或互联网的网关,为网络提供最后的聚合点,并允许多个模块一起工作。

在企业分层网络设计中,核心层交换机是顶层的,其他接入层和分布层都依赖它。它汇聚了来自分布层设备和接入层设备的所有流量,有时核心交换机还需要处理来自其他出口设备的外部流量。因此,对于核心交换机来说,吞吐量性能、高可用性是非常重要的。

网络功能将多个接入交换机连接在一起,并在不同的网段之间路由数据
部署位置通常位于数据中心或服务器机房中
速率要求专为高速数据传输而设计的高性能网络交换机
设备特性提供高级功能,如冗余、可靠性和高可用性
设备价格由于其先进的特性和功能,比接入交换机更昂贵

所以,在经典的园区网络三层拓扑中,一般使用多模块设计的机框式设备作为核心层的交换机。

核心层的交换机:多模块的机框式设备

由于机箱交换机包含一定数量的固定插槽(通常每个插槽 1U),因此可以将各种类型的线卡插入其中。机箱交换机可以配置各种线卡,以提供相应类型和数量的所需网络端口(铜缆和光纤)。此外,这种基于机箱的网络交换机的核心具有适用于所有线卡的通用背板,背板上包括电源模块、冷却风扇模块、控制平面/处理模块等。

作为核心层交换机,盒式设备能否取代机框设备?

如果在企业网络中工作过,您可能已经很熟悉这类大型机框设备了。很长一段时间以来,在网络核心层使用这类机框式交换机设备已经快成了架构大型网络时的事实标准。但实际上,随着云计算的发展,云数据中心网络已经率先抛弃了机框型交换机,转而使用一种更为先进的分布式交换结构——Leaf-spine架构。

Spine-Leaf架构

Leaf-spine是Clos网络的衍生产品,该架构允许网络中多达一半的交换设备离线,对网络的唯一影响仅仅是减少了冗余和吞吐量。在这架构下,我们可以采用全盒式的设备来组网,无需任何机框式设备,并且这套架构完全可以平移到园区网络。

云化园区解决方案

高可用性

机箱交换的主要卖点之一是高可用性。在机箱内,每个组件都应以 N+1 冗余部署。并且会需要双机部署以确保高可靠性,但不怕一万就怕万一,核心层的机框交换机往往集中承担着路由和网关功能,一旦出现问题时受影响的设备数量多,故障域极大。

扩展性

其实,大多数机箱交换机都依赖于 Clos 网络技术来实现机箱内的可扩展性。通过高速背板和多个线卡插槽的组合,机箱交换机确实具有相当大的灵活性。但这里的挑战在于,为了应对交换机生命周期内的网络扩容需求,一开始就必须购买足够大的交换机,

对于一些公司来说,核心层交换机的使用寿命预计会超过 7-10 年。作为网络的运营管理者,要么需要足够的先见之明,精准拿捏未来五年的业务需求,要么就会在建设初期就大幅超额购买(这也是大多数人的选择),但随之带来了很长一段时间的性能资源浪费。

基于Spine-leaf的分布式交换架构在扩展性方面明显更灵活:如果需要更多接入端口,就增加Leaf交换机,如果需要更多网络吞吐容量,就添加更多spine交换机,并且可以做到平滑扩容。这种架构非常适应各个行业不断变化的网络需求。

可升级性

对于机箱交换机来说,如此多的服务如此紧密地打包在一个控制平面中,升级是一项非常复杂的任务。为了解决这个问题,很多机框式交换机供应商创建了专门的“热升级”方式。但是对于如此高度耦合,位置如此关键的网络设备来说,当每一次升级都高度依赖于这套控制平面的正常运行,尽管厂商提供了升级选项,但一线的工程师还是宁可不升级去确保稳定运行。

在分布式的园区网络架构(Spine/Leaf)之下则无需有此顾虑。由于服务都是分布在许多设备上(比如分布式的网关),因此,单设备的问题对网络的影响很小。另外,由于网络中的设备之间只有松散的耦合,并非所有设备都必须像机框式交换机那样处于相同的软件版本。这意味着,您完全可以先升级一小部分网络作为试点。如果效果不佳将其回滚即可。如果效果不错再应用到整网。

关注vx:星融元Asterfusion了解更多资讯。

返回资源中心

智慧园区建设中面临的网络基础设施挑战

更多相关内容


什么是智慧园区?

相比传统商业地产运营模式,AI时代下的智慧园区运营结合了多种新兴技术手段:例如基于统一的平台,将办公协作、招商引资、工程项目、物业管理、产业分析、项目孵化等业务进行一体化的协调管理;通过标准化的接口,将智能设备及系统整合至园区内部运营平台,对数据统一监管,并运用大数据技术为客户提供个性化、定制化、智慧化服务。

智慧园区建设面临的挑战

智慧产业园区作为园区信息化和产业互联网的基础,是帮助企业向自动化、智能化转型的有力推动者。随着“互联网+园区管理”理念的实践不断深入,智慧产业园区建设也将从上层的应用软件平台的信息化、智慧化深入到数字经济转型的底层基础设施——园区基础网络。

终端接入数量和承载的业务复杂度剧增,对于园区基础网络的可靠性、规模和功能的扩展性都提出了更高要求,然而,上面提及的智慧园区应用都是在传统的租户自建网络模式下无法实现,或者部署起来相当受限的。

携手商业地产运营商共同进入AI时代

星融元云化园区解决方案

星融元的云化园区网络方案采用了先进的云网技术,基于Spine-Leaf架构的三层路由网络能为园区内的海量用户终端、园区物联网设备以及后端平台提供稳定的高速互联能力,轻松实现“一网多用”、Wifi“无缝漫游”等等实用功能,并且大大降低了租户和园区运营商的运维成本。

此外,星融元的园区网络设备开放出了丰富的软件可编程接口,可通过集成各类自动化工具和分析平台,赋能AI智能运维和精准的客户定位和大数据分析等等,推动运营服务的升级优化,甚至从中探索出新的商业增值点。

云化园区解决方案

体验优化

  • 毫秒级漫游切换,业务不中断
  • 25G高速上行,海量数据并发接入无压力

超高可靠

  • 天然无广播风暴,天然无环路
  • 去堆叠/去MC-LAG,更低复杂度的多路径负载分担网络

极简运维

  • 轻量级的网络集群管理
  • 同层设备业务配置相同,开局自动下发

更多案例和方案详细信息,请关注微信公众号:@星融元Asterfusion

返回资源中心

AIGC承载网优化设计方案(下)

更多相关内容


AIGC承载网优化设计思路

网络性能瓶颈问题

通信时长的考虑

带宽:与单机不同,多机之间的网络带宽是比单机内部的带宽要低很多的,

多机之间的网络通信往往会受到网络拓扑、物理连接和网络设备等因素的限制,导致实际的带宽较单机内部的带宽低很多。如单机内部NVLink3.0带宽高达600GB/s;而多机之间的网络一般是400Gb/s或200Gb/s(且是Gb/s)
在AIGC承载网络中,多机之间的通信是必要的,尤其是在分布式计算环境下,不同计算节点之间需要进行数据传输、模型同步和参数更新等操作。这些通信过程可能影响到整体的网络性能和计算效率。

设备转发时延:IB交换机或低时延交换机

设备转发时延

性能提升

(1)提升单机网络宽带

提升单机网卡带宽,同时需要匹配主机PCIe带宽和网络交换机的带宽

网卡速率40G100G200G400G
PCIe3.0*83.0*164.0*164.0或5.0*16
交换机Serdes4*10G4*25G4*50G8*50G

增加网卡的数量,初期业务量少,可以考虑CPU和GPU共用,后期给CPU准备单独的1到2张网卡,给GPU准备4或8张网卡。

增加网卡的数量

(2)应用RDMA网络(IB或RoCE)

借助RDMA技术,减少了GPU通信过程中的数据复制次数,优化通信路径,降低通信时延。

优化通信路径,降低通信时延

优化通信路径,降低通信时延

(3)减少网络拥塞

胖树结构:通过多路径的布线和聚合链路的利用,可以提供高带宽、低延迟和高可靠性的通信。
1:1收敛比

1:1收敛比

双网分流:通过同时连接到两个不同的网络,将流量分流到两个路径上,从而减轻单一网络的负载和拥塞情况。这里, CPU的流量与GPU流量彻底分离开。

CPU的流量与GPU流量彻底分离开

(4)通信算法优化

单机优化

单机优化

多级优化

多级优化

  • 利用NVLink高带宽优势在单机内部的GPU之间完成数据同步
  • 多机之间的GPU利用多网卡建立多个环,对不同分段数据进行同步
  • 最后单机内部的GPU再同步一次,最终完成全部GPU的数据同步

大规模网络扩展问题

算力昂贵是大家普遍的共识,由于GPU资源本身稀缺的特性,尽可能多的把GPU资源集中在一个统一的资源池里面,将有利于任务的灵活调度,减少AI任务的排队、减少资源碎片的产生、提升GPU的利用率。

要组成大规模GPU集群,网络的组网方式需要进行优化。

(1)网络架构横向扩展

ToR交换机用于和GPU Server直接连接,构成一个Block。

ToR交换机向上一层是Leaf交换机,一组ToR交换机和一组Leaf交换机之间实现无阻塞全连接架构,构成一个Pod
不同Pod之间使用Spine交换机连接。

ToR交换机用于和GPU Server直接连接,构成一个Block

接入能力分析

Pod是典型集群规模

  • Block是最小单元,包括256个GPU
  • Pod是典型集群规模,包括8个Block,2048个GPU
  • 超过2048个GPU,通过Fabric-Pod模式进行扩展

GPU网卡的连接建议

GPU网卡的连接

异构网络自适应通信技术
基于异构网络自适应通信技术,不同服务器上相同位置的GPU,在同一轨道平面,仍然走机间网络通

以某厂家的技术实现为例:基于异构网络自适应通信技术,不同服务器上相同位置的GPU,在同一轨道平面,仍然走机间网络通信。

要去往不同位置的GPU(比如host1上的GPU1,需要向其它host上的GPU8 送数据),则先通过机内网络,转发到host1上的GPU8上,然后通过机间网络,来完成通信。机间网络的流量,大部分都聚合在轨道内传输(只经过一级ToR)。机间网络的流量大幅减少,冲击概率也明显下降,从而提供了整网性能。根据实测,异构网络通信在大规模All-to-All场景下,对中小数据包的传输性能提升在30%左右。

(2) 计算与存储网络分离

CPU的流量与GPU流量彻底分离开

网络可用性问题

可用性问题在GPU集群中要求不高

因为大规模分布式的AI任务基本都是离线的训练任务,网络中断不会对主业务造成直接影响。

但是也需要关注,因为一个AI训练持续的时间可能会很长,如果没有中间状态保存的话,网络中断就意味着前面花费时间训练出来的成果全部失效,所使用的GPU资源也全部被浪费掉。

AI训练任务对网络拓扑的高度敏感性

某一处网络的中断,会导致其他节点网络的非对称,无限增加上层处理的复杂度,因此,在设计集群的时候需要考虑中断容忍的网络架构。

(1)存储双上联

由于网络中断,导致一个存储节点下线,可能会在网络内触发大量数据恢复流量,增加网络负载,因此,建议采用双上联设计,确保某个交换机或上联链路中断不会影响存储节点的可用性。

(2) 计算网单上行

由于AI训练的特殊性,综合性能与成本考虑,暂不考虑双上联设计。

(3)采用GPU网卡连接方式

同一个GPU Server上的8块卡连接到8个ToR,可以节省机间网络的流量,大部分都聚合在轨道内传输(只经过一级ToR),机间网络的流量大幅减少,冲击概率也明显下降,从而提供了整网性能

但是,上面的方案,GPU Server上任何一个网卡或链接中断都会导致网络的非对称,整个GPU Server都会受到影响。所以,干脆让所有网卡共享同一个交换机,好处是,如果ToR交换机故障,影响到的GPU Server会尽可能少,从整个系统的角度出发,可用性反而提高了

采用GPU网卡连接方式

AIGC承载网设计实践

需求汇总(以某客户项目模型为例)

RoCE的计算网络 RoCE存储网络
1.不少于600端口200G以太网接入端口,未来可扩容至至少1280端口1.不少于100端口200G以太网接入端口,未来可扩容至至少240端口
2. 全网无收敛(1:1收敛比),全线速交换2. 带宽收敛比不大于3:1
3. 支持RoCE实现无损以太网3. 支持 RoCE 实现无损以太网

整网的方案设计

AIGC承载网方案架构图

AIGC承载网方案架构图

计算网络设计—-方案1(整网1:1无收敛)

不考虑GPU的8个接口的接入方式,8个接口接入1台或多台ToR

计算网络设计方案

  • 交换机 10 Leaf + 20 ToR= 30 台,提供640个接入端口(20*32=640),每台GPU服务器8端口,可以最大可接入GPU服务器 80台
  • 接入侧和Fabric内部互联均可以使用200G的AOC(含两端的200G光模块),其中接入侧600条,Fabric侧600条,合计1200条
方案1扩展性

计算网络设计方案

基于该架构,最多可以接入64台ToR,最大可以扩展到2048个200G接口接入,满足1280接口接入的扩展性要求

计算网络设计—-方案2(整网1:1无收敛)

考虑GPU的8个接口的接入方式,8个接口接入到8台Leaf,每8台Leaf作为一个分组

计算网络设计方案2

  • 交换机 13 Leaf + 24 ToR = 37 台,按600个接入端口(75台GPU服务器),每组8个ToR接入25台GPU服务器,3组ToR接入75台
  • 每组ToR接入25台GPU服务器,下行接入带宽为200*200GE,因此,上行也需要至少是200*200GE带宽,每台ToR到每台Leaf为2条200G,总上行带宽为2*13*8*200GE,满足1:1收敛要求
  • 接入侧和Fabric内部互联均可以使用200G的AOC(含两端的200G光模块),其中接入侧600条,Fabric侧624条,合计1224条
方案2扩展性

计算网络设计方案2的扩展性

  • 基于该架构,最多可以接入8组ToR ,每组8个ToR接入32台GPU服务器,8组ToR接入256台
  • 最大可以扩展到2048个200G接口接入,满足1280接口接入的扩展性要求

存储网络设计(整网3:1收敛)

存储网络设计方案

  • 交换机 2 Leaf + 3 ToR = 5 台,提供最大144个接入端口(满足100个接入需求)
  • 如果不考虑Leaf高可靠部署,也可以单Leaf接入
  • 接入侧和Fabric内部互联均可以使用200G的AOC(含两端的200G光模块),其中接入侧100条,Fabric侧36条,合计136条
存储网络设计的扩展性

存储网络设计的扩展性

  • 交换机 2 Leaf + 5 ToR = 7 台,提供最大240个接入端口(满足240个接入的扩展需求)

设备配置汇总

网络类型设备类型设备型号台数合计
方案1
计算网络(600*200GE端口)SpineCX664D-N1035
LeafCX664D-N20
存储网络(100*200GE端口)SpineCX664D-N2
LeafCX664D-N3
AOC线缆(含模块)AOC1336条
方案2
计算网络(600*200GE端口)SpineCX664D-N1342
LeafCX664D-N24
存储网络(100*200GE端口)SpineCX664D-N2
LeafCX664D-N3
AOC线缆(含模块)AOC1360条

星融元方案价值与优势

  1. 超低TCO、超高性价比:相较于IB方案,大幅度降低用户的网络TCO,同时确保高性能
  2. 横向平滑扩容、1:1收敛无阻塞:无收敛的网络设计确保无阻塞的大容量网络,按需横向扩展
  3. 整网RoCEv2:基于CEE/DCB能力,提供可与IB媲美的性能和同样无损的网络服务
  4. 开放网络操作系统:星融元网络操作系统AsterNOS,SONiC企业级发行版,支持灵活的功能扩展、在线升级
  5. 无缝对接云管:AsterNOS 利用简单易用的REST API,可轻松让第三方的云平台/控制器快速纳管
  6. 专家级服务:专业、全面、可靠的研发、方案与服务团队,为客户提供小时级的快速响应服务

返回资源中心

什么是TIP OpenWiFi?

更多相关内容


星融元于2023年4月加入电信基础设施项目 (TIP) 开放融合无线(OCW) 项目组,并已基于开源 TIP OpenWiFi 项目构建了云化园区网络解决方案中的控制器和无线AP部分。

开放融合无线(OCW) 项目组

与专有解决方案相比,OpenWiFi 结合了部署节省 (CAPEX) 和自动化驱动的运营节省 (OPEX),显着降低了总体拥有成本 (TCO);OpenWiFi支持多样化的供应商云控制器和接入点选择,为服务提供商提供了企业级 Wi-Fi 基础设施的选择和灵活性。

结合社区路标规划,星融元会在后续控制器版本中不断更新完善,更多信息请持续关注星融元官网和公众号。

社区路标规划

星融元为什么要基于TIP OpenWiFi 开发园区控制器?

OpenWiFi是开放融合无线(OCW) 项目组贡献的第一个项目。它于 2021 年 5 月推出,包括接入点 (AP) 硬件、开源 AP 网络操作系统 (NOS) 和用于构建云原生 Wi-Fi 的 SDK面向 Wi-Fi 服务提供商和企业的控制器和管理软件。

OpenWiFi是开放融合无线(OCW) 项目组贡献的第一个项目

借助于优秀的开源开放底层框架打造企业级产品已经是当前常见的产品创新模式,可以避免”重复造轮子”,集中精力在应用层面的创新,节约部署和开发成本。当前全球已有很多基于OpenWiFi的大规模商业部署案例。

OpenWiFi高度开放解耦的特性,云控制器SDK提供开放的北向API,支持无缝接入很多白盒硬件,应用广泛。来自不同供应商的AP、云控制器和 OTT 分析解决方案能够在同一网络上放心地互操作和协同工作。

基于OpenWiFi的大规模商业部署案例

Openwifi的架构

微服务组件微服务组件

  • 基于RBAC(角色访问控制)的安全框架
  • 基于OpenAPI北向接口
  • Kafka消息队列
  • 固件管理
  • 集中式仪表盘(WEBUI)
  • 用户接口
  • Docker Compose & Helm 自动化部署

OpeWiFi采用的是基于微服务的架构。通过微服务,可将大型应用分解成多个独立的组件,其中每个组件都有各自的责任领域。在处理一个用户请求时,基于微服务的应用可能会调用许多内部微服务来共同生成其响应。现代云原生应用通常使用容器构建微服务,Docker是微服务架构的绝佳示例,因为它们可让您专注于开发服务,而无需担心依赖项。

星融元园区控制器的微服务界面预览

星融元园区控制器的微服务界面预览

OpenWiFi 的ucentral数据模型

  • OpenWiFi 的ucentral数据模型OpenWiFi 2.0 设备管理数据模型基于uCentral 协议实现
  • uCentral 组件集成到OpenWrt,具备通用性
  • 消息交互采用 JSON 消息体
  • 支持通过 WEBUI 根据配置项自动生成配置文件

OpenWiFi的部署

OpenWiFi采用Docker Compose部署管理,该工具用于定义和运行多容器 Docker 应用程序的工具, YML 文件来配置应用程序需要的所有服务;Docker处于同一OpenWiFi网桥下,容器之间可以通过IP互访,也可以通过别名互访。

星融元园区控制器容器部署页面预览

星融元园区控制器容器部署页面预览


附录:电信基础设施项目 (TIP)简介

电信基础设施项目 (TIP) 是一个致力于推动基础设施解决方案以促进全球连接的社区组织,成员包括数百家参与公司——从服务提供商和技术合作伙伴到系统集成商和其他连接利益相关者,共同致力于加速开放、分类和基于标准的技术解决方案的开发和部署,以提供世界现在和未来几十年所需的高质量网络连接。
鉴于世界上一半的人口仍然没有连接到互联网,而对于那些已经连接到互联网的人来说,连接往往是不够的。这限制了互联网提供的众多消费者和商业利益,从而影响了全球 GDP 增长。然而,当前解决方案缺乏灵活性(由于技术提供商的选择有限而加剧这种矛盾),使得运营商高效构建和升级网络面临挑战。

电信基础设施项目

返回资源中心

对星融元产品感兴趣?

立即联系!

返回顶部

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