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

标签: 技术实现

再谈 SONiC:生态现状与新场景扩展实践


关注星融元


SONiC(Software of Open Networking in Cloud,云端开放网络软件)由微软为其 Azure 数据中心开发,并于 2016 年开源,基于 Linux 发行版 Debian。

关于SONiC

SONiC 使用 SAI 将软件与底层硬件分离,使其能够在多供应商 ASIC 上运行。

据 Gartner 称,随着人们对 SONiC 的兴趣日益浓厚,SONiC 很有可能在未来三到六年内成为类似于 Linux 的网络操作系统。

SONiC 系统架构由各种模块组成,这些模块通过集中式和可扩展的基础架构相互交互。其中的核心基础设施是 Redis 数据库,它提供一个独立于语言的接口,支持在所有 SONiC 子系统之间进行数据持久存储、复制和多进程通信。

SONiC

Redis数据库采用“发布者/订阅者”消息传递方式,运行在SONiC系统内的各类应用程序可以只订阅所需的数据,并避免与其功能无关的实现细节,从而保持了各组件模块的独立性:每个模块放置在独立的 docker 容器中,且都是完全独立于平台特定细节而编写

SONiC的发展前景

SONiC采用的开放、解耦的软件架构十分适应云计算对网络基础设施的需求,使得网络也开始作为一个可编程的对象,在更多新业务场景发挥出创造性的价值。

作为这样一个云原生的网络操作系统,SONiC采用的模块化方法可支持高效的故障恢复和在线升级,允许在不中断整个系统运行的情况下更换或增强特定组件

举几个例子:用户可以升级操作系统更新、驱动程序等单个软件组件,或者动态添加新协议或应用程序,而不会影响其他模块或导致整个交换机宕机;用户也无需受限于传统单一供应商的产品路线图来推进自身的业务创新,而是可以自主控制系统的功能,并按需集成各类网络自动化和应用程序等重要工具

SONiC 架构是否可靠?

根据由微软 Azure 网络技术研究员兼 CVP、SONiC 基金会管理委员会主席 Dave A. Maltz 领导的团队开展的一项研究,该团队对 Azure 数据中心的 18 万台交换机进行了为期三个月的跟踪。

研究发现:数据中心交换机自投入生产部署以来,至少有 3 个月保持不间断运行的概率为 98.5%;3个月后,SONiC 交换机的生存概率比非 SONiC 交换机高 1% ,并且随着时间的推移,可靠性方面的差距还在扩大。

Azure Kaplan-MeirerAzure 数据中心交换机的 Kaplan-Meirer 生存曲线

SONiC 的生态现状

SONiC 生态系统已形成多元化的社区和商业版本,暂无统一的公开统计,下面仅简要列举。

社区版

