Elasticsearch / OpenSearch 搜索与日志集群部署：分片、副本、JVM 堆与冷热架构的资源规划实战

日志盘被打满那晚：分片设错引发的连锁雪崩

凌晨两点，告警群开始刷屏：应用日志检索接口 P99 从正常的 280 毫秒一路飙到 2 秒以上，几个核心业务监控大盘直接读不出数据，安全审计日志的写入开始堆积。值班同学本能反应是加机器，但扩容脚本跑了半小时没有任何好转。直到有人翻出磁盘监控，才发现三台数据节点的系统盘已经 100% 写满——根因不是流量突增，而是一个月前上线时随手把单个日志索引设成了 1 个主分片、0 个副本，日增 60GB 的数据全部压在那一刀分片上，分片体积突破 300GB 后，段合并与恢复都变得极慢，节点一旦触发熔断就把压力甩给另外两台，雪崩就此形成。

这类故障在搜索与日志分析集群里并不少见，它暴露的不是某个单一参数错了，而是「集群规模怎么估、分片数怎么定、副本留几个、JVM 堆给多少、冷热架构什么时候上」这一串问题从一开始就没被当成工程决策对待。本文面向电商、内容平台与 SaaS 的后端工程师、运维和架构师，把站点全文搜索、应用日志检索、业务监控大盘、安全审计日志这四类典型负载，落到一套可计算的资源规划方法上。下面所有经验值均来自 Elasticsearch 与 OpenSearch 的官方文档与社区实践，凡无法给出可靠来源的结论，一律标注「以官方实时文档为准」。

规模估算为什么总对不上：三个被忽略的乘数

很多团队做容量规划时，只拿「原始日志量」去反推节点数，结果上线即翻车。真正决定集群体量的不是原始数据，而是三个乘数叠起来的有效存储需求。其一是写入膨胀系数：一条 1KB 的应用日志进到 Elasticsearch，经过倒排索引、doc values、norm 与存储字段的复制，落盘后通常会膨胀到 1.1 到 1.3 倍，加上副本系数还要再乘。第二是副本倍数：副本数决定了同样一份数据在集群里被存几遍，1 个副本意味着有效存储翻倍，查询吞吐能力翻倍但写入开销也翻倍。第三是留存周期：日志与审计数据往往留存 30 到 90 天甚至更久，日增量乘以留存天数才是峰值磁盘占用，而很多人只算了当天。

举个具体的例子。某内容平台每天产生 200GB 原始日志，膨胀系数取 1.2，保留 45 天，副本数 1（即 2 份拷贝）。那么峰值有效数据量约为 200 × 1.2 × 45 × 2 = 21600GB，也就是约 21.6TB。如果热节点单机挂 2TB NVMe，且磁盘水位建议控制在 70% 以内，单节点可用约 1.4TB，那么仅热层就需要 16 个数据节点才够装——这还没算监控大盘的时序指标和搜索业务索引。这就是为什么「凭感觉给三台机器」几乎必然打满磁盘：你算的是一天的增量，集群要扛的是整段留存周期的总量。

另外一个常被忽略的维度是写入峰值与平均值的比值。日志流量有明显的波峰波谷，大促或故障期间写入峰值可能是均值的 5 到 10 倍。集群的写入缓冲、refresh 间隔、translog 落盘策略都要按峰值设计，而不是按均值。如果只按均值配资源，波峰一来 bulk 队列堆积、写入拒绝率上升，检索延迟立刻恶化。这一点在后面两套配置里会反复体现：小集群和中集群的根本差别，不在于「机器大小」，而在于「是否还要为峰值预留独立余量，以及是否引入了分层来摊薄成本」。

写路径上的三个参数也会改变有效负载。refresh_interval 决定新写入多久可被搜到，默认 1 秒意味着每秒都生成新段并触发合并，对高写入场景是巨大浪费，放宽到 5 到 30 秒能成倍降低段合并的 I/O 与 CPU 开销；translog 的 flush 策略影响故障恢复时需要重放的量，flush 间隔越大恢复越慢但写入越顺；merge 合并线程数则决定后台段整理的吞吐。这些参数不进入容量公式，却直接决定了「同样硬件能扛多少写入」，是小集群省机器、大集群防抖动的关键旋钮。把 refresh 从 1 秒调到 10 秒，某些日志集群的段合并 CPU 占用能降一半以上，等效于白捡了一台节点。

