Skip to content

Commit 56dfb41

Browse files
authored
Merge pull request #281278 from MicrosoftDocs/release-maxsurge-ga
Standing PR - MaxSurge Updates
2 parents 13dfa17 + eff0335 commit 56dfb41

9 files changed

+164
-10
lines changed

articles/virtual-machine-scale-sets/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -151,6 +151,8 @@
151151
href: virtual-machine-scale-sets-change-upgrade-policy.md
152152
- name: Configure rolling upgrade policy
153153
href: virtual-machine-scale-sets-configure-rolling-upgrades.md
154+
- name: Rolling upgrades with MaxSurge
155+
href: virtual-machine-scale-sets-maxsurge.md
154156
- name: Performing manual upgrades
155157
href: virtual-machine-scale-sets-perform-manual-upgrades.md
156158
- name: Reimage a virtual machine
23.7 KB
Loading
18.2 KB
Loading
23.5 KB
Loading
30.3 KB
Loading
46.9 KB
Loading

articles/virtual-machine-scale-sets/virtual-machine-scale-sets-configure-rolling-upgrades.md

Lines changed: 12 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -5,18 +5,18 @@ author: mimckitt
55
ms.author: mimckitt
66
ms.topic: how-to
77
ms.service: virtual-machine-scale-sets
8-
ms.date: 6/14/2024
8+
ms.date: 7/23/2024
99
ms.reviewer: ju-shim
10-
ms.custom: upgradepolicy, devx-track-azurepowershell
10+
ms.custom: upgradepolicy, maxsurge
1111
---
1212
# Configure rolling upgrades on Virtual Machine Scale Sets (Preview)
1313

1414
> [!NOTE]
1515
> Rolling upgrade policy for Virtual Machine Scale sets with Uniform Orchestration is in general availability (GA).
1616
>
17-
> **Rolling upgrade policy for Virtual Machine scale Sets with Flexible Orchestration is currently in preview.**
18-
>
19-
> **MaxSurge for Virtual Machine Scale Sets with Flexible Orchestration and Uniform Orchestration is currently in preview.**
17+
> **MaxSurge for Virtual Machine scale Sets with Uniform Orchestration is currently in preview.**
18+
>
19+
> **Rolling upgrade policy and MaxSurge for Virtual Machine scale Sets with Flexible Orchestration is currently in preview.**
2020
>
2121
> Previews are made available to you on the condition that you agree to the [supplemental terms of use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/). Some aspects of these features may change prior to general availability (GA).
2222
@@ -48,16 +48,19 @@ Register-AzProviderFeature -FeatureName MaxSurgeRollingUpgrade -ProviderNamespac
4848

4949
## Concepts
5050

