SDN系統方法 | 3. 基本架構

隨著網際網路和資料中心流量的爆炸式增長，SDN已經逐步取代靜態路由交換裝置成為構建網路的主流方式，本系列是免費電子書《Software-Defined Networks: A Systems Approach》的中文版，完整介紹了SDN的概念、原理、架構和實現方式。原文: Software-Defined Networks: A Systems Approach

第3章 基本架構

SDN是一種利用可程式設計的商用硬體構建網路的方法，從而通過軟體實現智慧的包轉發控制以及其他網路操作。實現這樣的設計不依賴任何特定協議棧，而是需要一組開放API以及支援這些API的新軟體元件。本章將介紹SDN軟體棧的基本架構。

本章定義了這種軟體棧的一般架構，介紹了符合該架構的一個示例集合，不過能夠整合到該架構中的特定元件和工具其實有多種選擇。我們這樣做只是為了使討論更加具體，我們介紹的元件有兩個重要屬性。第一，它們是開源的，可以在GitHub上免費獲得。第二，它們旨在共同努力，提供全面的解決方案，覆蓋我們需要的所有場景。這兩個屬性使得任何人都可以構建出在生產網路中執行的相同的端到端系統。

3.1 軟體棧(Software Stack)

圖15給出了軟體棧的概覽，包括一個執行本地交換機作業系統(Switch OS) 的裸金屬交換機(Bare-Metal Switch)，由一組控制應用程式(Control Applications) 控制，這些控制程式託管在全域性網路作業系統(Network OS) 上。圖15右邊顯示了一組對應的範例開源元件(SD-Fabric, ONOS和Stratum)，左邊顯示了相關的P4工具鏈。本章將介紹這些元件，後面章節將給出更多細節。

請注意此圖與第1章中的圖2之間的相似性。兩幅圖都包含兩個開放介面: 一個在控制程式和網路作業系統之間，另一個在網路作業系統和底層可程式設計交換機之間。在圖15中，這兩個介面被描述為“API shims”，在示例元件的上下文中，第一種介面對應於gNMI、gNOI和FlowObjective的組合，第二種介面對應於gNMI、gNOI和P4Runtime或OpenFlow的組合。gRPC是這些API的傳輸協議，這是一種常規的實現選擇。(注意，與其他協議不同，OpenFlow不會在gRPC上執行。)

重要的是要記住，圖15中列出的軟體元件都對應於活躍開源專案，因此會繼續發展(就像它們的API一樣)。每個元件的特定版本(及其相關API)已經整合並部署到試驗和生產環境中。例如，雖然圖中顯示P4Runtime是Switch OS匯出的候選控制介面，但也有一些部署的解決方案使用OpenFlow。(包括Comcast的部署。)類似的，雖然圖中顯示gNMI/gNOI作為交換機的配置/操作介面，但也有使用NETCONF的解決方案。

本書的目的不是要試圖跟蹤所有可能的組合的元件版本和API，而是在圖15中選擇專注於單一一致的堆疊，因為這代表了迄今為止我們基於早期軟體棧所能做出的關於"正確"方法的最佳判斷。

3.1.1 交換機實現 vs 主機實現(Switch vs Host Implementation)

圖15顯示了從單一交換機視角出發的軟體棧檢視，但是從網路視角分析也很重要。圖16通過關注連線虛擬機器(VM)的網路端到端路徑給出了這樣一個視角。

這一檢視突出了系統的兩個重要方面。首先強調了網路作業系統(如ONOS)是網路範圍內的，而交換機作業系統(如Stratum)在每個交換機內。

其次，SDN軟體棧的一部分執行在終端主機上。尤其是需要在伺服器管理程式中執行虛擬交換機(vSwitch, Virtual Switch) 軟體，負責將資料包轉發到VM以及轉發從VM返回的包。(當然，並不是每個終端主機都執行VM，但類似架構同樣適用於容器主機或裸金屬伺服器。)就像物理交換機一樣，vSwitch將資料包從輸入埠轉發到輸出埠，但這些是連線到VM(或容器)的虛擬埠，而不是連線到物理機器的物理埠。

