01 Elasticsearch 宽泛应用带来的老本问题
Elasticsearch（下文简称“ES”）是一个分布式的搜索引擎，还可作为分布式数据库来应用，罕用于日志解决、剖析和搜寻等场景；在运维排障层面，ES 组成的 ELK（Elasticsearch+ Logstash+ Kibana）解决方案，简略易用、响应速度快，并且提供了丰盛的报表；高可用方面，ES 提供了分布式和横向扩大；数据层面，反对分片和多正本。
ES 的应用便捷，生态残缺，在企业之中失去了宽泛的利用。随之而来的是物理资源和费用的减少，如何升高 ES 场景的老本成为了大家广泛关怀的话题。
如何升高 ES 的老本
ES 的次要的老本是主机老本，主机老本又分为计算资源和存储资源。
计算资源简略了解就是 CPU 和内存，如果升高 CPU 和主机的数量，意味着计算能力会降落，因而通常会采纳冷热节点；热节点应用高配的机器，冷节点应用低配的机器；比方 CPU 内存比从 1:4 升高为 1:8，如 8C32G->4C32G。然而没有升高内存，因为 ES 对内存有更高的需要，来进步响应速度。或者采纳低频的 CPU，更老的硬件。
存储老本是远大于计算成本的，是要重点思考的老本 。当初的存储介质通常是 SSD 和 HDD 这种两种介质，在云厂商 SSD 的老本是 0.8 元 /G，HDD 的老本是 0.35 元 /G，对象存储的价格是 0.12 元 /G。但前两种设施是块设施，提供的是文件系统的协定，但对象存储反对是 S3 协定的，彼此之间不兼容。
如何将对象存储和 ES 联合起来，咱们调研了两种计划。
第一种计划，批改 ES 存储引擎，适配对象存储调用。这种形式须要批改 ES 的源码，团队要投入很多的人力来做开发设计调研以及最初的验证，投入产出比是非常低的。
第二种计划是将对象存储作为磁盘来应用，将其挂载到操作系统。把 ES 分为 hot 和 warm 节点。hot 节点存储热数据，挂载的是块设施。warm 节点应用对象存储。
02 对象存储文件系统选型
文件系统选型的时候次要思考了三个方面。 第一个是性能，首先要满足最根本的性能需要，第二个是性能，第三个是可靠性 。咱们调研了 s3fs、goofys 和 JuiceFS。
性能方面，s3fs 和 goofys 在 read 和 write 方面没有本地缓存，其性能是依附 s3 的性能来撑持的，这两个文件系统整体的性能相比 JuiceFS 会低一些。
最显著的是 mv，对象存储没有 rename 操作，在对象存储中进行 rename 操作就是一个 copy 加 delete，性能代价是十分大的。
ls 方面，对象存储的存储类型是 kv 存储，不具备目录语义，所以 ls 整个目录构造对于 s3 来说，其实是对整个元数据的遍历，调用代价十分大。在大数据的场景下，性能是非常低的，并且有一些个性性能是不反对的。
元数据方面，s3fs 和 goofys 没有本人独立的元数据，所有的元数据都是依赖于 s3 的，JuiceFS 有本人的独立的元数据存储，
易用性方面，这几个产品都是非常简单易用，通过一个简略的命令就能够实现 s3 的挂载；从可维护性来说，JuiceFS 有本人的独立的元数据引擎，咱们须要对元数据服务进行运维；从社区的角度来说，JuiceFS 的社区活跃度是最高的。基于以上综合思考，金山云抉择了 JuiceFS。
基于 JuiceFS 的测试
JuiceFS 产品介绍中第一句话就是“像本地盘一样应用对象存储”，恰好是咱们做 ES 时所须要的性能。JuiceFS 曾经集成了很多种对象存储，金山云的 KS3 也曾经残缺兼容，只须要再选一个元数据库即可。
第二性能验证。元数据库罕用的有 Redis，关系型据库、KV 数据库等。咱们从这三个层面，元数据库撑持的数据量、响应速度、可运维性来做判断。
从数据量上来说，TiKV 无疑是最高的，然而咱们的设计初衷是让每套 ES 集群独立一个元数据库实例，因而不同集群之间的元数据是不进行共享的，为了高可用彼此间须要相互隔离。
其次在响应速度方面，ES 把 JuiceFS 作为冷节点存储，冷节点存储的数据 IO 要比元数据的调用性能损耗更大，所以咱们认为元数据的调用性能不是外围思考的点。
从运维的角度来说，关系型数据库大家都比拟熟，开发人员都能够很轻松的上手，其次公司是有公司有 RDS For MySQL 产品，有业余的 DBA 团队来负责运维，所以最终是抉择了 MySQL 作为的元数据引擎。
JuiceFS 可靠性测试
元数据选型完当前，咱们对 JuiceFS 进行了可靠性测试，JuiceFS 挂载到主机上只须要三步：
第一步，创立文件系统，咱们要指定 bucket 来确定它的 AK、SK 以及元数据库；
第二步，把文件系统 mount 到磁盘上；
第三步，把 ES 软链到 JuiceFS 的 mount 目录上。
尽管设计初衷是将 JuiceFS 作为冷节点，然而在测试的过程中，咱们想用一种极限的形式来压测 JuiceFS。咱们设计了两种极限压测。
第一个：将 JuiceFS + KS3 挂载到 hot 节上，把数据实时写到 JuiceFS。
ES 的写入流程是先写到 buffer 中也就是内存外面，当内存满或者是达到索引设定的工夫阈值当前，会刷新到磁盘上，这时候会生成 ES 的 segment。它是由一堆的数据和元数据文件来形成的，每次刷新就会生成一系列的 segment，这时候就会产生频繁的 IO 调用。
咱们通过这种压测的形式来测试 JuiceFS 整体的可靠性，同时 ES 自身它会有一些 segment merge。这些场景在 warm 节点是不具备的，所以咱们是想用一种极限的形式来压测。
第二种策略，通过生命周期治理来做热数据到冷数据的迁徙。
测试的时候 JuiceFS1.0 还没有公布，测试的过程中的确发现了问题，在实时写的过程中会呈现了数据损坏的状况，跟社区沟通后能够通过批改缓存的大小来防止：
–attr-cache=0.1 属性缓存时长，单位秒 (默认值: 1)
–entry-cache=0.1 文件项缓存时长，单位秒 (默认值: 1)
–dir-entry-cache=0.1 目录项缓存时长，单位秒 (默认值: 1)
这三个参数的缓存默认是 1，把时长改成 0.1，它的确解决了索引损坏的问题，然而会带来一些新的问题，因为元数据的缓存和数据缓存的工夫变短，会导致在执行系统命令的时候，比方 curl 一个系统命令，查看索引数量或者集群状态，失常的状况下，调用可能在秒级，而这种变动可能导致须要数 10 秒才可能实现。
第二个问题就是写入的 QPS 有显著降落。咱们能够看到监控图中 Write QPS 十分不稳固，这并不代表 ES 实在的 QPS，因为监控图中的 QPS 是通过两次失去的 documents 数量来做差失去的，因为旧版 JuiceFS 存在一些内核缓存问题，导致 ES 读到了一些旧数据。咱们把该问题反馈给了社区，JuiceFS 1.0 正式公布后问题失去解决。
咱们就进行了新一轮的测试，新一轮的测试确定了 hot 节点 3 台，8C16G 500G SSD，warm 节点 2 台，4C16G 200G SSD，测试时长 1 周，每天写入数据量 1TB(1 正本)，1 天后转到 warm 节点。没有再呈现索引数据损坏状况，通过这次压测没有再呈现之前遇到的问题，这就给了咱们信念，接下来咱们把整个的 ES 逐步的往这方面来做迁徙。
JuiceFS 数据存储和对象存储的差别
JuiceFS 有本人的元数据，所以在对象存储上和 JuiceFS 当中看到的目录构造是不一样的。
JuiceFS 分为三层构造，chunk、slice、block，因而咱们在对象存储下面看到的是 JuiceFS 对文件做拆分之后的数据块。然而所有的数据是通过 ES 来治理，所以这一点用户不须要关注，只须要通过 ES 来执行所有的文件系统操作即可。JuiceFS 会失当治理对象存储中的数据块。
通过这一系列的测试后，金山云将 JuiceFS 利用在日志服务（Klog）中，为企业用户提供一站式日志类数据服务，实现了云上的数据能够不出云，间接就实现数据采集，存储剖析以及告警的一站式服务；云下的数据提供了 SDK 客户端，通过采集工具来实现数据上云的整个整条链路，最初能够把数据投递到 KS3 和 KMR，来实现数据的加工计算。
03 Elasticsearch 冷热数据管理
ES 有几个罕用概念：Node Role、Index Lifecycle Management、Data Stream。
Node Role，节点角色。每一个 ES 节点会调配不同的角色，比方 master、data、ingest。重点介绍一下 data 节点，老版本是分为三种，就是 hot、warm、cold 节点，在最新的版本外面减少了 freeze，冷冻节点。
Index Lifecycle Management（ILM）咱们分为了 4 个阶段：
- hot: 索引正在被频繁更新和查问。
- warm: 索引不再被更新，但查问量个别。
- cold: 索引不再被更新，并且很少被查问。这些信息依然须要可搜寻，但如果查问速度较慢也没关系。
- delete: 索引不再须要，能够平安地删除。
ES 官网提供了一个生命周期的管理工具，咱们能够基于索引的大小，docs 数量的大小以及工夫策略，把一个大的索引拆分成成多个小索引。一个大索引从治理运维查问，它的开销的代价是十分大的。生命周期治理性能不便咱们更灵便地治理索引。
Data Stream 是在 7.9 版本提出推出了一个新性能，它是基于索引生命周期治理来实现了一个数据流写入，能够很不便地解决工夫序列数据。
在查问多个索引时，通常是把这些索引合并在一起来查问，咱们能够应用 Data Stream，他就像一个别名一样，能够自行路由到不同的索引外面。Data Stream 对时序数据的存储管理和查问来说更敌对，这个是来对 ES 的冷热治理下面是来更近了一步，不便整个的运维治理。
正当布局冷节点大小
当咱们把冷数据放到对象存储上时，会波及到冷节点的治理，次要是分为三个方面：
第一：内存和 CPU 以及存储空间。内存的大小决定了分片的数量。咱们通常会在 hot 节点会把物理内存依照一半一半进行划分:
一半给 ES 的 JVM，另外一半是给 Lucene。Lucene 是 ES 的检索引擎，为其调配足够的内存，能晋升 ES 查问体现。因而相应地，咱们在冷数据节点能够适当的把 JVM 内存，而后缩小 Lucene 内存，不过 JVM 的内存不要超过 31G。
第二：CPU/ 内存比从后面提到的 1:4 降到 1:8。在存储空间上应用了 JuiceFS 和对象存储能够认为存储空间是有限的，但因为它是挂在冷节点上的，尽管有有限的空间能够应用，然而受限于内存大小，所以这就决定了有限存储空间的只是现实状态。如果再扩充，整个 ES 的在冷节点的稳定性下面就会有比拟大的隐患。
第三：存储空间。以 32G 内存 为例，正当的存储空间为 6.4 TB。能够通过扩充分片的数量来扩充空间，但在 hot 节点，分片数量是要严格控制的，因为须要思考到 hot 节点的稳定性，在冷节点适当放大这个比例是能够的。
这里须要重点思考的因素有两个，就是一个是稳定性，第二个数据恢复时长。因为当节点挂掉，比方 JuiceFS 过程挂掉，或者冷节点挂掉，或者运维的时候须要从新挂载，这时候就须要把所有的数据从新加载到 ES 外面，将会在 KS3 产生大量的频繁读数据申请，如果数据量越多，那么整个的 ES 的分片工夫复原时长会越长。
罕用的索引分片治理办法
治理办法次要思考三个方面：
- shard 过大: 导致集群故障后复原迟缓; 容易造成数据写热点，导致 bulk queue 打满，回绝率回升；
- shard 过小: 造成更多的 shard，占用更多的元数据，影响集群稳定性; 升高集群吞吐；
- shard 过多: 造成更多的 segment，IO 资源节约重大，升高查问速度; 占用更多内存，影响稳定性。
数据在写入的时候，整个的数据大小是不确定的，通常会先创立模板，先确定固定的分片的大小，确定分片的数量，而后再创立 mapping 以及创立索引。
这时候就可能会呈现两个问题，第一个就是分片过多，因为在预期的时候不晓得到底要写入到多少数据，有可能我创立的分片多，然而没有更多的数据进来。
第二个就是创立的分片数量过少，会导致索引过大，这时候会须要把小的分片进行合并，须要把采纳更长的工夫做数据的 rotate，再把一些小的 segment 合并成更大的 segment，防止占用更多的 IO 和内存。同时还须要删除一些空索引，空索引尽管没有数据，然而它会占用内存。倡议正当的分片大小是管制在 20～50g。
04 JuiceFS 应用成果及注意事项
以某线上集群为例，数据规模：每天写入 5TB，数据贮存 30 天，热数据贮存一周，节点数量：5 个热节点，15 个冷节点。
采纳 JuiceFS 后，热节点放弃不变，冷节点从 15 个降到了 10 个，同时咱们用了一个 1TB 的机械硬盘做给 JuiceFS 来做缓存。
能够看到在凌晨的时候会有大量对象存储调用，这因为咱们把整个的生命周期的治理操作放到了低峰期来运行。
JuiceFS 内存占用通常会在几百 MB，它在高峰期调用的时候会在不到 1.5G 以及它的 CPU 的占用，体现无异样。
以下是 JuiceFS 的应用注意事项：
第一：不共用文件系统。 因为咱们把 JuiceFS 挂载到冷节点上，那么每一台机器上所看到的是一个全量的数据，更敌对的形式是采纳多个文件系统，每一个 ES 节点采纳一个文件系统，这样能做到隔离，然而会带来相应的治理问题。
咱们最终选定的是一套 ES 对应一个文件系统的模式，这个实际带来的问题是：每一个节点都会看到全量数据，这时候就会容易有一些误操作。如果用户要在下面做一些 rm，有可能会把其余机器上的数据删掉了，然而综合思考咱们是在不同集群之间不共享文件系统，而在同一个集群里，咱们还是应该均衡治理和运维，所以采纳了一套 ES 对应一个 JuiceFS 文件系统 的模式。
第二：手动迁徙数据到 warm 节点。 在索引生命周期治理，ES 会有一些策略，会把热节点的数据迁到冷节点。策略在执行时，有可能是在业务高峰期，这时候会对热节点产生 IO，而后把数据 copy 到冷节点，再把热节点的数据删除，整个热节点的零碎的代价是比拟大的，所以咱们是采纳的手动，来管制哪些索引什么工夫迁徙到冷节点。
第三：低峰错期进行索引迁徙。
第四：防止大索引。 在删除大索引时，它的 CPU 以及 IO 性能要比热节点要差一些，这时候会导致冷节点和 master 失联，失联当前就会呈现了从新加载数据，而后从新复原数据，整个就相当于 ES 故障了，节点故障了，这个代价是十分大的。
第五：正当的分片大小。
第六：敞开回收站。 在对象存储上，JuiceFS 默认保留一天的数据，但在 ES 的场景下是不须要的。
还有一些其余波及到一些大量 IO 的操作，要在 hot 节点实现。比方索引的合并、快照的复原、以及分片的缩小、索引以及数据的删除等，这些操作如果产生在冷节点，会导致 master 节点失联。尽管对象存储老本比拟低，然而频繁的 IO 调用老本会升高，对象存储会要依照 put 和 get 的调用次数来免费，因而须要把这些大量的操作来放到热节点上，只供业务侧冷节点来做一些查问。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)