elasticsearch如何设计集群

本文为博客园做者所写： 一寸HUI，我的博客地址：https://www.cnblogs.com/zsql/

　　在写本文时就在想，若是让你负责一个elasticsearch集群，从零开始，你会从哪些方面考虑？咱们也知道es基本都是开箱即用，并且也很好用，配置参数也用默认的就好，只是这么简单的用不难，可是要想更好的用好es集群，那要怎么去作设计呢？咱们知道想要用es集群，首先要安装es集群，固然es安装须要硬件，也就是服务器的支撑，若是安装好了es集群，也不能空跑吧，因此要有数据，因此要写入数据，固然写入数据是为了后期有所用，好比查询数据，作分析等。用是能够了，若是数据量增大，业务更加复杂，还要考虑如何更好的用，怎么用能够提升效率？一个集群也不可能只有一我的用呀，若是不少人用，就会存在不安全，须要考虑权限吧，想一想也算健全了，可是万一哪天机器出问题了，数据丢失了怎么办？是否是须要作可靠的备份呢？若是整个集群完完了，又怎么办呢？固然这样的状况基本不可见，可是是否是要考虑进来呢？就算从安全和容错，以及性能方面都考虑清除了，集群正常运行了，不少时候都不免天有不测风云，是否是要常常关注整个集群或者索引的一些状态信息呢？不能时时刻刻盯着集群的健康状态吧，因此这里须要监控一下集群吧，固然到这里位置整个集群算是很好的运行起来了，可是后期随着数据量的增长，业务的增加，运维难度就会愈来愈大，因此前期的设计很重要，规范化管理很重要。大概就想了这么多，本文的内容也是围绕着这些问题进行展开的。有兴趣的请继续往下读。声明：本文是elasticsearch的版本为7.8.1

1、如何对机器进行选择

一、内存

　　若是有一种资源是最早被耗尽的，它多是内存。排序和聚合都很耗内存，因此有足够的堆空间来应付它们是很重要的。即便堆空间是比较小的时候， 也能为操做系统文件缓存提供额外的内存。由于 Lucene 使用的许多数据结构是基于磁盘的格式，Elasticsearch 利用操做系统缓存能产生很大效果。

　　64 GB 内存的机器是很是理想的， 可是32 GB 和16 GB 机器也是很常见的。

二、磁盘

　　硬盘对全部的集群都很重要，对大量写入的集群更是加倍重要（例如那些存储日志数据的）。硬盘是服务器上最慢的子系统，这意味着那些写入量很大的集群很容易让硬盘饱和，使得它成为集群的瓶颈。

　　若是你负担得起 SSD，它将远远超出任何旋转介质（注：机械硬盘，磁带等）。 基于 SSD 的节点，查询和索引性能都有提高。若是你负担得起，SSD 是一个好的选择，若是使用了机械磁盘，使用 RAID 0 是提升硬盘速度的有效途径，对机械硬盘和 SSD 来讲都是如此。没有必要使用镜像或其它 RAID 变体，由于高可用已经经过 replicas 内建于 Elasticsearch 之中，再不济，一台机器也多弄几个磁盘，这样在配置的能够指定多几个目录，这样能下降一个磁盘的io压力。

三、cpu

大多数 Elasticsearch 部署每每对 CPU 要求不高。所以，相对其它资源，具体配置多少个（CPU）不是那么关键。可是仍是建议16核以上做为生产环境，由于elasticsearch的thread pool和这个配置直接相关。若是你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远赛过稍微快一点点的时钟频率。

四、网络

　　快速可靠的网络显然对分布式系统的性能是很重要的。 低延时能帮助确保节点间能容易的通信，大带宽能帮助分片移动和恢复。现代数据中心网络（1 GbE, 10 GbE）对绝大多数集群都是足够的。Elasticsearch 假定全部节点都是平等的—​并不会由于有一半的节点在150ms 外的另外一数据中心而有所不一样。更大的延时会加剧分布式系统中的问题并且使得调试和排错更困难。

