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

标签： A-lab-AI&HPC

0成本5分钟！利用开源大模型搭建本地专属AI知识库

关注星融元

你一定经历过各种通用大模型一本正经胡说八道的时候吧，AI一通丝滑输出让人真假难辨，防不胜防。这种情况被称为AI幻觉。

大模型产生幻觉不幸“翻车”的原因很大程度上是“先天不足”，例如训练时来自特定领域的训练数据就比较缺失或存在偏差等。对于企业，AI的幻觉已经成为阻碍其落地应用的严重缺陷。

我们自然想让一些企业内部私有数据也进入到大模型推理分析的过程，让其更好服务于日常业务，但出于信息安全等考量，私有数据显然不可随意上传到第三方平台。针对这种情况，将企业内部知识库和大模型连接起来构建一个本地私有化的专属的AI知识库不失为一种简易的解决方案。

构建本地私有知识库的基本步骤

1. 整理出需要模型分析的私有数据，比如文本数据（doc、csv、ppt…），音视频数据，甚至一些网址链接。

2. 通过一个嵌入模型将这些信息转换成模型能够看得懂的向量信息，即信息的向量化。

3. 将向量化的信息存储到专属的向量数据库中，构建本地知识库。

这个时候当用户提问时，我们引入的通用大模型将会结合本地知识库中所存在的信息有针对性的回答，甚至也可以专门分析本地知识库中的信息来输出。

本地私有知识库构建

本地AI知识库的安装和配置

AnythingLLM 是一款构建本地知识库的工具，能够直接读取文档并处理大量信息资源，包括文档上传、自动抓取在线文档，然后进行文本的自动分割、向量化处理，以及实现本地检索增强生成（RAG）等功能。

AnythingLLM支持几乎所有的主流大模型和多种文档类型，可定制化程度高，安装设置简单，适用于MacOS、Linux和Windows平台，也可以使用Docker安装。AnythingLLM默认通过Ollama来使用LLama2 7B、Mistral 7B、Gemma 2B等模型，也可以调用OpenAI、Gemini、Mistral等大模型的API服务。除AnythingLLM以外，近期较为热门的知识库工具还有MaxKB、RAGFlow、FastGPT、Dify 、Open WebUI 等。

01、下载并安装Ollama（用于下载各类通用大模型）

访问 https://ollama.com/download 选择所需版本

下载安装Ollama

02、安装大模型和嵌入模型

我们示例中选择的是通义千问大模型和M3e嵌入模型，大家也可以根据自己的需要选择其他模型下载。Ollama支持的模型列表及资源占用情况可从官网查阅：https://ollama.com/library

安装大模型

嵌入大模型

03、下载并安装AnythingLLM

访问 https://anythingllm.com/download 选择对应版本

下载AnythingLLM

04、配置AnythingLLM

配置参数选择Ollama

配置Ollama

Embedder选择M3e

Embedder选择M3e

向量数据库选择LanceDB（默认）

向量数据库选择LanceDB（默认）

上传私有数据并验证AI问答效果

至此，一个AI驱动的本地私有知识库的基本架构已经搭建完成。接下来我们需要创建工作区，上传各种文档格式的企业私有数据，验证是否能正常工作。

上传

上传

上传

01、csv表格

随意生成一份原始数据如下：

对话结果（对数据进行排序和筛选）：

02、docx文档

原始数据是星融元AsterNOS网络操作系统的文档，其中涉及到高可靠特性的部分如下。

文档

对话结果：

结果

03、网址

星融元CX-N超低时延交换机在官网的产品详情页，涉及到产品特性的片段如下。

特性

对话结果：

检验结果

可以看到，这个本地AI知识库已经在利用我们上传的私有文本数据回答问题了，下一步您需要持续不断地丰富私有内容，让其更加智能、可靠；大型企业则更需要对其“悉心调教”，例如充分考虑本地AI推理系统的并发接入性能，在网络基础设施上进行相应调整和升级，也要关注和其他内部工具的集成。

AsterNOS监控方案

1 AsterNOS监控方案

1.1 方案概述

本文档将简要介绍AsterNOS监控方案及其各组件功能，并完成对Asterfusion CX-N系列超低时延云交换机的配置和数据采集。

1.2 整体逻辑方案图

AsterNOS监控方案逻辑图
图1：AsterNOS监控方案逻辑图

1.3 各组件功能

  • Alertmanager：主要用于接收Prometheus发送的告警信息，并及时地将告警信息发送到PrometheusAlert进行转发。
  • PrometheusAlert：运营告警中心消息转发系统，支持主流的监控系统Prometheus以及所有支持WebHook接口的系统发出的预警信息，支持将收到的信息通过WeChat、Mail、飞书、短信等渠道推送。
  • Grafana：是一个开源的监控数据分析和可视化套件，最常用于对基础设施和应用数据分析的时间序列数据进行可视化分析。
  • Prometheus：Prometheus是一个开源的系统监控和报警系统，同时支持多种Exporter采集数据，Prometheus性能足够支撑上万台规模的集群。
  • SNMP Exporter：通过SNMP协议中用不同的OID区分不同的状态数据，OID非常类似于Prometheus中的指标的概念，SNMP Exporter通过从Agent查询指定的OID数据，同时将数据映射到可读的指标上，实现SNMP数据到Prometheus指标的转换，大部分场景下用户无需额外配置即可将OID转换为可读的指标数据。
  • Node Exporter：多用于收集内核公开的硬件或操作系统指标，监控设备的CPU、内存、磁盘、I/O等信息。

2 组网方案

2.1 软硬件信息

名称版本备注
监控节点CPU：48 Cores
内存：128 GB		Prometheus、Alertmanager Grafana
服务器系统CentOS Linux release 7.9.2009 (Core) 
AsterNOSAsterNOS Version 3.1 R0402P02 
Prometheusprom/prometheus:v2.37.0 
Alertmanagerquay.io/prometheus/alertmanager 
Grafanagrafana/grafana-oss:9.0.6 
Node ExporterNode Exporter:v0.3.0SONiC Node Exporter
SNMP ExporterSNMP Exporter:0.24.1 
表1：软硬件版本信息

2.2 监控系统规划

主机名节点IP节点角色
监控节点管理口：10.240.5.223
Promehteus：9090 Alertmanager：9093 Grafana：3000 PrometheusAlert：8080		Prometheus、Alertmanager、Grafana、PrometheusAlert
AsterNOS管理口：10.230.1.10 Node Exporter：9100 SNMP Exporter：9116Node Exporter、SNMP Exporter
表2：监控规划

3 监控组件部署

3.1 Node Exporter

在每台被监控交换机上部署Node Exporter，用于收集内核公开的硬件或操作系统指标，监控交换机的CPU、内存、磁盘、I/O等信息。Node Exporter监听本地9100端口。

root@sonic:~# version=$(curl -s https://api.github.com/repos/kamelnetworks/sonic_exporter/releases | jq '.[0].name' -r)
root@sonic:~# sonic-package-manager install   \
--from-repository "ghcr.io/kamelnetworks/sonic_exporter:${version}" \
--enable
root@sonic:~# config feature state sonic_exporter enabled
root@sonic:~# config sonic-exporter port 9100
root@sonic:~# netstat -nlp |grep 9100
部署Node Exporter
Docker方式安装：
root@sonic:~# docker run -d  --net=host \
-v /run/redis/:/var/run/redis/ \
--name roce_exporter sonic_exporter:0.3.0

3.1.1 Node Exporter Metrics

浏览器访问设备的9100端口，查看采集的数据。

查看采集的数据
图2：Node Exporter采集数据

3.1.2 Node Exporter 自定义监控

通过Node Exporter的Textfile插件完成自定义监控，自定义脚本并把内容以Key:value的方式写入以.prom结尾的文件，定时任务执行自定义脚本，添加启动参数，Node Exporter采集数据。

root@sonic:~# ./node_exporter \
--collector.textfile.directory='/home/admin/Prometheus/’
root@sonic:~# cat /home/admin/Prometheus/asternos.prom
#HELP example_metric read from /path/example.prom  
#TYPE example_metric guage  
example_metric 1

3.2 SNMP Exporter数据转换

在每台被监控交换机上部署SNMP Exporter，SNMP Exporter通过Agent查询指定的OID数据，同时将数据映射到可读的指标上，实现SNMP数据到Prometheus指标的转换，完成监控私有数据开发。SNMP Exporter监听本地9116端口。SNMP Exporter文件下载地址：https://github.com/prometheus/snmp_exporter/releases/download/v0.24.1/snmp_exporter-0.24.1.freebsd-amd64.tar.gz

SNMP完整配置文件：

snmp.yml
root@sonic:~# tar -xvf snmp_exporter-0.24.1.linux-amd64.tar.gz
root@sonic:~# cd snmp_exporter-0.24.1.linux-amd64
root@sonic:~/snmp_exporter-0.24.1.linux-amd64# cat snmp.yml
auths:
  public_v2:
    community: public
    security_level: noAuthNoPriv
    auth_protocol: MD5
    priv_protocol: DES
    version: 2
modules:
  AsterNOS:
    walk:
    - 1.3.6.1.2.1.2
    - 1.3.6.1.2.1.31.1.1
    get:
    - 1.3.6.1.2.1.1.1.0
    metrics:
    - name: asterSysRunTime
      oid: 1.3.6.1.4.1.56928.25.1.1
      type: gauge
      help: AsterNOS CX-N switch Device operating time
    - name: asterPortHighSpeed
      oid: 1.3.6.1.2.1.31.1.1.1.15
      type: gauge
      help: AsterNOS CX-N Port negotiation Speed
      indexes:
      - labelname: asterPortIndex
        type: gauge
      lookups:
      - labels:
        - asterPortIndex
        labelname: asterPortAlias
        oid: 1.3.6.1.2.1.31.1.1.1.18
        type: DisplayString
      - labels:
        - asterPortIndex
        labelname: asterPortDescr
        oid: 1.3.6.1.2.1.2.2.1.2
        type: DisplayString

root@sonic:~/snmp_exporter-0.24.1.linux-amd64# ./snmp_exporter &

3.2.1 SNMP Exporter Metrics

浏览器访问设备的9116端口，查看采集的数据。Moudle：AsterNOS。

图3：SNMP Exporter采集数据

3.2.2 SNMP Exporter Metrics（Docker）

Docker方式安装SNMP Exporter

snmp.tar
root@sonic:~# docker load < snmp.tar
root@sonic:~# docker run -d \
-v /home/admin/snmp.yml:/etc/snmp_exporter/snmp.yml \ 
--net=host --name snmp_exporter prom/snmp-exporter:v0.24.1

3.3 监控报警推送

3.3.1 Alertmanager

在监控节点部署Alertmanager，主要用于接收Prometheus发送的告警信息，并及时地将告警转发到ProtmetheusAlert。

[root@computer1 prometheus] docker run --name alertmanager \
-v ~/prometheus/alertmanager.yml:/etc/alertmanager/alertmanager.yml \
-d -p 0.0.0.0:9093:9093 quay.io/prometheus/alertmanager
[root@computer1 prometheus] cat alertmanager.yml
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'web.hook'
receivers:
  - name: 'web.hook'
    webhook_configs:
      - url: 'http://127.0.0.1:5001/'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
equal: ['alertname', 'dev', 'instance']

3.3.2 PrometheusAlert

在监控节点部署PrometheusAlert，主要用于接收Alertmanager转发的告警信息，并及时地通过WeChat、Email、飞书和短信等渠道发送告警通知。

[root@computer1 prometheus] docker run -d -p 8080:8080 -v \ ~/prometheus/app.conf:/app/conf/app.conf \
--name prometheusalert feiyu563/prometheus-alert:latest
[root@computer1 prometheus] cat app.conf
appname = PrometheusAlert
#登录用户名
login_user=root
#登录密码
login_password=tera123
#监听地址
httpaddr = "0.0.0.0"
#监听端口
httpport = 8080
runmode = dev
#开启JSON请求
copyrequestbody = true
#告警消息标题
title=PrometheusAlert
#日志文件路径
logpath=logs/prometheusalertcenter.log

