一個白牌廠商視角：極簡交換機NOS演進史

作者簡介：成偉，蘇州盛科系統(tǒng)工程師經(jīng)理

傳統(tǒng)的交換機操作系統(tǒng)(簡稱NOS)對大眾是一個相對封閉的領(lǐng)域。隨著白牌交換機的高速增長，NOS紛紛開源，NOS的開發(fā)者也從只有設(shè)備商工程師，擴大到互聯(lián)網(wǎng)，運營商以及云計算的從業(yè)者。

NOS的作用是按照管理者的意志將網(wǎng)絡(luò)中的業(yè)務(wù)在交換機上運轉(zhuǎn)起來。所以NOS首先需要提供對管理者或者控制器的接口；然后需要運行協(xié)議運算，和網(wǎng)絡(luò)中的其他交換機進行協(xié)議面的交互；第三是需要硬件接口來適配交換芯片，風(fēng)扇電源等板載硬件。如下圖，我們可以將NOS拆分為三個核心功能模塊，以及基礎(chǔ)架構(gòu)模塊。

管理接口，包括傳統(tǒng)的CLI, SNMP, WEB功能。SDN引入的Openflow, NET-CONF, OPEN Config，Restful API功能等；協(xié)議應(yīng)用模塊，包括二層的協(xié)議模塊STP, LLDP, M-LAG，三層的協(xié)議模塊OSPF, BGP, VRRP等，以及DHCP, NTP等應(yīng)用模塊，SDN時代的Openflow Agent，包括OVS，；硬件接口上包括對接交換芯片，電源，風(fēng)扇的管理接口；

具備了以上三個核心功能就算是一個合適的NOS了，但給看一個NOS牛不牛，更要看“基礎(chǔ)架構(gòu)”，它是NOS骨骼和肌肉，NOS的健壯性，延展性都由它決定，NOS演進其實是這個基礎(chǔ)架構(gòu)的的演進歷史。

我們將過程分割為兩個階段，第一段是思科，Juniper，Arista的巨頭廠商競爭時期，這個時期核心技術(shù)集中在設(shè)備商手中，是一個技術(shù)積累的階段；第二段是OPS, Sonic和OPX這些開源新勢力的時代，喜歡玩顛覆的互聯(lián)網(wǎng)廠商帶著SDN的新需求參與了進來。

巨頭之爭

原始架構(gòu)

《Inside Cisco IOS Software Architecture》介紹的IOS架構(gòu)如上圖，框架里還包括軟件轉(zhuǎn)發(fā)的模塊，可見屬于非常早期版本。通過藍色方框去剖析Cisco IOS，可以看到IOS滿足了NOS的三個要素，管理接口，協(xié)議應(yīng)用模塊，硬件接口。但是在基礎(chǔ)架構(gòu)上還相對原始，沒有將管理接口和協(xié)議應(yīng)用模塊分開。這個架構(gòu)更多的是解決有無問題，當時的精力更多的還是在業(yè)務(wù)模塊上。

模塊化架構(gòu)

《JunOS OS for Dummies》中介紹的JunOS的架構(gòu)如上圖，包含管理接口，協(xié)議應(yīng)用模塊，硬件接口的同時提出了模塊化架構(gòu)的理念。

The modular architecture of Junos OS allows individual control plane processes to run in their own module (also sometimes called a daemon). Each module has specified processing resources and runs in its own protected memory space, avoiding the processing conflicts that can occur in other platforms.

同樣是比較早期的架構(gòu)，但是通過這個架構(gòu)可以清晰的看到管理接口和其他模塊是分離的，已經(jīng)有一些控制和轉(zhuǎn)發(fā)的分離的意思在里面，但這次演進不是革命性的，更像是從溫飽到小康的進步。

數(shù)據(jù)庫架構(gòu)

Arista的EOS的架構(gòu)圖如上圖，EOS最牛的地方就是他的數(shù)據(jù)庫架構(gòu)，SysDB是一個Key-Value的內(nèi)存數(shù)據(jù)庫，Arista的核心亮點是能夠原生的解決進程級別故障，流程如下：

可以看到進程故障時候，交換芯片繼續(xù)保持轉(zhuǎn)發(fā)，進程恢復(fù)后從SysDB重新獲取狀態(tài)繼續(xù)運行，該功能不但可以保障業(yè)務(wù)的穩(wěn)定運行，還可以實現(xiàn)單進程升級功能。記得當時Arista一個典型的DEMO是將正在運行的STP KILL掉進行單進程升級，因為STP的狀態(tài)都是存在SysDB里的，所以STP進行恢復(fù)工作后，業(yè)務(wù)層面可以做到不感知。

數(shù)據(jù)庫架構(gòu)的演進是一個重大的變革，顛覆了傳統(tǒng)的定義數(shù)據(jù)結(jié)構(gòu)，然后進程間消息通信的傳統(tǒng)的架構(gòu)。開發(fā)者可以使用類似開發(fā)通用軟件的思路進行開發(fā)，而且NOS的數(shù)據(jù)可視化了，大大降低定位問題，解決問題的難度。

思科在NX-OS上同樣通過Key-Value的內(nèi)存數(shù)據(jù)庫來實現(xiàn)了HA，如下圖：

思科的NX-OS清晰的完成了管理和協(xié)議應(yīng)用分離(排名不分先后)，實現(xiàn)了輕量級的Key-Value內(nèi)存數(shù)據(jù)庫完成了HA Infrastructure，思科在龐大的協(xié)議棧包袱下始終不斷演進，同樣令人欽佩。

新勢力

SDN高速發(fā)展，白牌產(chǎn)業(yè)催生了一批開源開放的NOS，這些新興的NOS站在巨人的肩膀上，都基于數(shù)據(jù)庫架構(gòu)，OPS選擇了OVSDB，Sonic和OPX選擇了Redis，OVSDB和Redis都屬于Key-Value的In-memory數(shù)據(jù)庫。

但這并沒有讓新勢力滿足，SDN要的是更快，更靈活，更大規(guī)模，更好擴展。巨頭時期的NOS開發(fā)周期還是過長，升級還是有點不方便，用慣了動態(tài)語言的互聯(lián)網(wǎng)開發(fā)者表示無法接受。數(shù)據(jù)中心的互聯(lián)網(wǎng)用戶對NOS最痛點的需求是如何流量無感知的完成版本迭代，以及如何更方便，更高效的進行版本升級。

數(shù)據(jù)庫架構(gòu) + 容器架構(gòu)

做公有云的微軟自然的想到通過虛擬化重構(gòu)NOS，將容器技術(shù)應(yīng)用到了NOS。容器技術(shù)可以簡單理解為：對Linux操作系統(tǒng)來看是容器是一個進程，容器看自己內(nèi)部是一個輕量級虛擬機。Sonic將各種進程，比如BGP運行在容器中，原生的解決了JunOS提出的模塊化問題，更重要是配合數(shù)據(jù)庫架構(gòu)，由對單進程的升級，變成了對容器的升級，聰明的使用成熟通用的技術(shù)解決傳統(tǒng)問題。

總結(jié)整個基礎(chǔ)架構(gòu)發(fā)展史如下圖：

經(jīng)過歷代演進，NOS已經(jīng)不再是結(jié)構(gòu)復(fù)雜，需要像黑客一樣定位問題，產(chǎn)品化周期和芯片差不多的專用操作系統(tǒng)了�，F(xiàn)代NOS在架構(gòu)上進化為使用通用的數(shù)據(jù)庫，容器虛擬化技術(shù)，支持高速迭代，某種意義上設(shè)備商是不是也可以稱自己是互聯(lián)網(wǎng)公司了。