Based on your feedback, today we are making some helpful updates to Windows Azure that provide developers flexibility for making in-place updates to deployed services. Best of all, these updates are easily made without changing the public IP of the service.
Windows Azure now supports a wider range of changes to a deployed service without requiring the use of a VIP swap or a complete delete and re-deploy of the service. With the following changes permitted through an in-place update, you will now be allowed to make almost all possible updates without requiring a VIP swap or a re-deploy!
The newly allowed in-place updates are:
- Change the virtual machine size (scale-up or scale-down)
- Increase local storage
- Add or remove roles to a deployment
- Change the number or type of endpoints
Summary of changes allowed
|
Changes permitted to hosting, services, and roles |
In-place update |
Staged (VIP swap) |
Delete and re-deploy |
|
Operating system version |
Yes |
Yes |
Yes |
|
.NET trust level |
Yes |
Yes |
Yes |
|
Virtual machine size |
Yes Warning Changing virtual machine size will destroy local data. When making this change using the service management APIs, the force flag is required Note Requires Windows Azure SDK 1.5 or later |
Yes |
Yes |
|
Local storage settings |
Yes Increase only. Note Requires Windows Azure SDK 1.5 or later |
Yes |
Yes |
|
Add or remove roles in a service |
Yes |
Yes |
Yes |
|
Number of instances of a particular role |
Yes |
Yes |
Yes |
|
Number or type of endpoints for a service |
Yes Note Requires Windows Azure SDK 1.5 or later.
Note Availability may be temporarily lost as endpoints are updated |
No |
Yes |
|
Names and values of configuration settings |
Yes |
Yes |
Yes |
|
Values (but not names) of configuration settings |
Yes |
Yes |
Yes |
|
Add new certificates |
Yes |
Yes |
Yes |
|
Change existing certificates |
Yes |
Yes |
Yes |
|
Deploy new code |
Yes |
Yes |
Yes |
Changing Virtual Machine Size example
The following example shows how to change the virtual machine size through the Windows Azure portal.
Figure 1: Initial state of the deployment
When attempting to change the size of the VM without checking the box for “Allow VM size or role count to be updated” the following error will be shown:
Figure 2: Error message when attempting to change role count
Now when the same operation is attempted with the “Allow VM size or role count to be updated” checkbox checked the VM size will be updated:
Figure 3: Update with the checkbox checked
Figure 4: Deployment after update has completed
More Control over in-place updates
In addition to the wider applicability of an in-place update, you now have greater control over the update process itself by being able to rollback an update that is in progress or even starting a second update. While an update is in progress (defined by at least one instance of the service not yet updated to the new version) you can roll back the update by using the Rollback Update Or Upgrade operation.
If the rollback operation is specified to be in automatic mode, the rollback will begin immediately in the first upgrade domain without waiting for all instances in the upgrade domain that is currently offline to return to the Ready state. To prevent multiple upgrade domains from being offline simultaneously the rollback can be done in manual mode. In manual mode the first upgrade domain will not be rolled back until Walk Upgrade Domain is called for the first upgrade domain.
Multiple Update Operations
Initiating a second update operation while the first update is ongoing will perform similar to the rollback operation. If the second update is in automatic mode, the first upgrade domain will be upgraded immediately, possibly leading to instances from multiple upgrade domains being offline at the same point in time. Further details on using the rollback operation or initiating multiple mutating operations can be found here.
Summary of Update Options
Now that most modification can be performed using any of the three options for updating a hosted service, it is worth taking some time to describe when each option is most appropriate. This is best described by the following table of advantages and disadvantages:
|
Update option |
Description |
Advantages |
Disadvantages |
|
The new package is uploaded and applied to the running instances of the service. |
Only a single running deployment is required.
Service availability can be maintained as long as there are at least two instances for each role. |
Service capacity is limited while instances are brought down, updated and then restarted. Service code must be able to support multiple versions of the code running on different instances as the instances are updated |
|
|
Upload the new package and swap it with the existing production version. This is referred to as a VIP swap because it simply swaps the visible IP addresses of the services. |
No service downtime or loss of capacity. |
Two deployments are required to be running at least during the update. |
|
|
Redeploy the service |
Suspend and then delete the service, and then deploy the new version. |
Only a single running deployment is required. |
Service will be down between deleting the service and redeploying the service.
Virtual IP (VIP) will often change when the service is redeployed. |
Further details on updating a Windows Azure service can be found here.