Skip to content

Commit 39ebc16

Browse files
committed
updates
1 parent ee7604b commit 39ebc16

File tree

2 files changed

+14
-16
lines changed

2 files changed

+14
-16
lines changed
-27 Bytes
Loading

articles/virtual-machine-scale-sets/virtual-machine-scale-sets-maxsurge.md

Lines changed: 14 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -23,16 +23,16 @@ Rolling upgrades with MaxSurge can help improve service uptime during upgrade ev
2323
## Concepts
2424

2525
> [!NOTE]
26-
> [Automatic OS image upgrades](virtual-machine-scale-sets-automatic-upgrade.md) and [automatic extension upgrades](../virtual-machines/automatic-extension-upgrade.md) automatically inherit the rolling upgrade policy and use it to perform upgrades.
26+
> [Automatic OS image upgrades](virtual-machine-scale-sets-automatic-upgrade.md) and [automatic extension upgrades](../virtual-machines/automatic-extension-upgrade.md) automatically inherit the rolling upgrade policy and use it to perform upgrades. If MaxSurge is enabled in your rolling upgrade policy, automatic OS image upgrades and automatic extension upgrades will also be applied using the MaxSurge upgrade method.
2727
2828
|Setting | Description |
2929
|---|---|
30-
|**Rolling upgrade batch size %** | Specifies how many of the total instances of your scale set you want to be upgraded at one time. <br><br>Example: A batch size of 20% when you have 10 instances in your scale set results in upgrade batches with two instances each. When using MaxSurge, this results in 2 additional instances being created in each batch. |
31-
|**Pause time between batches (sec)** | Specifies how long you want your scale set to wait between upgrading batches.<br><br> Example: A pause time of 10 seconds means that once a batch is successfully completed, the scale set will wait 10 seconds before moving onto the next batch. |
32-
|**Max unhealthy instance %** | Specifies the total number of instances allowed to be marked as unhealthy before and during the rolling upgrade. <br><br>Example: A max unhealthy instance % of 20 means if you have a scale set of 10 instances and more than two instances in the entire scale set report back as unhealthy, the rolling upgrade stops. |
33-
|**Max unhealthy upgrade %**| Specifies the total number of instances allowed to be marked as unhealthy after being upgraded. <br><br>Example: A max unhealthy upgrade % of 20 means if you have a scale set of 10 instances and more than two instances in the entire scale set report back as unhealthy after being upgraded, the rolling upgrade is canceled. <br><br>Max unhealthy upgrade % is an important setting because it allows the scale set to catch unstable or poor updates before they roll out to the entire scale set. |
34-
|**Prioritize unhealthy instances** | Tells the scale set to upgrade instances marked as unhealthy before upgrading instances marked as healthy. <br><br>Example: If some instances in your scale set that show as failed or unhealthy when a rolling upgrade begins, the scale set updates those instances first. |
35-
|**Enable cross-zone upgrade** | Allows the scale set to ignore Availability Zone boundaries when determining batches. |
30+
|**Rolling upgrade batch size %** | Specifies how many of the instances in your scale set you want to be upgraded at one time. <br><br>Example: A batch size of 20% when you have 10 instances in your scale set results in upgrade batches with two instances each. When using MaxSurge, this results in 2 additional instances being created in each batch. |
31+
|**Pause time between batches (sec)** | Specifies how long you want your scale set to wait between upgrading batches.<br><br> Example: With MaxSurge enabled, a pause time of 10 seconds means that once the new instances have successfully provisioned and are reporting as healthy, the scale set will wait 10 seconds before moving onto the next batch. |
32+
|**Max unhealthy instance %** | Specifies the total number of instances allowed to be marked as unhealthy before and during the MaxSurge upgrade. <br><br>Example: A max unhealthy instance % of 20 means if you have a scale set of 10 instances and more than two of your instances in the entire scale set report back as unhealthy, the rolling upgrade stops. |
33+
|**Max unhealthy upgrade %**| Specifies the total number of new instances allowed to be marked as unhealthy after being upgraded. <br><br>Example: A max unhealthy upgrade % of 20 means if you have a scale set of 10 instances and more than two of the newly created instances report back as unhealthy after being upgraded, the rolling upgrade is canceled. <br><br>Max unhealthy upgrade % is an important setting because it allows the scale set to catch unstable or poor updates before they roll out to the entire scale set. |
34+
|**Prioritize unhealthy instances** | Tells the scale set to upgrade instances marked as unhealthy before upgrading instances marked as healthy. <br><br>Example: If some instances in your scale set that show as failed or unhealthy when a MaxSurge upgrade begins, the scale set will replace those instances first. |
35+
|**Enable cross-zone upgrade** | Allows the scale set to ignore Availability Zone boundaries when determining batches. This means a batch may contain instances in multiple availability zones at the same time depending on the batch size and the size of your scale set. |
3636

