本文将从以下几个维度梳理相关知识信息，篇幅较长，建议先转发收藏。

• 存储架构沿革
• 分布式存储网络协议选择
• 交换机硬件设备选型
• RoCE无损网络配置和管理（手动配置和自动化配置）
• 性能测试方案（关键指标、测试工具和参数解读）
• 最佳实践

传统集中式存储和分布式存储的对比

传统集中式 SAN/NAS 存储起步早、技术成熟，具备高IOPS、低时延、数据强一致性等优势，适合金融、医疗等行业的核心业务系统的数据库存储场景，但集中式的架构同时决定了它的扩展能力受限于存储机头，无法很好地支撑大规模数据存储和高并发访问场景。

随着云计算技术快速迭代，AI智算的逐步落地应用推广，计算能力与上层业务规模的急速扩展推动着存储基础设施转变为分布式存储架构。

分布式存储作为新一代的存储技术，使用分布式存储软件将算力服务器本地的硬盘组成统一的存储资源池，从架构层面解决了传统集中式存储的扩展性问题，规模可扩展至上千个节点，容量可扩展到PB甚至EB级，并且性能可随容量线性提升。

在分布式存储中，网络通信方面若采用传统的TCP/IP以太网会占用大量的CPU资源，并且需要额外的数据处理。进入全闪存储时代，传统的以太网通信协议栈已无法再满足存储网络需求。

分布式存储网络的搭建

网络协议的选择

为了解决分布式存储I/O路径长和传统TCP协议带来的性能瓶颈，业界已经广泛采用高带宽低时延的RDMA网络与集群内外部的互联。

RDMA可以简单理解为利用相关的硬件和网络技术，服务器A的网卡可以直接读写服务器B的内存，应用程序不需要参与数据传输过程，只需要指定内存读写地址，开启传输并等待传输完成即可。

当前主流的RDMA网络分为了InfiniBand和RoCEv2两大阵营。

IB网络因其性能优异早已广泛应用到 HPC 场景，但需要专用的网卡、交换机配套线缆和管理平台。

RoCEv2使用开放和标准化协议在以太网上传输IB流量，整体部署成本优势明显，采用厂商优化的RoCE网络设备，端到端性能足够稳定替代IB。以下是星融元CX-N系列RoCE交换机与同规格IB交换机的存储集群组网，测试结果甚至局部超越IB，后文会提供更详细的测试信息。

组网架构

在计算和存储分离的部署场景中，我们推荐部署2张Spine-Leaf 架构的物理网，存储后端网将单独使用一张物理网，以保证分布式存储集群能够快速无阻塞地完成多副本同步、故障后数据重建等任务，而存储前端网和业务则可用一张物理网。

另外，存储节点对网络接入侧的可靠性要求相对较高，因此存储集群中的节点，一般推荐使用双归或多归（Multi-homing）方式接入。

网络硬件选型

存储网络的硬件选型方面一般要满足如下几点：

1. 高密度的100G/200G/400G接口，尽量减少交换机台数
2. 支持IB/RoCE协议，500ns以内的端口转发时延，支持PFC/ECN等无损网络特性
3. 全盒式设备形态，提供灵活、扁平的横向扩展能力（支持多达数千个存储/计算节点，并可保证同集群下的任何两台存储服务器之间的通信不超过三跳）

RoCE 无损网络的配置和管理

NVIDIA IB网络的配置和管理已经高度系统化和整体化，此处不加赘述。

与IB相比，未经优化的RoCE网络需要在交换机上手动配置调整，步骤会相对复杂；不过在部分交换机上(星融元CX-N系列)也可以借助于其开放的软件架构和API，引入自动化工具简化RoCE配置，并提供与UFM类似的网络监控和管理能力。

一般手动方式

在完成基础的连接与配置后，需要先根据业务场景对全网的流量优先级进行规划，并对所有的交换机使能PFC与PFC死锁监控功能，让不同的业务流量进入不同的队列进行转发，使基于RoCEv2的存储业务流量优先转发。

同时，使能所有交换机的ECN功能，保障存储队列的低时延和高吞吐。需要注意的是，交换机和服务器网卡上共同的参数需要保持一致，对于队列划分、缓存、PFC门限及ECN门限等配置需要结合业务情况动态调整，以达最佳性能表现。

