linux+FBOSS

FBOSS负责管理交换机ASIC并提供更高级别的远程API，转换为特定的ASIC SDK方法。外部处理的包括管理、控制，路由、配置和监控流程。下图说明了交换机中的FBOSS、其他软件进程和硬件组件。请注意，在我们的生产环境部署中，FBOSS与我们的服务器共享相同的Linux环境（例如，操作系统版本、打包系统），因此我们可以在服务器和交换机上使用相同的系统工具和库。

FBOSS由多个互连组件组成，有这几大类：交换机软件开发工具包（SDK），HwSwitch，硬件抽象层，SwSwitch，状态观察器，本地配置生成器，Thrift管理接口和QSFP服务。 FBOSS代理是主进程，运行着FBOSS大部分功能 。交换机SDK与FBOSS代理打包在一起并进行编译。SDK由外部的交换机ASIC供应商提供。除QSFP服务之外的所有其他组件（作为其独立进程运行）驻留在FBOSS代理内。

交换机SDK。交换机SDK是ASIC供应商提供的软件，它暴露出用于与底层ASIC功能交互的API。这些API包括ASIC初始化、安装转发表规则和监听事件处理程序。

HwSwitch。 HwSwitch代表交换机硬件的抽象。 HwSwitch的接口提供了用于配置交换机端口、向这些端口发送和接收数据包、以及为端口上的状态更改和这些端口上发生的数据包输入/输出事件注册回调的通用抽象。除了通用抽象之外，ASIC特定实现也被推送到硬件抽象层，允许与交换机硬件进行交换机无关的交互。虽然不是一个完美的抽象，但FBOSS已被移植到两个ASIC系列，并且正在进行更多移植。

状态观察器（State Observers）。通过保持协议状态变化，SwSwitch可以实现ARP，NDP，LACP和LLDP等底层控制协议。通过称为状态观察（State Observation）的机制向协议通知状态变化。具体而言，任何对象在初始化时都可以将自身注册为状态观察者。通过这样做，每个未来的状态更改都会调用对象提供的回调。回调提供了对有问题的状态更改、允许对象做出相应的反应。例如，NDP将自身注册为状态观察器，以便它可以对端口更改事件做出反应。通过这种方式，状态观察机制允许协议实现与关于状态管理的问题分离。

Thrift管理接口。网络的配置管理平面是与网络分离的。每个FBOSS实例都包含一个本地控制平面，运行如BGP等协议，在微服务器上通过Thrift管理接口与集中式网络管理系统进行通信。FBOSS Thrift接口的完整开源规范可公开获取的。鉴于可以修改接口以满足我们的需求，Thrift为我们提供了一种简单而灵活的方式来管理和操作网络，从而提高稳定性和高可用性。

QSFP服务。 QSFP服务管理一组QSFP端口。 该服务检测QSFP模块的插入或移除、读取QSFP产品信息（例如制造商）、控制QSFP硬件功能（即改变功率配置）、监视QSFP模块。FBOSS最初在FBOSS代理内部拥有QSFP服务。 但是随着该服务的不断发展，我们必须重新启动FBOSS代理和交换机来应用更改。 因此，我们将QSFP服务分离为一个单独的流程，以提高FBOSS的模块性和可靠性。因此，FBOSS代理更可靠，因为QSFP服务中的任何重新启动或错误都不会直接影响代理。但是由于QSFP服务是一个单独的进程，因此需要单独的工具进行打包、部署和监控。 此外，现在需要在QSFP服务和FBOSS代理之间进行精细的进程同步。

状态管理。FBOSS的软件状态管理机制专为高并发、快速读取和简单安全的更新而设计。状态被建模为版本化的copy-on-write (写时复制)树。树的根是主交换机状态类，根的每个子节点代表交换机状态的不同类别，例如端口或VLAN条目。当树的一个分支发生更新时，如果有必要,将会复制并更新分支中一直到根的每个节点。下图说明了由VLAN ARP表条目更新调用的交换机状态更新过程。我们可以看到只重建了从修改后的ARP表到根目录的节点和链接。在创建新树时，FBOSS代理仍然与先前的状态交互，而不需要捕获任何状态上的锁。一旦完成整个树的copy-on-write过程，FBOSS将从新的交换机状态进行读取。

硬件特定状态。硬件状态是保留在ASIC内部的状态。每当需要在软件中更新硬件状态时，软件必须调用交换机SDK以检索新状态。 FBOSS HwSwitch在硬件状态的相应部分上获得读锁和写锁，直到更新完成。基于锁定的状态更新的选择可能因SDK实现而异。

