昌江黎族自治县网站建设_网站建设公司_过渡效果

问题：旧数据很贵（而且越来越贵）

随着法律法规的变化和数据保留期限的延长，许多 Elasticsearch 客户开始思考：如何在不让存储成本耗尽预算的情况下保留历史数据？

你的 ILM（索引生命周期管理）策略可能运行得很顺畅。新数据作为热（Hot）数据进入，随着时间推移变为温（Warm）或冷（Cold）数据，然后被冻结（Frozen）为可搜索快照，最终——根据你的合规要求，在180天、10年或更长时间后被删除。

当删除操作执行时，通常会连同可搜索快照一起删除。当然，你可能在别处有常规快照，但如果没有完全恢复，这些快照是无法搜索的。如果六个月后有人问你：“嘿，我们要查一下 2023 年第二季度发生了什么？”你将面临漫长的恢复操作、耗时的人工重新摄入（re-ingestion），或者是一场关于数据保留策略的尴尬对话。

显而易见的解决方案似乎是……干脆别删？永远保留那些冻结索引！但这会带来新的问题：

成本蔓延：冻结层存储不是免费的，积少成多。
集群杂乱：管理成百上千个古老的冻结索引会变得非常混乱。
资源浪费：你为数据的“可搜索性”付费，但实际上可能好几个月都没搜索过它。

你真正想要的是一种中间方案：一种既能保持数据可访问，又不会因 S3 存储成本而破产的方法。

解决方案：Deepfreeze 让旧数据变得便宜（但并未消失）

Deepfreeze 是 Elastic 推出的一个新的仓库（Repository）管理解决方案。它允许你为已删除的索引保留可搜索快照，将它们移动到更便宜的 S3 存储层，并在以后需要时轻松恢复。这一切都归功于Elasticsearch 允许你在删除索引的同时保留其可搜索快照。

在配置 ILM 删除操作时，删除阶段有一个常被忽视的选项：

{"delete":{"delete_searchable_snapshot":false}}

将其设置为false，当索引被删除时，快照仓库会将快照文件保留在 S3 中。索引从你的集群中消失了（不再占用资源！），但底层数据仍然静静地躺在你的 S3 存储桶里，耐心等待。

但有趣的地方在于：如果你只是将这些快照留在同一个仓库中，它们仍然由 Elasticsearch “管理”，这意味着它们必须保留在标准访问层（Standard Access Tier）。AWS S3 智能分层（Intelligent-Tiering）不会将它们移动到更便宜的层级，因为从 S3 的角度来看，Elasticsearch 仍在积极管理该存储桶。
Deepfreeze 通过轮转快照仓库解决了这个问题。

可以这样理解：与其拥有一个永远不断添加文件夹的大文件柜，不如每个月启用一个新的文件柜。旧的文件柜会被关闭、贴上标签并移至更便宜的仓库。如果你需要旧文件柜里的东西，随时可以把它取回来打开。

注意：Deepfreeze 目前支持 AWS。Azure 和 GCP 已在未来的开发路线图中。

Deepfreeze 如何工作：实现数据自由的四个步骤

Deepfreeze 是一个 Python 自动化工具，定期运行（通常通过 cron）来管理这个轮转过程。当你执行其每月的rotate（轮转）操作时，会发生以下情况：

第一步：创建一个新的 S3 存储桶

Deepfreeze 创建一个新的 S3 存储桶，名称递增（如Repository-000002）。该存储桶配置了你首选的存储类——默认为 Standard（标准），但也可以选择 Intelligent Tiering（智能分层）。

请注意，为了便于讨论，我在这里使用“存储桶（bucket）”一词。实际上，Deepfreeze 是在同一个存储桶内创建新的基础路径（base path），以避免潜在的 AWS 存储桶创建限制。为简单起见，我将这种存储桶和路径的组合统称为存储桶。

第二步：将存储桶挂载为 Elasticsearch 仓库

新的 S3 存储桶被注册为 Elasticsearch 集群中的快照仓库。你的 ILM 策略现在将开始使用这个仓库来存放新的冻结索引。

第三步：更新 ILM 策略以使用新仓库

这是见证奇迹的时刻。Deepfreeze 会自动：