3.3.3 对接Email报警

[root@computer1 prometheus]# cat alertmanager.yml 
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'AlertManager_Email'
receivers:
- name: 'AlertManager_Email'
  webhook_configs:
  - url: 'http://10.240.5.223:8080/prometheusalert?type=email&tpl=prometheus-email&email='
    send_resolved: true
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
equal: ['alertname', 'dev', 'instance']

[root@computer1 prometheus]# cat app.conf
#---------------------↓邮件配置-----------------------
#是否开启邮件
open-email=1
#邮件发件服务器地址
Email_host=smtp.qq.com
#邮件发件服务器端口
Email_port=465
#邮件帐号
Email_user=
#邮件密码
Email_password=
#邮件标题
Email_title=AsterNOS告警
#默认发送邮箱
Default_emails=

报警信息：

AsterNos告警

3.3.4 对接飞书报警

[root@computer1 prometheus]# cat alertmanager.yml 
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'AlertManager_Feishu'
receivers:
- name: 'AlertManager_Feishu'
  webhook_configs:
  - url: 'http://10.240.5.223:8080/prometheusalert?type=fs&tpl=prometheus-fs&fsurl=https://open.feishu.cn/open-apis/bot/v2/hook/41078fb9-c716-434f-9ca4-d8ba64caa7ea'
    send_resolved: true
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

[root@computer1 prometheus]# cat app.conf
#---------------------↓全局配置-----------------------
appname = PrometheusAlert
#登录用户名
login_user=root
#登录密码
login_password=tera123
#监听地址
httpaddr = "0.0.0.0"
#监听端口
httpport = 8080
runmode = dev
#设置代理 proxy = http://123.123.123.123:8080
proxy =
#开启JSON请求
copyrequestbody = true
#告警消息标题
title=PrometheusAlert
#日志文件路径
logpath=logs/prometheusalertcenter.log
#是否开启飞书告警通道,可同时开始多个通道0为关闭,1为开启
open-feishu=1
#默认飞书机器人地址
fsurl=https://open.feishu.cn/open-apis/bot/v2/hook/41078fb9-c716-434f-9ca4-d8ba64caa7ea

报警信息：

Prometheus告警信息

3.4 Prometheus

在监控节点部署Prometheus，用于存储Exporter采集的数据，同时提供数据检索和报警推送等功能。

[root@computer1 prometheus] docker run -d -p 9090:9090 -v \ ~/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
--name prometheus  prom/prometheus:v2.37.0
[root@computer1 prometheus] cat prometheus.yml
scrape_configs:
  - job_name: "node-exporter"
    static_configs:
      - targets: ["10.230.1.10:9100"]
  - job_name: "snmp-exporter"
    static_configs:
      - targets:
        - 10.230.1.10
    metrics_path: /snmp
    params:
      auth: [public_v2]
      module: [AsterNOS]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 10.230.1.10:9116
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - 10.240.5.223:9093
rule_files:
  - "AsterNOS_rules.yml"

[root@computer1 prometheus] cat AsterNOS_rules.yml
groups:
- name: "CXN_node"
  rules:
  - alert: "CPU高负载警告"
    expr: ((1-(node_memory_MemAvailable_bytes / (node_memory_MemTotal_bytes))) * 100)>90
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "实例 {{ $labels.instance }} 的CPU使用率过高"
      description: "此设备的CPU使用率已超过阈值，当前值: {{ $value }}%。此问题会导致系统中各个服务假死、断连，甚至是服务器宕机，请管理员务必及时处理！"

3.4.1 Prometheus Metrics Explorer

浏览器访问监控节点的9090端口，查看Prometheus采集到的数据。

查看Prometheus采集到的数据
图5：Prometheus数据展示

3.5 Grafana

在监控节点部署Grafana，用于对基础设施和应用数据分析的时间序列数据进行可视化分析。

[root@computer1 prometheus] docker run -d -p 3000:3000 \
--name grafana  grafana/grafana-oss:9.0.6

3.5.1 Grafana Login

浏览器访问监控节点的3000端口访问Grafana登录页面，默认用户名密码admin/admin。

Grafana登录页面
图6：Grafana登陆页面

3.5.2 配置数据源

在Grafana管理面板上添加Prometheus数据源。

Grafana管理面板
图7：Grafana添加数据源

3.5.3 监控大屏

在Grafana管理面板上导入AsterNOS监控配置文件。AsterNOS监控大屏文件：

AsterNos.json
Grafana添加Dashboard
图8：Grafana添加Dashboard
Grafana监控大屏展示
图9：Grafana监控大屏展示

MC-LAG、数据中心交换机

基于CX-N产品的MC-LAG应用场景配置

1 目的

本文主要讲解企业级SONIC交换机的 MC-LAG解决方案和配置。

2 型号和版本

以下产品可以实现本方案：
CX-N系列交换机
AsterNOS系统软件版本：
AsterNOSv3.1

3 MC-LAG介绍

MC-LAG（Multi Chassis Link Aggregation Group，跨设备链路聚合组）是一种实现跨设备链路聚合的机制，通过将一台设备与另外两台设备进行跨设备链路聚合，保留了普通链路聚合的优点，同时提供了设备级别的冗余。

MC-LAG提供了一种横向虚拟化技术，将两台物理设备虚拟成单台逻辑设备，这台虚拟出来的“单个设备”与其相连的上行或下行设备实现“一对一”链路聚合。如下图所示：

链路聚合

本文所介绍的设备MC-LAG工作模式为：控制面主备模式、数据面双活模式，即：

在控制面需要区分主设备和备设备，主链路和备用链路；

在数据面采用双活方式，两台设备各自决定转发数据流。

4 MC-LAG基础配置说明

Asterfusion交换机运行企业级SONiC（AsterNOS）系统，能够灵活支持MC-LAG组网。

4.1 配置MC-LAG

mclag domain domain-id #创建MC-LAG域并进入视图，当前只支持创建一个域，范围1-4095。

session-timeout timeout #超时时间，单位秒，取值范围为3~3600，默认值为15秒；心跳检测报文的时间间隔应小于MC-LAG会话超时时间的1/3；会话超时时间应为心跳检测报文时间间隔的倍数。

Example:
sonic(config)# mclag domain 10
sonic(mclag-domain)# session-timeout 15

4.2 配置peer-link

vlan vlan-id #在全局视图下配置专用vlan，1-4095。

interface link-aggregation lag-id #创建聚合组，1-9999。

mode static #配置聚合模式为静态

commit #提交配置

switchport trunk vlan vlan-id #指定专用vlan并加入业务vlan

interface ethernet interface-name #进入接口视图

link-aggregation-group lag-id [port-priority port-priority] #加入相应lag，并可指定优先级0-65535，默认255。

startup-delay delay #配置接口延迟，默认为150秒，建议peer-link所在的物理接口上配置延迟值为145秒。

mclag domain domain-id #进入mclag域，id为之前配置的值。

peer-link link-aggregation name #指定peer-link。

commit #提交配置

Example:
sonic(config)# vlan 10
sonic(config-vlan-10)# exit
sonic(config)# interface link-aggregation 10
sonic(config-lagif-10)# mode static
sonic(config-lagif-10)# commit
sonic(config-lagif-10)# switchport trunk vlan 10
sonic(config-lagif-10)# exit
sonic(config)# interface ethernet 0/10
sonic(config-if-0/10)# link-aggregation-group 10
sonic(config-if-0/10)# startup-delay 100
sonic(config-if-0/10)# exit
sonic(config)# mclag domain 10
sonic(mclag-domain)# peer-link link-aggregation 10
sonic(mclag-domain)# commit

4.3 配置心跳检测链路

说明：心跳检测链路用来转发MC-LAG的控制报文，可以与peer-link共用，也可以使用单独的物理链路；

当开启双主检测功能时，要求心跳检测链路与peer-link共用，否则将导致功能失效。

使用单独的物理链路配置心跳检测

interface ethernet interface-name #进入接口视图

ip address A.B.C.D/M #配置接口ip地址

mclag domain domain-id #进入mclag域视图

peer-address A.B.C.D #配置心跳检测链路对端ip地址

local-address A.B.C.D #配置线条检测链路本端ip地址

vrf vrf-name #指定心跳检测链路VRF，默认default

heartbeat-interval interval #配置MC-LAG 心跳检测报文发送间隔时间，单位为秒，取值1~60，默认为1秒；

commit #提交配置

Example:
sonic(config)# interface ethernet 0/11
sonic(config-if-0/11)# ip address 10.0.0.11/24
sonic(config-if-0/11)# exit
sonic(config)# mclag domain 10
sonic(mclag-domain)# peer-address 10.0.0.12
sonic(mclag-domain)# local-address 10.0.0.11
sonic(mclag-domain)# heartbeat-interval 1
sonic(mclag-domain)# commit

使用peer-link配置心跳检测链路

interface vlan vlan-id #进入peer-link专用vlanif配置视图

ip address A.B.C.D/M #配置vlanif的ip地址

mclag domain domain-id #进入mclag域视图

peer-address A.B.C.D #配置心跳检测链路对端ip地址

local-address A.B.C.D #配置线条检测链路本端ip地址

vrf vrf-name #指定心跳检测链路VRF，默认default

commit #提交配置

Example:
sonic(config)# vlan 10
sonic(config-vlan-10)# ip address 10.0.0.11/24
sonic(config- vlan-10)# exit
sonic(config)# mclag domain 10
sonic(mclag-domain)# peer-address 10.0.0.12
sonic(mclag-domain)# local-address 10.0.0.11
sonic(mclag-domain)# commit

4.4 配置MC-LAG成员接口

说明：建议使用低速接口作为MC-LAG成员接口，为提高系统可靠性，建议跨设备聚合组使用动态聚合，并开启LACP短超时。要求部署MC-LAG的两台设备成员物理接口的port ID相同，否则无法正常聚合。

vlan vlan-id #创建业务VLAN，1-4094。

interface link-aggregation lag-id #进入LAG接口配置视图并创建下行聚合组，1-9999。

lacp fast-rate#开启lacp短超时

commit #提交配置

switchport trunk vlan vlan-id #加入业务vlan

mclag domain domain-id #进入mclag域视图

member lag lag-id #添加mclag成员接口

Example:
sonic(config)# vlan 10
sonic(config-vlan-10)# exit
sonic(config)# interface link-aggregation 10
sonic(config-lagif-10)# lacp fast-rate
sonic(config-lagif-10)# commit
sonic(config-lagif-10)# switchport trunk vlan 10
sonic(config-lagif-10)# exit
sonic(config)# mclag domain 10
sonic(mclag-domain)# member lag 10

4.5 配置Monitor Link组

说明：建议在部署MC-LAG的主备设备上配置Monitor Link组，上行口配置为uplink，下行口配置为downlink，开启该功能后，上行口状态down后，下行口会联动down，保证拓扑中出现故障时能够快速收敛。

monitor-link-group group-name [delay-time]#创建monitor-link组，delay-time为可选参数，表示上行口up后下行口up的延迟时间，单位秒，不配置时默认值为0。

interface ethernet interface-name #进入接口视图

monitor-link group-name uplink #配置上行口为uplink

interface link-aggregation lag-id #进入下行聚合组接口配置视图

monitor-link group-name downlink #配置MC-LAG成员接口为downlink

Example:
sonic(config)# monitor-link-group monitor1
sonic(config)# interface ethernet 0/48
sonic(config-if-0/48)# monitor-link monitor1 uplink
sonic(config-if-0/48)# exit
sonic(config)# interface ethernet 0/0
sonic(config-if-0/0)# monitor-link monitor1 downlink

5 MC-LAG典型配置案例

5.1 要求