部署。FBOSS不使用像Chef或Jenkins这样的现有自动化软件部署框架，而是使用自研的名为fbossdeploy的部署软件。开发我们自己的部署软件的主要原因之一是允许与现有外部监视器进行更紧密的反馈循环。我们有几个现有的外部监视器，可以持续检查网络的健康状况。这些监视器检查链路故障、BGP收敛时间、网络可达性等属性。虽然为部署通用软件而构建的现有部署框架可以很好地防止软件相关错误的传播，例如死锁或内存泄漏，但它们不是为了检测和防止整个网络范围的故障而构建的，因为这些故障可能很难从单个节点检测出来。因此，构建fbossdeploy可以快速响应部署期间可能发生的整个网络范围的故障，例如可达性故障。FBOSS部署过程（代号叫金丝雀）与其他持续部署过程非常相似，并分为三个不同的部分：持续部署、每日部署和分阶段部署。这三个部分中的每一个都是为了可靠部署这个目的。我们目前是大体按月的部署周期，按月的部署周期包含“持续部署”、“每日部署”和“分阶段部署”，以确保高度的运营稳定性。

配置设计。网络设备的配置在数据中心环境中高度标准化。给定一个特定拓扑，每个设备都使用模板和自动生成的配置数据进行自动配置。例如，交换机的IP地址配置由交换机的类型（例如，ToR或aggregation）,还有集群中的交换机上游/下游邻居确定。

配置生成和部署。配置数据由我们的网络管理系统Robotron生成，并分发给每个交换机。然后，FBOSS代理中的本地配置生成器使用配置数据并创建活动配置文件。如果对数据文件进行了任何修改，则会生成新的活动配置文件，并将旧配置存储为分阶段配置文件。这种配置过程有许多优点。首先，它不允许多个实体并发修改配置，这避免了配置出现不一致。其次，它使配置可重现且确定，因为配置是版本化的，并且FBOSS代理总是在重新启动时读取最新配置。最后，它避免了人为配置错误。另一方面，我们的全自动配置系统也存在缺点 – 它缺乏功能强大的人机交互式CLI，使得手动调试错误变得困难;此外，不支持增量配置更改，这又使得每次配置更改都需要重新启动FBOSS代理。

监控和故障处理。传统上，数据中心运营商使用标准化的网络管理协议（如SNMP）从供应商网络设备收集交换机统计信息，例如CPU/内存利用率、链路负载、数据包丢包情况和其他系统运行健康状态。相比之下，FBOSS允许外部系统通过两种不同的接口收集交换机统计信息：Thrift管理接口和Linux系统日志。 Thrift管理接口以Thrift模型中指定的形式提供查询。该接口主要用于监控交换机上层的使用情况和链路统计信息。鉴于FBOSS作为Linux进程运行，我们也可以直接访问交换机微服务器的系统日志。这些日志专门用于记录事件类别和失败事件。这允许管理系统监视底层系统运行状况和硬件故障。对于收集的统计数据，我们的监控系统FbFlow 根据数据类型将数据存储到Scuba或Gorilla数据库中。存储数据后，我们的工程师可以在很长一段时间内在高层次查询和分析数据。监控系统可以轻松获得监控数据。

ONIE+ONL+SAI+SONIC

SONiC由微软提供，SONiC是构建网络设备（如交换机）所需功能的软件集合。它可以通过交换机换抽象接口（SAI）运行在不同的ASIC平台。正是由于SAI的存在，SONiC的的App（网络功能）才能够支持多个厂家的ASIC。SONiC的网络应用都是基于容器构建的，可以非常方便的在生产环境实现不停机部署或升级应用。需要注意的是，SAI没有公开源代码，ASIC厂家只提供二进制格式的SAI文件。虽然SAI没有开源，但是SAI向上给SONiC提供了一套统一的API 接口，向下则对接不同的ASIC。

SONiC得到了交换机芯片厂家、系统厂商、应用等的广泛支持。

SONiC和SAI支持的ASIC芯片厂商及其对应产品为：

SONiC是构建交换机网络功能的软件集合，需要运行在Base OS上。SONiC所使用的Base OS 是ONL (Open Network Linux ) 。ONL是一款为白盒交换机而设计的开源Linux操作系统，ONL中包括了许多硬件（温度传感器、风扇、电源、CPLD控制器等）的驱动程序。

SONiC支持非常完善的网络协议，支持BGP、ECMP、QoS-ECN、PFC、WRED、CoS、SNMP、Syslog、LLDP、NTP、LAG，ACL、DHCP、IPv6等也马上会支持……