扫描所有的 ILM 策略
在searchable_snapshot（可搜索快照）操作中查找对旧仓库的任何引用
将 ILM 策略复制为引用新仓库的新策略
更新索引模板以使用新策略

你不需要手动编辑几十个策略。Deepfreeze 会处理一切。

第四步：卸载旧仓库（但保留最近的）

Deepfreeze 维护一个已挂载仓库的滑动窗口——默认情况下，它保持最近 6 个月的仓库可访问。更早的仓库会从 Elasticsearch 中卸载，但S3 存储桶保持完好。

一旦被卸载，这些存储桶就不再受 Elasticsearch 主动管理，Deepfreeze 现在可以将它们移动到 Glacier。

优势：为什么要关注它

成本优化

Elasticsearch 的冻结层存储虽然比热或温存储便宜，但仍会产生标准的 S3 存储费用。S3 Glacier 层比标准 S3 存储便宜 95%。日积月累，这是一笔可观的资金。

无负担的数据保留

合规性要求通常强制保留数据多年。Deepfreeze 让你能够满足这些要求，而无需不断向财务部门解释为什么存储账单一直在增长。

需要时快速访问

因为可搜索快照仍保持其原生格式，你可以使用 Elasticsearch 标准的_mountAPI 重新挂载它们。无需漫长的恢复过程，无需重新格式化——只需指向旧仓库并挂载索引即可。

Deepfreeze 进一步简化了这一点，它跟踪处理过的每个仓库的时间范围，使得类似下面的操作成为可能。系统会自动完成从指定范围解冻数据的所有工作：从 S3 请求存储桶，当数据可用时挂载仓库，甚至挂载覆盖指定日期的索引：

$ deepfreeze thaw --start-date2024-10-12 --end-date2024-12-01

当时限过后（默认 30 天），AWS 会自动将数据重新冻结到 Glacier。Deepfreeze 会在正常运行期间检查这一点，并更新其元数据、仓库和索引。

（AWS 实际上并不将数据从 Glacier 移动到 Standard。相反，它将所需数据复制回 Standard，然后在时限到期后将其删除。）

全自动化

按计划运行 Deepfreeze（每月第一天运行一次适合月度轮转），然后就可以不用管它了。它会自动处理所有繁琐的策略更新、存储桶创建和仓库管理。可以通过 cron 或 .service 文件运行它。示例可在 GitHub 上找到。

减少集群杂乱

你的 Elasticsearch 集群只需要跟踪当前已挂载的仓库。古老的索引不会出现在你的集群状态、监控仪表板或备份例程中。一切都保持得更干净。

配置：让 Deepfreeze 为你工作

Deepfreeze 非常灵活。你可以通过环境变量、命令行参数或两者结合来配置它。例如，你可以通过设置DEEPFREEZE_KEEP环境变量来更改默认挂载仓库的数量。默认值为 6。增加此值可让你访问更多数据。

DEEPFREEZE_KEEP=10

DEEPFREEZE_KEEP值的理想设置取决于需要旧数据的可能性。如果你很少查看超过一年的数据，请将保留值设置为 12，以确保你的集群拥有一整年的数据；Deepfreeze 将把任何更旧的数据推送到 Glacier 存储。

你还可以更改 AWS 存储类，使用intelligent_tiering（基于访问自动分层）代替默认的 standard（全价，始终可访问）：

DEEPFREEZE_STORAGE_CLASS=intelligent_tiering

每个操作的选项都在 GitHub README 中。

真实案例

无论你是要摄取应用程序日志、安全事件、物联网传感器数据，还是其他完全不同的数据，成本节省都将取决于你的摄取速率和保留期限。

例如，如果你每天摄取 175GB 的应用程序日志，但通常只需要最近 6 个月的数据可供故障排除搜索。假设合规性要求保留 7 年：

没有 Deepfreeze：

在冻结层保留 7 年 × 60TB = 420TB
成本：~$9,660/月

使用 Deepfreeze：

在冻结层保留 6 个月 × 30TB = 30TB：$690/月
在 S3 归档中保留 6.5 年 × 390TB：$1,560/月
总计：$2,250/月（节省 77%）

技术深入：幕后原理

对于那些想了解实际发生了什么的人，这里是实现的概览。

Deepfreeze 流程图

