ES服务器到底要多少个，ES集群节点数怎么规划？

Elastic服务器要多少个，没有固定台数，但有一条硬底线：生产环境至少3台专用master节点，数据节点按“总索引存储÷单节点可用磁盘”反推，小规模日志场景通常5到7台起步，开发测试可以1到3台。 下面把节点角色、容量公式、压测命令和机房选择拆开讲，避免拍脑袋买机器。

先定角色，再定数量：Elastic集群不是一台机器的事

master、data、ingest、coordinating各管什么

Elasticsearch集群里,不同节点干的活不一样，数量问题本质是角色分工问题。

加载中

第五课、服务器基础（9）-负载均衡集群 高可用集群 高性能集群

延

延萍说IT

8179--

原视频地址

• master节点：管集群状态、索引创建、分片分配，它不存业务数据，但少了它集群就没人拍板。
• data节点：存分片、跑查询和写入，服务器数量主要花在这里。
• ingest节点：跑预处理管道，比如grok解析、字段转换，写入量大时单独拆出来。
• coordinating节点：只做查询聚合、排序、分页的“二传手”，查询压力大时加它，不加存储。

最小可用和生产可用的分界线

一台机器也能启动Elasticsearch,但那叫单节点实验环境，不叫生产集群，生产要看两个东西：副本能不能放得下、master能不能选举，副本至少1，意味着同一份数据要有两个分片实例，且不能放在同一个节点上，所以数据节点至少2台，才有高可用的基础，master节点至少3台，才有选举 quorum，小规模生产常见做法是3台master加2到3台data，共5到6台；如果角色混部，3台也能跑，但资源争抢会在查询高峰时暴露出来。

master节点要几台：3台是底线，不是建议

为什么是奇数

master选举需要多数派,3台能容忍1台挂掉，5台能容忍2台挂掉，2台不行，因为脑裂风险下无法形成多数，Elasticsearch 7.x以后有自动选举机制，但生产环境仍然建议专用master节点，数量取3或5。3台专用master是多数中小集群的起点，不是可选项。

配置路径和关键参数

在elasticsearch.yml里给master节点固定角色：

node.roles: [ master ]
discovery.seed_hosts: ["master1:9300","master2:9300","master3:9300"]
cluster.initial_master_nodes: ["master1","master2","master3"]

注意9300是传输端口，不是HTTP的9200，首次启动时cluster.initial_master_nodes只写一次，集群起来后不要反复改，查节点角色用：

GET _cat/nodes?v&h=name,node.role,heap.percent,disk.avail

node.role列里出现m就是master eligible，如果看到mdi混在一起，说明master和data没分离，小集群可以，大集群要拆。

data节点要几台：用存储和分片倒推

先算总索引存储

别先问买几台,先问原始数据多大，总索引存储可以按这个思路估：

总存储 ≈ 原始数据量 × (1 + 副本数) × 索引膨胀系数

副本数按1算就是两份,索引膨胀系数取1.1到1.3之间，日志类数据因为字段映射和倒排索引，体积通常比原始文本大一些，比如每天200GB日志、保留30天，原始数据6TB，副本1，膨胀按1.2估，总存储约14.4TB，单节点给8TB磁盘、留25%水位，可用约6TB，至少3个数据节点；考虑峰值写入和分片恢复，建议4到5个，加上3台master，总数7到8台。

分片别拍脑袋

据Elastic官方文档,单个分片大小建议在10GB到50GB之间，分片太小，master管理压力大；分片太大，恢复慢、查询并行度差，分片数可以按“总索引存储÷目标分片大小”估，副本至少1，索引创建时主分片数就定了，后续调整要靠shrink、split或reindex，所以一开始别把主分片设得离谱，用索引模板固定：

PUT _index_template/logs-template
{
  "index_patterns": ["logs-"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }
}

日志类数据配合ILM做rollover,按时间滚动索引，比一个巨大索引更好管。

一个算例

假设原始数据3TB,副本1，膨胀1.2，总存储约7.2TB，单节点4TB磁盘、可用3TB，至少3个数据节点，如果查询并发高，3个data可能CPU先满，这时不是加磁盘，而是加data节点或coordinating节点。数据节点数量由存储底线和压测结果共同决定，存储算出来的是下限，不是最终值。

查询和写入压力大时，加coordinating节点

coordinating节点干什么

