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

发布于:2025-07-28 ⋅ 阅读:(13) ⋅ 点赞:(0)

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

1.集群架构设计

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

2.节点角色配置详解

2.1 热层节点(Hot)

# elasticsearch.yml
node.roles: [ data_hot, ingest ]
node.attr.tier: hot
  • 硬件规格
    • CPU16核+(高频处理器,如 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
  • 硬件规格
    • CPU8核(中端处理器)
    • 内存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
  • 硬件规格
    • CPU4核(低功耗处理器)
    • 内存16GB(堆内存≤8GB)
    • 磁盘7200rpm HDD × 6(JBOD),单盘 8 -16 TB。HDD 每 TB 成本仅为 SSD 的 1 / 5 1/5 1/5,容量优先,容忍高延迟。
  • 策略:设置 index.codec: best_compression(最大化压缩)。

2.4 冷冻层节点(Frozen)

# elasticsearch.yml
node.roles: [ data_content, data_frozen ]
node.attr.tier: frozen
  • 硬件规格
    • CPU4核(共享资源)
    • 内存16GB
    • 磁盘SATA HDD × 1 (512GB 缓存盘) + 对接对象存储(如 AWS S3)。本地磁盘仅作缓存,长期数据存于对象存储(每 TB 成本 < < < $ 20 20 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 2-4 24 T B TB TB $ 1 , 500 + 1,500+ 1,500+ 日志、实时监控
温层 SAS SSD 8 − 16 8-16 816 T B TB TB $ 800 800 800 近线业务数据
冷层 HDD(JBOD) 48 − 96 48-96 4896 T B TB TB $ 150 150 150 审计日志、历史订单
冷冻层 S3 ∞ ∞ $ 20 20 20 合规存档(7年以上)

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

6.为什么需要 data_content 角色 ?

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

7.架构优势总结

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

🚀 实际部署建议:使用 Kubernetes Operators(如 ECK)或 Terraform 实现分层节点自动化部署。


网站公告

今日签到

点亮在社区的每一天
去签到