Open vSwitch: Provider 网络

本体系结构示例用于提供实例与物理网络基础设施之间使用VLAN(802.1q)实现的二层连接。它支持一个无标签（flat）网络和最多4095个带标签（VLAN）的网络。VLAN网络的实际数量取决于物理网络基础设施。有关provider网络的详细信息，请参阅OpenStack官方文档：intro os networking provider。

警告:
Linux发行版通常会打包较旧版本的Open vSwitch软件，这在使用网络服务时可能会出现问题。我们建议至少使用最新的长期稳定版（LTS）的Open vSwitch，以获得最佳体验和支持。参见官网可用版本和安装指南了解更多信息。

前提

一个具有以下组件的控制器节点:

两个网络接口: 管理和 provider.
OpenStack Networking server service 与 ML2 插件.

两个具有以下组件的计算节点:

两个网络接口: 管理和 provider.
OpenStack Networking Open vSwitch (OVS) layer-2 agent, DHCP agent, metadata agent, 与任何依赖关系包括OVS.

注:
大型的部署环境，通常在部分计算节点上部署DHCP和metadata代理，以提高性能和冗余度。然而，代理过多的话可能会压垮消息总线。此外，为了进一步简化部署，可以省略metadata代理，并使用配置驱动器为实例提供metadata。

架构

下图显示了一个无标签（flat）网络的组件和连接。在这种特殊情况下，实例驻留在与网络的DHCP代理相同的计算节点上。如果DHCP代理驻留在另一个计算节点上，后者只包含一个DHCP命名空间，与一个在OVS integration网桥上的端口。

下图描述了两个标签（VLAN）网络中组件之间的虚拟连接。基本上，所有使用单个OVS integration网桥的网络应当具有不同的内部VLAN标签。内部VLAN标签几乎总是不同于Networking服务中分配的网络VLAN。与无标签网络情况类似，DHCP代理可能驻留在不同的计算节点上。

注:
以上这些图片忽略了控制器节点，因为其不参与处理实例的网络流量.

示例配置

使用以下示例配置作为模板，在你的环境中部署provider网络。

控制器节点

安装提供neutron-server服务和 ML2 插件的 Networking 服务组件。
在文件 neutron.conf 中:
- 配置通用选项:
  
  请参考OpenStack项目文档： shared/deploy-config-neutron-common.txt
- 禁用service插件因为provider网络不需要. 尽管如此，这破坏了dashboard面板中管理Networking服务的部分。参考最新的安装指南获取更多信息。
  
  [DEFAULT]
  service_plugins =
- 每个network启用两个DHCP agents，所以两个计算节点都可为provider网络提供DHCP 服务。
  
  [DEFAULT]
  dhcp_agents_per_network = 2
- 如果需要, 参考关于MTU的配置文档.
在文件 ml2_conf.ini 中:
- 配置驱动和network类型:
  
  [ml2]
  type_drivers = flat,vlan
  tenant_network_types =
  mechanism_drivers = openvswitch
  extension_drivers = port_security
- 配置网络映射:
  
  [ml2_type_flat]
  flat_networks = provider
  
  [ml2_type_vlan]
  network_vlan_ranges = provider
注:
“tenant_network_types” 项为空，因为此架构不支持self-service网络.

“network_vlan_ranges” 选项的值 “provider” 缺少VLAN ID范围，支持使用任意的VLAN ID.

填充数据库

# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

启用以下的服务:
- Server

计算节点 Compute nodes

安装 Networking service OVS layer-2 agent, DHCP agent, 和 metadata agent.
安装 OVS.
在文件 “neutron.conf 中, 配置通用选项:

参见OpenStack项目文档: shared/deploy-config-neutron-common.txt

在文件 ”openvswitch_agent.ini“ 中, 配置 OVS agent:

[ovs]
bridge_mappings = provider:br-provider[securitygroup]
firewall_driver = iptables_hybrid

