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网络。

控制器节点

---

1. 安装提供neutron-server服务和 ML2 插件的 Networking 服务组件。

2. 在文件 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的配置文档.

3. 在文件 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.

4. 填充数据库

   # 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
   

5. 启用以下的服务:

   • Server

计算节点 Compute nodes

---

1. 安装 Networking service OVS layer-2 agent, DHCP agent, 和 metadata agent.

2. 安装 OVS.

3. 在文件 “neutron.conf 中, 配置通用选项:

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

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

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

5. 在文件 ”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行为。

6. 在文件 ”metadata_agent.ini“ 中, 配置 metadata agent:

   [DEFAULT]
   nova_metadata_host = controller
   metadata_proxy_shared_secret = METADATA_SECRET
   

   “METADATA_SECRET”值必须与文件“nova.conf”中的“[neutron]”段中的相同选项的值相同.

7. 启用以下服务:

   • OVS

8. 创建OVS provider网桥 ”br-provider“:

   $ ovs-vsctl add-br br-provider
   

9. 将provider网络接口作为一个端口添加到 ”br-provider“ 网桥上：

   $ ovs-vsctl add-port br-provider PROVIDER_INTERFACE
   

   替换“PROVIDER_INTERFACE”为处理provider网络的底层接口的名称。例如：“eth1”.

10. 启用以下服务:

• OVS agent
• DHCP agent
• Metadata agent

验证服务操作 Verify service operation

---

1. 加载管理工程的证书.
2. 验证存在的和运行的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”设备对.

注:

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