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图形页面