Strict minimum bandwidth support for tunnelled networks

The aim of the RFE is to improve the previous implemented RFE
Strict minimum bandwidth support [1].

[1]https://bugs.launchpad.net/neutron/+bug/1578989

Change-Id: I21a1d9bee1d195f704a518ea3dbd3f2b1e35a357
Related-Bug: #1991965
This commit is contained in:
Rodolfo Alonso Hernandez 2022-10-03 10:02:30 +02:00
parent 9462d10a7b
commit 0c8ccb5191
1 changed files with 173 additions and 0 deletions

View File

@ -0,0 +1,173 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=======================================================
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 support [1]_.
Problem Description
===================
Since [1]_, 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 at [2]_.
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 VTEP [3]_. This host interface
is identified by an IP address, known as "local_ip" in the ML2 plugin
configuration file [4]_.
This RFE proposes to use the same configuration options provided in [1]_,
adding a static string constant to define a tunnelled network, "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.
* Tempest tests.
Documentation Impact
====================
User Documentation
------------------
Ammend the "Strict minimum bandwidth support" [1]_ documentation, adding this
new improvement.
References
==========
.. [1] [RFE] Strict minimum bandwidth support (egress)
https://bugs.launchpad.net/neutron/+bug/1578989
.. [2] https://review.opendev.org/q/%25231578989
.. [3] https://networklessons.com/cisco/ccnp-encor-350-401/introduction-to-virtual-extensible-lan-vxlan
.. [4] https://github.com/openstack/neutron/blob/599c81767ea7aa3bde7a64ff57b20f34fb314548/neutron/conf/plugins/ml2/drivers/ovs_conf.py#L44-L50