openstack
/
neutron-specs
Code Issues Proposed changes
neutron-specs/specs/2023.1/strict-minimum-bandwidth-tu...

6.6 KiB
Raw Blame History

Strict minimum bandwidth support for tunnelled networks

Launchpad bug: https://bugs.launchpad.net/neutron/+bug/1991965

The aim of the RFE is to improve the previous implemented RFE Strict minimum bandwidth support1.

Problem Description

Since2, Neutron has the ability to model the available bandwidth of the physical interfaces (ingress and egress) connected to the physical networks (flat and VLAN networks). This information is collected by Placement and used to spawn virtual machines with network ports on compute nodes with enough bandwidth. That guarantees a minimum port throughput.

This feature is currently implemented in three backends: ML2/SR-IOV, ML2/OVS and ML2/OVN. The full list of related patches can be reviewed at3.

However, most of the current deployments do not use physical backed networks (flat or VLAN) but overlay networs (VXLAN and Geneve). Of course those deployments use ML2/OVS and ML2/OVN; ML2/SR-IOV does not support tunnelled networks. That leads to an existing gap in the currently implemented feature: there is no way to model tunnelled networks.

Proposed Change

This RFE proposes a way to model the available bandwidth for tunnelled networks in compute nodes. This implementation will be limited to ML2/OVS and ML2/OVN backends.

The referred backends handle the overlay traffic sending and receiving this traffic from a host interface, that acts as a VTEP4. This host interface is identified by an IP address, known as "local_ip" in the ML2 plugin configuration file5.

This RFE proposes to use the same configuration options provided in6, adding a static string constant to define a tunnelled network that could be configurable by the administrator. The default value will be "rp_tunnelled". For example:

[ovs]
resource_provider_bandwidths = br0:EGRESS:INGRESS,rp_tunnelled:EGRESS:INGRESS
resource_provider_hypervisors = br0:compute2,rp_tunnelled:compute1

This new string constant cannot be used as a physical bridge name. To avoid any possible clash, there will be a new check when parsing the physical network bridge mappings.

A host with ML2/OVN backend with a physical network (mapped to the physical bridge "br-ex") and a tunnelled network will report the following resource provider tree:

$ openstack resource provider list
+--------------------------------------+------------------------------------------+------------+--------------------------------------+--------------------------------------+
| uuid                                 | name                                     | generation | root_provider_uuid                   | parent_provider_uuid                 |
+--------------------------------------+------------------------------------------+------------+--------------------------------------+--------------------------------------+
| 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | u20ovn                                   |         10 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | None                                 |
| cb101b60-527b-5264-8e7f-213c7b88e9e1 | u20ovn:OVN Controller agent              |          1 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 |
| 521f53a6-c8c0-583c-98da-7a47f39ff887 | u20ovn:OVN Controller agent:br-ex        |         20 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | cb101b60-527b-5264-8e7f-213c7b88e9e1 |
| dfdbf43f-f60b-577c-bae8-3dcea448c735 | u20ovn:OVN Controller agent:rp_tunnelled |          6 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | cb101b60-527b-5264-8e7f-213c7b88e9e1 |
+--------------------------------------+------------------------------------------+------------+--------------------------------------+--------------------------------------+

A new static trait is added to this resource provider: "CUSTOM_TUNNELLED_NETWORKS". This is what identify that this resource provider is for tunnelled networks. E.g.:

$ openstack resource provider trait list $rp_tun
+----------------------------------+
| name                             |
+----------------------------------+
| CUSTOM_VNIC_TYPE_NORMAL          |
| CUSTOM_VNIC_TYPE_DIRECT          |
| CUSTOM_VNIC_TYPE_DIRECT_PHYSICAL |
| CUSTOM_VNIC_TYPE_MACVTAP         |
| CUSTOM_VNIC_TYPE_VDPA            |
| CUSTOM_VNIC_TYPE_REMOTE_MANAGED  |
| CUSTOM_VNIC_TYPE_BAREMETAL       |
| CUSTOM_TUNNELLED_NETWORKS        |
+----------------------------------+

REST API Impact

This RFE does not introduce any API change.

Data Model Impact

This RFE does not introduce any model change.

Security Impact

None.

Performance Impact

None.

Other Impact

Currently there is no support for minimum bandwidth QoS rules for tunnelled networks, neither in Placement nor in the ML2 backend (OVS, OVN). However, it is possible to have ports with those type of QoS rules (maybe inherited from the network QoS policy). With this feature, the minimum bandwidth QoS rules won't be discarded, like now, when the port resource request is built (that is the Placement blob to request a specific bandwidth in a specific network). A new check will be added to inform about those ports located on tunnelled networks with minimum bandwidth QoS rules.

Implementation

Assignee(s)

Primary assignees:

Rodolfo Alonso Hernandez <ralonsoh@redhat.com> (IRC: ralonsoh)

Work Items

  • ML2 plugin update.
  • Documentation.
  • Tests and CI related changes.

Testing

  • Unit/functional tests.
  • Fullstack tests: increase the current fullstack tests coverage to check this new feature.
  • Tempest tests: create a VM with a minimum bandwidth port, update the QoS policy and minimum bandwidth rule limits, unset the QoS policy, migrate the VM.

Documentation Impact

User Documentation

Ammend the "Strict minimum bandwidth support"7 documentation, adding this new improvement.

References

  1. [RFE] Strict minimum bandwidth support (egress) https://bugs.launchpad.net/neutron/+bug/1578989↩︎

  2. [RFE] Strict minimum bandwidth support (egress) https://bugs.launchpad.net/neutron/+bug/1578989↩︎

  3. https://review.opendev.org/q/%25231578989↩︎

  4. https://networklessons.com/cisco/ccnp-encor-350-401/introduction-to-virtual-extensible-lan-vxlan↩︎

  5. https://github.com/openstack/neutron/blob/599c81767ea7aa3bde7a64ff57b20f34fb314548/neutron/conf/plugins/ml2/drivers/ovs_conf.py#L44-L50↩︎

  6. [RFE] Strict minimum bandwidth support (egress) https://bugs.launchpad.net/neutron/+bug/1578989↩︎

  7. [RFE] Strict minimum bandwidth support (egress) https://bugs.launchpad.net/neutron/+bug/1578989↩︎