openstack——Neutron基本架構詳解

前言：

在部署完oenstack多節點時，若是發現ntpd服務

無法同步的現象，查看控制節點的iptables和防火牆是否關閉

查看管理員賬號密碼

[root@ct ~(keystone_admin)]# cat keystonerc_admin 
unset OS_SERVICE_TOKEN
    export OS_USERNAME=admin
    export OS_PASSWORD='123123'
    export OS_REGION_NAME=RegionOne
    export OS_AUTH_URL=http://192.168.254.20:5000/v3
    export PS1='[\u@\h \W(keystone_admin)]\$ '
    
export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3

一：Neutron基本架構

與openstack其他服務和組件的設計思路一樣，neutron也採用分佈式架構，由多個組件（服務）共同對外提供網絡服務。

neutron架構非常靈活，層次多

一方面是爲了支持各種現有或者將來會出現的先進網絡技術加入到架構中，有足夠的邏輯擴展性

另一方面支持分佈式部署，可以獲得足夠的物理擴展性；比如擴展計算節點，neutron只需要增加一個相應的計算組件即可

基本架構圖：

neutron僅有一個主要服務進程neutron-server，它運行於控制節點上，對外提供oopenstack網絡API作爲訪問neutron的入口，收集請求後調用插件（plugin）進行處理，最終由計算節點和網絡節點的各種代理（agent)完成請求。

network provider ，是指提供openstack的網絡服務的虛擬機或者物理網絡設備，比如linux bridge、open vswitch或者其他支持neutron的物理交換機。

queue ，與其他服務一樣，neutron的各個組件之間需要相互協調通信，neutron-server、插件、代理之間通過消息隊列（默認使用rabbit mq 實現）進行通信和相互協調

network database ，默認使用mariaDB，用於存放openstack的網絡狀態信息，包括：網絡、子網、端口、路由等

客戶端（client）是指使用neuton服務的應用程序，可以是命令行工具、horizon（openstack圖形操作界面，dashboard）或者nova計算服務

舉例說明：拿一個創建vlan 10虛擬網絡的流程

① neutron-server收到創建網絡的請求，通過消息隊列（rabbit）告知已註冊的linux bridge插件，這裏假設網絡提供者爲linux bridge

② linux bridge將要創建的網絡信息保存到數據庫，並通過消息隊列傳話筒通知運行在各個節點上的代理

③ 代理收到信息後會在節點上的物理網卡上創建vlan設備（比如物理接口的子接口，eth1.10），並創建一個網橋來橋接網絡設備

二：neutron ——neutron-server詳解

neutron-server提供一組API來定義網絡連接和IP地址，也就是提供一個IP地址，供nova等客戶端調用，讓我們去連接，去發出指令

它本身也是一個分層的模型設計

neutron-server包括四個層次

① resetflu API：直接對客戶端API服務，屬於最前端的API，包括——core API 和 extension API

core API ：提供管理網絡、子網和端口核心資源的resetful API

extension API：提供網絡管理、路由器、負載均衡、防火牆、安全組等擴展資源的resetful API

② commnon service：通用服務，負責對API的請求進行檢驗認證並授權

③ neutron core ; 核心處理程序，調用相應的API插件來處理上層API的請求

④ plugin API ： 定義插件的抽象功能集合，提供通用調用插件API的接口，包括core plugin API 和extension plugin API兩種類型

neutron core通過core plugin API調用相應的core plugin

通過 extension plugin API 調用相應的service plugin

三：neutron——neutron-plugin插件

neutron遵循openstack的設計原則，採用開放式架構，通過插件、代理與網絡提供者的配合來實現各種網絡功能

插件是neutron的一種API的後端實現，目的是增強擴展性。

插件按照功能可分爲core plugin和service 兩種類型；由core plugin API 和extension plugin API去調用

• core plugin 提供基礎二層虛擬網絡支持，實現網絡、子網和端口核心資源的支持
• service plugin 提供core plugin 之外的功能，提供路由器、防火牆、安全組、負載均衡扽該服務支持

備註：值得一提的是，直到h版本，neutron纔開始提供一個名爲 L3 router service plugin 的插件去支持路由服務

插件由neutron-server的core plugin API 和extension plugin API調用，用於確定具體的網絡功能