幸運的是，可以把vSwitch看作物理交換機，包括其支援的API。注意一個實現細節，即vSwitch是在通用處理器上而不是在專用積體電路(ASIC)上通過軟體實現的。因此作為軟體交換機，大大降低了引入額外功能的障礙，從而能夠提供豐富、動態的功能集。例如，OVS(Open vSwitch) 是一款應用廣泛的開源vSwitch，支援OpenFlow作為北向API，構成了原有Nicira網路虛擬化平臺的資料平面。OVS可以與一系列補充工具整合，比如另一個開源元件DPDK(資料平面開發工具包, Data Plane Development Kit)，從而優化x86處理器上的資料包轉發操作。雖然這是一個重要的主題，但本書不會探討vSwitch(如OVS或其他終端主機優化)的所有可能性，而是像對待端到端路徑上的任何其他交換機一樣對待vSwitch。

圖16顯示的另一個實現細節是，主機可能用智慧網絡卡(SmartNIC, Smart Network Interface Card) 來輔助(甚至取代)vSwitch。廠商將核心功能解除安裝到網絡卡上已經有很長的歷史了(例如，從計算TCP/IP checksum到支援VM)，但在SDN環境中，一種可能的有趣應用是複製網路交換機上的轉發流水線。這同樣有一系列可能的實現選擇，包括FPGA和ASIC，以及網絡卡是固定功能還是可程式設計(使用P4)。就我們的目的而言，將把這種智慧網絡卡當作端到端路徑上的另一個交換元件。

主機中心視角

本書採用面向網路的SDN視角，將終端主機(執行在主機作業系統中的虛擬交換機和連線主機到網路的網絡卡)視為網路的擴充套件，在網路作業系統的控制下執行。不過以主機為中心的觀點同樣有效，更重要的是，其附帶了一個健壯的開源軟體生態系統，作為主機作業系統的一部分執行。

DPDK是其中一個例子，但另一個受到關注的是eBPF(擴充套件伯克利包過濾器, extended Berkeley Packet Filter)和XDP(快速資料路徑, eXpress Data Path)的組合，它們提供了一種方法來在OS核心(甚至可能在SmartNIC上)中程式設計通用的Match-Action規則。這在精神上與OpenFlow和P4相似，只是它們允許Action部分是任意程式。相比之下，OpenFlow定義了一組固定的動作，而P4是表達動作的特定語言(例如，不包括迴圈)。當Action必須在固定週期內執行時，這是必要的，例如基於交換機的轉發流水線。它還使資料平面的形式化驗證(formal verification)成為可能，這是第10章討論的一個很有前途的機會。

3.2 裸金屬交換機(Bare-Metal Switch)

我們從圖15和圖16所示軟體棧從下往上介紹，底層的網路資料平面是由一組互連的裸金屬交換機實現。我們現在重點關注單個交換機，整個網路拓撲是由執行在軟體棧頂層的控制程式決定，後面我們會介紹一個管理葉脊拓撲的控制應用程式。

該架構與交換機供應商無關，本章介紹的完整軟體棧執行在基於Tofino和Tomahawk交換晶片構建的交換機上，分別由Barefoot Networks(現在是英特爾)和博通製造。Tofino晶片實現了基於PISA的可程式設計轉發流水線，而Tomahawk晶片實現了固定功能流水線。

兩種晶片都通過兩個P4程式定義轉發流水線，第一個(forward.p4)指定轉發行為，第二個(arch.p4)指定目標轉發晶片的邏輯架構。P4編譯器生成載入到網路作業系統和交換機中的目標檔案，圖15中我們沒有指出這些目標檔案(後面將在第4章和第5章中介紹詳細資訊)，但是兩個元件都需要感知輸出邏輯，因為一個實現轉發行為(交換機)，而另一個控制轉發行為(網路作業系統)。

