docker进行ElasticSearch集群部署

快乐敲代码

已于 2023-02-08 10:11:32 修改

阅读量2.2k

点赞数 1

分类专栏：应用部署文章标签： elasticsearch docker

于 2022-06-13 16:37:21 首次发布

本文链接：https://blog.csdn.net/qiaodaima0/article/details/125262686

版权

应用部署专栏收录该内容

10 篇文章 0 订阅

订阅专栏

环境：

（1）Centos7
（2）JDK1.8
（3）docker
（4）ElasticSearch7.6

建议：

（1）服务器至少3台，否则没必要集群部署
（2）java后台推荐直接连接客户端节点

概念：

node节点：master、data、client

默认情况下，ES集群节点都是混合节点，即在elasticsearch.yml中默认node.master: true和node.data: true

master节点数量至少保证3个，不然主节点宕机时，可能无法选举出master节点
shard切片数量：与data数据节点数量成正比，但不宜超过data节点数量，索引一旦创建，shard值不可改变。

shard切片——也叫主切片，将索引数据分切成多个部分，防止单个节点服务不可用后，不至于所有数据都不可用，数据切分后，查询效率也会有所提高，类似于数据库的水平分表，把单表大量数据均分成多个分表中。
replicas副本——也是切片，只不过叫做副本切片，正常情况下承担读的任务分配，但写操作不会直接在副本上进行，会在主切片上进行，然后副本复制主切片上的数据，只有当主切片故障了，副本会升级成主切片，此时会承担读写任务。

replicas副本数量：其值越大搜索效率越高，但写入性能越低（一条数据写入操作需要做（1+replicas）遍）具体值与集群data节点数量相关，不宜超过【data节点数-1】，副本数量可以通过命令修改。

同一部分的数据的切片和副本不会在同一个节点上。服务器A,B，两个切片一份副本，数据d会被分割成d1和d2，A服务器上有d1和d2（一个主切片，一个副本切片，d1和d2那个是主的就不一定了,随机分配的）,B服务器上也有d1和d2，不会让A服务器同时有两个d1，B服务器拥有两个d2，因为这样有一个服务器挂了，那么数据就不完整了，但是前面的分配一个节点挂了，数据还是完整的。

切片总数=切片*（副本+1）
5个切片，一份副本，实际总共切片数量为5*（1+1）=10

master - 主节点：

master节点数量至少保证3个
主要功能：维护元数据，管理集群节点状态；不负责数据写入和查询。
配置要点：内存可以相对小一些，但是机器一定要稳定，最好是独占的机器。
elasticsearch.yml配置如下 :
node.master: true
node.data: false

data - 数据节点：

主要功能：负责数据的写入与查询，压力大。
配置要点：大内存，最好是独占的机器。
elasticsearch.yml 配置如下:
node.master: false
node.data: true

client - 客户端节点：

主要功能：负责任务分发和结果汇聚，分担数据节点压力。
配置要点：大内存，最好是独占的机器
elasticsearch.yml配置如下 :
node.master: false

mixed- 混合节点：

既是主节点，又是数据节点，服务器数量不充足的情况下，也只能考虑这种节点配置
elasticsearch.yml 配置如下:
node.master: true
node.data: true

部署：

服务器IP：
192.168.8.49
192.168.8.50
192.168.8.51

1、配置文件

cd /home/docker
mkdir es
cd es/
touch elasticsearch.yml
vi elasticsearch.yml

手动新建elasticsearch.yml配置文件，方便docker进行文件

#集群名称 所有节点名称一致
cluster.name: es-clusters

#当前该节点的名称，每个节点不能重复es-node-1,es-node-2,es-node-3
node.name: es-node-1

#当前该节点是不是有资格竞选主节点
node.master: true

#当前该节点是否存储数据
node.data: true

#设置为公开访问
network.host: 0.0.0.0

#设置其它节点和该节点交互的本机器的ip地址,三台各自为
network.publish_host: 192.168.8.49

# 设置映射端口
http.port: 9200

# 内部节点之间沟通端口
transport.tcp.port: 9300

#支持跨域访问
http.cors.enabled: true
http.cors.allow-origin: "*"

#配置集群的主机地址
discovery.seed_hosts: ["192.168.8.49", "192.168.8.50", "192.168.8.51"]
#初始主节点，使用一组初始的符合主条件的节点引导集群
cluster.initial_master_nodes: ["es-node-1", "es-node-2","es-node-3"]
#节点等待响应的时间，默认值是30秒,增加这个值，从一定程度上会减少误判导致脑裂
discovery.zen.ping_timeout: 30s