参考《ES权威指南》：https://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.html

2、集群安装要怎么配置和设计

2.一、系统设置

官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/system-config.html

1、设置系统配置 ulimit #暂时修改，切换到该用户es，ulimit -n 65535 
/etc/security/limits.conf #永久修改 es -  nofile  65535 ulimit -a #查看当前用户的资源限制 2、禁用sawpping 方式一： swapoff -a #临时禁用全部的swap文件 vim /etc/fstab #注释掉全部的swap相关的行，永久禁用 方式二： cat /proc/sys/vm/swappiness #查看该值 sysctl vm.swappiness=1 #临时修改该值为1 vim /etc/sysctl.conf #修改文件 永久生效 vm.swappiness = 1 #若是有该值，则修改该值，若没有，则追加该选项，sysctl -p生效命令 方式三： 配置elasticsearch.yml文件，添加以下配置： bootstrap.memory_lock: true GET _nodes?filter_path=**.mlockall #检查如上配置是否成功 注意：若是试图分配比可用内存更多的内存，mlockall可能会致使JVM或shell会话退出!

3、配置文件描述符 ulimit -n 65535 #临时修改 vim /etc/security/limits.conf #永久修改 es soft nproc 65535 es hard nproc 65535

4、配置虚拟内存 sysctl -w vm.max_map_count=262144 #临时修改该值 vim /etc/sysctl.conf #永久修改 vm.max_map_count=262144

5、配置线程数 ulimit -u 4096 #临时修改 vim /etc/security/limits.conf #永久修改

2.二、基本安装配置

节点设计：

默认状况下，全部的节点都是master节点，data节点，ingest节点，ml节点（若是为true），数据节点也是transform节点

 节点的类型：

1. Master-eligible node 候选主节点node.master: true，主节点负责建立或删除索引，跟踪哪些节点是集群的一部分，以及决定将哪些碎片分配给哪些节点。全部的候选主节点在没有配置node.voting_only: true的状况下，均可以经过选举称为主节点。主节点必须可以访问data数据目录，也能够设置专用的主节点，通常至少选用3台，把其余的角色设置为false便可。
2. Data node 用于数据的存储，CRUD，搜索，聚合等,node.data: true，数据节点保存包含已创建索引的文档的分片。数据节点处理与数据相关的操做，如CRUD、搜索和聚合。这些操做是I/O密集型、内存密集型和cpu密集型，也能够设置专用的数据节点
3. Ingest node 用于数据前期的预处理，相似logstash，node node.ingest: true
4. Machine learning node 用于运行做业和处理机器学习API请求
5. Transform node 用于数据转换node.transform: true，若是是数据节点，则默认为true，不然false
6. Coordinating node  协调节点，每一个节点都是协调节点，不可关闭，协调节点将请求转发给持有数据的数据节点。每一个数据节点在本地执行请求，并将其结果返回给协调节点。在收集阶段，协调节点将每一个数据节点的结果减小为单个全局结果集

 　　 若是集群很小，机器不够用的状况下，能够把数据节点和主节点公用，若是想要主节点高可用的话，就要至少在3台机器上配置node.master：true，固然还能够更多，奇数就行了，若是机器不少，能够把主节点和数据节点分离，这样配置更加单一原则，主节点更加稳定，因此集群也会更加稳定。具体怎么配置见官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/modules-node.html

再看看elasticsearch几个重要的配置：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/important-settings.html

1、数据目录配置 path: data: - /mnt/elasticsearch_1 - /mnt/elasticsearch_2 - /mnt/elasticsearch_3 或者path.data: /data/es/es_cluster 2、log日志目录配置 path.logs: /data/es/es_cluster/elasticsearch-7.8.1/logs 3、集群名配置 cluster.name: es1304、节点名配置 node.name: prod-data-2

5、network.host配置 network.host: 192.168.88.130 #默认为回环地址127.0.0.1，生产环境须要修改 6、集群节点发现配置 discovery.seed_hosts: ["192.168.88.130","192.168.88.131","192.18.88.132] #例如集群三个节点 cluster.initial_master_nodes: ["es130","es131","es132"] #配置集群初始化首次启动符合主节点的列表

