Skip to end of metadata
Go to start of metadata

Overview of "Define Scaling Policy" Use Case

Define policy to effect scaling decisions


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Integrated Observatory Operator
References UC.R1.16 Scale the Processing
Uses  
Is Used By  
Extends  
Is Extended By  
In Acceptance Scenarios None
Technical Notes  
Lead Team CEI
Primary Service Elastic Computing Services
Version 1.7
UC Priority 3
UC Status Mapped + Ready
UX Exposure ONC

Summary

This information summarizes the Use Case functionality.

Decision engines provide automatic scaling and compensation in the system, by adding or removing resources in response to sensor information. For a decision engine, define the policy that describes how scaling is to occur. This includes handling multiple instances for high availability purposes. The policy has to define sensors (i.e., system measurements), algorithms, and thresholds for adding and subtracting units. Each scaling resource has a policy. Decision engines are present in EPUs (manage pools of virtual machines), and HA Agents (manage pools of processes).

Assumptions

  • Definition of scaling policy occurs during operations
  • Templates for scaling policy exist (e.g., n-preserving, geographically distributed, elastic scaling, allocation-based scaling)
  • Sensor types are predefined (e.g., queue length sensor, CPU average, message latency, allocation)
  • CEI capabilities are fully functional

Initial State

Scaling policy templates exist in the system (added during integration time), system is operational.

Scenario for "Define Scaling Policy" Use Case

  1. Operator selects ION capability to list existing HA Agents or EPUs
    1. Via operator console or API
  2. Operator selects a specific scaling resource such as an EPU
    1. Another type of scaling resource is an HA Agent managing a pool of service processes
  3. Operator selects to define the decision engine's scaling policy
    1. Scaling policy is shown, if existing
    2. Could choose to edit an existing policy, or create a new one.
    3. Note: scaling policy is completely different from access policy (governance)
  4. Operator edits scaling policy (or creates new policy)
    1. Possible policies are defined as a set of templates: "n-preserving", sensor-based compensation rules, etc.
    2. Select policy template from existing choices
    3. Define policy parameters: e.g.the n in "n-preserving" template, or the min max thresholds for increasing and subtracting units; instantiation locations, geographical distribution
    4. Define policy input: Select from available sensor types; Parameterize sensor, e.g. queue length of queue X
    5. Define error conditions and notifications
    6. Modify policy rule details
  5. The system begins allocating resources based on the new policy.
    1. If and once the decision engine is active

Final State

Scaling policy is in effect for targeted decision engine.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

Note that the available policy templates and sensor inputs will be limited in Release 2. The operator will select from a set of predefined policies, with a few simple infrastructure domains in Release 2.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.