Neutron - 网络服务¶
准备和部署¶
Neutron 默认在 /etc/kolla/globals.yml 中启用
#enable_neutron: "{{ enable_openstack_core | bool }}"
网络接口¶
Neutron 外部接口用于与外部世界通信，例如提供商网络、路由器和浮动 IP。要设置 Neutron 外部接口，请修改 /etc/kolla/globals.yml 设置 neutron_external_interface 为所需的接口名称或逗号分隔的接口名称列表。其默认值为 eth1。这些外部接口由 network 组中的主机使用。如果设置了 enable_neutron_provider_networks 或启用了 DVR，它们也由 compute 组中的主机使用。
外部接口分别连接到由 neutron_bridge_name 定义的桥接器（Open vSwitch 或 Linux Bridge，具体取决于驱动程序），默认值为 br-ex。当有多个外部接口时，neutron_bridge_name 应该是一个相同长度的逗号分隔列表。
默认 Neutron 物理网络是 physnet1，或者当有多个外部网络接口时，是 physnet1 到 physnetN。可以通过将 neutron_physical_networks 设置为相同长度的逗号分隔列表来更改此设置。
示例：单个接口¶
在只有单个 Neutron 外部接口的情况下，配置很简单
neutron_external_interface: "eth1"
示例：多个接口¶
在某些情况下，可能需要多个外部网络接口。这可以通过逗号分隔的列表来实现
neutron_external_interface: "eth1,eth2"
neutron_bridge_name: "br-ex1,br-ex2"
这两个列表是“zip”在一起的，这样 eth1 连接到 br-ex1 桥接器，而 eth2 连接到 br-ex2 桥接器。Kolla Ansible 将这些接口映射到 Neutron 物理网络 physnet1 和 physnet2 分别。
示例：自定义物理网络¶
有时我们可能希望自定义使用的物理网络名称。这可能是为了允许并非所有主机都可以访问所有物理网络，或者使用更具描述性的名称。
例如，在具有用于 Ironic 配置的单独物理网络的环境中，控制器可能可以访问两个物理网络
neutron_external_interface: "eth1,eth2"
neutron_bridge_name: "br-ex1,br-ex2"
neutron_physical_networks: "physnet1,physnet2"
而计算节点只能访问 physnet2。
neutron_external_interface: "eth1"
neutron_bridge_name: "br-ex1"
neutron_physical_networks: "physnet2"
提供商网络¶
提供商网络允许将计算实例直接连接到物理网络，从而避免隧道。这对于某些性能关键型应用程序是必需的。只有 OpenStack 的管理员才能创建这些网络。
要在实例中使用提供商网络，还需要在 /etc/kolla/globals.yml 中设置以下内容
enable_neutron_provider_networks: yes
对于提供商网络，计算主机必须创建一个由 Ansible 配置和配置的外部桥接器（当 Neutron 分布式虚拟路由 (DVR) 模式启用时也需要这样做）。在这种情况下，请确保为 compute 组中的主机正确配置了 neutron_external_interface。
内部 DNS 解析¶
网络服务允许用户使用与端口、网络和浮动 IP 关联的两个属性来控制分配给端口的名称。下表显示了这些资源中每个资源可用的属性
资源 |
dns_name |
dns_domain |
|---|---|---|
端口 |
是 |
是 |
网络 |
否 |
是 |
浮动 IP |
是 |
是 |
要启用此功能，需要在 /etc/kolla/globals.yml 中设置以下内容
neutron_dns_integration: "yes"
neutron_dns_domain: "example.org."
重要提示
neutron_dns_domain 值必须不同于 openstacklocal（其默认值）并且必须以句点 . 结尾。
注意
网络服务与外部 DNSaaS（DNS-as-a-Service）的集成在 Designate - DNS 服务 中描述。
OpenvSwitch (ml2/ovs)¶
默认情况下，kolla-ansible 使用 openvswitch 作为其底层网络机制，您可以使用 neutron_plugin_agent 变量在 /etc/kolla/globals.yml 中更改它
neutron_plugin_agent: "openvswitch"
当在兼容的内核（4.3+ 上游，请参阅您的发行版的文档以了解支持详细信息）上使用 Open vSwitch 时，您可以通过使用配置覆盖（请参阅 Kolla 中的 OpenStack 服务配置）切换到使用本机 OVS 防火墙驱动程序。您可以在 /etc/kolla/config/neutron/openvswitch_agent.ini 中设置它
[securitygroup]
firewall_driver = openvswitch
L3 代理高可用性¶
可以使用以下命令以高可用性 (HA) 状态创建 L3 和 DHCP 代理
enable_neutron_agent_ha: "yes"
如果活动代理停止，这允许网络在控制器之间故障转移。如果启用此选项，也建议设置
neutron_l3_agent_failover_delay:
有时需要重新启动代理。在每个代理的重新启动操作之间调用此延迟（以秒为单位）。正确设置后，它将停止由所有代理同时重新启动引起的网络中断。确切的重新启动时间取决于硬件和存在的路由器数量。一个经验法则是将值设置为 40 + 3n，其中 n 是路由器的数量。例如，对于 5 个路由器，40 + (3 * 5) = 55，因此可以将该值设置为 55。但是，更好的方法是首先确定中断持续多长时间，然后相应地设置该值。
默认值为 0。非零起始值仅会在故障转移时间大于延迟时导致中断，这比一致的行为更难诊断。
OVN (ml2/ovn)¶
为了将 OVN 作为 neutron 的机制驱动程序使用，您需要设置以下内容
neutron_plugin_agent: "ovn"
使用 OVN - Kolla Ansible 默认不会启用分布式浮动 IP 功能（不会在计算节点上启用外部桥接器）。要更改此行为，您需要设置以下内容
neutron_ovn_distributed_fip: "yes"
默认情况下，通过将 ovn-controller 组中的总主机数除以 ovn_sb_db_relay_compute_per_relay（默认为 50）中的值并向上取整来计算中继组的数量 (ovn_sb_db_relay_count)。例如，如果您在 ovn-controller 组中有 120 个主机，您将得到 ceil(120 / 50) = 3 个中继组。您可以覆盖 ovn_sb_db_relay_compute_per_relay 以缩放每个中继处理的主机数量，例如
ovn_sb_db_relay_compute_per_relay: 25
您还可以通过 ovn_sb_db_relay_count 绕过自动计算并手动设置固定数量的中继组
ovn_sb_db_relay_count: 10
注意
如果显式设置 ovn_sb_db_relay_count，它将有效地覆盖基于 ovn_sb_db_relay_compute_per_relay 计算的计数。
也可以使用 Ansible host_var ovn_sb_db_relay_client_group_id 设置 ovn-controller 主机（网络节点或超visor）与特定 OVN 中继之间的静态映射。
同样 - 为了在 OVN 网络场景中部署 Neutron DHCP 代理，请使用
neutron_ovn_dhcp_agent: "yes"
这可能需要，例如，当使用 Ironic 裸机节点作为计算服务时。目前 OVN 无法回答端口类型外部的 DHCP 查询，Neutron 代理就在这里提供帮助。
为了部署 Neutron OVN 代理，您需要设置以下内容
neutron_enable_ovn_agent: "yes"
目前，该代理仅用于硬件卸载端口的 QoS。
在需要运行 ovn-nbctl 或 ovn-sbctl 命令时，从 ovn_northd 容器运行它们最方便
docker exec ovn_northd ovn-nbctl show
Mellanox Infiniband (ml2/mlnx)¶
为了将 mlnx_infiniband 添加到 neutron 的机制驱动程序列表中以支持 Infiniband 虚拟功能，您需要设置以下内容（假设也使用 enable_neutron_sriov 标志启用了 neutron SR-IOV 代理）
enable_neutron_mlnx: "yes"
此外，您还需要通过 neutron_mlnx_physnet_mappings 提供 physnet:interface 映射，该映射通过 mlnx_agent.ini 和 eswitchd.conf 将其呈现给 neutron_mlnx_agent 容器
neutron_mlnx_physnet_mappings:
ibphysnet: "ib0"
外部系统中（交换机）的 SSH 身份验证¶
默认情况下，Kolla 会生成并复制 ssh 密钥到 neutron_server 容器（位于 /var/lib/neutron/.ssh/id_rsa），可用于在外部系统（例如在 networking-generic-switch 或 networking-ansible 管理的交换机）中进行身份验证。
您可以在 passwords.yml 中设置 neutron_ssh_key 变量以控制使用的密钥。
Neutron 的自定义内核模块配置¶
Neutron 可能需要特定的内核模块才能实现某些功能。虽然 Ansible 角色中有预定义的默认模块，但用户可以根据需要添加自定义模块的灵活性。
要为 Neutron 添加自定义内核模块，请修改 /etc/kolla/globals.yml 中的配置
neutron_modules_extra:
- name: 'nf_conntrack_tftp'
params: 'hashsize=4096'
在本例中
neutron_modules_extra: 允许用户指定其他模块及其关联的参数。给定的配置调整了 nf_conntrack_tftp 模块的 hashsize 参数。
在外部系统中（交换机）的 SSH 身份验证
Kolla 中有一个功能，允许克服在 ml2/ovs 中重新启动 neutron-l3-agent 和 neutron-dhcp-agent 或在 ml2/ovn 中重新启动 neutron-ovn-metadata-agent 时中断数据平面连接、dhcp 和元数据服务的问题。
要启用它，请修改 /etc/kolla/globals.yml 中的配置
neutron_agents_wrappers: "yes"
有关更多详细信息，请参阅 bug 1891469
