Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 7. Using Quality of Service (QoS) policies to manage data traffic


You can offer varying service levels for VM instances by using quality of service (QoS) policies to apply rate limits to egress and ingress traffic in Red Hat OpenStack Services on OpenShift (RHOSO) environments.

You can apply QoS policies to individual ports, or apply QoS policies to a project network, where ports with no specific policy attached inherit the policy.

Note

Internal network owned ports, such as DHCP and internal router ports, are excluded from network policy application.

You can apply, modify, or remove QoS policies dynamically. However, for guaranteed minimum bandwidth QoS policies, you can only apply modifications when there are no instances that use any of the ports the policy is assigned to.

7.1. QoS rules

You can configure the following rule types to define a quality of service (QoS) policy in the Red Hat OpenStack Services on OpenShift (RHOSO) Networking service (neutron):

Minimum bandwidth (minimum_bandwidth)
Provides minimum bandwidth constraints on certain types of traffic. If implemented, best efforts are made to provide no less than the specified bandwidth to each port on which the rule is applied.
Bandwidth limit (bandwidth_limit)
Provides bandwidth limitations on networks, ports, floating IPs (FIPs), and router gateway IPs. If implemented, any traffic that exceeds the specified rate is dropped.
DSCP marking (dscp_marking)
Marks network traffic with a differentiated services code point (DSCP) value.
Minimum packet rate (minimum-packet-rate)
Provides minimum rate of packet transmission constraints on certain types of traffic. If implemented, best efforts are made to provide no less than the specified rate of packet transmission to each port on which the rule is applied. Currently, only placement enforcement is supported.

QoS policies can be enforced in various contexts, including virtual machine instance placements, floating IP assignments, and gateway IP assignments.

Depending on the enforcement context and on the mechanism driver you use, a QoS rule affects egress traffic (upload from instance), ingress traffic (download to instance), or both.

Note

In ML2/OVN deployments, you can enable minimum bandwidth and bandwidth limit egress policies for hardware offloaded ports. You cannot enable ingress policies for hardware offloaded ports. For more information, see Section 7.2, “Configuring the Networking service for QoS policies”.

Expand
Table 7.1. Supported traffic direction by driver (all QoS rule types)

Rule [1]

Supported traffic direction by mechanism driver

ML2/SR-IOV

ML2/OVN

Minimum bandwidth

Egress only

Egress only

Bandwidth limit

Egress only [2]

Egress and ingress

DSCP marking

N/A

Egress only [3]

[1] RHOSO does not support QoS for trunk ports.

[2] The mechanism drivers ignore the max-burst-kbits parameter because they do not support it.

[3] ML2/OVN does not support DSCP marking on tunneled protocols.

Expand
Table 7.2. Supported traffic direction by driver for placement reporting and scheduling (minimum bandwidth only)

Enforcement type

Supported traffic by direction mechanism driver

ML2/SR-IOV

ML2/OVN

Placement

Egress and ingress

Technology preview [1]

[1] See OSPRH-507.

Expand
Table 7.3. Supported traffic direction by driver for enforcement types (bandwidth limit only)

Enforcement type

Supported traffic direction by mechanism driver

ML2/OVN

Floating IP

Egress and ingress

Gateway IP

Egress and ingress

7.2. Configuring the Networking service for QoS policies

The quality of service feature in the Red Hat OpenStack Services on OpenShift (RHOSO) Networking service (neutron) is provided through the qos service plug-in. With the ML2/OVN mechanism driver, qos is loaded by default. However, this is not true for ML2/SR-IOV.

When using the qos service plug-in with the ML2/SR-IOV mechanism driver, you must also load the qos extension on their respective agents.

The following list summarizes the tasks that you must perform to configure the Networking service for QoS. The task details follow this list:

  • For all types of QoS policies:

    • Add the qos service plug-in.
    • Add qos extension for the agents (SR-IOV only).
  • In ML2/OVN deployments, you can enable minimum bandwidth and bandwidth limit egress policies for hardware offloaded ports. You cannot enable ingress policies for hardware offloaded ports.
  • Additional tasks for scheduling VM instances using minimum bandwidth policies only:

    • Specify the hypervisor name if it differs from the name that the Compute service (nova) uses.
    • Configure the resource provider ingress and egress bandwidths for the relevant agents on each Compute node.
    • (Optional) Mark vnic_types as not supported.
  • Additional task for DSCP marking policies:

    • Enable edpm_ovn_encap_tos. By default, edpm_ovn_encap_tos is disabled.

Prerequisites

  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.

