OpenStack入門之核心組件梳理（5）——Neutron篇

時間 2020-03-18

標籤 openstack 入門核心組件梳理 neutron 简体版

原文原文鏈接

OpenStack入門之核心組件梳理（5）——Neutron篇

前言

本文將講解OpenStack核心組件之一的Neutron組件。但願閱讀本文前，建議初學者提早認知雲計算、Linux操做系統、服務器羣集以及OpenStack概念以及架構圖。本文主要是爲了自行整理有關OpenStack的相關知識理論，也是同讀者分享本身對OpenStack中Neutron下面的淺解。linux

友情連接：下面的三篇文章對於初學者或多或少能夠幫你在宏觀上了解雲計算以及OpenStack。數據庫

雲計算淺談安全

OpenStack概念以及核心組件概述服務器

OpenStack部署節點類型和架構網絡

1、Neutron的基本概念

1.1Neutron的前世此生

Neutron的前身是Quantum，Quantum英文爲量子，Neutron英文翻譯爲中子，雖然筆者不知道這樣來命名項目的具體緣由，但從直觀的感受上就會以爲這個玩意不簡單哈！架構

其實最初OpenStack並無將網絡組件獨立出來，爲之成立單獨的一個核心項目，最初是一個叫作Nova-network的網絡模型，這種模型很是簡單，就是一種單一的平面網絡，以下圖所示：負載均衡

但若熟悉網絡知識就會發這種模式存在很大的缺點，好比：框架

單一網絡有瓶頸，沒有體現出雲的特性（如可伸縮）；
難以實現租戶的隔離性；

因此技術須要不斷更新發展，相關的技術大佬通過思索，嘗試，最後制定出一種方案——將網絡服務獨立出來，隨後不斷優化成立了Neutron項目。而Neutron的網絡模型也發生了很大改變，後面會深刻介紹。這裏主要是體會一下技術發展的魅力，瞭解一下Neutron的前身與發展。分佈式

1.2 Neutron的基本概念

Neutron是OpenStack核心的項目之一，主要是提供雲計算環境下的網絡服務。在OpenStack中，Neutron自己採用的也是分佈式架構，即由多個服務或者說功能模塊來共同對外提供網絡服務。Neutron的設計初衷是實現"網絡即服務"，即NaaS。在設計上遵循的是基於SDN（軟件定義網絡）實現網絡虛擬化的原則，而在其實現上採用的是linux系統的相關網絡技術。ide

1.3 Neutron的主要做用

在OpenStack中，Neutron網絡服務具體的做用是容許用戶建立和管理網絡對象，這裏的對象指的就是網絡、子網、端口等，而且這些對象能夠被其餘的OpenStack服務使用。

而且，Neutron爲整個OpenStack環境提供網絡的支持，涵蓋了二層交換、三層路由轉發、負載均衡、防火牆和***等網絡通訊技術。

此外，Neutron項目中很是值得一提的就是插件，插件的存在乎味着OpenStack架構的可擴展性很是強，而且能夠適應不一樣的網絡設備，穩定工做。其中ML2算是典型表明，以後的文章也會進行介紹。

2、Neutron的基本架構

在上述給出連接的第三篇文章中，介紹了由OpenStack官網給出的關於OpenStack概念架構圖以及邏輯架構圖。若是細心認真看這個架構圖的話，你會發現邏輯架構圖中都有OpenStack中Neutron組件。筆者將之截取出來，以下圖所示：

那麼如何梳理理解上述的邏輯架構圖？

其實，這和咱們生活中同樣，熟悉一個事物，或者一我的，你得先初步認識，而後有所瞭解，最終理解熟悉，這在咱們學習中也是同樣的道理。因此，先來認知理解框架中的功能模塊的概念和做用。

2.1Neutron架構模塊介紹

2.1.1 neutron-server

該模塊是一個進程，並且是Neutron惟一主要的服務進程，通常運行於控制節點，提供相應的API（這類API通常基於REST風格原則）做爲訪問Neutron的入口。

2.1.2 neutron plugin

neutron 插件，由core plugins（核心插件）和service plugins（服務插件）組成。擔任相似接收請求派發任務的角色。

core plugins：提供基礎的二層虛擬網絡支持，包括網絡、子網和端口核心資源；（以後技術和版本的更新使其發生了變化，後面會談到）
service plugins:指的是除了core plugins之外的其餘插件，例如提供路由器、防火牆、安全組以及負載均衡等服務的支持。

