openstack
/
neutron
Code Issues Proposed changes

[Doc][L3][QoS] Enable floating IP qos 

This patch adds documents for floating IP qos feature.
Both neutron server side and L3 agent side settings
will be introduced in this patch.

Partially-Implements blueprint: floating-ip-rate-limit

Change-Id: Ia1f84a5d436220fd22ee1e739242db707d75cf85
This commit is contained in:
LIU Yulong 2017-12-02 11:13:44 +08:00
parent 0444c21d41
commit 8f6dd26cbe
2 changed files with 183 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
doc/source/admin/config-qos.rst
View File

@ -32,7 +32,7 @@ Supported QoS rule types
QoS supported rule types are now available as ``VALID_RULE_TYPES`` in `QoS rule types
<https://git.openstack.org/cgit/openstack/neutron-lib/tree/neutron_lib/services/qos/constants.py>`_:
* bandwidth_limit: Bandwidth limitations on networks or ports.
* bandwidth_limit: Bandwidth limitations on networks, ports or floating IPs.
* dscp_marking: Marking network traffic with a DSCP value.
@ -102,6 +102,14 @@ On the controller nodes:
section in ``/etc/neutron/neutron.conf`` (``message_queue`` is the
default).
#. Optionally, in order to enable the floating IP QoS extension ``qos-fip``,
set the ``service_plugins`` option in ``/etc/neutron/neutron.conf`` to
include both ``router`` and ``qos``. For example:
.. code-block:: none
service_plugins = router, qos
#. In ``/etc/neutron/plugins/ml2/ml2_conf.ini``, add ``qos`` to
``extension_drivers`` in the ``[ml2]`` section. For example:
@ -136,6 +144,16 @@ On the network and compute nodes:
[agent]
extensions = qos
#. Optionally, in order to enable QoS for floating IPs, set the ``extensions``
option in the ``[agent]`` section of ``/etc/neutron/l3_agent.ini`` to
include ``fip_qos``. If ``dvr`` is enabled, this has to be done for all the
L3 agents. For example:
.. code-block:: ini
[agent]
extensions = fip_qos
#. As rate limit doesn't work on Open vSwitch's ``internal`` ports,
optionally, as a workaround, to make QoS bandwidth limit work on
router's gateway ports, set ``ovs_use_veth`` to ``True`` in ``DEFAULT``
@ -341,6 +359,119 @@ network, or initially create the network attached to the policy.
value is too high, too few packets could be limited and achieved bandwidth
limit would be higher than expected.
The created policy can be associated with an existing floating IP.
In order to do this, user extracts the floating IP id to be associated to
the already created policy. In the next example, we will assign the
``bw-limiter`` policy to the floating IP address ``172.16.100.18``.
.. code-block:: console
$ openstack floating ip list
+--------------------------------------+---------------------+------------------+------+-----+
| ID | Floating IP Address | Fixed IP Address | Port | ... |
+--------------------------------------+---------------------+------------------+------+-----+
| 1163d127-6df3-44bb-b69c-c0e916303eb3 | 172.16.100.9 | None | None | ... |
| d0ed7491-3eb7-4c4f-a0f0-df04f10a067c | 172.16.100.18 | None | None | ... |
| f5a9ed48-2e9f-411c-8787-2b6ecd640090 | 172.16.100.2 | None | None | ... |
+--------------------------------------+---------------------+------------------+------+-----+
.. code-block:: console
$ openstack floating ip set --qos-policy bw-limiter d0ed7491-3eb7-4c4f-a0f0-df04f10a067c
In order to detach a floating IP from the QoS policy, simply update the
floating IP configuration.
.. code-block:: console
$ openstack floating ip set --no-qos-policy d0ed7491-3eb7-4c4f-a0f0-df04f10a067c
Or use the ``unset`` action.
.. code-block:: console
$ openstack floating ip unset --qos-policy d0ed7491-3eb7-4c4f-a0f0-df04f10a067c
Floating IPs can be created with a policy attached to them too.
.. code-block:: console
$ openstack floating ip create --qos-policy bw-limiter public
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| created_at | 2017-12-06T02:12:09Z |
| description | |
| fixed_ip_address | None |
| floating_ip_address | 172.16.100.12 |
| floating_network_id | 4065eb05-cccb-4048-988c-e8c5480a746f |
| id | 6a0efeef-462b-4312-b4ad-627cde8a20e6 |
| name | 172.16.100.12 |
| port_id | None |
| project_id | 916e39e8be52433ba040da3a3a6d0847 |
| qos_policy_id | 5df855e9-a833-49a3-9c82-c0839a5f103f |
| revision_number | 1 |
| router_id | None |
| status | DOWN |
| updated_at | 2017-12-06T02:12:09Z |
+---------------------+--------------------------------------+
The QoS bandwidth limit rules attached to a floating IP will become
active when you associate the latter with a port. For example, to associate
the previously created floating IP ``172.16.100.12`` to the instance port with
fixed IP ``192.168.222.5``:
.. code-block:: console
$ openstack port show a7f25e73-4288-4a16-93b9-b71e6fd00862
+-----------------------+--------------------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------------------+
| admin_state_up | UP |
| ... | ... |
| device_id | 69c03d70-53e8-4030-9c02-675c47f0b06b |
| device_owner | compute:nova |
| dns_assignment | None |
| dns_name | None |
| extra_dhcp_opts | |
| fixed_ips | ip_address='192.168.222.5', subnet_id='...' |
| id | a7f25e73-4288-4a16-93b9-b71e6fd00862 |
| ip_address | None |
| mac_address | fa:16:3e:b5:1a:cc |
| name | |
| network_id | ea602456-3ea8-4989-8981-add6182b4ceb |
| option_name | None |
| option_value | None |
| port_security_enabled | False |
| project_id | 916e39e8be52433ba040da3a3a6d0847 |
| qos_policy_id | None |
| revision_number | 6 |
| security_group_ids | 77436c73-3a29-42a7-b544-d47f4ea96d54 |
| status | ACTIVE |
| subnet_id | None |
| tags | |
| trunk_details | None |
| updated_at | 2017-12-05T15:48:54Z |
+-----------------------+--------------------------------------------------+
.. code-block:: console
$ openstack floating ip set --port a7f25e73-4288-4a16-93b9-b71e6fd00862 \
0eeb1f8a-de96-4cd9-a0f6-3f535c409558
.. note::
For now, the L3 agent floating IP QoS extension only uses
``bandwidth_limit`` rules. Other rule types (like DSCP marking) will be
silently ignored for floating IPs. A QoS policy that does not contain any
``bandwidth_limit`` rules will have no effect when attached to a
floating IP.
If floating IP is bound to a port, and both have binding QoS bandwidth
rules, the L3 agent floating IP QoS extension ignores the behavior of
the port QoS, and installs the rules on the appropriate device in the
router namespace.
Each project can have at most one default QoS policy, although it is not
mandatory. If a default QoS policy is defined, all new networks created within
this project will have this policy assigned, as long as no other QoS policy is

