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代理。

監控和故障處理。

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等也馬上會支持……

閱讀更多 通信網絡規劃與設計 的文章

關鍵字: 軟件 美好，一直在身邊 開源