Question

Difficulty: Very hardConfigure Virtual Machine Scale Sets (VMSS)

You are configuring an autoscale policy for an Azure Virtual Machine Scale Set (VMSS) named `vmss1` that currently has a capacity of 33 instances. The scale set uses the Uniform orchestration mode. You define the following autoscale rules within a single profile:

* Scale-out rule: Increase the instance count by 11 when the average CPU percentage of the scale set is greater than 70%70\% for a duration of 1010 minutes.
* Scale-in rule: Decrease the instance count by 11 when the average CPU percentage of the scale set is less than 55%55\% for a duration of 1010 minutes.
* Both rules have a cool-down period of 1010 minutes.

A sustained, constant workload requiring a total of 215%215\% CPU capacity (distributed evenly across all active instances) is applied to `vmss1`.

What is the behavior of the scale set under this workload, and how can you resolve any potential issues?

  1. A
    The scale set will experience transient CPU spikes and remain at 33 instances because the average CPU load must exceed the scale-out threshold by at least 15%15\% before scaling triggers. To resolve this, you should increase the scale-out threshold to 85%85\%.
  2. B
    The scale set will scale out to 44 instances and remain stable because the cool-down period prevents any scale-in events once the scale-out event completes under a sustained load. To resolve the performance latency, you must decrease the cool-down period to 55 minutes.
  3. The scale set will enter an infinite loop of scaling out to 44 instances and scaling in to 33 instances (thrashing). To resolve this, you should decrease the scale-in threshold to 50%50\%.Answer
  4. D
    The scale set will scale in to 22 instances and remain stable because the scale-in rule takes precedence over the scale-out rule when metrics conflict. To resolve this, you must delete the scale-in rule and rely on manual scaling.

Answer

The scale set will enter an infinite loop of scaling out to 4 instances and scaling in to 3 instances (thrashing). To resolve this, you should decrease the scale-in threshold to 50%.
The correct option is the one describing that the scale set will enter an infinite loop (thrashing) and suggesting lowering the scale-in threshold. At 33 instances, a load of 215%215\% results in an average CPU of 71.67%71.67\%, which exceeds the 70%70\% scale-out threshold. After the duration is met, the scale set adds 11 instance, making the capacity 44 instances. At 44 instances, the average CPU load drops to 53.75%53.75\%, which is below the 55%55\% scale-in threshold, triggering a scale-in back to 33 instances. This cycle repeats indefinitely. Decreasing the scale-in threshold to 50%50\% prevents the scale-in rule from triggering when the instance count is 44, stabilizing the scale set.

Step-by-Step Solution

1
Calculate the average CPU utilization per instance at the starting capacity of 33 instances under the total workload demand of 215%215\%.
Each instance runs at approximately 71.67%71.67\% CPU utilization (215%/3215\% / 3).
To determine whether the initial conditions will trigger a scale-out rule (>70%> 70\%).
2
Analyze the scaling action and the resulting instance count.
The average CPU utilization (71.67%71.67\%) exceeds the scale-out threshold (70%70\%), causing the scale set to add 11 instance, bringing the total capacity to 44 instances.
To trace the first state transition of the scale set.
3
Calculate the average CPU utilization per instance at the new capacity of 44 instances under the same workload of 215%215\%.
Each instance runs at 53.75%53.75\% CPU utilization (215%/4215\% / 4).
To evaluate the scale set state against the scale-in threshold (<55%< 55\%) once the new instances are active.
4
Identify the stability of the new state and determine the resolution.
The new CPU utilization (53.75%53.75\%) falls below the scale-in threshold (55%55\%), triggering a scale-in back to 33 instances. This creates an infinite loop of scaling (thrashing). To resolve it, the scale-in threshold must be set below 53.75%53.75\% (e.g., 50%50\%) so that the scale-in rule does not trigger at 44 instances.
To resolve the thrashing by ensuring the scale-in threshold accounts for the capacity increase from scaling out.

Key Concept

Avoiding autoscale flapping (thrashing) by correctly spacing metric thresholds to account for capacity changes.
Estimated Time:3m 0s
Rate this question