51+
> [!NOTE]
52+
> [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.
53+
5154
|Setting | Description |
5255
|---|---|
5356
|**Upgrade Policy Mode** | The upgrade policy modes available on Virtual Machine Scale Sets are **Automatic**, **Manual**, and **Rolling**. |
5457
|**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. |
5558
|**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. |
5659
|**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. |
5760
| **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. |
58-
|**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. |
61+
|**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 are failed or unhealthy when a rolling upgrade begins, the scale set updates those instances first. |
5962
| **Enable cross-zone upgrade** | Allows the scale set to ignore Availability Zone boundaries when determining batches. |
60-
| **MaxSurge (Preview)** | With MaxSurge enabled, new instances are created in batches using the latest scale model. Once the batch of new instances are successfully created and marked as healthy, they begin taking traffic. The scale set then deletes instances in batches matching the old scale set model. This continues until all instances are brought up-to-date. rolling upgrades with MaxSurge can help improve service uptime during upgrade events. <br><br>With MaxSurge disabled, the existing instances in a scale set are brought down in batches to be upgraded. Once the upgraded batch is complete, the instances begin taking traffic again, and the next batch begins. This continues until all instances brought up-to-date. |
63+
| **MaxSurge (Preview)** | With MaxSurge enabled, new instances are created in batches using the latest scale model. Once the batch of new instances is successfully created and marked as healthy, they begin taking traffic. The scale set then deletes instances in batches matching the old scale set model. This continues until all instances are brought up-to-date. rolling upgrades with MaxSurge can help improve service uptime during upgrade events. <br><br>For more information see [MaxSurge rolling upgrades](virtual-machine-scale-sets-maxsurge.md). |
6164

6265

6366
## Setting or updating the rolling upgrade policy
@@ -248,7 +251,7 @@ Stop-AzVmssRollingUpgrade `
248251
If you decide to cancel a rolling upgrade or the upgrade has stopped due to any policy breach, any more changes that result in another scale set model change trigger a new rolling upgrade. If you want to restart a rolling upgrade, trigger a generic model update. This tells the scale set to check if all the instances are up to date with the latest model.
249252

250253
### [CLI](#tab/cli4)
251-
To restart a rolling upgrade after its been canceled, you need to trigger the scale set to check if the instances in the scale set are up to date with the latest scale set model. You can do this by running [az vmss update](/cli/azure/vmss#az-vmss-update).
254+
To restart a rolling upgrade after it has been canceled, trigger the scale set to check if the instances in the scale set are up to date with the latest scale set model. You can do this by running [az vmss update](/cli/azure/vmss#az-vmss-update).
252255

253256
```azurecli
254257
az vmss update \
@@ -257,7 +260,7 @@ az vmss update \
257260
```
258261

259262
### [PowerShell](#tab/powershell4)
260-
To restart a rolling upgrade after its been canceled, you need to trigger the scale set to check if the instances in the scale set are up to date with the latest scale set model. You can do this by running [Update-AzVmss](/powershell/module/az.compute/update-azvmss).
263+
To restart a rolling upgrade after it's been canceled, you need to trigger the scale set to check if the instances in the scale set are up to date with the latest scale set model. You can do this by running [Update-AzVmss](/powershell/module/az.compute/update-azvmss).
261264

262265
```azurepowershell
263266
$VMSS = Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
Lines changed: 143 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,143 @@
1+
---
2+
title: Rolling upgrades with MaxSurge for Virtual Machine Scale Sets (preview)
3+
description: Learn about how to utilize rolling upgrades with MaxSurge on Virtual Machine Scale Sets.
4+
author: mimckitt
5+
ms.author: mimckitt
6+
ms.topic: overview
7+
ms.service: virtual-machine-scale-sets
8+
ms.date: 7/23/2024
9+
ms.reviewer: ju-shim
10+
ms.custom: upgradepolicy. maxsurge
11+
---
12+
# Rolling upgrades with MaxSurge on Virtual Machine Scale Sets (Preview)
13+
14+
> [!NOTE]
15+
> **Rolling upgrades with MaxSurge for Virtual Machine Scale Sets is currently in preview.**
16+
>
17+
> Previews are made available to you on the condition that you agree to the [supplemental terms of use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/). Some aspects of these features may change prior to general availability (GA).
18+
19+
Rolling upgrades with MaxSurge can help improve service uptime during upgrade events. With MaxSurge enabled, new instances are created in batches using the latest scale model. When the new instances are fully created and healthy, they begin taking traffic. The scale set then deletes instances in batches matching the old scale set model. The process continues until all instances are brought up-to-date.
20+
21+
## Prerequisites
22+
23+
Before configuring a rolling upgrade policy on a Virtual Machine Scale Set with Flexible Orchestration or enabling MaxSurge on either Flexible or Uniform Orchestration deployments, register the feature providers to your subscription.
24+
25+
## Feature Registration
26+
27+
```azurepowershell-interactive
28+
Register-AzProviderFeature -FeatureName VMSSFlexRollingUpgrade -ProviderNameSpace Microsoft.Compute
29+
30+
Register-AzProviderFeature -FeatureName MaxSurgeRollingUpgrade -ProviderNamespace Microsoft.Compute
31+
```
32+
33+
34+
## Concepts
35+
36+
> [!NOTE]
37+
> [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.
38+
39+
|Setting | Description |
40+
|---|---|
41+
|**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 two instances being created in each batch. |
42+
|**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 are successfully provisioned and are reporting as healthy, the scale set will wait 10 seconds before moving onto the next batch. |
43+
|**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. |
44+
|**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. |
45+
|**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 are failed or unhealthy when a MaxSurge upgrade begins, the scale set replaces those instances first. |
46+
|**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. |
47+
48+
## Considerations
49+
50+
When using rolling upgrades with MaxSurge, new virtual machines are created using the latest scale set model to replace virtual machines using the old scale set model. These newly created virtual machines counts towards your overall core quota. Additionally, these new virtual machines have new IP addresses and are placed into an existing subnet. You also need to have enough IP address quota and subnet space available to deploy these newly created virtual machines.
51+
52+
During the rolling upgrade processes, Azure performs a quota check before each new batch. If that quota check fails, the rolling upgrade will be canceled. You can restart a rolling upgrade by making a new change to the scale set model or triggering a generic model update. For more information, see [restart a rolling upgrade](virtual-machine-scale-sets-configure-rolling-upgrades.md#restart-a-rolling-upgrade).
53+
54+
## MaxSurge vs in place upgrades
55+
56+
### MaxSurge upgrades
57+
58+
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.
59+
60+
:::image type="content" source="./media/upgrade-policy/maxsurge-upgrade.png" alt-text="Diagram that shows the process of performing a rolling upgrade with MaxSurge.":::
61+
62+
### In place upgrades
63+
64+
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 doesn't consume any extra quota.
65+
66+
:::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.":::
67+
68+
69+
## Configure rolling upgrades with MaxSurge
70+
Enabling or disabling MaxSurge can be done during or after scale set provisioning. When using a rolling upgrade policy, the scale set must also use an [Application Health Extension](virtual-machine-scale-sets-health-extension.md) or 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.
71+
72+
73+
74+
75+
### [Portal](#tab/portal)
76+
77+
Select the Virtual Machine Scale Set you want to change the upgrade policy for. In the menu under **Settings**, select **Upgrade Policy** and from the drop-down menu, select **Rolling - Upgrades roll out in batches with optional pause**.
78+
79+
:::image type="content" source="../virtual-machine-scale-sets/media/upgrade-policy/rolling-upgrade-policy-portal.png" alt-text="Screenshot showing updating the upgrade policy and enabling MaxSurge in the Azure portal.":::
80+
81+
### [CLI](#tab/cli)
82+
Update an existing Virtual Machine Scale Set using [az vmss update](/cli/azure/vmss#az-vmss-update).
83+
84+
```azurecli-interactive
85+
az vmss update \
86+
--name myScaleSet \
87+
--resource-group myResourceGroup \
88+
--set upgradePolicy.mode=Rolling \
89+
--max-batch-instance-percent 10 \
90+
--max-unhealthy-instance-percent 20 \
91+
--max-unhealthy-upgraded-instance-percent 20 \
92+
--prioritize-unhealthy-instances true \
93+
--pause-time-between-batches PT2S \
94+
--max-surge true
95+
96+
```
97+
98+
### [PowerShell](#tab/powershell)
99+
Update an existing Virtual Machine Scale Set using [Update-AzVmss](/powershell/module/az.compute/update-azvmss).
100+
101+
```azurepowershell-interactive
102+
$vmss = Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
103+
104+
Set-AzVmssRollingUpgradePolicy `
105+
-VirtualMachineScaleSet $VMSS `
106+
-MaxBatchInstancePercent 20 `
107+
-MaxUnhealthyInstancePercent 20 `
108+
-MaxUnhealthyUpgradedInstancePercent 20 `
109+
-PauseTimeBetweenBatches "PT30S" `
110+
-EnableCrossZoneUpgrade True `
111+
-PrioritizeUnhealthyInstance True `
112+
-MaxSurge True
113+
114+
Update-Azvmss -ResourceGroupName "myResourceGroup" `
115+
-Name "myScaleSet" `
116+
-UpgradePolicyMode "Rolling" `
117+
-VirtualMachineScaleSet $vmss
118+
```
119+
120+
### [ARM Template](#tab/template)
121+
122+
Update the properties section of your ARM template and set the upgrade policy to rolling and various rolling upgrade options.
123+
124+
125+
``` ARM Template
126+
"properties": {
127+
"singlePlacementGroup": false,
128+
"upgradePolicy": {
129+
"mode": "Rolling",
130+
"rollingUpgradePolicy": {
131+
"maxBatchInstancePercent": 20,
132+
"maxUnhealthyInstancePercent": 20,
133+
"maxUnhealthyUpgradedInstancePercent": 20,
134+
"pauseTimeBetweenBatches": "PT2S",
135+
"MaxSurge": "true"
136+
}
137+
}
138+
}
139+
```
140+
---
141+
## Next steps
142+
To learn more about upgrades for Virtual Machine Scale Sets, see [configure rolling upgrade policy](./virtual-machine-scale-sets-configure-rolling-upgrades.md).
143+

articles/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy.md

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
title: Upgrade policies for Virtual Machine Scale Sets (Preview)
2+
title: Upgrade policies for Virtual Machine Scale Sets (preview)
33
description: Learn about the different upgrade policies available for Virtual Machine Scale Sets.
44
author: mimckitt
55
ms.author: mimckitt
@@ -29,6 +29,8 @@ Additionally, there can be situations where you might want specific instances in
2929

3030
With an automatic upgrade policy, the scale set makes no guarantees about the order of virtual machines being brought down. The scale set might take down all virtual machines at the same time to perform upgrades.
3131

32+
:::image type="content" source="./media/upgrade-policy/automatic-upgrade.png" alt-text="Diagram that shows a high level diagram of what happens when using an automatic upgrade policy.":::
33+
3234
Automatic upgrade policy is best suited for DevTest scenarios where you aren't concerned about the uptime of your instances while making changes to configurations and settings.
3335

3436
If your scale set is part of a Service Fabric cluster, *Automatic* mode is the only available mode. For more information, see [Service Fabric application upgrades](../service-fabric/service-fabric-application-upgrade.md).
@@ -37,13 +39,17 @@ If your scale set is part of a Service Fabric cluster, *Automatic* mode is the o
3739

3840
With a manual upgrade policy, you choose when to update the scale set instances. Nothing happens automatically to the existing virtual machines when changes occur to the scale set model. New instances added to the scale set use the most update-to-date model available.
3941

42+
:::image type="content" source="./media/upgrade-policy/manual-upgrade.png" alt-text="Diagram that shows a high level diagram of what happens when using a manual upgrade policy.":::
43+
4044
Manual upgrade policy is best suited for workloads where you require more control over when and how instances are updated.
4145

4246
### Rolling upgrade policy
4347

4448

4549
With a rolling upgrade policy, the scale set performs updates in batches. You also get more control over the upgrades with settings like batch size, max healthy percentage, prioritizing unhealthy instances and enabling upgrades across availability zones.
4650

51+
:::image type="content" source="./media/upgrade-policy/rolling-upgrade.png" alt-text="Diagram that shows a high level diagram of what happens when using a rolling upgrade policy.":::
52+
4753
Rolling upgrade policy is best suited for production workloads that require a set number of instances always be available. Rolling upgrades is safest way to upgrade instances to the latest model without compromising availability and uptime.
4854

4955
When using a rolling upgrade policy on Virtual Machine Scale Sets with Flexible Orchestration, the scale set must also use the [Application Health Extension](virtual-machine-scale-sets-health-extension.md) to monitor application health.

0 commit comments

Comments
 (0)