节点角色与职责：管理节点、工作节点、仲裁节点

集群搭建之前，有一件事得先想清楚——每个节点干什么活。

我刚开始接触分布式巡检系统的时候，觉得所有机器都一样，随便装个 Agent 就能跑。结果呢？调度乱了、心跳丢了、数据冲突了……嗯，后来花了整整两天才把集群救回来。

说白了，节点角色没分清楚，集群就容易翻车。这一章咱们就聊聊三种核心角色：管理节点、工作节点、仲裁节点。

一、管理节点：集群的“大脑”

管理节点（Master / Controller Node）是整个集群的调度中心。所有巡检任务从这里分发，所有状态数据汇聚到这里。

1. 核心职责

• 任务调度：决定哪个工作节点去执行哪台设备的巡检。
• 配置下发：把巡检脚本、告警规则、认证凭据分发给对应节点。
• 状态收集：接收工作节点上报的心跳、任务进度和结果。
• 故障检测：超过心跳超时未收到报文的节点，标记为异常。

2. 个人经验与避坑

我在项目中见过一种情况：管理节点只有一个，结果它宕了，整个集群趴窝半天。

避坑指南：我曾经遇到一个团队把管理节点和工作节点混装在同一台机器上。结果工作节点跑一个高负载巡检任务，把 CPU 吃满，管理节点的调度心跳全断了。集群直接脑裂。所以，角色隔离是个好习惯。

二、工作节点：巡检任务的“双手”

工作节点（Worker / Agent Node）是真正干活的机器。它们负责执行具体的巡检指令，比如 ping 设备、采集指标、运行脚本。

1. 核心职责

• 任务执行：从管理节点拉取任务并运行。
• 数据上报：把巡检结果推回管理节点或直接写入存储层。
• 资源监控：对本机 CPU、内存、磁盘做轻量级监控。
• 自愈上报：当自身出现异常时，主动向管理节点报告。

2. 并发与资源限制

你想想看，一个工作节点同时跑 50 个巡检任务，CPU 和网络都顶不住。我通常会在 Agent 配置里限制并发数：

# agent.yml
worker:
  concurrent_tasks: 5          # 最大并发任务数
  task_timeout: 120            # 单个任务超时（秒）
  resource_limits:
    cpu_max: 80%               # CPU 使用上限
    memory_max: 1GB            # 内存上限

三、仲裁节点：避免“脑裂”的保险丝

说到仲裁节点，可能有的同学觉得陌生。其实它在高可用集群里非常关键——尤其在管理节点超过 1 个的时候。

1. 为什么要仲裁节点？

假设你有 2 个管理节点，节点 A 和节点 B 之间的网络断了。这时两个节点都认为对方挂了，都抢着当主节点。这就叫脑裂（split-brain）。

仲裁节点的作用就是投票。当管理节点之间无法通信时，哪个节点能联系到超过半数的仲裁节点，哪个才能继续当主。

2. 仲裁节点配置实例

我在项目中常用 etcd 或 consul 来做仲裁层。以下是一个基本的 etcd 集群部署思路：

# 3 节点 etcd 集群（内置仲裁功能）
etcd1: 192.168.1.10
etcd2: 192.168.1.11
etcd3: 192.168.1.12

# 每个节点启动命令大致如下
etcd --name etcd1 \
     --initial-advertise-peer-urls http://192.168.1.10:2380 \
     --listen-peer-urls http://0.0.0.0:2380 \
     --initial-cluster etcd1=http://192.168.1.10:2380,etcd2=http://192.168.1.11:2380,etcd3=http://192.168.1.12:2380 \
     --initial-cluster- my- \
     --initial-cluster-state new

四、三种角色的对比总结

五、部署时容易踩的坑

1. 管理节点与工作节点混部——资源争抢导致调度卡顿。
2. 仲裁节点少于 3 个——网络抖动就整个集群不可用。
3. 所有角色都跑在同一台机器——单点故障，一宕全挂。
4. 忘记配置健康检查——节点挂了管理节点也不知道。