【ELasticsearch】节点角色分离最佳实践

本文介绍一个基于严格分层架构的 Elasticsearch 生产集群设计方案，满足 热、温、冷、冷冻 四层存储需求，并结合硬件选型与角色配置说明。

1.集群架构设计

数据层	节点角色组合	核心功能	节点数量	分片策略
热层	data_hot + ingest	实时写入、高频检索	$\ge 3$	副本数 $\ge 1$
温层	data_content + data_warm	近期访问数据、中等频率查询	$\ge 3$	副本数 $=1$
冷层	data_content + data_cold	历史数据归档、低频查询	$2-3$	副本数 $=1$ （可降为 $0$）
冷冻层	data_content + data_frozen	长期存档、几乎不访问	$1-2$	副本数 $=0$ $+$ 对象存储

2.节点角色配置详解

2.1 热层节点（Hot）

# elasticsearch.yml
node.roles: [ data_hot, ingest ]
node.attr.tier: hot

• 硬件规格：
  • CPU：16核+（高频处理器，如 Intel Xeon Gold 63xx）
  • 内存：64GB+（堆内存分配 ≤ 30GB，剩余给 OS Cache）
  • 磁盘：NVMe SSD × 2（RAID 0），单盘 1 - 2 TB。NVMe 提供百万级 IOPS，应对高并发写入/实时查询。
• 磁盘策略：单节点多磁盘条带化（提升 IO 吞吐）。

2.2 温层节点（Warm）

# elasticsearch.yml
node.roles: [ data_content, data_warm ]  # 关键：data_content持久化数据
node.attr.tier: warm

• 硬件规格：
  • CPU：8核（中端处理器）
  • 内存：32GB（堆内存 ≤ 16GB）
  • 磁盘：SAS SSD × 4（RAID 10），单盘 2 - 4 TB。SAS SSD 成本低于 NVMe，但仍有数千 IOPS，适合中等查询负载。
• 优化：关闭 index.refresh_interval（降低刷新频率）。

2.3 冷层节点（Cold）

# elasticsearch.yml
node.roles: [ data_content, data_cold ]
node.attr.tier: cold

• 硬件规格：
  • CPU：4核（低功耗处理器）
  • 内存：16GB（堆内存≤8GB）
  • 磁盘：7200rpm HDD × 6（JBOD），单盘 8 -16 TB。HDD 每 TB 成本仅为 SSD 的 $1/5$，容量优先，容忍高延迟。
• 策略：设置 index.codec: best_compression（最大化压缩）。

2.4 冷冻层节点（Frozen）

# elasticsearch.yml
node.roles: [ data_content, data_frozen ]
node.attr.tier: frozen

• 硬件规格：
  • CPU：4核（共享资源）
  • 内存：16GB
  • 磁盘：SATA HDD × 1 （512GB 缓存盘） + 对接对象存储（如 AWS S3）。本地磁盘仅作缓存，长期数据存于对象存储（每 TB 成本 $<$ $$20$）。
• 集成：使用 Elasticsearch 的 Searchable Snapshots 特性。

3.分层存储流动逻辑

ILM策略触发滚动

30天后

90天后

卸载索引

新数据写入

热层节点

索引移至温层

索引移至冷层

创建快照上传至S3

冷冻层按需挂载查询

4.关键配置说明

• ILM 策略示例：

  PUT _ilm/policy/tiered_policy
  {
    "policy": {
      "phases": {
        "hot": {"actions": {"rollover": {"max_size":"50gb"}}},
        "warm": {"min_age":"3d", "actions": {"allocate": {"require": {"tier":"warm"}}}},
        "cold": {"min_age":"30d", "actions": {"allocate": {"require": {"tier":"cold"}}}},
        "frozen": {"min_age":"90d", "actions": {"searchable_snapshot": {"snapshot_repository":"s3_repo"}}}
      }
    }
  }
  

• 节点属性分配：
  • 启动参数中添加：-Enode.attr.tier=hot（各层对应值不同）
• 冷冻层集成对象存储：

  PUT _snapshot/s3_repo
  {
    "type": "s3",
    "settings": {"bucket": "my-frozen-archive"}
  }
  

5.硬件选型对比表

层级	存储类型	单节点容量	成本/TB/年	适用场景
热层	NVMe SSD	$2-4$ $TB$	$$1,500+$	日志、实时监控
温层	SAS SSD	$8-16$ $TB$	$$800$	近线业务数据
冷层	HDD（JBOD）	$48-96$ $TB$	$$150$	审计日志、历史订单
冷冻层	S3	$\infty$	$$20$	合规存档（7年以上）

❗ 注：成本基于公有云/自建 IDC 混合模型估算，实际需按供应商报价调整。

6.为什么需要 data_content 角色 ？

• 核心作用：在 7.9+ 版本中，data_content 角色替代了传统的 data 角色，明确标识该节点存储持久化数据（非时序数据）。
• 分层必要性：温 / 冷 / 冷冻层的数据需长期保留，必须用 data_content 防止误删。
• 与热层分离：热层使用 data_hot（可自动清理滚动索引），避免持久化占用高性能资源。

7.架构优势总结

• 成本优化：SSD 使用量减少 $70\%+$，存储成本下降 $5$ 倍（热 → 冷冻层）
• 性能隔离：避免高 IO 负载（热层）影响归档查询（冷冻层）
• 扩展灵活：每层独立扩容（如冷层优先加磁盘，热层优先加 CPU）
• 合规就绪：冷冻层依托对象存储实现 WORM（Write Once Read Many）

实际部署建议：使用 Kubernetes Operators（如 ECK）或 Terraform 实现分层节点自动化部署。