在 Windows Server 故障转移群集环境中，保持系统补丁及时安装和维持业务连续性往往是矛盾的。群集感知更新（Cluster-Aware Updating，简称 CAU）是微软内置于故障转移群集角色的一项自动化更新编排功能，它能够在群集节点逐个离线的过程中，把高可用角色无缝迁移到其他节点，从而实现整个群集打完补丁却不让用户感知到服务中断。CAU 并不是简单的 Windows Update 调度器，而是一套理解群集拓扑、资源组依赖和仲裁状态的协调框架。借助 CAU，管理员无需半夜手动暂停节点、迁移虚拟机、安装更新再恢复，整个过程可以像滚动升级一样自动完成。
CAU 的核心工作机制与运行模式
CAU 的本质是一个运行在群集之上的更新协调器。它会读取群集节点的成员关系，按照预设顺序每次挑出一个节点进入“更新中”状态。被选中节点会先触发排水操作，也就是通过 Move-ClusterGroup 把该节点承载的虚拟机、文件共享、SQL 实例等资源组转移到健康节点。排水完成后，CAU 调用目标节点本地的 Windows Update 客户端或 WSUS 接口拉取补丁，安装后按需重启，等节点重新加入群集且通过健康探测，再把资源组回迁，接着处理下一个节点。整个过程有全局锁保护，防止多个节点同时更新破坏群集仲裁。
CAU 提供两种运行模式。自更新模式（Self-Updating）是在群集内部选举一个协调者节点，由它按照计划任务周期性驱动更新，适合无人值守的常规补丁日。远程更新模式（Remote-Updating）则由一台域内的管理机通过 Invoke-CauRun 命令远程连接群集并掌控流程，管理员可以实时看到每个节点的阶段。两种模式都依赖群集名称对象与 C$ 管理共享，因此域信任与防火墙放行 445 端口是前置条件。
从底层看，CAU 在每次节点切换时都会向群集数据库写入一个全局锁，防止两个节点同时被排水导致仲裁丢失。如果某个节点在重启后迟迟不在线，CAU 会依据 Update Run Profile 里配置的超时阈值判定失败并暂停整个运行，避免半更新状态扩散。理解这个锁机制，是排查“更新卡在 50%”问题的关键。此外，CAU 会在开始更新前自动检查所有节点是否具备相同的 CAU 插件版本和更新服务器配置，不一致时会直接报告预检失败，防止版本漂移。
更新运行配置文件的定制与脚本扩展
CAU 的行为由更新运行配置文件（Update Run Profile）决定，默认有 Microsoft.Default 和 Microsoft.PreventRestart 等内置方案，但生产环境通常需要自定义。通过 Save-CauRunProfile 可以把参数导出为 XML，里面能指定要跳过的补丁 KB 号、最大并发更新节点数、重启后等待群集稳定的秒数，以及是否运行预检脚本。比如数据库群集往往不允许自动重启，就需要把 RestartTimeout 设得很长并关闭强制重启。配置文件中每个参数都有明确含义：MaxFailedNodes 控制允许最多几个节点失败后整体停止；MaxRetriesPerNode 是单节点重试次数；ConcurrentNodes 决定同时更新的节点数，大多数场景下应设为 1，以保证业务冗余。
除了内置的 Windows Update 提供源，CAU 允许挂载自定义的更新脚本插件。最常见的是 PreUpdateScript 和 PostUpdateScript，它们可以是 PowerShell 文件，用于在打补丁前把存储多路径状态 dump 出来，或在打补丁后校验网卡团队是否复原。脚本必须返回 0 退出码，否则 CAU 会认为预检不通过并中止该节点更新。很多运维踩过的坑是把写日志的脚本放在后台，结果主线程退出码非零导致整轮更新失败。下面这段示例展示如何定义一个只更新安全补丁且每次仅停一个节点的配置文件：
# 定义自定义 CAU 运行配置参数
$profile = @{
MaxFailedNodes = 0
MaxRetriesPerNode = 2
ConcurrentNodes = 1
# 指定更新前和更新后的检查脚本，请替换为实际共享路径
PreUpdateScript = "\\192.168.0.1\scripts\pre-check.ps1"
PostUpdateScript = "\\192.168.0.1\scripts\post-check.ps1"
# 仅更新安全分类的补丁
UpdateCategories = @("Security")
}
# 将配置保存到群集 CLUS01，命名为 MySecureProfile
Save-CauRunProfile -ClusterName CLUS01 -ProfileName MySecureProfile -Parameters $profile这种脚本扩展让 CAU 不只是打补丁，而成为变更前的健康闸门。需要注意的是，脚本必须能被群集节点以 LocalSystem 身份执行，因此共享脚本目录要授予所有群集节点的机器账户读取权限，否则脚本不会运行。同时，如果使用了 UpdateCategories 参数，CAU 会仅从 WSUS 或 Microsoft Update 中筛选对应分类的补丁，未分类的补丁将被忽略，适合严格控制变更范围的环境。
常见问题排查与和手动更新的对比优势
使用 CAU 时最容易遇到的是节点排水失败。这通常因为资源组设置了 AntiAffinity 规则，或某台虚拟机启用了直通磁盘无法实时迁移。此时 CAU 日志会记录在 C:\Windows\Cluster\Reports 目录下的 HTML 报告里，用浏览器打开能看到具体卡在哪个群集角色。另一个高频问题是协调者节点自身需要更新，却因为持有 CAU 角色而无法排水，解决办法是允许 CAU 在自更新模式下把协调权临时漂到其它节点。还有一类典型故障是补丁安装完成后节点重启卡在“正在等待节点可连接”状态，往往是因为 DNS 缓存未刷新或群集服务启动超时，需检查 C:\Windows\Cluster\Reports 中的 wait 时间戳。
对比传统手工暂停节点再补丁的方式，CAU 的优势非常明显。手动流程里管理员容易漏掉某个节点，导致群集内版本不一致引发兼容性问题；或者在排水时误把共享存储离线。CAU 用全局视图保证每个节点都被覆盖，且每次只动一个，降低了人为失误。下面的表格列出了二者在关键维度的差异：
| 维度 | 手动更新 | CAU 自动更新 |
|---|---|---|
| 节点覆盖完整性 | 依赖人工清单 | 群集成员自动枚举 |
| 业务中断窗口 | 可能多次抖动 | 单次角色迁移平滑 |
| 失败回滚 | 手工干预 | 暂停并保留状态 |
| 审计报告 | 零散记录 | 集中 HTML 报告 |
| 对人为失误的容忍 | 较低，易漏更新或误操作 | 较高，有预检和全局锁 |
在大规模 Hyper-V 群集或文件服务器群集里，CAU 配合 SCVMM 或 Azure Arc 还能做跨群集的编排。但当群集跨越不同子网且使用存储副本时，仍建议先在测试群集跑一轮 Invoke-CauRun -Preview 来生成模拟报告，确认没有资源会被意外停机，再切到正式运行。只有这样，才能真正把 Windows Server 上的补丁维护从熬夜救火变成后台静默任务。
群集感知更新Windows Server故障转移群集CAU更新编排修改时间：2026-08-19 05:51:33