用户的一台服务器server1运行着重要应用，希望接入的网络稳定可靠，现在用4台Asterfusion sonic交换机搭建网络，将两台leaf设备组成mc-lag与server1连接，测试其中一条链路断开的情况下server1是否会断网，测试过程中用server1与server2进行数据传输测试。

5.2 拓扑图

拓扑图

5.3 测试环境

硬件

名称型号硬件指标数量
spine交换机CX532P-N参见彩页1
Leaf交换机CX308P-48Y-N-V2参见彩页3
服务器X86普通服务器2
光模块多模100G QSFP286
光纤多模100G适用3
光模块多模10G SFP+6
光纤多模10G适用3

软件

软件版本
交换机操作系统AsterNOSv3.1
服务器系统CentOS Linux 7.8.2003
服务器内核 3.10.0-1127.18.2.el7
iperf33.9

管理IP

设备名称接口IP地址
Spine管理口10.230.1.31
Leaf1管理口10.230.1.21
Leaf2管理口10.230.1.22
Leaf3管理口10.230.1.23
Server-1管理口10.230.1.11
Server-2管理口10.230.1.12

设备通信IP

设备名称接口IP地址
SpineEthernet 0/0 10.0.10.201
SpineEthernet 0/410.0.11.201
SpineEthernet 0/810.0.12.201
SpineLoopback 0 172.16.0.1
Leaf1Ethernet 0/0 (Mc-Lag)100.0.10.201
Leaf1Ethernet 0/4(peer-link)11.0.0.11
Leaf1Ethernet 0/4810.0.10.1
Leaf1Loopback 0 172.16.0.2
Leaf2Ethernet 0/0 (Mc-Lag)100.0.10.201
Leaf2Ethernet 0/4(peer-link)11.0.0.12
Leaf2Ethernet 0/4810.0.11.1
Leaf2Loopback 0 172.16.0.3
Leaf3Ethernet 0/0 100.0.20.201
Leaf3Ethernet 0/4810.0.12.1
Leaf3Loopback 0 172.16.0.4
Server-1Bond0100.0.10.200
Server-2Eth0100.0.20.200

5.4 测试前的准备工作

确保各设备按照拓扑图正确连接，确保iperf3测试软件正确安装。

5.5 配置步骤

第 1 步

配置 server1 的 bond0 接口的 IP 地址和网关。

[admin@Server1~]# sudo vim /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
BROADCAST=100.0.10.255
IPADDR=100.0.10.200
NETMASK=255.255.255.0
NETWORK=100.0.10.0
ONBOOT=yes
USERCTL=no
GATEWAY=100.0.10.201
BONDING_OPTS=”miimon=100 mode=4 lacp_rate=fast xmit_hash_policy=layer2+3 fail_over_mac=1″
MASTER=yes
[admin@Server1~]# sudo vim /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=”eth0″
BOOTPROTO=none
ONBOOT=”yes”
MASTER=bond0
SLAVE=yes
HWADDR=”b8:59:9f:42:36:68″
[admin@Server1~]# sudo vim /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=”eth1″
BOOTPROTO=none
ONBOOT=”yes”
MASTER=bond0
SLAVE=yes
HWADDR=”b8:59:9f:42:36:69″
[admin@Server1~]# sudo systemctl restart network

第 2 步

配置 server2 的 eth0 接口的 IP 地址和网关。

[admin@Server1~]# sudo ifconfig eth0 100.0.20.200/24 up
[admin@Server1~]# sudo route add default gw 100.0.20.201

第 3 步

配置spine switch IP地址。

sonic# configure terminal
sonic(config)# interface ethernet 0/0
sonic(config-if-0/0)# ip address 10.0.10.201/24
sonic(config-if-0/0)# interface ethernet 0/4
sonic(config-if-0/4)# ip address 10.0.11.201/24
sonic(config-if-0/4)# interface ethernet 0/8
sonic(config-if-0/8)# ip address 10.0.12.201/24
sonic(config-if-0/8)# exit
sonic(config)# interface loopback 0
sonic(config-loif-0)# ip address 172.16.0.1/32

第 4 步

配置三台leaf设备的IP 地址和 MC-LAG。

Leaf1 配置

sonic# configure terminal
sonic(config)# interface ethernet 0/48
sonic(config-if-0/48)# ip address 10.0.10.1/24
sonic(config-if-0/48)# interface loopback 0
sonic(config-loif-0)# ip address 172.16.0.2/32
sonic(config-loif-0)# exit
sonic(config)# vlan 10
sonic(config-vlan-10)# exit
sonic(config)# vlan 30
sonic(config-vlan-30)# exit
sonic(config)# interface link-aggregation 10
sonic(config-lagif-10)# exit
sonic(config)# interface ethernet 0/0
sonic(config-if-0/0)# speed 10000
sonic(config-if-0/0)# link-aggregation-group 10
sonic(config-if-0/0)# exit
sonic(config)# interface ethernet 0/4
sonic(config-if-0/4)# speed 10000
sonic(config-if-0/4)# switchport trunk vlan 10
sonic(config-if-0/4)# switchport trunk vlan 30
sonic(config-if-0/4)# exit
sonic(config)# interface link-aggregation 10
sonic(config-lagif-10)# switchport trunk vlan 10
sonic(config-lagif-10)# exit
sonic(config)# vlan 10
sonic(config-vlan-10)# ip address 100.0.10.201/24
sonic(config-vlan-10)# exit
sonic(config)# vlan 30
sonic(config-vlan-30)# ip address 11.0.0.11/24
sonic(config-vlan-10)# exit
sonic(config)# monitor-link-group monitor1
sonic(config)# interface ethernet 0/48
sonic(config-if-0/48)# monitor-link monitor1 uplink
sonic(config-if-0/48)# exit
sonic(config)# interface ethernet 0/0
sonic(config-if-0/0)# monitor-link monitor1 downlink
sonic(config-if-0/0)# exit
sonic(config)# mclag domain 10
sonic(mclag-domain)# peer-link ethernet 0/4
sonic(mclag-domain)# local-address 11.0.0.11
sonic(mclag-domain)# peer-address 11.0.0.12
sonic(mclag-domain)# member lag 10
sonic(mclag-domain)# commit
sonic(mclag-domain)# interface vlan 10
sonic(config-vlan-10)# mac-address 00:11:22:33:44:55
sonic(config-vlan-10)# exit
sonic(config)# write

Leaf2 配置

sonic# configure terminal
sonic(config)# interface ethernet 0/48
sonic(config-if-0/48)# ip address 10.0.11.1/24
sonic(config-if-0/48)# interface loopback 0
sonic(config-loif-0)# ip address 172.16.0.3/32
sonic(config-loif-0)# exit
sonic(config)# vlan 10
sonic(config-vlan-10)# exit
sonic(config)# vlan 30
sonic(config-vlan-30)# exit
sonic(config)# interface link-aggregation 10
sonic(config-lagif-10)# exit
sonic(config)# interface ethernet 0/0
sonic(config-if-0/0)# speed 10000
sonic(config-if-0/0)# link-aggregation-group 10
sonic(config-if-0/0)# exit
sonic(config)# interface ethernet 0/4
sonic(config-if-0/4)# speed 10000
sonic(config-if-0/4)# switchport trunk vlan 10
sonic(config-if-0/4)# switchport trunk vlan 30
sonic(config-if-0/4)# exit
sonic(config)# interface link-aggregation 10
sonic(config-lagif-10)# switchport trunk vlan 10
sonic(config-lagif-10)# exit
sonic(config)# vlan 10
sonic(config-vlan-10)# ip address 100.0.10.201/24
sonic(config-vlan-10)# exit
sonic(config)# vlan 30
sonic(config-vlan-30)# ip address 11.0.0.12/24
sonic(config-vlan-10)# exit
sonic(config)# monitor-link-group monitor1
sonic(config)# interface ethernet 0/48
sonic(config-if-0/48)# monitor-link monitor1 uplink
sonic(config-if-0/48)# exit
sonic(config)# interface ethernet 0/0
sonic(config-if-0/0)# monitor-link monitor1 downlink
sonic(config-if-0/0)# exit
sonic(config)# mclag domain 10
sonic(mclag-domain)# peer-link ethernet 0/4
sonic(mclag-domain)# local-address 11.0.0.12
sonic(mclag-domain)# peer-address 11.0.0.11
sonic(mclag-domain)# member lag 10
sonic(mclag-domain)# commit
sonic(mclag-domain)# interface vlan 10
sonic(config-vlan-10)# mac-address 00:11:22:33:44:55
sonic(config-vlan-10)# exit
sonic(config)# write

Leaf3 配置

sonic# configure terminal
sonic(config)# interface ethernet 0/48
sonic(config-if-0/48)# ip address 10.0.12.1/24
sonic(config-if-0/48)# interface ethernet 0/0
sonic(config-if-0/0)# speed 10000
sonic(config-if-0/0)# ip address 100.0.20.201/24
sonic(config-if-0/0)# interface loopback 0
sonic(config-loif-0)# ip address 172.16.0.4/32
sonic(config-loif-0)# exit
sonic(config)# write

第 5 步

配置spine设备bgp。

sonic# configure terminal
sonic(config)# router bgp 65001
sonic(config-router)# bgp router-id 171.16.0.1
sonic(config-router)# no bgp ebgp-requires-policy
sonic(config-router)# neighbor 172.16.0.2 remote-as 65002
sonic(config-router)# neighbor 172.16.0.3 remote-as 65002
sonic(config-router)# neighbor 172.16.0.4 remote-as 65004
sonic(config-router)# address-family l2vpn evpn
sonic(config-router)# neighbor 172.16.0.2 activate
sonic(config-router)# neighbor 172.16.0.3 activate
sonic(config-router)# neighbor 172.16.0.4 activate
sonic(config-router)# advertise-all-vni
sonic(config)# write
sonic(config)# reload

第 6 步

 配置三台leaf设备bgp。

Leaf1 配置

sonic(config)# router bgp 65002
sonic(config-router)# bgp router-id 171.16.0.2
sonic(config-router)# no bgp ebgp-requires-policy
sonic(config-router)# neighbor 172.16.0.1 remote-as 65001
sonic(config-router)# neighbor 172.16.0.3 remote-as 65002
sonic(config-router)# address-family ipv4 unicast
sonic(config-router-af)# network 172.16.0.2/32
sonic(config-router-af)# exit
sonic(config)# router bgp 65002
sonic(config-router)# address-family l2vpn evpn
sonic(config-router)# neighbor 172.16.0.1 activate
sonic(config-router)# neighbor 172.16.0.3 activate
sonic(config-router)# advertise-all-vni
sonic(config)# write
sonic(config)# reload

Leaf2 配置

sonic(config)# router bgp 65002
sonic(config-router)# bgp router-id 171.16.0.3
sonic(config-router)# no bgp ebgp-requires-policy
sonic(config-router)# neighbor 172.16.0.1 remote-as 65001
sonic(config-router)# neighbor 172.16.0.2 remote-as 65002
sonic(config-router)# address-family ipv4 unicast
sonic(config-router-af)# network 172.16.0.3/32
sonic(config-router-af)# exit
sonic(config)# router bgp 65002
sonic(config-router)# address-family l2vpn evpn
sonic(config-router)# neighbor 172.16.0.1 activate
sonic(config-router)# neighbor 172.16.0.2 activate
sonic(config-router)# advertise-all-vni
sonic(config)# write
sonic(config)# reload

Leaf3 配置

sonic(config)# router bgp 65004
sonic(config-router)# bgp router-id 171.16.0.4
sonic(config-router)# no bgp ebgp-requires-policy
sonic(config-router)# neighbor 172.16.0.1 remote-as 65001
sonic(config-router)# address-family ipv4 unicast
sonic(config-router-af)# network 172.16.0.4/32
sonic(config-router-af)# exit
sonic(config)# router bgp 65004
sonic(config-router)# address-family l2vpn evpn
sonic(config-router)# neighbor 172.16.0.1 activate
sonic(config-router)# advertise-all-vni
sonic(config)# write
sonic(config)# reload