即，要配什麼樣的網絡，插件處理neutron-server發來的請求

它的主要職責是

①在數據庫中維護neutron網絡的狀態信息（更新neutron數據庫），

②通知相應的代理去實現具體的網絡功能

每一個插件支持一組API資源並完成特定操作，這些操作最終由插件通過RPC調用相應的代理（agent）來完成

四：neutron——neutron agent 、neutron provider代理與網絡提供者

代理處理插件傳來的請求，負責在網絡提供端口上真正實現各種網絡功能

代理使用物理設備或者虛擬化技術完成實際的操作任務

比如：用於路由具體操作的L3 agent

備註：插件、代理、網絡提供者三者是配套使用的；比如網絡提供者是linux bridge ，就需要使用linux bridge 對應的插件和代理，如果換成了open vswitch，就需要修改插件和代理，換成配套的纔可以使用

五：neutron的物理部署

neutron 與其他openstack服務組件系統工作，可以部署在多個物理主機節點上，主要涉及控制節點、網絡節點和計算節點。每個節點可以部署多個

典型的主機節點部署介紹如下：

5.1 控制節點和計算節點

• 控制節點上部署 neutron-service （API）、core plugin 和service plugin 的代理

這些代理包括

neutron-plugin-agent、

neutron-medadata-agent、

neutron-dhcp-agent、

neutron-L3-agent、

neutron-lbaas-agent等

core plugin和service plugin已經集成到neutron-server中，不需要運行一個獨立的plugin服務

• 計算節點上可以部署 core plugin、linux bridge 或open vswitch 的代理，負責提供二層的網絡功能

• 控制節點和計算節點都需要部署core plugin的代理，因爲控制節點與計算節點通過該代理才能建立二層連接

5.2 控制節點和網絡節點

可以通過增加網絡節點來承擔更大的負載冗餘，該方案特別適合規模較大的open vswitch環境

控制節點部署neutron-server服務，只負責通過neutron-server相應前端API的請求

網絡節點部署的服務包括core plugin 的代理和service plugin 的代理，將所有的代理從控制節點分離出來，部署到獨立的網絡節點上，由獨立的網絡節點實現數據的交換、路由以及負載均衡等高級網絡服務

六： neutron 主要插件、代理與服務

neutron插件、代理服務層次結構如下

6.1 插件——ML2插件

neutron可以通過開發不同的插件和代理來支持不同的網絡技術，這是一種相當靈活開放的架構

6.1.1 ML2誕生的原因

不過，隨着所支持的網絡提供者種類的增加，開發人員發現了兩個突出的問題：

• 多種網絡提供者無法共存

core plugin 負責管理和維護neutron二層的虛擬網絡的狀態信息，一個neutron網絡只能由一個插件管理

而core plugin 插件與相應的代理是一一對應的

如果linux bridge 插件，則只能選擇linux bridge代理，必須在openstack的所有節點上使用linux bridge 作爲虛擬交換機

• 開發插件的工作量太大

所有傳統的core plugin 之間存在大量重複的代碼

比如數據庫的訪問代碼

爲了解決這兩個問題，從openstack 的havana版本開始，neutron實現一個插件ML2（moduler layer2）用來取代所有的core plugin

6.1.2 ML2優點

ML2 插件允許openstack網絡中同時使用多種二層的網絡技術，不同的節點可以使用不同的網絡機制

ML2能夠與現在所有的代理無縫集成，以前使用的代理無需變更，只要將傳統的core plugin替換ML2

ML2使得對新的網絡技術支持更爲簡單，無需重新開發新的core plugin插件，只需開發相應的機制驅動（mechansion driver），大大減少要編寫的和維護的代碼

6.1.3 .架構圖如下：

6.1.4 ML2插件介紹

ML2對二層的網絡進行抽象，解鎖了neutron所支持的網絡類型（type）與訪問這些網絡類型的虛擬網絡實現機制（mechansim），並通過驅動的形式進行擴展

不同的網絡類型對應不同的類型驅動（type driver），由類型管理器（type manager）進行管理

不同的網絡實現機制對應不同的機制驅動（mechansim），由機制管理器（mechansim manager）進行管理