Procedure

  1. If you are using the ML2/SR-IOV mechanism driver, you must enable the qos agent extension on the Compute nodes, also referred to as the RHOSO data plane.

    For more information, see Configuring the Networking service for QoS policies for SR-IOV.

  2. Add the required QoS configuration. Place the configuration in the edpm_network_config_template under ansibleVars:

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
      name: my-data-plane-node-set
    spec:
      ...
      nodeTemplate:
        ...
        ansible:
          ansibleVars:
            edpm_network_config_template: |
              ---
              OvnHardwareOffloadedQos: true
              ...
    Copy to Clipboard Toggle word wrap
  3. If you want to create DSCP marking policies, add edpm_ovn_encap_tos: '1' under ansibleVars:

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
      name: my-data-plane-node-set
    spec:
      ...
      nodeTemplate:
        ...
        ansible:
          ansibleVars:
            edpm_network_config_template: |
              ---
              OvnHardwareOffloadedQos: true
            edpm_ovn_encap_tos: 1
              ...
    Copy to Clipboard Toggle word wrap

    When edpm_ovn_encap_tos is enabled (has a value of 1), the Networking service copies the DSCP value of the inner header to the outer header. The default is 0.

  4. Save the OpenStackDataPlaneNodeSet CR definition file.
  5. Apply the updated OpenStackDataPlaneNodeSet CR configuration:

    $ oc apply -f my_data_plane_node_set.yaml
    Copy to Clipboard Toggle word wrap
  6. Verify that the data plane resource has been updated:

    $ oc get openstackdataplanenodeset
    Copy to Clipboard Toggle word wrap
    Sample output
    NAME                     STATUS MESSAGE
    my-data-plane-node-set   False  Deployment not started
    Copy to Clipboard Toggle word wrap
  7. Create a file on your workstation to define the OpenStackDataPlaneDeployment CR, for example, my_data_plane_deploy.yaml:

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneDeployment
    metadata:
      name: my-data-plane-deploy
    Copy to Clipboard Toggle word wrap
    Tip

    Give the definition file and the OpenStackDataPlaneDeployment CR a unique and descriptive name that indicates the purpose of the modified node set.

  8. Add the OpenStackDataPlaneNodeSet CR that you modified:

    spec:
      nodeSets:
        - my-data-plane-node-set
    Copy to Clipboard Toggle word wrap
  9. Save the OpenStackDataPlaneDeployment CR deployment file.
  10. Deploy the modified OpenStackDataPlaneNodeSet CR:

    $ oc create -f my_data_plane_deploy.yaml -n openstack
    Copy to Clipboard Toggle word wrap

    You can view the Ansible logs while the deployment executes:

    $ oc get pod -l app=openstackansibleee -n openstack -w
    
    $ oc logs -l app=openstackansibleee -n openstack -f \
    --max-log-requests 10
    Copy to Clipboard Toggle word wrap
  11. Verify that the modified OpenStackDataPlaneNodeSet CR is deployed:

    Example
    $ oc get openstackdataplanedeployment -n openstack
    Copy to Clipboard Toggle word wrap
    Sample output
    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete
    Copy to Clipboard Toggle word wrap
  12. Repeat the oc get command until you see the NodeSet Ready message:

    Example
    $ oc get openstackdataplanenodeset -n openstack
    Copy to Clipboard Toggle word wrap
    Sample output
    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready
    Copy to Clipboard Toggle word wrap

    For information on the meaning of the returned status, see Data plane conditions and states in the Deploying Red Hat OpenStack Services on OpenShift guide.

Verification

  • Confirm that the qos service plug-in is loaded:

    $ openstack network qos policy list
    Copy to Clipboard Toggle word wrap

    If the qos service plug-in is loaded, then you do not receive a ResourceNotFound error.

7.3. Configuring the Networking service for QoS policies for SR-IOV

The quality of service feature in the Red Hat OpenStack Services on OpenShift (RHOSO) Networking service (neutron) is provided through the qos service plug-in. If your Networking service ML2 mechanism driver is SR-IOV, then you must also load the qos extension driver for the NIC switch agent, neutron-sriov-nic-agent, which runs on the Compute nodes, also referred to as the RHOSO data plane.

Prerequisites

  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.

