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.
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 Link kopierenLink in die Zwischenablage kopiert!
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.
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”.
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.
Enforcement type | Supported traffic by direction mechanism driver | |
ML2/SR-IOV | ML2/OVN | |
Placement | Egress and ingress | Technology preview [1] |
[1] See OSPRH-507.
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 Link kopierenLink in die Zwischenablage kopiert!
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).
-
Add the
- 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.
-
Enable
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
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.
Add the required QoS configuration. Place the configuration in the
edpm_network_config_template
underansibleVars
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you want to create DSCP marking policies, add
edpm_ovn_encap_tos: '1'
underansibleVars
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow When
edpm_ovn_encap_tos
is enabled (has a value of1
), the Networking service copies the DSCP value of the inner header to the outer header. The default is0
.-
Save the
OpenStackDataPlaneNodeSet
CR definition file. Apply the updated
OpenStackDataPlaneNodeSet
CR configuration:oc apply -f my_data_plane_node_set.yaml
$ oc apply -f my_data_plane_node_set.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the data plane resource has been updated:
oc get openstackdataplanenodeset
$ oc get openstackdataplanenodeset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
NAME STATUS MESSAGE my-data-plane-node-set False Deployment not started
NAME STATUS MESSAGE my-data-plane-node-set False Deployment not started
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneDeployment metadata: name: my-data-plane-deploy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipGive the definition file and the
OpenStackDataPlaneDeployment
CR a unique and descriptive name that indicates the purpose of the modified node set.Add the
OpenStackDataPlaneNodeSet
CR that you modified:spec: nodeSets: - my-data-plane-node-set
spec: nodeSets: - my-data-plane-node-set
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save the
OpenStackDataPlaneDeployment
CR deployment file. Deploy the modified
OpenStackDataPlaneNodeSet
CR:oc create -f my_data_plane_deploy.yaml -n openstack
$ oc create -f my_data_plane_deploy.yaml -n openstack
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ oc get pod -l app=openstackansibleee -n openstack -w $ oc logs -l app=openstackansibleee -n openstack -f \ --max-log-requests 10
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the modified
OpenStackDataPlaneNodeSet
CR is deployed:- Example
oc get openstackdataplanedeployment -n openstack
$ oc get openstackdataplanedeployment -n openstack
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
NAME STATUS MESSAGE my-data-plane-node-set True Setup Complete
NAME STATUS MESSAGE my-data-plane-node-set True Setup Complete
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Repeat the
oc get
command until you see theNodeSet Ready
message:- Example
oc get openstackdataplanenodeset -n openstack
$ oc get openstackdataplanenodeset -n openstack
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
NAME STATUS MESSAGE my-data-plane-node-set True NodeSet Ready
NAME STATUS MESSAGE my-data-plane-node-set True NodeSet Ready
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ openstack network qos policy list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the
qos
service plug-in is loaded, then you do not receive aResourceNotFound
error.
7.3. Configuring the Networking service for QoS policies for SR-IOV Link kopierenLink in die Zwischenablage kopiert!
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
-
Open the
OpenStackDataPlaneNodeSet
CR definition file for the node set you want to update, for example,my_data_plane_node_set.yaml
. Add the required QoS configuration,
NeutronSriovAgentExtensions: "qos"
.Place the configuration in the
edpm_network_config_template
underansibleVars
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save the
OpenStackDataPlaneNodeSet
CR definition file. Apply the updated
OpenStackDataPlaneNodeSet
CR configuration:oc apply -f my_data_plane_node_set.yaml
$ oc apply -f my_data_plane_node_set.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the data plane resource has been updated:
oc get openstackdataplanenodeset
$ oc get openstackdataplanenodeset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
NAME STATUS MESSAGE my-data-plane-node-set False Deployment not started
NAME STATUS MESSAGE my-data-plane-node-set False Deployment not started
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneDeployment metadata: name: my-data-plane-deploy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipGive the definition file and the
OpenStackDataPlaneDeployment
CR a unique and descriptive name that indicates the purpose of the modified node set.Add the
OpenStackDataPlaneNodeSet
CR that you modified:spec: nodeSets: - my-data-plane-node-set
spec: nodeSets: - my-data-plane-node-set
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save the
OpenStackDataPlaneDeployment
CR deployment file. Deploy the modified
OpenStackDataPlaneNodeSet
CR:oc create -f my_data_plane_deploy.yaml -n openstack
$ oc create -f my_data_plane_deploy.yaml -n openstack
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ oc get pod -l app=openstackansibleee -n openstack -w $ oc logs -l app=openstackansibleee -n openstack -f \ --max-log-requests 10
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the modified
OpenStackDataPlaneNodeSet
CR is deployed:- Example
oc get openstackdataplanedeployment -n openstack
$ oc get openstackdataplanedeployment -n openstack
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
NAME STATUS MESSAGE my-data-plane-node-set True Setup Complete
NAME STATUS MESSAGE my-data-plane-node-set True Setup Complete
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Repeat the
oc get
command until you see theNodeSet Ready
message:- Example
oc get openstackdataplanenodeset -n openstack
$ oc get openstackdataplanenodeset -n openstack
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
NAME STATUS MESSAGE my-data-plane-node-set True NodeSet Ready
NAME STATUS MESSAGE my-data-plane-node-set True NodeSet Ready
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
Obtain the UUID for the NIC switch agent:
openstack network agent list
$ openstack network agent list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow With the
neutron-sriov-nic-agent
UUID, run the following command:openstack network agent show <uuid>
$ openstack network agent show <uuid>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Example
openstack network agent show 8676ccb3-1de0-4ca6-8fb7-b814015d9e5f \ --max-width 70
$ openstack network agent show 8676ccb3-1de0-4ca6-8fb7-b814015d9e5f \ --max-width 70
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Sample output
You should see an agent object with a field called
configuration
. When theqos
extension is loaded, theextensions
field should containqos
in its list.Copy to Clipboard Copied! Toggle word wrap Toggle overflow