Scaling Groups
The Scaling Groups tab details the various computational scaling groups available in Orion.
Scaling groups can be filtered by several drop-downs in the Filter Bar. Filters include instance type, market, minimum CPUs and GPUs, minimum memory, state, minimum size, and usage. All filters offer drop-down suggestions except for instance type, which requires you to enter the instance type, followed by “Enter”. Multiple filters may be applied at one time. Filters can be cleared individually by clicking the X next to a filter or by clicking the word “clear” next to the filter options.
Figure 1. The Scaling Groups tab of the System Information page. The “Group by family prefix” toggle is on. The c6i family has been expanded to show the groups and their specific instance type. The group name can be copied for each instance group by using the copy icon next to the name.
The table below represents spot and non-spot/on-demand EC2 instances.
Name |
Description |
||||
|---|---|---|---|---|---|
Type |
EC2 instance type and specification. |
||||
Market |
Spot versus on-demand instances. |
||||
CPU |
CPUs available. |
||||
GPU |
GPUs available. |
||||
Memory |
Memory available. |
||||
Disk Space |
Disk space available. |
||||
State |
Indicates the state of an ASG.
|
||||
Scaling |
ASG policy.
|
||||
Details |
Columns showing the state of the ASG and whether it is active or deactivated.
|
||||
Usage |
Percentage of resources currently provided by the ASG. |
||||
Cost/Hour |
Hourly instance cost. If spot, it will update regularly. |
||||
Edit |
Allows an Orion Stack admin to manage an ASG.
|
As tasks are submitted to Orion, the scheduler decides where to place the work based on the hardware and spot requirements of the cubes, as well as other factors such as affinity. As the workload grows, more instances are launched. This is first seen as an increase in desired instances count; soon thereafter, the healthy instances should match this. Desired and healthy instances are not allowed to exceed the maximum size.
Once work is complete and Orion starts to scale down, users see the desired count drop far more quickly than the healthy count. This is for two reasons: (1) those instances are likely still working on their current task, and (2) Orion does not terminate instances immediately after they complete work as startup takes time (several minutes depending on instance type and pricing model), so they remain as hot instances for new work.
If the desired count is higher than the healthy count for a long period, there is probably limited spot availability or no availability.