我們將在第4章介紹編譯器工具鏈的細節。現在，我們將只回答為什麼在有固定功能交換晶片的情況下，還需要一個P4程式(我們沒有使用P4來修改其固定行為)。簡單總結一下，因為我們需要正式的轉發流水線規範來生成資料平面API。P4程式提供了轉發流水線的抽象模型，無論晶片的實際硬體流水線是固定的還是可程式設計的，我們仍然需要知道如何將抽象流水線對映到物理流水線上，這就是arch.p4起作用的地方。對於可程式設計晶片，forward.p4實際上定義了流水線，而對於固定功能晶片，僅僅只是通過forward.p4描述流水線。我們仍然需要forward.p4，因為在兩種情況下工具鏈都需要使用它以及arch.p4生成位於控制平面和資料平面之間的API。

3.3 交換機作業系統(Switch OS)

從基本硬體往上看，每個交換機執行一個本地交換機作業系統。不要與管理交換機網路的網路作業系統混淆，這個交換機作業系統執行在交換機內部的商品處理器上(圖15中沒有顯示)。它負責處理髮送給交換機的API呼叫，例如來自網路作業系統的呼叫，以及對交換機內部資源採取適當的操作，有時會影響交換機晶片。

有多種開源交換機作業系統(包括最初由Microsoft Azure開發的SONiC)，但我們使用Stratum和Open Network Linux(ONL) 的組合作為主要示例。ONL是Linux的交換機發行版(最初由Big Switch Networks提供)，而Stratum(最初由谷歌開發)主要負責外部API和內部交換機資源之間的轉換。因此，我們有時把Stratum稱為瘦交換機作業系統(Thin Switch OS) 。

Stratum在交換機與外部世界的所有互動中起到中介作用，包括載入P4編譯器生成的目標檔案，該檔案定義了資料平面和控制平面之間的契約。契約有效的用自動生成的規範替換了OpenFlow的流規則抽象。其他Stratum管理API定義如下:

• P4Runtime: 控制轉發行為的執行時介面，是填充轉發表和操作轉發表狀態的關鍵。P4Runtime獨立於任何特定P4程式，並且與底層硬體無關。這與OpenFlow形成了鮮明對比，OpenFlow對轉發模型以及如何與控制平面互動有著相當明確的規定。(為了完整起見，圖15還列出了OpenFlow作為另一個控制介面。)
• gNMI(gRPC Network Management Interface): 用於設定和檢索配置狀態。gNMI通常與OpenConfig YANG模型配對，後者定義配置和狀態樹的結構。
• gNOI(gRPC Network OperationsInterfaces): 用於設定和檢索執行狀態，如證書管理、裝置測試、軟體升級、組網故障處理等。

如果你還記得在第一章中介紹的控制和配置之間的區別，那麼你會認出P4Runtime就是控制API，而gNMI/gNOI組合在一起就是交換機傳統配置API的現代版本。後一種API在歷史上被稱為OAM介面(即"Operations, Administration, and Maintenance")，通常被實現為命令列介面(當然，這不是真正的API)。

3.4 網路作業系統(Network OS)

網路作業系統是配置和控制交換機網路的平臺，作為邏輯上集中的SDN控制器在交換機之外執行，並在全網範圍內管理一組交換機。這個角色的核心是負責監控交換機狀態(例如，檢測埠和鏈路故障)，維護反映網路當前狀態和拓撲的全域性檢視，併為任何感興趣的控制程式提供該檢視。這些控制程式反過來"指示"網路作業系統根據它們提供的服務來控制底層交換機的資料包流，這些"控制指令"的表達方式是網路作業系統API的關鍵方面。

我們基於ONOS(開放網路作業系統, Open Network Operating System) 這一特定網路作業系統作為範例來完整描述這一概念，ONOS在效能、可伸縮性和可用性方面是最好的。簡單來說，ONOS負責三件事情:

• 管理拓撲(Managing Topology): 跟蹤網路基礎設施及其互聯裝置，為平臺和其他應用程式提供網路環境的共享檢視。
• 管理配置(Managing Configuration): 幫助在多個網路裝置上執行、跟蹤、回滾和驗證原子配置操作。這可以有效反映每個交換機的配置和操作介面(也使用gNMI和gNOI)，但是在網路級別而不是裝置級別上實現的。
• 控制交換(Controlling Switches): 控制網路交換機的資料平面資料包處理流水線，並對流水線內的流規則、組、監控等構建塊進行後續控制。

