一、写在前面：为什么要给数据“测体温”
在传统运维印象里，Elasticsearch（下文简称 ES）常被视作“热存储”——所有索引都放在昂贵 SSD 上，查询飞快，账单也飞快。当集群规模从几十 GB 膨胀到几十 TB，日志、指标、订单、埋点数据混杂在一起时，一条“保存 90 天”的合规要求就足以让硬件预算爆表。冷热分离（Hot-Warm-Cold Architecture）应运而生：让滚烫的“当日日志”留在 SSD，温热的“上周报表”降速到 SATA，冰冷的“去年审计”沉入大容量机械盘甚至对象存储，从而在查询体验与成本之间找到新的平衡。本文记录了一次从需求澄清、容量规划、节点划分、索引生命周期、性能验证到故障演练的完整实验，供你在真实落地时“按图索骥”。
二、需求澄清：谁能定义“冷”
实验开始前，必须与业务方、合规、财务达成三点共识：
1. 数据温度标签：
• 当日写入且 24 小时内被查询 → 热；
• 7 天内偶尔被搜索 → 温；
• 30 天后仅合规审计 → 冷；
• 90 天后几乎不再查阅 → 冻结（可快照归档）。
2. 查询 SLA：
• 热数据 P99 延迟 < 200 ms；
• 温数据可接受 1–3 s；
• 冷数据 10 s 内返回即可。
3. 成本边界：
• 整体存储成本下降 40 % 以上；
• 扩容窗口从 2 周拉长到 6 个月；
• 故障恢复时间（RTO）保持不变。
只有量化指标写进 SLA，后续实验才不会“拍脑袋”。
三、容量规划：先算账再分区
1. 数据量级估算
日均写入 500 GB，留存 90 天，原始体积 45 TB，算上副本系数 1.5，总需求 67.5 TB。
2. 温度分布预测
经验法则：
• 热占 5 %（3.4 TB）、温占 15 %（10 TB）、冷占 80 %（54 TB）。
3. 节点角色划分
• 热节点：SSD，CPU 高主频，承担写入与实时查询；
• 温节点：SAS/SATA，中等 CPU，承载低频查询；
• 冷节点：大容量机械盘，CPU 低频，仅支持快照恢复。
4. 副本策略
热索引 1 主 + 1 副本 → SSD 双写；
温索引 1 主 + 0 副本 → SATA 单写；
冷索引 0 主 + 1 快照 → 机械盘归档。
副本减少能进一步压缩冷数据成本。
四、集群布局：角色标签与感知调度
1. 节点打标签
在 elasticsearch.yml 中为节点增加：
• node.attr.temperature: hot / warm / cold
2. 分片感知
集群级设置 cluster.routing.allocation.awareness.attributes: temperature，保证主分片与副本不会落在同一温度节点。
3. 强制分配
通过 index.routing.allocation.require.temperature 将不同阶段的索引绑定到对应节点池。
4. 滚动升级
采用滚动重启策略：先冻结写入 → 迁移分片 → 重启节点 → 恢复写入，业务无感知。
五、索引生命周期策略（ILM）：让数据“自动驾驶”
ILM 是冷热分离的“自动驾驶仪”。一条策略包含四个阶段：
1. Hot
• 分片数 = 节点 CPU 核数 × 2，保证写入吞吐；
• 副本 1，保障 HA；
• 30 min 后触发 rollover，避免单分片过大。
2. Warm
• 触发条件：索引创建后 1 天，或分片大小 > 50 GB；
• 副本降为 0，节省磁盘；
• 分片合并（force_merge）到 1 段，减少段文件。
3. Cold
• 触发条件：索引年龄 7 天；
• 节点迁移到 cold 池，磁盘类型切换为大容量机械盘；
• 关闭索引，仅保留快照。
4. Delete
• 触发条件：索引年龄 90 天；
• 快照留存 2 年，随后物理删除。
ILM 的优雅在于：只需设置一次策略，后续索引自动迁移，人工零干预。
六、性能基线：冷热切换的体感测试
测试工具：
- Rally 压力注入：模拟 4 k QPS 写入，40 k QPS 查询；
- 自定义脚本：连续 7 天滚动生成不同温度数据。
结果摘要：
- 热节点：CPU 60 %，磁盘 IO 300 MB/s，P99 延迟 150 ms；
- 温节点：CPU 25 %，磁盘 IO 80 MB/s，P99 延迟 1.2 s；
- 冷节点：CPU 5 %，磁盘 IO 20 MB/s，P99 延迟 8 s。
数据与预期相符，SLA 达标。
七、故障演练：当“冷节点”突然挂掉
场景：冷节点掉电，索引分片不可读。
演练步骤：
1. 触发 ILM 快照恢复：snapshot restore 指定 repository；
2. 集群自动把冷节点标记为 exclude，分片重平衡到剩余节点；
3. 用 snapshot mount 把历史数据挂载为只读索引，查询延迟 12 s，可接受；
4. 新节点加入后，ILM 自动重平衡，恢复时间 30 min。
演练证明：即使冷节点全挂，也不影响热数据写入，且查询降级在 SLA 范围内。
八、监控与告警：让温度可感知
- 节点级：CPU、磁盘 IO、Heap 使用率，超过阈值即告警；
- 索引级：文档数、段数、存储大小，异常增长触发排查；
- 集群级：分片分布、迁移队列、快照任务，防止迁移风暴。
所有指标接入统一日志平台，值班手机只响“关键路径”。
九、成本复盘：数字说话
- 原方案：全 SSD 集群 72 TB，三年 TCO 100 %；
- 冷热分离后：
• 热节点 3.4 TB SSD，占 5 %；
• 温节点 10 TB SATA，占 15 %；
• 冷节点 54 TB 机械盘，占 80 %；
总 TCO 下降 42 %，符合预算目标。
运维人力：因 ILM 自动化，人工介入时间由每月 8 小时降至 1 小时。
十、经验沉淀：七条可复制的教训
1. 温度标签必须提前与业务方对齐，避免“我以为冷，他以为热”。
2. ILM 策略先在影子集群跑 2 周，确认无异常再上线生产。
3. 冷节点磁盘宁可多也不可不均匀，防止单盘热点。
4. 快照仓库跨可用区，防止“机房级”灾难导致冷数据全灭。
5. 监控阈值需随业务增长动态调整，避免“告警疲劳”。
6. 定期演练 ILM 回滚，防止快照仓库权限过期。
7. 把冷热分离策略写进 On-Call 手册，新人 10 分钟可上手。
十一、结语：温度思维，长期主义
冷热分离不是一次性的“磁盘搬家”，而是一种“温度思维”：
让数据像水一样自然流动，热时沸腾，冷时凝结，既不浪费资源，也不牺牲体验。
当你在下一次容量规划会上，面对不断膨胀的日志与有限的预算时，请记住：
用温度给数据分层，用自动化让分层自转，用监控让分层可见。
如此，ES 集群便能在岁月长河里，既保持滚烫的实时查询，也拥有冰冷的长期归档，真正做到“数据常青，成本可控”。
