Changing the Minimum and Maximum Scale per Virtual Service

Overview

Each Service Engine (SE) group has settings for minimum and maximum scale per virtual service (VS). These fields correspond to the number of SEs across which a VS can be scaled. This article explains the impact of changing these two settings on virtual services.

There are two ways for a VS to be affected by these settings:

The settings of the virtual service’s SE group are changed.
The VS is moved to another SE group having different settings.

Internally, the number of SEs requested for a VS is the sum of two numbers:

The minimum scale per VS of its SE group (min_scaleout_per_vs)
The user scaleout factor

The user scale-out factor is an internal variable starting 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

These are the rules governing all changes of minimum and maximum scale per VS:

User scale out always remains the same, except in scenario 1 (see above) when minimum scale per VS is decreased — for this case the user scale out is increased for virtual services in the SE group.
- User scale out is increased by the amount that the minimum scale per VS is decreased.
- The purpose of this behavior is to preserve the current scale for all existing virtual services within the SE group.
- 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.
When migrating a VS to another SE group, an error will occur if the current scale-out factor of the VS + the min_scaleout_per_vs of the new SE group exceeds the max_scaleout_per_vs of the new SE group.
When reducing max_scaleout_per_vs of an SE group:
- The current scale of all existing VSs in the group is preserved, even if it is greater than the new value of max_scaleout_per_vs.
- For existing virtual services with more SEs than the new maximum scale, the user is still able to manually scale in.

Changing SE Group Settings

The effects on an SE group’s virtual services when minimum/maximum scale per VS is changed are illustrated below:

Increasing Minimum Scale per VS

Effect on virtual services in the SE group:

Variable	Effect
min_scaleout_per_vs	Updated to new value
user scale out	No change
number of SEs requested	Increases

Example: Increasing min_scaleout_per_vs from 1 to 2 (VS has been scaled out once)

	Before	After
min_scaleout_per_vs	1	2
max_scaleout_per_vs	4	4
user scale out	1	1
number of SEs requested	2	3

Decreasing Minimum Scale per VS

Effect on virtual services in the SE group:

Variable	Effect
min_scaleout_per_vs	Updated to new value
user scale out	Increases by amount of decrease in min_scaleout_per_vs
number of SEs requested	No change

Example: Decreasing min_scaleout_per_vs from 2 to 1

	Before	After
min_scaleout_per_vs	2	1
max_scaleout_per_vs	4	4
user scale out	0	1
number of SEs requested	2	2

The purpose of this behavior is to preserve the current state of all VSs residing inside an SE group when min_scaleout_per_vs is reduced. By increasing the user scale out by the amount of decrease in min_scaleout_per_vs, Avi Vantage keeps 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 two options:

After changing the SE group settings, manually scale down every VS to reduce the user scale out to 0.
Move all VSs in the SE group to another SE group where min_scaleout_per_vs = 1. (Note: in this scenario, any previous user scale outs will be preserved, so it may still be necessary to manually scale in.)

Changing Maximum Scale per VS

Changing the maximum scale per VS has no effect on other variables. However, there is a difference in behavior between the two scenarios when it is reduced.

If moving a VS from an SE group to another SE group, an error will occur if the current scale-out factor of the VS + the min_scaleout_per_vs of the new SE group exceeds the max_scaleout_per_vs of the new SE group

If reducing the max_scaleout_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 value of max_scaleout_per_vs. The user has the option of manually scaling in to reduce this number to the new max.

Example: Reducing max_scaleout_per_vs from 4 to 2

Assume that an SE group with a minimum scale of 1 and a maximum scale of 4 has a single VS which has been scaled out twice. The number of SEs hosting that VS should be 3. If the user reduces the max scale per VS of the SE group to 2, all other variables remain the same.

	Before	After
min_scaleout_per_vs	1	1
max_scaleout_per_vs	4	2
user scale out	2	2
number of SEs requested	3	3

At this point, the number of SEs requested exceeds the value of max_scaleout_per_vs. The user will not be able to scale out at this point. However, to reduce the number of SEs for this VS to the new maximum, the user can manually scale in.

	Before	After
min_scaleout_per_vs	1	1
max_scaleout_per_vs	4	2
user scale out	2	1
number of SEs requested	3	2

Moving a VS to An SE Group Having Different Settings

Moving a VS to another SE group having different minimum/maximum scale per VS settings has the same behavior as the previous scenario except the cases in which min_scaleout_per_vs or max_scaleout_per_vs is decreased.

New SE group has lower minimum scale per VS

Effect on VS:

Variable	Effect
min_scaleout_per_vs	Updated to new value
user scale out	No change
number of SEs requested	Decreases

Unlike the behavior for the other scenario, the user scale out is not increased in this case. Thus, the total number of SEs requested will decrease.

Example: New SE group has min_scaleout_per_vs of 1 (previously 2)

	Before	After
min_scaleout_per_vs	2	1
max_scaleout_per_vs	4	4
user scale out	1	1
number of SEs requested	3	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. However, note that the user scale out in this case is still preserved, and the user must manually scale in to reduce this number.

New SE group has lower maximum scale per VS

A VS cannot be moved to an SE group whose max_scaleout_per_vs is less than the sum of the current user scale out factor of the VS and the min_scaleout_per_vs of the new SE group.

Example 1:

	Before	After
min_scaleout_per_vs	1	1
max_scaleout_per_vs	4	2
user scale out	2	2
number of SEs requested	3	ERROR: Move not allowed

Example 2:

	Before	After
min_scaleout_per_vs	1	1
max_scaleout_per_vs	4	2
user scale out	1	1
number of SEs requested	2	2

Example 3:

	Before	After
min_scaleout_per_vs	3	1
max_scaleout_per_vs	5	2
user scale out	1	1
number of SEs requested	4	2

A legacy active-standby SE group effectively has a min_scaleout_per_vs of 2 and a max_scaleout_per_vs of 2. Thus, the user scale out of a VS must be reduced to 0 prior to moving it to an active-standby SE group.

The example below illustrates this.

Example 4:

	Before	Attempt to move	Scale in	Try moving again
min_scaleout_per_vs	1	2	1	2
max_scaleout_per_vs	4	2	4	2
user scale out	1	1	0	0
number of SEs requested	2	ERROR: Move not allowed	1	2

Summary

The table below summarizes expected changes in the various scenarios.

↔ indicates no change

	Change SE Group Settings		Move VS to Another SE Group
SE Group Setting	VS: user scale out	VS: number of SEs requested	VS: user scale out	VS: number of SEs requested
min_scaleout_per_vs ↑	↔	↑	↔	↑
min_scaleout_per_vs ↓	↑	↔	↔	↓
max_scaleout_per_vs ↑	↔	↔	↔	↔
max_scaleout_per_vs ↓	↔	↔	↔	↔*

* An error occurs if the following holds true for the VS:
(current user scale out + new SE group’s min_scaleout_per_vs) > new SE group’s max_scaleout_per_vs

Configuration Min and Max Scale Out per VS via Avi UI

When defining the virtual service, use the Advanced Wizard.

As mentioned above, certain SE migrations can fail if the destination SE group’s settings are not set correctly.

An error occurs when the destination SE group's settings are too small.