一、寫在前面：為什么要給數據“測體溫”  

<i id='dt59d'></i>

在傳統運維印象里，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 集群便能在歲月長河里，既保持滾燙的實時查詢，也擁有冰冷的長期歸檔，真正做到“數據常青，成本可控”。