`#确保服务器网卡工作在 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

基于网络自动化工具

以下能力均来自于星融元 EasyRoCE Toolkit 内相关组件模块，当前该工具套件对签约客户免费。详情访问：https://asterfusion.com/easyroce/

1. 1条命令行启用和模板化配置RoCE ：针对无损网络优化的命令行视图和业务级的命令行封装，实现一条命令行启用；基于芯片规格和应用场景，预设最佳参数模版
2. 关键RoCE指标导出和可视化呈现：在交换机内运行一个容器化的监控采集前端（RoCE Expoter），将RoCE业务相关网络指标采集给开源监控方案Prometheus，为运维团队提供一个开箱即用的RDMA网络监控方案
3. RoCE 网络参数集中呈现：RoCE相关的配置调试信息组织起来集中展示到Prometheus面板，简化排障流程提高效率

存储性能测试的关键指标和软件工具

关键测试指标

存储性能测试项整体上分为IO时延和IOPS两个纬度，每个维度中又会按照读/写、数据块的大小分别进行测试。

通常情况下随机IO的性能远低于顺序IO、写入性能远低于读取性能。

• IO：单个读/写请求
• IO时延：发起请求到收到存储系统的响应消息所花费的时间
• IOPS：每秒存储系统能处理的IO请求数。
• 顺序IO：大量的IO请求连续相邻的数据块，典型的业务有日志、数据备份恢复、流媒体等。顺序IO的性能通常就是最高性能
• 随机IO：IO请求的是随机分布在存储介质各个区域的数据块，比如高并发读写大量小文件，就会导致IOPS和吞吐的性能下降，典型的业务有OLTP、交换分区、操作系统等。随机IO的性能通常是最低性能

此外，数据块大小对存储的性能表现直接的影响。

• 小IO，如1K、4K、8K
• 大IO，如32K、64K甚至更大

较大的IO会带来更高的吞吐，较小的IO会产生更高的IOPS。大多数真实的业务场景中，IO的大小是混合的。

性能测试步骤和工具

1. 存储网络的性能测试。主要关注网络单链路的吞吐和时延，常用的工具是iperf、ib_read/write_bw、ib_read/write_lat；
2. 会进行存储系统的基础性能测试。这里关注的是存储系统的时延和吞吐，常用的工具是fio；
3. 业务级别的兼容性、稳定性以及性能测试。兼容性方面主要测试交换机的API是否能满足业务系统的要求，稳定性方面的测试则是网络设备级和链路级别的高可靠，性能测试则会用业务场景专用的测试工具进行压测，比如：数据库一体机常用的工具是swingbench和hammerdb，对象存储场景中常用的工具是cosbench。

测试参数说明

以下是国内某数据库厂商分别使用 Mellanox SB7700与星融元CX532P-N组网，使用测试工具fio得出的结果概要：

测试时延时使用的是1v1的方式，测试存储系统IOPS时分别用1v1、2v1的方式进行压测。目标是测试服务器在假设的小IO业务场景中（100% 随机，70% 读，30% 写，IO size 4K）的性能表现。

[root@server ~]# fio \
-filename=/root/randrw_70read_4k.fio \
-direct=1 \
-iodepth 1 \
-thread \
-rw=randrw \
-rwmixread=70 \
-ioengine=psync \
-bs=4k \
-size=5G \
-numjobs=8 \
-runtime=300 \
-group_reporting \
-name=randrw_70read_4k_local

`-filename=/root/randrw_70read_4k.fio`
支持文件、裸盘、RBD image。该参数可以同时制定多个设备或文件，格式为：-filename=/dev/vdc:/dev/vdd（以冒号分割）。

`-direct=1`
direct即使用直接写入，绕过操作系统的page cache。

`-iodepth=1`
iodepth是设置IO队列深度，即单线程中一次给系统多少IO请求。如果使用同步方式，单线程中iodepth总是1；如果是异步方式，就可以提高iodepth，一次提交一批IO，使得底层IO调度算法可以进行合并操作，一般设置为32或64。

`-thread`
fio默认是通过fork创建多个job，即多进程方式，如果指定thread，就是用POSIX的thread方式创建多个job，即使用pthread_create()方式创建线程。

`-rw=randrw`
设置读写模式，包括：write(顺序写)、read(顺序读)、rw(顺序读写)、randwrite(随机写)、randread(随机读)、randrw(随机读写)。

`-rwmixread=70`
设置读写IO的混合比例，在这个测试中，读占总IO的70%，写IO占比30%。

`-ioengine=psync`
设置fio下发IO的方式，本次测试使用的IO引擎为psync。

`-bs=4k`
bs即block size(块大小)，是指每个IO的数据大小

`-size=5g`
测试总数据量，该参数和runtime会同时限制fio的运行，任何一个目标先达到，fio都会终止运行。在做性能测试时，尽量设置大点，比如设置2g、5g、10g或者更大，如果基于文件系统测试，则需要需要小于4g。

`-numjobs=8`
本次作业同时进行测试的线程或进程数，线程还是进程由前面提到的thread参数控制。

`-runtime=300`
测试总时长，单位是s。和size一起控制fio的运行时长，在做一般性性能测试的时候，该时间也尽量设置长点，比如5分钟、10分钟。

`-group_reporting`
多个jobs测试的时候，测试结果默认是单独分开的，加上这个参数，会将所有jobs的测试结果汇总起来。

`-name=randrw_70read_4k_local`
本次测试作业的名称。

最佳实践

星融元（Asterfusion）为中国TOP3公有云打造媲美IB的低时延网络。

需求背景

该公有云用户作为中国TOP3云计算服务市场的重要参与者之一，为政府、企业和个人用户提供安全可靠的云计算解决方案。2022年需要对存储业务区域进行扩容，进一步提升网络服务质量。

• 设备时延要低，满足分布式存储的业务需求
• 具有良好的供应链保障机制
• 能够提供及时且专业的技术支持

方案介绍

通过星融元CX664D-N（64x200GE）大容量低时延以太网交换机提高应用响应速度，同时为业务提供无损传输保障，满足高可靠、低时延的需求。

• 整网采用RoCEv2，通过PFC、ECN、DCBX保障业务无损，提供与IB媲美的性能和无损网络
• 超低时延提高业务并发量，加快数据传输速度，提升业务响应效率，抢占市场先机
• 更低的技术门槛和运维成本，可以在传统以太网上实现超低时延、零丢包、高性能的网络传输

相关文档：分布式存储网络解决方案

产品型号： 星融元（Asterfusion）CX664D-N（64 x 200G QSFP56/QSFP28/QSFP+）
功能特性：RoCEv2, PFC, ECN, DCBX ……

应用场景：分布式存储，数据中心，GPU算力集群……
最后更新：2026-05-26

关注星融元

智算环境组网采用的 Clos 架构下，各交换节点基于常规的 ECMP 路由（分布式运行和自我决策转发）往往无法完全感知全局信息，容易导致多层组网下的流量发生 哈希（HASH）极化 现象，导致某些路径负载过重（拥塞），而其他路径负载很轻（闲置），严重拖慢智算集群整体性能。

什么是哈希极化？

哈希极化，又称哈希不均，其根本原因在于哈希算法的一致性与网络拓扑结构和流量模式特性之间的相互作用。

一般情况下，网络设备通常使用相同或非常相似的哈希算法和相同的输入参数（如标准的五元组）。

当网络中存在大量具有相似特征的流（例如，大量流共享相同的源IP或目的IP），而这些特征恰好是哈希算法的主要输入，那么这些相似的流非常有可能不像预期那样被分布到所有可用的等价路径上，而是呈现出明显的偏向性。

此外，当流量经过多个使用 ECMP 的网络设备（原本在leaf层被“打散”的流量，经过Spine 层转发又被集中到少量链路上），以及流量模式本身的特征（由少数大流主导），都会加剧哈希极化现象。

主动路径规划配置逻辑

在不引入动态负载均衡技术的情况下，我们可以通过增加参与哈希计算的因子，以及主动规范流量路径的方式来应对 AI 算力集群规模化部署的痛点（例如负载均衡和租户隔离等），主动路径规划需要网络工程师按照如下转发逻辑去配置 RoCE 交换机：

1. 智算服务器上每张网卡都对应一个接口，服务器产生跨 Spine 的上行流量会在Leaf交换机判定并执行策略路由转发给对应 Spine

• 在1:1无收敛的情况下，Leaf 交换机的每个下行端口绑定一个上行端口
• 在 n:1 的情况下，上下行端口以倍数关系（向上取整） 形成 n:1 的映射

2. 跨 Spine 上行流量在 Spine 上按照标准 L3 逻辑转发在智算环境下的轨道组网中，多数流量仅在轨道内传输，跨轨传输流量较小，网络方案可以暂不考虑在 Spine 上拥塞的情况；

3. 跨 Spine 下行流量进入 Leaf 后根据 default 路由表指导转发。

可以看到，以上配置逻辑若完全以手动输入命令行的方式下发到所有交换机，会是一件相当繁琐且耗时的事情，也容易引入配置失误。

借助 EasyRoCE 工具配置

为加速智算场景下的路由优化配置，此前我们有介绍过 PPD 工具（主动路径规划，Proactive Path Definer）的1.0 版本。如今经过一段时间的实践打磨，PPD 工具迎来了一轮迭代，升级到2.0版本，其主要运行步骤如下：

1. 从 AID 工具（AI基础设施蓝图规划，AI Infrastructure Descriptor）读取网络基础配置信息。
2. 运行 PPD 工具，生成路由配置文件。
3. 在 UG 工具 （统一监控面板，Unified Glancer）中展示配置文件，用户核对并确认配置下发。

作为 EasyRoCE 工具套件的构成部分，PPD 可以独立运行在服务器上，也可以代码形式被集成到第三方管理软件中。

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

PPD 2.0 升级了什么？

PDD 2.0 版本主要带来了以下几点的显著提升：

• 改善 AID 与 PPD 工具的对接流程，完全实现网络基础信息的自动化填充
• 优化 PPD 工具的图形界面操作体验，配置下发进度和结果可即时呈现，便于管理员快速排查异常原因
• 自动集成到统一监控面板（UG），与其他 RDMA 网络配置信息在一处集中查看和管理

使用演示

第一步：导入基础网络信息

AID 工具是 PPD 的“数据源”，其中有一个专门的工作表存储了 PPD 工具所依赖的所有基础网络信息，主要是 GPU server 各网卡的 IP 地址、交换机接口互联关系和其对应的 IP 地址等，以上都支持一键自动填充；此外，该工作表内还预留有与多租户网络配置相关的标识信息（InstanceID和 Description），管理员可按需手动填写以便于后续管理、使用。

第二步：运行PPD工具生成路由配置

上传PPD相关工具到管理服务器，解压后程序结构如下：

运行 start_ppd.sh 命令即可启动PPD。

第三步：选择下发配置

此时，所有与主动路由规划相关的信息已经自动集成到了统一监控面板，管理员登录UG面板可以看到 PDD 工具界面。

点击左上配置生成按钮，会出现设备可用的配置文件（XXXX.cfg）。管理员可以查看生成配置文件详情二次核对，确认勾选，再点击上方批量下发即可等待工具自动下发配置。

待配置全部下发完成，界面即时显示设备当前部署结果，失败设备提供报错信息，排障后可尝试二次下发。

EasyRoCE-PPD 工具界面概览

关注星融元

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

关于SONiC

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

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

SONiC 系统架构由各种模块组成，这些模块通过集中式和可扩展的基础架构相互交互。其中的核心基础设施是 Redis 数据库，它提供一个独立于语言的接口，支持在所有 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-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 与SONiC社区版主要能力对比-表1

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 系列开放智能网关平台） 。

AsterNOS 的交付模式

软硬一体化交付

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

软件化交付

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

虚拟化试用 （vAsterNOS）

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

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

【参考文档】

• https://www.racheesingh.com/papers/sigcomm-ccr-final465-with-open-review.pdf
• https://searchnetworking.techtarget.com.cn/12-26723
• https://sonicfoundation.dev/demystifying-sonic-its-importance-in-modern-data-centers/