Curve 文件存储在 Elasticsearch 冷热数据存储中的应用实践

Elasticsearch 在生产环境中有广泛的应用，本文介绍一种方法，基于网易数帆开源的 Curve 文件存储，实现 Elasticsearch 存储成本、性能、容量和运维方面的显著提升。

ES 使用 CurveFS 的四大收益

1.CurveFS 提供的成本优势

为了高可靠，ES 如果使用本地盘的话一般会使用两副本，也就是说存储 1PB 数据需要 2PB 的物理空间。但是如果使用 CurveFS，由于 CurveFS 的后端可以对接 S3，所以可以利用对象存储提供的 EC 能力，既保证了可靠性，又可以减少副本数量，从而达到了降低成本的目的。

以网易对象存储这边当前主流的 EC 20+4 使用为例，该使用方式就相当于是 1.2 副本。所以如果以 ES 需要 1PB 使用空间为例，那么使用 CurveFS+1.2 副本对象存储只需要 1.2PB 空间，相比本地盘 2 副本可以节省 800TB 左右的容量，成本优化效果非常显著。

2.CurveFS 提供的性能优势

以下文将要介绍的使用场景为例，对比 ES 原来使用 S3 插件做 snapshot 转存储的方式，由于每次操作的时候索引需要进行 restore 操作，以 100G 的日志索引为例，另外会有传输时间，如果 restore 的恢复速度为 100M，那么也要 300 多秒。实际情况是在一个大量写入的集群，这样的操作可能要几个小时。

而使用 CurveFS 后的新模式下基本上只要对 freeze 的索引进行 unfreeze，让对应节点的 ES 将对应的 meta 数据载入内存就可以执行索引，大概耗时仅需 30S 左右，相比直接用 S3 存储冷数据有数量级的下降。

3.CurveFS 提供的容量优势

本地盘的容量是有限的，而 CurveFS 的空间容量可以在线无限扩展。同时减少了本地存储的维护代价。

4.CurveFS 提供的易运维优势

ES 使用本地盘以及使用 S3 插件方式，当需要扩容或者节点异常恢复时，需要增加人力运维成本。CurveFS 实现之初的一个目标就是易运维，所以 CurveFS 可以实现数条命令的快速部署以及故障自愈能力。

另外如果 ES 使用 CurveFS，就实现了存算分离，进一步释放了 ES 使用者的运维负担。

选用 CurveFS 的原因

背景： 在生产环境有大量的场景会用到 ES 做文档、日志存储后端，因为 ES 优秀的全文检索能力在很多时候可以大大的简化相关系统设计的复杂度。比较常见的为日志存储，链路追踪，甚至是监控指标等场景都可以用 ES 来做。

本地盘到 MinIO

为了符合国内的法律约束，线上系统需要按照要求存储 6 个月到 1 年不等的系统日志，主要是国内等保、金融合规等场景。按照内部管理的服务器数量，单纯 syslog 的日志存储空间每天就需要 1T，按照当前手头有的 5 台 12 盘位 4T 硬盘的服务器，最多只能存储 200 多天的日子，无法满足日志存储 1 年的需求。

针对 ES 使用本地盘无法满足存储容量需求这一情况，网易 ES 底层存储之前单独引入过基于 S3 的存储方案来降低存储空间的消耗。如下图，ES 配合 minio 做数据存储空间的压缩。举例来说 100G 的日志，到了 ES 里面因为可靠性需求，需要双副本，会使用 200G 的空间。ES 针对索引分片时间，定期性转存储到 minio 仓库。

MinIO 到 CurveFS

这个方案从一定程度上缓解了存储空间的资源问题，但是实际使用的时候还会感觉非常不便利。

• 运维成本。ES 节点升级的时候需要额外卸载安装 S3 插件，有一定的运维成本。

• 性能瓶颈。自己私有化搭建的 Minio 随着 bucket 里面数据量的增长，数据存储和抽取都会成为一个很大的问题

• 稳定性问题。在内部搭建的 Minio 集群在做数据 restore 的时候，因为文件处理性能等因素，经常遇到访问超时等场景，所以一直在关注是否有相关的系统可以提供更好的读写稳定性。

由于 S3 协议经过多年的演化，已经成了对象存储的工业标准。很多人都有想过用 fuse 的方式使用 S3 的存储能力。事实上基于 S3 的文件系统有很多款，例如开源的 s3fs-fuse、ossfs、RioFS、CurveFS 等。

在通过实际调研以及大量的测试后，基于 Curve 的性能（尤其是元数据方面，CurveFS 是基于 RAFT 一致性协议自研的元数据引擎，与其他没有元数据引擎的 S3 文件系统(比如 s3fs,ossfs)相比具备巨大的性能优势），易运维，稳定性，Curve 可以同时提供块存储以及文件存储能力等能力以及 Curve 活跃的开源氛围，最终选用了 CurveFS。

CurveFS 结合 ES 的实践

CurveFS 简介

CurveFS 是一个基于 Fuse 实现的兼容 POSIX 接口的分布式文件系统，架构如下图所示:

CurveFS 由三个部分组成：

1. 客户端 curve-fuse，和元数据集群交互处理文件元数据增删改查请求，和数据集群交互处理文件数据的增删改查请求。

2. 元数据集群 metaserver cluster，用于接收和处理元数据(inode 和 dentry)的增删改查请求。metaserver cluster 的架构和 CurveBS 类似，具有高可靠、高可用、高可扩的特点：MDS 用于管理集群拓扑结构，资源调度。metaserver 是数据节点，一个 metaserver 对应管理一个物理磁盘。CurveFS 使用 Raft 保证元数据的可靠性和可用性，Raft 复制组的基本单元是 copyset。一个 metaserver 上包含多个 copyset 复制组。