第 7 步

用server1发送流量到server2，并查看spine上流量走向

[admin@Server2~]# iperf3 -s
[admin@Server1~]# iperf3 -c 100.0.20.200 -l 20k -b 100G -M 9000 -t 1000

查看Spine设备流量

查看Spine设备流量

第 8 步

将leaf1上行接口0/48 down，查看spine流量走向

查看spine流量走向

6 结论

本次测试中，mc-lag链路故障后服务器之间可以正常通信，mc-lag链路恢复后服务器之间仍然可以正常通信，说明通过两台asterfusion sonic switch组成的mc-lag网络可以满足用户对网络高稳定性及高可靠性的需求。

点击了解Asterfusion CX-N数据中心交换机

如有其它问题，请填写右侧需求表单联系我们

RoCE、SONiC

Asterfusion SONiC交换机的RoCE方案配置

1 目的

本文主要讲解企业级SONIC交换机的RoCE方案及配置。

2 型号和版本

以下产品可以实现本方案：
CX-N系列交换机
AsterNOS系统软件版本：
AsterNOSv3.1

3 RoCE 原理和配置注意事项

3.1 RoCE介绍

在各种HPC高性能计算场景中，对网络的诉求基本上是高吞吐和低时延这两个重要特性，为了实现高吞吐和低时延，业界一般采用 RDMA(Remote Direct Memory Access，远程直接内存访问)替代 TCP 协议。但是RDMA 对于丢包非常敏感，一旦发生丢包重传，性能会急剧下降。因此要使得 RDMA 吞吐不受影响，丢包率必须保证在 1e-05（十万分之一）以下，最好为零丢包。

RoCE (RDMA over Converged Ethernet)网络通过PFC+ECN特性来保障网络传输过程不丢包。

3.2 RoCE 原理和配置注意事项

RoCE网络通过PFC+ECN方式保证网络无损。具体原理如下：

PFC+ECN原理

当serverA与serverB通信时，正常数据流向如绿色实线所示，从A经过交换机S到达B，然后再由B返回到A。

当报文发生拥塞时，需要先使ECN发挥作用，设置交换机的ECN缓存阈值区间为N~M，当缓存超过N时，S开始随机在报文中标记ECN位，当缓存超过M时，S开始在所有报文中标记ECN位。B收到带有ECN标记的报文后，开始向A发送CNP报文，通知A降低发送速率，直到找到最佳速率后，以该速率持续发送数据，从而达到不丢包的目的。

当报文发生拥塞时，PFC也会发挥作用，设置交换机的PFC缓存阈值为Q，当缓存超过Q时，交换机会立即向A持续发送PAUSE数据帧，A收到PAUSE帧后，会立即停止向S的该队列发送报文，这时数据流会中断。当A不再收到pause报文之后，将重新开始向S发送报文。

因此，为了降低数据中断对业务的影响，应尽量避免PFC的触发，使用ECN来保障数据传输，此时就需要交换机的缓存阈值设置Q应该大于M。确保ECN先于PFC触发。

4 Asterfusion Enterprise SONiC 交换机 RoCE 配置

Asterfusion交换机运行企业级SONiC（AsterNOS）系统，采用PFC+ECN的方式保障RoCE网络无损。

有两种配置方式：

4.1 一键自动配置RoCE参数

Example:
sonic# configure terminal
sonic(config)# qos roce lossless
sonic(config)# qos service-policy roce_lossless

它还提供所有与 RoCE 相关配置信息的一键查看功能。命令如下：

sonic# show qos roce

4.2 手动配置RoCE参数

当一键RoCE的配置参数与当前场景并不是很匹配时，也可以手动进行参数配置，以达到最佳效果，相关配置如下：

修改 DSCP 映射

configure termin

diffserv-map type ip-dscp roce_lossless_diffserv_map   #进入DSCP映射配置视图

ip-dscp value cos cos_value  #配置DSCP到COS的映射，value指定DSCP值，范围0-63；cos_value指定COS值，范围0-7

default {cos_value|copy}  #default cos_value表示所有数据包被映射到相应的COS值；default copy表示系统默认的映射

Example:
sonic# configure terminal
sonic(config)# diffserv-map type ip-dscp roce_lossless_diffserv_map
sonic(config-diffservmap-roce_lossless_diffserv_map)# ip-dscp 1 cos 1
sonic(config-diffservmap-roce_lossless_diffserv_map)# default copy

修改队列调度策略

configure terminal

policy-map roce_lossless    #进入相关视图

queue-scheduler priority queue queue-id  #配置SP模式调度，queue-id表示队列，范围0-7

queue-scheduler queue-limit percent queue-weight queue queue-id #配置DWRR模式调度，queue-weight表示调度权重百分比，范围0-100；queue-id表示队列，范围0-7

Example:
sonic# configure terminal
sonic(config)# policy-map roce_lossless
sonic(config-pmap-roce-lossless)# queue-scheduler priority queue 3
sonic(config-pmap-roce_lossless)# queue-scheduler queue-limit percent 60 queue 3

调整PFC水线

configure terminal

buffer-profile roce_lossless_profile #进入PFC配置视图

mode lossless dynamic dynamic_th size size xoff xoff xon-offset xon-offset [xon xon]

#修改PFC无损Buffer。

dynamic_th表示动态阈值系数，取值范围为[-4,3]；动态阈值= 2dynamic_th×剩余可用buffer。例如，dynamic_th设为1，那么动态阈值为2倍的剩余可用buffer，即实际threshold为2/3的总可用buffer；

size表示保留大小，单位为字节，建议配置值为1518；

xoff表示PFC反压帧触发缓存门限值，建议配置为cell size（224 Bytes）的整数倍，单位为字节。xoff与线缆长度，接口速率等参数有关。xoff值必须大于xon值；

xon-offset表示PFC反压帧停止缓存门限值，建议配置为cell size（224 Bytes）的整数倍，单位为字节。建议配置值为13440；

xon为可选参数一般配置为0。

Example:
sonic# configure terminal
sonic(config)# buffer-profile roce_lossless_profile
sonic(config-buffer-profile-roce_lossless_profile)# mode lossless dynamic 1 size 1518 xoff 896 xon-offset 13440 xon 0

调整ECN水线

configure terminal

wred roce_lossless_ecn  #进入ECN配置视图

mode ecn gmin min_th gmax max_th gprobability probability [ymin min_th ymax max_th yprobability probability|rmin min_th rmax max_th rprobability probability]

#修改ECN参数。

min_th设置显式拥塞通告的下限绝对值，单位为字节。即当队列中的报文长度达到此数值时，接口开始按照概率将报文的ECN字段置为CE。可配置的min threshold最小值为15KB，建议配置值为15360；

max_th设置显式拥塞通告的上限绝对值，单位为字节。即当队列中的报文长度达到此数值时，接口开始将全部报文的ECN字段置为CE；不同速率接口的建议值分别为：100/200G为76800,400G为1536000。

probability设置将报文的ECN字段的设置为CE的最大概率，整数形式，取值范围[1,100]。对于时延敏感型业务，建议最大丢弃概率设置为90%；对于吞吐敏感型业务，建议设置为10%。

Example:
sonic# configure terminal
sonic(config)# wred roce_lossless_ecn
sonic(config-wred-roce_lossless_ecn)# mode ecn gmin 15360 gmax 76800 gprobability 90

5 用户测试案例

5.1 要求

现用三台已安装Mellanox 100G网卡的服务器，测试CX532P-N交换机无损转发数据的特性，如下图所示，用server1发送RDMA流量经过交换机的无损队列转发给server3，同时用server2发送普通TCP流量经交换机转发给server3，查看数据接收情况。

5.2 拓扑图

拓扑图

5.3 测试环境

硬件

名称型号硬件指标数量备注
交换机CX532P-N参见彩页2
服务器X86普通服务器3安装100G IB网卡
光模块100GQSFP286
光纤多模100G适用3
网卡MCX653195A-ECAT100G3

软件

软件版本备注
交换机操作系统AsterNOSv3.1
宿主机操作系统openEuler 22.03
宿主机内核 5.10.0-136.33.0.109
Mellanox网卡驱动5.10.0-60.18.0网卡驱动版本要适配宿主机内核版本
iperf33.9

管理网口IP地址规划

设备名称接口IP地址备注
CX532P-N管理口10.230.1.18
Server-1管理口10.230.1.11
Server-2管理口10.230.1.12
Server-3管理口10.230.1.13

业务网口IP地址规划

设备名称接口IP地址备注
CX532P-NVlan接口100.0.10.200
Server-1业务接口100.0.10.10Mellanox 网卡接口
Server-2业务接口100.0.10.11Mellanox 网卡接口
Server-3业务接口100.0.10.12Mellanox 网卡接口

5.4 测试前的准备工作

根据拓扑图将每台服务器连接到交换机，确保服务器上已正确安装 Mellanox 网卡和驱动程序，并安装 iperf3 测试工按照组网图将各服务器与交换机正确连接，确保服务器上安装好mellanox网卡及驱动，并安装好iperf3测试工具。

5.5 配置步骤

第 1 步

对交换机进行基础配置，确保三个接口在同一二层网络中，数据能正常转发。

sonic# configure terminal
sonic(config)# vlan 101
sonic(config-vlan-101)# interface ethernet 0/0
sonic(config-if-0/0)# switchport access vlan 101
sonic(config-if-0/0)# interface ethernet 0/4
sonic(config-if-0/4)# switchport access vlan 101
sonic(config-if-0/4)# interface ethernet 0/8
sonic(config-if-0/8)# switchport access vlan 101
sonic(config-if-0/8)# exit
sonic(config)# interface vlan 101
sonic(config-vlanif-101)# ip address 100.0.10.200/24

第 2 步

一键配置交换机RoCE参数。

onic# configure terminal
sonic(config)# qos roce lossless
sonic(config)# qos service-policy roce_lossless

查看交换机RoCE配置

sonic# show qos roce
查看RoCE配置

第 3 步

配置三台服务器ip地址，并配置网卡的RoCE参数，本次无损队列使用队列3。

[admin@Server1~]# sudo ifconfig ens1f2 100.0.10.10/24 up
[admin@Server2~]# sudo ifconfig ens1f2 100.0.10.11/24 up
[admin@Server3~]# sudo ifconfig ens1f2 100.0.10.12/24 up
[admin@Server1~]# sudo mlnx_qos -i ens1f2 –trust dscp
[admin@Server1~]# sudo mlnx_qos -i ens1f2 –pfc 0,0,0,1,0,0,0,0
[admin@Server1~]# sudo cma_roce_mode -d mlx5_0 -p 1 -m 2
[admin@Server1~]# sudo echo 96 > /sys/class/infiniband/mlx5_0/tc/1/traffic_class
[admin@Server1~]# sudo cma_roce_tos -d mlx5_0 -t 96
[admin@Server1~]# sudo echo 1 > /sys/class/net/ens1f2/ecn/roce_np/enable/3
[admin@Server1~]# sudo echo 1 > /sys/class/net/ens1f2/ecn/roce_rp/enable/3
[admin@Server1~]# sudo echo 16 > /sys/class/net/ens1f2/ecn/roce_np/cnp_dscp
[admin@Server1~]# sudo sysctl -w net.ipv4.tcp_ecn=1
[admin@Server3~]# sudo mlnx_qos -i ens1f2 –trust dscp
[admin@Server3~]# sudo mlnx_qos -i ens1f2 –pfc 0,0,0,1,0,0,0,0
[admin@Server3~]# sudo cma_roce_mode -d mlx5_0 -p 1 -m 2
[admin@Server3~]# sudo echo 96 > /sys/class/infiniband/mlx5_0/tc/1/traffic_class
[admin@Server3~]# sudo cma_roce_tos -d mlx5_0 -t 96
[admin@Server3~]# sudo echo 1 > /sys/class/net/ens1f2/ecn/roce_np/enable/3
[admin@Server3~]# sudo echo 1 > /sys/class/net/ens1f2/ecn/roce_rp/enable/3
[admin@Server3~]# sudo echo 16 > /sys/class/net/ens1f2/ecn/roce_np/cnp_dscp
[admin@Server3~]# sudo sysctl -w net.ipv4.tcp_ecn=1

