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.

../_images/system_scaling_groups.png

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.

Table 1. Scaling Groups.

Name

Description

Type

EC2 instance type and specification.

  • Hovering over the infoicon icon provides further details about the Auto Scaling Group (ASG).
  • Group Name represents either an internal or AWS group name.

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.

  • Healthy: New instances can be added.
  • Drain: Due to administrative action, existing instances will not be given more work and will be
    terminated as they finish their current work. New instances will not be added.
  • Not Configured: A new group that will attempt to start a new instance to finish configuration.
  • Scaling Suspended: Existing instances accept work, but new instances cannot be added
    due to AWS capacity.
  • Failed: Due to persistent errors, existing instances will not be given more work and
    will be terminated. New instances will not be added.
  • Suspect: Non-scaling AWS errors are occurring. Existing instances will accept work, but new
    instances cannot be added. If errors continue, the group state will move to “Failed”.

Scaling

ASG policy.

  • Adjusts the desired capacity of the group between the minimum and maximum capacity values.
  • Launches or terminates the instances as needed. The number of instances increases (Up arrow) or
    decreases (Down arrow) dynamically to meet changing conditions.

Details

Columns showing the state of the ASG and whether it is active or deactivated.

Healthy Instances: Number of instances currently available to process work.

Desired: Number of instances the scheduler would like to have as healthy.

Min: Minimum size of the group (the default is 0).

Max: Maximum size of the group (can help limit spending in Orion).

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.

  • Min Size
  • Max Size
  • Min Reserve: If set, ensures that there are always N idle instances for that scaling group.
  • Affinity: A scheduler feature to increase the preference of a group (the default is 0).
  • State

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.