這種實現框架使得ML2具有彈性，易於擴展，能夠靈活支持多種網絡類型和實現機制

• 類型驅動（type driver）

neutron 支持的每一種網絡類型都有一個對應的ML2類型驅動

類型驅動負責維護網絡類型的狀態，執行驗證、創建網絡等工作

目前neutron已經實現的網絡類型包括：flat、local、vlan、vxlan、gre

• 機制驅動（mechansim drvier）

neutron 支持的每一種網絡機制都有一個對應的ML2機制驅動

機制驅動負責獲取類型驅動維護的網絡狀態，並確保在相應的網絡設備（物理或虛擬的）上正確實現這些狀態

6.1.5 舉例

類型驅動爲vlan，機制驅動爲linux bridge

如果創建vlan 10，那麼vlan的類型驅動會確保vlan 10的信息保存到neutron數據庫中，包括網絡的名稱、vlan ID等

而linux bridge 機制驅動會確保各個節點上的linux bridge 代理在物理網卡上創建ID爲10的vlan設備和bridge設備，並將二者進行橋接

他們兩個是一一對應的

6.1.6 目前neutron已經實現的網絡機制有三種類型

• 基於代理（agent-based）：包括linux bridge、open vswitch
• 基於控制器（controller-based）：包括open stacdaylight、vmwavre NSX等
• 基於物理交換：包括cisco nexus、arista、mellanox等

6.1.7 擴展資源

ML2作爲一個core plugin ，在實現網絡、子網和端口核心資源的同時，也實現了包括端口綁定（port bindings）、安全組（security group）等部分擴展資源

總之，ML2插件已經成爲neutron首選插件，至於如何配置ML2後面在做闡述

6.2 代理 ————（二層，以太網與交換機）

6.2.1 linux bridge 代理

linux bridge 是成熟可靠的neutron二層網絡虛擬化技術，支持local、flat、vlan、vxlan這四種網絡類型，目前不支持gre

linux bridge 可以將一臺主機上的多個網卡橋接起來，充當一臺交換機，他可以橋接物理網卡，又可以是虛擬網卡

用於橋接虛擬機網卡的是tap接口，這是一個虛擬出來的網絡虛擬設備，成爲tap設備

作爲網橋的一個端口，tap接口在邏輯上與物理接口具有相同的功能，可以接收和發送數據包

如果選擇linux bridge 代理，在計算機節點上數據包從虛擬機發送到物理網卡需要經過以下設備

• tap接口（tap intergface）：用於網橋虛擬機的網卡，名爲tap xxx
• linux 網橋（linux bridge）：作爲二層交換機，名爲brq xxx
• vlan 接口（vlan interface）：在vlan網絡中用於連接網橋，名爲ethx.y（ethx爲物理網卡名，y爲vlan ID）
• vxlan接口（vxlan interface）：在vxlan網絡中用於連接網橋，名爲vxlan-z（z是VNID）

計算節點上的linux bridge環境下的flat網絡和vlan網絡，下面2個示意圖中，網橋（交換機）是核心

vlan網絡中的2個vlan有自己的網橋，實現了基於vlan的功能

VLAN 網絡 缺點：支持用戶少，安全性不好，在生產環境中，是不會用linux birdge

如果改用vxlan，其中的vlan接口換成vxlan接口，可以命名爲vxlan-101和vxlan-102

​ https://www.sdnlab.com/20830.html

6.2.2 open vswitch代理

與linux bridge相比，open vswitch （可簡稱OVS）具有幾種管控功能，而且性能更加優化，支持更多的功能，目前在openstack領域被稱爲主流。

它支持local、flat、vlan、vxlan、gre、geneve等所有網絡類型

6.2.2.1 open vswitch 的設備類型

• tap設備：用於網橋連接虛擬機網口
• linux網橋：橋接網絡接口（包括虛擬接口）
• veth對（veth pair）：直接相連的一對虛擬機網絡接口，發送veth對一端的數據包由另一端接收。在openstack中，它用來鏈接兩個虛擬網橋
• vos網橋：open vswitch的核心設備，包括一個ovs集成網橋（inegration bridge）和一個ovs物理連接網橋。所有計算節點上運行的虛擬機鏈接到集成網橋，neutron通過配置集成網橋上的端口來實現虛擬機網絡隔離。物理連接網絡直接連接到物理網卡。這兩個ovs網絡通過一個veth對連接，open vswitch的每個網橋都可以看作是一個真正的交換機，可以支持vlan