2.1.3 neutron agent

neutron代理模塊，負責接收消息而且執行任務的模塊，與上述的neutron plugin對應，扮演的是真正處理工做的角色。

2.1.4 neutron provider

neutron網絡提供者，主要做用是提供OpenStack網絡服務的虛擬機或者物理網絡的設備，例如Linux Bridge、OVS（Open vSwitch）（這二者也是重點）或者其餘能夠正常Neutron的物理交換機。

2.1.5 Queue

Queue——隊列，這裏是消息隊列——MQ，用於Neutron各個模塊之間相互的通訊，通常默認的是基於Erlang語言的RabbitMQ來實現協調通訊問題的。

2.1.6 neutron database

這裏你們都知道是數據庫，不過這是存放網絡信息的數據庫，默認使用的是Mariadb數據庫。

好了，看完上述的內容，想必對架構中的各類模塊有所瞭解了。那麼如何將這些模塊聯繫起來呢？

這就須要來說述一下該架構工做時的過程，筆者將這個過程稱做"看圖說話"。

2.2Neutron的工做流程

這裏能夠經過一個例子結合上圖來說述該架構的工做原理以及整個過程。

假設如今要建立一個虛擬網絡。整個流程是這樣的：

（1）Neutron-server 收到要建立虛擬網絡的請求，經過消息隊列通知對應的插件，（先不考慮ML2）假設網絡提供者（neutron provider）爲OVS（Open vSwitch），那麼這裏的插件對應的就是OVS的插件；

（2）OVS插件收到消息後，將須要建立的虛擬網絡的信息（名稱、ID值等）保存到Neutron database中並經過消息隊列通知運行在各個節點上的agent；

（3）agent，即代理收到消息後會在節點上建立對應設備，例如vlan設備。

3、Neutron-server分層模型講解

本小節將詳細談一下Neutron-server服務。下圖爲Neutron-server的分層結構。

3.1 Neutron-server分層結構簡述

Neutron-server的分層結構如上圖所示，自上而下分別是：

3.1.1 Core API 和 Extension API

Core API：對外提供管理網絡（network）、子網（subnet）和端口（port）的RESTful API；
Extension API：對外提供管理路由（router）、負載均衡（LB）、防火牆（firewall）等資源的RESTful API；

3.1.2 Common Service

用於認證和校驗API請求；

3.1.3 Neutron Core

Neutron-server中的核心處理程序，去調用對應的插件處理請求；

3.1.4 Core Plugin API 和 Extension Plugin API

Core Plugin API：用於給核心處理程序調用Core Plugin的接口；
Extension Plugin API：與給核心處理程序調用Extension Plugin的接口；

3.1.5 Core Plugin 和 Service Plugin

分別對應核心插件和服務插件，核心插件響應核心API，服務插件響應擴展API；

其中，核心插件主要是在數據庫中維護network、subnet和port的狀態，並負責調用相應的agent在network provider上執行相關操做，好比建立network；服務插件主要是在數據庫中維護router、load balance、security group等資源的狀態，並負責調用相應的agent在network provider上執行相關操做，好比建立router。

3.1.6 Database

數據庫，用於存放對應的數據信息。

其實歸根結底，Neutron-server說白了就能夠理解爲是API和Plugins的組合，即提供API服務和運行插件兩大任務。

3.2 Neutron-server響應的流程

其實Neutron-server響應服務請求的流程並不複雜，主要能夠分爲如下幾個步驟：

假設Neutron-server收到客戶端發送的建立網絡請求的案例：

一、首先，根據用戶須要建立的對象調用對應的API（核心仍是擴展API）；

二、對應的API響應以後將請求下發，此時須要經過Common Service進行認證校驗以及受權；

三、認證和受權等操做都經過以後，交付給Neutron Core核心處理程序經過調用對應的插件類型處理請求。

4、Neutron的網絡基本概念

Neutron管理的網絡資源包括network、subnet和port，下面依次介紹。

4.1 network

network是一個隔離的二層廣播域。Neutron支持多種類型的network，包括local、fla、VLAN、VxLAN和GRE以及Geneve。

local

local網絡與其餘網絡和節點隔離。local網絡中的instance只能與位於同一節點上同一網絡的instance通訊，local網絡主要用於單機測試。

特色：

