共计 2957 个字符，预计需要花费 8 分钟才能阅读完成。
背景
稿定科技旗下稿定设计产品是一个聚焦商业设计的多场景在线设计平台，突破了软硬件间的技术限度，会集创意内容与设计工具于一体，为不同场景下的设计需要提供优质的解决方案，满足图片、视频等全类型媒介的设计需要，让设计更简略。
稿定科技应用 Elasticsearch（下文中简称为 ES）作为日志检索组件，随着业务量的增长，每天有 2T 左右的新增数据，须要保留 15~30 天，给磁盘和零碎带来了不小的压力。在 ES 中为了保障日志的写入和查问的性能，大多应用单位存储老本更高的高性能云盘。然而，在理论的业务场景中，超过 7 天的数据仅作低频应用，全副存储在高性能云盘必然会导致过高的老本和空间的节约。
计划
Elasticsearch 7.10 版本推出了索引生命周期概念，开始反对数据分层存储，能够指定不同节点应用不同的磁盘介质来辨别冷热数据，比方应用 HDD 磁盘来存储温冷数据，能取得更大的应用空间和更低的老本。这个个性非常适合日志索引场景。
在温冷数据的存储介质上，应用 JuiceFS 代替 HDD 磁盘，相当于取得了有限容量的存储空间。通过 ES 的索引生命周期治理，能够主动实现索引的创立 – 迁徙 – 销毁整个生命周期治理，无需手工干涉。
在咱们的实际中，首先将 ES 集群降级到目前最新的 7.13 版本。而后拆分冷热节点，热节点优先思考性能，冷节点优先思考存储的容量和老本。同时，调整索引和模板形式，配置数据生命周期、索引模板和数据流，实现索引数据写入。
调整后整个索引的流转如下图所示：
在索引创立时，配置 index.routing.allocation.require.box_type:hot 进行节点筛选；
期待索引进入 warm 周期时，调整 index.routing.allocation.require.box_type:warm，并迁徙到 warm 节点后，数据进入冷节点存储，理论存储于 JuiceFS 中；
期待索引进入 delete 周期时，ES 会主动把索引数据删除。
客户收益
计划中应用的 JuiceFS 是什么呢？
JuiceFS 是一款面向云环境设计的企业级分布式文件系统。提供齐备的 POSIX 兼容性，为利用提供一个低成本、空间有限的共享文件系统。应用 JuiceFS 存储数据，数据自身会被长久化在对象存储（例如，Amazon S3、阿里云 OSS 等），联合 JuiceFS 的元数据服务来提供高性能文件存储。JuiceFS 在寰球私有云服务中都提供有全托管服务，只需点点鼠标，十分钟配置好。同时 JuiceFS 在 2021 年初在 GitHub 开源，受到寰球开发者的关注和参加，目前曾经取得 3700+ stars。
在本计划中 ES 集群 warm 节点应用 JuiceFS 做存储之后，咱们不必再对这些节点做容量布局和扩容工作，也省去了节点故障时的数据迁徙，降老本的同时还为运维带来很大的便当。
JuiceFS 的长久层应用对象存储，弹性计费，TCO 比应用一般云盘还要低。在本计划的 ES 集群中，Hot 节点应用的云盘价格为 1000 元 /TB/ 月，应用全托管的 JuiceFS 服务加上对象存储的开销，价格约为 250 元 /TB/ 月。ES 集群总容量 60TB+，通过冷热分层解决，75% 的数据存在 JuiceFS 中，仅存储老本曾经节俭近 60%。如果再加上运维团队节俭的工夫精力，这个计划为客户的数据存储带来的 TCO 降落至多有 70%。
实际
集群配置
集群共 9 个节点，⼀个独⽴的 master 节点（elastic_001），另外 8 个数据节点，其中有 5 个热数据节点（elastic_002 ~ elastic_006），3 个冷数据节点（elastic_007 ~ elastic_009）。
目录挂载与配置
JuiceFS 挂载在 ES 冷数据节点，提供 ES 的数据⽬录。
节点配置有⼀块 2T 的数据盘，挂载在 /data ⽬录，ES 过程以容器的⽅式启动，数据盘挂载的是零碎的 /data/elastic ⽬录，因为使⽤的容器挂载零碎⽬录的⽅式，不能通过 软链 的⽅式将 ES 数据⽬录 (/data/elastic ) 指向 JuiceFS 挂载的某个⼦⽬录，使⽤了 Linux 零碎的 bind mount 将 JuiceFS 的⼦⽬录挂载到 /data/elastic 这个门路上。⽐如在 007 节点上：
# ./juicefs mount gd-elasticsearch-jfs \
--cache-dir=/data/jfsCache --cache-size=307200 \
--upload-limit=800 /jfs
# mount -o bind /jfs/data-elastic-pro-007 /data/elastic 这样在 /data/elastic ⽬录看到 /jfs/data-elastic-pro-007 的内容。
在 008 和 009 节点上也做相似挂载操作。
如果您还不相熟 JuiceFS 的初始化、挂载等基本操作，请参考 JuiceFS 官网文档。
ES 索引 Rollover 时有很多随机写操作，为了保障写的性能，挂载 JuiceFS 时加上了 writeback 参数，这样会数据先写本地磁盘，后盾异步将数据上传到对象存储。本地磁盘⽬录使⽤的是 /data/jfsCache/gd-elasticsearch-jfs/rawstaging/，请留神不要删除这个⽬录中的任何⽂件，否则可能呈现数据失落。
cache-size 和 upload-limit 别离⽤来限度本地的读缓存使⽤空间为 300GiB，写对象存储的带宽不超过 800Mbps。attrcacheto 和 entrycacheto 别离示意内核的 attr cache 和 entry cache 的缓存超时工夫，单位是秒。
性能优化
升高节点负载
在采纳 JuiceFS 之前，ES 集群生命周期中配置了 Force Merge，具体配置项为 warm.actions.forcemerge.max_num_segments: 1，它会导致数据在 Rollover 时从新 Merge，给 CPU 带来极大的压力。而这步动作是齐全没必要的，敞开 Force Merge 配置即可防止不必要的性能开销，升高节点负载。
Rollover 参数配置优化
因为 warm 阶段数据写入 JuiceFS，最终会长久化到对象存储上，应用层不必再存储多正本，能够在索引 Rollover 过程中，设置 replicas 为 0，即 warm.actions.number_of_replicas: 0。
另外，思考当索引数据迁徙到 warm 阶段后，数据并不再写入，能够设置 warm 阶段索引只读，即 warm.actions.readonly: {}，敞开索引的数据写入能够缩小内存占用量。
总结
随着工夫的推移和业务量的增长，企业势必面临更大规模的数据存储和治理上的双重挑战。在本案中，稿定科技充分发挥 Elasticsearch 的生命周期治理能力，依据业务须要将日志数据进行分层存储。将须要频繁应用的热数据保留在 SSD，而超过 7 天的低频应用数据则存储在性价比更高的 JuiceFS，为客户节俭存储老本 60%。同时，JuiceFS 还为利用提供近乎有限的弹性空间，省去了容量布局、扩容、数据迁徙等一系列的运维工作，晋升了企业 IT 架构的效率。
举荐浏览 ：
Shopee x JuiceFS：ClickHouse 冷热数据拆散存储架构与实际
JuiceFS v0.17 公布，通过 1270 项 LTP 测试！