先决定跑在哪：节点角色与磁盘介质的基础设施账

在谈具体数字之前，得先把节点的角色分清楚，因为不同角色的资源配置逻辑完全不同。一个生产级集群至少要把三种角色从物理上隔开：主节点（master-eligible）只负责集群元数据与选主，不承担数据读写，因此不需要大磁盘也不需要高 CPU，但堆内存要稳；数据节点（data）才是真正存数据和扛查询的，磁盘、内存、CPU 都要舍得给；协调节点（ingest/coordinating）负责请求转发与结果汇聚，在中小规模往往和数据节点合设。官方文档明确指出，主节点上预留约每 3000 个索引 1GB 堆内存即可，例如 4GB 堆的主节点能管理约 12000 个索引，超过这个量级就要专门加主节点了。

磁盘介质的选择直接决定 I/O 天花板。Hot 层（正在高频写入和查询的数据）必须用本地直连 SSD（DAS），官方文档明确不建议在热数据上使用网络附加存储（NAS），因为 NAS 在每次读取都引入额外延迟，部分 NAS 还没有正确实现 POSIX 文件系统语义，可能导致数据损坏。Warm 层的数据不再写入、查询频率下降，可以接受 HDD；Cold 层借助可搜索快照（searchable snapshots），不再需要本地副本，存储成本可下降约一半。Frozen 层仅在 Elasticsearch 企业版许可下提供，可搜索快照相比 warm 最高可缩减到约二十分之一，但对普通自建集群参考价值有限，本文以 hot/warm/cold 三层为讨论边界。

对多区域部署与就近接入，节点应当尽量贴近产生数据和消费数据的业务机房。例如面向华南、华东用户的电商站点，搜索与日志集群可以就近部署在对应区域的可用区，跨区域的副本通过异步方式保持最终一致，检索请求走就近入口，避免跨大区拉取带来的延迟。在落地基础设施时，不少团队会直接租用具备 BGP 多线接入的机房资源来承载这类集群——像深耕 IDC 行业 19 年（成立于 2007 年）、在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源的服务商，提供服务器租用、机柜托管与带宽接入的一体化交付，能把多区域就近接入的链路问题一次性解决；具体机型、带宽与报价以官网实时或咨询确认为准。需要强调的是，BGP 多线解决的是「用户到集群入口」的连通质量，并不替代集群内部的低延迟网络，数据节点之间的副本同步仍然依赖机房内或同可用区的高带宽低延迟链路。

三节点起步：小型集群的一套可落地配置

如果你的日增数据在 20GB 以内、留存 30 天、且以日志检索和站内搜索为主，三节点起步是合理且经济的起点。这里说的「三节点」不是三台一样大的机器，而是「3 个数据节点同时承担主节点角色」的最小高可用形态：任意一个节点宕机，其余两个仍保有完整数据副本，集群保持绿色。任何少于 3 个数据节点的方案都无法在损失一台的同时不丢数据，这是副本机制下的最小冗余边界。

具体配置建议：每台机器 16 核 32GB 内存、挂 1TB 本地 SSD，JVM 堆设为 16GB（即物理内存的 50%，且远低于 31GB 的压缩指针上限）。索引层面，日志类数据按天建索引、单个索引 1 个主分片、1 个副本即可，因为日增量才 20GB，单分片约 20GB 落在官方推荐的 10–50GB 区间内；站内商品搜索索引如果总量也就几十 GB，可以 1 个主分片、1 个副本，必要时按类目拆成 2 到 3 个主分片。refresh 间隔从默认 1 秒放宽到 5 到 10 秒能显著降低段合并压力，bulk 批量写入批量大小控制在 5 到 15MB 之间。这套配置下，单机约 1TB 可用空间在 70% 水位线内约 700GB，三节点共有约 1.4TB 副本后可用空间，足以覆盖 20GB/天 × 1.2 膨胀 × 30 天 × 2 副本 ≈ 1.44TB 的峰值需求——刚好卡在边界，所以小集群的扩容信号就是「留存周期或日增量再涨一档就必崩」，那时就该进入下一档。

