Introduction
This section allows the system administrator to configure fairness among different tenants w.r.t access to workflow-hub.
Fairness Control Algorithms
Fairness Control Algorithms
Fairness control algorithms is allowed to be configured from the Workflow Hub Administration Tab. As this configuration affects all tenants, privilege to access this tab should be provided to System Administrators ONLY. When any role in the tenant is being created, it must be ensured that the following privileges are NOT allocated to the role (allocation of these privileges would enable access to Workflow Hub Administration Tab).
- WORKFLOW HUB CONFIGURATION READ
- WORKFLOW HUB CONFIGURATION WRITE
The algorithms are described below.
Configuration
Administration tab lists three parameters, of which 2 are configurable. The other parameter is read-only.
- Max Workflow Runs: This indicates the system-limit about the number of concurrent workflow runs supported. User cannot change this value.
- Algorithm Type: This is a drop-down, which allows user to select one of three types: No-Limit, Static & Dynamic
- Tenant Fairness Parameter (TFM): This is a parameter provided to the algorithm.
No Limit
When user selects no-limit, it will NOT impose any limit on per-tenant executions. In other words each tenant would have access to trigger all the 128 executions. Selection of this algorithm is recommended when we have no more than 1-2 tenants using Workflow Hub. When No Limit is selected, the TFM has no impact on the algorithm behavior.
Static
When user selects static, a tenant can execute runs up to a certain limit (dictated by the TFM). Any new run executed after reaching the limit will be in Queued state.
The limit is calculated as follows:
Limit = MaxWfRuns*TFM/(Number of tenants)
As an example: If we have 128 workflows and 8 tenants, with TFM set to 1, each tenant would be allowed to execute 16 concurrent runs. Additional runs executed meanwhile will be put into queue. This also implies that the system utilisation is very low (12.5%) IF ONLY ONE tenant is active. User can tweak this, by adjusting the TFM to say 3-4. Then a single tenant could use up to 50% of the system. However, if more than 2-3 users access the system simultaneously, there could be a fairness problem.
The static algorithm is recommended, when we have a large number tenants, but very few of the tenants are active at any given time (i.e., very few tenants need to simultaneously execute workflows). In that case, the TFM should be tuned to a value to achieve high system utilisation, with few active tenants.
Dynamic
With the Dynamic algorithm, the limit is dynamically determined depending on the overall usage of the Workflow Hub. The limit would be a function of the spare-capacity : TFM*(MaxWfRuns - TotalRunningWFs). So, when the usage is high, the spare-capacity will be small, and therefore limit will become small. Light users with very few running workflows would be allowed to submit new execution runs. New workflow-runs triggered by heavy users of the system will be queued. This approach trades off short-term utilisation for longer term fairness. Use of Dynamic limits are recommended, when the number of active tenants cannot be predicted as easily as the case with Static.
Example:
- Suppose the total ongoing executions is 32, this implies the spare capacity is 96. The limit would be set to 384 (which is higher than the MaxWfRuns, but it does not matter, as this value changes with every evaluation). So, a tenant with 1 ongoing execution as well as 29 ongoing executions would be treated the same. Both requests would be allowed.
- Suppose the total ongoing executions is 120: The spare capacity is 8. The limit would be set to 24 (with TFM of 3.0). Now, the tenant with 1 ongoing execution would be allowed to submit a execution request. Subsequently, runs of a tenant with 29 ongoing executions would be queued.
Recommended TFM for Dynamic: 3.0
