248 lines
10 KiB
ReStructuredText
248 lines
10 KiB
ReStructuredText
=============================
|
|
Tricircle Quality of Service
|
|
=============================
|
|
|
|
Background
|
|
==========
|
|
|
|
QoS is defined as the ability to guarantee certain network requirements
|
|
like bandwidth, latency, jitter and reliability in order to satisfy a
|
|
Service Level Agreement (SLA) between an application provider and end
|
|
tenants. In the Tricircle, each OpenStack instance runs its own Nova and
|
|
Neutron services but shares the same Keystone service or uses federated
|
|
KeyStones, which is a multi-region deployment mode. With networking automation,
|
|
networks or ports created in different OpenStack cloud should be able to be
|
|
associated with QoS policies.
|
|
|
|
Proposal
|
|
========
|
|
|
|
As networking automation across Neutron could be done through the Tricircle,
|
|
the QoS automation should be able to work based on tenant's need too. When
|
|
tenant wants to apply QoS to the network or port from the central Neutron, QoS
|
|
can't be created in the local Neutron server in the bottom pod directly, since
|
|
it's still unclear whether the network will be presented in this pod or not.
|
|
|
|
In order to achieve QoS automation operations, QoS can't be created in the
|
|
local Neutron server directly until there are some existing networks/ports
|
|
in bottom pod. The Tricircle central Neutron plugin(abbr: "central plugin")
|
|
will operate QoS information in the local Neutron server, QoS service isn't
|
|
like network/port that needs to be created during VM booting, in order to
|
|
speed up the local VMs booting and reduce the delay that caused by
|
|
synchronization between central Neutron and local Neutron, Tricircle central
|
|
plugin should use an asynchronous method to associate QoS with the local
|
|
network/port, or remove QoS association in each local Neutron if needed.
|
|
|
|
Implementation
|
|
==============
|
|
|
|
Case 1, QoS policy creation
|
|
----------------------------
|
|
|
|
In this case, we only create QoS in the central Neutron.
|
|
|
|
Case 2, QoS policy association without local network/port in place
|
|
------------------------------------------------------------------
|
|
|
|
QoS has been created in the central Neutron but local network/port has not
|
|
yet been created.
|
|
|
|
In this case, we just need to update network/port with QoS policy id in the
|
|
central Neutron.
|
|
|
|
Case 3, QoS policy association with local network/port in place
|
|
---------------------------------------------------------------
|
|
|
|
After QoS has been created in the central Neutron and local network/port
|
|
also has been created, associate QoS with network/port in the central Neutron.
|
|
|
|
In this case, network/port has been created in the local Neutron. After
|
|
network/port is updated with the QoS policy id in the central Neutron, we also
|
|
need to do some similar association in the local Neutron. Central Neutron uses
|
|
"create_qos_policy" job to create the local QoS policy firstly, then update the
|
|
network/port QoS association asynchronously in the local Neutron through the
|
|
network/port routing information and add the QoS routing information in routing
|
|
table. XJob will interact with local Neutron to update the QoS policy id for
|
|
network/port in local Neutron.
|
|
|
|
Case 4, provision VM with QoS policy associated central port/network
|
|
--------------------------------------------------------------------
|
|
|
|
QoS has been associated to central port/network first, local network/port
|
|
is created later in VM provision.
|
|
|
|
In this case, QoS has been associated to the central network/port and at this
|
|
point local network/port does not exist. Since QoS has not been created in
|
|
the local Neutron but central Neutron has finished the association, local
|
|
neutron needs to trigger central Neutron to finish the local network/port
|
|
QoS association when VMs booting in the local. When VM booting in the bottom
|
|
pod, local Neutron sends update port request with port information to central
|
|
Neutron and if QoS id field exists in the network/port, the central Neutron
|
|
will be triggered to use XJob to create an QoS policy creation job in the
|
|
local Neutron (it also speeds up VM booting) and add the QoS routing
|
|
information in routing table.
|
|
|
|
Case 5, QoS policy updating
|
|
----------------------------
|
|
|
|
In this case, if local network/port isn't associated with QoS, we only update
|
|
QoS in the central Neutron.
|
|
|
|
If QoS policy has been associated with local network/port in place, after
|
|
central Neutron updates QoS, central Neutron will use XJob to create a QoS
|
|
asynchronous updating job through the network/port routing information.
|
|
XJob will asynchronously update QoS in the local Neutron.
|
|
|
|
Case 6, QoS policy disassociation
|
|
-----------------------------------
|
|
|
|
For QoS policy disassociation, just need to change the parameters of
|
|
"QoS_policy_id" to None when update network/port in the central Neutron and
|
|
we can disassociate network/port.
|
|
|
|
In this case, if network/port in local Neutron isn't associated with QoS, we
|
|
only disassociate network/port in the central Neutron.
|
|
|
|
If QoS policy has been associated with network/port in local Neutron, after
|
|
central Neutron disassociates network, central Neutron will use XJob to
|
|
create a network update job to disassociate the network with the QoS policy;
|
|
for port, central Neutron will synchronously update the port to disassociate
|
|
it with the QoS policy in the local Neutron.
|
|
|
|
Case 7, QoS policy deletion
|
|
----------------------------
|
|
|
|
QoS policy can only be deleted if there is no any association in central
|
|
Neutron. In this case, if local network/port isn't associated with QoS, we
|
|
only delete QoS in the central Neutron.
|
|
|
|
If there is QoS policy routing info, after central Neutron deletes QoS,
|
|
central Neutron will use XJob to create a QoS asynchronous deletion job
|
|
through the network/port routing information. XJob will asynchronously
|
|
delete QoS in the local Neutron.
|
|
|
|
Case 8, QoS rule creation
|
|
--------------------------
|
|
|
|
In this case, if local network/port isn't associated with QoS, we only create
|
|
QoS rule in the central Neutron.
|
|
|
|
If QoS policy has been associated with local network/port in place, after central
|
|
Neutron creates QoS rules, central Neutron will use XJob to create a QoS rules
|
|
syncing job through the network/port routing information, then asynchronously
|
|
creates QoS rules in the local Neutron.
|
|
|
|
Case 9, QoS rule updating
|
|
--------------------------
|
|
|
|
In this case, if local network/port isn't associated with QoS, we only update
|
|
QoS rule in the central Neutron. If QoS policy has been associated with local
|
|
network/port in place, after central Neutron updates QoS rule, central Neutron
|
|
will trigger XJob to create a QoS rules syncing job in the local Neutron
|
|
through the network/port routing information. XJob will asynchronously update
|
|
QoS rule in the local Neutron.
|
|
|
|
Case 10, QoS rule deletion
|
|
----------------------------
|
|
|
|
In this case, if local network/port isn't associated with QoS, we only delete
|
|
QoS rule in the central Neutron.
|
|
|
|
If QoS policy has been associated with local network/port in place, after
|
|
central Neutron deletes QoS rule, central Neutron will use XJob to create a QoS
|
|
rules syncing job through the network/port routing information. XJob will
|
|
asynchronously delete QoS rule in the local Neutron.
|
|
|
|
QoS XJob jobs list
|
|
-------------------
|
|
|
|
- **1: create_qos_policy(self, ctxt, policy_id, pod_id, res_type, res_id=None)**
|
|
|
|
Asynchronously creating QoS policy for the corresponding pod which id equals
|
|
"pod_id", specify network or port in through the parameter res_type and
|
|
res_id. If res_type is RT_NETWORK, then res_id is network's uuid, if res_type
|
|
is RT_PORT, then res_id is port's uuid
|
|
|
|
**Triggering condition:**
|
|
|
|
When associating network/port in the central Neutron, if this network/port
|
|
exists in the local Neutron, triggering this asynchronous job to complete
|
|
the local association.
|
|
|
|
When central plugin processing a port update request sent by local plugin
|
|
and finding the port is associated with QoS.
|
|
|
|
If pod_id is POD_NOT_SPECIFIED then the async job will process all related
|
|
pods, so the create_qos_policy(self, ctxt, policy_id, pod_id) job will deal
|
|
with not only single pod's QoS association.
|
|
|
|
If the res_type is RT_NETWORK/RT_PORT, after creating the qos policy on pod,
|
|
the async job will bind the qos policy that just created to the network/port
|
|
specified by the parameter of res_id.
|
|
|
|
- **2: update_qos_policy(self, ctxt, policy_id, pod_id)**
|
|
|
|
Asynchronously updating QoS policy for the corresponding pod which id equals
|
|
"pod_id".
|
|
|
|
**Triggering condition:**
|
|
|
|
When updating QoS policy in the central Neutron, if it also exists in the
|
|
local Neutron, triggering this asynchronous job to complete the local QoS
|
|
updating.
|
|
|
|
If pod_id is POD_NOT_SPECIFIED then the async job will process all related
|
|
pods, so the update_qos_policy(self,ctxt,policy_id,pod_id) job will deal with
|
|
not only single pod's QoS association.
|
|
|
|
- **3: delete_qos_policy(self, ctxt, policy_id, pod_id)**
|
|
|
|
Asynchronously deleting QoS policy for the corresponding pod which id equals
|
|
"pod_id".
|
|
|
|
**Triggering condition:**
|
|
|
|
When deleting QoS policy in the central Neutron, if this QoS policy exists in
|
|
the local Neutron, triggering this asynchronous job to complete the local QoS
|
|
deletion.
|
|
(Warning: the deleted QoS policy must be disassociated first.)
|
|
|
|
If pod_id is POD_NOT_SPECIFIED then the async job will process all related
|
|
pods, so the delete_qos_policy(self,ctxt,policy_id,pod_id) job will deal with
|
|
not only single pod's QoS association.
|
|
|
|
- **4: sync_qos_policy_rules(self, ctxt, policy_id)**
|
|
|
|
Asynchronous operation for rules of one QoS policy for specified project.
|
|
There are two trigger conditions. The one is that central Neutron
|
|
creates/updates/deletes QoS rules after QoS policy has been associated with
|
|
local network/port. The other is that central plugin processes a port update request
|
|
sent by local plugin and finds the port is associated with QoS policy.
|
|
|
|
If the rule both exists in the central Neutron and local Neutron, but with
|
|
inconsistent content, just asynchronously updating this QoS rule in the local
|
|
Neutron.
|
|
|
|
If the rule exits in the central Neutron, but it does not exist in the local
|
|
Neutron, just asynchronously creating this QoS rule in the local Neutron.
|
|
|
|
If the rule exits in the local Neutron, but it does not exist in the central
|
|
Neutron, just asynchronously deleting this QoS rule in the local Neutron.
|
|
|
|
|
|
Data Model Impact
|
|
-----------------
|
|
|
|
None
|
|
|
|
Dependencies
|
|
------------
|
|
|
|
None
|
|
|
|
Documentation Impact
|
|
--------------------
|
|
|
|
Release notes
|
|
|