Neutron Charms 的路由提供商网络¶
随着 L3 导向的结构在数据中心中的广泛部署，Neutron charms 需要支持多段网络。路由提供商网络已在 Neutron 本身中实现，以模拟具有多个隔离 L2 网络（每个网络都有自己的 VLAN（交换结构）和连接到这些网络的网络或计算节点）的部署。
问题描述¶
连接到单独交换结构并因此使用提供商网络的部署需要意识到连接到不同 L2 段的多个子网。虽然不同交换结构上的 VLAN ID 可能匹配，但它们定义了隔离的广播域，并且应该使用不同的子网，以便正确实施寻址和路由。
Neutron 中的提供商网络过去只有一个段，但从 Newton 开始，支持多段网络，这些网络称为路由提供商网络。从数据模型角度来看，子网与网络段关联，并且由于子网到段的分配，给定的提供商网络变为多段。这个概念与创建虚拟路由和转发 (VRF) 实例相同，因为 L3 网络上的端主机被假定位于单个地址空间中，但可能位于不同的子网中，并且需要实施路由以确保所有主机和实例之间可以相互进行 L3 访问。
路由提供商网络的注意事项包括
调度（Neutron 需要使用 Nova Placement API）；
子网变得感知段；
端口变得感知段；
IP 地址到端口的分配延迟到已知段之后；
具有 IP 地址耗尽意识的放置；
实例的实时迁移和撤离（约束在相同的 L2）；
DHCP 和元数据代理调度。
一个 nova 规范 用于路由提供商网络，其中包含对上述要点进行详细概述，包括使用 通用资源池。
为了考虑与段关联的 IPv4 地址范围，Neutron 使用 Nova placement API 创建 IPv4 库存并根据需要更新它们。Neutron 还会为每个段创建一个 Nova 主机聚合。
在修改 charm 以支持此功能时，需要考虑以下几点
“segments”服务插件启用（无条件或通过选项）；
与其他功能（L3 HA、DVR、BGP）结合的部署场景；
浮动 IP 使用；
对现有部署的影响（升级）。
此外，从 Charm 和 Juju 的角度来看，需要解决以下问题
使用 Juju AZ 或标签约束处理不同交换结构上的 physnet 映射；
适当放置单元，以确保部署了必要的代理。
部署场景¶
部署场景应包括使用 charm-neutron-gateway 和不使用它的设置。此外，对于存在 charm neutron-gateway 的用例，我们需要考虑 DVR 和 L3 HA 情况。
仅在网络节点上的提供商网络（SNAT 和 FIP 子案例）；
提议的变更¶
鉴于路由提供商网络在 Newton 版本中的实现方式存在某些限制，此规范针对 Ocata 版本。
Segments 服务插件¶
相关的 Ocata 文档部分包含 3 个主要配置要求
需要将“segments”添加到 service_plugins 列表中（neutron-api）；
需要在 neutron.conf 中添加一个计算放置 API 部分；
网关和计算节点上的物理网络相关配置选项需要与给定的交换结构配置匹配（请参阅下面的章节）；
因此，建议的方法如下
如果部署的 OpenStack 版本是 Ocata 或更高版本，则无条件地在 charm-neutron-api 中渲染“segments”service_plugin；
如果部署的 OpenStack 版本是 Ocata 或更高版本，则将 Nova placement API 部分渲染添加到 charm-neutron-api。
无条件添加 segments 服务插件的原因是该功能的实现和文档记录方式。
除非 子网与段关联，否则提供商网络被认为是单段的，并且适用旧行为。文档中也要求网络关联的所有子网都需要具有一个段，或者没有子网需要具有一个段。这在 公共文档和 代码中都有记录。
网络服务强制执行网络上的零个或所有子网都与一个段关联。例如，尝试在包含与段关联的子网的网络上创建一个没有段的子网会生成一个错误。
这种区别允许为标准的 ML2 核心插件无条件添加此服务插件。
多个 L2 网络（交换结构）¶
每个网络段都包含 网络类型信息，这意味着对于 ML2 插件的 flat_networks 和 network_vlan_ranges 选项，根据交换结构，可能存在不同的值。在这种情况下，需要部署多个相同的 charm 作为具有不同名称的应用程序，以创建每个结构的配置。这可以在 Juju 中建模为可用区，尽管这种映射并不完全准确，因为在同一个交换结构上可能有多个可用区，或者每个可用区可能有一个结构。在一般情况下，可以使用 Juju 中的标签约束来提供与交换结构相关的放置元数据。无论哪种方式，为了实现配置命名空间的隔离，以下 charm 可能需要每个结构的配置
charm-neutron-openvswitch（从属，提供商网络或 DVR 案例）；
charm-nova-compute（作为 neutron-ovs charm 的主程序 - 定义放置）；
charm-neutron-gateway（在部署它时）。
Neutron charms（ovs 或 gateway）包含以下特定于结构的选项
bridge-mappings；
flat-provider-networks；
vlan-ranges；
enable-local-dhcp-and-metadata（需要在所有地方为 true）；
虽然假设所有节点在给定部署中的配置都相同，并且节点将连接到的交换机将具有相同的配置会很诱人，但我们需要考虑一般情况。
多应用程序方法允许避免对 charm-neutron-api 进行任何修改，并在 bundle.yaml 中具有以下内容
variables:
data-port: &data-port br-data:bond1
vlan-ranges: &vlan-ranges provider-fab1:2:3 provider-fab2:4:5 provider-fab3:6:7
bridge-mappings-fab1: &bridge-mappings-fab1 provider-fab1:br-data
bridge-mappings-fab2: &bridge-mappings-fab2 provider-fab2:br-data
bridge-mappings-fab3: &bridge-mappings-fab3 provider-fab3:br-data
vlan-ranges-fab1: &vlan-ranges-fab1 provider-fab1:2:3
vlan-ranges-fab2: &vlan-ranges-fab2 provider-fab2:4:5
vlan-ranges-fab3: &vlan-ranges-fab3 provider-fab3:6:7
# allocate machines such that there are enough
# machines in attached to each switch fabric
# fabrics do not necessarily correspond to
# availability zones
machines:
"0":
constraints: tags=compute,fab1
"1":
constraints: tags=compute,fab1
"2":
constraints: tags=compute,fab1
"3":
constraints: tags=compute,fab1
"4":
constraints: tags=compute,fab1
"5":
constraints: tags=compute,fab2
"6":
constraints: tags=compute,fab2
"7":
constraints: tags=compute,fab2
"8":
constraints: tags=compute,fab2
"9":
constraints: tags=compute,fab3
"10":
constraints: tags=compute,fab3
"11":
constraints: tags=compute,fab3
"12":
constraints: tags=compute,fab3
services:
nova-compute-kvm-fab1:
charm: cs:nova-compute
num_units: 5
bindings:
# ...
options:
# ...
default-availability-zone: az1
to:
- 0
- 1
- 2
- 3
- 4
nova-compute-kvm-fab2:
charm: cs:nova-compute
num_units: 5
bindings:
# ...
options:
# ...
default-availability-zone: az2
to:
- 5
- 6
- 7
- 8
nova-compute-kvm-fab3:
charm: cs:nova-compute
num_units: 5
bindings:
# ...
options:
# ...
default-availability-zone: az3
to:
- 9
- 10
- 11
- 12
neutron-openvswitch-fab1:
charm: cs:neutron-openvswitch
num_units: 0
bindings:
data: \*overlay-space-fab1
options:
bridge-mappings: \*bridge-mappings-fab1
vlan-ranges: \*vlan-ranges-fab1
prevent-arp-spoofing: True
data-port: \*data-port
enable-local-dhcp-and-metadata: True
neutron-openvswitch-fab2:
charm: cs:neutron-openvswitch
num_units: 0
bindings:
data: \*overlay-space-fab2
options:
bridge-mappings: \*bridge-mappings-fab2
vlan-ranges: \*vlan-ranges-fab2
prevent-arp-spoofing: True
data-port: \*data-port
enable-local-dhcp-and-metadata: True
neutron-openvswitch-fab3:
charm: cs:neutron-openvswitch
num_units: 0
bindings:
data: \*overlay-space-fab3
options:
bridge-mappings: \*bridge-mappings-fab3
vlan-ranges: \*vlan-ranges-fab3
prevent-arp-spoofing: True
data-port: \*data-port
enable-local-dhcp-and-metadata: True
# each of the apps needs to be related appropriately
# ...
上面的 bundle 部分是针对没有 charm-neutron-gateway 的设置，尽管可以使用相同的方法轻松添加它。由于 charm-neutron-gateway 和 charm-neutron-openvswitch 之间没有关系，因此将每个结构的的服务关联没有问题。需要记住的是不同结构的覆盖网络的基础设施路由，以便可以创建端点之间的 VXLAN 或其他隧道。
记录的要求和限制¶
Ocata 路由提供商网络 指南提到了调度器限制，但是这些限制是针对 Newton 的，很可能已经过时。查看 Newton 文档可以确定该文档部分未针对 Ocata 进行更新。
最低 API 版本要求在 Pike 版本文档中存在
在撰写本文时（Pike），由于无法将路由提供商网络与 external-net 扩展一起使用，因此无法使用浮动 IP。
这可能被认为是一个严重的限制，但是
依赖路由提供商网络的部署本质上是 L3 导向的，并且很可能不需要经常使用 NAT 功能，从而缓解了对浮动 IP 的需求；
路由提供商网络不在部署时强制执行。
备选方案¶
N/A
实现¶
负责人¶
- 主要负责人
dmitriis
Gerrit Topic¶
对于与此规范相关的所有补丁，请使用 Gerrit 主题“1743743-fe-routed-provider-networks”。
git-review -t 1743743-fe-routed-provider-networks
工作项¶
在 charm-neutron-api 中为 Ocata+ 添加“segments”到 service_plugins；
将 section-placement 添加到 charm-neutron-api，并在 Ocata+ 模板中导入它
仓库¶
没有新的存储库。
文档¶
发布说明应提及可以使用此功能。
值得创建一个专门的指南，涵盖不同的 OpenStack 网络部署场景如何映射到 charm 选项。
安全性¶
没有明显的安全风险。
测试¶
即使在单个结构上使用不同的 VLAN 来模拟单独的结构和 L3 连接，也可以引入以下功能测试
部署具有两个 neutron-openvswitch 和 nova-compute charm 的 bundle，并按照上述描述配置它们；
创建如 文档中所述的多段网络；
创建几个具有连接到上述路由提供商网络的接口的实例，并确保在段之间提供外部 L3 连接；
验证段之间的 L3 连接。
依赖项¶
无
