透過現象看本質——談談ML2 plugin這回事兒
本文關鍵詞：OpenStack、Neutron Plugin、Neutron Agent、Core Plugin、ML2插件、ML2架構、Driver、緊耦、解耦。
前言
在OpenStack中，其控制管理着計算、存儲、網絡三大資源。要想明白OpenStack是如果對計算、存儲和網絡資源進行管理的，就需要清楚OpenStack的架構，模塊組成和各自分工的任務等等。
而網絡是作爲OpenStack中最爲核心之一的、也是相對於其他最爲複雜的一塊，因此需要細品~
今天就來透過現象看本質，談一談ML2插件這回事兒~
Neutron Plugin是個什麼鬼？
Plugin——插件，根據百度搜索的結果，其介紹爲：一種遵循一定規範的應用程序接口編寫出來的程序。那麼什麼是Neutron插件呢？不用想太多，其實就是有關網絡的插件，可以使Neutron提供完整的服務。
我們知道，在OpenStack中，總的來說插件的作用可以理解爲：
-
處理Neutron Server發來的請求；
-
維護OpenStack中網絡的狀態；
- 調用agent處理請求；
由此也可以明白，在OpenStack Neutron項目中，插件和代理服務是相對應的，而且plugin解決的是在數據庫中存放網絡信息，需要解決的是網絡請求時需要什麼配置的問題，而agent解決的是如何具體配置網絡的問題，而agent處理時需要通過Neutron provider（網絡提供者）提供虛擬或物理網絡（Linux Bridge或OVS或其他的物理交換機），也可以說這三者需要配套使用。
細的來說，Neutron Plugin 有兩種，一種是Core Plugin——核心插件,主要是在數據庫中維護network、subnet和port的狀態，並負責調用相應的agent在network provider上執行相關操作，比如創建network；另一種是Service Plugin——服務插件，主要是在數據庫中維護router、load balance、security group等資源的狀態，並負責調用相應的agent在network provider上執行相關操作，比如創建router。
那麼，plugin的其中一個職責就是維護Neutron網絡的狀態信息的，那麼這就產生了一個問題：
對於不同的Neutron Provider的plugin，就需要對每種plugin寫一個十分類似的代碼用來訪問數據庫，這樣代碼又多又冗雜。於是就有了ML2插件，來解決這個問題，當然，也不僅僅是因爲這個原因。下面就來聊聊ML2插件吧。
ML2 Core Plugin又是個什麼鬼？
ML2——Moduler Layer 2，是Neutron在H版本實現的一個新的核心插件，用來替代原來的linux bridge plugin 和open vswitch plugin。說白了，就是新的技術來了，用ML2這個核心插件換了原來的插件，一統江山了。
這就又會有兩個問題：
- 爲什麼要更換核心插件？
- ML2核心插件怎麼用?
我們如果深究這兩個問題，不難發現，這兩個問題的精髓——一個涉及作用優勢，另一個涉及架構原理。
我們一步一步來推究這兩個問題。
1、傳統Core Plugin在使用過程中出現的主要問題
第一個問題在前面已經提出了，主要是開發成本和效率的問題，這個問題其實從本質上來說就是稍加複雜罷了，倒不至於是最爲核心的問題，最麻煩的是不易維護。而最爲核心的是這第二個問題：對於不同的Neutron Provider來說，傳統的核心插件是不支持它們共存使用的。
怎麼來理解這第二個問題呢？
通過之前的瞭解，我們知道傳統的核心插件與其代理是一一對應的，這就意味着假設選擇是Linux Bridge Plugin，那麼就必須使用Linux Bridge Agent,並且在OpenStack的所有節點上都必須使用Linux Bridge作爲虛擬交換機作爲網絡提供者，OVS同樣如此。
我們要知道，在生產環境中，服務器的數量和對應的角色，甚至是所處的位置都可能不一樣。如果每一個節點服務器上的都必須統一爲同一個網絡提供者，這勢必會導致一系列的問題，最容易想到的就是技術更新帶來的工程量的問題。
2、ML2 Core Plugin 是怎麼解決傳統Core Plugin的問題的？
ML2 Core Plugin提供了一個允許在OpenStack網絡中同時使用多種Layer 2 網絡技術的框架，這樣可以使不同的節點可以使用不同的網絡實現機制。如下圖所示：
通過上圖所示，在採用ML2核心插件之後，可以在不同的節點服務器上分別部署不同的Agent。並且，ML2不僅支持這樣的部署方式，而且可以實現與Agent的無縫集成，也就是說，之前所使用的agent不需要更改，只需要將原來的Neutron Server上的傳統的核心插件換爲ML2插件即可。
這說明了兩個方面：
- 其他節點上的Agent可以是不一樣的，並且無需更改；
- 只需要針對ML2實現機制的原理進行研究和開發對應的功能即可（下面瞭解ML2的架構時再細說）；
3、瞅一瞅ML2的架構
如果需要了解ML2或者深入理解ML2的工作原理，就先要引入驅動的概念。在計算機中，驅動指的是驅動計算機裏軟件的程序。而在ML2中，驅動其實就是爲了使ML2具備更好的彈性，易於擴展，方便而靈活地支持和訪問多種網絡類型及其機制的程序。
ML2對二層網絡進行的抽象和建模，引入了type driver和mechansim driver，分別對應類型驅動和機制驅動。在講述這兩個驅動之前，先來瞅一眼ML2插件的架構圖：
通過這幅圖，可以體現出在架構設計乃至程序設計時的解耦思想，這裏補充說明一下什麼是緊耦和解耦：
這兩者的思想恰好相反，緊耦表示二者或二者以上之間的關聯、聯繫非常緊密，誰離開誰，單方面都無法正常工作或提供服務；解耦的意思就是多方之間雖然互相之間有一定聯繫，但是並非缺少誰就不能工作，例如現在非常火的容器開發，就是基於這樣的思想。這樣的思想在軟件開發層面比較多，在運維方面則體現在架構的設計層面。
有了直觀的架構格局，再來說明一下這兩類驅動：
（1）Type Driver
type driver——類型驅動，顯然從上圖就可以明白，Neutron支持的每一種網絡類型都有與之對應的ML2的類型驅動。
類型驅動主要負責維護網絡類型的狀態，執行驗證創建網絡等。這些網絡類型可以參考上一篇文章。
（2）Mechansim Driver
Mechansim Driver——機制驅動，Neutron支持的每一種網絡機制都有一個對應的ML2 機制驅動。（有的可能沒聽說過，本文暫且忽略）
機制驅動主要負責獲取由Type Driver維護的網絡狀態，並確保在相應的網絡設備（物理或虛擬）上正確實現這些狀態。
4、理一理ML2驅動工作的過程
可能，如此直白的解釋不僅抽象而且無聊，還是通過一個例子來簡述一下吧，也好方便理解一下ML2插件的工作過程。
假設type driver爲Vlan，mechansim driver爲Linux Bridge，我們需要創建一個vlan 10的網絡。這個創建的過程是這樣的：
- vlan type driver會確保將vlan10的信息保存到Neutron數據庫中，包括network的名稱，vlan ID等；
- 對應的linux bridge 的mechanism driver會確保各節點上的linux brige agent在物理網卡上創建ID爲10的vlan設備和bridge設備，並將兩者進行橋接；
補充說明：
- Linux Bridge Driver支持的type包括local、flat、vlan、and vxlan；
- Open Vswitch Driver除了這4種type還支持gre；
- L2 population driver作用是優化和限制overlay網絡中的廣播流量；
- vxlan和gre都屬於overlay網絡；
結尾來一個小總結
本文將述了有關ML2核心插件的相關內容，通過問題的引出深入淺出理解neutron目前使用最爲廣泛的ML2核心插件。ML2插件是核心插件，替換了傳統的插件，通過引入兩個驅動，解決了傳統核心插件帶來的問題。這也體現出在架構設計中所需要考慮的問題，尤其是可擴展性方面。此外，通過本文可以瞭解有關驅動的作用以及理解緊耦和解耦的思想。