一、Neutron概述
Neutron是 OpenStack項目中負責提供網絡服務的組件，它基於軟件定義網絡的思想，實現了網絡虛擬化下的資源管理。Neutron 的設計目標是實現“網絡即服務（Networking as a Service）”，在設計上遵循了基於 SDN 實現網絡虛擬化的原則，在實現上充分利用了 Linux 系統上的各種網絡相關的技術。
二、Neutron功能
1. 二層交換
Neutron支持多種虛擬交換機，一般使用Linux Bridge和Open vSwitch創建傳統的VLAN網絡，以及基於隧道技術的Overlay網絡，如VxLAN和GRE（Linux Bridge 目前只支持 VxLAN）。
2. 三層路由
Neutron從Juno版開始正式加入的DVR(Distributed Virtual Router)服務，它將原本集中在網絡節點的部分服務分散到了計算節點上。可以通過namespace中使用ip route或者iptables實現路由或NAT，也可以通過openflow給OpenvSwitch下發流表來實現。
3. 負載均衡
LBaaS 支持多種負載均衡產品和方案，不同的實現以 Plugin 的形式集成到 Neutron，通過HAProxy來實現。
4. 防火牆
Neutron有兩種方式來保障instance和網絡的安全性，分別是安全組以及防火牆功能，均可以通過iptables來實現，前者是限制進出instance的網絡包，后者是進出虛擬路由器的網絡包。
三、Network
1. Local
Local網絡，本地的一個Linux Bridge，除了虛擬機的虛擬網卡不連接其他的網絡設備，實際場景很少使用，可以忽略。
2. Flat
Flat網絡，不帶vlan tag的網絡，相當於Local網絡的Linux Bridge連接到一個物理網卡，該網絡中的instance能與同網絡的instance通信，且可以跨多個節點，實際場景也很少用到。
3. VLAN
VlAN網絡，可以跨節點，目前是私有雲網絡應用較多。
4. VXALN
VXLAN網絡，是基於隧道技術的 overlay 網絡，通過唯一的VNI區分於其他 vxlan 網絡。vxlan中數據包通過VNI封裝成UPD包進行傳輸，因為二層的包通過封裝在三層傳輸，能夠克服vlan和物理網絡基礎設施的限制。
5. GRE
GRE網絡，與vxlan類似的一種overlay網絡，使用IP包進行封裝。
四、Neutron架構
Neutron采用分布式架構，由多個組件共同對外提供網絡服務，如下圖所示：
由上圖可以看到Neutron有以下組件構成：
- Neutron Server：對外提供OpenStack網絡API，接收請求，並調用Plugin處理請求。
- Plugin：處理Neutron Server發來的請求，維護OpenStack邏輯網絡的狀態，並調用Agent處理請求。
- Agent：處理Plugin的請求，負責在Network Provider上真正實現各種網絡功能。
- Network Provider：提供網絡服務的虛擬或者物理網絡設備，比如Linux Bridge，OpenVSwitch或者其他支持Neutron的物理交換機。
- Queue：Neutron Server，Plugin和Agent之間通過Messaging Queue通信和調用。
- Database：存放OpenStack的網絡狀態信息，包括Network，Subnet，Port，Router等。
舉例說明
為了了解他們之間的關系，我們舉個例子進行說明，創建一個VLAN100的Network，Network Provider是Linux Bridge：
（1）Neutron Server接收到創建Network的請求，通過Message Queue(RabbitMQ)通知已注冊的Linux Bridge Plugin。
（2）Plugin將要創建的Network的信息(例如名稱、VLAN ID等)保存到數據庫中，並通過Message Queue通知運行在各節點上的Agent。
（3） Agent收到消息后會在節點上的物理網卡(比如eth2)上創建VLAN設備(比如eth2.100)，並創建Bridge(比如brqXXX)橋接VLAN設備。
這里進行幾點說明：
（1）Plugin確定的是網絡要配置成什么樣子，而至於如何配置，則交由Agent完成。
（2）Plugin，Agent和Network Provider是配套使用的，比如上例中Network Provider是Linux Bridge，那么就得使用Linux Bridge的Plugin和Agent；如果Network Provider換成了OVS或者物理交換機，Plugin和Agent也得替換。
（3）Plugin的一個主要的職責是在數據庫中維護Neutron網絡的狀態信息，這就造成一個問題：所有Network Provider的Plugin都要編寫一套非常類似的數據庫訪問代碼。為了解決這個問題，Neutron在Havana版本實現了一個 ML2(Modular Layer 2) Plugin，對Plugin的功能進行抽象和封裝。有了ML2 Plugin，各種Network Provider無需開發自己的Plugin，只需要針對ML2開發相應的Driver就可以了，工作量和難度都大大減少。ML2會在后面詳細討論。
（4）Plugin按照功能分為兩類：Core Plugin和Service Plugin。Core Plugin維護Neutron的Netowrk, Subnet和Port相關資源的信息，與Core Plugin對應的Agent包括Linux Bridge,OVS等；Service Plugin提供Routing, Firewall, Load Balance等服務，也有相應的Agent。
五、Neutron Server
由之前得知，Neutron Server向上提供API，向下調用Plugin，如下圖
- Core API: 對外提供管理Network, Subnet和Port的RESTful API。
- Extension API: 對外提供管理Router, Load Balance, Firewall等資源的RESTful API。
- Commnon Service: 認證和校驗 API 請求。
- Neutron Core: Neutron Server的核心處理程序，通過調用相應的Plugin處理請求。
- Core Plugin API: 定義了Core Plgin的抽象功能集合，Neutron Core通過該API調用相應的Core Plugin。
- Extension Plugin API: 定義了Service Plugin的抽象功能集合，Neutron Core通過該API調用相應的Service Plugin。
- Core Plugin: 實現了Core Plugin API，在數據庫中維護network, Subnet和Port的狀態，並負責調用相應的Agent在Network Provider上執行相關操作，比如創建Network。
- Service Plugin: 實現了Extension Plugin API，在數據庫中維護Router, Load Balance, Security Group等資源的狀態，並負責調用相應的Agent在Network Provider上執行相關操作，比如創建Router。
六、Network Provider
由之前得知，Plugin，Agent和Network Provider的類型必須是配套的，常見的就是Linux Bridge和OVS的，分別如下圖所示：
我們以Linux Bridge為例進行說明，介紹一下Plugin和Agent的工作。
Linux Bridge Core Plugin
- 實現Core Plugin API。
- 負責維護數據庫信息。
- 通知Linux Bridge Agent實現具體的網絡功能。
Linux Bridge Agent
- 接收來自Plugin的請求。
- 通過配置本節點上的Linux Bridge實現Neutron網絡功能。
問題：
由上可知，需要添加Network Provider類型的時候，需要有配套的Plugin和Agent，這樣存在兩個問題：
（1）無法同時使用多種Network Provider，Core Plugin負責管理和維護Neutron的Network, Subnet和Port的狀態信息，這些信息是全局的，只需要也只能由一個Core Plugin管理。只使用一個Core Plugin本身沒有問題。但問題在於傳統的Core Plugin與Core Plugin Agent是一一對應的。也就是說，如果選擇了Linux Bridge Plugin，那么Linux Bridge Agent將是唯一選擇，就必須在OpenStack的所有節點上使用Linux Bridge作為虛擬交換機（即Network Provider）。同樣的，如果選擇OpenvSwitch Plugin，所有節點上只能使用OpenvSwitch，而不能使用其他的Network Provider。
（2）開發新的Core Plugin工作量大，所有傳統的Core Plugin都需要編寫大量重復和類似的數據庫訪問的代碼，大大增加了Plugin開發和維護的工作量。
ML2作為新一代的Core Plugin，提供了一個框架，允許在OpenStack網絡中同時使用多種Layer 2網絡技術，不同的節點可以使用不同的網絡實現機制。
如上圖所示，采用ML2 Plugin后，可以在不同節點上分別部署Linux Bridge Agent, OpenvSwitch Agent, Hyper-V Agent以及其他第三方Agent。
ML2 不但支持異構部署方案，同時能夠與現有的Agent無縫集成：以前用的Agent不需要變，只需要將Neutron Server上的傳統Core Plugin替換為ML2。有了ML2，要支持新的Network Provider就變得簡單多了：無需從頭開發Core Plugin，只需要開發相應的Mechanism Driver，大大減少了要編寫和維護的代碼。
七、ML2 Core Plugin
ML2對二層網絡進行抽象和建模，引入了Type Driver和Mechanism Driver。
這兩類Driver解耦了Neutron所支持的網絡類型(Type)與訪問這些網絡類型的機制(Mechanism)，其結果就是使得ML2具有非常好的彈性，易於擴展，能夠靈活支持多種Type和Mechanism
- Type Driver
Neutron支持的每一種網絡類型都有一個對應的ML2 Type Driver。Type Driver負責維護網絡類型的狀態，執行驗證，創建網絡等。ML2支持的網絡類型包括Local, Flat, VLAN, VxLAN和GRE。
- Mechanism Driver
Neutron支持的每一種網絡機制都有一個對應的ML2 Mechanism Driver。Mechanism Driver負責獲取由Type Driver維護的網絡狀態，並確保在相應的網絡設備(物理或虛擬)上正確實現這些狀態。
舉例說明
Type和Mechanisim都太抽象，現在我們舉一個具體的例子：Type Driver為Vlan，Mechanism Driver為Linux Bridge，我們要完成的操作是創建Network VLAN100，那么：
（1）VLAN Type Driver會確保將VLAN100的信息保存到Neutron數據庫中，包括Network的名稱，VLAN ID等。
（2）Linux Bridge Mechanism Driver會確保各節點上的Linux Brige Agent在物理網卡上創建ID為100的VLAN設備和Brige設備，並將兩者進行橋接。
- Mechanism Driver有三種類型：
（1）Agent-based: 包括Linux Bridge，OpenvSwitch等。
（2）Controller-based: 包括OpenDaylight，VMWare NSX等。
（3）基於物理交換機: 包括Cisco Nexus，Arista，Mellanox等。
八、Service Plugin/Agent
Core Plugin/Agent負責管理核心實體：Net, Subnet和Port。而對於更高級的網絡服務，則由Service Plugin/Agent管理。
Service Plugin及其Agent提供更豐富的擴展功能，包括路由，Load Balancer，Firewall等，如圖所示：
- DHCP: DHCP Agent通過dnsmasq為Instance提供DHCP服務。
- Routing: L3 Agent可以為Project(租戶)創建Router，提供Neutron Subnet之間的路由服務。路由功能默認通過IPtables實現。
- Firewall: L3 Agent可以在Router上配置防火牆策略，提供網絡安全防護。
- Load Balancer: Neutron默認通過HAProxy為Project中的多個Instance提供Load Balancer服務。
九、總結
前面我們詳細討論了Neutron架構，包括Neutron Server，Core/Service Agent。現在用兩張圖做個總
- Neutron通過Plugin和Agent提供的網絡服務。
- Plugin位於Neutron Server，包括Core Plugin和Service Plugin。
- Agent位於各個節點，負責實現網絡服務。
- Core Plugin提供L2功能，ML2是推薦的plugin。
- 使用最廣泛的L2 Agent是Linux Bridage和OpenvSwitch。
- Service Plugin和Agent提供擴展功能，包括DHCP, Routing, Load Balancer, Firewall, VPN等。
如果我們有了controller之后，比如OVN，那么vm可以直接連接ovs的br-int，bridge就可以去掉了，封裝和解封裝也會直接放在br-int，也就是只剩下vm和ovs的br-int，而諸如Security Group、DVR等等一系列的功能都可以用openflow流表去實現，這樣就大大增加了流表的數量，減少了橋的使用。
原文鏈接：http://zhaozhanxu.com/2017/06/10/OPENSTACK/2017-06-10-neutron1/
參考資料：http://www.cnblogs.com/CloudMan6/
感謝各位大神們~