Microsoft Azure instances and the guest OS they reside in have to be upgraded occasionally. The Cloud Service might need a new software deployment or a configuration change. The guest OS might need a patch or an upgrade to a new version. To ensure that a Cloud Service can remain online 24/7 (an SLA of 99.95%), Microsoft Azure provides an upgrade capability that allows upgrades to be performed without stopping the Cloud Service completely as long as each role in the service has two or more instances.
Microsoft Azure supports two types of upgrade: in-place upgrade and Virtual IP swap. An in-place upgrade applies changes to the configuration and code of existing virtual machines (VM) that host instances of the Cloud Service. A VIP swap modifies the load-balancer configuration so that the VIP address of the production deployment is pointed at the instances that are currently in the staging slot, and the VIP address of the staging deployment is pointed at the instances currently in the production slot.
There are two types of in-place upgrades: configuration change and deployment upgrade. A configuration change can be applied on the Microsoft Azure Portal by editing the existing configuration directly on the portal. A configuration change or a deployment upgrade can be performed on the Microsoft Azure Portal by uploading a replacement service configuration file, ServiceConfiguration.cscfg, or by directly modifying the settings in the Configure tab of the Cloud Service web page. They can also be performed by invoking the appropriate operations in the Microsoft Azure Service Management REST API. By repeating the Publishing a Cloud Service with options from Visual Studio recipe, a deployment upgrade could be initiated directly from Visual Studio. Note that it is possible to do an in-place upgrade of an individual role in an application package.
A configuration change supports only modifications to the service configuration file, which includes changing the guest OS; changing the value of configuration settings such as connection strings, and changing the actual X.509 certificates used by the Cloud Service. Note that a configuration change cannot be used to change the names of configuration settings as they are specified in the service definition file.
A deployment upgrade supports changes to the application package as well as all the changes allowed in a configuration change. Additionally, a deployment upgrade supports some modifications to the ServiceDefinition.csdef service definition file. These modifications include changing the following:
Role type
The local resource definitions
The available configuration settings
The certificates defined for the Cloud Service
A Cloud Service has an associated set of upgrade domains that control the phasing of upgrades during an in-place upgrade. The instances of a role are distributed evenly among upgrade domains. During an in-place upgrade, all the instances in a single upgrade domain are stopped, reconfigured, and then restarted. This process continues with one upgrade domain at a time until all the upgrade domains have been upgraded. This phasing ensures that the Cloud Service remains available during an in-place upgrade, albeit with roles being served by fewer instances than usual. By default, there are five upgrade domains for a Cloud Service, although this number can be reduced/increased in the service definition file.
The only distinction between the production and staging slots of a Cloud Service is that the load balancer forwards any network traffic that arrives at the service VIP address to the production slot and any network traffic that arrives at the staging VIP address to the staging slot. In a VIP swap, the production and staging slots to which the load balancer forwards network traffic are swapped. This has no effect on the actual VMs running the service; it is entirely a matter of where inbound network traffic is forwarded to. A VIP swap affects the entire service simultaneously and does not use upgrade domains. Nevertheless, as a Cloud Service is a distributed system, there might be a small overlap during a VIP swap, where inbound traffic is forwarded to some instances that run the old version of the service and some instances that run the new version. The only way to guarantee that old and new versions are never simultaneously in production is to stop the Cloud Service while performing the upgrade.
Note that Microsoft occasionally has to upgrade the root OS of a server that hosts an instance. This type of upgrade is always automatic, and Microsoft provides no ability for it to be performed manually.
In this recipe, we'll learn how to upgrade a deployment to a Cloud Service.
We need to deploy an application to the production and staging slots of a Cloud Service. We could use, for example, the Cloud Service we created in the Using startup tasks in a Microsoft Azure role recipe.
We are going to use the Microsoft Azure Portal to perform an in-place upgrade, a VIP swap, and a manual guest OS upgrade. In this stage, we will perform an in-place upgrade of the production deployment using the following steps:
On the Microsoft Azure Portal, go to the Dashboard tab of the Cloud Service in the Cloud Services section and then choose the Production slot.
Click on Update and provide a deployment label, a package location, and a configuration location.
Choose the roles to update (this is optional) or click on All to update the entire service.
Click on either the Allow the update if role sizes change or if the number of roles change or Update the deployment even if one or more roles contain a single instance boxes and then confirm.
Repeat steps 1 to 4 in the staging slot.
Click on the Swap button to perform the VIP swap.
In the Configure tab of either the production or staging slot of the Cloud Service, locate the Operating system section.
Select the desired OS Family and OS Version, and press Save.
We can perform in-place upgrades of the production and staging slots independently of each other. In step 1, we indicated that we wanted to perform an in-place upgrade of the production slot. In step 2, we specified the details of the upgrade, such as the label and a location for the upgraded application package and service configuration file.
In step 3, we chose which roles have to be upgraded, as it is common to have just a few parts of the entire solution modified by an upgrade. In step 4, we told Azure to continue the upgrade even under those circumstances. Those checkboxes are intended as a double check to avoid unwanted downtime.
We can perform a VIP swap only if there is a Cloud Service deployed to the staging slot, and we ensured this in step 5. We initiated the VIP swap in step 6.
We can perform guest OS upgrades of the production and staging slots independently of each other. In step 7, we located the desired slot to upgrade the guest OS in. We initiated the guest OS upgrade in step 8.
In Chapter 7, Managing Azure Resources with the Azure Management Libraries, we will see how to use the Microsoft Azure Management libraries to manage deployments, including performing upgrades.
Have a look at the following MSDN links to get additional information:
Advanced scenarios about updating an Azure Cloud Service at http://msdn.microsoft.com/en-us/library/azure/hh472157.aspx
Swapping deployments using Management REST APIs at http://msdn.microsoft.com/en-us/library/azure/ee460814.aspx