6.2.2.2 open vswitch數據包流程

如果選擇open vswitch代理，在計算節點上的數據包從虛擬機發送到物理網卡上需要依次經過以下設備

• tap接口：用於網橋虛擬機的網卡，命名爲tapxx
• linux 網橋：與linux bridge 相同，命名爲qbrxxx（其中編號與tap的編號一致）
• veth對：兩端分別命名爲qvbxxx和qvoxxx
• ovs集成網橋：命名爲br-int
• ovs patch端口：兩端分別命名爲int-br-ethx和phy-br-ethx （ethx爲物理網卡名）
• ovs 物理連接網橋：分爲兩種類型，在flat和vlan網絡中使用ovs提供者網橋（provider bridge），命名爲br-ehtx
  • ​ 在vxlan、gre、geneve疊加網絡中使用ovs隧道網橋（tun bridge），命名爲br-tun
  • ​ 另外在local網絡中不需要任何ovs物理連接網橋
• 物理網絡接口：ethx

6.2.2.3 open vswitch網絡的邏輯結構

與linux bridge 代理不同，opoen vswitch 代理不通過 eth1.101、eth1.102等vlann接口隔離不同的vlan

所有的虛擬機都連接到同一個網橋br-int，open vswitch通過配置br-int和br-ethx上的流規則（flow rule）來進行vlan轉換，進而實現vlan之間的隔離，

例如內部標籤分別爲1和2，而物理網絡的vlan標籤是101和102

當br-eth1網橋上的phy-br-eth1端口收到一個vlan 1標記的數據包時，會將其中的vlan 1 轉化爲vlan 101

當br-eth1網橋上的int-br-eth1端口收到一個vlan 101標記的數據包時，會將其中的vlan 101 轉化爲vlan 1

6.3 代理————（三層，IP與路由）

6.3.1 DHCP代理

openstack的實例在啓動過程中能夠從neutron提供的dhcp服務自動獲取IP地址

6.3.1.1 DHCP主要組件

• DHCP代理（neutron-DHCP-agent）：爲項目網絡提供dhcp功能，提供原數據請求服務（metadata request）
• dhcp驅動：用於管理dhcp服務器，默認爲DNSmasq，這是一個提供dhcp和dns服務的開源軟件，提供dns緩存和dhcp服務
• dhcp代理調度器（agent scheduler）：負責dhcp代理和網絡的調度

4.3.1.2 DHCP代理的主要任務

neutron dhcp 提供兩類 reset API接口：agent managerment extension API和agent scheduler extension API

這兩類API都是extension API，是DHCP的核心組件，他們完成以下任務

• 定期報告dhcp代理的網絡狀態，通過rpc報告給neutron-server，然後通過core plugin報告給數據庫並進行更新網絡狀態
• 啓動dnsmasq進程，檢測qdhcp-xxx名稱（namespace）中的ns-xxx端口接收到DHCP discover 請求，在啓動dnsmasq進程的過程中，決定是否需要創建名稱空間中的ns-xxx端口，是否需要配置名稱空間中的IPTABLES，是否需要刷新dnsmasq進程所需的配置文件

創建網絡在子網上啓用dhcp時，網絡節點上的dhcp代理會啓動一個dnsmasq進程爲網絡提供dhcp服務

dnsmasq與網絡是一一對應關係，一個dnsmasq進程可爲同一網絡中所有啓動dhcp的子網提供服務

6.3.1.3 dhcp代理配置文件

dhcp代理配置文件是/etc/neutron/dhcp_agent.ini

其中重要的配置選項有二個

[root@ct ~(keystone_admin)]# grep -vE '^#|^$' /etc/neutron/dhcp_agent.ini 
[DEFAULT]
interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver
resync_interval=30
enable_isolated_metadata=False
enable_metadata_network=False
debug=False
state_path=/var/lib/neutron
root_helper=sudo neutron-rootwrap /etc/neutron/rootwrap.conf
[agent]
[ovs]

interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver

• interface_drive：用來創建tap設備的接口驅動

