南阳哪里做网站网站优化专家

南阳哪里做网站,网站优化专家,php网站培训班,制作一个购物网站需要多少钱问题#xff1a;旧数据很贵#xff08;而且越来越贵#xff09; 随着法律法规的变化和数据保留期限的延长#xff0c;许多 Elasticsearch 客户开始思考#xff1a;如何在不让存储成本耗尽预算的情况下保留历史数据#xff1f; 你的 ILM#xff08;索引生命周期管理旧数据很贵而且越来越贵随着法律法规的变化和数据保留期限的延长许多 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_KEEP10DEEPFREEZE_KEEP值的理想设置取决于需要旧数据的可能性。如果你很少查看超过一年的数据请将保留值设置为 12以确保你的集群拥有一整年的数据Deepfreeze 将把任何更旧的数据推送到 Glacier 存储。你还可以更改 AWS 存储类使用intelligent_tiering基于访问自动分层代替默认的 standard全价始终可访问DEEPFREEZE_STORAGE_CLASSintelligent_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_reposself.client.snapshot.get_repository(name*)return[rforrinall_reposifr.startswith(self.repo_name_prefix)]自动 ILM 策略更新无需手动编辑策略。Deepfreeze 遍历策略结构并更新仓库引用# 简化的概念示例forpolicy_name,policyinilm_policies.items():forphaseinpolicy[phases]:ifsearchable_snapshotinphase[actions]:phase[actions][searchable_snapshot][snapshot_repository]new_repo es.ilm.put_policy(namepolicy_name,policypolicy)重要注意事项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_ELASTICSEARCHhttps://es.example.com:9200exportDEEPFREEZE_CA/path/to/http_ca.crt# 用于自签名证书exportDEEPFREEZE_USERNAMEelasticexportDEEPFREEZE_KEEP6# 使用 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推荐工作流从小规模开始使用单个索引或低优先级数据进行测试监控成本在最初几个月观察你的 AWS 账单以验证节省情况验证分层如果选择了智能分层检查 S3 指标以确保其按预期工作逐步自动化一旦有了信心添加到 cron 并扩展到更多索引总结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 或联系我们