Windows故障转移集群的配置信息分散在多个层面，例如节点服务状态、资源组依赖关系、共享存储路径、网络名称与虚拟IP等。如果把 CMDB 集成范围仅限为服务器基本属性，发生集群切换或仲裁变更时配置台账就会失真。本文重点讨论如何对 Windows 集群建立可落地的配置项模型，并用自动采集方式完成配置项同步。
一、Windows 集群配置项建模与数据边界
在 CMDB 中管理集群，需要先定义配置项类型和关系。一般来说至少包括集群自身、集群节点、资源组、资源、网络名称、共享存储六类 CI。集群自身记录名称、版本、仲裁模式、运行状态；节点记录主机名、节点权重、所属域、操作系统版本；资源组记录首选所有者节点、故障转移策略、是否自动故障转移；资源进一步区分 IP 地址、网络名称、共享磁盘、通用脚本等类型；共享存储记录磁盘签名、容量和挂载路径。
建模时还要明确关系。一个集群包含多个节点，一个节点可以承载多个资源组，一个资源组可以包含多个资源，一个网络名称资源通常依赖一个或多个 IP 地址资源。把关系固化在 CMDB 中，后续做影响分析或故障定位时才能沿着依赖链快速查询。对于 Windows Server 故障转移集群，这些关系不直接暴露在注册表或日志里，更适合通过 PowerShell 的集群模块读取内存中的集群数据库快照，而不是手工整理 Excel。
边界也需要控制。不要把集群内每个应用配置文件都塞进 CMDB，否则数据噪音会淹没真正的配置项。建议只采集影响可用性和故障转移行为的对象，例如集群核心配置、网络名称、共享磁盘、仲裁见证、节点成员关系。应用级配置仍交由应用自身的配置管理系统维护，只在 CMDB 中保留一个指向应用配置库的标识即可。
二、通过 PowerShell 批量采集集群配置数据
Windows Server 自带 FailoverClusters 模块，Get-ClusterNode、Get-ClusterGroup、Get-ClusterResource 等命令可以直接读取集群配置。把这些命令封装成采集脚本，再由 CMDB 的作业调度器或中间件定期执行，可以避免人工维护。下面示例展示如何把节点、资源组和资源共享到 CSV，再交由 CMDB 导入程序处理：
# 获取当前集群节点并选择关键属性 Import-Module FailoverClusters $nodes = Get-ClusterNode | Select-Object Name, State, NodeWeight, PrimaryOwnerInterface $groups = Get-ClusterGroup | Select-Object Name, OwnerNode, State, FailoverThreshold, FailoverPeriod $resources = Get-ClusterResource | Select-Object Name, Type, State, OwnerGroup $nodes | Export-Csv -Path C:\CMDB\data\cluster_nodes.csv -NoTypeInformation -Encoding UTF8 $groups | Export-Csv -Path C:\CMDB\data\cluster_groups.csv -NoTypeInformation -Encoding UTF8 $resources | Export-Csv -Path C:\CMDB\data\cluster_resources.csv -NoTypeInformation -Encoding UTF8
仅靠集群模块还不够，某些底层配置需要读取注册表。例如集群服务启动参数位于 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc，集群仲裁配置的部分信息保存在 HKEY_LOCAL_MACHINE\Cluster 下。PowerShell 可以通过 Get-ItemProperty 读取这些键值，但需要确保脚本运行在管理员权限下。若采集程序部署在非集群节点上，还需要使用 Get-WmiObject -Class MSCluster_Node -Namespace root\mscluster 进行远程读取，并配置 WinRM 信任。
数据库连接信息、共享存储的卷 GUID、群集名称资源依赖关系等也建议纳入采集范围。文件服务器集群的共享目录信息可通过 Get-SmbShare 补充，但要注意区分本地共享与集群文件服务器角色。不同版本和不同补丁级别的 Windows 在命令输出字段上可能存在差异，因此脚本中应做字段存在性判断，否则容易因某个字段缺失导致整条 CI 同步失败。
三、变更检测与配置漂移控制
集群配置很少长期不变，节点维护、补丁重启、资源切换、存储扩容都会产生变更。如果没有变更检测机制，CMDB 里记录的只是某个时间点的快照，无法判断当前实际状态是否与台账一致。可以把每次采集到的关键字段拼接成规范化字符串，计算 SHA256 哈希指纹，并与上一次指纹比较。如果指纹不一致，再逐字段比较差异，生成变更事件。
例如对每个资源组生成 Name|OwnerNode|State|FailoverThreshold 这样的指纹，存储到 CMDB 的配置项属性中。下一次采集发现指纹变化后，一方面更新 CMDB 中的当前值，另一方面将旧值、新值、变更时间、采集来源写入变更历史表。对于计划内维护，可以由维护人员在变更窗口前提前登记计划任务，系统自动关联变更记录；对于没有对应计划的指纹变化，则按异常漂移告警，提醒配置管理员检查是否发生意外切换或权限变更。
哈希指纹方法实现简单，但要注意字段顺序和空值处理，否则会出现大量低价值告警。建议把可忽略字段先过滤掉，例如状态字段在故障转移瞬间可能短暂变为 Offline，如果每一次短暂切换都记录，会淹没真实问题。可以在采集脚本中设置稳定窗口，连续两次以上采集仍不一致时才触发变更事件，这样能有效降低误报。
四、权限控制与同步安全
集群配置采集需要较高权限，但 CMDB 集成不应长期使用域管理员账户运行。建议在集群节点上创建一个专门的服务账户，仅授予读取集群配置和有限注册表项的最小权限。对于本地读取，可以把服务账户加入本地 Performance Monitor Users 组和 Distributed COM Users 组；对于远程 WMI 查询，还需要在节点上开放 WinRM 端口并限制来源 IP。
如果 CMDB 平台支持 Agent 模式，尽量在每个集群节点上部署轻量采集代理，由代理读取本机集群信息后推送到 CMDB 服务器。这样不需要开启大规模远程管理通道，也便于在防火墙策略中只放行出站 HTTPS。若使用无 Agent 模式，则需要通过跳板主机执行远程 PowerShell 或 WinRM 调用，并确保所有远程命令都有日志审计。
同步过程中的敏感信息也要处理，例如共享存储的访问凭据、集群服务账户密码等不应进入 CMDB 配置项正文。需要这类信息时，应在 CMDB 中存储凭据引用标识，由专用密钥管理系统按需解密。这样即使 CMDB 数据库被误导出，也不会直接暴露 Windows 集群的管理凭据。
集群配置管理数据库集成不是简单导入几台服务器，而是把故障转移集群作为多级配置项实体来管理。通过建模、自动采集、指纹变更检测和最小权限同步，才能让 CMDB 在集群故障诊断和容量规划中真正发挥作用。