2. 集群架构与角色规划
Elasticsearch 集群的性能与稳定性，很大程度上在“节点怎么分工”这一步就已经决定。默认情况下，每个节点都同时承担主节点候选、数据存储、协调转发等职责，小规模时省事，规模一大就会出现主节点被数据写入拖累、协调节点成为瓶颈、批量导入压垮查询等连锁问题。角色分离的本质，是把不同性质的负载放到不同节点上，让每类节点只做自己擅长的事。
一、节点角色的职责边界
Elasticsearch 7.x 之后通过 node.roles 显式声明角色，常见角色及其职责如下：
- master（主节点候选）：负责集群状态管理——创建/删除索引、分片分配、节点上下线、映射变更等元数据操作。它不存储业务数据，也不处理搜索和写入请求。主节点是集群的“大脑”，一旦被数据负载拖慢，整个集群的元数据操作都会卡住。
- data（数据节点）：存储分片、执行文档的索引与检索、参与分片恢复和段合并。这是资源消耗最大的角色，CPU、内存、磁盘 IO 都集中在这里。
- data_content / data_hot / data_warm / data_cold：数据节点的细分角色，配合 ILM（索引生命周期管理）实现冷热分层。热层用 SSD 承载高频写入查询，温冷层用大容量 HDD 存放历史数据。
- ingest（预处理节点）：在文档真正写入索引前执行 ingest pipeline，完成字段解析、grok 提取、时间戳转换、富化等。它消耗 CPU，尤其是正则和脚本处理。
- coordinating（协调节点）：不承担主节点、数据、ingest 角色，只负责接收客户端请求、把请求分发到相关分片、汇总各分片结果并返回。它相当于查询的“汇聚层”。
- ml、transform、remote_cluster_client：分别用于机器学习、转换任务和跨集群检索，按需启用。
需要强调：协调节点不是一个可以显式声明的角色，而是“不承担其他角色”的节点自然形成的定位。任何节点都会参与请求转发，但只有把主、数据、ingest 都剥离后，它才成为专职协调节点。
二、主节点与数据节点为什么要分离
主节点候选数量应满足“奇数且至少 3 个”的法定人数要求，推荐 3 个专用主节点，避免 2 个（无法形成多数派）或过多（选举开销上升）。专用主节点配置可以很低：2～4 vCPU、4～8 GB 堆内存即可，但网络必须稳定、延迟低，因为它们之间要频繁同步集群状态。
数据节点则相反，需要大内存、多核 CPU 和高速磁盘。把主节点和数据节点混在一起，风险在于：一次大规模写入或段合并会占满 CPU 和 IO，导致主节点心跳超时、集群状态发布延迟，严重时触发重新选举，出现“脑裂”式的服务抖动。因此生产集群普遍采用专用主节点 + 专用数据节点的组合。
三、协调节点与 ingest 节点的选型
协调节点的价值在查询密集场景最明显。一个搜索请求会打到多个分片，协调节点负责扇出（scatter）和汇聚（gather）。如果协调节点同时还是数据节点，它既要处理自己的分片查询，又要汇总其他节点的结果，容易在高峰期成为瓶颈。专用协调节点建议配置高 CPU 和较大堆内存（因为要缓存和合并大量分片结果），一般 8～16 vCPU、16 GB 堆内存起步，数量根据并发查询量横向扩展。
ingest 节点的选型取决于 pipeline 复杂度。如果只是简单的 set、rename 处理器，开销很小，可以和数据节点合并；如果使用 grok 正则、脚本、enrich 富化，CPU 消耗显著，建议独立部署，避免拖慢数据节点的索引和查询。一个实用的判断方法是：观察 ingest pipeline 的 current 指标和节点 CPU，如果 ingest 耗时占写入链路比例超过 20%，就应考虑拆分。
四、典型集群拓扑与容量影响
下面给出三种常见规模下的拓扑参考，均为示例配置，实际需按数据量、QPS 和 SLA 调整：
| 规模 | 节点构成 | 适用场景 | 容量影响 |
|---|---|---|---|
| 小型（≤ 3 节点） | 3 个节点，主+数据+协调合一 | 开发测试、日志量 < 50 GB/天 | 角色混布，主节点易受写入影响，扩展性差 |
| 中型（6～10 节点） | 3 专用主 + 3～5 数据 + 2 协调 | 生产日志、中等业务检索 | 主节点稳定，协调层可横向扩展，数据层按磁盘扩容 |
| 大型（20+ 节点） | 3 专用主 + 热/温/冷数据层 + 3+ 协调 + 独立 ingest | 高并发检索、PB 级数据、冷热分层 | 各层独立扩展，成本可控，故障域隔离清晰 |
角色分离对容量的影响体现在几个方面。第一，专用主节点不存数据，会“浪费”少量资源，但换来集群状态稳定，这是值得的。第二，协调节点不存数据，需要额外机器，但能显著提升查询吞吐，尤其在高并发聚合场景。第三，热温分层让热层用少量 SSD 承载高频数据，温层用廉价大容量盘存历史，整体存储成本可下降 40%～60%。第四，分片数量与数据节点数量要匹配：每个数据节点建议承载 20～50 个分片（含副本），分片过多会加重主节点和协调节点的元数据与汇聚负担。
五、配置落地要点
在 elasticsearch.yml 中显式声明角色，避免默认全角色带来的耦合：
# 专用主节点
node.roles: [ master ]
node.name: master-1
# 专用数据节点（热层）
node.roles: [ data_hot, data_content ]
node.name: hot-1
# 专用协调节点
node.roles: [ ]
node.name: coord-1
# 专用 ingest 节点
node.roles: [ ingest ]
node.name: ingest-1注意 node.roles: [ ] 表示该节点不承担任何显式角色，即专职协调节点。主节点候选数量必须为奇数，且 discovery.seed_hosts 和 cluster.initial_master_nodes 要正确配置，否则集群无法稳定选主。角色调整后需要重启节点，且要确保数据分片有足够副本，避免重启期间数据不可用。
data 角色，也不要在数据节点上启用 master 角色（除非是 3 节点以内的小集群且明确接受风险）。角色混布是生产环境最常见的性能隐患之一。
总结来说，角色规划的核心逻辑是：让主节点只做决策、数据节点只做存储与计算、协调节点只做汇聚、ingest 节点只做预处理。规模越大，这种分离带来的收益越明显；规模很小时可以适度合并，但必须清楚合并的代价在哪里。拓扑设计没有唯一答案，关键是让每类负载都有明确的承载者，并且能够独立扩展。