The Impact of Changes to Min/Max Scaleout per Virtual Service
Overview
Each Avi Service Engine (SE) group has settings for minimum and maximum scaleout per virtual service (VS), min_scaleout_per_vs and max_scaleout_per_vs. These settings govern the number of SEs across which a VS can be scaled. This article explains the impact of changing these two settings on virtual services.
Refer to Service Engine Group article for more information, including how to make these settings.
A virtual service can be affected when:
- The min-max settings of its SE group are dynamically changed. All virtual services placed on the SE group are affected.
- It is moved to another SE group having different settings.
Summary of Behavior
Release 18.2.1 and Prior
To provide continuity in the performance of applications placed on an SE group, decreases to an SE group’s min_scaleout_per_vs and/or changes to max_scaleout_per_vs settings have no effect on the number of virtual service placements currently running in the group. Increasing the SE group’s min_scaleout_per_vs will increase the number of virtual service placements by the same amount. After a change in settings, if a virtual service is scaled in or out such that the number of placements falls within the bounds described by the new settings, it is thereafter constrained to those bounds.
Note the following:
-
Imagine a VS is disabled and then the value of
max_scaleout_per_vsis set lower than that virtual service’s placement count. If that VS is then enabled, themax_scaleout_per_vsupper bound will be ignored and the previous number of placements will be made.
When migrating a VS from one SE group to another, Avi Vantage records the number of scaleout placements above the current value of the group’smin_scaleout_per_vs. Then, on the destination group, it performs that same number of scaleouts beyond that group’smin_scaleout_per_vsvalue. -
If a migration would exceed the destination group’s
max_scaleout_per_vs, Avi Vantage issues a warning and does not perform the migration. -
If the destination group’s
min_scaleout_per_vs*setting is set higher than that of the originating group, the number of VS placements in the destination group will be corresponding larger.
Release 18.2.2 and Higher
Changes to an SE group’s min_scaleout_per_vs and/or max_scaleout_per_vs settings result in the same behavior as described above with following exceptions.
- Increases in an SE group’s
min_scaleout_per_vswill only increase the number of virtual service placements if the new minimum value is greater than the current number of virtual service placements. - If a VS is disabled and then enabled, the number of placements are capped at
max_scaleout_per_vs. - When migrating a VS from one SE group to another, Avi Vantage disregards the number of placements made within the group. The VS is placed according to the destination group’s
min_scaleout_per_vs.
Example Scenarios
The effect on virtual services when the minimum/maximum scaleout per VS settings of their SE group are changed is illustrated in this section.
Release 18.2.1 and Prior
Refer to the version of this article for the Avi Vantage release 18.1 family.
Release 18.2.2 and Higher
To understand the examples, it should be noted that internally, the number of SEs requested for a VS is the sum of two numbers:
- The minimum scaleout per VS of its SE group (
min_scaleout_per_vs) - The user scaleout factor
The user scaleout factor is an internal variable which starts at 0 for all virtual services. This number increases by 1 when a user scales out and decreases by 1 when the user scales in.
General Behavior
Following are the rules governing all changes of minimum and maximum scale per VS:
- Decreasing the minimum scale per VS has no effect on the scale of existing virtual services in the group.
- For this case, the user scaleout is increased by the amount that the minimum scale per VS is decreased.
- For an existing VS, if the user wishes it to be scaled at the minimum level of the SE group, the user must explicitly scale in.
- Increasing the minimum scale per VS will only increase the scale of existing VSs if the new minimum is greater than the VS’s current scale.
- Increasing or decreasing the maximum scale per VS of an SE group has no effect on the scale of existing VSs in the group.
- For VSs with more SEs than the new maximum scale, the user is still able to manually scale in.
- A VS which is disabled then enabled will preserve its existing scale, capped by the current SE group’s maximum scale per VS.
- A VS which is moved to another SE group will be placed on the minimum scale per VS of the new SE group.
Changing SE Group Settings
The effect on VSs in an SE group when its minimum/maximum scale per VS is changed are illustrated below:
Increasing Minimum Scale per VS
For a VS without any user scaleout, increasing the minimum scale of the SE group will simply increase the VS’s number of SEs to the new minimum.
Example
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS |
| initial state | 1 | 0 | 1 |
| min scale per VS: 1 → 2 | 2 | 0 | 2 |
For a VS with user scaleout, increasing the minimum scale will only increase the number of SEs if the new minimum is greater than the VS’s current scale.
Example 1
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS |
| initial state | 1 | 0 | 1 |
| user scale out | 2 | 1 | 1 |
| min scale per VS: 1 → 2 | 2 | 0 | 2 |
Example 2
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS |
| initial state | 2 | 1 | 1 |
| min scale per VS: 1 → 3 | 3 | 0 | 3 |
Decreasing Minimum Scale per VS
Decreasing the minimum scale per VS of an SE group will have no effect on its existing VSs’ scale. To maintain the same number of SEs, the user scaleout is increased by the amount of decrease in minimum scale.
Example
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS |
| initial state | 2 | 0 | 2 |
| min scale per VS: 2 → 1 | 2 | 1 | 1 |
| user scale in | 1 | 0 | 1 |
The purpose of this behavior is to preserve the current state of all VSs residing inside an SE group when min scale per VS is reduced. By increasing the user scaleout by the amount of decrease in min_scaleout_per_vs, we keep the number of SEs requested the same.
If the desired outcome in the above example is to scale every VS in the SE group down to 1 SE, there are three options:
- After changing the SE group settings, manually scale down every VS to reduce the user scaleout to 0.
- Set the maximum scale per VS of the SE group to 1. Disable and enable all VSs (maximum scale can also be reduced after the disable).
- Move all VSs in the SE group to another SE group where the
min_scaleout_per_vsis 1.
Changing Maximum Scale per VS
Changing the maximum scale per VS has no effect on the other variables.
If reducing the maximum scale per VS of an SE group, all VSs within the SE group will retain the same number of SEs. Thus, the number of SEs requested for a VS in this situation can be greater than the new maximum scale per VS. The user has the option of manually scaling in to reduce this number to the new max.
Example
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS | Max scaleout per VS |
| initial state | 3 | 2 | 1 | 4 |
| max scale per VS: 4 → 2 | 3 | 2 | 1 | 2 |
| user scale in | 2 | 1 | 1 | 2 |
VS Disable and Enable
When a VS is disabled and then enabled, it will be placed on (current min scale per VS + number of user scaleouts), capped by the current max scale per VS of the SE group.
If a VS is disabled and then enabled without changing the scale settings of the SE group, the VS will remain at the same scale.
Example 1
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS | Max scaleout per VS |
| Initial state | 3 | 2 | 1 | 4 |
| VS disabled | 0 | 2 | 1 | 4 |
| VS enabled | 3 | 2 | 1 | 4 |
Example 2
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS | Max scaleout per VS |
| Initial state | 2 | 0 | 2 | 4 |
| VS disabled | 0 | 0 | 2 | 4 |
| Min scale per VS: 2 → 1 | 0 | 1 | 1 | 4 |
| VS enabled | 2 | 1 | 1 | 4 |
Example 3
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS | Max scaleout per VS |
| Initial state | 4 | 3 | 1 | 4 |
| Max scale per VS: 4 → 1 | 4 | 3 | 1 | 1 |
| VS disabled | 0 | 3 | 1 | 1 |
| VS enabled | 1 | 0 | 1 | 1 |
Moving a VS to Another SE Group With Different Settings
Moving a VS to another SE group will always place the VS on the min_scaleout_per_vs of the new SE group.
Example 1
| Action | Num of SEs Requested | User scaleout | min scaleout per VS | Max scaleout per VS |
| Initial state | 2 | 0 | 2 | 4 |
| User scale out | 3 | 1 | 2 | 4 |
| VS moved to new SE group with (min: 1, max: 2) | 1 | 0 | 1 | 2 |
Since the VS has been moved to a new SE group, Avi Vantage does not attempt to preserve its state and will thus respect the settings of the new SE group.
Example 2
| Action | Num of SEs Requested | User scaleout | Min scaleout per VS | Max scaleout per VS |
| Initial state | 1 | 0 | 1 | 4 |
| VS moved to new SE group with (min: 2, max: 2) | 2 | 0 | 2 | 2 |
A legacy active-standby SE group effectively has a minimum scale per VS of 2 and a maximum scale per VS of 2.
Summary
The following table summarizes expected changes in the various scenarios:
| Action | VS: num of SEs |
↑ min_scaleout_per_vs |
Increase only if current number of SEs < min_scaleout_per_vs |
↓ min_scaleout_per_vs |
Stays the same |
↑ max_scaleout_per_vs |
Stays the same |
↓ max_scaleout_per_vs |
Stays the same |
| VS disable/enable | Caps at max_scaleout_per_vs |
| Move VS to another SE group | New SE group’s min_scaleout_per_vs |