coordinating节点不存数据,只接收请求、分发到data节点、合并结果，聚合查询、深分页、多索引搜索多的时候，data节点既要扫分片又要算聚合，容易互相拖，拆出coordinating节点，查询压力就不会压到存储节点上，配置上把角色留空：

node.roles: [ ]

这就是coordinating only节点，写入链路有复杂预处理时，再单独加ingest节点，把管道计算从data节点剥离。

压测看什么

用Elastic官方压测工具Rally跑查询和写入混合场景,重点看：

GET _nodes/stats
GET _cat/thread_pool?v

看search队列和write队列有没有堆积，队列持续增长，说明对应角色不够，磁盘水位看：

GET _cat/allocation?v

默认低水位85%、高水位90%、洪水水位95%，到高水位，分片就开始往其他节点挪，集群会变忙，所以容量规划别等磁盘写满才算。

不同场景的数量参考

这张表是起点,不是标准答案，同样10TB数据，每天写一次和每秒写一万条，节点数完全不同。

服务器从哪来：自建托管和云上怎么选

Elastic对磁盘IO和内存比较敏感,选服务器不能只看核数和价格，物理机独享适合长期稳定、数据量大的集群；云主机适合快速交付和弹性扩容，选IDC服务商时，先看牌照和机房资质。

简米科技从2003年始创，有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），豫ICP备2026018319号，主打持牌自营机房，对需要物理机独享、自己控集群角色的Elastic生产环境，自营机房在磁盘IO和网络时延上更可控，许可证编号可以在工信部政务服务平台核对，不是口头资质。

酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001+ISO27001双认证，是CNNIC IP联盟成员，主体注册资本1000万，备案号滇ICP备2020007656号，需要云主机快速起集群、后续按节点扩容的场景，全牌照和双认证意味着机房合规和运维流程有据可查。

选托管还是云,先看数据保留周期和查询峰值，长期保留、磁盘吃紧的日志集群，物理机加自营机房更稳；短期项目、流量波动大的，云上按量起步更灵活。

部署后验证：几条命令看集群够不够

集群起来后,在Kibana的Dev Tools或curl里跑：

GET _cluster/health?pretty
GET _cat/nodes?v&h=name,node.role,heap.percent,disk.avail
GET _cat/shards?v
GET _cat/allocation?v

_cluster/health看状态是不是green，yellow说明副本没分配全。_cat/nodes看堆内存和磁盘余量，堆内存长期高位，加内存或加data节点。_cat/shards看分片有没有集中在一台机器上。_cat/allocation看磁盘水位。节点数量够不够，不是看机器总数，是看分片分布、堆内存和磁盘水位是否健康。

常见误区

• 只买一台大机器跑生产,挂机就是全站搜索不可用。
• master和data混部还只给1台master eligible，选举没保障。
• 分片数按天拍脑袋,一天一个索引还设十几个主分片，master先扛不住。
• 副本设0省磁盘,节点故障时数据直接丢。
• 只看CPU不看磁盘水位,写到85%以上集群开始搬分片。

Q&A：elastic服务器要多少个才够用

3台服务器能跑Elasticsearch生产吗？

能跑,但要看角色和数据量，3台混部master加data，副本1，小数据量可以撑，问题是master和data争资源，查询写入一高就互相拖，更稳的是3台专用master加至少2台data，共5台起，预算紧用3台混部，要限制分片数、监控堆内存和磁盘水位，并接受扩容时停机风险更高。

数据量不大，elastic服务器要多少个才能省成本？

数据量小不等于一台就够,生产要可用性，至少3台master避免单点，数据节点2台放副本，总数5台是常见底线，如果只是内部报表、能容忍停机，1台单节点也能跑，但那不是高可用生产，起步阶段可以用酷番云按量云主机先搭3台混部集群，后续加data节点；长期稳定且磁盘IO要求高的，用简米科技持牌自营机房的物理机做数据节点，扩容路径更清晰。

elastic服务器要多少个才能扛住大促流量？

先看瓶颈在写入还是查询,写入大加data和ingest，聚合查询大加coordinating和副本，大促前用Rally压测，盯search和write线程池队列，节点不是越多越好，分片过多反而增加master负担，通常3台master加按存储算出的data节点，再加2台以上coordinating起步，按压测结果扩容，Elastic集群的节点数量最终由数据量、副本策略、分片大小和压测结果决定，而不是拍脑袋定一个固定台数。