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-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/...

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

本文作者

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

吴宏松，Curve Maintainer