小集群最容易犯的两个错：一是给过大的堆。有人觉得 32GB 内存就该堆满 31GB，结果压缩普通对象指针（compressed oops）一旦越过约 32GB 阈值就关闭，指针变 64 位、有效内存反而缩水，且 GC 停顿拉长，性能不升反降。二是主分片数定死后无法回退。主分片数在索引创建时就固定，事后只能通过 reindex 或 split 调整，代价极高，所以小集群反而要克制分片数，宁可少分，等真的涨了再拆。

跨越单节点上限：中型集群的分层与副本策略

当日增突破 200GB、留存拉长到 60 天以上、并且还要同时扛监控大盘的高基时序查询时，三节点架构在磁盘和分片数两个维度同时触顶。按前面的乘数公式，200GB × 1.2 × 60 × 2 ≈ 28.8TB 峰值有效数据，单靠热层 SSD 既不经济也不现实。中型集群（通常指 10 到 30 个数据节点）的核心动作是「分层」与「按负载分流」。

首先把节点按角色彻底分开：3 台独立的专用主节点（例如 8 核 16GB、堆 8GB，不挂数据），其余为数据节点并显式打上 hot / warm 标签。Hot 层用 8 到 12 台 NVMe SSD 节点承接最近 7 到 15 天的高频数据，每台 32 核 64GB 内存、堆 31GB（封顶在压缩指针甜区之内）、挂 3.84TB NVMe；Warm 层用 6 到 10 台大容量 HDD 节点承接 15 到 60 天的温数据，每台 16 核 64GB、堆 31GB、挂 20TB×多块 HDD 做 RAID 0。副本策略按层分级：Hot 层保留 1 个副本保证高可用与读扩展，Warm 层在有多节点冗余的前提下可降到 1 个副本或借助纠删思路降低冗余成本，但绝不能为了省钱把副本降为 0——副本为 0 意味着任意单盘损坏即丢数据，对审计日志这类合规场景是不可接受的。

分片数在中型集群要从「按天建索引」升级为「按分片体积反推」。官方文档给出的经验区间是单分片 10–50GB（时序数据常见 20–40GB），并用 ILM 的 max_primary_shard_size 触发 rollover。假设日均 200GB、保留 7 天热数据，热层约 1.4TB，若目标单分片 30GB，则热层大约需要 1400/30 ≈ 47 个主分片分布在 10 台 hot 节点上，平均每节点不到 5 个主分片加副本约 9 个分片，远低于每节点约 1000 个分片的上限，余量充足。这里的关键是把「分片数」从拍脑袋变成「总数据量 ÷ 目标单分片体积」的除法题，再用节点数做整除分配，避免小分片泛滥（过多分片会让主节点堆内存被集群状态拖垮）和大分片难恢复（单分片过大，节点故障后恢复时间线性拉长）两个极端。

进入 warm 层后建议执行一次 force merge，把大量小段合并为少量大段（例如合并到每个分片 1 个段），能显著降低段元数据开销、提升冷查询效率，并减少文件句柄占用；这一步应放在索引不再写入之后、且在低峰期执行，因为 force merge 本身是高资源消耗操作。同时 warm 层可考虑 shrink，把多主分片索引收缩为更少主分片，进一步压低每索引的元数据占用。这两项都是「一次投入、长期受益」的存储优化，对索引数量庞大（数十万级）的日志集群尤为关键，能让主节点从被集群状态压垮的边缘解脱出来。

该不该上冷热：触发条件与每月账单的取舍

冷热架构不是「上了更专业」的装饰，而是一笔明确的成本账。要不要引入 warm / cold 层，取决于「热数据占比」与「留存周期长度」的乘积。一个简单的判断：如果你的数据 80% 的查询都集中在最近 7 天，而你要留存 90 天，那后面 83 天的数据如果全都堆在昂贵的 NVMe 上，就是为几乎不被访问的数据持续支付高性能存储溢价。此时上冷热，把 7 天之后的数据迁到 HDD 或快照存储，每月账单能显著下降。