64
doc/source/contributor/internals/quality_of_service.rst
View File

@ -41,6 +41,10 @@ Service side design
base extension + API controller definition. Note that rules are subattributes
of policies and hence embedded into their URIs.
* neutron.extensions.qos_fip:
base extension + API controller definition. Adds qos_policy_id to floating
IP, enabling users to set/update the binding QoS policy of a floating IP.
* neutron.services.qos.qos_plugin:
QoSPlugin, service plugin that implements 'qos' extension, receiving and
handling API calls to create/modify policies and rules.
@ -113,7 +117,7 @@ Database models
~~~~~~~~~~~~~~~
QoS design defines the following two conceptual resources to apply QoS rules
for a port or a network:
for a port, a network or a floating IP:
* QoS policy
* QoS rule (type specific)
@ -138,8 +142,8 @@ unset, no change to existing networks will be made.
From database point of view, following objects are defined in schema:
* QosPolicy: directly maps to the conceptual policy resource.
* QosNetworkPolicyBinding, QosPortPolicyBinding: defines attachment between a
Neutron resource and a QoS policy.
* QosNetworkPolicyBinding, QosPortPolicyBinding, QosFIPPolicyBinding:
define attachment between a Neutron resource and a QoS policy.
* QosPolicyDefault: defines a default QoS policy per project.
* QosBandwidthLimitRule: defines the rule to limit the maximum egress
bandwidth.
@ -180,12 +184,12 @@ Those are defined in:
For QosPolicy neutron object, the following public methods were implemented:
* get_network_policy/get_port_policy: returns a policy object that is attached
to the corresponding Neutron resource.
* attach_network/attach_port: attach a policy to the corresponding Neutron
resource.
* detach_network/detach_port: detach a policy from the corresponding Neutron
resource.
* get_network_policy/get_port_policy/get_fip_policy: returns a policy object
that is attached to the corresponding Neutron resource.
* attach_network/attach_port/attach_floatingip: attach a policy to the
corresponding Neutron resource.
* detach_network/detach_port/detach_floatingip: detach a policy from the
corresponding Neutron resource.
In addition to the fields that belong to QoS policy database object itself,
synthetic fields were added to the object that represent lists of rules that
@ -239,13 +243,20 @@ The flow of updates is as follows:
policy (with all the rules included) from the server. After that, the QoS
extension applies the rules by calling into QoS driver that corresponds to
the agent.
* For floating IPs, a ``fip_qos`` L3 agent extension was implemented. This
extension receives and processes router updates. For each update, it goes
over each floating IP associated to the router. If a floating IP has a QoS
policy associated to it, the extension uses ResourcesPullRpcApi to fetch
the policy details from the Neutron server. If the policy includes
``bandwidth_limit`` rules, the extension applies them to the appropriate
router device by directly calling the l3_tc_lib.
* on existing QoS policy update (it includes any policy or its rules change),
server pushes the new policy object state through ResourcesPushRpcApi
interface. The interface fans out the serialized (dehydrated) object to any
agent that is listening for QoS policy updates. If an agent have seen the
policy before (it is attached to one of the ports it maintains), then it goes
with applying the updates to the port. Otherwise, the agent silently ignores
the update.
policy before (it is attached to one of the ports/floating IPs it maintains),
then it goes with applying the updates to the port/floating IP. Otherwise,
the agent silently ignores the update.
Agent side design
@ -262,6 +273,14 @@ Reference agents implement QoS functionality using an `L2 agent extension
networking technology, while the QoS extension handles operations that are
common to all agents.
For L3 agent:
* neutron.agent.l3.extensions.fip_qos
defines QoS L3 agent extension. It implements the L3 agent side of floating
IP rate limit. For all routers, if floating IP has QoS ``bandwidth_limit``
rules, the corresponding TC filters will be added to the appropriate router
device, depending on the router type.
Agent backends
~~~~~~~~~~~~~~
@ -399,6 +418,10 @@ neutron.services.qos.drivers.openvswitch.driver register method for an example.
will just act as an interface to bypass the received QoS API request and help with
database persistence for the API operations.
.. note::
L3 agent ``fip_qos`` extension does not have a driver implementation,
it directly uses the ``l3_tc_lib`` for all types of routers.
Configuration
-------------
@ -407,12 +430,17 @@ To enable the service, the following steps should be followed:
On server side:
* enable qos service in service_plugins;
* for ml2, add 'qos' to extension_drivers in [ml2] section.
* for ml2, add 'qos' to extension_drivers in [ml2] section;
* for L3 floating IP QoS, add 'qos' and 'router' to service_plugins.
On agent side (OVS):
* add 'qos' to extensions in [agent] section.
On L3 agent side:
* For for floating IPs QoS support, add 'fip_qos' to extensions in [agent] section.
Testing strategy
----------------
@ -455,6 +483,16 @@ New functional tests for tc_lib to set bandwidth limits on ports are in:
* neutron.tests.functional.agent.linux.test_tc_lib
New functional tests for test_l3_tc_lib to set TC filters on router floating
IP related device are covered in:
* neutron.tests.functional.agent.linux.test_l3_tc_lib
New functional tests for L3 agent floating IP rate limit:
* neutron.tests.functional.agent.l3.extensions.test_fip_qos_extension
API tests
~~~~~~~~~