不具有vlan特性，不能對二層網絡進行隔離；
同一個local網絡的虛擬機實例會鏈接到相同的虛擬交換機上，實例之間能夠通訊；
虛擬交換機沒有綁定任何物理網卡，沒法與宿主機以外的網絡通訊；

flat

flat網絡是無vlan tagging的網絡。flat網絡中的instance能與位於同一網絡的instance通訊，而且能夠跨多個節點。

vlan

vlan網絡是具備802.1q tagging的網絡。vlan是一個二層的廣播域，同一vlan中的instance能夠通訊，不一樣vlan只能經過router通訊。vlan網絡能夠跨節點，是應用最普遍的網絡類型。

vxlan

vxlan是基於隧道技術的overlay網絡。vxlan網絡經過惟一的segmentation ID（也叫VNI）與其餘vxlan網絡區分。vxlan中數據包會經過VNI封裝成UPD包進行傳輸。由於二層的包經過封裝在三層傳輸，可以克服vlan和物理網絡基礎設施的限制。

vxlan和vlan相比的優點：

租戶數量從4K增長到16M——支持數量增大；
租戶內部通訊能夠跨越任意IP網絡，支持虛擬機任意遷移——跨網絡通訊；
通常來講，每一個租戶邏輯上都有一個網關實例，IP地址能夠在租戶間進行復用——重複使用不衝突；
可以結合SDN技術對流量進行優化——支持與其餘技術結合應用

gre

gre是與vxlan相似的一種overlay網絡。主要區別在於使用IP包而非UDP進行封裝。

不一樣network之間在二層上是隔離的。

4.2 Subnet

subnet是一個IPv4或者IPv6地址段。instance的IP從subnet中分配。每一個subnet須要定義IP地址的範圍和掩碼。

4.3 Port

port能夠看做虛擬交換機上的一個端口。port上定義了MAC地址和IP地址，當instance的虛擬網卡VIF（Virtual Interface）綁定到port時，port會將MAC和IP分配給VIF。
port與subnet是1對多關係。一個port必須屬於某個subnet；一個subnet能夠有多個port。

5、Neutron的主要功能

前文第一小節中提到有關Neutron的主要做用，的確，Neutron爲整個OpenStack環境提供着網絡支持，包括二層交換、三層路由、負載均衡、防火牆等等。而且Neutron提供了對應的框架，使得用戶經過配置能夠實現這些功能。下面簡述這些功能。

5.1二層交換VSwitch

Neutron支持多種虛擬交換機，包括Linux原生的Linux Bridge和Open vSwitch。

Open vSwitch（OVS）是一個開源的虛擬交換機，它支持標準的管理接口和協議。

利用Linux Bridge和OVS，Neutron除了能夠建立傳統的VLAN網絡，還能夠建立基於隧道技術的Overlay網絡，好比VxLAN和GRE（Linux Bridge目前只支持VxLAN）。

5.2三層路由VRouter

實例能夠配置不一樣網段的IP，Neutron的VRouter（虛擬路由器）實現實例可跨網段通訊。通常能夠經過IP forwarding、iptables等技術來實現路由和NAT。

5.3負載均衡Load Balance

Openstack在Grizzly版本第一次引入了Load-Balancing-as-a-Service（LBaaS），提供了將負載分發到多個實例的能力。LBaaS支持多種負載均衡產品和方案，不一樣地實現以Plugin的形式集成到Neutron，目前默認的Plugin是HAProxy（我的理解是屬於七層負載吧）。

5.4防火牆Firewall

Neutron經過下面兩種方式來保障instance和網絡的安全性。

Security Group：經過iptables限制進出實例的網絡包。
Firewall-as-a-Service：FWaaS，限制進出虛擬路由器的網絡包，也是經過iptables實現。

6、小結

本文主要介紹OpenStack中核心子項目之一的Neutron，Neutron項目原理內容涉及很是廣，本文先針對其基礎部分進行講述，從總體上了解Neutron,對於neutron provider、neutron plugins（重點是ML2）、網絡原理、相關代理（L3）等深層原理（例如Linux中的網絡虛擬化，名稱空間等專業詞彙的理解）後面會繼續更新。

本文主要講述了其基本概念做用、核心組件介紹（着重講述Neutron-server的響應過程）、Neutron的架構講解以及Neutron提供的主要功能和網絡類型（記住前面4種！）

謝謝閱讀！