Windows Azure Host OS Updates

Windows Azure updates the operating system in the root partition, sometimes referred to as the host OS, at least every quarter to keep the environment secure for all customer applications running on the platform. The virtualization architecture used by Windows Azure is similar to that of Windows Hyper-V. It includes a root partition that hosts the Windows Azure root partition OS and Windows Azure agent that’s responsible for creating child partitions to execute Windows Azure services on the Windows Azure guest OS.

Updating the Windows Azure root partition OS and Windows Azure Hypervisor requires that the virtual machines on the server being updated are shut down and subsequently restarted. To implement the Windows Azure SLA, Windows Azure must not simultaneously shut down virtual machines hosting different update domains of the same Windows Azure service role. To make sure that it does not do so, Windows Azure determines the optimal order to update servers while honoring update domain constraints. For more information on the Windows Azure SLA, see Service Level Agreements.

Once Windows Azure initiates the update of a server, it proceeds according to the following steps:

1. Virtual machines running on the server that have an Input Endpoint in their role’s service model are removed from the load balancer rotation so that no new requests will come to the virtual machine and instead new requests are sent to other instances of that role as per the Windows Azure load-balancing policies.
   
   
2. Each virtual machine hosting a Web or Worker Role receives a Stopping event, whereas VM Roles receive a standard Windows shutdown event.
   
   
3. Worker, Web, and Virtual machine roles are allowed five minutes to respond to the stopping and shutdown event before they are forcibly stopped.
   
   
4. After all guest virtual machines are stopped, the root partition OS shuts down and the server reboots.
   
   
5. The updated root partition OS starts.
   
   
6. The virtual machines hosted on the server boot and start their application code.
   
   
7. Virtual machines hosting service roles with Input Endpoints reconnect to the load balancer, enabling them to receive client requests.
   
   

Windows Azure waits until the role code in each virtual machine on an updated server enters the Ready state before updating different servers that host the same roles, but that reside in different update domains. However, to guarantee a timely update for a secure platform, each role instance has only 15 minutes to reach the healthy Ready state before Windows Azure stops waiting and starts updating other servers, potentially hosting roles of different update domains. The 15 minute timer starts when a role instance begins executing Startup tasks.

Note
Due to this behavior, if you have startup tasks or code in the OnStart method which takes longer than 15 minutes, you may have role instances from multiple upgrade domains offline at the same time, which may affect your service availability.

See Also