本体系结构示例用于提供实例与物理网络基础设施之间使用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”设备对.
注:
返程流量遵循反向的相同的步骤。