SONiC系统架构

SONiC系统由两部分组成:
1.彼此交互的模块
2.用于交互的基础设施(集中式,可扩展)

其中用于交互的基础设施主要是一个非关系型数据库Redis引擎:
1.提供了一个无视语言的接口
2.是一种数据保持,复制和多进程交互的手段

每个模块只订阅自己关注的数据

每个模块都存在于各自的Docker容器里形成独立的组件,每个组件都与平台细节完全解耦

SONiC由一下几个容器组成:

  • Dhcp-relay
  • Pmon
  • Snmp
  • Lldp
  • Bgp
  • Teamd
  • Database
  • Swss
  • Syncd

下图描绘出了每个模块中包含的功能,以及它们之间的交互。
不是所有的功能都与Redis服务器交互,其中一些功能与外部实体(netlink,文件系统等)产生交互。
图中蓝色箭头表示与Redis数据库的交互,黑色交投表示与外部实体的交互

不是所有的功能都位于某个容器中,比如CLI和sonic配置模块,就是位于Linux主机上的
SONiC系统架构_第1张图片

SONiC子系统描述

Teamd container:

Pmon container:

Snmp container:

Dhcp-relay container:

Lldp container:

Bgp container:

可以运行Quagga或FRR的路由协议栈
此容器可以进一步分为以下几个部分:

  • bgpd :
    获取路由状态,并将其通过zebra和fpmsyncd接口下发到转发面
  • zebra :
    是一个路由管理器。它提供路由表更新,接口查询,不同协议间的路由分发
    同时,它会将计算好的FIB下发到内核(通过netlink)和南向转发进程组件(通过Forwarding-Plane-Manager interface也就是FPM)
  • fpmsyncd:
    一个小小的守护进程。主要负责将从zebra处收集到的FIB状态注入到Redis引擎中的APPL_DB表

Database container:

Swss container:

SWitch State Service是一组工具套装,它能有效促使SONiC各个模块之间的交流
它提供了一个机制去促成多方的交流和仲裁

同时,SWSS的几个进程会负责与SONiC应用层的北向交互
其中有三个进程是运行在其他容器里的,包括Fpmsyncd,Teamsyncd和Lldp_syncd
但是无论它们运行在哪个容器里,都有着一个共同的目标:
【提供了 能够使 SONiC应用 和 SONiC的集中式消息基础设施(Redis引擎) 保持连接的途径】
【provide the means to allow connectivity between SONiC applications and SONiC’s centralized message infrastructure (redis-engine).】
这些进程 约定俗成地 命名为 *syncd。下面介绍各种syncd:

  • Portsyncd
    监听与端口相关的(port-related)netlink事件。在启动期间,portsyncd会通过解析系统的硬件配置文件 获取物理端口的信息。
    最终portsyncd将所有收集到的状态信息推送到APPL_DB中。像 端口速率,lanes和MTU将通过此途径传送。
    portsyncd还会将状态注入到STATE_DB。
  • Intfsyncd
    监听与接口相关的(interface-related)netlink事件并将收集到的状态信息推送到APPL_DB。像 新建/修改 的接口IP地址 这样的参数将通过此进程得到处理。
  • Neighsyncd
    监听与邻居关系相关的(neighbor-related)netlink事件,这种事件通常是 新发现的邻居产生的ARP处理进程 触发的。
    像 MAC地址和邻居的地址族信息都是通过这个进程处理的。出于 数据平面的L2重写的目的,最终这个状态信息将用于构建邻接表。再次强调,这个状态信息最终会被传送到APPL_DB中。
  • Teamsyncd
    在teamd容器中运行,其获取到的状态信息将被传送到APPL_DB中。
  • Fpmsyncd
    在bgpd容器中运行,其获取到的状态信息将被传送到APPL_DB中。
  • Lldp_syncd
    在lldp容器中运行。

