更新管理器的工作原理
更新管理器评估和应用适用于 Windows 与 Linux 的所有 Azure 计算机和已启用 Azure Arc 的服务器的更新。
更新管理器 VM 扩展
在已启用 Azure 或 Arc 的服务器上启用或触发 Azure 更新管理器操作 (AUM) 时,AUM 将分别在计算机上安装 Azure 扩展或已启用 Arc 的服务器扩展来管理更新。
首次在计算机上启动任何更新管理器操作(例如检查更新、安装一次性更新、定期评估或首次在计算机上运行计划的更新部署)时,将自动在计算机上安装扩展。
客户不必显式安装扩展及其生命周期,因为它由 Azure 更新管理器管理,包括安装和配置。 更新管理器扩展是使用以下代理安装和管理的,更新管理器在计算机上工作需要这些代理:
- 适用于 Azure VM 的 Azure VM Windows 代理或 Azure VM Linux 代理。
- 已启用 Azure Arc 的服务器代理
注意
Arc 连接是更新管理器、非 Azure 计算机(包括已启用 Arc 的 VMWare、SCVMM 等)的先决条件。
对于 Azure 计算机,将安装单一扩展,而对于已启用 Azure Arc 的计算机,则需要安装两个扩展。 下面是安装的扩展的详细信息:
操作系统 | 分机 |
---|---|
Windows | Microsoft.CPlat.Core.WindowsPatchExtension |
Linux | Microsoft.CPlat.Core.LinuxPatchExtension |
更新源
Azure 更新管理器遵循计算机上的更新源设置,并相应地提取更新。 AUM 不会发布或提供更新。
如果将 Windows 更新代理 (WUA) 配置为从 Windows 更新存储库或 Microsoft 更新存储库或 Windows Server Update Services (WSUS) 提取更新,则 AUM 将遵循这些设置。 有关详细信息,请参阅如何配置 Windows 更新客户端。 默认情况下,它配置为从 Windows 更新存储库中提取更新。
AUM 执行以下步骤:
- 检索 Windows 更新客户端或 Linux 包管理器为操作系统指定的系统更新的状态评估信息。
- 启动通过 Windows 更新客户端或 Linux 包管理器下载和安装更新的过程。
注意
- 计算机将根据配置为与其同步的源报告其更新状态。 如果 Windows 更新服务配置为向 WSUS 报告,则更新管理器中的结果可能与 Microsoft 更新所显示的内容不同,具体取决于 WSUS 上次与 Microsoft 更新同步的时间。 对于配置为向本地存储库(而不是公共包存储库)报告的 Linux 计算机来说,此行为也是如此。
- 更新管理器将仅查找 Windows 更新服务在你选择本地 Windows 系统上的本地“检查更新”按钮时找到的更新。 在 Linux 系统上,只会发现本地存储库上的更新。
Azure Resource Graph 中存储的更新数据
更新管理器扩展将所有挂起的更新信息和更新安装结果推送到 Azure Resource Graph,其中保留以下时间段的数据:
Data | Azure Resource Graph 中的保持期 |
---|---|
挂起的更新(ARG 表名称:patchassessmentresources) | 七天 |
更新安装结果(ARG 表名称:patchinstallationresources) | 30 天 |
有关详细信息,请参阅 Azure Resource Graph 的日志结构,以及示例查询。
如何在 Azure 更新管理器中安装修补程序
在 Azure 更新管理器中,以以下方式安装修补程序:
它首先对 VM 上的可用更新进行新的评估。
更新安装遵循评估。
- 在 Windows 中,符合客户条件的所选更新将逐个安装,
- 而在 Linux 中,它们分批安装。
在更新安装期间,系统会通过多个步骤检查维护时段的使用。 对于 Windows 和 Linux,将在维护时段中分别留出 10 分钟和 15 时间以便随时重新启动。 在继续安装剩余更新之前,它会检查预期的重新启动时间加上平均更新安装时间(对于下一个更新或下一组更新)是否不会超过维护时段。 对于 Windows,除 Service Pack 更新外,所有类型的更新的平均更新安装时间为 10 分钟。 对于 Service Pack 更新,时间为 15 分钟。
请注意,即使更新安装超过维护时段,也不会强行停止正在进行的更新安装(一旦根据上述计算启动),以避免计算机处于可能不确定的状态。 但是,在超过维护时段后,它不会继续安装剩余的更新,在这种情况下会引发维护时段超时错误。
仅当安装了所有所选更新并且涉及的所有操作(包括重新启动和评估)都成功时,修补/更新安装才会标记为“成功”。 否则,它会标记为“失败”或“已完成”,并显示警告。 例如,
场景 更新安装状态 所选更新之一无法安装。 已失败 重新启动不会因任何原因而发生且重新启动等待时间超时。 已失败 计算机在重新启动期间无法启动。 已失败 初始或最终评估失败 已失败 更新需要重新启动,但“从不重新启动”选项处于选中状态。 已完成但出现警告 如果 Ubuntu pro 许可证不存在,则 ESM 包会跳过 ubuntu 18 或更低版本的修补。 已完成但出现警告 系统会在结束时进行评估。 请注意,在某些情况下,更新安装结束时可能不会发生重新启动和评估过程,例如,超出维护时段的情况,更新安装因某些原因而失败的情况等等。