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:
parent
9462d10a7b
commit
0c8ccb5191
|
@ -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
|
Loading…
Reference in New Issue