开始 (START) │ ├─► 初始化 Elasticsearch 客户端 (SSL/TLS, 认证) │ ├─► 计算下一个仓库后缀 │ ├─► 验证：至少存在一个具有该前缀的仓库 │ ├─► 验证：新仓库名称尚未存在 │ ├─► 通过 boto3 创建新的 S3 存储桶路径 │ └─► 配置：存储类, ACL, 区域 │ ├─► 在 Elasticsearch 中注册新仓库 │ └─► 类型：s3 │ └─► 设置：存储桶, 基础路径, 存储类 │ ├─► 更新所有 ILM 策略 │ ├─► 从集群获取所有策略 │ ├─► 对于每个使用上一个仓库的策略： │ │ └─► 查找 searchable_snapshot 操作 │ │ └─► 将旧仓库名称替换为新名称 │ │ └─► 提交更新后的策略 │ └─► 记录策略更新计数 │ ├─► 卸载旧仓库 │ ├─► 列出所有匹配前缀的仓库 │ ├─► 排除任何已解冻（thawed）的仓库 │ ├─► 按后缀排序（最旧的在前） │ ├─► 当 (总数 > KEEP) 时： │ │ └─► 删除最旧的仓库 (S3 存储桶保留！) │ └─► 记录已卸载仓库计数 │ 结束 (END)

关键实现细节

智能仓库发现：该工具通过前缀匹配来发现仓库，确保它只管理自己创建的仓库：

defget_repos(self)->list:"""获取所有匹配我们前缀的仓库"""all_repos=self.client.snapshot.get_repository(name='*')return[rforrinall_reposifr.startswith(self.repo_name_prefix)]

自动 ILM 策略更新：无需手动编辑策略。Deepfreeze 遍历策略结构并更新仓库引用：

# 简化的概念示例forpolicy_name,policyinilm_policies.items():forphaseinpolicy['phases']:if'searchable_snapshot'inphase['actions']:phase['actions']['searchable_snapshot']['snapshot_repository']=new_repo es.ilm.put_policy(name=policy_name,policy=policy)

重要注意事项

S3 智能分层（Intelligent-Tiering）的问题

这里有一个值得讨论的有趣架构问题：AWS S3 智能分层如何对已卸载的可搜索快照的“温度”进行分类？

理念是，一旦从 Elasticsearch 卸载，S3 存储桶不再被主动管理，因此访问模式降为零，智能分层应该将数据通过归档访问层（Archive Access tiers）向下移动到深度归档访问层（Deep Archive Access）（甚至 Glacier 即时检索）。

因为这依赖于一切顺利且数据在至少 90 天内保持未触动和未访问，Deepfreeze 默认将仓库放在 Standard 层，并在卸载后立即将其移动到 Glacier，而不是等待智能分层决定是否到时候了。我们确保数据尽快移动到 Glacier，但不会提前。

初始设置要求

在运行 Deepfreeze 之前，你需要：

已配置保留可搜索快照的 ILM 策略：
```
"delete":{"delete_searchable_snapshot":false}
```
至少一个现有的仓库，且带有你选择的前缀（deepfreeze 会验证这一点）
AWS 凭证，配置为可访问 S3（通过环境、IAM 角色或凭证文件）
Elasticsearch 认证，具有管理仓库和 ILM 策略的权限

设置命令会运行一套全面的预检查，以确保在开始之前条件正确。

设置后任务

Deepfreeze 只是创建了管理仓库的环境；它并不帮助你的数据进入这些仓库。我们不了解你的业务以及你想为了后代保存哪些数据。Deepfreeze 设置运行后，请确保你至少有一个 ILM 策略使用此仓库并禁用了快照删除。你还需要确保有一个索引模板，将此 ILM 策略与你想要保存的索引或数据流相关联。

开始使用

安装

# 克隆仓库gitclone https://github.com/elastic/deepfreeze.gitcddeepfreeze# 以开发模式安装pipinstall-e.# 或者直接安装依赖pipinstall-r requirements.txt

基本用法

