Windows Azure Host Update: Reason, time, and manner

Windows http://www.aliyun.com/zixun/aggregation/13357.html ">azure computing platforms, which include WEB role, Worker role, and virtual machines, are based on computer virtualization. Deep access to the underlying operating system makes Windows Azure's platform, a service (PaaS), uniquely compatible with many existing software components, runtimes, and languages, and of course, without this in-depth access, including the ability of users to provide their own operating system images, Windows Azure Virtual machines cannot be categorized as infrastructure or services (IaaS).

Host operating systems and host agents

Of course, computer virtualization means that your code, whether deployed in PaaS Worker role or IaaS virtual machine, is in Windows Server
The Hyper-V virtual machine executes. Each Windows Azure server (also known as a physical node or host) hosts one or more virtual machines (called "instances"), which include scheduling these virtual machines on the physical CPU kernel, allocating private RAM to them, and authorizing and controlling access to local disks and network I/O.

The following illustration shows a simplified view of the Server Software architecture. The host partition (also known as the root partition) runs the server Core profile of Windows Server as the host operating system, and you can see that the only difference between the diagram and the standard Hyper-V architecture diagram is that the Windows Azure Architecture Controller (FC) host agent ( HA) exists in the host partition, and there is also a guest agent (GA) in the guest partition. FC is the brain of the Windows Azure computing platform, and HA is its agent responsible for consolidating servers into the platform so that FC can deploy, monitor, and manage virtual machines that define Windows Azure cloud services. Only the PaaS role has GA, which is the agent of FC, provides run-time support for the role, and monitors the health of the role.

Host Update Reason

To ensure that Windows Azure provides a reliable, efficient, and secure platform for your applications, you need to provide security, reliability, and high performance updates to fix the host operating system and HA. As you consider the frequency with which Windows Update restarts your own installed Windows, we deploy updates to the host operating system at approximately the monthly rate. HA consists of multiple subcomponents, such as network Proxy (NA) and virtual machine virtual disk drivers, which are used to manage virtual machine VLANs, which are used to connect a virtual machine disk to a BLOB containing data in its Windows Azure store. So we update HA and its subcomponents at different intervals, depending on when the patch or new feature is ready.

The steps that you can take when you deploy an update depend on the type of update. For example, almost all HA-related updates do not need to reboot the server when applied. However, Windows operating system updates almost always have at least one patch, often with multiple, causing a reboot. Therefore, we have FC "staging" The new operating system that we deploy as a VHD on each server, and FC instructs HA to reboot the server to enter the new image.

PaaS update process

A key attribute of Windows Azure is its PaaS scale-out computing model. When you use one of these stateless virtual machine types (whether Web or Worker) in a cloud service, you can easily expand and shrink roles by simply updating the number of role instances in the cloud service configuration. FC will automatically do all the work to create a new virtual machine when you expand, and close and remove the virtual machine when you zoom out.

However, the reason that the scale-out model of Windows Azure is so unique is that it makes the core of the model highly available. FC defines a concept called an update domain (UD), used to ensure that roles are available in scheduled updates that require instance restarts, whether they are role updates that are applied by the cloud service owner, such as role code updates, or host updates that involve server restarts, such as host operating system updates. FC can guarantee that an instance of a different UD will not be taken offline as a result of a scheduled update. By default, each role has 5 UD, but the cloud service can request up to 20 UD in its service definition file. The following figure shows how FC can propagate two roles of cloud services across three UD.

Role instances can invoke the Run-time APIs to determine that their UD and portal sites also display role instances to UD mappings. Here is a two-character cloud service with two instances per role, so each UD has an instance of each role:

About UD,FC behavior is different for cloud service updates and host updates. When an update is an update to the cloud service application, FC updates all instances of each UD in turn. It moves to the next UD only if all instances in the current UD are restarted and reported to the GA as normal, or when the cloud service owner requires FC to move through the service management API to the next UD.

During a host update, the sequence and number of instances in which a role restarts simultaneously may vary, rather than processing one UD at a time. This is because instance placement on the server prevents FC from restarting the server, where all instances of UD are hosted and even managed in UD order. Consider the instance assignments for the server in the following figure. Instance 1 of service A's role is on server 1, instance 2 is on server 2, and instances of service B are placed in reverse order. Regardless of the order in which the FC restarts the server, the service restarts the instance in the reverse order of its UD. The allocation shown is relatively rare because the FC allocation algorithm attempts to optimize by placing instances from the same UD on the same server, regardless of the service to which these instances belong. However, this allocation is a valid assignment because FC can restart the server without violating the commitment that it will not cause instances of different UD of the same role to be taken offline at the same time (single service).

Another difference between host updates and cloud service updates is that when updates are updated for hosts, FC must ensure that the instance does not indefinitely delay the progress of server updates throughout the datacenter. As a result, FC allocates the instance within a maximum of five minutes and then restarts the server to the new host operating system, and the role instance reports its normal operation for up to 15 minutes after reboot. Restart the host, VM, and GA, and finally start the role instance code, which takes several minutes, so the instance typically goes offline in 15-30 minutes, depending on how long the instance and any other shared servers are actually shut down and restarted. For more detailed information about the expected state changes in Web role and Worker role during host operating system updates, click here. Note that for the PaaS service, FC also manages the operating system services for the guest, so after performing the host operating system update, the corresponding guest operating system update is typically performed (for the PAAs service that chooses to update), which is implemented by UD like other cloud service updates.

IaaS and host Updates

The preceding discussion revolves around the PaaS role, which automatically gains the benefits of UD when the role is scaled horizontally. Virtual machines, on the other hand, are essentially single instance roles that do not have horizontal scaling capabilities. An important goal of the IaaS feature version is to enable the virtual machine to achieve high availability in the case of host updates and hardware failures, and the availability set function is here. You can use the PowerShell command or the Windows Azure management portal to add virtual machines to the set of availability. The following is a sample cloud service with virtual machines assigned to the availability set:

As with roles, the availability set has 5 UD by default and supports up to 20 UD. FC Cross UD propagates an assigned instance to a set of availability, as shown in the following figure. This enables customers to deploy virtual machines designed for high availability, such as the two virtual machines configured for SQL Server mirroring, to the availability set. This ensures that the host update will cause only half of the mirrors to be restarted at the same time, as described here (this will not be discussed in this article, but FC You also use a feature called a fault domain to automatically propagate instances of roles and availability sets across servers so that any single hardware failure in the data center affects up to half of the instances.

More information

You can find more information about updating the domain, fault domain, and availability set in the Windows Azure meeting, and you can click here to find the relevant meeting video on Mark's webcast page. The Windows Azure MSDN documentation describes the host operating system update and the service definition schema for the update domain.