Service and Workflow Intro

There are very many services (resident processes) inside SONiC, 20 or 30 of them, and they will start as the switch starts up and stay running until the switch is shut down. If we want to quickly grasp SONiC, going through it service by service will easily get bogged down in details, so it is best to make a broad classification of these services and control flows to help us build a macro concept.

Note

我们这里不会深入到某一个具体的服务中去，而是先从整体上来看看SONiC中的服务的结构，帮助我们建立一个整体的认识。关于具体的服务，我们会在工作流一章中，对常用的工作流进行介绍，而关于详细的技术细节，大家也可以查阅每个服务相关的设计文档。

服务分类

In general, the services in SONiC can be divided into the following categories: *syncd, *mgrd, feature implementations, orchagent and syncd.

*syncd服务

These services all end with syncd in their names. They all do similar things: they are responsible for synchronizing hardware state into Redis, and generally target either APPL_DB or STATE_DB.

For example, portsyncd is to synchronize the state of all the ports in the switch to STATE_DB by listening to the events of netlink, while natsyncd is to listen to the events of netlink and synchronize the state of all the NATs in the switch to APPL_DB.

*mgrd服务

These services have names that end with mgrd. As the name suggests, these services are so-called "Manager" services, meaning that they are responsible for the configuration of individual hardware, the exact opposite of *syncd. Their logic has two main parts:

  1. 配置下发：负责读取配置文件和监听Redis中的配置和状态改变（主要是CONFIG_DB，APPL_DB和STATE_DB），然后将这些修改推送到交换机硬件中去。推送的方法有多种，取决于更新的目标是什么，可以通过更新APPL_DB并发布更新消息，或者是直接调用linux下的命令行，对系统进行修改。比如：nbrmgr就是监听CONFIG_DB，APPL_DB和STATE_DB中neighbor的变化，并调用netlink和command line来对neighbor和route进行修改，而intfmgr除了调用command line还会将一些状态更新到APPL_DB中去。
  2. 状态同步：对于需要Reconcile的服务，*mgrd还会监听STATE_DB中的状态变化，如果发现硬件状态和当前期望状态不一致，就会重新发起配置流程，将硬件状态设置为期望状态。这些STATE_DB中的状态变化一般都是*syncd服务推送的。比如：intfmgr就会监听STATE_DB中，由portsyncd推送的，端口的Up/Down状态和MTU变化，一旦发现和其内存中保存的期望状态不一致，就会重新下发配置。

功能实现服务

There are some functions that do not rely on the OS itself, but are implemented by some specific processes, such as BGP, or some external interfaces. These services often have names ending in d for deamon, e.g.: bgpd, lldpd, snmpd, teamd, etc., or simply the name of this function, e.g.: fancontrol.

orchagent服务

This is one of the most important services in SONiC, unlike other services that are only responsible for one or two specific functions, orchagent, as the orchestrator (orchestrator) of the switch ASIC state, checks all the states in the database from the *syncd service, consolidates them and sends them down to the database used to store the switch ASIC configuration: ASIC_DB: This state is finally received by syncd` and calls the SAI API to interact with the ASIC SDK and the ASIC through the SAI implementations provided by each vendor, and finally sends the configuration down to the switch hardware.

syncd服务

The syncd service is downstream of orchagent, which is named syncd, but it is responsible for both *mgrd and *syncd of ASIC.

  • 首先，作为*mgrd，它会监听ASIC_DB的状态变化，一旦发现，就会获取其新的状态并调用SAI API，将配置下发到交换机硬件中。
  • 然后，作为*syncd，如果ASIC发送了任何的通知给SONiC，它也会将这些通知通过消息的方式发送到Redis中，以便orchagent和*mgrd服务获取到这些变化，并进行处理。这些通知的类型我们可以在SwitchNotifications.h中找到。

服务间控制流分类

With these categories, we can understand the services in SONiC more clearly, and it is very important to understand the control flow between services. With the above classification, we can also divide the main control flow here into two categories: configuration delivery and state synchronization.

配置下发

The flow of configuration issuance is generally as follows:

  1. 修改配置：用户可以通过CLI或者REST API修改配置，这些配置会被写入到CONFIG_DB中并通过Redis发送更新通知。或者外部程序可以通过特定的接口，比如BGP的API，来修改配置，这种配置会通过内部的TCP Socket发送给*mgrd服务。
  2. *mgrd下发配置：服务监听到CONFIG_DB中的配置变化，然后将这些配置推送到交换机硬件中。这里由两种主要情况（并且可以同时存在）：
    1. 直接下发：
      1. *mgrd服务直接调用linux下的命令行，或者是通过netlink来修改系统配置
      2. *syncd服务会通过netlink或者其他方式监听到系统配置的变化，并将这些变化推送到STATE_DB或者APPL_DB中。
      3. *mgrd服务监听到STATE_DB或者APPL_DB中的配置变化，然后将这些配置和其内存中存储的配置进行比较，如果发现不一致，就会重新调用命令行或者netlink来修改系统配置，直到它们一致为止。
    2. 间接下发：
      1. *mgrd将状态推送到APPL_DB并通过Redis发送更新通知。
      2. orchagent服务监听到配置变化，然后根据所有相关的状态，计算出此时ASIC应该达到的状态，并下发到ASIC_DB中。
      3. syncd服务监听到ASIC_DB的变化，然后将这些新的配置通过统一的SAI API接口，调用ASIC Driver更新交换机ASIC中的配置。

Configuration initialization is similar to configuration distribution, but the configuration file is read when the service is started, so we won't expand on that here.

状态同步

If at this time, something happens, such as a bad network port, the state in the ASIC changes, etc., this time we need to do a state update and synchronization. This process generally looks like this:

  1. 检测状态变化：这个状态变化主要来源于*syncd服务（netlink等等）和syncd服务（SAI Switch Notification），这些服务在检测到变化后，会将它们发送给STATE_DB或者APPL_DB。
  2. 处理状态变化：orchagent和*mgrd服务会监听到这些变化，然后开始处理，将新的配置重新通过命令行和netlink下发给系统，或者下发到ASIC_DB中，让syncd服务再次对ASIC进行更新。

具体例子

The official documentation of SONiC gives several examples of typical control flow, so I won't expand too much here, interested parties can go here: [SONiC Subsystem Interactions](https://github.com/sonic-net/SONiC/wiki/ Architecture#sonic-subsystems-interactions). We will also choose some very common workflows to expand on later in the workflow chapter.

参考资料

  1. SONiC Architecture