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
c9a9703feb
|
@ -0,0 +1,178 @@
|
|||
..
|
||||
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 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" [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