Windows ">Azure 的计算平台（其中包括 Web Role、Worker Role 和虚拟机）基于计算机虚拟化。对基础操作系统的深入访问使 Windows Azure 的平台即服务 (PaaS) 与许多现有软件组件、运行时和语言唯一兼容，当然，如果没有这种深入访问（包括用户自己提供操作系统映像的能力），Windows Azure 的虚拟机则不能归类为基础设施即服务 (IaaS)。
主机操作系统和主机代理
当然，计算机虚拟化意味着，您的代码无论是部署在 PaaS Worker Role 还是 IaaS 虚拟机中，均在 Windows Server
Hyper-V 虚拟机中执行。每台 Windows Azure 服务器（也称为物理节点或主机）托管一个或多个虚拟机（称为“实例”），这包括在物理 CPU 内核上调度这些虚拟机、为它们分配专用 RAM，以及授权并控制对本地磁盘和网络 I/O 的访问。
下图显示了服务器软件体系结构的简化视图。主机分区（也称为根分区）将 Windows Server 的 Server Core 配置文件作为主机操作系统运行，您可以看到图解和标准 Hyper-V 体系结构图之间的唯一区别是，Windows Azure 结构控制器 (FC) 主机代理 (HA) 存在于主机分区中，此外在来宾分区中还有一个来宾代理 (GA)。FC 是 Windows Azure 计算平台的大脑，HA 是其代理，负责将服务器整合到平台中，以便 FC 可以部署、监控和管理定义 Windows Azure 云服务的虚拟机。只有 PaaS 角色具有 GA，它是 FC 的代理，可为角色提供运行时支持并监控角色的运行状况。
主机更新的原因
要确保 Windows Azure 为应用程序提供可靠、高效且安全的平台，需要提供具有安全性、可靠性和高性能的更新对主机操作系统和 HA 进行修补。正如您会考虑 Windows Update 重启您自己安装的 Windows 的频率，我们会以大约每月一次的频率将更新部署到主机操作系统。HA 由多个子组件组成，例如网络代理 (NA) 和虚拟机虚拟磁盘驱动程序，前者用于管理虚拟机 VLAN，后者用于将虚拟机磁盘连接到包含其在 Windows Azure 存储中的数据的 Blob。因此，我们会根据修补程序或新功能准备就绪的时间，以不同的时间间隔更新 HA 及其子组件。
部署更新时可以采取的步骤取决于更新的类型。例如，几乎所有与 HA 相关的更新在应用时都无需重新启动服务器。但是Windows 操作系统更新几乎总是至少有一个补丁，通常还可能有多个, 会导致重新启动。因此，我们让 FC 在每台服务器上“暂存”我们作为 VHD 部署的新版操作系统，然后 FC 会指示 HA 重新启动服务器以进入新的映像。
PaaS 更新流程
Windows Azure 的一个关键属性是其 PaaS 的横向扩展计算模型。当您在云服务中使用其中一种无状态虚拟机类型（无论是 Web 还是 Worker）时，您只需更新云服务配置中的角色实例数，即可轻松扩展和缩小角色。FC 将自动完成所有工作，以在您扩展时创建新虚拟机，在缩小时关闭并删除虚拟机。
然而，让 Windows Azure 的横向扩展模型如此独特的原因在于，它使模型的核心部分具有高可用性。FC 定义了一个称为更新域 (UD) 的概念，用于确保角色在要求实例重新启动的计划更新中可用，而不管这些更新是云服务所有者应用的角色更新（如角色代码更新），还是涉及服务器重新启动的主机更新（如主机操作系统更新）。FC 可以保证不会因为计划中的更新导致来自不同 UD 的实例同时脱机。默认情况下, 每个角色有5个UD, 不过云服务可以在其服务定义文件中申请多达 20 个 UD。下图显示了 FC 如何跨三个 UD 传播云服务的两个角色的实例。
角色实例可以调用运行时 API，以确定它们的 UD 和门户网站也显示角色实例到 UD 的映射。这里是一个具有两个角色的云服务，每个角色有两个实例，因此每个 UD 有每个角色的一个实例：
关于 UD，FC 针对云服务更新和主机更新的行为有所不同。当更新是云服务应用的更新时，FC 将依次更新每个 UD 的所有实例。仅当目前UD中所有实例重新启动并向 GA 报告自己正常运行时，或当云服务所有者要求 FC 通过服务管理 API 移动到下一个 UD 时，它才会移动到下一个 UD。
在主机更新期间，一个角色同时重新启动的实例的顺序和数量可能有所不同，而不是一次处理一个 UD。这是因为服务器上的实例放置可以防止 FC 重新启动服务器，在这些服务器上，UD 的所有实例同时被托管，甚至按 UD 顺序托管。考虑下图中服务器的实例分配。服务 A 的角色的实例 1 位于服务器 1 上，实例 2 位于服务器 2 上，而服务 B 的实例则按相反顺序放置。不管 FC 按什么顺序重新启动服务器，服务都会以与其 UD 相反的顺序重新启动实例。所示的分配是比较少见的，因为 FC 分配算法通过尝试在同一服务器上放置来自相同 UD 的实例来进行优化，而不管这些实例属于什么服务。但此分配是有效分配，因为 FC 可以重新启动服务器，而不违反它不会导致（单一服务的）相同角色的不同 UD 的实例同时脱机的承诺。
主机更新和云服务更新之间的另一个区别是，当更新为主机更新时，FC 必须确保实例不会无限期拖延整个数据中心的服务器更新进度。因此，FC 会在最多五分钟内分配实例，然后将服务器重新启动到新的主机操作系统，而角色实例会在重新启动后最多 15 分钟内报告其正常运行。依次重新启动主机、VM 和 GA，最后启动角色实例代码，此过程需要几分钟，因此实例通常会在 15 到 30 分钟之间脱机，具体取决于该实例和任何其他共享服务器的实���关闭和重新启动分别需要多长时间。有关主机操作系统更新过程中 Web role 和 Worker role 的预期状态变化的更多详细信息，请单击此处。请注意，对于 PaaS 服务，FC 还会为来宾管理操作系统服务，因此在执行主机操作系统更新后通常会执行相应的来宾操作系统更新（针对选择更新的 PaaS 服务），后者由 UD 像其他云服务更新一样实施更新。
IaaS 和主机更新
前面的讨论围绕 PaaS 角色，它会在角色横向扩展时自动获得 UD 的益处。另一方面，虚拟机实质上是没有横向扩展能力的单实例角色。IaaS 功能版本的一个重要目标是使虚拟机能够在主机更新和硬件故障时实现高可用性，可用性集功能的作用就体现在这里。您可以使用 PowerShell 命令或 Windows Azure 管理门户将虚拟机添加到可用性集。下面是具有分配到可用性集的虚拟机的示例云服务：
正如角色一样，默认情况下可用性集有 5 个 UD，最多支持 20 个 UD。FC 跨 UD 将分配的实例传播到可用性集，如下图中所示。这使客户能够将专为高可用性设计的虚拟机（例如为 SQL Server 镜像配置的两个虚拟机）部署到可用性集，这可确保主机更新将导致只有一半的镜像同时重新启动，如此处所述（本文将不讨论这一点，但 FC 还使用一种称为故障域的功能来跨服务器自动传播角色和可用性集的实例，以便数据中心的任何单个硬件故障最多影响一半实例）。
更多信息
您可以在 Windows Azure 会议中找到有关更新域、故障域和可用性集的更多信息，您还可以单击此处，在 Mark 的网络直播页面找到相关会议视频。Windows Azure MSDN 文档介绍了主机操作系统更新和更新域的服务定义架构。