#配置集群最少主节点数目，通常为 (可成为主节点的主机数目 / 2) + 1
discovery.zen.minimum_master_nodes: 2
#配置集群最少正常工作节点数
#gateway.recover_after_nodes: 2

#禁用交换内存，提升效率
bootstrap.memory_lock：true

2、服务器优化/配置

root用户修改/etc/security/limits.conf，添加如下，提高进程及资源使用限制上线

* soft nofile 65536
* hard nofile 65536
* soft nproc 32000
* hard nproc 32000
* hard memlock unlimited
* soft memlock unlimited

执行命令使其生效

source /etc/profile

修改/etc/systemd/system.conf，添加如下

DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity

重启服务器，或执行下面两个命令使其配置生效

systemctl daemon-reload
systemctl daemon-reexec

修改虚拟内存最大映射数
系统虚拟内存默认最大映射数为65530，无法满足ES系统要求，需要调整为262144以上。
sudo vi /etc/sysctl.conf

#添加参数
vm.max_map_count = 262144

重新加载/etc/sysctl.conf配置

sysctl -p

3、拉取镜像

 #elasticSearch镜像
docker pull elasticsearch:7.6.2
	
#elasticSearch-head镜像	
docker pull mobz/elasticsearch-head:5-alpine

4、启动ElasticSearch

注意：我们启动参数设置的-Xms2g -Xmx2g，根据服务器内存实际情况调整。
● Xms 为jvm启动是分配的最大内存
● Xmx 为jvm运行过程分配的最大内存
● Xss 为jvm启动的每个线程分配的内存大小，jdk1.5+默认1M

docker run -d -p 9200:9200 -p 9300:9300 \
-e "ES_JAVA_OPTS=-Xms2g -Xmx2g" \
-v /home/docker/es/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \
--name elasticsearch  \
--restart=always \
elasticsearch:7.6.2

如启动报错：
ERROR: bootstrap checks failed memory locking requested for elasticsearch process but memory is not locked
则重启服务器

5、启动ElasticSearch-head

docker run -d -p 9001:9100 \
--name elasticsearch-head \
--restart=always \
mobz/elasticsearch-head:5-alpine

ElasticSearch-Head请求Content-Type问题
进入elasticsearch-head容器内部，修改vendor.js文件，需要安装vi

1、进入容器
docker exec -it 容器id /bin/sh
2、修改vendor.js
vim /usr/src/app/_site/vendor.js
3、6886行 /contentType: "application/x-www-form-urlencoded 
   改成 contentType: "application/json;charset=UTF-8" 
  7573行 var inspectData = s.contentType === "application/x-www-form-urlencoded" &&` 
    改成 var inspectData = s.contentType === "application/json;charset=UTF-8" &&
4、退出容器，重启容器

管理页面地址：http://127.0.0.1:9001/
创建测试索引并加入一些数据
在这里插入图片描述

这个就表示三个节点都成功，且自动选择了es-node-3为主节点，数据框加粗的0/1为主分片，分布在es-node-1和es-node-3，
两个副本分布在es-node-1、es-node-2，为了保证数据可靠性，同一份数据的主分片和副本不会同时在一个节点上。

从颜色上可以直观的获取集群的健康状态
绿色：最健康的状态，代表所有的主分片和副本分片都可用。
黄色：分配了所有主分片，但至少缺少一个副本，没有数据丢失，因此搜索结果仍将完整。
红色：部分主分片不可用，此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好。

在这里插入图片描述

思考：

（1）为什么master候选节点最少三个？

如果你只有两台节点，那么是无法使用官方的这个配置公式的，（这也就是为什么我们之前建议最少要三台机器能成为主节点），两台的话会出现各种各样的问题，为什么呢？
思考一下假设集群中共有2个节点，discovery.zen.minimum_master_nodes分别设置成2和1会怎么样？
如果我们有2个节点，都可以是master候选节点，那么quorum是2 / 2 + 1 = 2。此时就有问题了，因为如果一个node挂掉了，这么这时节点发生变更，那么只剩下一个master候选节点，是无法满足quorum数量的，也就无法选举出新的master，集群就彻底挂掉了。此时就只能将这个参数设置为1，但是这就无法阻止脑裂的发生了。