关于分布式: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；部署后成果如下图:

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

能够看到次要的革新重点是将 node6 到 node8，3 个节点进行 ES 的配置革新，其中以 node6 节点的配置为例：

cluster.name: ops-elk
node.name: ${HOSTNAME}
network.host: [_local_,_bond0_]
http.host: [_local_]
discovery.zen.minimum_master_nodes: 1
action.auto_create_index: true
transport.tcp.compress: true
indices.fielddata.cache.size: 20%
path.data: /home/nbs/elk/data1/data
path.logs: /home/nbs/elk/data1/logs
- /curvefs/mnt1
xpack.ml.enabled: false
xpack.monitoring.enabled: false
discovery.zen.ping.unicast.hosts: ["ops-elk1:9300","ops-elk7:9300","ops-elk
7: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/…

[2]：https://github.com/opencurve/…

本文作者

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

吴宏松，Curve Maintainer