Each Avi Load Balancer Service Engine (SE) group has settings for minimum and maximum scaleout per virtual service (VS). These settings govern the number of SEs across which a VS can be scaled. This section explains the impact of changing these two settings on virtual services.

For more information on scale out settings, see Service Engine Group.

A virtual service can be affected in the following scenarios:

  1. The min-max settings of its SE group are dynamically changed. All virtual services placed on the SE group are affected.

  2. It is moved to another SE group having different settings

Impact of Changes

Changes to the min_scaleout_per_vs or max_scaleout_per_vs settings of an SE group result in the same behavior as described above with the following exceptions:

  • Increase in the min_scaleout_per_vs of an SE group only increases 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 re-enabled, the number of placements are capped at max_scaleout_per_vs.

  • When migrating a VS from one SE group to another, the Avi Load Balancer disregards the number of placements made within the group‌. The VS is placed according to the min_scaleout_per_vs value of the destination group.

Scenarios

The effect on virtual services when the minimum-maximum scaleout per VS settings of the SE group are changed is illustrated in the following section.

To understand the examples, it should be noted that internally, the number of SEs requested for a VS is the sum of the following two numbers:

  1. The minimum scaleout per VS of its SE group (min_scaleout_per_vs).

  2. 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 only increases the scale of existing VSs if the new minimum is greater than the current scale of the VS.

  • 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 and re-enabled preserves its existing scale, capped by the current maximum scale per VS of the SE group.

  • 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 or maximum scale per VS is changed is illustrated in the following section:

  • Increasing Minimum Scale per VS

For a VS without any user scaleout, increasing the minimum scale of the SE group increases the number of SEs of the VS to the new minimum.

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 increases the number of SEs, only if the new minimum is greater than the current scale of the VS.

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 the scale of the existing VS. 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:

  1. After changing the SE group settings, manually scale down every VS to reduce the user scaleout to 0.

  2. 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).

  3. Move all VSs in the SE group to another SE group where the min_scaleout_per_vs is 1.

  • Changing Maximum Scale per VS

Changing the maximum scale per VS has no effect on the other variables.

If the maximum scale per VS of an SE group is reduced, all VSs within the SE group retain the same number of SEs. So 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 is 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 remains 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, the Avi Load Balancer does not attempt to preserve its state and adheres to 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 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

min_scaleout_per_vs of new SE group