2.三、jdk相关配置

推荐使用elasticsearch自带的jdk，elasticsearch7.8.1默认的是openjdk 14，因此配置好jdk相关的JAVA_HOME就好

export JAVA_HOME=/data/es/elasticsearch-7.8.1/jdk export PATH=$JAVA_HOME/bin:$PATH

　　还有一个重点配置就是java堆大小的配置，这个参数影响到太多的性能，若是内存容许的话，直接配上20-30G就行了，这里要注意堆的最大值和最小值要同样，否则启动的时候会检查这两个不同就会报错。

参考官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/heap-size.html

配置jvm.options 文件或者配置ES_JAVA_OPTS变量

配置文件config/jvm.options 

自定义的jvm选项能够配置在config/jvm.options.d/文件夹下，必须以.options结尾的文件，这里只例举了一小部分配置，具体还有垃圾回收等相关配置

-Xms2g -Xmx2g 8 ：-Xmx2g #java8 8 -：- Xmx2g #大于java8 8 - 9 ： - Xmx2g #java8到java9

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

设置Xmx和Xms你的物理内存不超过50％。Elasticsearch出于JVM堆之外的目的须要内存，所以为此留出空间很重要。

设置Xmx而且Xms不超过JVM用于压缩对象指针（JVM compressed oops）的阈值；确切的阈值有所不一样，但接近32 GB（4-32G则启用UseCompressedOop；）

3.四、相关插件配置

一、ik分词插件配置

下载地址：https://github.com/medcl/elasticsearch-analysis-ik/releases

须要下载对应的版本，而后解压在plugins目录下，而后重启集群便可

 

二、head插件安装

header插件上手

https://github.com/mobz/elasticsearch-head

https://nodejs.org/zh-cn/download/

第一种：使用谷歌浏览器head插件

第二种：使用head服务

#Running with built in server git clone git://github.com/mobz/elasticsearch-head.git cd elasticsearch-head npm install npm run start open http://localhost:9100/

三、hdfs插件（用于备份还原）

下载：https://artifacts.elastic.co/downloads/elasticsearch-plugins/repository-hdfs/repository-hdfs-7.8.1.zip

安装文档：https://www.elastic.co/guide/en/elasticsearch/plugins/7.9/plugin-management-custom-url.html  #7.9的文档不影响哈

 具体执行：./bin/elasticsearch-plugin install file:///data/hd07/car/repository-hdfs-7.8.1.zip   #这里不要忘记加file:///

而后须要重启ES的集群

3、索引要怎么设计

　　首先索引建立后，索引的分片只能经过_split和_shrink接口对其进行成倍的增长和缩减，主要是由于es的数据是经过_routing分配到各个分片上面的，因此本质上是不推荐去改变索引的分片数量的，由于这样都会对数据进行从新的移动。还有就是索引只能新增字段，不能对字段进行修改和删除，缺少灵活性，因此每次都只能经过_reindex重建索引了。还有就是一个分片的大小以及因此分片数量的多少严重影响到了索引的查询和写入性能。因此可想而知，设计一个好的索引可以减小后期的运维管理和提升很多性能。因此前期对索引的设计是至关的重要的。

• 好的索引设计在整个集群规划中占据举足轻重的做用，索引的设计直接影响集群设计的好坏和复杂度。
• 好的索引设计应该是充分结合业务场景的时间维度和空间维度，结合业务场景充分考量增、删、改、查等全维度设计的。
• 好的索引设计是彻底基于“设计先行，编码在后”的原则，前期会花很长时间，为的是后期工做更加顺畅，避免没必要要的返工

索引的设计详情见个人另一篇文章：elasticsearch如何设计索引

4、读写性能要怎么提高