3737
## Considerations
3838

@@ -42,14 +42,19 @@ During the rolling upgrade processes, Azure performs a quota check before each n
4242

4343
## MaxSurge vs in place upgrades
4444

45+
### MaxSurge upgrades
46+
4547
Rolling upgrades with MaxSurge creates new instances with the latest scale set model to replace instances running with the old model. By creating new instances, you can ensure that your scale set capacity doesn't drop below the set instance count during the duration of the upgrade process.
4648

4749
:::image type="content" source="./media/upgrade-policy/maxsurge-upgrade.png" alt-text="Diagram that shows the process of performing a rolling upgrade with MaxSurge.":::
4850

49-
Rolling upgrades with MaxSurge disabled performs upgrades in place. Meaning the virtual machine undergoing the upgrade will not be available for traffic during the upgrade process. This reduces your scale set capacity during the upgrade process but does not consume any extra quota.
51+
### In place upgrades
52+
53+
Rolling upgrades with MaxSurge disabled performs upgrades in place. Depending on the type of upgrade, the virtual machines may not be available for traffic during the upgrade process. This may reduce your scale set capacity during the upgrade process but does not consume any extra quota.
5054

5155
:::image type="content" source="./media/upgrade-policy/in-place-upgrade.png" alt-text="Diagram that shows the process of performing a rolling upgrade without maxsurge.":::
5256

57+
5358
## Configure rolling upgrades with MaxSurge
5459
Enabling or disabling MaxSurge can be done at any point in time. This includes during or after scale set provisioning. When using a rolling upgrade policy, the scale set must also use the [Application Health Extension](virtual-machine-scale-sets-health-extension.md) have a [health probe](../load-balancer/load-balancer-custom-probe-overview.md). It's suggested to create the scale set with a manual upgrade policy and update the policy to rolling after successfully confirming the application health is being properly reported.
5560

@@ -122,13 +127,6 @@ Update the properties section of your ARM template and set the upgrade policy to
122127
---
123128
## Frequently asked questions
124129

125-
### Is MaxSurge generally available for Virtual Machine Scale Sets with Uniform Orchestration?
126-
Yes. All upgrade policies including rolling upgrades with MaxSurge are generally available for Virtual Machine Scale Sets with Uniform Orchestration.
127-
128-
129-
### Is MaxSurge generally available for Virtual Machine Scale Sets with Flexible Orchestration?
130-
No. All upgrade policies including rolling upgrades with MaxSurge are in Public Preview for Virtual Machine Scale Sets with Flexible Orchestration.
131-
132130
### What triggers a MaxSurge upgrade?
133131
Any changes that result in an update to the scale set model result in a MaxSurge upgrade. This includes upgrades that generally don't require a restart such as adding Data Disks.
134132

@@ -141,5 +139,5 @@ During a MaxSurge upgrade, new virtual machines are created to replace virtual m
141139

142140

143141
## Next steps
144-
Learn how to [set the upgrade policy](virtual-machine-scale-sets-set-upgrade-policy.md) of your Virtual Machine Scale Set.
142+
To learn more about upgrades for Virtual Machine Scale Sets, see [configure rolling upgrade policy](virtual-machine-scale-sets-set-configure-rolling-upgrades.md).
145143

0 commit comments

Comments
 (0)