如果使用linux bridge 連接，該值設爲neutron.agent.linux.interface.BridgeInterfaceDriver

如果使用OVS 連接，該值設爲neutron.agent.linux.interface.OVSInterfaceDriver

     29 # The driver used to manage the DHCP server. (string value)
     30 #dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq

• dhcp_driver：指定dncp啓動，默認值爲neutron.agent.linux.dhcp.Dnsmasq

表示dnsmasq進程來實現dhcp服務

6.3.1.4 dhcp代理工作機制

dhcp代理運行在網絡節點上，dhcp爲項目網絡提供dhcp服務IP地址動態分配，另外還會提供元數據請求服務

工作機制如下

①用戶創建實例時，neutron隨機生成mac並從配置數據中分配一個固定的IP地址，一起保存到dnsmasq的hosts文件中，讓dnsmasq進程做好準備

②於此同時，nova-compute會設置mac地址

③實例啓動，發出dhcp discover廣播，該廣播消息在整個網絡中都可以被收到

④廣播消息到達dnsmasq監聽tap端口。dnsmasq收到後檢查hosts文件，發現有對應項，它以dhcp offer消息將IP和網關IP發回到虛擬機實例

⑤虛擬機實例發回dhcp request消息確認接收dhcp offer

⑥dnsmasq發回確認消息dhcp ack，整個過程結束

6.3.2 linux 網絡名稱空間

在介紹dhcp服務時提到的linux 網絡名稱空間（network namespace簡稱netns）是linux提供的一種內核級別的網絡環境隔離方法，namespace也可以翻譯稱爲命名空間或者名字空間

當前linux 支持6種不同類型的名稱空間，網絡名稱空間是其中一種

在二層網絡上，vlan可以將一個物理交換機分割爲幾個獨立的虛擬交換機，類似的，在三層網絡上，linux 網絡名稱空間可以將一個物理三層網絡分割成幾個獨立的虛擬三層網絡

這個可以作爲一種資源虛擬隔離機制

6.3.2.1 LINUX 網絡名稱空間概述

在linux 中，網路空間可以被認爲是隔離的擁有單獨網絡棧（網絡接口、路由、iptables等）的環境，她經常來隔離網絡資源（設備和服務）

只有擁有同樣網絡名稱空間的設備才能批次訪問。

它還提供了在網絡名稱空間內運行進程的功能，後臺進程可以運行不同名稱空間內的相同端口上

用戶還可以虛擬出一塊網卡

在網絡名稱空間裏，可以創建一個完全獨立的全新網絡環境，包括：

• 獨立的接口

• 路由表

• ARP表

• IP地址表

• iptables或ebtables等

與網絡有關的組件都是獨立的

通常情況下可以使用ip netns add 命令添加新的網絡名稱空間

使用ip netns list 命令查看所有的網絡名稱空間

執行以下命令進入指定的網絡名稱空間

ip netns exec netns名稱 命令

可以在指定的虛擬環境中運行任何命令，例如一下命令：

ip netns exec net001 bash

又如，爲虛擬網絡環境netns0 的eth0 接口增加IP地址

ip netns netns0 ip address add 10.0.1.1/24 eth0

網絡名稱空間內部通信沒有問題，但是相互之間隔離的網絡名稱空間，他們之間如果要進行通信，就必須採用特定的方法

使用veth對

veth對是一種成對出現的網絡設備，他們像一根虛擬的網絡線，可用於連接兩個名稱空間，向veth對一端輸入的數據將自動轉發到另外一端

例如創建兩個網絡名稱空間的netns1和netns2並使它們之間通信，可以執行以下步驟：

①創建兩個網絡名稱空間

ip netns add netns1

ip netns add netns2

②創建一個veth對

ip link add veth1 tpye veth peer name veth2

創建的一對veth虛擬接口，類似管道（pipe），發給veth1的數據包可以在veth2收到

發給veth2的數據包可以在veth1收到，相當於安裝兩個接口並用網線連接起來

③將上述兩個veth虛擬接口分別放置到兩個網絡名稱空間中

ip link set veth1 netns netns1

ip link set veth2 netns netns2

這樣兩個veth虛擬接口就別出現在兩個網絡名稱空間中，兩個空間就打通了，其中的設備可以相互訪問

