1. ElasticSearch集群介绍
主节点(或候选主节点)
主节点负责创立索引、删除索引、调配分片、追踪集群中的节点状态等工作, 主节点负荷绝对较轻, 客户端申请能够间接发往任何节点, 由对应节点负责散发和返回处理结果。
一个节点启动之后, 采纳 Zen Discovery机制去寻找集群中的其余节点, 并与之建设连贯, 集群会从候选主节点中选举出一个主节点, 并且一个集群只能选举一个主节点, 在某些状况下, 因为网络通信丢包等问题, 一个集群可能会呈现多个主节点, 称为“脑裂景象”, 脑裂会存在失落数据的可能, 因为主节点领有最高权限, 它决定了什么时候能够创立索引, 分片如何挪动等, 如果存在多个主节点, 就会产生抵触, 容易产生数据失落。要尽量避免这个问题, 能够通过 discovery.zen.minimum_master_nodes 来设置起码可工作的候选主节点个数。 倡议设置为(候选主节点/2) + 1 比方三个候选主节点,该配置项为 (3/2)+1 ,来保障集群中有半数以上的候选主节点, 没有足够的master候选节点, 就不会进行master节点选举,缩小脑裂的可能。
主节点的参数设置:
node.master = truenode.data = false
数据节点
数据节点负责数据的存储和CRUD等具体操作,数据节点对机器配置要求比拟高、,首先须要有足够的磁盘空间来存储数据,其次数据操作对系统CPU、Memory和IO的性能耗费都很大。通常随着集群的扩充,须要减少更多的数据节点来进步可用性。
数据节点的参数设置:
node.master = falsenode.data = true
客户端节点
客户端节点不做候选主节点, 也不做数据节点的节点,只负责申请的散发、汇总等等,减少客户端节点类型更多是为了负载平衡的解决。
node.master = falsenode.data = false
提取节点(预处理节点)
能执行预处理管道,有本人独立的工作要执行, 在索引数据之前能够先对数据做预处理操作, 不负责数据存储也不负责集群相干的事务。
参数设置:
node.ingest = true
- 协调节点
协调节点,是一种角色,而不是实在的Elasticsearch的节点,不能通过配置项来指定哪个节点为协调节点。集群中的任何节点,都能够充当协调节点的角色。当一个节点A收到用户的查问申请后,会把查问子句散发到其它的节点,而后合并各个节点返回的查问后果,最初返回一个残缺的数据集给用户。在这个过程中,节点A表演的就是协调节点的角色。
ES的一次申请十分相似于Map-Reduce操作。在ES中对应的也是两个阶段,称之为scatter-gather。客户端收回一个申请到集群的任意一个节点,这个节点就是所谓的协调节点,它会把申请转发给含有相干数据的节点(scatter阶段),这些数据节点会在本地执行申请而后把后果返回给协调节点。协调节点将这些后果汇总(reduce)成一个繁多的全局后果集(gather阶段) 。
- 部落节点
在多个集群之间充当联结客户端, 它是一个非凡的客户端 , 能够连贯多个集群,在所有连贯的集群上执行搜寻和其余操作。 部落节点从所有连贯的集群中检索集群状态并将其合并成全局集群状态。 把握这一信息,就能够对所有集群中的节点执行读写操作,就如同它们是本地的。 请留神,部落节点须要可能连贯到每个配置的集群中的每个单个节点。
2. ElasticSearch集群原理
2.1 集群分布式原理
ES集群能够依据节点数, 动静调整分片与正本数, 做到整个集群无效平衡负载。
单节点状态下:
两个节点状态下, 正本数为1:
三个节点状态下, 正本数为1:
三个节点状态下, 正本数为2:
2.2 分片解决机制
设置分片大小的时候, 需事后做好容量布局, 如果节点数过多, 分片数过小, 那么新的节点将无奈分片, 不能做到程度扩大, 并且单个分片数据量太大, 导致数据重新分配耗时过大。
假如一个集群中有两个数据节点。movie索引的分片散布状况如下所示:
PUT /orders{ "settings":{ "number_of_shards":2, //主节点 "number_of_replicas":2 //正本节点 }}
整个集群中存在P0和P1两个主分片, P0对应的两个R0正本分片, P1对应的是两个R1正本分片。
2.3 新建索引解决流程
- 写入的申请会进入主节点, 如果是NODE2正本接管到写申请, 会将它转发至主节点。
- 主节点接管到申请后, 依据documentId做取模运算(内部没有传递documentId,则会采纳外部自增ID),
如果取模后果为P0,则会将写申请转发至NODE3解决。
- NODE3节点写申请解决实现之后, 采纳异步形式, 将数据同步至NODE1和NODE2节点。
2.4 读取索引解决流程
- 读取的申请进入MASTER节点, 会依据取模后果, 将申请转发至不同的节点。
- 如果取模后果为R0,外部还会有负载平衡解决机制,如果上一次的读取申请是在NODE1的R0, 那么以后申请会转发至NODE2的R0, 保障每个节点都可能平衡的解决申请数据。
- 读取的申请如果是间接落至正本节点, 正本节点会做判断, 若有数据则返回,没有的话会转发至其余节点解决。
3. ElasticSearch集群部署布局
筹备一台虚拟机:
10.10.20.28: Node-1 (节点一), 端口:9200, 9300
10.10.20.28: Node-2 (节点二),端口:9201, 9301
10.10.20.28: Node-3 (节点三),端口:9202, 9302
4. ElasticSearch集群配置
解压安装包:
cd /usr/local/clustertar -xvf elasticsearch-7.10.2-linux-x86_64.tar.gz
将安装包解压至/usr/local/cluster目录。
批改集群配置文件:
vi /usr/local/cluster/elasticsearch-7.10.2-node1/config/elasticsearch.yml
10.10.20.28, 第一台节点配置内容:
# 集群名称cluster.name: my-application#节点名称node.name: node-1# 绑定IP地址network.host: 10.10.20.28# 指定服务拜访端口http.port: 9200# 指定API端户端调用端口transport.tcp.port: 9300#集群通讯地址discovery.seed_hosts: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]#集群初始化可能参选的节点信息cluster.initial_master_nodes: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]#开启跨域拜访反对,默认为falsehttp.cors.enabled: true##跨域拜访容许的域名, 容许所有域名http.cors.allow-origin: "*"
批改目录权限:
chown -R elsearch:elsearch /usr/local/cluster/elasticsearch-7.10.2-node1
复制ElasticSearch装置目录:
复制其余两个节点:
cd /usr/local/clustercp -r elasticsearch-7.10.2-node1 elasticsearch-7.10.2-node2cp -r elasticsearch-7.10.2-node1 elasticsearch-7.10.2-node3
批改其余节点的配置:
10.10.20.28第二台节点配置内容:
# 集群名称cluster.name: my-application#节点名称node.name: node-2# 绑定IP地址network.host: 10.10.20.28# 指定服务拜访端口http.port: 9201# 指定API端户端调用端口transport.tcp.port: 9301#集群通讯地址discovery.seed_hosts: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]#集群初始化可能参选的节点信息cluster.initial_master_nodes: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]#开启跨域拜访反对,默认为falsehttp.cors.enabled: true##跨域拜访容许的域名, 容许所有域名http.cors.allow-origin: "*"
10.10.20.28第三台节点配置内容:
# 集群名称cluster.name: my-application#节点名称node.name: node-3# 绑定IP地址network.host: 10.10.20.28# 指定服务拜访端口http.port: 9202# 指定API端户端调用端口transport.tcp.port: 9302#集群通讯地址discovery.seed_hosts: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]#集群初始化可能参选的节点信息cluster.initial_master_nodes: ["10.10.20.28:9300", "10.10.20.28:9301","10.10.20.28:9302"]#开启跨域拜访反对,默认为falsehttp.cors.enabled: true##跨域拜访容许的域名, 容许所有域名http.cors.allow-origin: "*"
启动集群节点
先切换elsearch用户, 在三台节点顺次启动服务:
su elsearch/usr/local/cluster/elasticsearch-7.10.2-node1/bin/elasticsearch -d/usr/local/cluster/elasticsearch-7.10.2-node2/bin/elasticsearch -d/usr/local/cluster/elasticsearch-7.10.2-node3/bin/elasticsearch -d
留神: 如果启动呈现谬误, 将各节点的data目录清空, 再重启服务。
- 集群状态查看
集群装置与启动胜利之后, 执行申请: http://10.10.20.28:9200/_cat/nodes?pretty
能够看到三个节点信息,三个节点会自行选举出主节点(ES的是基于Bully选举算法做的改良实现):
5. ElasticSearch集群分片测试
批改kibana的配置文件,指向创立的集群节点:
elasticsearch.hosts: ["http://10.10.20.28:9200","http://10.10.20.28:9201","http://10.10.20.28:9202"]
重启kibana服务, 进入控制台:
http://10.10.20.28:5601/app/home#/
再次创立索引(正本数量范畴内):
PUT /orders{ "settings":{ "index":{ "number_of_shards": 2, "number_of_replicas": 2 } }}
能够看到, 这次后果是失常:
集群并非能够随便减少正本数量, 创立索引(超出正本数量范畴):
PUT /orders{ "settings":{ "index":{ "number_of_shards": 2, "number_of_replicas": 5 } }}
能够看到呈现了yellow正告谬误:
本文由mirson创作分享, 感激大家的反对, 心愿对大家有所播种!
入群申请,请加WX号:woodblock99