认识一下SONiC到底是啥。开始可能有好多地方理解有误，请多指正。文章参照SONiC文档。

概览

SONiC(Software for Open Networking in the Cloud)是安装在Linux上的软件合集，运行在硬件交换机上，在数据中心网络中提供路由功能。因为是一个合集，所以我们首先看一下他由哪些东西组成。

组件

由上图可以看出SONiC由几层组成，由下到上分别是Hardware components，Drivers，Linux Kernel Interface，Other source/bin，SONiC Open Source，Applications。

Hardware components

硬件组件是指交换机内所有物理组件，包括风扇、电源、LED和网络收发器。

Drivers

应该是各个厂商提供的相关驱动。

Linux Kernel Interface

图上看主要是netdev和sysfs。

Other source/bin

暂时不清楚。

SONiC Open Source

这是重头戏，主要包含了SAI API、ASIC Control Software、Object Library三块。

• SAI(Switch Abstraction Interface)是标准的C语言API，有特定的交换机ASIC的SDK实现。
• ASIC Control Software是指SWSS(Switch State Service)，主要是收集硬件交换机的状态信息。
• Object Library

SWSS

SWSS是一组软件，提供了数据库接口，用于网络应用程序和网络硬件交换机进行通信和状态表示。

网络应用程序读写数据库APP_DB。比如netlink route syncer，guagga FPM route syncer，ACL control，QoS control，LB，telemetry control等等。
Orchestration agents同时读写APP_DB和ASIC_DB。他负责验证和传输应用数据到SAI对象的逻辑。
syncd进程同时读写ASIC_DB和SAI SDK。

kv数据库

选择kv数据库，是为了提供与语言无关的接口，并且提供数据持久性，复制和多进程通信的方法。
Redis被选择为底层数据库引擎，但是未来可能会改变。

网络应用

SONiC网络应用程序使用SwSS编写完全独立于硬件的通信细节。应用程序仅仅订阅所需的数据。例子包括L3路由、L2桥接、ACL、QoS、Telemetry streaming、Tunneling、link aggregation、LB和策略路由等。

Orchestration Agent

该模块主要是负责在APP表和ASIC表之间转换和复制数据。每个ASIC表只能有一个生产者。目前只有一个业务流agent，后面可以添加。只有一个Orchestration Agent可以写入ASIC_DB数据库。

syncd

syncd主要是负责在ASIC_DB和符合SAI的ASIC SDK之间复制数据，每个SAI SDK只能有一个syncd进程。

Object Library

主要负责SONiC应用和外部应用的交互。Object Library定义了两种类型的应用程序：

• 客户端，对Objects执行创建、设置、获取和删除操作。
• 服务端，执行客户端的请求操作

另外，Object Library实现了publish/subscribe模型。服务端发布事件；客户端订阅事件和对象。客户端可以订阅创建、修改和删除对象时生成的事件。

SONiC架构的关键租户是允许停止、启动、重启和替换进程的。

Applications

主要是通过docker运行一些网络相关功能的app。

Database

SwSS通过使用前缀命名实现redis表的概念，设计producer/consumer时要确保数据的完整性。

APP_表是针对每个场景设计的，比如：ROUTE_TABLE和NEIGH_TABLE。

ASIC_表是从SAI头文件创建的，比如ASIC_sai_unicast_route_entry_t和ASIC_sai_neighbor_entry_t。

Table Operations

Producer

SET - insert or update a key -> fileds and values.
DEL - deletes a key

Consumer

POP - get a table change notification, the key name and the key->feilds and values and operation[SET, DEL]
SELECT - check if a table notifications exists

Transactions

SwSS在内部实现transactions，所以producers和consumers可以使用类似队列的方法与数据库保持同步。

每个TABLE，都有用于内部通知实现的QUEUE key。

下面介绍一个工作实例：

intfsyncd进程使用swss producer API对APP.INTF_TABLE执行SET。producer API在TABLE中配置key/value，并且为每个QUEUE key设置一个等效条目。

OA(the orchestration agent)是APP.INTF_TABLE的consumer，OA将从swss consumer API收到APP.INTF_TABLE数据更改的通知。consumer API将从QUEUE key中pop key、value和OP。intfsyncd写入APP.INTF_TABLE的数据保持不变。

详细信息参照代码：

Tablename+"_KEY_QUEUE"
Tablename+"_VALUE_QUEUE"
Tablename+"_OP_QUEUE"

Switch Data Service Database Schema

定义了两个数据库，APP和ASIC。SwSS之外的APP期望通过明确定义名称的keys添加到APP数据库来存储数据。ASIC数据库存储硬件同步agent使用的数据。ASIC数据库中的key预计严格遵守SAI属性。

keys必须看起来像是表名的字符串作为前缀。允许的key是"a-z[0-9]_"并且以"_TABLE:"结尾

在redis中，数据库只定义我的数字：

数据库0 = APP_DB
数据库1 = ASIC_DB
数据库7 = TEST

schema

详见文档

Database 1 – ASIC_DB

ASIC数据库存储硬件同步agents的数据。ASIC数据库中的keys严格按照SAI属性命名。详情见文档。

Switch state service Layer 3 Implementation

本节提供了如何学习BGP路由并将其传播到ASIC的示例。以quagga为例，但也可以使用其他路由APP。

Platform Management Service

平台管理服务管理外围设备，比如风扇、PDU、LED和收发器。通用交换机平台利用I2C总线，通常与一个或者多个I2C主设备来管理这些设备。这些器件通常通过一些列的I2C多路复用器连接到I2C主器件。

Linux内核具有非常成熟的I2C子系统和定义良好的API。它支持几乎所有常用的I2C设备(主设备、多路复用器、传感器)。然后，SONiC利用Linux内核公开接口来管理这些设备。在这种方式中，SONiC首先为这些I2C设备安装kernel drivers，创建I2C书拓扑，并暴露像hwmon这样的sysfs接口来管理这些设备。

SONiC提供了一些服务和实用程序来管理这些设备：

• decode-syseeprom：显示系统eeprom信息
• sensors：监控温度和风扇速度
• fancontrol：根据传感器温度调整风扇速度
• ledd：根据链路或者系统状态更改LED灯
• sfputil：管理收发器，比如show transceiver eeprom，检测存在，重置，更改lpmode

平台供应商有望开发他们的平台模块来构建I2C树，公开sysfs接口并且开发插件已将他们的设备钩挂到SONiC平台管理服务。详细信息可以查看平台移植指南。