作为处理大规模日志或时序数据的核心技术,Elasticsearch集群的存储成本和查询性能是需要持续优化的矛盾点。分层存储架构(Hot-Warm-Cold/Frozen)是解决这一问题的标准方案,它允许我们将最新、访问频率高的数据存储在高性能硬件上(Hot),而将较旧、访问频率低的数据逐步迁移到低成本、高容量的存储上(Warm, Cold)。
本文将聚焦如何通过配置节点角色和使用索引生命周期管理(Index Lifecycle Management, ILM)来搭建一个高效的分层存储架构。
1. 理解分层存储模型
| 层级 | 特点 | 硬件建议 | 典型用途 |
|---|---|---|---|
| Hot (热) | 写入和查询性能最高。数据正在被写入。 | SSD/NVMe,高CPU/内存。 | 过去 1-7 天的最新数据。 |
| Warm (温) | 只读,查询性能良好,但不再写入。 | 高容量HDD或混合SSD/HDD,中等CPU/内存。 | 过去 8-90 天的数据。 |
| Cold (冷) | 只读,查询性能较低,但存储成本极低。 | 高容量HDD,低CPU/内存,或使用对象存储网关。 | 超过 90 天,但仍需可查的历史数据。 |
2. 配置Elasticsearch节点角色
要实现分层存储,首先需要为集群中的不同节点分配明确的数据层级角色。这通常通过修改 elasticsearch.yml 来完成。
示例配置(elasticsearch.yml)
Hot 节点配置:
# elasticsearch.yml (Node 1-3)
node.roles: [ data_content, data_hot, ingest, master ]
cluster.routing.allocation.disk.threshold_enabled: true
Warm 节点配置:
# elasticsearch.yml (Node 4-6)
node.roles: [ data_warm, data_content, ingest ]
# 假设Warm节点使用成本更低的存储,通常也配置较少的资源。
Cold 节点配置:
# elasticsearch.yml (Node 7-9)
node.roles: [ data_cold ]
# Cold节点应具有最大的存储容量。
配置完成后,重启节点,Elasticsearch集群将能够识别这些不同的数据层级。
3. 核心操作:创建ILM策略
索引生命周期管理(ILM)是自动在这些层级间迁移数据的机制。我们定义一个策略,规定数据在不同阶段停留的时间和操作。
以下是一个名为 log_data_policy 的ILM策略示例,用于将数据从热层迁移到温层,再到冷层。
ILM策略 JSON 示例
使用 Kibana Dev Tools 或 cURL 提交以下请求:
PUT _ilm/policy/log_data_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_age": "7d",
"max_size": "50gb"
},
"set_priority": {
"priority": 100
}
}
},
"warm": {
"min_age": "30d",
"actions": {
"forcemerge": {
"max_num_segments": 1
},
"shrink": {},
"set_priority": {
"priority": 50
}
}
},
"cold": {
"min_age": "90d",
"actions": {
"set_priority": {
"priority": 0
},
"set_read_only": {},
"migrate": {
"node_attribute": "data_cold"
}
}
}
}
}
}
策略解读:
- Hot Phase: 持续 7 天或达到 50GB 后进行 Rollover(滚动索引)。
- Warm Phase: 当索引年龄达到 30 天后,进入温层。执行 forcemerge(强制合并)以优化存储空间和查询性能,然后执行 shrink(缩小索引),减少副本数,降低资源消耗。
- Cold Phase: 当索引年龄达到 90 天后,进入冷层。设置为只读,并通过 migrate 自动将分片移动到 data_cold 节点上。
4. 应用策略到索引模板
为了确保新创建的索引能自动遵循这个生命周期管理策略,我们需要创建一个索引模板,并在模板中引用该 ILM 策略。
PUT _index_template/log_template
{
"index_patterns": ["logstash-*"],
"priority": 500,
"template": {
"settings": {
"index": {
"lifecycle": {
"name": "log_data_policy",
"rollover_alias": "logstash"
},
"routing": {
"allocation": {
"require": {
"data": "hot"
}
}
}
}
}
},
"composed_of": [
{
"name": "logs-mappings",
"template": {
"mappings": {
"properties": {
"@timestamp": {
"type": "date"
}
}
}
}
}
]
}
注意要点:
- “index.lifecycle.name”: “log_data_policy”:指定了要使用的 ILM 策略。
- “index.lifecycle.rollover_alias”: “logstash”:指定了索引写入别名。
- “index.routing.allocation.require.data”: “hot”:关键设置,确保新创建的索引(当前写入索引)只分配到 Hot 节点上。
5. 总结与优化
通过上述配置,您已经成功建立了一个自动化的分层存储架构。数据在写入 Hot 节点后,会根据时间自动迁移到 Warm 节点(进行优化操作),最终迁移到 Cold 节点(实现存储成本最低化)。
优化建议:
- 副本配置: 在 Warm/Cold 阶段,由于数据是只读的,可以适当降低副本数(如从 2 降到 1),以进一步节省存储空间。
- Frozen 层: 如果数据访问频率极低,可以考虑引入 Frozen 层,通过快照或可搜索快照(Searchable Snapshots)技术,将数据完全移出集群,存储在对象存储(如S3)中,实现极致成本控制。
- 测试查询性能: 在 Warm 和 Cold 阶段,由于硬件变化,查询延迟会增加。务必在生产环境部署前,对不同层级的数据执行基准查询测试,以确保满足业务的SLA要求。
汤不热吧