Neutron 架构 - 每天5分钟玩转 OpenStack（67）
前面我們討論了 Neutron 的基本概念，今天我們開始分析 Neutron 的架構。
Neutron 架構
與 OpenStack 的其他服務的設計思路一樣，Neutron 也是采用分布式架構，由多個組件（子服務）共同對外提供網絡服務。
Neutron 由如下組件構成：
Neutron Server
對外提供 OpenStack 網絡 API，接收請求，并調用 Plugin 處理請求。
Plugin
處理 Neutron Server 發來的請求，維護 OpenStack 邏輯網絡的狀態， 并調用 Agent 處理請求。
Agent
處理 Plugin 的請求，負責在 network provider 上真正實現各種網絡功能。
network provider
提供網絡服務的虛擬或物理網絡設備，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交換機。
Queue
Neutron Server，Plugin 和 Agent 之間通過 Messaging Queue 通信和調用。
Database
存放 OpenStack 的網絡狀態信息，包括 Network, Subnet, Port, Router 等。
Neutron 架構非常靈活，層次較多，其目的是：
為了支持各種現有或者將來會出現的優秀網絡技術。
支持分布式部署，獲得足夠的擴展性。
通常魚和熊掌不能兼得，雖然獲得了這些優勢，但這樣使得 Neutron 更加復雜，更不容易理解。 后面我們會詳細討論 Neutron 的各個組件，但在這之前，非常有必要先通過一個例子了解這些組件各自的職責以及是如何協同工作。
以創建一個 VLAN100 的 network 為例，假設 network provider 是 linux bridge， 流程如下：
Neutron Server 接收到創建 network 的請求，通過 Message Queue（RabbitMQ）通知已注冊的 Linux Bridge Plugin。
Plugin 將要創建的 network 的信息（例如名稱、VLAN ID等）保存到數據庫中，并通過 Message Queue 通知運行在各節點上的 Agent。
Agent 收到消息后會在節點上的物理網卡（比如 eth2）上創建 VLAN 設備（比如 eth2.100），并創建 bridge （比如 brqXXX） 橋接 VLAN 設備。
關于 linux bridge 如何實現 VLAN 大家可以參考本教程“預備知識->網絡虛擬化”的相關章節。
這里進行幾點說明：
plugin 解決的是 What 的問題，即網絡要配置成什么樣子？而至于如何配置 How 的工作則交由 agent 完成。
plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 換成了 OVS 或者物理交換機，plugin 和 agent 也得替換。
plugin 的一個主要的職責是在數據庫中維護 Neutron 網絡的狀態信息，這就造成一個問題：所有 network provider 的 plugin 都要編寫一套非常類似的數據庫訪問代碼。為了解決這個問題，Neutron 在 Havana 版本實現了一個 ML2（Modular Layer 2）plugin，對 plgin 的功能進行抽象和封裝。有了 ML2 plugin，各種 network provider 無需開發自己的 plugin，只需要針對 ML2 開發相應的 driver 就可以了，工作量和難度都大大減少。ML2 會在后面詳細討論。
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的邏輯架構，下一節我們討論 Neutron 的物理部署方案。
總結
以上是生活随笔為你收集整理的Neutron 架构 - 每天5分钟玩转 OpenStack（67）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： TCP三次握手、糊涂窗口、粘包问题
- 下一篇： 网络安全(1)-身份认证