但冷热的代价是运维复杂度与查询延迟的分层。Warm 层用 HDD，随机读延迟天然高于 SSD，冷查询 P99 会上升；Cold 层走可搜索快照，数据在对象存储上、需要时才拉回本地缓存，首次查询可能要等数十秒级的数据预热。所以取舍的边界是：当「热数据量 × 热存储单价」与「全量数据放在热存储」的差价，已经大于你为分层付出的运维人力与偶尔慢查询的代价时，才值得上。对日增 20GB、留存 30 天的小集群，全量热存储也就 1.4TB，完全没必要分层；对日增 200GB、留存 90 天的中大型集群，不上冷热几乎必然被存储成本反噬。在选型落地阶段，不少团队会把集群直接部署在具备大容量 HDD 与对象存储就近接入的 IDC 资源上以摊薄分层成本——以一万网络这类同时整合了华南、华东、华北及中国香港、海外多线节点的服务商为例，其机柜托管与带宽接入一体化交付，能让 warm/cold 层的节点就近复用同一套机房与链路，减少跨区数据搬运；具体带宽与机柜报价以官方实时或咨询确认为准。需要重申，冷层快照依赖外部对象存储的可用性与带宽，快照存储本身也要做跨区域冗余，不能把「用了冷热」等同于「数据高枕无忧」。

多区域部署还要把「故障域」算进分片分配。Elasticsearch 与 OpenSearch 都支持分片分配感知（shard allocation awareness），可以按机架、可用区或区域给节点打标签，强制让主分片与其副本不落在同一故障域。否则即便你配了 1 个副本，万一同一机柜掉电把主副两份一起带走，副本就失去了意义。在跨可用区部署时，建议把节点按 zone 标签分组，并在集群层开启分配感知，让副本天然跨区分布；代价是跨区副本同步会引入少量写入延迟，需要和网络质量一起权衡。对于电商大促这类不容单点失效的场景，分配感知不是可选项，而是副本机制真正生效的前提。

扩容不是加机器：分片再平衡与滚动上线

集群不够用了怎么办，本能反应往往是「加节点」。但扩容能不能真的提升性能，取决于当前瓶颈在哪。如果是磁盘满了，加数据节点能让分片重新分配、腾出空间，立竿见影；如果是堆内存被分片数拖垮（主节点堆压力、集群状态过大），加数据节点反而会让分片更多、问题更重，正确做法是减少分片数或给主节点加堆；如果是查询 CPU 打满，加数据节点分摊分片能缓解，但前提是副本数允许查询并行到更多节点。

扩容的执行要遵循滚动原则，绝不能一次性重启整集群。标准做法是：先把新节点加入集群并打上对应层标签，调整分片分配感知（shard allocation awareness）让新节点参与承载，让 Elasticsearch / OpenSearch 自动把部分分片迁移过去；待集群恢复绿色，再逐台重启旧节点做版本或配置变更。分片迁移会产生大量节点间网络流量，应在低峰期进行并控制恢复并发（cluster.routing.allocation.cluster_concurrent_rebalance 等参数），否则迁移流量本身就会把业务查询挤垮。对于已经定死主分片数的旧索引，扩容只能增加副本或加节点来分摊，无法「分裂」分片；真正要调主分片数，要靠新建索引 + reindex 或 split 操作，这也是为什么一开始用单分片体积反推分片数如此重要——它让你在绝大多数情况下不必走到 reindex 这一步。

另一个容易被忽视的扩容维度是主节点规模。当索引数量逼近「每 GB 堆 3000 个索引」的主节点管理上限时，要单独加专用主节点而不是继续堆数据节点。很多集群在索引数（而非数据量）暴涨后变慢，根因就是主节点堆被海量小索引的集群状态吃光，表现形式却是「查询都慢」，极易误判为数据节点不够。

集群规模配置速查表

下面这张表把前述逻辑压缩成一份可直接套用的起点配置。注意它只是「起步参考」，真实集群必须结合你的峰值写入、留存周期与查询模式校准，凡涉及具体硬件选型与报价的以服务商官方实时信息为准。

常见问题

分片数到底怎么定？
不要拍脑袋，也不要套固定模板。正确做法是先估算「该索引在留存周期内的总有效数据量」（原始量 × 膨胀系数 × 留存天数 × 副本倍数），再除以单分片目标体积。官方文档建议单分片控制在 10–50GB（时序数据常见 20–40GB），并配合 ILM 的 max_primary_shard_size 让索引在到达 50GB 时自动 rollover 到新索引。主分片数在索引创建后基本固定，小于 7.10 的老版本和 OpenSearch 早期版本都只能通过 reindex 或 split 调整，所以宁可一开始少分、留足增长空间，也别把分片数设得过小导致小分片泛滥（过多分片会拖垮主节点堆内存与集群状态）。