第 4 步

使用server1和server2向server3发数据包，其中server1发送RoCE流量，server2发送tcp流量。

[admin@Server3~]# ib_send_lat -R -d mlx5_0 -F –report_gbits -a
[admin@Server1~]# ib_send_lat -a -R -x 3 -d mlx5_0 -F -f 2 100.0.10.12
[admin@Server3~]# iperf3 -s
[admin@Server2~]# iperf3 -c 100.0.10.12 -l 20k -b 100G -M 9000 -t 1000

查看三个接口的各队列数据转发情况。

sonic# show counters queue 0/0
查看0/0接口的队列转发
sonic# show counters queue 0/4
查看0/4接口的队列转发
sonic# show counters queue 0/8
查看0/8接口的队列转发

6 结论

由转发结果可以看出，经过队列3转发的RoCE流量未丢包，经过队列0转发的TCP流量由于带宽不足产生丢包。CX532P-N交换机可以通过RoCE功能实现网络无损传输。

点击了解Asterfusion CX-N数据中心交换机

如有其它问题，请填写右侧需求表单联系我们

用于解决方案的背景图

一文揭秘AI智算中心网络流量 – 数据存储篇

关注星融元

本篇为“揭秘AI智算中心网络流量“系列的第三篇，前篇请参阅：

01、生成式AI对数据存储有哪些需求？

对于较小规模的AI模型，本地连接的磁盘存储可能就足够；进入大模型时代，则通常需要基于对象存储或并行文件系统的共享存储。一个完整的生成式AI的工作流的各阶段对存储有不同需求，具体可拆解如下：

  • 数据挖掘：需要从多个来源收集非结构化的数据，一般与混合云集成，用数据湖作为存储平台；
  • 数据准备：进行数据汇总、标准化和版本控制，关注存储的效率和灵活的数据管理能力，多采用统一存储平台；
  • 模型训练和微调：在智算中心内部，结合GPU服务器本地内存和远端的并行/分布式存储系统。因为GPU的投入巨大，需要高性能存储来高效地提供数据，并在整个过程中保持高利用率；
  • 推理阶段：该阶段旨在利用已训练好的模型实时生成输出，需要将输入模型和推理生成的文字/图片/视频流存储下来作为备份。

02、智算中心的存储网络

我们大致可将AI智算中心内部的数据存储系统进行简单的层次分类，主要包括GPU内存、存储网和存储设备。

| 图片引自 NVIDIA技术博客

| 图片引自 NVIDIA技术博客

一般来说，在存储层次结构中位置越高，其存储性能（尤其是延迟）就越快。因为本文的定位在分析网络流量，我们将聚焦于存储网络（data fabric）层次，即智算中心内部GPU服务器内存与远端存储服务器之间传输的数据。

在一个计算和存储分离的部署场景中，一般推荐部署2张Spine-Leaf架构的物理网：前端网和后端网。其中，存储前端网和业务网共用一张物理网。

存储后端网则单独使用一张物理网，以保证分布式存储集群能够快速无阻塞地完成多副本同步、故障后数据重建等任务。存储节点对网络接入侧的可靠性要求相对较高，因此推荐使用双归（MC-LAG）或者多归（EVPN-Multihoming）接入。

存储网络流量主要发生在模型训练的场景，它是一种单播流量，逻辑上仅需要以存储服务器为中心的星型连接。

  • 一是从存储服务器中分批加载训练数据集到GPU内存。
  • 二是训练的中间结果（定期保存的参数和优化器状态，即Check Point）要在存储服务器共享，并通过网络读写。

⑴ 数据集加载流量分析

在一个epoch中，整个训练集被遍历一次，如果进行评估，验证集也将被遍历一次。以下假设在每个epoch中进行评估，整个数据集的存储大小为D。

  • 数据并行时，整个数据集从网络存储读取，通过scatter操作分别加载到不同的GPU上，总网络流量为D。
  • 张量并行时，整个数据集从网络存储读取，通过broadcast操作发送给所有GPU，总的网络流量为 D x G。
  • 流水线并行时，整个数据集从网络存储读取，喂给流水线上第一个GPU，总网络流量为D。
  • 3D并行时，整个数据集从网络存储读取，在数据并行维度上分配，在张量并行维度上广播，总网络流量为D x G（tp） 。

以C4数据集为例，数据集的大小约38.5 TB，假设张量并行GPU数量为8，3D并行时每个epoch中加载数据集产生的网络流量为308TB。

⑵ Checkpoint存储流量分析

Checkpoint中存储了模型参数、优化器状态和其它训练状态（包括模型配置、训练的超参数、日志信息等）。优化器包含了梯度、动量和二阶矩估计等，每一种数据大小都等于模型参数。其它训练状态的大小可以忽略不计。假设模型参数为P，数据格式为BFLOAT16，优化器为Adam/AdamW，则checkpoint总大小为：

2 x P + 2 x P x 3 = 8 x P

这个checkpoint要保存在存储服务器中，虽然在张量并行、流水线并行和3D并行时，这些数据从多个GPU上通过gather操作汇聚到存储服务器，但无论如何，数据总量是一个checkpoint大小。假设每个epoch存储一次。这样，每个epoch产生的流量为：

8 x P

以Llama3-70B模型为例，假设每个epoch均存储，则产生的网络存储流量为560GB。

03、存储网设备选型：RoCE还是InfiniBand

相比训练场景，在智算中心存储网传输的流量与并行计算完全不在一个量级——虽然对链路带宽要求不那么高，但仍需满足高速分布式存储业务中所需的高吞吐、低时延、无损传输特性，并灵活满足存储集群规模调整所需的高可扩展性。

NVIDIA DGX SuperPOD™ 的方案在存储网采用的是200G的InfiniBand交换机。而事实上，随着近年来AI以太网技术的进步，RoCE与IB在转发时延上的细微差异，对分布式存储业务性能几乎没有影响。结合科学的网络参数调优，我们已在多个客户现场稳定测得了运行RoCEv2协议的交换机端到端性能全面优于IB交换机的结果。RoCE交换机作为IB平替已是不争的事实。

星融元 CX664P-N 是一款专为智算/超算中心设计的超低时延RoCE交换机，凭借以下特性在存储场景中脱颖而出。

型号为CX564P-664D-N数据中心交换机产品图

CX664D-N— 业务接口：64 x 200GE QSFP56, 2 x 10GE SFP+

  • CX-N系列一贯的超低延迟特性，端到端性能可媲美IB*（*测试数据详见方案手册）
  • 12.8Tbps 的线速 L2/L3 交换性能，提供高密度 200G/100G 以太网接口，满足主流存储网络需求并兼顾未来升级空间；另有两个 10G 端口用于管理网接入
  • 支持基于 RDMA 的 NVMe-oF (全端口标配RoCEv2)和EVPN-Multihoming → 什么是EVPN多归属，和MC-LAG的区别？
  • 搭载持续进化的企业级SONiC——AsterNOS网络操作系统，其开放的软件架构通过REST API开放全部网络功能给AI智算中心管理系统，实现无损以太网的自动化极简部署 → Easy RoCE：一键启用无损以太网

除存储网之外，基于通用、解耦、高性能的以太网硬件和开放软件框架，星融元可为大模型算力中心提供10G-800G的全场景互联能力。

一文揭秘AI智算中心网络流量 – AI推理篇

关注星融元

本篇为“揭秘AI智算中心网络流量“系列的第二篇，前篇请参阅：一文揭秘AI智算中心网络流量 – 大模型训练篇 。有关数据存储流量的分析将于下篇呈现，敬请关注。

AI推理是指从经过训练的大模型中获取用户查询或提示的响应的过程。

为了生成对用户查询的完整响应，AI推理服务器从一次推理迭代中获取输出token，将其连接到用户输入序列，并将其作为新的输入序列反馈到模型中以预测下一个token。这个过程被称为“自回归”计算，此过程重复进行，直到达到预定义的停止标准。

自回归

AI推理系统如何生成一次完整的响应？

⑴ 预填充/提示（Prefill）：模型从用户那里获得输入序列。基于此输入，模型预测第一个输出token。

⑵ 解码（Decode）：将生成的输出token连接到输入序列。更新后的输入序列被反馈到经过训练的模型中，然后生成下一个token。

⑶ 循环：解码继续进行，每个新token都是基于所有先前token的累积序列生成的。这种将输出token自回归地馈送到输入的过程确保模型在每个步骤的输出都受到所有先前token的影响，从而使其能够保持上下文和连贯性。

⑷ 终止：当模型达到停止标准时，它会终止该过程。停止标准可以是以下之一。

  • 最大序列长度：一旦达到总token（输入和输出）数量的定义限制
  • 序列结束 (EOS) ：模型生成一个特殊token，表示文本生成的结束。
  • 上下文完成：当模型确定生成的文本已根据提供的上下文得出自然且合乎逻辑的结论

AI并行推理网络流量分析

由于在预填充阶段已知整个token输入序列，因此推理加速器可以并行计算所有输入token的信息，并执行模型来预测下一个输出token。

在大模型推理时，虽然模型经过了压缩（比如4bit量化），但模型尺寸仍可能超过单个GPU的内存，这时候就需要张量并行，即使单个GPU可以容纳整个模型，张量并行可以加速推理过程。如果并发用户数较大，单个GPU来不及及时响应，就需要数据并行。

让我们再次回顾AI推理的两个关键阶段：

  1. 预填充（Prefill）阶段根据用户输入的prompt，生成输入token序列，并进行批处理，计算KV（Key, Value）缓存，并生成第一个输出token。这个阶段可以认为是大模型在理解用户输入，KV缓存存储了输入序列的上下文信息（为下面的Decode阶段缓存），其特点是需要大量的计算。
  2. 解码（Decode）阶段是一个循环过程，根据之前生成的token序列和KV缓存，计算下一个token，直到生成完整的输出。这个阶段可以认为是大模型在一个字一个字的说话。由于KV缓存的密集型计算已在 Prefill 阶段完成，因此此阶段仅处理上一阶段新生成的 token。因此，计算密集程度较低；但这一步需要从 KV缓存中读取前面所有token的Key,Value，所以需要高速的内存访问。

由于以上两个阶段对GPU的需求不同，我们可以采用Prefill-Decode解耦的方式，由2个不同类型的GPU分别承担Prefill和Decode阶段的计算任务，顺序执行。这时候就需要在两个阶段间传输KV缓存。

在生产部署时，通常结合上述几种方式。相比AI训练，AI推理只有前向传播过程，计算量相对较低，但需要快速的生成下一个token。流量产生有两个来源：

  1. 每次推理在Prefill GPU和Decode GPU之间传递KV缓存；
  2. Prefill GPU集群和Decode GPU集群分别实施张量并行，产生的中间激活的传递。不会有巨量的梯度同步流量。

假设并发用户数为U，数据并行维度为G(dp)，张量并行维度为G(tp)，用户输入序列的平均长度为S(in)个token，模型产生输出的平均长度为S(out)个token。

在张量并行时，前向传播产生了GPU间的网络流量，各个GPU计算出的中间激活值需要合并，由all-reduce操作进行求和。

假设模型有L层，在一次推理过程中，S(in)个输入token在模型的每一layer进行2次批量合并，共2L次，而对于每个输出Token，在模型的每个layer的中均进行2次合并，共 2xS(out) x L 次。此外，在Prefill阶段和Decode阶段之间有一次KV缓存的传递。AI并行推理网络流量如下图所示：

假设模型的隐藏状态大小为H，GPU数量为G，计算激活使用的数据格式为FLOAT16（2个字节表示一个数），每次all-reduce操作的通信量为