在文件 ”dhcp_agent.ini“ 中, 配置 DHCP agent:
```
[DEFAULT]
interface_driver = openvswitch
enable_isolated_metadata = True
force_metadata = True
```
注:

”force_metadata“项强制DHCP agent提供一个到metadata服务（169.254.169.254）的主机路由，不管子网中是否包含路由器接口，以便保持相同及可预测的子网的metadata行为。
在文件 ”metadata_agent.ini“ 中, 配置 metadata agent:
```
[DEFAULT]
nova_metadata_host = controller
metadata_proxy_shared_secret = METADATA_SECRET
```
“METADATA_SECRET”值必须与文件“nova.conf”中的“[neutron]”段中的相同选项的值相同.
启用以下服务:
- OVS
创建OVS provider网桥 ”br-provider“:
```
$ ovs-vsctl add-br br-provider
```
将provider网络接口作为一个端口添加到 ”br-provider“ 网桥上：
```
$ ovs-vsctl add-port br-provider PROVIDER_INTERFACE
```
替换“PROVIDER_INTERFACE”为处理provider网络的底层接口的名称。例如：“eth1”.
启用以下服务:

OVS agent
DHCP agent
Metadata agent

验证服务操作 Verify service operation

加载管理工程的证书.
验证存在的和运行的agents:

      $ openstack network agent list+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+| ID                                   | Agent Type         | Host     | Availability Zone | Alive | State | Binary                    |+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+| 1236bbcb-e0ba-48a9-80fc-81202ca4fa51 | Metadata agent     | compute2 | None              | True  | UP    | neutron-metadata-agent    || 457d6898-b373-4bb3-b41f-59345dcfb5c5 | Open vSwitch agent | compute2 | None              | True  | UP    | neutron-openvswitch-agent || 71f15e84-bc47-4c2a-b9fb-317840b2d753 | DHCP agent         | compute2 | nova              | True  | UP    | neutron-dhcp-agent        || a6c69690-e7f7-4e56-9831-1282753e5007 | Metadata agent     | compute1 | None              | True  | UP    | neutron-metadata-agent    || af11f22f-a9f4-404f-9fd8-cd7ad55c0f68 | DHCP agent         | compute1 | nova              | True  | UP    | neutron-dhcp-agent        || bcfc977b-ec0e-4ba9-be62-9489b4b0e6f1 | Open vSwitch agent | compute1 | None              | True  | UP    | neutron-openvswitch-agent |+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+

南北向流量 North-south

实例位于计算节点1上，并且使用provider网络1.
实例发送报文到互联网上的主机.

以下步骤涉及计算节点1:

实例的接口（1）发送报文到安全组网桥的实例端口；（2）通过 “veth” 设备对。
安全组网桥上的安全组规则（3）对报文进行防火墙以及连接跟踪处理。
安全组网桥上的OVS端口（4）转发报文到OVS integration网桥的安全组端口；（5）通过 “veth” 设备对完成.
OVS integration 网桥为报文添加内部VLAN 标签.
OVS integration 网桥 “int-br-provider” 的 patch 端口 (6) 发送报文到OVS provider 网桥 “phy-br-provider” 的patch端口（7）.
OVS provider 网桥使用真实的VLAN标签101替换报文的内部VLAN标签.
OVS provider 网桥的 provider network 端口 (8) 发送报文到物理网络接口（9）.
物理网络接口转发报文到物理网络基础设施交换机上（10）.

以下步骤涉及物理网络基础设施:

交换机去掉报文的VLAN标签101，转发到路由器（11）.
路由器将报文由provider网络（12）路由到外部网络（13），并且转发报文到交换机（14）.
交换机转发报文到外部网络（15）.
外部网络（16）接收报文.

注:

返程流量遵循反向的相同的步骤。

东西向情景 1: 实例在同一个网络

相同网络上的实例可直接在包含这些实例的计算节点之间通信.

实例1位于计算节点1，使用provider网络1.
实例2位于计算节点2，使用provider网络1.
实例1发送报文到实例2.

