架构的核心思想如果要用一个比喻来解释 SONiC 的架构它就像一座现代化的工厂每个车间Docker 容器负责一项具体工作车间之间不直接递纸条而是把信息贴在一块中央公告板Redis 数据库上有一个调度中心orchagent统一协调所有车间的产出最终把成品交给生产线ASIC 硬件这种设计的好处很直接某个车间出了问题重启它就行不影响其他车间要增加一个新车间也很简单——只需要知道往公告板哪里写数据、从哪里读数据。全局视图下面这张图展示了 SONiC 的完整架构从上到下分为四层从上到下应用容器层— BGP、LLDP、Teamd、SNMP 等各自实现一个网络功能Redis 数据库— 中央通信枢纽所有容器通过它交换数据Swss 容器— 编排引擎把应用需求翻译成硬件能理解的指令Syncd 容器 ASIC— 通过 SAI 把指令下发到硬件芯片九大容器逐个看Database 容器所有人的公告板这是 SONiC 最基础的容器——其他所有容器都依赖它。里面跑的是 Redis 数据库引擎维护了五个逻辑数据库下一篇会详细讲。所有容器通过 UNIX socket 连接 Redis。不走网络、不用 TCP纯本地通信延迟可以忽略不计。BGP 容器路由协议栈虽然名字叫BGP 容器但它实际跑的是完整的 FRRouting 协议栈支持 BGP、OSPF、IS-IS 等多种路由协议。容器里有三个核心进程它们分工明确bgpd负责和外部路由器建立 BGP 邻居关系接收路由信息。zebra是路由管理器从 bgpd以及其他协议进程收集路由选出最优路径计算出最终转发表FIB。关键点来了zebra 会把计算好的路由同时推向两个方向方向一通过 netlink 写入 Linux 内核路由表。这让设备的 CPU 能转发报文用于处理 ping、SSH 等管理流量。方向二通过 FPM 接口传给fpmsyncdfpmsyncd 再写入 Redis 的 APPL_DB。这条路最终会让硬件 ASIC 学到这条路由所有正常数据流量走硬件线速转发。为什么要两条路径因为数据中心交换机处理的绝大多数流量必须走硬件转发CPU 根本扛不住 Tbps 级别的吞吐但设备自身的管理流量又必须经过 CPU 协议栈。Swss 容器SONiC 的大脑SwSSSwitch State Service是 SONiC 最核心、最复杂的容器。如果 Database 容器是公告板那 Swss 就是调度中心。Swss 里面有两大类角色第一类状态收集者*syncd 进程这些进程从 Linux 系统收集各种状态信息写入 Redis进程做什么写到哪portsyncd监听端口事件网线插拔、speed 变化启动时解析硬件配置获取端口列表APPL_DB STATE_DBintfsyncd监听接口 IP 地址变更APPL_DBneighsyncd监听 ARP/NDP 发现的新邻居MAC 地址 IPAPPL_DB还有一些 *syncd 进程跑在别的容器里但干的事一样进程所在容器做什么fpmsyncdBGP 容器把路由表写入 APPL_DBteamsyncdTeamd 容器把 LAG 状态写入 APPL_DBlldp_syncdLLDP 容器把邻居信息写入 APPL_DB看到规律了吗所有*syncd命名的进程都是状态搬运工——从各处收集信息统一写入 Redis。第二类编排引擎orchagentorchagent是 SONiC 系统中最重要的单个进程。它的工作是从 APPL_DB 读取所有 *syncd 进程写入的状态理解这些状态之间的依赖关系比如路由需要 nexthopnexthop 需要邻居 MAC把最终结果以 ASIC 能理解的格式写入 ASIC_DBorchagent 内部由多个 Orch 类组成每个处理一种资源Orch 类处理什么RouteOrch路由表项NeighOrch邻居/ARP 表项PortsOrch端口配置AclOrchACL 规则FdbOrchMAC 地址表VlanOrchVLAN 配置这些 Orch 类之间也有依赖——RouteOrch 在处理一条路由前会先检查 NeighOrch 里对应 nexthop 的邻居是否已经解析好了。这种跨 Orch 的依赖编排是 orchagent 复杂度的主要来源。第三类配置管理者*mgrd 进程进程做什么intfmgrd监听 CONFIG_DB 和 STATE_DB配置 Linux 内核接口vlanmgrd在依赖条件满足时配置 Linux VLAN 接口mgrd 进程的特点它们会同时看 CONFIG_DB用户想要什么和 STATE_DB当前条件是否满足只有两边都 OK 时才真正执行操作。Syncd 容器软硬件的翻译官Syncd 容器是 SONiC 软件和硬件 ASIC 之间的桥梁。它做的事情概念上很简单从 ASIC_DB 读取 orchagent 写入的硬件编程指令调用 SAISwitch Abstraction InterfaceAPISAI 底层调用芯片厂商提供的 SDK最终把配置写入 ASIC 芯片关键细节在编译 SONiC 镜像时syncd 会链接到特定厂商的 SDK 动态库。这意味着跑 Broadcom 芯片的交换机和跑 Mellanox 芯片的交换机它们的 syncd 容器镜像是不同的——但 Swss、BGP 等上层容器的镜像完全相同。这就是 SAI 抽象层的价值上层应用写一次代码通过 SAI 适配任意芯片。syncd 还有反向职责周期性从硬件读取端口统计信息计数器写入 COUNTERS_DB供 CLI 和 SNMP 消费。Teamd 容器链路聚合运行 Linux 开源的 teamd 实现提供 LACP链路聚合控制协议功能。容器里两个进程teamdLACP 协议栈和对端设备协商聚合teamsyncd把 LAG 的端口成员状态同步到 APPL_DBPmon 容器硬件健康监控负责监控交换机的物理硬件sensord每隔几秒读取温度传感器、电压传感器记录到日志。超过阈值时触发告警fancontrol根据温度调节风扇转速防止设备过热Pmon 通过 Linux 的/sys文件系统和平台驱动交互读取硬件传感器数据。SNMP 容器被网管系统查询数据中心里通常有 Zabbix/Prometheus/LibreNMS 等监控系统通过 SNMP 轮询交换机状态。SNMP 容器就是响应这些查询的snmpd标准 SNMP 守护进程监听 UDP 161 端口sonic_ax_implSONiC 定制的 AgentX 子代理。它从 Redis 读取各种状态端口计数器、邻居信息等翻译成 SNMP MIB 格式提供给 snmpd精妙之处snmpd 本身完全不了解 SONiC 内部结构。sonic_ax_impl 充当翻译官把 Redis 里的数据翻译成 SNMP 世界的语言。LLDP 容器认识你的邻居交换机需要知道每个端口对面连的是什么设备——这就是 LLDP 协议的作用。容器里三个进程配合工作lldpmgrd每 5 秒从 STATE_DB 获取端口状态告诉 lldpd 哪些端口可用lldpd在可用端口上收发 LLDP 数据包和对端设备交换信息lldp_syncd每 10 秒从 lldpd 获取最新邻居信息写入 APPL_DB 的 LLDP_ENTRY_TABLE下游消费者比如 SNMP 子代理从 APPL_DB 读取这些邻居信息响应网管查询。DHCP-relay 容器跨网段的 DHCP当终端设备发出 DHCP 请求但 DHCP 服务器在另一个子网时交换机需要把请求转发过去。这就是 DHCP-relay 容器的工作——简单直接运行标准的 dhcp-relay agent。宿主 Linux 上的组件不是所有功能都跑在容器里。以下组件直接运行在宿主操作系统上sonic-cfggen配置的翻译机当你修改了/etc/sonic/config_db.json并执行config reloadsonic-cfggen 负责解析配置文件根据模板生成各容器需要的具体配置触发相应容器重新加载配置SONiC CLI用户交互基于 Python Click 库构建的命令行工具。show命令从 Redis 读取状态展示给你config命令把你的意图写入 CONFIG_DB。Linux 内核SONiC 深度依赖标准 Linux 内核能力netlink系统事件通知端口 up/down、IP 变更、邻居发现Network namespace容器网络隔离sysfs硬件传感器访问标准路由表CPU 路径的报文转发为什么这种架构行得通你可能会想用 Redis 当通信总线、把功能拆到这么多容器里性能和复杂度不是问题吗在数据中心交换机场景下这些担忧并不成立数据面不经过 Redis— 正常数据包由 ASIC 硬件线速转发Redis 只处理控制面路由更新、配置变更等控制面频率有限— 一台交换机的路由变更可能每秒几十到几百次Redis 每秒可以处理百万级操作可维护性更重要— 数据中心有成千上万台交换机能独立升级某个组件而不影响转发远比省几毫秒控制面延迟重要本篇小结要点内容容器数量9 个主要容器各司其职通信方式所有容器通过 RedisUNIX socket通信最核心容器Swss编排引擎orchagent 是灵魂*syncd 命名规律所有状态收集进程以 *syncd 命名双路径设计路由同时推送到 Linux 内核和硬件 ASIC硬件隔离只有 Syncd 容器接触芯片上层完全硬件无关下一篇预告第4篇Redis 数据库——SONiC 的神经系统— 五大数据库各自存什么、谁在读谁在写、数据格式长什么样。我们还会完整追踪一条路由从 BGP 学到到硬件下发的 12 步旅程。