Wazuh Server Cluster 深度指南：主从架构、配置详解与负载均衡实战

Wazuh Server Cluster 深度指南主从架构、配置详解与负载均衡实战【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuhWazuh 是一个开源的统一 XDR 与 SIEM 安全平台其 server 集群Wazuh server cluster允许将多个 Wazuh server 节点组织为分布式环境以支持海量终端接入并提供高可用能力。本文以仓库 docs/ref/modules/cluster/README.md 为主线结合 集群配置参考、负载均衡文档 以及framework/wazuh/core/cluster/下的 Python 实现系统讲解集群的节点角色、内部同步机制、完整配置项、配置示例以及 NGINX / HAProxy 负载均衡的落地方法。读完本文你将能够独立规划、配置并运维一个 Wazuh server 集群。Wazuh server cluster 是什么Wazuh server cluster 由多个运行在分布式环境中的 Wazuh server 节点组成是一种提供水平扩展与性能提升的部署策略。在监控端点数量庞大的场景下可以将该架构与网络负载均衡器结合把 Wazuh agent 的连接均匀分发到多个节点上从而让 Wazuh 平台在保证高可用性的同时高效管理大量 agent。集群由**一个主节点master node和多个工作节点worker node**构成agent 被配置为向集群内的 server 节点上报数据。这种设计显著改善了整体可扩展性与服务器性能。集群架构master 与 worker 的角色划分Wazuh server cluster 中存在两种节点角色主节点master和工作节点worker。角色决定了每个节点的职责并建立了同步过程中的层级关系。一个 Wazuh server cluster只能有一个主节点在同步期间主节点的数据始终优先于工作节点从而保证集群内数据的一致性与统一性。Master node主节点主节点负责集中协调并确保关键数据在所有节点间保持一致其职责包括接收并管理 agent 的注册与删除请求创建和管理共享配置组shared configuration groups。从主节点同步到工作节点的数据包括agent 注册信息共享配置shared configuration。同步过程中工作节点上已存在的同名文件会被主节点版本直接覆盖。从源码看主节点的职责落在 framework/wazuh/core/cluster/master.py 中MasterHandler类统一处理来自 worker 的各类同步命令如syn_i_w_m_p完整性权限申请、syn_i_w_m完整性同步、syn_a_w_magent 信息同步、syn_w_g_c全量 agent-groups 请求等Master类则维护全局任务包括周期性的文件状态计算file_status_update与 agent-groups 广播agent_groups_update。Worker node工作节点工作节点的职责包括将 agent 的注册enrollment请求重定向到主节点从主节点同步共享数据接收并处理来自 Wazuh agent 的事件向主节点发送 agent 状态更新。值得注意的是如果共享文件在工作节点上被修改这些改动会在下一次同步周期中被丢弃并替换为主节点的版本。这与wazuh-manager.conf不同——后者被明确排除在同步文件清单之外见下文哪些文件参与同步。注意对/var/wazuh-manager/etc/wazuh-manager.conf的配置修改不会自动同步到工作节点。必须在主节点上修改后手动复制到各 worker 节点并重启相应节点才能生效。这与 cluster.json 的 excluded_files 配置 中显式排除wazuh-manager.conf的实现一致。工作原理wazuh-clusterd 与内部同步线程Wazuh server cluster 由wazuh-clusterd守护进程管理实现了 master–worker 架构。所有通信均由工作节点发起且每个 worker 独立地与 master 通信。集群内部通过多个线程分工协作完成不同操作Keep-alive 线程维护持久连接由 worker 周期性向 master 发送保活消息。对应的间隔配置为intervals.worker.keep_alive默认 60 秒见 cluster.json。Agent info 线程发送 agent 操作系统详细信息与状态信息。master 在存储更新前会校验 agent 是否存在避免写入过期数据stale data。Agent groups send 线程向 worker 分发 agent 组group分配信息。这些数据由 master 在 agent 首次连接时计算得出。Local agent-groups 线程周期性从数据库检索 agent 组信息并在 master 上缓存避免为每个 worker 重复查询。对应Master.agent_groups_update方法其启动前会等待agent_group_start_delay默认 30 秒以便 worker 先连接上 master见 master.py 第 1090-1127 行。Integrity 线程将共享文件从 master 同步到 worker。Local integrity 线程周期性计算文件完整性信息源码中使用BLAKE2b哈希与修改时间戳见 cluster.py 的 get_files_status避免为每个 worker 连接重复计算完整性数据。同步流程的源码级拆解从 framework/wazuh/core/cluster/worker.py 可以看到 worker 侧的完整同步逻辑sync_integrityworker 连接 master 后每sync_integrity秒默认 9 秒向 master 发送一次本地文件元数据路径 BLAKE2b 哈希 修改时间master 收到后与自身元数据比对找出差异文件并回传worker.py 第 511-550 行。sync_agent_info每sync_agent_info秒默认 10 秒从本地 wazuh-manager-db 检索本节点上报的 agent 信息分块发送给 master 的数据库worker.py 第 552-589 行。master 侧在 master.py 中通过integrity_check将接收到的 worker 元数据与自身integrity_control比对借助 cluster.compare_files 将文件分为四类missingworker 缺失、shared双方哈希不同需更新、extraworker 多余需删除以及 extra_valid随后通过integrity_sync打包发送。文件压缩与解压由 compress_files / decompress_files 完成支持按max_zip_size与compress_level控制传输体积。哪些文件参与同步同步的文件范围由 framework/wazuh/core/cluster/cluster.json 定义目录说明权限etc/client.keysagent 密钥库与authd.pass注册共享密码来源为 master0o640etc/shared/共享配置组文件全部文件递归0o660var/multigroups/多分组合并文件merged.mg递归0o660同时该文件定义了排除规则excluded_files包含wazuh-manager.confexcluded_extensions包含~、.tmp、.lock、.swp等临时文件后缀。集群日志所有集群日志统一写入/var/wazuh-manager/logs/cluster.log用于排查同步、连接与配置问题。集群配置参考完整的按选项含默认值与允许值均已对照配置解析器验证说明见 Cluster Configuration。集群配置位于/var/wazuh-manager/etc/wazuh-manager.conf的clusterXML 节中属于Manager-only模块内部选项前缀为wazuh_clusterd.*。配置项详解配置项默认值允许值说明namewazuh任意名称当前节点所属集群的名称。同一集群的所有节点必须使用相同的 namenode_namenode01任意名称当前节点的名称。每个节点必须唯一若两个节点重名其中一个将被拒绝node_typemastermaster、worker节点角色。当前实现只允许一个 master 节点key安装时随机生成字母、数字与下划线32 字符节点间通信加密密钥必须为 32 字符且所有节点一致port1516大于 1024 且小于 65535 的端口号集群通信端口bind_addr127.0.0.1任意合法 IP节点存在多个网卡时指定用于集群通信的 IP 地址nodes127.0.0.1集群节点的任意合法地址IP 或 DNS通过node标签逐个列出集群中的 master 节点。仅允许一个 master若配置多个将使用第一个hiddennoyes、no是否在告警中隐藏产生告警的集群信息密钥生成命令openssl rand -hex 16配置校验的源码依据上述约束并非仅停留在文档层面framework/wazuh/core/cluster/cluster.py 的 check_cluster_config 会在启动时严格校验key非空且恰好 32 个字符、仅含字母数字node_type必须为master或workerport必须为整数且满足1024 port 65535常量MIN_PORT/MAX_PORT定义于 cluster.py 第 44-45 行nodes中不允许出现保留地址localhost、0.0.0.0、127.0.1.1若配置了多个节点会发出警告并仅使用第一个作为 master。同时 utils.py 的 read_config 定义了默认配置字典node_typemaster、namewazuh、node_namenode01、port1516、bind_addr127.0.0.1、nodes[127.0.0.1]、hiddenno并会自动为缺失项补默认值当配置文件完全没有cluster节时返回默认配置。内部选项内部选项位于/var/wazuh-manager/etc/wazuh-manager-internal-options.conf# Cluster debug level (0-2, default: 0) wazuh_clusterd.debug0该选项控制集群守护进程的调试日志级别0 为不输出调试信息2 为最详细。配置示例标准 Master 节点cluster namewazuh/name node_namemaster-node/node_name node_typemaster/node_type keyc98b62a9b6169ac5f67dfe55b73a8d2a/key port1516/port bind_addr0.0.0.0/bind_addr nodes nodeMASTER_NODE_IP/node /nodes hiddenno/hidden /cluster标准 Worker 节点cluster namewazuh/name node_nameworker-node-01/node_name node_typeworker/node_type keyc98b62a9b6169ac5f67dfe55b73a8d2a/key port1516/port bind_addr0.0.0.0/bind_addr nodes nodeMASTER_NODE_IP/node /nodes hiddenno/hidden /cluster配置 worker 时注意name与key必须与 master 完全一致node_name必须全局唯一node_type设为worker且nodes指向 master 节点的 IP。自定义集群通信端口cluster namewazuh/name node_namemaster-node/node_name node_typemaster/node_type keyc98b62a9b6169ac5f67dfe55b73a8d2a/key port5516/port bind_addr0.0.0.0/bind_addr nodes nodeMASTER_NODE_IP/node /nodes hiddenno/hidden /cluster端口只需大于 1024 且小于 65535所有节点必须使用相同端口。在告警中隐藏集群信息cluster namewazuh/name node_namemaster-node/node_name node_typemaster/node_type keyc98b62a9b6169ac5f67dfe55b73a8d2a/key port1516/port bind_addr0.0.0.0/bind_addr nodes nodeMASTER_NODE_IP/node /nodes hiddenyes/hidden /cluster将hidden设为yes后告警中不再展示是集群中哪个节点产生了该告警。负载均衡把 agent 分发到多个节点负载均衡器将工作负载分发到多个资源上。在 Wazuh server cluster 中它把 agent 分发到不同的 worker 节点以提升可扩展性、可用性与性能。负载均衡器让 agent 可以透明地向不同 Wazuh server 节点注册与上报当某个节点不可用时agent 会自动重连到其他可用节点。实践中常使用两种负载均衡方案NGINX与HAProxy。完整内容见 Cluster Load Balancing。使用 NGINXNGINX 可作为 TCP 负载均衡器分发 agent 流量。使用发行版自带的软件包安装 NGINX 后编辑nginx.confstream { upstream master { server MASTER_NODE_IP:1515; } upstream cluster { hash $remote_addr consistent; server MASTER_NODE_IP:1514; server WORKER_NODE_IP:1514; server WORKER_NODE_IP:1514; } server { listen 1515; proxy_pass master; } server { listen 1514; proxy_pass cluster; } }配置说明1515端口用于 agent 注册enrollment此处仅指向 master 节点因为注册请求最终由 master 处理1514端口用于 agent 事件上报通过hash $remote_addr consistent实现基于来源 IP 的一致性哈希保证同一 agent 尽量稳定地落在同一节点。将占位 IP 替换为实际节点地址后重新加载服务nginx -t nginx -s reload使用 HAProxyHAProxy 为 TCP 服务如 Wazuh agent 连接提供高可用与负载均衡能力。可通过系统软件包或 Docker 安装。创建/etc/haproxy/haproxy.cfgglobal maxconn 4000 user haproxy group haproxy daemon defaults mode tcp timeout connect 10s timeout client 1m timeout server 1m frontend wazuh_register bind :1515 default_backend wazuh_register backend wazuh_register balance leastconn server master MASTER_NODE:1515 check server worker1 WORKER_NODE:1515 check frontend wazuh_reporting bind :1514 default_backend wazuh_reporting backend wazuh_reporting balance leastconn server master MASTER_NODE:1514 check server worker1 WORKER_NODE:1514 check该配置使用leastconn算法优先分发到当前连接数最少的节点并启用健康检查。启动服务service haproxy startHAProxy helper按集群状态自动更新后端HAProxy helper 会根据集群状态自动更新HAProxy 的后端服务器列表。使用前需配置 Dataplane APIdataplaneapi: host: 0.0.0.0 port: 5555 user: - name: USER password: PASSWORD insecure: true haproxy: config_file: /etc/haproxy/haproxy.cfg haproxy_bin: /usr/sbin/haproxy reload: reload_cmd: service haproxy reload随后在 master 的wazuh-manager.conf中加入以下节以启用 helperhaproxy_helper haproxy_disabledno/haproxy_disabled haproxy_addressHAPROXY_ADDRESS/haproxy_address haproxy_userUSER/haproxy_user haproxy_passwordPASSWORD/haproxy_password /haproxy_helper重启 manager 使配置生效并通过集群日志确认 helper 是否正常工作systemctl restart wazuh-manager tail /var/wazuh-manager/logs/cluster.log从源码看HAProxy helper 的实现位于 framework/wazuh/core/cluster/hap_helper/其配置结构在 cluster.py 的 HAPROXY_HELPER_SCHEMA 中定义并通过validate_haproxy_helper_config在集群启动时校验参数合法性如端口范围 1024–65535、协议仅允许 http/https 等。集群运维与健康检查除配置与负载均衡外集群的日常运维还包括健康检查MasterHandler.to_dict与Master.get_healthmaster.py 第 224-243 行与第 1160-1189 行提供每个 worker 的同步状态、最近 keep-alive 时间、完整性检查/同步时间等健康信息可结合cluster_control工具或 API 的 healthcheck 接口查看。同步周期调优cluster.json中intervals节集中定义了 worker 侧sync_integrity9、sync_agent_info10、keep_alive60、connection_retry10等与 master 侧recalculate_integrity8、process_pool_size2、agent_group_start_delay30等的周期参数可用于按需调整同步频率与并发度。排障入口优先查看/var/wazuh-manager/logs/cluster.log临时文件清理、同步失败如文件过大、压缩失败等场景分别由 cluster.py 的 clean_up / update_cluster_control 处理。总结Wazuh server cluster 通过单 master 多 worker的层级结构与以 worker 主动发起通信的同步机制在保持数据一致性的前提下实现了水平扩展与高可用。部署时的关键实践可以归纳为三点一是严格保持各节点name、key、port一致并保证node_name唯一二是牢记wazuh-manager.conf不会自动同步需要手动复制三是在 agent 规模较大时引入 NGINX 或 HAProxy 将1514上报与1515注册流量分发到各 worker 节点并可选启用 HAProxy helper 实现后端自动更新。结合本文给出的配置示例与源码级原理你可以据此规划出适合自身环境规模的 Wazuh server 集群方案。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考