Merge "[Doc][L3][QoS] Enable floating IP qos"
This commit is contained in:
commit
01c99152f9
doc/source
@ -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``
|
||||
@ -371,6 +389,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
|
||||
|
@ -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
|
||||
~~~~~~~~~
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user