Azure Host OS Updates
Updated: November 13, 2014
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 Azure is similar to that of Windows Hyper-V. It includes a root partition that hosts the Azure root partition OS and Azure agent that’s responsible for creating child partitions to execute Azure services on the Azure guest OS.
Updating the Azure root partition OS and Azure Hypervisor requires that the virtual machines on the server being updated are shut down and subsequently restarted. To implement the Azure SLA, Azure must not simultaneously shut down virtual machines hosting different update domains of the same Azure service role. To make sure that it does not do so, Azure determines the optimal order to update servers while honoring update domain constraints. For more information on the Azure SLA, see Service Level Agreements.
Once Azure initiates the update of a server, it proceeds according to the following steps:
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 Azure load-balancing policies.
Each virtual machine hosting a Web or Worker Role receives a Stopping event, whereas VM Roles receive a standard Windows shutdown event.
Worker, Web, and Virtual machine roles are allowed five minutes to respond to the stopping and shutdown event before they are forcibly stopped.
After all guest virtual machines are stopped, the root partition OS shuts down and the server reboots.
The updated root partition OS starts.
The virtual machines hosted on the server boot and start their application code.
Virtual machines hosting service roles with Input Endpoints reconnect to the load balancer, enabling them to receive client requests.
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 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.
|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.|