2 x H x （Gtp-1）x Gtp

在Prefill阶段，所有输入Token，在模型的每个layer的中均进行2次批量合并，共2xS(in)xL次。在Decode阶段，对于每个Token，在模型的每个layer的中均进行2次合并，共2xS(out)xL次。因此，U个用户的并发推理，中间激活值的总网络流量为

4 x U x（Sin+Sout）x L x H x （Gtp-1）x Gtp

另外，在一次推理中，KV缓存的大小为

4 x Sin x L x H

因此，U个用户的并发推理，KV缓存传递的网络流量为

4 x U x Sin x L x H

以Llama3-120B模型为例，模型层数140， 隐藏状态大小8192，张量并行度为4，用户prompt的平均长度S(in)为256个token，产生的输出的平均长度S(out)为4096个token。则要支持100个并发用户请求所需要的推理流量为：

4 x 100 x （256 + 4096）x 140 x 8192 x （4-1）x 4 + 4 x 100 x 256 x 140 x 8192 = 21.896TB

其中，KV缓存传递的流量虽然不大，每个用户约1.17GB，但需要在10ms左右的时间内一次传递完成。如果用1个800G端口传递，最快需要11.7ms。

AI推理对网络的需求

超高频率

AI推理流量虽然远小于训练时的网络流量，但值得注意的是，推理需要在很短的时间内完成，每个token在每一层产生2次流量，并要求在极短时间内传输完毕。假设至少要达到100token/s的推理速度，并行加速比为90%，那么每个token的推理速度要小于1ms，KV缓存需要在10ms左右完成。整个网络吞吐量应大于

4 x 100 x 140 x 8192 x （4-1）x 4/0.001 + 4 x 100 x 140 x 8192/0.01 = 5551GB/s ≈ 44.4Tbps

严格时间同步

无论是训练还是推理流量，都具有非常严格的周期性规律。基于木桶原理，如果GPU的时钟不同步，将造成同样的计算量花费不同的时间，计算快的GPU不得不等待计算慢的GPU。

开放与兼容性

AI推理进程涉及应用已训练好的AI模型进行决策或识别。对比AI训练，AI推理芯片门槛相对更低，我们的确也看到推理领域萌生出了开放生态的雏形，不少新兴初创企业加入竞争，涌现出基于不同算力架构的技术方案。

另一方面，在实际生产部署中的AI推理业务往往会与前端的业务/应用网络形成紧密配合，经由现有数据中心和云网络基础设施对外提供服务。

这便要求基础设施具备相当的开放性——网络不但要连接底层的异构算力（GPU、CPU、NPU）系统，还需要实现与上层管理系统的对接集成，例如与基于K8s的算力调度平台、已有的云管平台等等。

随着大模型的应用不断深化，AI算力部署将从训练场景逐步转向推理，推理需求也逐渐从云端迁移至边缘/终端，并呈现出垂直行业定制化的趋势。在云-边-端之间，我们需要构建一个更为均衡、通用化的网络基础设施体系。

在已被用户场景充分验证的数据中心开放云网能力之上（BGP、VXLAN、Calico容器路由、RoCE、NVMe-oF等），星融元推出的 星智AI 网络解决方案基于通用、解耦、高性能的以太网硬件和开放的SONiC软件框架，为AI智算中心提供10G-800G速率的以太网交换机，灵活支持单一速率或混合速率交换机组网，在保持极致性能的同时可编程、可升级，帮助客户构建高性能的AI智算中心网络，提供用于AI训练、推理、分布式存储、带内外管理等场景的互联能力。

  • 最大支持64个800G以太网接口，共51.2T交换容量
  • 超低时延，在800G端口上实现业界最强的560ns cut-through时延
  • 全端口标配支持RoCEv2
    200+MB大容量高速片上包缓存，显著减小集体通信时RoCE流量的存储转发时延
  • Intel至强CPU + 大容量可扩展内存，运行持续进化的企业级SONiC——AsterNOS网络操作系统，并通过DMA直接访问包缓存，对网络流量进行实时加工
  • INNOFLEX可编程转发引擎：可以根据业务需求和网络状态实时调整转发流程，最大程度避免网络拥塞和故障而造成的丢包
  • FLASHLIGHT精细化流量分析引擎：实时测量每个包的延迟和往返时间等，经过CPU的智能分析，实现自适应路由和拥塞控制
  • 10纳秒级别的PTP/SyncE时间同步，保证所有GPU同步计算
  • 开放的软件架构（生产就绪的SONiC，AsterNOS）通过REST API开放全部网络功能给AI智算中心管理系统，与计算设备相互协同，实现AI算力集群的自动化部署

AI Open Ecology

一文揭秘AI智算中心网络流量 – 大模型训练篇

关注星融元

前言：自2017年起，AI模型的规模每半年翻一番，从初代Transformer的6500万增长到GPT-4的1.76万亿，预计下一代大语言模型将达到10万亿规模。另一方面，用于模型训练的数据量持续增长，如C4数据集，原始数据量累计超过9.5PB，每月新增200-300TB，目前经过清洗加工后的数据集大小约38.5 TB，训练样本数364.6M。进一步，随着多模态大模型的兴起，训练数据从单一的文本过渡到图像和视频乃至3D点云，数据规模将是文本数据的1万倍以上。

AI模型的规模巨大并持续快速增长，不仅将带来数据中心流量的指数型增长，独特的流量特征也将为数据中心网络带来崭新的需求。

深入分析AI大模型在训练、推理和数据存储流量将帮助数据中心建设者有的放矢，用更低的成本，更快的速度、更健壮的网络为用户提供更好的服务。

本篇我们将聚焦于介绍AI大模型训练场景下的网络流量，AI推理和数据存储场景会在接下来的文章中呈现，敬请关注。

AI model

AI训练程序首先将模型参数加载到GPU内存中，之后将经历多个epoch（即使用所有训练集对模型进行一次完整训练），每个epoch的处理过程可以简单描述为4步：

  1. 加载训练数据，在每个epoch中，根据batch size将整个数据集分为若干个mini-batch，分批次加载训练数据，直到遍历整个训练数据集。
  2. 训练，包括前向传播、计算损失、反向传播和参数/梯度更新，每个mini-batch都进行上述步骤。
  3. 评估，使用评估数据集对模型的指标进行评估。这一步是可选的，可以在整个训练完成后单独进行，也可以间隔若干个epoch进行一次。
  4. 保存checkpoint，包括模型状态、优化器状态和训练指标等。为了减少存储需求，通常经过多个epoch后保存一次。

在大模型出现之前，整个过程在可在一台AI服务器内部完成，训练程序从服务器本地磁盘读取AI模型和训练集，加载到内存中，完成训练、评估，然后将结果存储回本地磁盘。虽然为了加速训练，也会采用多块GPU同时训练，但所有的I/O均发生在一台AI服务器内部，并不需要网络I/O。

AI大模型训练的网络流量有哪些？

进入大模型时代，AI训练的流量路径和其网络需求发生了巨大变革。

首先是模型的参数规模超出了单个GPU的内存，采用GPU集群协同计算，则需要相互之间通信以交换信息，这类信息包括参数/梯度、中间激活值等。

庞大的数据集被所有GPU共享，需要集中存放到远端的存储服务器中通过网络调用，分批加载到GPU服务器上。此外，定期保存的参数和优化器状态也需要通过存储服务器共享，在每个训练epoch中，都要通过网络读写数据。

由此，AI大模型训练的网络流量可分为以下两类：

  • 第一类是GPU之间同步梯度和中间激活的网络流量，它发生在所有GPU之间，是一种广播式流量，逻辑上需要所有GPU全连接。
  • 第二类是GPU和存储服务器之间的流量，它仅仅发生在GPU和存储服务器之间，是一种单播流量，逻辑上仅需要以存储服务器为中心的星型连接。

并行训练技术

其中，GPU之间的网络流量与传统数据中心内部流量迥然不同，这与AI大模型的训练方法息息相关——并行训练技术。

并行训练：AI智算中心的主要流量来源

当前广泛应用于AI训练并行计算模式主要有以下三类：

数据并行将不同的样本数据分配给不同的GPU，以加快训练速度；用在主机之间
张量并行将模型的参数矩阵划分为子矩阵，并分配到不同的GPU上，以解决内存限制并加速计算。一般用在主机内部。
流水线并行将模型分为多个阶段，每个阶段分配给不同的GPU，以改善内存利用率和资源效率。一般用在主机之间

并行训练

常见的集合通信流量模式（如下图）

Collective communication

1.数据并行（Data Parallelism）

在数据并行时，主要的网络流量来源于梯度同步，它发生在每次mini-batch处理之后，由一个all-reduce操作计算平均值。理想情况下，所有GPU全连接，每个GPU给其它G-1个GPU单独发送数据，共需发送G x（G-1）份数据。

FSDP(完全分片数据并行)是一种改进的数据并行技术，旨在优化内存使用和通信效率。它通过将模型参数和梯度在多个GPU之间分片（shard）存储，实现更高效的内存利用和通信。

在FSDP时，网络流量来自前向传播的参数收集以及反向传播中的梯度同步。

前向传播的参数收集由all-gather操作完成，all-gather的通信复杂度与all-reduce相同。

后向传播的梯度同步由all-reduce操作完成，由于每个GPU的参数只有原来的1/G，一个epoch中总的网络流量只有普通数据并行的1/G。

2.张量并行（Tensor Parallelism）

在张量并行时，模型参数分布到G个GPU上，每个GPU只存储1/G参数。网络流量主要来自前向传播过程的中间激活值的传递以及反向传播过程中的梯度同步。

前向传播中，各个GPU计算出的中间激活值需要合并，由一次all-reduce操作进行求和。对于每个Token，在模型的每个layer的中均进行2次合并，共2xTxL次通信。

反向传播中，梯度需要在GPU之间同步，这种在每一层的处理中发生2次，由all-reduce操作将各个GPU上梯度求和。这种同步发生在每个mini-batch的每个layer的处理过程中。共2×N×L次通信。

3.流水线并行（Pipeline Parallelism）

在流水线并行时，网络流量主要来自前向和反向传播过程的中间激活值的传递。与张量并行不同，这些流量的传递发生在模型的前后两个阶段之间，使用Point-to-point通信而非all-reduce操作，并且频率也大大减小了。

综上，在三种并行方式中，张量并行的网络流量最大、频率最高，流水线并行的流量最低，数据并行的通信频率最低。如下表所示，P为模型参数，T为token数，L为模型层数，H为隐藏状态大小，G为GPU数量，N为mini-batch的数量，采用BFLOAT16数据格式，每个参数占2个字节。在每个epoch过程中：

 流量模式后向传播总网络流量反向传播同步次数前向过程总网络流量前向过程传递次数
数据并行all-reduce2 × N × P × G × (G-1)100
FSDPall-gather + all-reduce2 × N × P × (G-1)L2 × N × P × (G-1)L
张量并行all-reduce4 × N × P × L × (G-1)2 × L4 × L × T × H × (G-1) × G2 × L × T
流水线并行Point-to-point2 × T × H × (G-1)G-12 × T × H × (G-1)G-1

以具有80层（L）的Llama3 70B（P）模型和C4数据集为示例计算：采用BFLOAT16数据格式，每个参数占2个字节，隐藏层维度设为8192（H），使用8个GPU（G）进行数据并行。C4数据集token（T）总数约156B，样本数364.6 millions；batch size为2048，则每个epoch包含约178,000个mini-batch（N）。

计算可得每个epoch过程中：

 反向传播总网络流量（PB）反向传播同步次数前向过程总网络流量（PB）前向过程总网络流量
数据并行1396 PB100
FSDP1758017580
张量并行2662216021840160*156*10^9
流水线并行17.9717.97

3D并行技术下的网络流量

数据并行、张量并行和流水线并行三个技术通常会组合起来使用，可进一步提高训练大模型时的效率和可扩展性。这时候，GPU也就按照这三个维度组成了GPU集群。