6.3.2.2 linux 網絡名稱空間實現dhcp 服務隔離

neutron 通過網絡名稱空間爲每個網絡提供獨立的dhcp和路由服務，從而允許項目創建重疊的網絡，如果沒有這種隔離機制，網絡就不能重疊，這樣就失去了很多靈活性

每個dnsmasq進程都位於獨立的網絡名稱空間，命名爲qdhcp-xxx

以創建flat網絡爲例，neutron自動新建該網絡對應的網橋brqfxxx，以及dhcp的tap設備tapxxx。

物理主機本身也有一個網絡名稱空間，稱爲root，擁有一個迴環設備（loopback device）。

如果dhcp的tap接口放置到qdhcp-xxx名稱空間，該tap虛擬接口將無法直接與root名稱空間中的網橋設備brqxxx連接

爲此，neutron使用veth對來解決這個問題，添加veth對，使tapxxx與ns-xxx讓qdhcpxxx連接到brqxxx

6.3.2.3 linux 網絡名稱空間實現路由器

neutron允許在不同的網絡中的子網的cidr和IP地址重疊，具有相同的ip地址的2個虛擬機也不會產生衝突，這是由於neutron的路由器通過linux網絡名稱空間實現的，每個路由器有自己獨立的路由表

6.3.3 neutron 路由器

neutron路由器是一個三層的（L3）網絡的抽象，他作用是：模擬物理路由器，爲用戶提供路由、NAT等服務

在openstack中，不同子網之間的通信需要路由器，項目網絡與外部網絡之間的通信更需要路由器

neutron提供虛擬路由器，也支持物理路由器

例如，兩個隔離的vlan網絡之間需要實現通信，可以通過物理路由器實現，由物理路由器提供相應的IP路由表，確保兩個IP子網之間的通信，將兩個vlan網絡中的虛擬機默認網關分別設置爲路由器的接口A和B的IP地址。

vlan A中的虛擬機要與vlan B中的虛擬機通信時，數據包將通過 vlan A 中的物理網卡到達路由器，由物理路由器轉發到vlan B 中的物理網卡，再到達目的虛擬主機

neutron的虛擬路由器使用軟件模擬物理路由器，路由實現機制相同。neutron的路由服務由L3代理提供

6.3.4 L3 代理

在neutron 中 L3代理（neutron-l3-agent）具有相當重要的地位

6.3.4.1 L3代理作用

他不僅提供虛擬路由器，

而且通過iptables提供①地址轉換（SNAT、DNAT）、②浮動地址（floating IP）和③安全組（security group）功能

l3代理利用linux IP棧、路由和iptables來實現內部網絡中的不同網絡虛擬機的實例之間的通信，以及虛擬機實例和外部路由之間的網絡流量路由和轉發，L3代理可以部署在控制節點或者網絡節點上

6.3.4.2 路由（routing）

L3代理提供的虛擬機路由器通過虛擬接口連接到子網，一個子網一個接口，該接口的地址是該子網的網關地址

虛擬機的IP地址棧如果發現數據包的目的IP地址不在本網段，則會將其發到路由器上對應其子網的虛擬機接口

然後，虛擬機路由器根據配置的路由器規則和目的地址將包轉發到目的端口發出

L3代理會將每個路由器創建一個網絡名稱空間，通過veth對與tap相連，然後將網關IP配置在位於名稱空間的veth接口上，這樣就能夠提供路由，網絡節點如果不支持linux名稱空間，則只能運行一個虛擬路由器

6.3.4.3 通過網絡名稱空間支持網絡重疊

在雲環境下用戶可以按照自己的規劃創建網絡，不同的項目（租戶）的網絡IP地址可能會重疊，爲了實現此功能，L3代理使用linux 網絡名稱空間提供隔離的轉發上下文，隔離不同的項目（租戶）的網絡，每個L3代理運行在一個名稱空間中

每個名稱空間名稱默認格式爲：qrouter

6.3.4.4 源地址轉換（source network address translation，SNAT）

L3代理通過iptables表中增加postrouing鏈來實現源地址轉化，即內網計算機訪問外網時，發起王文的內網IP地址（源IP）轉換爲外網網關的IP地址