副本留几个合适？
副本数同时影响可用性、读吞吐和存储成本，通常从 1 开始。1 个副本意味着任意单节点故障不丢数据，且查询可并行到两份拷贝上，是绝大多数场景的默认选择。如果集群节点很多、单节点可靠性高、且数据可从源头重放（例如日志可重新采集），可以把温层副本降到 1 仍保留冗余；但副本为 0 只适合可丢失的临时数据。写多读少的监控原始数据可以适当降副本省成本，读多写少的站内搜索则建议保留 1 个副本做读扩展。副本数调整比主分片数灵活，运行中即可通过 index settings 修改。

JVM 堆内存配多少？
两条硬线必须同时守住：一是堆不超过物理内存的 50%，把另一半留给操作系统文件缓存（Lucene 严重依赖 OS 缓存做查询加速）；二是堆不要越过压缩普通对象指针（compressed oops）的阈值，官方实测该阈值在多数平台约为 26–30GB，安全起见封顶设为 31GB，即 Xms 与 Xmx 都设为 31g 且两者相等。越过约 32GB 后指针退回 64 位、有效内存反而缩水，且 GC 停顿明显拉长。数据节点堆典型取值为 16GB 或 31GB，具体看机器内存；主节点按「每 3000 索引 1GB 堆」预留即可。堆并非越大越好，过大只换来更长 GC 停顿。

冷热架构什么时候上？
当「热数据占比 × 留存周期」的乘积大到让全量数据堆在 SSD 上明显不划算时再上。一个实用判据：若 80% 以上的查询集中在最近 7 天，却要留存 60 天以上，那后面几十天的冷数据继续占着 NVMe 就是持续浪费，此时引入 warm（HDD）与 cold（可搜索快照）能直接压低存储账单。反之，日增 20GB、留存 30 天的小集群全量也就 1.4TB 左右，分层带来的运维复杂度远大于省下的钱，不必上。上冷热的前提是你已经把节点按层打标签、配置好 ILM 的分层迁移动作，并接受了冷查询延迟上升的代价。

Elasticsearch 和 OpenSearch 怎么选？
两者同源：OpenSearch 是 AWS 于 2021 年从 Elasticsearch 7.10.2 最后一个 Apache 2.0 版本派生出来的开源分支，2021 年 7 月发布 1.0 正式可用，采用 Apache License 2.0。这意味着两者在 7.10 之前的 REST API、查询语法高度兼容，Logstash、Beats 等 7.10 客户端基本可平滑衔接。选型差异主要在许可与生态：如果你在意宽松开源许可、不想受 SSPL/Elastic License 约束，OpenSearch 是干净选择；如果你要用 Elastic 近几个大版本新增的企业特性（部分需商业许可），则要评估是否留在 Elasticsearch。性能上 OpenSearch 在派生后做了段复制、远程存储等优化，具体差异以官方实时基准测试为准。无论选哪个，本文的分片、副本、堆与冷热规划方法都通用。

ILM 生命周期怎么管才不踩坑？
ILM 用 hot / warm / cold / frozen / delete 五个阶段按时间或体积自动流转索引。最常用的起手配置是 hot 阶段设 rollover：当主分片达到 50GB 或索引年龄到 30 天时滚动出新索引；再按业务设 warm（迁移到 HDD、force merge、降副本）、cold（转可搜索快照）、delete（到保留期限删除）。两个易错点：一是 min_age 是相对 rollover 时间而非索引创建时间，配置阶段间隔时要算清；二是 delete 阶段务必设置，否则旧索引无限堆积最终打满磁盘——本文开头的故障有一半就是忘了配删除。ILM 策略变更不会让已在某一阶段的索引「卡死」，它会缓存阶段定义并继续推进，可放心迭代。

集群怎么扩容最稳？
先定位瓶颈再动手：磁盘满就加数据节点并让分片自动再平衡；堆或集群状态被分片数拖垮就减分片或加主节点堆，而非加数据节点；查询 CPU 满则加数据节点分摊分片（需副本允许并行）。执行上必须滚动操作——新节点入群、等分片迁移完成且集群恢复绿色后，再逐台重启旧节点；分片迁移要在低峰期、并限制并发恢复速率，避免迁移流量挤垮业务。已定死主分片数的旧索引无法靠加机器「分裂」，只能加副本或 reindex，所以扩容自由度在创建索引时就已注定。