# 设置环境变量（或使用 .env 文件）exportDEEPFREEZE_ELASTICSEARCH=https://es.example.com:9200exportDEEPFREEZE_CA=/path/to/http_ca.crt# 用于自签名证书exportDEEPFREEZE_USERNAME=elasticexportDEEPFREEZE_KEEP=6# 使用 config.yml 文件代替cp/path/to/deepfreeze/packages/deepfreeze-cli/config.yml.example ~/.deepfreeze/config.yml# ...然后编辑以设置你的值# 运行 deepfreeze 设置deepfreeze setup# 使用命令行选项deepfreeze setup --repo_name_prefix dftest\--bucket_name_prefix myorg_dftest\--base_path_prefix df_snapshots

总结

Deepfreeze 解决了许多 Elasticsearch 运维人员面临的一个现实问题：如何在不破产的情况下保持历史数据可访问？

通过自动化快照仓库的轮转并让 AWS S3 原生的分层能力承担重任，你将获得：

✅ 长期数据保留的大幅成本节省
✅ 完全符合数据保留政策
✅ 快速访问最近的历史数据（默认为 6 个月）
✅ 需要时按需重新挂载旧数据
✅ 自动运行的干净、自动化的工作流程

Deepfreeze 与你现有的 ILM 策略配合使用，只需极少的配置。它不是对你整个数据管理策略的重新设计——而是一个几乎立即就能收回成本的优化。

从 Glacier 检索数据确实会产生成本，并且需要时间（截至本文撰写时，标准检索需要 6 小时）。因此，如果你预计需要频繁使用历史数据，Deepfreeze 可能不太适合，将数据保留在冻结层可能是更好的解决方案。

如果你正在大规模运行 Elasticsearch 并存储超过几个月的历史数据，Deepfreeze 值得认真考虑。你的首席财务官（CFO）会感谢你，而你知道自己仍能满足六个月前的审计请求，也会睡得更香。

资源与后续步骤

代码仓库：github.com/elastic/deepfreeze
文档：参见仓库中的/README.md和docs/目录
依赖项：Python 3.8+，其他如pyproject.toml中所述

有疑问或想分享你的 deepfreeze 成功故事？在 GitHub 上提交 issue 或联系我们！

昌江黎族自治县网站建设_网站建设公司_过渡效果_seo优化

问题：旧数据很贵（而且越来越贵）

解决方案：Deepfreeze 让旧数据变得便宜（但并未消失）

Deepfreeze 如何工作：实现数据自由的四个步骤

第一步：创建一个新的 S3 存储桶

第二步：将存储桶挂载为 Elasticsearch 仓库

第三步：更新 ILM 策略以使用新仓库

第四步：卸载旧仓库（但保留最近的）

优势：为什么要关注它

成本优化

无负担的数据保留

需要时快速访问

全自动化

减少集群杂乱

配置：让 Deepfreeze 为你工作

真实案例

技术深入：幕后原理

Deepfreeze 流程图

关键实现细节

重要注意事项

S3 智能分层（Intelligent-Tiering）的问题

初始设置要求

设置后任务

开始使用

安装

基本用法

推荐工作流

总结

资源与后续步骤

热门文章

文章分类

标签云

需要专业的网站建设服务？

昌江黎族自治县网站建设_网站建设公司_过渡效果_seo优化

问题：旧数据很贵（而且越来越贵）

解决方案：Deepfreeze 让旧数据变得便宜（但并未消失）

Deepfreeze 如何工作：实现数据自由的四个步骤

第一步：创建一个新的 S3 存储桶

第二步：将存储桶挂载为 Elasticsearch 仓库

第三步：更新 ILM 策略以使用新仓库

第四步：卸载旧仓库（但保留最近的）

优势：为什么要关注它

成本优化

无负担的数据保留

需要时快速访问

全自动化

减少集群杂乱

配置：让 Deepfreeze 为你工作

真实案例

技术深入：幕后原理

Deepfreeze 流程图

关键实现细节

重要注意事项

S3 智能分层（Intelligent-Tiering）的问题

初始设置要求

设置后任务

开始使用

安装

基本用法

推荐工作流

总结

资源与后续步骤

热门文章

文章分类

标签云

相关文章

终极CRT-Royale使用指南：5步为现代游戏注入复古灵魂

【普中DSP28335开发攻略】-- 第 22 章 I2C-EEPROM 实验

FanControl步进速率智能散热配置指南：实战静音调校技巧

需要专业的网站建设服务？