Procedure

  1. Open the OpenStackDataPlaneNodeSet CR definition file for the node set you want to update, for example, my_data_plane_node_set.yaml.
  2. Add the required QoS configuration, NeutronSriovAgentExtensions: "qos".

    Place the configuration in the edpm_network_config_template under ansibleVars:

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
      name: my-data-plane-node-set
    spec:
      ...
      nodeTemplate:
        ...
        ansible:
          ansibleVars:
            edpm_network_config_template: |
              ---
              NeutronSriovAgentExtensions: "qos"
              ...
    Copy to Clipboard Toggle word wrap
  3. Save the OpenStackDataPlaneNodeSet CR definition file.
  4. Apply the updated OpenStackDataPlaneNodeSet CR configuration:

    $ oc apply -f my_data_plane_node_set.yaml
    Copy to Clipboard Toggle word wrap
  5. Verify that the data plane resource has been updated:

    $ oc get openstackdataplanenodeset
    Copy to Clipboard Toggle word wrap
    Sample output
    NAME                     STATUS MESSAGE
    my-data-plane-node-set   False  Deployment not started
    Copy to Clipboard Toggle word wrap
  6. Create a file on your workstation to define the OpenStackDataPlaneDeployment CR, for example, my_data_plane_deploy.yaml:

    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneDeployment
    metadata:
      name: my-data-plane-deploy
    Copy to Clipboard Toggle word wrap
    Tip

    Give the definition file and the OpenStackDataPlaneDeployment CR a unique and descriptive name that indicates the purpose of the modified node set.

  7. Add the OpenStackDataPlaneNodeSet CR that you modified:

    spec:
      nodeSets:
        - my-data-plane-node-set
    Copy to Clipboard Toggle word wrap
  8. Save the OpenStackDataPlaneDeployment CR deployment file.
  9. Deploy the modified OpenStackDataPlaneNodeSet CR:

    $ oc create -f my_data_plane_deploy.yaml -n openstack
    Copy to Clipboard Toggle word wrap

    You can view the Ansible logs while the deployment executes:

    $ oc get pod -l app=openstackansibleee -n openstack -w
    
    $ oc logs -l app=openstackansibleee -n openstack -f \
    --max-log-requests 10
    Copy to Clipboard Toggle word wrap
  10. Verify that the modified OpenStackDataPlaneNodeSet CR is deployed:

    Example
    $ oc get openstackdataplanedeployment -n openstack
    Copy to Clipboard Toggle word wrap
    Sample output
    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete
    Copy to Clipboard Toggle word wrap
  11. Repeat the oc get command until you see the NodeSet Ready message:

    Example
    $ oc get openstackdataplanenodeset -n openstack
    Copy to Clipboard Toggle word wrap
    Sample output
    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready
    Copy to Clipboard Toggle word wrap

    For information on the meaning of the returned status, see Data plane conditions and states in the Deploying Red Hat OpenStack Services on OpenShift guide.

Verification

Confirm that the NIC switch agent, neutron-sriov-nic-agent, has loaded the qos extension.

  1. Obtain the UUID for the NIC switch agent:

    $ openstack network agent list
    Copy to Clipboard Toggle word wrap
  2. With the neutron-sriov-nic-agent UUID, run the following command:

    $ openstack network agent show <uuid>
    Copy to Clipboard Toggle word wrap
    Example
    $ openstack network agent show 8676ccb3-1de0-4ca6-8fb7-b814015d9e5f \
    --max-width 70
    Copy to Clipboard Toggle word wrap
    Sample output

    You should see an agent object with a field called configuration. When the qos extension is loaded, the extensions field should contain qos in its list.

    -------------------------------------------------------------------+
    | Field             | Value                                          |
    -------------------------------------------------------------------+
    | admin_state_up    | UP                                             |
    | agent_type        | NIC Switch agent                               |
    | alive             | :-)                                            |
    | availability_zone | None                                           |
    | binary            | neutron-sriov-nic-agent                        |
    | configuration     | {device_mappings: {}, devices: 0, extensi | | | ons: [qos], resource_provider_bandwidths: |
    |                   | {}, resource_provider_hypervisors: {}, reso | | | urce_provider_inventory_defaults: {allocatio | | | n_ratio: 1.0, min_unit: 1, step_size: 1,  |
    |                   | reserved: 0}}                                |
    | created_at        | 2024-08-08 08:22:57                            |
    | description       | None                                           |
    | ha_state          | None                                           |
    | host              | edpm-compute-0.ctlplane.example.com            |
    | id                | 8676ccb3-1de0-4ca6-8fb7-b814015d9e5f           |
    | last_heartbeat_at | 2024-08-08 08:24:27                            |
    | resources_synced  | None                                           |
    | started_at        | 2024-08-08 08:22:57                            |
    | topic             | N/A                                            |
    -------------------------------------------------------------------+
    Copy to Clipboard Toggle word wrap
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat