OpenStack Neutron ML2

02-02

Neutron 系列文章 Neutron Topic Tree：

本文所有的內容都基於OpenStack Pike版本。

其實在2016年，我曾經在IBM Developerworks上寫過一篇文章介紹Neutron ML2。現在，在經歷了OVN和Dragonflow的ML2重構之後，現在再來回顧一下ML2。

首先，什麼是ML2？ML2（Modular Layer 2）是Neutron Server中管理L2相關功能的模塊。

Neutron Server

既然是Neutron Server中的模塊，那就先看看ML2在Neutron Server架構中的位置。

OpenStack Neutron是OpenStack中的網路項目。Neutron由多個進程構成，這些進程分布在一個或者多個（通常是多個）主機上，協同工作，為OpenStack提供網路服務。所有這些進程的核心是Neutron Server，所有的API，DB，RPC請求，都是在這裡匯總處理，主要的業務邏輯也是在Neutron Server中完成。可想而知，Neutron Server是所有Neutron進程中最複雜的。Neutron Server的架構粗略看來，如下所示：

實際的架構要更加複雜，不過為了說明ML2，這個架構就夠了。

Neutron Server北向提供REST API，Neutron的REST API/Resource都是在extension中定義，api router只是簡單的將REST API定位到extension。extension與實際的plugin關聯。

具體的REST API的處理都是在plugin中進行。Neutron Server的業務代碼是由一個個plugin構成，這裡分為core plugin和service plugin。Core plugin是實現了L2功能的plugin，service plugin是其他所有的plugin的統稱，包括實現了Router的L3Plugin，實現了Trunk的Trunkplugin，實現了Segment的SegmentPlugin等等。可以看出，一個plugin就是一個小的網路功能。業務邏輯運算，DB和RPC的調用都是在plugin內部完成。

Neutron Server與其他Neutron進程（Neutron agents）的交互，通過Message Queue或者說是RPC（RabbitMQ）調用完成。Neutron中的service plugin都定義在這個目錄：

neutron/neutron/servicesn

既然plugin分為core plugin和service plugins，那麼這裡的core plugin和service plugin還有什麼區別？

service plugin是可有可無的，大部分service plugin如果不配置，是不會運行在Neutron Server的進程中。而core plugin是必須存在的，如果不配置則無法啟動Neutron Server。並且，不論從OSI 7層網路來看，還是TCP/IP協議族來看，二層網路是其他網路功能的基礎，如果沒有二層網路，其他所有網路都無法實現。所以從這個角度來看，實現L2功能的core plugin，是Neutron Server必須包含的plugin。本文介紹的ML2是Neutron core plugin的主流實現（沒有之一）。

Core plugin發展歷史

從誕生之初，OpenStack就支持多種SDN後端。比如Neutron自己，就有OpenVSwitch和LinuxBridge的實現。其他的如OVN，Dragonflow，ODL，OpenContrail，NSX等等，都是Neutron支持的SDN後端。不同的SDN對網路功能的實現方式不一樣。在早期版本的Neutron中，存在各個SDN版本的core plugin。用戶根據當前環境對應的SDN，選擇相應的core plugin。這裡有幾個問題：

這些core plugin中，有大量的Neutron DB的操作。雖然SDN後端的實現不一樣，但是Neutron DB中的數據模型基本是一樣的。這樣就有大量重複的代碼在各個core plugin中。
一些業務邏輯的處理，例如segmentation的操作（分配VLAN ID），對於大多數SDN也是類似的，這些相似的業務代碼，在各個core plugin中也重複著。
如果一個新的SDN，需要接入Neutron，那麼需要新增一個core plugin，同樣的也需要拷貝這些代碼。
Bug fix需要在所有的core plugin中更新。

儘管有這些問題，早期的Neutron代碼中，還是同時管理著所有的這些core plugin。隨著Neutron的發展，一方面功能越來越多，相應的core plugin越來越龐大，另一方面，加入的SDN越來越多，core plugin的數量也越來越多。最多的時候有20+個core plugin存在於OpenStack Neutron的代碼中，維護相當困難。

因此在OpenStack Havana版本，Neutron社區對core plugin進行重構，將重複的DB操作和業務邏輯代碼剝離出來，成為ML2 plugin。而每個SDN獨特的代碼，作為ML2 mechanism driver，存在於新的ML2架構中。有關ML2的架構，下面會詳細說明。

接下的幾個版本，各個SDN逐漸將自己的core plugin轉換成ML2 mechanism driver。而在Kilo版本，除了OpenVSwitch和LinuxBridge，所有其他SDN的mechanism driver和未完成轉換的core plugin，都從Neutron代碼中刪除，這在Neutron Core and Vendor code decomposition有具體的介紹。被移除的SDN代碼，有的成為了Neutron下面的子項目，像networking-ovn，networking-odl等，有些由SDN提供商自己維護。在這之後，每個SDN，只需要維護自己的ML2 mechanism driver（當然，還有一些service plugin），ML2 plugin由OpenStack Neutron社區維護。

需要說明的是，並非所有的SDN的core plugin都重構到了ML2架構下，有些仍然是core plugin的形式存在，例如OpenContrail和VMware NSX。

所以，現在說的Neutron ML2 plugin，是一個通用的，新的架構。而其他的Neutron core plugin，是一些私有的，遺留的代碼。

ML2 Architecture

雖然ML2是Neutron Server的一個可插拔的（core）plugin，但是ML2本身也是由多個可插拔的組件組成。簡單的畫了一下：

網路上其他有關Neutron ML2架構介紹，一般都不包括Extension Driver，這是因為這是一個後加的組件，定義在：Support for Extensions in ML2。接下來，看看這三類Driver分別起什麼作用。

Type Drivers：對於Tenant network type，例如VLAN，VXLAN，FLAT的支持。它包括了segmentation ID的分配，MTU計算等。對於Tunnel network type，例如VXLAN，還涉及VTEP的管理。這裡ML2將VTEP需要更新的信息，通過RPC，發送到計算/網路節點，通過節點上的OpenVSwitch Agent更新VTEP信息。
Mechanism Drivers：配置SDN，完成port binding等。原來這些代碼是在各個core plugin，ML2重構之後，core plugin將自己特殊的代碼剝離出來，放在Mechanism Driver。前面說過OpenStack Neutron只管理OVS Mechanism driver和Linuxbridge Mechanism Driver，其他的Driver由SDN自己的項目管理。
Extension Drivers：Neutron L2附加功能的支持。例如與Port和Network關聯的DNS，Securitygroup和QOS。

既然有了這些可插拔的組件，Neutron ML2是如何使用它們？可以看出，這裡有三類driver，Neutron ML2通過三個manager對象來管理這些Drivers，每一類Drivers對應一個manager對象，代碼在：neutron.plugins.ml2.managers。通過這些manager，Neutron ML2完成Driver的初始化，方法調用等。

在Neutron ML2 plugin初始化的時候，會調用manager的初始化方法：

neutron/plugins/ml2/plugin.pyn def __init__(self):n # First load drivers, then initialize DB, then initialize driversn self.type_manager = managers.TypeManager()n self.extension_manager = managers.ExtensionManager()n self.mechanism_manager = managers.MechanismManager()n super(Ml2Plugin, self).__init__()n self.type_manager.initialize()n self.extension_manager.initialize()n self.mechanism_manager.initialize()n

前面說過Neutron ML2是Neutron L2相關功能的代碼。雖然OpenStack Neutron提供非常多的數據對象，但是Neutron定義的L2相關的數據對象只有網路（Network），子網（Subnet）和埠（Port）。所以，Neutron ML2 plugin都是關於網路，子網，埠的創建，更新，刪除。對應的ML2的各個組件，都是圍繞著這這些操作進行。這裡舉個比較典型的例子，就是創建網路，其對應的流程圖如下所示：

從這個流程來看，ML2的架構還是比較簡單的。在處理請求的時候只是依次的調用自身的各個模塊。其中與SDN相關的部分就是mechanism driver中的create_network_precommit和create_network_postcommit兩個方法。SDN只需要實現相應的方法，並且註冊到ML2中，就可以完成與Neutron的對接。

最後

ML2的歷史背景和大概架構介紹完了。ML2還有很多細節的地方，例如Hierarchical port binding，Overlay Network Tunnel管理，OVS和LinuxBridge的實現，L2 Population等。從架構上來看，ML2是簡單的，從功能上看，ML2又是龐大複雜的。這種設計實現思想在整個OpenStack Neutron項目都有體現。總結一下ML2的特點：

提供統一的API。不同的SDN只要實現相同的API即可接入OpenStack。
核心架構較小。主要就是三類Driver（type，extension，mechanism），對應三個manager。
可插拔的開放架構。任何功能，網路類型，都可以通過是實現上面三種Driver的一個或者多個來完成。
方便擴展。新功能的擴展不需要修改現有架構。