　　读写就是插入和查询嘛，写的话可能有并发写，还有就是是否写完要立马可见，查的话仍是和需求有关系，还有就是对查询一个语法的使用，还有就是查询数据会不会在内存中命中，这样的就减小去访问磁盘了，这里不说查询的一些语法和怎么查询更优，由于我的以为这是属于应用级别的，和集群相关性不强，这里大概例举几个配置。

首先这里说一句，当并发写入的时候，一定涉及到thread pool的配置，这些配置不建议修改，可是实在不行，也能够提升到cpu核数的两倍，因此涉及到并发的，和计算的，固然cpu越好性能就会也好。

写和查询的时候会涉及到一些参数，能够根据实际状况调整提高性能：（下面的都不是默认值了，能够在官网去查询）

#能够配置在elasticsearch.yml文件中
indices.memory.index_buffer_size: 20% indices.memory.min_index_buffer_size: 96mb indices.queries.cache.size: 20% indices.requests.cache.size: 2% 
#这里是索引级别的配置，须要配置在索引里面 index.merge.scheduler.max_thread_count: 1 #这个若是是ssd，使用默认的配置就好，这里配置为机械磁盘 index.refresh_interval: 60s index.store.type: hybridfs index.translog.sync_interval: 10s index.translog.flush_threshold_size: 1024mb

固然还有不少的配置，好比有配置translog的类型，能够提高性能，可是可能会牺牲数据的一致性。优化这种事情仍是根据实际状况进行针对性的优化和取舍比较好。

5、权限要怎么控制

　　权限这个东西真的很重要，毕竟不是全部人操做起来都很当心，也不是全部人的技术都很牛逼，也不是全部人都不会偷偷的搞事情，因此这么重要的数据固然须要管控起来撒。

直接参考个人另一篇博客吧，更加详细：elasticsearch7.8权限控制和规划

6、要怎么备份和还原

　　如今不少集群都是有多个副本，固然也是把容错机制看的很重要，在这种分布式的系统里面，数据的容错是很是重要的，好比elasticsearch，kafka，hdfs等，elasticsearch做为一个高速度的查询分布式集群，经过副原本进行容错，可是通常推荐副本为1，虽然大部分状况下是不会丢数据，可是不免会存在特殊状况。副本设置太多会影响性能，设置为1比较合适，可是若是一个分片的主分片和副分片所在的磁盘同时出问题呢，或者两台机器同时出问题呢，或者这几天操做异常，致使数据不正确，想恢复到几天前的索引呢，因此备份就显得尤其的重要了。

具体的备份还原详细文档请参考个人另外一篇文章：elasticsearch备份和还原（基于hdfs）

7、怎么监控集群

　　集群正常运行了，咱们须要常常关注集群的一些状态，或者节点级别，索引级别的一些状态，这些都是根据需求进行选择，好比对于我来讲，关心集群的粒度既能够了。

这里监控能够选不少种，好比elk，zabbix，prometheus等，固然看本身熟悉什么了，就能够选用什么组件，不过elasticsearch这么特别的集群可使用elk，毕竟ES也是elk中的一员。

看看elk监控的官方架构：（还须要一个es集群，不过节约点也能够一个集群，可是这样不稳妥）

官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/monitoring-overview.html

 

 固然我是没有使用elk这样的监控，由于对zabbix比较数据，需求也不高，经过zabbix的web监控就搞定了，复杂点的可使用elasticsearch的_cat API获取集群的相关状态信息，结合zabbix监控也很简单。

本文纯属我的的思考和想法，没有具体去实践（查询理论。。。），固然理论是可靠的。固然目前的思考可能也不会很全面，也不知道给博友有没有更好的建议呢？

 

参考：https://mp.weixin.qq.com/s?__biz=MzI2NDY1MTA3OQ%3D%3D&chksm=eaa82cfcdddfa5eacfcddb0cf54edcecb3ad86ca2cafd6f4f2d90cf8a4033d83eb16cb2a56f0&idx=1&mid=2247484628&scene=21&sn=666e416ae28b93e42c26f26b208dea84#wechat_redirect