集群基础架构：定义、类型、组件与拓扑
核心原理：什么是“集群”
集群（Cluster）的本质，是将多台独立服务器（节点）通过网络互联，并借助软件层协同，对外表现为单一计算资源或单一服务入口的系统。集群不是硬件的简单堆叠，其核心价值在于解决单机无法同时兼顾的三大矛盾：性能天花板、可用性缺口和扩展成本。
理解集群需要抓住三个关键视角：
- 用户视角：访问集群时，用户只感知到一个稳定的服务地址或计算资源池，无需关心背后是哪台机器在响应。
- 管理视角：集群是一个可统一调度、监控和扩缩容的资源集合，节点故障被封装为“资源状态变化”而非“服务中断”。
- 架构视角：集群由“控制面”和“数据面”构成。控制面负责决策（如谁做主节点、任务如何分配），数据面负责执行（如实际处理请求或计算任务）。
运维启示：判断一个系统是否为集群，不应只看硬件数量，而应看是否存在协同调度逻辑。若多台机器各自独立工作、互不感知，那只是“多台服务器”，而非集群。
集群的三大类型与选型逻辑
根据设计目标的不同，集群可分为以下三类。实际生产环境中，它们常组合使用，例如“负载均衡集群 + 后端高可用集群”是最常见的Web架构。
| 类型 | 核心目标 | 典型特征 | 代表技术 | 失败代价 |
|---|---|---|---|---|
| 高可用集群（HA） | 消除单点故障，保证服务连续性 | 主备/多活、故障切换、心跳检测 | Keepalived、Pacemaker、RHCS | 业务中断、数据丢失 |
| 负载均衡集群（LB） | 分摊请求流量，提升并发处理能力 | 调度器+后端池、健康检查、会话保持 | LVS、Nginx、HAProxy、F5 | 部分请求失败、吞吐下降 |
| 计算集群（HPC/批处理） | 聚合算力，并行处理大规模计算任务 | 任务分解、并行文件系统、高速互联 | Slurm、MPI、Hadoop YARN | 计算任务失败或延迟 |
选型时需回答三个问题：业务中断的容忍时间是多少？（决定HA的复杂度）；流量峰值是平稳还是突发？（决定LB的伸缩模式）；任务是长时计算还是短时请求？（决定计算集群的调度粒度）。
集群的核心组件与职责边界
无论哪种集群，其组件都可归纳为以下五类。理解它们的职责边界，是排障时定位问题域的基础。
- 节点（Node）：集群的最小计算单元，分为主节点（控制角色）和工作节点（执行角色）。主节点故障影响调度，工作节点故障影响容量。
- 网络平面：至少包含业务网络（对外提供服务）、集群内部网络（节点间心跳、数据同步）、管理网络（运维SSH、监控采集）。三网隔离是生产环境的硬性要求。
- 存储层：分为本地存储（性能高但非共享）、共享存储（如NFS、SAN，支持故障切换）、分布式存储（如Ceph、GlusterFS，兼顾扩展与冗余）。
- 调度/协调组件：负责维护集群状态一致性，例如ZooKeeper、etcd、Corosync。它们承载了选主逻辑、配置分发和成员关系管理。
- 接入层：即客户端访问集群的入口，可能是虚拟IP（VIP）、DNS域名或负载均衡器，其作用是将流量正确引至集群内部。
实战案例：某金融系统采用“LVS（LB）+ 两台Tomcat（HA）+ MySQL主从（HA）”架构。LVS将流量分发至两台Tomcat，Keepalived监控Tomcat进程，若主Tomcat宕机，备用节点在3秒内接管VIP。此架构中，LVS本身是单点，因此又用Keepalived实现了LVS主备。可见，高可用是层层嵌套的设计，每一层都需要明确其自身的故障转移策略。
典型拓扑结构与数据流
集群拓扑决定了故障域的范围。以下三种拓扑是生产中最常见的形态，请结合图示理解其数据流方向。
三种拓扑的故障域差异明显：主备拓扑的故障切换时间取决于心跳超时配置（通常1~10秒），切换期间服务短暂不可用；负载均衡拓扑中调度器是潜在单点，需额外为调度器部署HA；计算集群中调度器故障会导致新任务无法提交，但已运行任务不受影响。
常见误区与复盘
误区一：将“节点多”等同于“高可用”。若所有节点共享同一个交换机或同一块存储，则该交换机或存储仍是单点。高可用必须逐层检查：网络、电源、存储、应用进程，每一层都要有冗余机制。
误区二：忽略“脑裂”风险。在高可用集群中，若心跳网络中断，主备节点可能同时认为对方故障，各自抢占VIP和共享存储，导致数据双写损坏。生产环境必须配置fencing（隔离机制），如IPMI断电或存储锁，确保同一时刻只有一个节点持有资源。
复盘案例：某团队为负载均衡集群中的后端节点配置了每30秒一次的健康检查。当后端应用因慢SQL导致响应时间超过5秒时，健康检查仍返回200状态码，调度器未摘除异常节点，最终引发雪崩。改进方案：健康检查应同时探测端口连通性与关键接口响应时间阈值（如/healthz接口超过2秒即判失败），并配合熔断机制。
集群架构设计的本质是对故障域的划分与控制。运维人员应始终带着两个问题审视现有集群：“哪个组件故障会影响全局？”和“故障发生后，流量或任务如何转移？”。只有将这两个问题的答案落实到具体的拓扑、组件配置和切换脚本中，集群才能真正成为可靠的业务底座。