透過現象看本質——談談ML2 plugin這回事兒

透過現象看本質——談談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核心插件怎麼用?

咱們若是深究這兩個問題，不難發現，這兩個問題的精髓——一個涉及做用優點，另外一個涉及架構原理。

​ 咱們一步一步來推究這兩個問題。

一、傳統Core Plugin在使用過程當中出現的主要問題

​ 第一個問題在前面已經提出了，主要是開發成本和效率的問題，這個問題其實從本質上來講就是稍加複雜罷了，倒不至因而最爲核心的問題，最麻煩的是不易維護。而最爲核心的是這第二個問題：對於不一樣的Neutron Provider來講，傳統的核心插件是不支持它們共存使用的。

​ 怎麼來理解這第二個問題呢？

​ 經過以前的瞭解，咱們知道傳統的核心插件與其代理是一一對應的，這就意味着假設選擇是Linux Bridge Plugin，那麼就必須使用Linux Bridge Agent,而且在OpenStack的全部節點上都必須使用Linux Bridge做爲虛擬交換機做爲網絡提供者，OVS一樣如此。

​ 咱們要知道，在生產環境中，服務器的數量和對應的角色，甚至是所處的位置均可能不同。若是每個節點服務器上的都必須統一爲同一個網絡提供者，這勢必會致使一系列的問題，最容易想到的就是技術更新帶來的工程量的問題。

二、ML2 Core Plugin 是怎麼解決傳統Core Plugin的問題的？

​ ML2 Core Plugin提供了一個容許在OpenStack網絡中同時使用多種Layer 2 網絡技術的框架，這樣可使不一樣的節點可使用不一樣的網絡實現機制。以下圖所示：

​ 經過上圖所示，在採用ML2核心插件以後，能夠在不一樣的節點服務器上分別部署不一樣的Agent。而且，ML2不只支持這樣的部署方式，並且能夠實現與Agent的無縫集成，也就是說，以前所使用的agent不須要更改，只須要將原來的Neutron Server上的傳統的核心插件換爲ML2插件便可。

​ 這說明了兩個方面：

• 其餘節點上的Agent能夠是不同的，而且無需更改；
• 只須要針對ML2實現機制的原理進行研究和開發對應的功能便可（下面瞭解ML2的架構時再細說）；

三、瞅一瞅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維護的網絡狀態，並確保在相應的網絡設備（物理或虛擬）上正確實現這些狀態。

四、理一理ML2驅動工做的過程

​ 可能，如此直白的解釋不只抽象並且無聊，仍是經過一個例子來簡述一下吧，也好方便理解一下ML2插件的工做過程。

​ 假設type driver爲Vlan，mechansim driver爲Linux Bridge，咱們須要建立一個vlan 10的網絡。這個建立的過程是這樣的：

1. vlan type driver會確保將vlan10的信息保存到Neutron數據庫中，包括network的名稱，vlan ID等；
2. 對應的linux bridge 的mechanism driver會確保各節點上的linux brige agent在物理網卡上建立ID爲10的vlan設備和bridge設備，並將二者進行橋接；

補充說明：

1. Linux Bridge Driver支持的type包括local、flat、vlan、and vxlan；
2. Open Vswitch Driver除了這4種type還支持gre；
3. L2 population driver做用是優化和限制overlay網絡中的廣播流量；
4. vxlan和gre都屬於overlay網絡；

結尾來一個小總結

​ 本文將述了有關ML2核心插件的相關內容，經過問題的引出深刻淺出理解neutron目前使用最爲普遍的ML2核心插件。ML2插件是核心插件，替換了傳統的插件，經過引入兩個驅動，解決了傳統核心插件帶來的問題。這也體現出在架構設計中所須要考慮的問題，尤爲是可擴展性方面。此外，經過本文能夠了解有關驅動的做用以及理解緊耦和解耦的思想。