以上进程都是发布者,根据 发布者/订阅者 模型,SWSS还需要订阅者的角色来完成对接收到的消息的消耗和转移,下面的几个进程就是这样的角色:

  • Orchagent
    这是SWSS子系统最重要的组件。Orchagent包含一个逻辑处理功能,用来将所有 从其他*syncd进程注入的 状态信息提取出来,然后处理并转发这些信息,最终将这些信息推送至Orchagent的南向接口。这个南向接口就是redis引擎中的ASIC_DB,所以我们可以发现,Orchagent既是订阅者,又是生产者,因为它既从APPL_DB获取数据,也向ASIC_DB提供数据。
  • IntfMgrd
    处理来自APPL_DB,CONFIG_DB和STATE_DB的状态信息,然后在Linux内核中配置接口信息。只有在被检测的任何数据库中没有发生冲突和不一致的数据时,这一步骤才会执行。
  • VlanMgrd
    处理来自APPL_DB,CONFIG_DB和STATE_DB的状态信息,然后在Linux内核中配置vlan接口信息。正如IntfMgrd,只有在没有冲突数据存在的情况下才会执行这一步骤。

Syncd container:

Syncd 的主要目标就是提供一种 能让交换机的网络状态信息 和 交换机硬件/ASIC上的实际状态 保持同步的一种机制。这种机制主要包括初始化,配置以及收集交换机ASIC当前的状态。

它包含了几个主要的逻辑模块:

  • Syncd:
    Syncd执行上述提到的同步机制。在编译时,syncd与 硬件供应商提供的ASIC SDK连接,并且把状态信息注入到ASIC,这个效果是通过引用 被提供的接口 实现的。Syncd订阅ASIC_DB的信息,从SWSS获取信息,与此同时 将自身注册为一个生产者,将从硬件获得的状态信息发布出去。
  • SAI API:
    SAI(Switch Abstraction Interface)定义了一个API,这个API提供了与厂商无关的方式去控制转发单元,例如交换ASIC,它是一个统一化的NPU或者一个软交换。
  • ASIC SDK:
    硬件供应商期望能够提供一种SAI友好型的能够驱动他们的ASIC的SDK实现方法。这种实现方式通常通过动态链接库(dynamic-linked-library)的形式实现,这种机制调取驱动程序(在这里是指syncd)来执行它的驱动。

CLI / sonic-cfggen:

SONiC中负责提供命令行和系统配置的功能模块。
CLI组件重度依赖Python的Click库,该库为用户提供了一种灵活的客制化的方式去构建一个命令行工具。

Sonic-cfggen组件被SONIC的CLI调用,来完成 对配置修改 和 任何与SONiC模块交互的配置相关的动作。

SONiC子系统的交互

路由状态交互

在这一部分,我们来看一下在收到一个eBGP路由更新时SONiC的处理流程。我们假设会话已经建立起来了,而且学到的新路由以它的直连接口作为下一跳。

下图展示处理流程,有些不必要的步骤已经被省略:
SONiC系统架构_第2张图片
(0) 在BGP容器初始化时,zebra通过一个常规的TCP套接字连接到fpmsyncd。在稳定状态下,zebra所持有的路由表,Linux内核,APPL_DB和ASIC_DB需要保持高度一致。

(1) 一个新的TCP数据包到达位于内核空间的BGP位。内核的网络栈最终将携带的载荷递送至bgpd进程。

(2) Bgpd解析这个新的数据包,处理这个bgp更新,并且通知zebra这个新前缀的存在和与该协议相关的下一跳。

(3) 根据zebra的可达性判断,zebra生成一个route-netlink状态信息并将其注入到内核。

(4) Zebra 利用 FPM接口 发送这个netlink-route消息至fpmsyncd.

(5) Fpmsyncd处理该netlink消息然后推送该消息至APPL_DB.

(6) 作为订阅APPL_DB的订阅者,orchagentd将接收之前被推送至APPL_DB的信息内容。

(7) 完成对接收信息的处理后,orchagentd将引用sairedis APIs完成对ASIC_DB的路由信息注入。

(8) 作为订阅ASIC_DB的订阅者,syncd将接收 产生于orchagentd的 新状态信息。

(9)Syncd将会处理信息,然后引用SAI APIs,将这个状态信息注入到相应的asic驱动器中。

(10) 最终,新路由信息被推送到硬件。

你可能感兴趣的:(docker,linux,数据库)