GitHub (https://github.com/sonic-net)

微软Azure SONiC

作为SONiC的原始创建者,微软的发行版广泛应用于Azure全球数据中心,是社区最核心的参考实现。

星融元 Asterfusion SONiC(AsterNOS

提供基于SONiC的软硬件一体化的“交钥匙”商用解决方案,面向AI智算、通算云、园区网等场景深度优化,强调降低开放网络技术的使用门槛。

各大云服务商自研定制版

例如腾讯、阿里等云服务商均基于SONiC构建数据中心网络,运行了内部定制版本的SONiC。

Hedgehog Enterprise SONiC

来自初创公司Hedgehog,主要专注于企业边缘场景,提供简化部署的发行版,适配AI计算等新兴需求。

SONiC 的商用场景扩展:心远,路自宽

正如上文,研发资源充足的大型云服务商会为自己的超大规模数据中心定制开发 SONiC —— 尽管SONiC使用 SAI 实现了网络侧的软硬件解耦,但在不同的交换机硬件上完美运行SONiC,仍需要大量的深度硬件协同适配工作。

社区响应慢、开发门槛高,正是阻碍普通企业享用这一开放网络技术红利的直接因素。

星融元 Asterfuson 于 2017 年加入社区,是全球极少数有能力提供基于SONiC的、软硬一体的开放网络解决方案厂商,以“交钥匙”的方案降低SONiC操作和使用门槛:

一方面持续基于 SONiC 开放架构补充大量面向生产环境的功能增强,不断提升易用性和可靠性;另一方面也结合硬件设计能力,推出覆盖AI计算、云计算,企业园区全场景的系列化产品和完整方案,让开放网络变得“人人可用”、“开箱即用”

AsterNOS

AsterNOS与社区版对比AsterNOS 与SONiC社区版主要能力对比-表1
AsterNOS与社区版对比AsterNOS 与SONiC社区版主要能力对比-表2

数据中心(AsterNOS-DataCenter)

主要提供 L2/L3/VXLAN/Routing/EVPN 等云数据中心所需的各种功能,以及对智算等场景的RoCE、智能路由等特性的增强支持(未来也将主要基于此版本平滑支持下一代以太网协议,例如超以太网)。

51.2T 800G AI智算交换机软硬件系统设计全揭秘

企业园区(AsterNOS-Campus)

将SONiC的核心原则——开放性、易用性和灵活性引入园区。提供VXLAN 和 BGP-EVPN 虚拟化,实现灵活的逻辑网络编排;选定型号上采用 MPLS,可实现运营商级场景的无缝 WAN 集成;部分型号采用 PTP(精确时间协议),为关键应用提供高精度时间同步的网络。

从数据中心场景到园区网络,这不仅仅是“更换操作系统”,而是一次深度集成和系统级重构。我们针对资源受限的硬件平台(甚至是 1G 端口的接入交换机)移植并优化了SONiC,并围绕其他开放网络技术(例如OpenWiFi/OLS)提供端到端的新一代云化园区网整体解决方案。

开源开放技术栈下的园区多租户网络方案设计

最新实践:边缘路由(AsterNOS-VPP*)

从硬件角度来看,业界已有很多强大的基础平台如各类 DPU 网卡、高性能服务器或虚拟化主机;在软件方面,VPP等数据平面解决方案也已经显著成熟,两者共同为构建开放路由平台奠定了坚实的基础。

然而,SONiC 仍难以在这些新平台上提供完整的路由功能——市场上明显缺乏一种能够真正取代昂贵的封闭式黑盒路由器的商用级、成熟且用户友好的开放式路由解决方案。

AsteNOS-VPP 则是目前我们围绕SONiC的最新实践。具体而言是将 SAI 接口集成到 VPP 上,使基于 SONiC 的 AsterNOS 能够从交换机 ASIC 平台扩展到具有完整路由功能的 DPU 和服务器平台(如星融元ET系列:ET2500 系列开放智能网关平台) 。

VPP

AsterNOS 的交付模式

软硬一体化交付

AsterNOS可以运行在星融元自研的交换机硬件上,形成一体化的整机系统交付使用,用户享有厂商提供的一站式服务。

软件化交付

AsterNOS也具备运行在业界主流的白盒交换机硬件上的能力,因此也能以独立的软件形态交付给用户使用。当前主要兼容Celestica 和 Accton 两大品牌。

虚拟化试用 (vAsterNOS)

该模式的主要目的是便于用户快速了解AsterNOS、体验实际操作。即在星融元的私有环境里部署AsterNOS的虚拟化版本(vAsterNOS),并由管理元针对用户的试用要求搭建模拟网络,将操控权限交给用户试用。

如需获取本地运行的vAsterNOS(数据中心/园区版本),可自行下载 vAsterNOS;AsterNOS-VPP 试用,请与我们联系。

【参考文档】

A-Lab | 网工提效利器!面向 AI 场景的“向导式” 综合性规划工具


关注星融元


A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏,你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址:https://asterfusion.com/alab-for-netdevops/

今天我们介绍的是一套专为大规模 AI 网络环境搭建打造的综合性规划工具 EasyRoCE-AID (AI基础设施蓝图规划,AI Infrastructure Descriptor)。

它致力于为复杂的 AI 基础设施建设梳理脉络、把控全局,其核心价值在于通过系统性规划与整合,让抽象的网络架构和设备布局直观呈现,为技术人员提供清晰、精准的行动指南。


EasyRoCE Toolkit 是星融元依托开源、开放的网络架构与技术,为AI 智算、超算等场景的RoCE网络提供的一系列实用特性和小工具,如一键配置RoCE,高精度流量监控等…所有功能对签约客户免费开放。

详情访问:https://asterfusion.com/easyroce/


EasyRoCE

帮助网络架构师快速梳理智算环境的复杂需求,一站式规划参数、存储、业务管理和带外管理四张网

借助实用组网设计模板,自动计算并生成组网方案、设备互联关系和网络配置

一键导出 JSON 格式的设备互联关系数据,加速部署其他 EasyRoCE 系列工具插件,如GPU 节点内部路由规划(IRM)主动路径规划(PPD)多租户网络(MVD)以及实现与统一监控面板等(UG)相关的可视化呈现功能。

下面我们就逐步梳理一个典型智算中心基础网络的通用流程,来看 AID 工具是如何一步步引导用户完成高效且规范的部署动作。

步骤1:获取各类服务器基础信息

智算环境下的服务主要有 GPU 服务器、存储服务器、业务管理服务器三类,这一步需要手动向 AID 录入所有服务器硬件的设备名称、型号、功率、高度等等硬件信息。

服务器的网口数量和带宽规格,是后续规划网络的关键信息,另有部分信息(例如名称、高度)会作为 AID 中其他规划模块的引用对象。

步骤2:根据模板自动设计组网方案

有了上一步提供的服务器硬件信息,此时我们就可以根据集群规模大小,选择合适的“组网模板设计工具”(二层或三层,一般二层网络可满足大多数建网需求)。该设计工具本质上是从用户填写的 GPU 服务器、存储服务器、管理服务器和交换机规格信息,自动计算出每层所需的交换机数量。EasyRoCE Toolkit

EasyRoCE Toolkit

根据生成的组网方案,此时便可到AID对应位置去补充每台交换机的名称、型号、设备功率、设备高度、出厂序列号等信息。其中最大功率、设备高度等是后续规划设备分布的重要参数。

步骤3:确定机柜布局

该步骤依据设备性能特点、散热需求及数据交互逻辑,为实施规划人员制定机柜内部的最优空间分布方案提供参考。

机柜的布局信息包括机柜所在的园区、楼栋、楼层、房间、排/列、机柜编码、U#、设备名称。

点击左侧按钮展开,可以看到这排机柜的情况,其中机柜中每台设备的名称都引用于已填写的表格信息。

EasyRoCE Toolkit

步骤4:生成网络规划配置

经过上述步骤,智算环境下各个设备的互联关系也基本确定了。此时用户可运行 AID 内含的宏程序自动生成连接关系、自动填充互联 IP、服务器 Bond 口 IP、带外管理口 IP 等信息,快速完成参数网、存储网、业务管理网、带外管理网的规划配置,免去了人工计算的低效和潜在的错误风险。

EasyRoCE Toolkit

步骤5:与 EasyRoCE 工具模块对接

由AID规划配置的模块主要有,GPU Node内部路由规划器(IRM)、端到端路径规划(EPS)、主动路径规划(PPD)、多租户网络部署(MVD)等。

以主动路径规划工具(PPD)为例,我们使用 AID 工具规划交换机的设备名称、设备型号、设备角色、上行端口序号、下行端口序号、实例 ID、实例描述信息、下行 IP 列表、管理口地址、管理地址掩码、交换机的帐号密码.

其中除了实例 ID 和实例描述信息需要人为规划,其他字段都可以点击“填充设备信息”按钮完成自动填充。

EasyRoCE Toolkit

AID还可以联动基于 Prometheus+Grafana 的监控面板,辅助实现 RDMA 网络在大屏的可视化呈现功能。

参阅:一文解读开源开放生态下的RDMA网络监控实践

  • 拓扑自动呈现(TG)深度协同,依据设备互联信息,一键自动生成涵盖机柜内部、跨机柜乃至跨机房的完整网络拓扑图,精准展现设备层级关系、链路连接状态,以直观图形界面助力运维人员实时把控全网架构,迅速定位故障节点

云网扩容

  • 借助 光模块地图(TM),细致呈现光模块分布,明确各条光纤链路所用光模块状态信息,为光模块故障快速定位和提前预警提供重要参考

光模块地图

  • 联动 链路分布地图(LM),实时映射数据链路流量走向与负载分布,以动态可视化形式展现 AI 训练、推理等任务引发的流量潮汐变化,辅助优化网络资源分配,及时发现并化解拥塞风险

链路地图

更多AI智算网络技术分享,请持续关注星融元

产品与方案咨询:400-098-9811

优化WiFi体验!新一代园区网有自己的“流量瘦身术”


关注星融元


无线空口资源是连接物理层与网络性能的纽带,直接影响无线通信系统的容量、速率、稳定性、能效和覆盖能力。

让我们从“空口”说起

无线空中接口(Air Interface)简称“空口”,也称为无线电接口或 RF 接口,最早是来自电信领域的重要概念,指的是基站和移动设备相互通信的射频 (RF) 频谱。

我们可以类比有线网络去理解空口的概念。有线网络是通过线缆连接不同设备上的物理接口来实现信号传输,无线网络则是通过电磁波在空气中传播的,所以“空中接口”便是指的无线信号传输的接口,而在“空口”之间建立的链路就是无线链路。

无线空口技术涵盖了很多不同的技术和标准,如 LTE、Wi-Fi、蓝牙等,用以支持设备和网络基础设施之间语音、数据和视频的传输。

无线空口技术

在常见的企业无线局域网场景下,空口可以被简单理解为 AP 和各类无线终端/STA,以及和其他AP之间的虚拟逻辑接口。IEEE 802.11 标准在空口上定义了一组无线传输规范,包括每个无线信道的使用频率,带宽,接入定时和编码方法等等。

空口资源为什么重要?

无线空口资源是连接物理层与网络性能的纽带,直接影响通信系统的容量、速率、稳定性、能效和覆盖能力

首先,可用频谱是物理上有限的自然资源,且需通过国际协调和各国政府授权分配。高频段带宽大但覆盖差,低频段覆盖广但容量低,需平衡使用。

其次,空口资源分配策略直接影响同时服务的用户数和数据传输速率。如果空口上的多个用户同时发送数据包,产生了信号冲突会造成通信失败;此外,如果终端距离AP过远,无线信号微弱,网络吞吐量急剧下降,占用了空中接口时间,也会影响无线通信整体性能。

我们之前整理过的 Wi-Fi 6 核心技术,例如 1024-QAM 调制,改善多用户并发接入的OFDMA 和 MU-MIMO 等本质上都是在空口资源上做文章。

相关阅读:一文读懂:企业园区无线网技术及部署指南

空口利用率:无线网性能的关键指标

空口利用率是用来是指在一定时间内空口被有效数据占用的比例,也可以理解为无线信道的利用效率。一般50%左右的空口利用率是大多数常规企业局域无线网场景的一个合理阈值。

良好的空口性能需要综合采取一系列保护措施,例如避免碰撞,避退,降低冲突概率,调整 AP 无线信道,减少干扰,以及其他智能漫游和负载均衡等技术。

一般而言,采用更先进的无线标准协议,增加接入带宽和优化 AP 部署点位都能有效改善无线体验。但除此之外,无线网络场景还存在一些广播和组播报文,它们并不传输用户业务数据,却也会占用空口资源。具体有如下几类:

  • Probe Request 帧:由无线客户端发送,用于主动扫描周围的无线网络。也就是终端搜索信号的过程;
  • Probe Response 帧:由 AP 回应客户端的 Probe Request 帧,提供网络的具体信息。AP 响应中断的过程。达到负载也可能在这个环节拒绝终端的连接请求
  • DHCP 广播报文:设备通常通过 DHCP 协议获取 IP 地址 Discover、Offer、Request 和 ACK 报文都是广播报文,用于在无线网络中分配 IP 地址
  • ARP 广播报文:ARP (地址解析协议)广播报文用于将IP地址解析为 MAC 地址。在无线网络中, ARP 广播报文会占用空口资源,尤其是在设备较多的场景中
  • 组播报文:通常用于向多个设备发送相同的数据,如视频流或音频流,组播报文在无线空口以低速发送,且没有 ACK 机制保障,因此可能会占用较多的空口资源
  • 广播数据报文:如某些网络管理协议或服务发现协议(如 mDNS )会通过广播方式发送数据

用“减法思维”重构园区网络架构

通过引入云网中的先进理念和开放网络技术,星融元推出的云园区网络构造了一个全三层无广播的新一代云园区网络,从多维度节省了宝贵的无线空口资源,同时也降低整网的带宽波动和资源消耗、让网络更快更稳更安全。

campus network

  • 广播丢弃:终端发出的广播报文,除了 ARP 等协议报文会上送至交换机 CPU 处理,其余广播报文均会被丢弃;此举同时也隔离了发生在终端间的二层广播攻击,让网络更安全
  • 网关ARP代理:Leaf 层设备开启 ARP 代理(代答)功能,使用自身MAC地址快速对终端的请求完成代理,终端的访问均由网关转发,进一步抑制广播在网络中的传播(从连接终端的接口向上都是三层)。交换机不再进行大量广播泛洪动作,减低相关场景因为广播带来的资源消耗,进一步提升业务转发效率
  • ARP-TO-HOST:凭借 ARP-TO-HOST 能力,交换机将 ARP/NDP 表项转换为精确路由条目后进行路由转发
  • DHCP中继:终端的 DHCP 交互均通过交换机以单播形式代理转发,中继到 DHCP Server
  • 严格转发:AP 上使能严格转发,无线侧接口到的除组播报文外的所有报文均转发至上行口,避免无线侧的终端在 AP 上直接互访学习到终端真实的 MAC 地址,降低被攻击的风险
  • 广播转单播:AP 将从上行接口接收到的广播报文,查找本地的 IP 地址和 MAC 地址对应关系转换为单播报文,减少大量广播报文对空口资源的占用。如果终端不是直接连接在该 AP 下,就不再转发该报文,避免资源浪费

项目合作和产品方案咨询,欢迎拨打下方热线400-098-9811

或右下角小窗口联系我们~

实时解析和可视化呈现 GPU 集合通信路径


关注星融元


“黑盒”状态的集合通信

智算集群通常都是以GPU服务器为最小单位构建的,服务器内部安装了若干块GPU计算单元,在此之上会有CUDA、NCCL、PyTorch等软件系统协同构建AI大模型的训练/推理任务的基础环境。NCCL

目前最广泛应用的是英伟达的开源集合通信库 NCCL(NVIDIA Collective Communication Library),可以在英伟达的 GPU 芯片之间进行高效的数据交换和协同工作。其他云和 GPU 厂商也推出了一批 xCCLs,例如 HCCL、ACCL、TCCL 和 oneCCL 等

大模型的训练调优过程中,我们经常会遇到例如集群性能表现不如预期、训练任务中断现象,其原因除了来自模型自身或 GPU 服务器内部配置问题等等,还有可能是网络层面的数据传输。

然而,集合通信库位于开发框架之下,对于 GPU 集群的使用者来说,集合通信路径是透明无感知的黑盒状态

EPS 是什么?

EasyRoCE – EPS (E2E Path Scheduler,端到端路径规划)的主要功能是把集合通信库运行时不对外展示的各项关键信息,例如数据通信路径、任务中选用的 GPU、网卡状态等呈现给用户,帮助 GPU 集群的使用者快速定位问题,更好地利用集群的硬件资源,并基于此进行最佳路由规划。

对于 EPS 给出的推荐路由配置,用户可以自行决定是否下发。若确认选用推荐路由,EPS 可以调用 星融元 RoCE 交换机 提供的 REST API 完成配置自动下发。

  • 通信环可视化:自动解析通信链路信息,透传底层状态
  • 路由自动生成:算法和路径相关的路由推荐机制,配置自动下发
  • 辅助决策:底层通信信息集中到统一面板展示

EPS-EasyRoCE

如何使用 EPS?

本文提供的演示环境下,EPS 工具将会被部署在集群的 Master 节点(即产生 NCCL 日志文件的位置),并以 systemd 守护进程的方式在后台实时监控日志文件——每当日志更新,EPS 自动会解析最新的信息,转换为便于阅读和理解的形式推送到统一监控面板(如 EasyRoCE-UG )中集中呈现。

EPS 是星融元 EasyRoCE Toolkit 之一,以下仅展示基础功能,完整功能和最新版本请联系项目销售/售前人员。

1. 安装配置EPS

演示环境中的 Master 节点为一台独立的 CentOS 服务器,项目指定的工作目录为 /home/admin/EPS

安装配置EPS

2. 配置监控面板

演示使用 EasyRoCE Toolkit 内的统一监控面板(UG,Unified Glancer),在此之前需要提前完成该平台的部署,请参阅:一文解读开源开放生态下的RDMA网络监控实践 中的“监控平台配置”部分。

我们只需要为 UG 再添加一个呈现 HTML 的 Pannel,并完成 HTML 源的配置(如下图所示),EPS 解析出来的集合通信环信息就将作为各类 RDMA 网络相关监控指标信息的补充,辅助集群设施调优决策。

配置

完成以上所有步骤,我们就可以在 UG 看到实时更新的集合通信库运行信息,手动更新NCCL 日志文件,可以看到 UG 中呈现的解析信息也同步刷新。

配置

开源开放技术栈下的新一代园区网可视化运维实践


关注星融元


前言:近期我们已梳理过新一代园区网的主要概念和实现原理,介绍了这套方案区别于传统数通网络的新架构和理念,以及在真实场景中的效率表现。

前篇:

新一代云化园区之旅 进入这一阶段,我们已为一个中大型园区搭建好了云化后的基础网络,此后的管理维护工作将贯穿系统全生命周期。接下来我们将从可视化运维能力展开,分为以下三部分逐项介绍:

  • 网络可视
  • 告警管理
  • 巡检升级

网络可视

新一代云园区方案我们可提供两种不同层级的可视化能力。

一是对网络基础设施性能和运行状态的监控,借助控制器的图形界面得以呈现;

二是更细粒度的网络流量可视化,则是基于SONiC的 NPB 2.0 方案实现,该方案包含运行在交换机上 docker 应用和可选的开放架构的后端分析系统。

网络运行状态的集中呈现

星融元云化园区网络配套的 ACC 控制器(Asteria Campus Controller)擅长提供实时、多维度的监控,管理员能够在一处平台集中查看有线+无线网络的状态和配置信息。

我们使用 |健康值| 来评估各类网络设备的状态,这个数值由ACC综合评估各项指标进行智能计算得出。评估维度主要有:资源利用率,流量负载,硬件状态和运行情况;当监控指标超过指定阈值,则会自动生成告警信息通知管理员。

登录ACC后,在任意组织/场所界面下点击 |监控| 标签即可查看其下所有在网设备的健康状态,包含有线终端和无线终端。

有线、无线终端状态集中呈现

ACC

ACCACC

  • 终端生命健康状态、在线状态
  • 终端异常检测。例如终端仿冒会导致异常漫游,终端类型发生变化后根据策略将禁止上网和发送告警)
  • 关键操作回溯,便于定位故障,不用手动抓包

网络设备状态

ACC

ACC

  • 接口统计信息
  • PoE供电状态
  • 光模块运行状态
  • ……

基于SONiC的网络可视化:NPB 2.0

部分园区网络还要具备对网络流量的分析能力以满足更高的监控需求,传统方式一般是引入专门的NPB网络。

网络数据包代理(NPB)安装在流量采集点(或 SPAN 端口)与后端的安全和监控工具之间,其基本功能是协调网络数据包数据,以确保后端分析工具准确获得其所需的数据。

而在新一代云园区网中,我们支持在不改变现有网络架构的情况下,直接利用云园区交换机上的 |软件强化| 去配置一套实用的网络可视化系统,而无需再采购专门的网络硬件(例如TAP/分流器)单独部署NPB能力。

显而易见,这将会为园区网络节约一大笔短期建设支出,并降低专项运维成本。

园区交换机

那么什么是所谓的软件强化呢?简单说来即是在交换机运行的 SONiC NOS(例如星融元 AsterNOS) 上新增一个 Docker 形态部署的“NPB APP”,让园区交换机“身兼二职”——它既能是常规的交换机,完成L2/L3转发动作,同时也作为网络可视化前端设备,承担流量采集和向后端的策略分发工作。

而后端分析系统则可以采用开放硬件平台(如星融元ET系列和CX102S-DPU等)与开源 ntopng 工具协同提供服务。

102sntopng

ntopng是一个开源的网络流量探针软件,提供360°的网络可视性;它能够从流量镜像、Netflow导出设备、SNMP设备、防火墙日志、入侵检测系统收集流量信息。

告警管理

谈及告警管理,我们需要再次回到ACC控制器界面。

进入 ACC |组织/场所|下最右侧的|运维配置|标签,管理员可对特定范围配置需要关注的告警信息、阈值,以及接收通知的邮箱地址,并将已有告警设置一键同步到其他指定组织/场所。

所有告警信息可以在左侧面板的告警栏目下统一查看,包括当前告警和历史告警信息。

ACC

目前最新的控制器版本已支持的告警内容包括接口状态切换,接口模块状态,带宽利用率、用户表项(ARP、主机路由、MAC)资源的利用率,RADIUS 服务器、Portal服务器状态,BGP、BFD连接状态,以及CPU风扇电源等硬件信息等。

巡检与固件管理

设备巡检功能旨在定期检查和监控网络设备,以确保其正常运行并及时发现潜在故障。其主要功能包括:

  • 设备状态监控:检查CPU使用率、内存使用率、存储情况和端口状态
  • 日志与告警管理:收集设备日志,分析异常事件,并触发告警机制
  • 关键进程状态检查:监控关键进程的运行状态
  • 自动化巡检任务:按照固定时间间隔定期执行巡检任务,生成巡检报告
  • 所有告警信息可以在左侧面板的告警栏目下统一查看,包括当前告警和历史告警信息。

ACC

定期升级设备固件有助于维持网络系统的性能和安全,ACC具备的固件管理功能可对上传到控制器的不同版本镜像和补丁文件进行自动化的信息整理、解析验证,最后在管理员确认后完成批量下发。

ACC

园区产品

完整流程揭秘:30分钟搞定中大型园区网络业务开通,可行吗?


关注星融元


30分钟,从无到有,为中大型园区开通有线无线两张业务网,并在一个平台集中管理?

以上绝非夸夸其谈,如果是星融元新一代云化园区网,简直易如反掌!

我们使用全盒式SONiC交换机(Asterfusion CX-M系列)构建了深度云化的园区网络:采用更精简的Spine/Leaf 架构+统一的BGP路由 作为底层网络,依靠单一的云园区控制器(Asteria Campus Controller,ACC)即可快速完成整网的有线无线业务配置——体感近似于“即插即用”

ACC

只需三步

前篇我们已经介绍了一些概要,如果你此前对 TIP OpenWiFi 和 ACC 没有了解,建议先回顾一下:

完整揭秘:新一代园区网络运维管理全流程

配置前,园区网管理员需要将设备信息导入控制器指定组织/场所,按照拟定的网络规划给设备插线上电,后续操作都已高度自动化。

  1. 整网设备连接控制器(借助 DHCP option 自动获取控制器IP地址)
  2. 根据所选场景模板,控制器自动生成拓扑并完成基础网络配置(对用户屏蔽了技术细节,控制器自动计算BGP互联地址并完成整网路由配置)
  3. 开通有线网和无线网业务(基于控制器预置/自定义模板,图形界面一键批量下发)

第一步:设备自动连接控制器

设备上电后,可分两种情况讨论:

网络中已有DHCP Server —— 自动连接

星融元Asterfusion所有设备(包括交换机和AP)都可以作为 DHCP 客户端,出厂默认配置下即会自动发起DHCP请求,从网络中的DHCP Server 获取到 地址和控制器 IP 地址。

自动连接

#为了保证设备能获取到控制器的IP地址
#DHCP Server 需要能响应 option138 字段
#以下是 sc-dhcp-server 的配置参考
subnet 192.168.1.0 netmask 255.255.255.0{
range 192.168.1.100 192.168.1.200;
option routers 192.168.1.1:
option subnet-mask 255.255.255.0:
option capwap-ac-v4 “192.168.10.1” #控制器IP地址

网络中没有DHCP Server ——手动连接

很多初始状态的园区网络场景并没有DHCP服务器,此时我们只需串口接入一台Spine交换机,使能交换机上运行的ucentral-client 容器,并指定控制器IP。

该交换机连接上控制器后会自动从控制器处拿到用来配置其他Leaf交换机的文件,从而让整网设备都同控制器建立起连接。

sonic# config
sonic(config)# ucentral-client enable
sonic(config)# ucentral-client server 192.168.10.1 #控制器IP地址

第二步:自动生成拓扑和基础网络配置

完成设备与控制器连接后即可进入到控制器的规划拓扑标签下新建场景。

ACC控制器内置了名为中小型园区和中大型园区两种场景模板,两者都为Spine-Leaf架构的三层IP路由网络。

区别主要是后者在Spine和Leaf之间添加了一层Aggregation,从而轻松将Leaf交换机数量横向扩展到千台以上来适应更大规模的园区网络。

ACC

管理员仅需根据已拟定好的网络规划选择适合的模板,并设置交换机的对应型号、Spine/Leaf角色和数量,即可自动生成上述典型场景的推荐拓扑。

如下图所示,在生成的拓扑图上点击设备旁的编辑按钮即可继续设置各个互联端口。

ACC自动拓扑

最终效果可参考下图:场景组网下的设备上线状态、链路和接口关系一览无余。

上线状态

此时点击右上方的基础网络配置,即可配置业务网的静态出口路由,或者Spine上行出口链路所使用的动态路由,例如BGP、OSPF、路由汇聚等。

整个过程,用户除了提供IP地址等基础信息,无需关注其他技术细节,ACC控制器将会根据网络拓扑动态生成所需配置。

第三步:批量配置无线和有线业务

无线业务配置

ACC允许用户在设备上线前创建预置配置模板。

点击无线配置标签下的Wi-Fi设置,为无线 AP 配置业务开通必要的基础信息,如 SSID 设置、安全策略等。控制器可以根据管理员的输入,自动生成相应的配置脚本。

控制器支持配置多个无线业务配置,并通过标签区分 (上图示例为default)。无线 AP 接入PoE交换机自动上线并连接到控制器后,便会根据导入库存时设定的标签信息自动拉取与标签一致的配置

无线配置

对于特定场景,管理员也可在高级配置中自定义更改AP的默认配置。

LANs

当部分 AP(比如面板型 AP)提供的有线接口接入了有线终端,用户也可以在LANs处配置诸如上下行接口、VLAN tag、VLAN ID 等信息。

ACC

有线业务配置

与无线业务类似,ACC控制器可在有线业务配置标签下快捷完成配置脚本的生成和下发。可选设置项包括交换机的 VLAN、 DSCP 中继、ACL、DAI/IPSG、802.1x 用户认证信息等。

ACC

ACC

ACC

点击上图“配置”按钮,等待所有执行完毕,我们就已完成园区有线无线业务的开通。根据客户现场测算,以上操作平均用时在30分钟左右。此时整网的交换机、无线AP以及各类终端状态信息皆可在控制器内统一、集中地呈现,用以辅助日常运维管理。

ACC

关于新一代云园区网的可视化运维管理功能,例如设置告警、执行巡检等等我们将在下一篇详细介绍,请持续关注。

A-Lab 杂谈 | 自动化+可视化的智算中心多租户网络配置工具


关注星融元


A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏,你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址:https://asterfusion.com/alab-for-netdevops/

论是在通用云数据中心和智算中心,多租户网络的目标都是要允许多个用户或租户共享同一物理基础设施,同时保持各自的隔离和安全性。

多租户网络依赖于虚拟网络技术(如 VLAN、VXLAN 或 NVGRE)实现逻辑隔离。随着部署规模的增大,这些技术的配置和维护可能变得复杂,如果配置不规范,可能导致租户间冲突影响业务运行甚至严重的数据泄露。

今天我们分享的是一款用于多租户网络的配置工具:EasyRoCE-MVD(Multi-Tenant VPC Deployer )。作为星融元AI智算网络方案的附加能力之一,MVD 帮助用户快速实现租户隔离,参数、存储、业务的多网联动和自动化部署。

EasyRoCE Toolkit 是星融元依托开源、开放的网络架构与技术,为AI 智算、超算等场景的RoCE网络提供的一系列实用特性和小工具,如一键配置RoCE,高精度流量监控等… 详情访问:https://asterfusion.com/easyroce/

EasyRoCE Toolkit MVD

  • 根据配置脚本自动批量部署,支持图形化界面呈现配置细节并远程下发
  • MVD工具可独立运行在服务器上,也可以代码形式被集成到第三方管理软件

业务架构

多租户网络架构由 Underlay 网络和 Overlay 网络组成。

Underlay 网络指的是物理网络设施,由交换机、光缆等网络硬件构成,负责底层数据的物理传输,运行高效的路由协议(如 BGP)实现互联,通常采用 Spine-Leaf 架构组网,负责提供提供稳定带宽、低延迟和高可靠性,这是多租户网络的基础。

Overlay 网络是在 Underlay 网络之上构建的虚拟网络,解耦了物理网络与业务需求,为每个租户提供独立的网络空间(如子网、IP 地址、路由)用于实现租户隔离和自定义网络配置,是多租户网络实现的技术核心。

网络设计规划

首先是必不可少的网络规划,这一步需由工程师基于实际业务需求设计逻辑隔离,一般是采用 VLAN、VXLAN 技术划分虚拟网络,规划 IP 地址池及子网,避免地址冲突。VLAN 适合较小规模,而 VXLAN 扩展性更好,适合大规模部署。

作为示例,我们在EasyRoCE-AID(AI基础设施蓝图规划)工具引导下快速完成网络设计,并自动生成包含了以下信息的 JSON 配置文件(mvd.json) 作为 MVD 工具的输入。

form

自动生成配置

MVD 工具将解析上一步骤得到的JSON文件中的设备信息、BGP邻居信息,并为集群中的交换机生成对应配置。 运行过程示例如下:

配置过程

可视化呈现和远程下发

MVD 运行时会以 Exporter 形式将以上配置信息暴露于http监听端口(如18080,18180),该数据可被 Prometheus 调用并将其呈现在 Grafana 界面上,供用户直观浏览现网设备的拓扑信息。 

配置远程下发

用户点进配置文件可看到配置下的具体信息,对其进行二次核对后再自行决定下一步操作,比如选择批量下发或针对某一设备单独下发。

相关产品

星融元(Asterfusion)AI智算网络解决方案采用基于SONiC的开放NOS(AsterNOS)+ 100G-800G 超低时延以太网交换机硬件,全端口支持 RoCEv2 & EasyRoCE Toolkit。如需了解产品详情或项目定制方案请与我们联系。

完整揭秘:新一代园区网络运维管理全流程


关注星融元


前言:传统网络面临的结构性挑战显而易见,尤其是多地多分支机构的大型园区网络,哪怕引入了一个大而全的SDN控制器,但底层仍沿用着复杂的园区网络架构,有线无线两张网分离控制,真实使用体验依旧差强人意。

新一代的园区网应该是什么样的?且不论未来如何,在放眼可见的当下,除了承载常规的办公网业务,园区的网络基础设施已然在面对诸如物联网智能终端接入,频繁的无线漫游,以及各类公有云、本地私有云业务融合等等挑战。

园区网络的云化转型已成必然趋势。论及云化,不单是更高的带宽速率,更是要配合现代化的网络架构和灵活的运维方式,解决复杂业务和管理效率之间的矛盾。

TIP:电信业“开源运动”领导者

TIP(电信基础设施项目)成立于2016年,由Meta(原Facebook)联合多家全球电信运营商、技术公司和行业组织发起,是一个开放协作的行业联盟。其核心目标是推动电信基础设施的开放解耦化和软件化,通过技术创新降低网络部署和运营成本,加速全球通信网络的普及与升级。

TIP 推出的 OpenWiFi 和 OpenLAN Switching为企业园区网络场景带来了基于通用硬件和开源软件的解决方案。

uCentral 作为 OpenWiFi 通信框架的关键核心,是一种标准化数据模型,它定义了网络中关键配置数据的结构和语义,以确保整个网络的一致性和互操作性,并且该协议是开放可扩展的,随社区技术发展平滑演进。

OpenLAN Switching(OLS) 将 OpenWiFi 的管理框架延展到了有线网络,显著扩展了OpenWiFi 的功能。实现形式是在交换机内部以容器形式运行一个客户端(uCentral Client),将有线网络纳入统一管理框架中。

OpenWiFi、OLS、局域网(LAN)

OpenWiFi和OLS 在局域网(LAN)中扮演各自不同角色,通过统一的北向接口与上层管理系统(Cloud SDK )对接,并可复用成熟的开放网络组件(例如SONiC NOS)形成有线+无线、完整的端到端开放网络解决方案

Asteria Campus Controller(ACC) 是星融元基于SONiC+ OpenWiFi/OLS 的云化网络的核心组成部分。

作为一款基于TIP社区标准的轻量级控制器软件,ACC 为园区有线网络和无线网络的统一管理提供了全面的解决方案。它可以无缝管理无线AP(包括第三方白盒AP)和所有搭载着星融元AsterNOS的SONiC交换机,自动执行网络配置和管理等关键任务。正常情况下,为一个中大规模的园区开通网络业务仅需30分钟。

部署方式

ACC支持三种部署方式:

  • 本地部署(以docker形式部署在开放计算平台/服务器)
  • 虚机部署(部署在虚拟机内,网络设备较多时适用)
  • 云上部署(通过访问IP/域名,随时随地查看整网运行状态)

01、ACC 界面概览

登录ACC控制器后我们首先会看到一张全景地图,可以看到控制器纳管的网络自顶向下分为“根节点-组织-场所-设备”四个逻辑层。

ACC

(点开查看gif)

  • 根节点作为系统默认节点,不可调整;
  • 根节点下可建立“组织”,可以简单理解为一个管理域(例如一家公司或园区运营者可支配的管理范围);
  • “组织”下可建立“场所”,对应着不同的办公区域或者分支机构;“组织”支持嵌套结构,即建立子组织,并继续建立子组织下的“场所”;
  • “场所”之下是设备层,展示了分配在该场所的物理网络设备,一般是按照有线设备(交换机)、无线设备(AP)分组。

02、内生的资产管理能力

值得一提的是,控制器内部自带了较为完善的资产管理能力,标准使用流程下即可自动完成数据整理并生成设备清单。

具体来说,我们购入新设备做的第一件事便是进入预计安装部署的组织或场所,比如下图的“1号办公楼”,在库存栏目点击按键选择手动导入设备或者基于模板批量导入。

此处导入的信息主要是设备的角色类型(Spine或Leaf)和序列号。待设备上电,控制器会自动根据设备的MAC将其纳入所属的组织/场所,并无额外操作。

截图

导入完成后便可获得下面这张设备清单,它包含了设备所在场所、型号、名称、管理IP、许可证状态等信息字段。管理员可在此选择特定字段筛选,并在同一界面编辑调整清单信息。此处的“标签”字段对应的是控制器的配置模板,后续设备将据此标签信息从控制器拉取对应配置文件,做到真正的即插即用。

截图

03、ACC带来的运维效率提升

上文已经提到,使用ACC为一个中大规模的园区开通网络业务仅需30分钟,开局效率的大幅提升主要来自于以下几点:

  • 基于场景模板(全三层的Spine-Leaf 架构)自动生成规划拓扑
  • 屏蔽实现细节,由控制器自动计算并通过ZTP机制下发基础网络配置
  • 借助DHCP option 128 为交换机和无线AP同时提供“即插即用”的能力
  • 图形化界面+自定义脚本,一键配置VLAN业务,DHCP中继,以及其他安全协议

下一篇我们将围绕上述内容详细展开,请持续关注。

A-Lab 杂谈 | 十年老网工,为啥这次没把智算服务器一次配通?


关注星融元


A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏,你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址:https://asterfusion.com/alab-for-netdevops/

十年弹指一挥,当年的爆款热词“云计算”已然能搭上“传统” 二字当前缀;

十年弹指一挥,机房滚滚轰鸣声中,网工小王不知不觉熬成了老王;

老王不解啊,十年弹指一挥,咱亲手上架的服务器不说上千也有大几百,不就多了几张网卡,配个智算服务器怎会卡了壳?!

客官别笑,通用云计算中心与智算中心在主机侧网络架构层面的确存在显著差异,老网工偶尔走点弯路也是在所难免的啦。今天就让我们快速捋一捋其中缘由。

为啥出错?

传统CPU服务器多采用单网卡出口设计,通过OS内核协议栈实现网络报文转发,其网络拓扑相对简单,主要满足虚拟化资源的弹性调度需求。

源于AI训练任务对网络带宽的严苛要求,智算中心的GPU服务器普遍采用多网卡出口架构,用于接入参数网、存储网、业务网和带外管理网,其中通常会有8张网卡用于接入参数网,或称计算后端网络。而跨服务器的通信大多发生在同轨(Rail)的网卡/GPU之间。(请参考:关于智算的“多轨道网络架构”

多轨道网络架构

老王遇到的机间通信失败问题主要发生在以下两种场景:

场景1

智算业务报文从管理网段发出。两台GPU服务器A和B的8张网卡都接入到一张参数网,对应的网卡A1到A8、B1到B8,它们都分配到不同的网段,同轨网卡之间有互通需求(A1-B1,A2-B2…)

如果没有进行路由规划,通常在GPU服务器A的系统上会看到默认路由是业务网的,8个子网A1~8会产生8条对应的网段路由,报文会命中A的默认路由从管理网段发出,此时A1和B1是无法直接通信的。

场景2

回程通信失败。如果网卡A1到A8、B1到 B8 都分配到同一个网段下的不同IP,在这种情况下在服务器B上通过B1尝试与A1通信,会发现报文可以到达A1,但是回包会命中默认路由之外的代价最低的路由,很可能会从其他7张网卡中的一张出去,导致通信失败。

通信失败情况下可能的系统路由配置:

路由配置

应对思路

当传统路由设置方法在智算环境下失效,一个可行的应对方式是提前规划GPU服务器内的路由,借助Linux的多路由表和策略机制实现更加灵活、精细的流量控制和路由管理功能。

具体而言:在Linux内增加一个自定义路由表,并通过策略路由告知系统,特定源地址的报文根据这张自定义路由表转发,并在该表中增加一条指定目的网段的表项(例如前往10.0.5.0/24的报文从指定网卡发出)。

  • 多路由表(Multiple Routing Tables):Linux支持多张路由表,这些路由表可以通过不同的标识符来区分,每张路由表中可以包含一组路由规则。Linux系统默认会存在一个主路由表,当不特别指定的时候路由规则会写入默认路由表。
  • 策略路由机制(Policy Routing):根据数据包的源目的IP、网卡等条件来选择合适的路由表进行转发。

更高效的实现方式

更高效的办法,当然是用脚本工具批量自动配置啊!

星融元(Asterfusion)AI智算网络解决方案中包含的EasyRoCE Toolkit – IRM工具(In-Node Route Map,GPU服务器内部路由规划)正是用于解决多网卡路由问题——根据已有的IP地址规划表,自动生成并对集群内所有GPU服务器下发内部路由规划和配置。

IRM工具运行过程中需要通过SSH和集群中的所有GPU服务器进行交互,一般运行在管理节点上。

GPU服务器内部路由规划

网工老王仅需完成三步微操:

1、将IRM工具上传到管理节点;

2、指定需要解析的路由规划信息文件。该文件可在EasyRoCE-AID (AI Infrastructure Descriptor,AI基础设施蓝图规划)工具引导下手动填写,形式为下图所示的excel表格,主要包含IP和接口地址规划、Rail平面划分等构造智算网络的必备信息;

IP和接口地址规划、Rail平面划分

3、运行IRM工具脚本。等待上述规划信息完成转换重组后,IRM工具会生成包含路由配置的JSON文件并下发到集群,随后网络运维人员即可查验到所有GPU服务器内部的策略路由都已成功生效,同一个Rail平面内的网段按照预期正常互通。此外,该阶段生成的JSON文件亦可复用于其他客户自定义/第三方工具。

DeepSeek优化徒劳?揭秘99%的AI推理集群都适用的组网设计


关注星融元


DeepSeek的优化,精细但门槛极高

作为开源周的“彩蛋”,DeepSeek于上周六展示了采用混合专家模型(MoE)DeepSeek-V3 / R1 所使用的推理架构的整体方法——从增大吞吐和降低时延的目标出发,再次优化了PD分离架构,不过暂时没有开源代码。

(MoE)DeepSeek-V3 / R1

与Llama等采用张量并行(TP)的Dense(稠密)模型不同,混合专家(MoE)模型通过组合多个专家模型来处理复杂任务,每个专家模型专注于输入数据的不同部分,每次计算任务只需激活特定专家(而非整个神经网络)。

DeepSeek-V3 / R1 的推理系统架构一方面引入了更复杂的跨节点和多节点的传输提升计算效率和改善内存墙,同时也通过异步通信和流水线调度设计,确保由此增加的通信开销被计算任务掩盖。

值得注意的是,根据官方公布的信息,若要充分发挥DeepSeek MoE 模型的能力,起步资源是320卡,且不论在未开源的情况下面临的技术挑战。

综合成本和需求考量,上述面向专家并行的推理系统优化仅在部分toC云计算场景具备一定研究意义。现阶段toB行业大模型以及边缘计算场景仍以Dense模型为主,需要高并发的大集群平台部署可延续现有主流的算力网络设计思路,面向本地低并发需求则可采用大内存单机部署方案。

回顾:AI推理集群的PD分离和流量特征

大模型的推理任务一般分为两个阶段,一是Prefill,处理所有输入的 Token,生成第一个输出 token 和 KV cache,是算力密集型;二是Decode,利用 KV Cache 进行多轮迭代,每轮生成一个 token,需要反复读取前面所有token的 Key 和 Value,瓶颈在于内存访问。

从用户实际体验层面看,推理过程中最关键的指标是 “第一个Token的延迟” (Time To First Token, TTFT) 和后续token输出的延迟(Time Per output Token, TPOT)。

如果 Prefill 和 Decode 两个阶段在同一张GPU卡上运行,则容易发生资源争抢影响到 TTFT 和 TPOT 表现,尤其是当用户输入一段长 prompt 时,不光需要较多算力来支撑prefill运算, 也需要大内存来存储 KV Cache。

 Prefill-Decode

因此,业界通常采用 Prefill-Decode 分离的架构:用高算力卡做 Prefill(prefill server), 低算力卡做 Decode(decode server), Prefill节点在完成计算传输 KV cache 后即可释放本地显存。

参阅:一文揭秘AI智算中心网络流量 —AI推理

AI推理系统的 Scale-out 组网设计

推理集群的工程部署方面,由于 Prefill 和 Decode 采用的GPU并行方式不一样,Prefill和Decode集群是相互独立的,但两个集群间需要互联以同步KV cache。从两个阶段的输入输出来看,Prefill 流量的特征是低频大流量,要求大带宽;Decode 阶段流量的特征是高频小流量,要求低时延。

1、分离网络架构

  • 分为Prefill网络和Decode网络,分别负责本集群内流量,两个集群之间的流量通过互联网络实现
  • 两个网络分别运维管理,但Prefill和Decode GPU之间的流量至少需要3跳

2、统一网络架构

  • 单个网络同时负责集群内和集群间流量
  • 网络统一运维管理,Prefill和Decode GPU之间流量可一跳直达

统一网络架构

我们推荐采用统一网络架构,借助 QoS、自适应路由技术对 Prefill 和 Decode 流量分别处理。

Rail-only 拓扑

Rail-Only

  • GPU服务器内部:每四个GPU作为一组,共享一个并行推理网卡,连接到同一个PCI Switch,两组GPU之间的通信通过两个PCI Switch之间的直连通道完成;
  • GPU服务器之间:同一组号的GPU之间的通信通过交换机直接完成;不同组号的GPU之间的通信,先通过PCI Swtitch将流量路由到另一组的网卡,然后通过交换机完成

小规模并行推理网络拓扑

小规模并行推理网络拓扑

  • 每台推理服务器有8张GPU,2张400G网卡,双归连接到两台CX732Q-N
  • 16个推理服务器(128张GPU)和2个CX732Q-N组成一个PoD。Prefill和Decode服务器可能属于不同PoD
  • 可横向扩展至64个PoD

中大规模并行推理网络拓扑

  • 中大规模并行推理网络拓扑每台推理服务器有8张GPU,2张400G网卡,双归连接到两台CX864E-N
  • 64个推理服务器(512张GPU)和2个CX864E-N组成一个PoD,Prefill和Decode服务器在同一个PoD,服务器间一跳可达
  • 可横向扩展至64个PoD

拓扑设计仅供预览参考,方案均采用星融元(Asterfusion)提供的CX-N系列 AI智算网络产品:基于SONiC的开放NOS(AsterNOS)+ 100G/200G/400G/800G 超低时延以太网交换机硬件,全端口支持 RoCEv2 & EasyRoCE Toolkit。了解产品详情或项目定制方案请与我们联系。

对星融元产品感兴趣?

立即联系!

返回顶部

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