這種功能讓虛擬機實例能夠直接訪問外網

不過外網計算機還不能直接訪問虛擬機實力，因爲實例沒有外網IP地址，而DNAT就可以解決這一問題

項目（租戶）網絡連接到neutron路由器，通常將路由器作爲默認的網關，當路由器收到實例的數據包並將其轉發到外網時，路由器會將數據包的源地址修改爲自己的外網地址，確保數據包轉發到外網，並可以從外網返回

路由器修改返回的數據包。並轉發給之間發起訪問的實例

6.3.4.5目的地址轉換（destination network address translation DNAT）與浮動IP地址

neutron 需要設置浮動IP地址支持從外網訪問項目（租戶）網絡中的實例

每個浮動IP唯一對應一個路由器

浮動IP到關聯的端口，再到所在的子網，最後到包含該子網及外部子網路由器

創建浮動IP時，在neutron分配IP地址後，通過RPC通知該浮動IP地址對應的路由器去設置該浮動IP對應的IPtables規則，從外網訪問虛擬機實例時，目的IP地址爲實例的浮動IP地址

因此，必須由iptables將其轉化成固定的ip地址，然後再將其路由到實例

L3代理通過在iptables表中增加postrouting鏈來實現地址轉換

浮動IP地址是提供靜態NAT功能，建立外網IP地址與實例所在的項目（租戶網絡）IP地址的一對一映射，浮動IP地址配置在路由器提供網關的外網接口上，而不是在實例中，路由器會根據通信的方向修改數據包的源或者是目的IP

這是通過在路由器上應用IPTABLES的nat規則實現的

一旦設置浮動IP後，源地址轉換就不再使用外網關的IP地址了，而是直接使用對應的浮動IP地址，雖然相關的nat規則依然存在

但是neutron-l3-agent-float-snat比neutron-l3-agent-snat更早執行

6.4 服務 （services）

6.4.1 安全組（security group）

安全組定義了那些進入的網絡流量能被轉發給虛擬機實力的規則

安全組包含一些防火牆策略，被稱爲安全組規則（security group rule）

可以個每個實例綁定若干個安全組

可以定義若干個安全組

每個安全組可以有若干條規則

安全組的原理：

• 通過iptables對實例所在的計算機節點的網絡流量進行過濾
• 安全組規則作用在實例的端口上，具體是在連接實例的計算機節點上的linux網橋上實施

6.4.2 FWaas

6.4.2.1 概述

FWaas（firewall-as-a-service）是一種基於neutron-L3 agent 的虛擬防火牆，是neutron的一個高級服務

通過他，openstack可以將防火牆應用到項目（租戶）、路由器、路由器端口和虛擬機端口

在子網邊界上對三層和四層的流量進行過濾

傳統的網絡中的防火牆一般在網關上，用來控制子網之間的訪問

fwaas的原理也是一樣，在neutron路由上應用防火牆規則，控制進出項目（租戶）網絡的數據

防火牆必須關聯某個策略（policy），策略是規則（rule）的集合

防火牆會按順序執行策略中的每一條規則

規則是訪問控制的規則，由源於目的子網IP、源於目的端口、協議、允許（allow）和拒絕（deny）動作組成

安全組是最早的網絡安全模塊，其應用對象是虛擬網卡，在計算節點上通過iptables規則控制進出實例虛擬網卡的流量

fwaas的應用對象是虛擬路由器，可以在安全組之前控制從外部傳入的流量，但是對於同一個子網內的流量不做限制

安全組保護的是實例，fwaas保護的是子網，兩者互爲補充，通常部署fwaas和安全組來實現雙重防護

6.4.2.2 兩個版本：fwaasv1 和fwaas v2

fwaas v1是傳統防火牆方案，對路由器提供保護，將防火牆應用到路由器時，該路由器的所有內部端口收到保護，其中虛擬機2進出的數據流都會得到防火牆保護

新的版本的fwaas v2提供了更具細粒度的安全服務，防火牆的概念由防火牆組（firewall group）代替，一個防火牆包括兩項策略：

入口策略和出口策略

防火牆組不再用於路由器級（路由器全部端口）而是路由器端口

注意， fwaas v2的配置僅提供命令行工具，不支持dashboard圖形頁面