openstack-neutron
API server
API Server是 Neutron 的控制器，用户对网络资源的请求全部先交由 API Server 处理。 API Server 接到用户的请求后，会调用后端插件进行具体的任务实现。
网络插件和代理
Neutron 提供了灵活多样的网络插件和代理供用户选用，以便用户可以部署适合自身 的云环境网络。
插件与代理的主要功能在于实现由 API Server 转发的网络资源请求，如网络端口的插拔、路由增删、网络和子网创建以及提供 IP 地址等。
网络插件和代理的选取依赖于用户网络设备的厂家，个人理解为网络设备的驱动
Neutron网络概述
为了实现不同租户网络互相隔离，Neutron 提供了几种不同的网络拓扑与隔离技术，
1、Flat网络
在 Flat 网络中，不同计算节点上的全部实例接人同一个大二层网络内，全部实例共享此网络，不存在 VLAN 标记或其他网络隔离技术。
可以同时部署多个隔离的 Flat 网络，但是每个 Flat网络都要独占一个物理网卡
2、VLAN网络
VLAN 网络允许用户使用外部物理网络中的 VLAN ID 创建多个租户或供应商网络。
VLAN 网络通过 VLAN ID 进行二层网络的隔离，相同 VLAN ID 内部的实例可以实现自由 通信，而不同 VLAN 之间的实例通信则需要经过三层路由的转发。
由于 VLAN 网络可以实 现灵活多样的网络划分与隔离，故 VLAN 网络是生产环境中使用最为普遍的网络.
但是由于vlan仅有4064个，所以vlan主要用于私有云网络。
3、GRE和VxLAN
GRE 和 VxLAN 是一种网络封装协议
- 两者都是基于2次封装，类似vpn技术。
- 两者区别在于 GRE网络通过IP包进行数据传输，而VxLan通过UDP包进行数据传输，GRE或者VxLAN数据库包在流出节点之前会被打上相应的 GRE 或 VxLAN 网络 ID (Segmentation ID），而在进入节点后对应的ID会被剥离，之后再进入节点内部的虚拟网络进行数据转发。
GRE和VxLAN网络中的数据量要进入外部网络，必须配置路由器。
端口
端口port在 OpenStack 网络中是一种虚拟接口设备，用于模拟物理网络接口。
在 Neutron 中，端口是网络设备连接到某个虚拟网络的接人点，如虚拟机的 NIC 只能通过端口接入虚拟网络，端口还描述了与网络相关的配置，如配置到端口上的 MAC 和 IP
命名空间
- 在 Linux 系统中，网络命名空间（ Network Namespace）就是一个虚拟的网络设备， 网络命名空间有独立的路由表、 iptables 策略和接口设备等，网络命名空间彼此之间完全隔离。
- 假设系统中有 eth0 和 ethl 两个网卡设备，且 eth0 属于命名空间 namespacel ，而 etbl 属于 命名空间 namespace2 ，则 eth0 和 eth1 就类似于两个独立网络设备上的接口，彼此相互独立，而且只有进入各自的命名空间后，才能够对命名空间中的接口设备进行配置更改与查看。
- 因此，如果 eth0 和 ethl 加入各自的命名空间后，在 Linux 系统中，针对全局系统的网 络配置命令 ifconfig 是不能看到这两个网卡设备的相关配置信息的，必须进入各自的命名空间使用此命令才能看到相关信息。 在 Linux 中，使用命令 ip netns 可以查看系统中的全部网络命名空间，要配置或者查看命名空间中的设备，则需要进入特定命名空间并在命名空间 中执行相应命令。
- 例如，当前系统中有一个路由命名空间 qrouter-xxx，想要查看该命名空 间中的接口和 IP 配置情况，可以执行命令：
ip netns exec qroute-xxx ip addr show
Neutron 网络组件、架构与内部通讯
- 在 OpenStack 的模块架构中，网络是个代号为 Neutron 的独立社区项目，同 Compute、 Image 和 Identity 等项目一样， Neutron 的服务部署也需要跨越多个节点。
- 在 OpenStack 中，网络服务使用 Neutron-server 进程提供服务 API 接口，用户通过 Neutron-server 提供的 API 可以进行网络插件的管理配置。
- 通常为了实现网络配置数据的永久性存储，网络插件需要访问 OpenStack 的中心数据库。
- Neutron-server 不仅向云用户提供网络服务API，还向计算服务 Nova 和控制面板服务 Horizon 提供网络资源请求 API。
- 同时 Neutron-server 与 Neutron 插件需要访问 Keystone 服务以进行身份验证，而为了实现彼此交互。
- Neutron 的服务代理与插件需要访问消息队列服务。
- 其组件主要包括Neutron Server、插件代理 Plugin Agent、DHCP代理、L3代理和计量代理：
Neutron 内部各个组件代理与 Neutron Server 和 Plugins 之间以 RPC 的形式进行通信， 而 SDN Service 以 REST APis 的形式访问 Neutron Server 和相应的插件代理。 （现在REST较为流行（如对象存储的调用），早期的项目多使用RPC调用，RPC调用不透明，无法感知调用结果。REST调用采用http的报文，可用http回复的状态字节判断状态。）
Neutron Server
Neutron Server 主要负责对外提供openstack网络服务API及扩展。API接受请求后负责调用相应的Plugin进行请求处理。
而Plugin又负责调用Plugin Agent进行最终的任务处理并维护Openstack网络逻辑状态
主要运行在网络节点上，其组件包括Neutron Server服务进程和Neutron-*-plugin服务。或者说 Server API与插件构成了Neutron Server
API 接收请求后负责调用相应的 Plugin 进行请求处理，而 Plugin 又负责调用 Plugin Agent 进行最终的任务处理并维护 OpenStack 网络逻辑状态，因此Plugin 是 Neutron 中主要的数据库访问者。
1、Plugin Agent
租户网络服务请求在经过 Neutron Server 和 Plugin 之后，最终通过 Plugin Agent 来实现租户网络请求任务。
Plugin Agent ( neutron-*-agent）服务主要运行在计算节点并管理本地 虚拟交换机配置，用户选用的 Plugin 决定了计算节点所运行的 Plugin Agent，因为 Plugin 与 Agent 总是相互对应的。
插件代理服务需要访问消息队列以便和插件服务进行交互，同时插件代理需要访问数据库以便存储网络变更信息。 因此插件代理也是 Neutron 中主要的数据库访问者。
2、DHCP Agent
为租户提供DHCP服务，对neutron支持的全部网络plugins都是相同的，不依赖用户选择的Plugin
3、L3 Agent
L3 agent在provider类型的网络中并不是必须的，在self-servece网络中却是必须的。主要为外网访问租户网络中的虚拟机提供L3 route功能，L3 Agent也需要访问消息队列。
4、Network Provider Service
又称为SDN service 主要是向租户网络提供额外的网络服务
Neutron Plugin 与 Agent
Neutron plugin
- 从代码层面而言，插件是“可插拔（ Pluggable）”的 Python 类和函数，这些 Python 类 在 Neutron API 响应请求时被触发，同时插件在 Neutron Server 服务启动时加载，加载完成后插件被当成 Neutron Server 的一部分而运行。
- 用户对插件的实现可以是完整性（ Monolithic）的也可以是模块式 (Moduler）的。由于其实现过程较为复杂， Monolithic 形式的插件正被逐步淘汰，取而代之的是 Moduler 插件，其中最为成功的便是 Moduler Layer2，即 ML2 插件。
Neutron 的众多插件可以被归为两类 即 Core 插件和 Service 插件。
- Core 插件实现的是 Neutron 中的 Core API，其主要负责 L2 网络通信和 IP 管理，如网络、子网、 子网池和端口 的创建与删除。 如ML2
- Service 插件实现了 Neutron 中的扩展 API，并负责提供三层、四层和七层 的高级网络服务，如 L3 路由、防火墙、 VPN 与负载均衡等。
扩展：ML2插件详解
ML2 插件解耦了对不同网络驱动的调用，它将驱动分为两个部分， 即 TyperDriver 和 MechanismDriver。 在 Neutron 网络中， TyperDriver 代表不同的网络隔离类型（ Segmentation Type），如 Flat、 Local、 VLAN、 GRE 和 VxLAN
TyperDriver 负责维护特定类型网络所需的状态信息、执行 Provider 网络验证和租户网络分配等工作，而 MechanismDriver 主要负责提取 TyperDriver 所建立的信息并确保将其正确应用到用户启用的特定网络机制（ Networking Mechanism）中。
尽管 ML2 插件是个单一整体的插件，但是 ML2 插件支持多种 TyperDriver 和 MechanismDriver，并且不同的 MechanismDriver 所支持的 TyperDriver 种类不一样， 如 LinuxBridge 和 OpevSwitch 两种 MechanismDriver 都支持 Flat、 VLAN、 VXLAN 和 GRE这 4 种 TyperDriver，而 L2 population 仅支持 VXLAN 和 GRE这 2 种 TyperDriver，这意味着在启动 L2 population 时，用户不能使用 Flat 和 VLAN 进行租户网络的隔离。
ML2插件 typerdriver和MechanismDriver彼此支持矩阵：
MechDriver\TypeDriver Flat VLAN VxLAN GRE Open vSwitch yes yes yes yes Linux bridge yes yes yes yes SRIOV yes yes no no MacVTap yes yes no no L2 population no no yes yes ML2插件最大优势在于，可以并行使用不同开源软件或者厂家网络技术。
而这在ML2插件之前是不允许的。例如LinuxBridge和OpenvSwitch插件必须独立使用：
而使用ML2插件：
Plugin 必须与 Agent一一对应的硬性要求被屏蔽，即 ML2 插件可与多个 Agent 协同工作
Agents
Neutron Server 服务扮演的是网络控制中心的角色（通常 Neutron Server 服务也会部署在控制节点上），而实际上与网络相关的命令和配置主要在网络节点和 各个计算节点上执行，位于这些节点上的 Agents 便是与网络相关命令的实际执行者.
类似Plugin的Core 插件和 Service 插件， Agents 可以划分为 L2 Agents 与非 L2 Agents 两大类。
- L2 Agents如 OpenvSwitch agent、 LinuxBridge Agent、 SRIOV nic switch Agent 和 Hyper-V Agent 等。 L2 Agents 主要负责处理 OpenStack 中的二层网络通信，是 Neutron 网络中最为核心的部分。
- 非 L2 Agents 主要包括 L3 Agent、 DHCP Agent 和 Metadata Agent 等。 L3 Agent 负责 L3 层服务，如路由和 Floating IP ; DHCP Agent 负责 Neutron 网络的 DHCP 服务， Metadata Agent 允许用户实例通过网络 访问 Cloud-init 元数据和用户数据。 Agents 所获取的消息或指令来自消息队列总线，并且由 Neutron Server 或 Plugins 发出。
由于 Agents 负责网络的具体实现，因此 Agents 与特定 的网络技术、 Plugins 密切相关，如使用 OpenvSwitch Agent 则意味着通过 OpenvSwitch 技 术来实现虚拟网络，并且其对应的插件是 OpenvSwitch Plugin （被 ML2 插件取代）。
图 9-11 所示是 ML2 插件协同 OpenvSwitch Agent 与 Neutron 中的其他网络服务进行交互的简单流程。
在图 9-11所示中， Neutron Server 接收到客户端的 API 请求后，触发 ML2 插件进行请求处理， 由于 ML2 插件已经加载了 OVS Mechanism Driver （即 OpenvSwitch 插 件），于是 ML2 插件将请求转发给 ovs 驱动， ovs 驱动收到请求后使用其中的可用信息创建 RPC 消息， RPC 消息以 Cast 形式投递到计算节点上特定的 OVS Agent，计算节点上的 OVS Agent 接收到消息后便开始配置本地 OpenvSwitch 交换机实例
@w=600
与Plagin类似，Agent与Mechanism Driver也存在对应关系
Reference Implementaion L3 Agent DHCP Agent Metadata Agent L3 Metering Agent Open vSwitch&Open vSwitch Agent yes yes yes yes Linux bridge&Linux bridge Agent yes yes yes yes SRIOV&SRIOV nic switch Agent no no no no MacVTap&MacVTap Agent no no no no
通过以上分析可以看出，Neutron 的功能模块主要由 API Server、 Plugin 和 Agent 组成，其中 API Server 和 Plugins 主要由 Neutron-Server 服务运行，并且 Neutron 推荐的核心 Plugin 为 ML2 插件。
Neutron 插件的各种 Agent 位于计算节点和网络节点上，负责具体网络技术的实现。 如果将 Neutron 的内部功能结构展开 将得到图 9-12 所示的 Neutron 内部结构剖析图。
Neutron L3 Service 分析
在 Neutron 中， L3 Service 是个非常关键的服务， 其主要提供虚拟机不同 L2 子网之 间的 L3 路由，以及虚拟机与外网之间的 SNAT 和基于 Floating IP 的 DNAT 功能，如果 Open Stack 网络中未部署 L3 服务，则用户只能部署基于 Provider 的网络，而无法实现真正 的云计算 Self-Service 网络。
L3 Service 主要由 L3 Service 插件及其 API 和对应的 L3 Agent 组成，其中 L3 Service 插件和 API 由 Neutron-Service 服务来运行。通常部署在控制节点 上，而 L3 Agent 可以部署在控制节点上，也可以部署在网络节点上。
但是从 OpenStack 的 Juno 版本开始， L3 Agent 也可以部署在计算节点上以实现分布式虚拟路由（ Distributed Vritual Router, DVR）功能。
在实际工作中， Neutron 以 RESTful 的形式提供了两种类型的 API 服务，即 Core API 和 Extension API。 通过 Neutron 的 Core API，管理员可以创建网络、子网和端口等核心网络要素。通过 Extension API，管理员可以创建虚拟 Router、 LoadBalance、 VPN 和 Firewall 等高级的网络功能。
与 Neutron 的 Core API 和 Extension API 对应的是 Core Plugins 和 Service Plugins, Neutron Server 中的 API Server 在接收到请求后， 会调用相应的 Plugins 来 响应用户发起的网络资源请求。
Core Plugins 主要用于定义二层网络的网络类型以及网络接 口驱动等底层核心功能。
Service Plugins 主要用于定义 L3 Router 等三层以上的网络高级功能。
通常情况下，租户可以通过 L3 Plugin 提供的 APJ 创建虚拟 Router 和 Floating IP，并通 过Nova 的 API 将 Floating IP 绑定到实例上，从而实现租户内网与外网的通信。
@w=500
L3 Service 服务过程梳理
- 插件加载。
位于控制节点的 Neutron-Server 在启动时加载 L3 Service 插件， L3 Service 插件主要负责响应和处理用户对三层网络服务的 REST 请求，并将请求以 RPCcast 形式通过消息队列传递给网络节点上的 L3 Agent 进行最终处理。 L3 Service 工作过程如 图 9-15 所示。
-
L3 Agent 注册。
L3 Agent 通常运行在网络节点上， L3 Agent 服务启动后，通过消息 队列将自身注册到位于控制节点上的 L3 Service Plugin 中，以作为 Router Scheduler 对象供 口 Plugin 调用。 L3 Agent 实现由 Neutron AP！请求的虚拟路由功能。 -
虚拟路由管理。
网络节点上的 L3 Agent 根据控制节点 L3 Service Plugin 传递的配置 参数进行本地（网络节点）虚拟路由的管理。 -
路由功能实现。
Neutron L3 Agent 使用 Linux Nam esp ace 和 iptables 规则实现虚拟路 由功能。 -
路由隔离。
Namespace 提供了隔离的网络樵（ Network Stack） 空间，每个网络枝命 名空间中都有属于自己的 Routing tables 和 iptables 规则，由于网络梳命名空间彼此隔离， IP 地址可以在命名空间限制范围内重复使用。 -
路由创建。
L3 Agent 在网络节点上为租户网络中的每一个虚拟路由创建一个命名空 间，之后在命名空间中创建相应的虚拟路由端口 。 -
添加租户子网接口 。
当用户将租户子网在接入虚拟路由时，对应命名空间中虚拟路 由接口被标记到集成网桥上（通常以 br-int 表示），标记 ID 为租户网络的 Segmentation ID。 -
设置外网网关。
命名空间中的虚拟路由包含一个外网（通常以 br-ex 表示）的网关 接口 。 -
路由功能实现。
L3 Router 将 iptables 规则应用到命名空间虚拟路由网关接口上以实 现 DNAT (Floating IP）和 SNAT 功能。
L3 Router的工作流程
为了举例说明 L3 Router 的工作流程， 这里以部署一套常见的三层（Web-App-DB) Web 应用云虚拟机和租户网络为例。
由于要求 Web、 App 和 DB 分别处于不同的网 络，因此租户需要分别创建三个网络 webnet、 app-net 和 db-net，同时在三个网络上分别启动用于 Web、 App 和 DB 应用的实 例 web-server、 app-server 和 db-server。
由于 Web 服务器需要访问 App 服务器，同时 App 服务器需要访问 DB，因此需要创建一个虚拟路由，并将三个网络同时接人路由，同时需要为路由设置外网网关以便外网可以 访问 Web 服务器。 网络和实例创建完成后， 对应的 Neutron 网络拓扑如图 9-16 所示
@w=400
在上述虚拟路由的创建、子网接入和网关设置过程中， L3 Agent会为命名空间中的虚拟路由创建对应三个网络的三个端口，并将三个端口绑定到集成网桥 br-int 上.
为了进行网络隔离，绑定到 br-int 上的每个接口都会被打上与租户网络对应的 Local VLAN ID。 当各个租户网络跨越物理节点进行网络通信时，具有各自 Local VLAN ID 的网络数据在进入隧道（ Tunnels）之前， Local VLAN ID 会被隧道网桥（ br-tun）映射成为 Segmentation ID。
与图 9-16 中所示租户网络拓扑的网络节点对应的内部结构如图 9-17 所示。
图 9-17 所示中，网络节点中三个 DHCP 服务器分别为三个租户网络的实例提供 DHCP 服务，而三个租户网络均接入同一个虚拟路由，只是在 br-int 上创建了三个具有不同 Tag 的端口， 如 qr-
如果外部网络需要访问租户内网，则必须经过虚拟路由的网关接口才能实现，而如果租户内部私网在不同节点之间通信，则需要经过隧道网桥 br-tun，并通过 VxLAN 封装协议来实现。 在多数情况下，Neutron 的上述 L3 工作方式可以正常应对 OpenStack 灵活复杂的网络要求，但是这种 L3 功能集中部署的方式存在固有的限制，而这 种限制极大影响了整个 OpenStack 集群的性能和可扩展性。
在上述 3-Tier Web 应用服务器 部署示例中，除了租户私网与外网的南北向通信外，租户不同子网之间的通信数据流也要全部经过网络节点，这就意味着位于不同计算节点上的实例之间进行通信，其数据流也要进出网络节点， 即所有计算节点的数据流都要先汇聚到网络节点才能进行彼此通信。
而正常情况下， Web 服务器对 App 服务器的网络访问和 App 对 DB 的访问都不应该绕到网络节点，而是在两台服务器的宿主计算节点之间便可直接进行，然而由于计算节点没有 L3 Agent，因此全部计算节点的数据流都必须集中到部署了 L3 Agent 的网络节点，这个过程如图 9-18 所示。
@w=800
在小规模的 OpenStack 集群中 ，计算节点数目较小的情况下，上述 L3 Agent 集中的网络部署形式对集群性能的影响可能不是很明显，但是随着集群规模的扩大，计算节点数目 变得越来越多，计算节点上的虚拟机之间的通信也变得越来越频繁，此时的网络负载便会出现质的提升，因此网络瓶颈将会十分突出，如图 9-19 所示。
在 L3 Agent 集中部署到网络节点的情况下，单一的网络节点很可能因为过大的网络负载而出现各种性能问题。 为了解决这一问题，从 Juno 版本开始，社区引入了分布式虚拟路由 DVR ( Distributed Vritual Router）功能。
DVR 的主旨思想就是将 L3 Agent 的功能由网络节点分布到计算节点，从而让计算节点分流单一网络节点上的网络负载。 OpenStack Juno 版本发行后， DVR 功能被实现， L3 Service 的 L3 Agent 可以部署到计算节点，计算节点实例无须再到网络节点获取 L3 Routing 服务，网络节点仅负责 L3 SNAT 功能，其余 L3 Routing 功能被分散到各个计算节点。
但是在启用 DVR 模式的情况下，用 户不能启用 Neutron 的 L3 HA 功能。 不过在 Mitaka 版本发行后， DVR 与 L3 HA 的冲突限制被解决，当计算节点启用 DVR 模式时，网络节点的 L3 SNAT 可以启用基于 VRRP 协议的 L3 SNAT 高可用功能，即 Mitaka 版本中的 Neutron 实现了 L3 Service 全部功能的高可用。 DVR 模式下 L3 Service 各个功能模块在 Neutron 内部的分布情况如图 9-20 所示。
Neutron网络类型
Neutron 提供了两种网络类型，即租户Self-Service网络（Project Network 后者又称 Tenant 网络）和供应商网络（ Provider Network）。。
二者主要区别在于 Provider 网络只能由云管理员创建，并且实例仅可接入 Provider 网络 （又称外部网络或物理网络）， Provider 网络中不存在租户私网，也没有 L3 路由和 Floating IP 地址，同时 Provider 网络仅支持 Flat 和 VLAN 网络类型；
Tenant 网络是对 Provider 的扩展， 在租户可以创建 Tenant 网络之前必须先由云管理员创建 Provider 网络， Tenant 网络具有 L3 服务， 因此实例可以接人租户私网，除了云管理员，其他非授权用户也可以自助管理和使用 Tenant网络， 包括用以将私网与外网进行互联的 Router。 在 Tenant 网络中 ，外部网络（如 Internet）对接人私网的实例访问通过 Floating IP 来实现。
Provider Network
Provider 网络是一种仅实现二层 网络虚拟化，LoadBlancer、 Firewall 等高级功能的 Neutron 网络类型，相对而言， Provider 是一种半虚拟化的网络。 在 Provider 中 ，三层以上的功能不被虚拟化，而是借助物理网络设备来实现。
在 Provider 网络中，由于二层网络直接接入物理设备，二层网络之间的通信也由物理设备进行转发，因此 Provider 网络在实现过程中无须口服务，控制节点只需部署 API Server、 ML2 核心插件及 DHCP 和 Linux bridging 代理即可。
计算节点中的实例通过虚拟二层交换机直接接人物理网络，因此计算节点只需部署如 Open vSwitch 或 Linux bridging 等代理软件即可
Provider 网络拓扑架构很简单，只需在控制节点和计算节点中分别规划一块物理网卡， 并将其接入物理网络即可。 如果采用的是 VLAN 网络，则将交换机接口配置为 Trunk 模式， 节点只需一块物理网卡便可通过多个 VLAN ID 来实现不同网络的隔离。 如果采用的是 Flat网络，由于 Flat 网络没有 Tagging，如要配置多个 Flat 网络则需要节点提供同样数量的物理网卡
Provider 网络的拓扑架构如图 9-22 所示。
在 Provider 网络中，实例直接接人 Provider 网络（外部网络，如 192.168.115.0/24 ), 因此也不存在私有网络和虚拟路由设备的概念，同时也无须 Floating IP，即实例虚拟接口上获取的就是外网 IP。 外部网络可以直接访问位于 Provider网络上的虚拟机实例，而访问控制由计算节点上的防火墙规则来实现。
外网对实例的访问需要经过两个阶段，即 Provider 物理网络和 Provider 虚拟网络（如图 9-23 所示）。 Provider 物理和虚拟网络属于同一个网 络（ 192.168.115.0/24 ），只是网络被分为物理实现和虚拟实现，即节点内部为虚拟网络，而节点外部为物理设备网络。
Self-Service 网络
Self-Service 网络不仅提供了二层网络功能，还提供了三层路由转发和 VPN、 LoadBlancer、 Firewall 等高级网络功能。 在 Self-Service 网络中，租户可以自主创建和管理属于自己的多个租户子网（私有网络）并分配任意有效的私网 IP 地址，不同租户子网之间和租户私网与外网之间通过 L3 路由进行转发。 除了 Flat 和 VLAN 网络， Tenant 还 支持 GRE 和 VxLAN 等 Overlay 形式的租户网络隔离方式。
与 Provider 网络不同， Self-Service 网络的 L3 层功能采用虚拟技术来实现，因此 Self-Service 网络在实现过程中需要运行更多的网络服务组件。 由于部署 Self-Service 网络之前， 必须首先实现 Provider 网络，因此 Self-Servic巳网络的服务布局相对于 Provider 主要是多了 L3 Agent，如图 9-24 所示。
在租户可以创建 Self-Service 网络之前，管理员必须事先创建 Provider 网络， 然后租户创建的 Self-Service 网络通过 NAT 形式接入 Provider 物理网络。
计算节点上的实例创建时，接入 Self-Service 网络的实例可以直接访问外部网络（如 Internet） 。 但是，外部网络要访问计算节点实例，则必须通过实例 Floating IP，并通过 DNAT 才可实现。 Self-Service 网络通常使用 GRE 或 VxLAN 这类 Overlay 网络，即将虚拟网络进行封装后叠加（ Overlay) 到物理网络上进行传输。 由于 Self-Service 本身是租户内部私有网络（虚拟网络）， SelfService 网络中不同节点之间要实现互通，需要借助隧道（ Tunnel）封装技术来实现（如 GRE 或 VxLAN），通常节点之间的 Tunnel 建立在物理管理网络之上（ Management Physical Network), Self-Service 网络拓扑如图 9-25 所示。 图 9-25 中，由于 Self-Service 网络建立在 Provider 网络基础之上，因此 Self-Service 网络中可以并存 Provider 网络。
如前文所述， Provider 网络仅支持 Flat 和 VLAN 网络，而 Self-Service 网络中可以并 存 Provider 网络，因此 Self-Service 网络支持 Flat、 VLAN、 GRE 和 VxLAN 网络类型，并 且 Self-Service 网络中的实例也可以直接接入 Provider 物理网络，并使用 Flat 或 VLAN 方 式进行网络隔离。
一般情况下，在创建 Self-Service 网络后，计算节点实例通常接入 SelfService 网络， Self-Service 网络再通过 L3 路由接入 Provider 物理网络，并且 Self-Service 中的网络类型通常采用 GRE 或 VxLAN。
当实例创建完成并接人 SelιService 网络后，通常需要在 Provider 物理网络中创建 Floating IP 并将其绑定到实例上，以使得外部网络可以直接访问实例，这里实例从 Self-Service 网络中获取的 IP 称为固定 IP (Fixed ID），而租户从 Provider 物理网络中获取并绑定到实例的 IP 称为浮动 IP。
浮动 IP 可以解绑定之后重新分配给其他实例（如果将实例直接接入 Provider 网络，则不存在固定 IP 与浮动 IP 的概念）。 Self-Service 网络内部的通信过程如图 9-26 所示。 图中不仅有 Self-Service 网络， 还存在 Provider 网络。
Provider 网络部署与分析
Provider 网络（或者物理网络）是 Neutron 网络部署中一种拓扑简单、 性能优异、 可靠性较好的网络架构，但是 Neutron Provider 网络的这些优点是基于物理网络设备实现的，因此 Provider网络本质上不具备云计算网络的弹性按需和灵活操作等特性。
Provider 网络基于 OpenvSwitch 实现
Neutron 的 Provider 网络可以通过各种开源或厂商的网络插件和代理来实现，在开源领域，使用最多的是 ML2 网络插件和代理。
其中， ML2 插件通常部署在控制节点上，而 LinuxBridge 代理或 OpenvSwitch 代理部署在计算节点上
Provider 网络不需要网络节点。本节主要介绍基于 OpenvSwitch 开源网络技术的 Provider 网络部署实现，后一节将介绍基于 LinuxBridge 网络技术的 Provider 网络部署实现。 为了便 于介绍，这里以部署一个控制节点和两个计算节点组成的 VLAN 类型 Provider 网络为例， 节点群集 Provider 网络拓扑如图 9-27 所示。
图 9-27 所示中，控制节点和计算节点均至少需要两个网络接口，其中 InterfaceI 作为管理接口（管理网络为 10.0.0.0/24 ), lnterface2 作为 Provider 接口 。 各个节点的 Provider 接口 Interface2 接人常规物理网络中（物理交换机或路由到外部的网络）， Provider 网络接口上需要一个端口用于 OpenvSwitch 桥接，作为桥接用的物理网络端口不配置 IP。
Neutron 网络服务在控制节点和两个计算节点 上的分布如图 9-28 所示，其中，控制节点运行网 络管理服务 Neutron-Server、 ML2 插件、 DHCP 代理和 OpenvSwitch 软件及其代理服务，计算节 点除了运行 Nova-compute 服务之外，还需运行 ML2 插件、 OpenvSwitch 软件及其代理服务。
provider 网络架构
在 Provider 网络的常规架构中 ， 控制节点主要包括 OpenvSwitch Agent 和 DHCP Agent 网络组件，
其中， OpenvSwitch Agent 主要负责节点内部虚拟交换机的管理及其通信，同时还负责通过虚拟端口与其他网络组件进行交互，如命名空间 Namespace 或其他底层的接口 。
DHCP Agent 主要负责管理 DHCP 命名空间， DHCP 命名空间主要负责为使用 Provider 网络 的实例自动分发 IP。
图 9-30 和图 9-31 是常规 Provider 网络架构下控制节点网络组件及组件之间的连接示意图。 为了便于说明，图 9-31 所示中包含了两个不同的 Provider 网络。
与控制节点不同，计算节点主要运行的网络组件是 OpenvSwitch Agent 和 LinuxBridge Agent，其中 OpenvSwitch Agent 主要负责节点内部虚拟交换机的管理及其通信，同时还负责通过虚拟端口与其他网络组件的交互，如 LinuxBridge 或其他底层的网络接口 。
使用 OpenvSwitch Agent还需要使用LinuxBridge 的原因是传统 LinuxBridge 对安全组（ SecurityGroups）的处理要优于原生的 ovs 实现.
图 9-32 和图 9-33 是常规 Provider 网络架构下计算节点网络组件之间的连接示意图，为了便于说明，图 9-33 所示中 包含了两个不同的 Provider 网络。
provider 南北向流量分析
Provider 网络架构下，南北网络数据流向如图 9-34 所示。
在图 9-34 所示中，如果位于计算节点上的实例发送一个数据包到外网中的主机上， 则计算节点将产生如下的操作：
-
首先实例 Tap 接口将数据转发到节点内部的 LinuxBridge 网桥 qbr 上，由于目标主机位于其他网络，实例发出的数据包中包含目标主机的 MAC 地址，数据进入 qbr 后，其上的安全组规则对数据包进行状态跟踪和防火墙处理。
-
之后 qbr 将数据转发到 OpenvSwitch 的集成网桥 br-int 上，集成网桥 br-int 为数据包添加与 Provider Network 对应的内部标记（ Internal tag） 。
-
然后 hr-int 将数据转发到 OpenvSwitch 的 ProviderBridge 网桥 br-ex 上， br-ex 用实际的 ProviderNetwork VLAN ID 替换掉 hr-int 添加的 Internal tag。
-
最后 br-ex 通过计算节点的 Provider 网络接口将数据包转发到物理网络设备上。
-
数据包进入物理网络设备后，将进行如下的操作：
-
首先由交换机处理 Provider Network 与路由之间的 VLAN tag 操作；
-
然后路由器将来自 Provider Network 的数据包路 由到外部网络，交换机再次处理路由器与外网之间的 VLAN tag 操作；
-
最后交换机将数据 包转发到外网。
-
外网主机对 Provider 网络中的实例访问过程与实例对外网主机的访问过程 正好相反。
provider 东西向流量分析
Provider 网络东西数据流分为两种类型，即位于相同网段中的实例通信和不同网段之间的实例通信。 二者的区别在于， 不同 Provider 网段之间的实例通信需要具备三层路由功能的物理网络设备进行路由转发， 而相同 Provider 网络中的实例通信只需二层物理交换机进行转发。 不同 Provider 网络之间 的实例通信过程如图 9-35 所示。
provider网络的部署\创建\验证
基于openvswitch和linuxbridge的provider网络的部署,创建,和验证详见书籍P418
Self-Service网络部署和高可用
在实现 Self-Service 网络之前管理员必须已经实现 Provider 网络，因此在 Self-Service 网络中，用户也可以直接使用 Provider 网络，并将实例直接接人 Provider 物理网络而不是租户私有云网络。
与基于 OpenvSwitch 的 Provider 网络类似， Self-Service 网络的网络插件仍 然选择 ML2 核心插件，而不是 OpenVS witch Plugin （此插件已被 ML2 替换），同时代理选择 OpenvSwitch Agent，而 ML2 的 MechanismDriver 选择 ovs （即 OpenvSwitch）
在最简单的三节点 Self-Service 网络部署中，为了 Project 网络既可以使用 VLAN 类型，也可以使用 GRE/VxLAN 类型，控制节点至少需要一个网络接口（管理网络），网络节点至少需要四个网络接口（管理网络、 隧道网络、 VLAN 网络和外部网络），计算节点至少需要三个网络接口（管理网络、隧道网络和 VLAN 网络）。需要指出的是，如果 External 网络和 Project 网络都采用 VLAN 类型，则节点互联的物理网络设备必须支持 VLAN tagging。 Self-Service 网络的节点 Neutron 组件部署和常规架构如图 9-42 和图 9-43 所示。
计算,网络节点简介
图 9-42 所示中,计算节点上除了运行 Nova-compute 服务外，还运行 Neutron 的 ML2 插件和 OpenvSwitch 软件及其代理 Agent;控制节点主要运行 Neutron-Server 和 ML2 插件,网络节点运行 OpenvSwitch 软件及其 Agent、ML2 插件、L3 Agent、DHCP Agent 和 Metadata Agent。
图 9-43 所示中，每个计算节点都有 VLAN 网络和 Tunnel 网络， 而网络节点包括 VLAN 网络、 Tunnel 网络和外部网络。
需要指出的是，计算节点和网络节点上并非同时需要 VLAN 网络和 Tunnel 网络。 根据 Project 网络类型，用户也可以只部署 VLAN 网络或 Tunnel 网络。 如 Project 网络为 GRE/VxLAN 类型 ，则仅需要 Tunnel 网络，如果 Project 网络为 VLAN，则仅需要 VLAN 网络。
网络节点
网络节点主要包括 OpenvSwitch Agent、 DHCP Agent、 Metadata Agent 和 L3 Agent。
OpenvSwitch Agent 主要负责管理虚拟交换机及其通信，以及通过虚拟交换机端口与其他网络组件的交互，如命名空间 LinuxBridge 和其他底层网络接口；
DHCP Agent 管理 DHCP 命名空间，主要负责为 Project 网络中的实例自动分配 IP;
L3 Agent 主要负责管理 qrouter 命名空间； qrouter 命名空间负责 Project 网络与 External 网络以及 Project 网络之间 的连接，同时还负责路由实例与 Metadata Agent 之间的元数据信息；而 Metadata Agent 主要负责实例元数据相关操作。 网络节点内部运行的各个组件之间的交互过程如图 9-44 所示。
计算节点
计算节点主要运行的网络组件是 OpenvSwitch Agent 和 LinuxBridge Agent。
OpenvSwitch Agent 主要负责节点内部虚拟交换机的管理及其通信，同时还负责通过虚拟交换机端口与其他网络组件的交互，如 LinuxBridge 或其他底层的网络接口；
而 LinuxBridge Agent 主要用于处理与实例相关的安全组问题。 计算节点内部各个网络组件之间的交互过程如图 9-45 所示。
Self-Service 网络南北数据流分析
南北数据通信分为两种情况，即 Fixed IP 形式的南北网络通信 和 Floating IP 形式的南北网络通信。
对于仅有 Fixed IP 而没有为其绑定 Floating IP 的实例， 网络节点的 Router 负责 Project 网络与 External 网络的通信路由.
FixedIP 实例南北网络通信过程如图 9-46 所示。 图 9-46 所示中，假设 Compute Nodel 中的 instance 向 External 网络中的主机发送数据包，则该数据包在 Compute Nodel 节点内部的处理流程如下：