3. 数据集群 data cluster，用于接收和处理文件数据的增删改查。data cluster 目前支持两存储类型：支持 S3 接口的对象存储以及 CurveBS（开发中）。

Curve 除了既能支持文件存储，也能支持块存储之外，从上述架构图我们还能看出 Curve 的一个特点：就是 CurveFS 后端既可以支持 S3，也可以支持 Curve 块存储。这样的特点可以使得用户可以选择性地把性能要求高的系统的数据存储在 Curve 块存储后端，而对成本要求较高的系统可以把数据存储在 S3 后端。

ES 使用 CurveFS

CurveFS 定位于网易运维的云原生系统，所以其部署是简单快速的，通过 CurveAdm 工具，只需要几条命令便可以部署起 CurveFS 的环境，具体部署见[1][2]；部署后效果如下图:

在日志存储场景，改造是完全基于历史的服务器做的在线改造。下图是线上日志的一个存储架构示例，node0 到 node5 可以认为是热存储节点，机器为 12*4T，128G 的存储机型，每个节点跑 3 个 ES 实例，每个实例 32G 内存，4 块独立盘。node6 到 node8 为 12*8T 的存储机型，3 台服务器跑一个 Minio 集群，每台机器上的 ES 实例不做数据本地写。

可以看到主要的改造重点是将 node6 到 node8，3 个节点进行 ES 的配置改造，其中以 node6 节点的配置为例：

cluster.name: ops-elknode.name: ${HOSTNAME}network.host: [_local_,_bond0_]http.host: [_local_]discovery.zen.minimum_master_nodes: 1action.auto_create_index: truetransport.tcp.compress: trueindices.fielddata.cache.size: 20%path.data: /home/nbs/elk/data1/datapath.logs: /home/nbs/elk/data1/logs- /curvefs/mnt1xpack.ml.enabled: falsexpack.monitoring.enabled: falsediscovery.zen.ping.unicast.hosts: ["ops-elk1:9300","ops-elk7:9300","ops-elk7:9300","ops-elk8.jdlt.163.org:9300"]node.attr.box_type: cold

如配置所示，主要的改造为调整 ES 的数据存储目录到 CurveFS 的 fuse 挂载目录，然后新增 node.attr.box_type 的设置。在 node6 到 node8 上分别配置为 cold，node1 到 node5 配置对应属性为 hot，所有节点配置完成后进行一轮滚动重启。

ES 设置

除了底层配置外，很重要的一点就是调整 index 索引的设置。这块的设置难度不高，要点是：

1. 对应索引设置数据分配依赖和 aliases

2. 设置对应的 index Lifecycle policy

其实在新节点开放数据存储后，如果没有亲和性设置，集群马上会启动 relocating 操作。因此建议对存量的索引新增 routing.alloction.require 的设置来避免热数据分配到 CurveFS 存储节点。针对每天新增索引，建议加入以下这样的 index template 配置。

{  "template": {    "settings": {      "index": {        "lifecycle": {          "name": "syslog",          "rollover_alias": "syslog"        },        "routing": {          "allocation": {            "require": {              "box_type": "hot"            }          }        },        "number_of_shards": "10",        "translog": {          "durability": "async"        }      }    },    "aliases": {      "syslog": {}    },    "mappings": {}  }}

这个 index template 设置的核心要点：

1. routing 部分要指定新索引写到热数据节点

2. lifecycle 中的新增 rollover_alias 设置

index 部分的 lifecycle 是指索引的生命周期策略，需要注意 rollover_alias 里面的值要和下面的 aliases 定义对齐。

冷数据的切换，可以在 kibana 的 index_lifecycle_management 管理页面设置。针对上面的 syslog 场景，hot 部分设置如下图，其余基本默认的就可以了。

在索引周期管理配置页面中，除了设置 hot phase，还可以设置 warm phase，在 warm phase 可以做一些 shrink，force merge 等操作，日志存储场景我们直接做 hot 到 cold 的处理逻辑。

从技术上讲，日志存储类型的业务，底层索引一旦完成写后基本不做再次的数据更改，设置索引副本数量主要是为了应对分布式系统节点宕机等异常场景的数据恢复。如果存储层面有更可靠的方式，那么自然而然可以将 es 的副本数量调整为 0。因此杭研云计算存储团队研发的一款基于 S3 后端的存储文件系统 CurveFS，自然而然进入了冷数据选型的视野。从技术上讲内部 S3 存储基于 EC 纠删码的实现，通过降低 ES 的副本数量为 0，可以明显的降低对存储空间的使用需求。

后续规划

与 Curve 社区小伙伴沟通后，社区在 CurveFS 在存算分离方向的后续规划为：

• Curve 文件存储后端完全支持 Curve 块存储，满足一些场景下对性能的需求。预计 2023 Q1 发布。

• Curve 文件存储支持生命周期管理，支持用户自定义数据冷热，数据按需存储在不同集群中。预计 2023 Q2 发布。

• Curve 完全支持云原生部署。当前客户端已经支持 CSI，集群的部署支持预计 2023 Q2 发布。

参考资料

[1]：https://github.com/opencurve/curveadm/wiki/curvefs-cluster-deployment

[2]：https://github.com/opencurve/curveadm/wiki/curvefs-client-deployment

本文作者

顾贤杰，网易系统运维专家，杭研 SA&SRE 团队负责人

吴宏松，Curve Maintainer