You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-machine-scale-sets/virtual-machine-scale-sets-maxsurge.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ ms.custom: upgradepolicy
18
18
>
19
19
> 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).
20
20
21
-
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 batch of 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.
21
+
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.
22
22
23
23
## Concepts
24
24
@@ -27,16 +27,16 @@ Rolling upgrades with MaxSurge can help improve service uptime during upgrade ev
27
27
28
28
|Setting | Description |
29
29
|---|---|
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. |
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 two 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 are successfully provisioned and are reporting as healthy, the scale set will wait 10 seconds before moving onto the next batch. |
32
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
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. |
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 are failed or unhealthy when a MaxSurge upgrade begins, the scale set replaces those instances first. |
35
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. |
36
36
37
37
## Considerations
38
38
39
-
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 will have new IP addresses and be 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.
39
+
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 be 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.
40
40
41
41
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)
42
42
@@ -50,13 +50,13 @@ Rolling upgrades with MaxSurge creates new instances with the latest scale set m
50
50
51
51
### In place upgrades
52
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.
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 doesn't consume any extra quota.
54
54
55
-
:::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.":::
55
+
:::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.":::
56
56
57
57
58
58
## Configure rolling upgrades with MaxSurge
59
-
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.
59
+
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 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.
60
60
61
61
62
62
### [Portal](#tab/portal)
@@ -128,7 +128,7 @@ Update the properties section of your ARM template and set the upgrade policy to
128
128
## Frequently asked questions
129
129
130
130
### What triggers a MaxSurge upgrade?
131
-
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.
131
+
Any changes that result in an update to the scale set model result in a MaxSurge upgrade. These also include upgrades that generally don't require a restart such as adding Data Disks.
132
132
133
133
### Can I cancel a MaxSurge upgrade?
134
134
Yes. The process of canceling a MaxSurge upgrade is the same as canceling an in place rolling upgrade. You can stop the upgrade from the Azure portal, CLI, PowerShell, or any other SDK.
0 commit comments