3D并行技术

假设共有G(tp)×G(pp)×G(dp) 个GPU组成的3D并行阵列，全部P个参数将分割为G(tp)×G(pp)份，每一份大小为P/G(tp)/G(pp)。在模型并行、流水线并行和数据并行三个维度上都存在网络流量。接下来我们将深入到每个epoch的训练过程，分别计算不同阶段的网络流量组成和规模。

3D并行技术

1.反向传播中的网络流量

在每个mini-batch中，反向传播时的梯度同步分为：

  1. 张量维度上的梯度同步，在模型的每一层和数据维度的每一组中进行，总共 LxG(dp) 次，每次包含2个all-reduce操作。
  2. 数据维度上的梯度同步，在流水线维度的每个阶段和张量维度的每一组中进行，总共 G(tp)xG(pp) 次，每次包含1个all-reduce操作。

如下图所示：

反向传播中的网络流量

这样，在一个epoch中，梯度同步的总网络流量为：

4xNxP/Gtp/GppxGtpx(Gtp-1)xLxGdp+2xNxP/Gtp/GppxGdpx(Gdp-1)xGtpxGpp=2xNxPxGdpx[2xLx(Gtp-1)/Gpp+(Gdp-1)]

3.流水线并行维度的中间激活梯度传播，流量为：

2xTxHx(Gpp-1)

因此，在一个epoch中，整个反向传播的总流量为：

2xNxPxGdpx[2xLx(Gtp-1)/Gpp+(Gdp-1)]+2xTxHx(Gpp-1)

2.前向传播中的网络流量

前向传播时，中间激活的传递依次在张量并行、流水线并行维度上交替进行，其中张量并行的激活传递每次包含2个all-reduce操作。

如下图，以一个Token的前向传播所示：

Token的前向传播

因此，在一个epoch中，前向传播总网络流量为：

4xTxHxLxPxGtpx(Gtp-1)+2xTxHx(Gpp-1)

即：