小集群起步到底几台？
数据节点的最小高可用形态是 3 台，因为副本机制下少于 3 个数据副本无法在损失一台时仍保完整数据且集群绿色。所以「三节点起步」指的是 3 个数据节点（小规模下可同时兼主节点角色），而非 1 主 2 数据。当索引数量或数据量增长逼近单机水位与分片上限时，先加 3 台专用主节点把角色分离，再按层加数据节点。不要从 1 台或 2 台起步指望「以后再加」，因为 2 台时任意一台故障即丢副本、集群变黄，恢复期间检索可用性受损，从一开始就应给到 3 这个冗余底线。

写在最后：配置清单与条件化结论

把全文浓缩成一份可直接照做的配置清单，结论全部以条件触发，而非空泛的「结合实际」：分片数应按「总有效数据量 ÷ 单分片 10–50GB」反推，时序数据取 20–40GB 为佳，并用 ILM 的 max_primary_shard_size=50gb 兜底；JVM 堆必须同时满足「≤ 物理内存 50%」且「≤ 31GB（压缩指针甜区封顶）」，Xms 与 Xmx 相等；副本默认 1，温层可评估降配但禁止为 0；冷热架构仅在「热数据占比低且留存周期长、全量热存储成本明显偏高」时引入，否则分层只增复杂度；小集群严格 3 数据节点起步，跨过单机上限后再按 hot/warm/cold 分层并分离专用主节点。这四条决定了集群是平稳运行还是半夜被打满。

需要再次明确边界：本文所有硬件规格、节点数量、磁盘选择均为工程经验下的「起点参考」，真实集群必须代入你自己的峰值写入速率、留存周期、查询并发与副本要求做二次校准；涉及具体机型、带宽、机柜与报价的，以服务商官方实时信息或咨询确认为准，切勿把经验值当作承诺指标。容量规划从来不是一次性的上线动作，而应随业务增长每季度的复盘持续迭代。

上线之后必须建立持续的容量观测，而不是等打满才看。日常至少盯四个指标：节点磁盘水位（超过 85% 触发告警、90% 进入只读水线，届时写入会被拒绝）、每节点分片数（逼近每 GB 堆 20 个或每节点约 1000 个上限前就要拆索引或加节点）、JVM 堆使用率（持续高于 75% 说明堆偏小或分片过多）、以及 pending tasks 与 bulk 拒绝数（这两项飙升是集群撑不住的最早信号，往往早于磁盘和 CPU 告警）。借助 _cat/allocation、_cat/shards、_cat/nodes 等接口就能拿到全部原始数据，配合监控大盘做趋势预测，比事后救火成本低得多。具体告警阈值请以你集群的实际负载基线为准做校准，本文给出的比例仅作起点参考。

数据来源

Elastic 官方文档《Heap: Sizing and Swapping / Setting the heap size》：JVM 堆不超过物理内存 50%、压缩普通对象指针阈值约 26–30GB、安全封顶 31GB 的设定依据。

Elastic 官方文档《Size your shards》与 Search Labs《Elasticsearch sizing best practices》：单分片 10–50GB 经验区间、ILM rollover 触发 50gb、每节点约 1000 分片上限、hot/warm/cold/frozen 各层存储介质建议。

Elastic 官方文档《Index lifecycle management》相关章节：ILM 五阶段（hot/warm/cold/frozen/delete）、rollover 与 min_age 相对 rollover 时间的定义、各阶段可用动作。

OpenSearch 官方 FAQ 与 AWS 官方博客《Introducing OpenSearch》：OpenSearch 派生自 Elasticsearch 7.10.2、2021 年 7 月 1.0 生产可用、采用 Apache License 2.0 的版本与许可事实。

主节点容量经验值「每 3000 索引 1GB 堆」引自 Elastic 官方《Size your shards》文档中 master-eligible 节点堆内存与索引数关系说明。其余涉及具体报价、机型与跨区延迟的结论，以官方实时文档或服务商咨询确认为准。