關於最後一個角色，ONOS匯出了一個北向FlowObjectives抽象，以一種獨立於流水線的方式泛化流規則介面(在第6章中有更詳細的描述)，但不像獨立交換機匯出的控制介面那樣標準化。與傳統伺服器作業系統一樣，基於ONOS API上的應用程式不容易移植到另一個網路作業系統上。對這個介面的需求是開放的以及定義良好的，當前並不是只有一個這樣的介面。如果隨著時間的推移，如果業界對網路作業系統介面達成了共識，那麼應用程式將更容易被移植。但就像伺服器作業系統一樣，在軟體棧中層級越高的作業系統，就越難以達成這樣的共識。

最後，儘管圖15沒有顯示關於ONOS內部的任何細節，但為了更好的理解其在更高層面上所扮演的角色，我們注意到在任何網路作業系統中最關鍵的子系統是可伸縮鍵/值儲存(Scalable Key/Value Store)。由於ONOS提供了一個邏輯上集中的網路檢視，其效能、可伸縮性和可用性的關鍵在於如何儲存這些狀態。在ONOS中，這個儲存是由一個名為Atomix的開源專案提供的，該專案實現了RAFT共識演算法。像Atomix這樣的儲存服務是當今幾乎所有水平可伸縮雲服務的基石，我們將在第6章中詳細介紹。

3.5 葉棘網路(Leaf-Spine Fabric)

由於我們使用ONOS作為網路作業系統，所以僅限於使用ONOS託管的SDN控制應用程式。為了說明問題，我們使用SD-Fabric作為控制應用程式，它在可程式設計交換機網路上實現了葉棘網路。意思是，SD-Fabric定義了特定的網路拓撲結構，特別是資料中心叢集常見的葉脊拓撲結構。如2.3節所述，該拓撲包括一組葉交換機，每一個都作為ToR交換機(即連線單個機架中的所有伺服器)，然後葉交換機再由一組脊交換機互連。

從架構上來說，SD-Fabric扮演了三個角色。首先，提供了一個交換結構，在多機架叢集中將伺服器和執行在這些伺服器上的虛擬機器相互連線。其次，使用BGP將叢集作為整體連線到對等網路，包括Internet(也就是說，其行為很像路由器)。最後，將叢集作為整體連線到下游接入網(即PON、RAN等接入網)。換句話說，與其將SD-Fabric看作傳統的在資料中心內部構建的葉脊網路，不如將其看作是執行在網路邊緣的互連繫統，幫助連線訪問特定邊緣雲和基於IP的資料中心雲。

在實現方面，SD-Fabric實際上對應一套執行在ONOS上的控制程式，而不是單一應用程式。該套件支援多種控制平面特性，包括:

• VLAN和L2橋接
• IPv4和IPv6單播/組播路由
• DHCP L3中繼
• 伺服器和上行路由器的雙歸屬冗餘
• QinQ轉發/終止
• 基於MPLS的偽連線

對於每個特性，都有相應的控制程式與ONOS互動，通過觀察網路拓撲的變化併發出Flow Objective而實現，而不是基於任何傳統路由器/交換機的標準協議實現。只有當SD-Fabric需要與外部通訊(例如，上游城市/核心路由器)時，才會涉及到傳統協議，這時需要使用標準BGP(由開源Quagga伺服器實現)。這實際上是SDN環境的共同特徵: 內部或在新領域避免傳統路由協議，但與外部世界的互動仍然需要。

最後，SD-Fabric有時部署在一個站點，多個RAN基站通過SD-Fabric葉交換機連線。但是，SD-Fabric還可以使用多層棘網路擴充套件到多個站點，如圖17所示。第7章會更詳細介紹這部分內容。

你好，我是俞凡，在Motorola做過研發，現在在Mavenir做技術工作，對通訊、網路、後端架構、雲原生、DevOps、CICD、區塊鏈、AI等技術始終保持著濃厚的興趣，平時喜歡閱讀、思考，相信持續學習、終身成長，歡迎一起交流學習。 \ 微信公眾號：DeepNoMind