2xTxHx(2xLxGtpx(Gtp-1)+(Gpp-1)

由此，我们以Llama3-70B模型为例，采用8路张量并行 x 8路流水线并行 x 16路数据并行的模式，在共1024个GPU上进行训练，一个epoch产生的总流量约为85EB。如此庞大的流量规模，如果用1个交换容量为51.2T的交换机，24小时满负荷运行，需要约20天才能传输完毕。

考虑到一次预训练通常包含100个左右epoch，如果需要在100天完成训练，至少需要20台51.2T交换机来传输训练过程产生的数据。

AI训练对智算中心网络的要求

通过以上分析和计算，我们可以得出一个典型的AI智算中心对计算网的核心需求。

  • 超高带宽：一个epoch就会产生85EB的数据量，相当于整个互联网2.5天的流量。
  • 超低时延：一个训练样本的处理，就会产生100GB以上的数据，并需要在小于1毫秒的时间传输完毕。相当于1000个800G接口的传输速度。
  • 集合通信：GPU服务器之间的All-reduce, All-gather操作带来广播式流量，在上万个GPU之间，也就是上亿个GPU-GPU对之间同步。
  • 零容忍丢包：基于木桶原理，在集体通信过程中，仅仅是一对GPU之间流量的丢包和重传，也会造成整个集体通信的延迟，进而造成大量GPU进入空闲等待时间。
  • 严格时间同步：同样基于木桶原理，如果GPU的时钟不同步，将造成同样的计算量花费不同的时间，计算快的GPU不得不等待计算慢的GPU。

星融元CX-N系列交换机正是为智算中心AI训练场景而生的超低时延以太网交换机——在保持极致性能的同时，实现可编程、可升级的能力，与计算设备形成协同，共同打造10万级别的计算节点互联，将数据中心重构为可与超级计算机媲美的AI超级工厂。

  • 最大支持64个800G以太网接口，共51.2T交换容量。
    超低时延，在800G端口上实现业界最强的560ns cut-through时延。
  • 全端口标配支持RoCEv2，支持Rail-only，全连接Clos以及200G/400G混合组网，灵活适应不同的算力中心建设方案
  • 200+ MB大容量高速片上包缓存，显著减小集体通信时RoCE流量的存储转发时延。
  • Intel至强CPU + 大容量可扩展内存，运行持续进化的企业级SONiC——AsterNOS网络操作系统，并通过DMA直接访问包缓存，对网络流量进行实时加工。
  • INNOFLEX可编程转发引擎，可以根据业务需求和网络状态实时调整转发流程，最大程度避免网络拥塞和故障而造成的丢包。
  • FLASHLIGHT精细化流量分析引擎，实时测量每个包的延迟和往返时间等，经过CPU的智能分析，实现自适应路由和拥塞控制。
  • 10纳秒级别的PTP/SyncE时间同步，保证所有GPU同步计算。
  • 开放API，通过REST API开放全部功能给AI数据中心管理系统，与计算设备相互协同，实现GPU集群的自动化部署。

星融元发布 51.2T 800G 以太网交换机，赋能AI开放生态

关注星融元

IB与以太之争

以太网替代IB趋势明显。据相关报告：2024年TOP500的超算中，采用以太网方案占比48.5%，InfiniBand占比为39.2%，其中排名前6的超算中已有5个使用以太网互联。

开放系统战胜封闭系统仅是时间问题。我们已经看到，以太网借助其与生俱来的开放性迅速弥合了与InfiniBand的差距，如采用RoCEv2技术路线的星融元CX732Q-N（400G）超低时延交换机，已在多次严格的现场测试中表现出与InfiniBand交换机相当的性能。

以太网走向800G时代

从GPT-1到GPT-4，模型参数数量已从1.1亿增长到5000亿，甚至可能超过万亿。

然而，在部署超算集群的算力中心，先进芯片和先进算力并不对等，算力芯片只提供算力，而先进算力其实遵循着“木桶效应”——算力、存储和网络三个核心环节，出现一个短板会使整个系统的性能出现巨大的下滑。正因如此，800G以太网的推出势在必行。

近年来IEEE（电气电子工程师协会）、OIF（光网络互联论坛）等标准组织相继制定了400G网络的标准，为800G网络的发展奠定了基础。

800G 以太网发展大事记

年份主要事件
2022首款 51.2T 交换芯片发布；网络行业迎来了重要的里程碑。这些交换芯片将支持64个800Gb/s端口，标志着800G以太网发展进入实体化落地阶段。与此同时，首批800G光模块的验证也在此期间开始。
2023标准发布和开发验证；IEEE发布了IEEE 802.3df标准的第一版，该标准定义了800G以太网的物理层规范。与此同时，OIF还发布了224 Gb/s标准，为800G和1.6T系统构建112 Gb/s和224 Gb/s通道提供了指导方针。
2024-2026预计将确认800G以太网的物理层标准，进一步完善和测试规范，以确保网络设备的互操作性和高性能。

星融元超低时延800G以太网交换机

CX864E-N是一款行业顶尖规格的单芯片盒式以太网交换机，专为AI训练/推理、高性能计算（HPC）和云计算/存储的需求设计，具有业界领先的低延迟和高可靠性，是AI时代下智算中心的首选。它拥有 51.2T 的超大交换容量和 64x800G 的端口密度，可构建超大规模数据中心，并在更优的投入成本下提供与 InfiniBand 网络相当的端到端性能。
CX864E-N符合UEC（超以太网联盟）标准，具有丰富全面的 API，便于与数据中心和HPC集群的无缝集成，其作为厂商中立的网络设备亦可兼容其他主流厂商的GPU和网卡硬件。

产品亮点

  • 单芯片51.2T 高密端口以太网交换机，极简的硬件设计，在2RU 空间可提供 64x800G OSFP 或 128x400G/512x100G
  • 全端口支持RoCE（基于融合以太网的RDMA）以及用于简化无损以太网配置管理的Easy RoCE
  • 行业速度最快的交换机，兼容400G和800G，800GE 端口转发延迟低于 560 纳秒
  • 满流量负载下64x800G SR8 端口的最大 TDP 为 2200W
    200+MB 的大型片上缓冲区可实现更好的 RoCE 无损以太网性能
  • 10ns PTP 和 SyncE 性能，支持严格时间同步的 AI 并行计算
  • 先进的 INT（带内网络遥测）提供更加实时精确的数据包延迟、丢包和路径数据，助力实现更先进的拥塞控制算法
  • 搭载企业就绪的SONiC 发行版 AsterNOS，提供一站式的开放网络解决方案；功能容器化软件架构让操作系统更加强大、可靠，且易于二次开发和定制
  • 兼容来自业界主流供应商的异构 GPU 和 SmartNIC
  • 线速可编程，平滑支持不断演进的 UEC（超以太网联盟）标准

系列化交换机产品，构建中立、开放的一站式高性能AI网络

星融元成立于2017年，是国内领先的互联软硬件解决方案提供商。自成立以来，星融元上百名SONiC 研发专家组成的专业团队一直专注于打造世界上最好的SONiC 网络操作系统——最终成果便是 AsterNOS。基于此，星融元推出了1G-800G的系列化交换机，全面覆盖从PoE接入到大规模AI训练的网络互联场景。

经过多年的技术积淀和迭代，星融元已在国内外AI算力中心、云服务商、垂直行业、园区网等多场景头部客户实现落地，为移动云、国家电网、人民银行等海内外上千家客户提供完整网络互联方案，并在年初以第一名身份中标中国移动2023-2024年白盒交换机集采。

面向新时代下的新需求和新挑战，星融元仍将积极拥抱开放生态，持续为用户构建中立透明、易于运维、高性价比的AI基础网络。

图片星融元vAsterNOS（设备模拟器）现已发布，可运行在GNS3、EVE-NG等网络虚拟软件中体验命令行操作及部分功能特性，您可前往以下平台免费下载镜像！

星融元官网 http://asterfusion.com/d-vasternos/

GNS3平台 http://www.gns3.com/asterfusion-vasternos

欢迎广大开放网络/SONiC技术爱好者加入官方交流群，获取用户指导手册和其他一手资料，更有vAsterNOS相关技术人员在线答疑。（Q群号：801700146，验证消息：姓名+所在公司/组织+联系电话或工作邮箱）

Easy RoCE：在SONiC交换机上一键启用无损以太网

关注星融元

RDMA（远程直接内存访问）技术是一种绕过 CPU 或操作系统，在计算机之间直接传输内存数据的技术。它释放了内存带宽和 CPU，使节点之间的通信具有更低的延迟和更高的吞吐量。目前，RDMA 技术已广泛应用于高性能计算、人工智能工作负载、存储和许多其他场景。

1、RoCEv2对网络的需求和挑战

RoCEv1 基于以太网链路层实现，通过交换机上的流量控制技术确保物理层的可靠传输。RoCEv2 在 UDP 层之上实现，弥补了 InfiniBand 的一些局限性，支持更广泛的 RDMA 应用。

与 TCP 协议相比，UDP 速度更快，消耗的资源更少，但没有TCP的滑动窗口和确认响应等机制来确保可靠传输。在 RoCEv2 网络中，如果出现数据包丢失，网卡将丢弃所有收到的数据包，而发送方需要重新传输所有后续数据包，导致网络传输性能大幅下降。因此，我们通常使用 PFC（优先级流量控制）和 ECN（显式拥塞通知）等功能来保证可靠性。

在以太网交换机上配置上述功能需要熟悉 QoS 机制、配置逻辑和相关命令行。对于长期为客户配置 RoCEv2 网络的工程师来说，这可能并不困难。但对于大部分从事高性能计算和存储领域的技术人员，他们通常专注于服务器侧的相关技术，这种相对复杂的，但又必须调通的网络配置给他们带来了很多麻烦，甚至以往运维过IB网络的工程师也需要花时间学习相关知识。

2、在SONiC交换机上用常规步骤配置无损以太网

现在让我们快速回顾一下如何在SONiC交换机上按常规方法配置 RoCEv2 无损以太网。这里使用的是星融元CX-N系列超低时延交换机，搭载SONiC企业级发行版AsterNOS3.1 R0405P01版本，但没有使用其上的 EasyRoCE 功能。

在部署 RoCEv2 网络时，务必首先确认网络硬件条件：低延迟网络交换机需要能支持 PFC 和 ECN 等功能，服务器侧的网卡也需要支持 RoCEv2 。常规步骤下：

  1. 启用和取消需要分别配置 PFC 和 ECN。
  2. 故障排除或状态检查通常需要进入不同的命令行视图并多次执行 “show “命令，以确定当前队列映射、缓冲区、启用的队列、阈值、队列吞吐量、暂停和 CNP 触发器。

第一步，确保服务器网卡工作在 RoCEv2 模式下，为业务流量配置 PCP 或 DSCP，并启用 ECN。

#设置网卡RDMA CM的工作模式
[root@server ~]# cma_roce_mode -d mlx5_0 -p 1 -m

#设置网卡的优先级类型为DSCP
[root@server ~]# mlnx_qos -i enp1s0f0 –trust=dscp
DCBX mode: OS controlled
Priority trust state: dscp

#在队列3上开启PFC
[root@server ~]# mlnx_qos -i enp1s0f0 -f 0,0,0,1,0,0,0,0

#在队列3上开启DCQCN
[root@server ~]# echo 1 > /sys/class/net/enp1s0f0/ecn/roce_np/enable/3
[root@server ~]# echo 1 > /sys/class/net/enp1s0f0/ecn/roce_rp/enable/3

#设置CNP DSCP
[root@server ~]# echo 48 >

然后，在交换机端口配置以启用 PFC 和 ECN 功能并指定队列。您需要在以太网交换机的指定队列（需与服务器上的队列匹配）上启用 PFC 和 ECN，并调整缓冲区和阈值。

# 设置PFC门限值
sonic(config)# buffer-profile pg_lossless_100000_100m_profile
sonic(config-buffer-profile-pg_lossless_100000_100m_profile)# mode lossless dynamic -2 size 1518 xon 0 xoff 46496 xon-offset 13440
sonic(config-buffer-profile-pg_lossless_100000_100m_profile)# exit

# 在3、4队列开启PFC功能（AsterNOS的PFC功能默认使能3、4队列，无需配置）
sonic(config)# priority-flow-control enable 3
sonic(config)# priority-flow-control enable 4
sonic(config)# exit

# 设置ECN门限值
sonic(config)# wred roce-ecn
sonic(config-wred-roce-ecn)# mode ecn gmin 15360 gmax 750000 gprobability 10
sonic(config-wred-roce-ecn)# exit

# 配置Diffserv map
sonic(config)# diffserv-map type ip-dscp roce-dmap
sonic(config-diffservmap-roce-dmap)# ip-dscp 48 cos 6

# 配置Class map
sonic(config)# class-map roce-cmap
sonic(config-cmap-roce-cmap)# match cos 3 4
sonic(config-cmap-roce-cmap)# exit

# 配置Policy map
sonic(config)# policy-map roce-pmap
sonic(config-pmap-roce-pmap )# class roce-cmap
sonic(config-pmap-c)# wred roce-ecn
sonic(config-pmap-c)# priority-group-buffer pg_lossless_100000_100m_profile
sonic(config-pmap-c)# exit
sonic(config-pmap-roce-pmap )# set cos dscp diffserv roce-dmap
sonic(config-pmap-roce-pmap )# exit

# 进入以太网接口视图，绑定策略，将RoCE网络配置在接口上使能
sonic(config)# interface ethernet 0/0
sonic(config-if-0/120)# service-policy roce-pmap

3、使用AsterNOS上的Easy RoCE快捷配置无损以太网

星融元在 AsterNOS 上推出了 “EasyRoCE” 功能，该功能将无损以太网相关的配置命令行进行了封装和模板化，大大简化了RoCEv2网络配置和部署流程。请注意，以下命令行仅简单展示交换机上与该功能相关的部分关键配置，完整的验证演示流程请参考文末视频。

一键启用无损以太网

一键RoCE

故障排除或状态检查

AsterNOS 的 Easy RoCE 功能支持 show roce 命令行，用于一站式查看全局或接口视图的RoCE 配置和计数，以及清除所有配置和计数。

# 检查RoCE配置
sonic# show qos roce

故障排除

# 查看特定接口的计数
sonic# show counters qos roce interface 0/0 queue 3
# 清除全部计数
sonic# clear counters qos roce

状态检查

自动化配置和网络可见性

上述命令可帮助您快速配置无损以太网，如果您需要微调参数，Easy RoCE也支持自定义更改设备提供的默认模板，该模板也可通过上层管理平台向设备下发。

基于 AsterNOS 的开放式架构，我们还开发了一个容器化部署的 roce_exporter，用于提取设备 RoCE 相关信息，并与 Prometheus 无缝对接以提高网络可见性。

自动化配置

相关文章

一文梳理基于优先级的流量控制（PFC）

关注星融元

什么是PFC（基于优先级的流量控制）

丢包对不同协议的影响有所不同，应用会以不同的方式作出响应：一些应用可以容忍这一情况，通过重新发送所丢数据包得以恢复。以太网能够支持这些情况，但有些应用不能容忍任何丢包情况，要求保证端到端传输没有丢包。为了使以太网能够满足应用的无丢包要求，需要制定一种方法来通过以太网提供无损服务。基于优先级的流量控制PFC就产生了。PFC（Priority-based Flow Control，基于优先级的流量控制）功能是一种精细的流量控制机制，在IEEE 802.1Qbb标准文档中的定义是：对传统流控暂停机制的一种增强。PFC是基于优先级为不同的业务来提供不同服务的，可以解决传统以太网流控机制和该需求之间的冲突。

PFC工作原理

PFC是暂停机制的一种增强，PFC允许在一条以太网链路上创建8个虚拟通道，为每条虚拟通道指定一个优先等级并分配专用的资源（如缓存区、队列等等），允许单独暂停和重启其中任意一条虚拟通道而不影响其他虚拟通道流量的传输，保证其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

数据中心场景中发生网络拥塞的原因

产生拥塞的原因有很多，在数据中心场景里比较关键也是比较常见的原因有三点：

  • 进行数据中心网络架构设计时，如果采取非对称带宽设计，即上下行链路带宽不一致。也就是说当下联服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。
  • 当前数据中心网络多采用Fabric架构，采用ECMP来构建多条等价负载的链路，并HASH选择一条链路来转发，是简单的。但这个过程没有考虑到所选链路本身是否已经拥塞，对于已经产生拥塞的链路来说，会加剧链路的拥塞。
  • TCP Incast是Many-to-One（多对一）的通信模式，在数据中心云化的大趋势下这种通信模式常常发生，尤其是那些分布式存储和计算应用，包括Hadoop、MapReduce、HDFS等。如图1所示，当一个Parent Server向一组节点发起请求时，集群中的节点会同时收到请求，并且几乎同时相应。所有节点同时向Parent Server发送TCP数据流，使得交换机上连Parent Server的出端口缓存不足，造成拥塞。

TCP Incast多对一通信模式

图1：TCP Incast多对一通信模式

为了实现端到端的无损转发，避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失，交换机必须引入其他机制，如流量控制，通过对链路上流量的控制，减少对交换机Buffer的压力，来规避丢包的产生。

PFC流量控制的工作机制

一旦出现瞬时拥塞，即某个设备的队列缓存消耗较快，超过一定的阈值，设备即向数据进入的方向发送反压信息，上游设备收到反压信息，会根据反压信息指示停止发送或延迟发送数据，并将数据存储在本地端口buffer，如果本地端口buffer消耗超过阈值，则继续向上反压。直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

如图2所示，交换机Switch-1和Switch-2的连接端口分别创建8个优先级队列，并为每个队列分配相应的buffer，业务报文通过数据流中携带的优先级字段进行标识，buffer大小使得各队列有不同的数据缓存能力。

PFC工作机制

图2：PFC工作机制

Switch-2的第5优先级队列出现拥塞时，本端报文处理方式：

  • 如果Switch-2使能了PFC功能，向上游设备Switch-1发送PFC Pause帧，通知对端设备暂时停止发送第5优先级队列的报文。对端设备在接收到PFC Pause帧后，将暂时停止向本端发送该类报文，暂停时间长短信息由PFC Pause帧所携带。当拥塞仍然存在时，此过程将重复进行，直至拥塞解除；
  • 如果Switch-2没有使能PFC功能，则直接将报文丢弃。

当Switch-1收到PFC Pause帧时，其报文处理方式是：

  • 若Switch-1使能了PFC功能，且尚未暂停发送第5优先级的报文，则暂停发送该优先级的报文，并根据PFC Pause帧中对应的暂停时间启动定时器。当定时器到期后，将恢复相应优先级报文的发送；
  • 若Switch-1使能了PFC功能，且已经暂停发送第5优先级的报文，则根据PFC Pause帧中对应的暂停时间更新对应定时器的到期时间；
  • 若PFC Pause帧中对应的暂停时间为0，则相当于使对应的暂停定时器立即到期，立即恢复相应优先级报文的发送；
  • 若PFC Pause帧中对应的暂停时间不为0，则相当于复位对应的暂停定时器。也就是说，只要本端一直拥塞，则对端会因不断收到PFC Pause帧而持续暂停发送相应优先级的报文；
  • 若Switch-1没有开启相应优先级的PFC功能，则不会暂停发送相应优先级的报文。

PFC的帧格式

Pause帧实际上是一个以太帧，IEEE802.1Qbb中定义了PFC帧的格式，如图3所示：

PFC帧格式

图3：PFC帧格式

  • Destination MAC Address：目的MAC地址，为01-80-C2-00-00-01；
  • Source Mac Address：源MAC地址，为本设备MAC地址；
  • Ethernet type：以太网帧长度或类型域，为88-08，用于标明本帧的类型为MAC控制帧；
  • Control opcode：MAC控制操作码，PFC Pause帧仅是MAC控制帧的一种，其在MAC控制帧中的操作码为01-01；
  • Priority enable vector：优先级使能向量，高字节置0，低字节的每个位代表相应的Time[n]是否有效。E[n]代表优先级n，当E[n]为1时，表示Time[n]有效，处理该优先级的数据流，即停止流量发送；当E[n]为0，表示Time[n]无效，忽略该优先级的数据流，即流量不受影响继续发送；
  • Time：时间，包含Time[0]至time[7]的8个数组单元，每个数组单元为2字节。当E[n]为0时，Time[n]没有意义。当E[n]为1时，Time[n]代表接收站点抑制优先级为n的报文发送的时间，时间的单位为物理层芯片发送512位数据所需要的时间；
  • Pad（transmit as zero）：预留，传输时为0；
  • CRC：循环冗余校验。
  • PFC死锁

PFC死锁，是指当多个交换机之间因微环路等原因同时出现拥塞,各自端口缓存消耗超过阈值，而又相互等待对方释放资源，从而导致所有交换机上的数据流都永久阻塞的一种网络状态。

正常情况下，当一台交换机的端口出现拥塞时，数据进入的方向(即下游设备)将发送PAUSE帧反压，上游设备接收到Pause帧后停止发送数据，如果其本地端口缓存消耗超过阈值，则继续向上游反压。如此一级级反压，直到网络终端服务器在Pause帧中指定Pause Time内暂停发送数据，从而消除网络节点因拥塞造成的丢包。

但在特殊情况下，例如发生链路故障或设备故障时，如图4所示，当4台交换机都同时向对端发送Pause帧，这个时候该拓扑中所有交换机都处于停流状态，由于PFC的反压效应，整个网络或部分网络的吞吐量将变为零。

PFC死锁

图4：PFC死锁

相关文章

对星融元产品感兴趣？

立即联系！

电话咨询
联系表单
返回顶部

如何联系我们？

产品中心

快速导航

订阅我们获取最新资讯。

订阅服务

关注星融元

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