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 架構很是靈活，層次較多，其目的是：

1. 爲了支持各類現有或者未來會出現的優秀網絡技術。

2. 支持分佈式部署，得到足夠的擴展性。

一般魚和熊掌不能兼得，雖然得到了這些優點，但這樣使得 Neutron 更加複雜，更不容易理解。 後面咱們會詳細討論 Neutron 的各個組件，但在這以前，很是有必要先經過一個例子瞭解這些組件各自的職責以及是如何協同工做。

以建立一個 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 設備。

關於 linux bridge 如何實現 VLAN 你們能夠參考本教程「預備知識->網絡虛擬化」的相關章節。

這裏進行幾點說明：

1. plugin 解決的是 What 的問題，即網絡要配置成什麼樣子？而至於如何配置 How 的工做則交由 agent 完成。

2. plugin，agent 和 network provider 是配套使用的，好比上例中 network provider 是 linux bridge，那麼就得使用 linux bridge 的 plungin 和 agent；若是 network provider 換成了 OVS 或者物理交換機，plugin 和 agent 也得替換。

3. plugin 的一個主要的職責是在數據庫中維護 Neutron 網絡的狀態信息，這就形成一個問題：全部 network provider 的 plugin 都要編寫一套很是相似的數據庫訪問代碼。爲了解決這個問題，Neutron 在 Havana 版本實現了一個 ML2（Modular Layer 2）plugin，對 plgin 的功能進行抽象和封裝。有了 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的邏輯架構，下一節咱們討論 Neutron 的物理部署方案。