以下步骤涉及计算节点1:

实例1的接口（1）发送报文到安全组网桥的实例接口（2），通过 “veth” 设备对.
安全组网桥上的安全组规则（3）对报文进行防火墙和连接跟踪处理.
安全组网桥的OVS端口（4）发送报文到OVS integration网桥的安全组端口（5），通过 “veth” 设备对.
OVS integration网桥为报文添加内部VLAN标签.
OVS integration网桥 “int-br-provider” 的 patch 端口 (6) 发送报文到OVS provider网桥 “phy-br-provider” 的patch端口（7）.
OVS provider 网桥使用实际的VLAN标签101替换报文的内部VLAN标签.
OVS provider 网桥的 provider network 端口 (8) 发送报文到物理网络接口（9）.
物理网络接口转发报文到物理网络基础设施交换机（10）.

以下步骤涉及物理网络基础设施:

交换机将报文由计算节点1转发到计算节点2（11）.

以下步骤涉及计算节点2:

物理网络接口（12）转发报文到OVS provider网桥的 provider network 端口 (13).
OVS provider 网桥 “phy-br-provider” 的 patch 端口 (14) 转发报文到OVS integration 网桥 “int-br-provider” 的patch 端口 (15).
OVS integration 网桥使用内部VLAN标签替换实际的VLAN标签101.
OVS integration 网桥的安全组端口 (16) 转发报文到安全组网桥的OVS端口 (17).
安全组网桥上的安全组规则 (18) 对报文进行防火墙和连接跟踪处理.
安全组网桥的实例端口 (19) 转发报文到实例2的接口（20），通过 “veth” 设备对.

注:

返程流量遵循反向的相同的步骤。

东西向情景 2: 实例在不同的网络

实例通过物理网络基础设施中的路由器通信.

实例1位于计算节点1，并使用provider网络1.
实例2位于计算节点2，并使用provider网络2.
实例1发送报文到实例2.

注:

两个实例位于相同的计算节点以演示VLAN标签如何做到多个虚拟Layer-2网络运行在同一个物理Layer-2网络上.

以下步骤涉及计算节点:

实例1（1）发送报文到安全组网桥的实例端口（2），通过“veth”设备对.
安全组网桥上的安全组规则（3）对报文进行防火墙和连接跟踪处理.
安全组完全的OVS端口（4）发送报文到OVS integration网桥的安全组端口（5），通过“veth”设备对.
OVS integration 网桥为报文增加内部VLAN标签.
OVS integration 网桥 “int-br-provider” 的patch 端口 (6) 发送报文到OVS provider网桥 “phy-br-provider” 的patch端口（7）.
OVS provider 网桥使用实际的VLAN标签101替换报文的内部VLAN标签.
OVS provider 网桥的 provider network 端口 (8) 发送报文到物理网络接口（9）.
物理网络接口转发报文到物理网络基础设施交换机（10）.

以下步骤涉及物理网络基础设施:

交换机移除报文的VLAN标签101，转发到路由器（11）.
路由器将报文由provider网络1（12）路由到provider网络2（13）.
路由器转发报文到交换机（14）.
交换机为报文添加VLAN标签102，转发到计算节点1（15）.

以下步骤涉及计算节点:

物理网络接口（16）转发报文到OVS provider网桥的provider network 端口 (17).
OVS provider 网桥 “phy-br-provider” 的patch 端口 (18) 转发报文到OVS integration 网桥 “int-br-provider” 的patch端口（19）.
OVS integration 网桥将报文的实际VLAN标签102替换为内部VLAN标签.
OVS integration 网桥的安全组端口(20) 去除报文的内部VLAN标签，转发到安全组网桥的OVS端口(21).
安全组网桥的安全组规则 (22) 对报文进行防护墙和连接跟踪处理.
安全组网桥的实例端口（23）转发报文到实例2的接口，（24）通过“veth”设备对.

注:

返程流量遵循反向的相同的步骤。