ElasticSearch集群架构
分布式系统的可用性与扩展性：
高可用性
服务可用性-允许有节点停止服务
数据可用性-部分节点丢失，不会丢失数据
可扩展性
请求量提升/数据的不断增长(将数据分布到所有节点上)
ES集群架构的优势：
提高系统的可用性，部分节点停止服务，整个集群的服务不受影响
存储的水平扩容
核心概念
节点
集群
一个集群可以有一个或者多个节点
不同的集群通过不同的名字来区分，默认名字“elasticsearch“
通过配置文件修改，或者在命令行中 -E cluster.name=es-cluster进行设定’
节点
节点是一个Elasticsearch的实例；本质上就是一个JAVA进程
一台机器上可以运行多个Elasticsearch进程，但是生产环境一般建议一台机器上只运行一个Elasticsearch实例
每一个节点都有名字，通过配置文件配置，或者启动时候 -E node.name=node1指定
每一个节点在启动之后，会分配一个UID，保存在data目录下
节点类型
- Master Node：主节点
处理创建，删除索引等请求，负责索引的创建与删除
决定分片被分配到哪个节点
维护并且更新Cluster State - Master eligible nodes：可以参与选举的合格节点
每个节点启动后，默认就是一个Master eligible节点，可以设置 node.master: false禁止。
Master-eligible节点可以参加选主流程，成为Master节点。
当第一个节点启动时候，它会将自己选举成Master节点 - Data Node：数据节点
可以保存数据的节点，叫做Data Node，负责保存分片数据。在数据扩展上起到了至关重要的作用。
通过增加数据节点可以解决数据水平扩展和解决数据单点问题 - Coordinating Node：协调节点
负责接受Client的请求， 将请求分发到合适的节点，最终把结果汇集到一起。
每个节点默认都起到了Coordinating Node的职责 - 其他节点
Hot & Warm Node
不同硬件配置 的Data Node,用来实现Hot & Warm架构，降低集群部署的成本
Ingest Node
数据前置处理转换节点，支持pipeline管道设置，可以使用ingest对数据进行过滤、转换等操作
Machine Learning Node
负责跑机器学习的Job，用来做异常检测
Tribe Node
Tribe Node连接到不同的Elasticsearch集群，并且支持将这些集群当成一个单独的集群处理
分片(Primary Shard & Replica Shard)
主分片（Primary Shard)
用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点之上
一个分片是一个运行的Lucene的实例
主分片数在索引创建时指定，后续不允许修改
副本分片（Replica Shard）
用以解决数据高可用的问题。 副本分片是主分片的拷贝
副本分片数，可以动态调整
增加副本数，还可以在一定程度上提高服务的可用性(读取的吞吐)
指定索引的主分片和副本分片数
PUT /blogs
{
"settings": {
"number_of_shards": 3, #主分片
"number_of_replicas": 1 #副分片
}
}
集群状态和分片设定
分片的设定
对于生产环境中分片的设定，需要提前做好容量规划。
分片数设置过小，导致后续无法增加节点实现水平扩展；单个分片的数据量太大，导致数据重新分配耗时。
分片数设置过大，影响搜索结果的相关性打分，影响统计结果的准确性；单个节点上过多的分片，会导致资源浪费，同时也会影响性能
7.0 开始，默认主分片设置成1，解决了over-sharding（分片过度）的问题
集群status
Green: 主分片与副本都正常分配
Yellow: 主分片全部正常分配，有副本分片未能正常分配
Red: 有主分片未能分配。例如，当服务器的磁盘容量超过85%时,去创建了一个新的索引
CAT API查看集群信息
GET /_cat/nodes?v #查看节点信息
GET /_cat/health?v #查看集群当前状态：红、黄、绿
GET /_cat/shards?v #查看各shard的详细情况
GET /_cat/shards/{index}?v #查看指定分片的详细情况
GET /_cat/master?v #查看master节点信息
GET /_cat/indices?v #查看集群中所有index的详细信息
GET /_cat/indices/{index}?v #查看集群中指定index的详细信息
集群搭建
系统环境
操作系统: CentOS7，准备用户es。关闭防火墙
elasticsearch：elasticsearch-7.17.3
需要删除es下的data目录里面的节点信息，否则会加载以前的节点信息导致集群搭建失败
修改elasticsearch.yml
#指定集群名称3个节点必须一致
cluster.name: elasticsearch
#指定节点名称，每个节点名字唯一
node.name: node-1
#是否有资格为master节点，默认为true
node.master: true
#是否为data节点，默认为true
node.data: true
#绑定ip,开启远程访问,可以配置0.0.0.0
network.host: 0.0.0.0
#指定web端口
http.port: 9200
#指定tcp端口
transport.tcp.port: 9300
#用于节点发现
discovery.seed_hosts: ["192.168.10.111","192.168.10.112","192.168.10.114"]
#7.0新引入的配置项,初始仲裁，仅在整个集群首次启动时才需要初始仲裁。
#该选项配置为node.name的值，指定可以初始化集群主节点的名称
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
#解决跨域问题
http.cors.enabled: true
http.cors.allow-origin: "*"
每个节点的配置文件，只要把node.name 修改即可，其他配置相同。
切换为es用户启动es。
（其中：1、安装jdk请参参考 https://blog.csdn.net/huaxinzhang/article/details/130702554
2、各服务器安装ElasticSearch https://blog.csdn.net/huaxinzhang/article/details/130578370）
查看启动时候publish的地址是否是 配置文件上的地址，如果是其他地址，需要通过ifconfig把其他网关禁止。
验证集群
192.168.213.138:9200/_cat/nodes
到此集群搭建完毕！
集群搭建遇到的问题总结
本地电脑Windows10配置：
虚拟机配置：
1、启动es报utf-8错误
解决：把elasticsearch.yml配置文件中的中文注释
2、启动es报内核大小不足
解决：把jvm.options配置文件配置设置成
-Xms2g
-Xmx2g
原来是
-Xms4g
-Xmx4g
安装Cerebro客户端
Cerebro介绍
Cerebro 可以查看分片分配和通过图形界面执行常见的索引操作。 完全开源，并且它允许添加用户，密码或 LDAP 身份验证问网络界面。
Cerebro 基于 Scala 的Play 框架编写，用于后端 REST 和 Elasticsearch 通信。 它使用通过 AngularJS 编写的单页应用程序（SPA）前端。
1、下载
wget https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.tgz
2、解压
tar xf cerebro-0.9.4.tgz
3、启动服务
cerebro-0.9.4/bin/cerebro
#后台启动
nohup bin/cerebro > cerebro.log &
访问：http://192.168.213.138:9000
输入ES集群节点：http://192.168.213.138:9200，建立连接：
ps: es集群都要开启，不然连接不上
安装kibana
修改kibana配置 vim config/kibana.yml
server.port: 5601
server.host: "192.168.213.138"
elasticsearch.hosts: ["http://192.168.213.138:9200","http://192.168.213.139:9200","http://192.168.213.140:9200"]
i18n.locale: "zh-CN"
启动 访问kibana
ES安全认证
ES敏感信息泄露的原因
Elasticsearch在默认安装后，不提供任何形式的安全防护。不合理的配置导致公网可以访问ES集群。比如在elasticsearch.yml文件中,server.host配置为0.0.0.0
免费的方案
- 设置nginx反向代理
- 安装免费的Security插件
Search Guard ： https://search-guard.com/
readonlyrest： https://readonlyrest.com/ - X-Pack的Basic版
从ES 6.8开始，Security纳入x-pack的Basic版本中，免费使用一些基本的功能
集群内部安全通信
ElasticSearch集群内部的数据是通过9300进行传输的，如果不对数据加密，可能会造成数据被抓包，敏感信息泄露。
解决方案： 为节点创建证书
TLS 协议要求Trusted Certificate Authority (CA）签发x.509的证书。证书认证的不同级别：
Certificate ——节点加入需要使用相同CA签发的证书
Full Verification——节点加入集群需要相同CA签发的证书，还需要验证Host name 或IP地址
No Verification——任何节点都可以加入，开发环境中用于诊断目的
生成节点证书
命令 elasticsearch-certutil 简化了生成证书的过程，它负责生成CA并与CA签署证书。
a、创建证书颁发机构CA
随便进入一个节点的bin 目录下执行elasticsearch-certutil 命令即可，如下
# 该命令输出单个文件，默认名称为elastic-stack-ca.p12。此文件是PKCS＃12密钥库
# 其中包含CA的公共证书和用于对每个节点的证书签名的私钥。
bin/elasticsearch-certutil ca
执行这个命令之后：
- 会让你输入生成elastic-stack-ca.p12文件放在哪。（直接回车，放在当前目录）
- 回车之后让你输入密码，该密码是让你保护文件和密钥的。如果你以后还要加集群的话，要记得输入的密码。
b、生成证书和私钥
# 此命令生成证书凭证，输出的文件是单个PKCS＃12密钥库，其中包括节点证书，节点密钥和CA证书。
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
执行命令之后需要你操作3次：
- 第一次，输入上面生成CA的密码，没有设置直接回车
- 第二次，生成的文件路径，直接回车
- 第三次，生成这次证书与私钥文件的密码，建议和上面生成CA一致（怕忘记密码，也可以直接回车）
如下图需要输入密码的地方：
命令执行完之后会生成两个 .p12 文件，这个就是各节点通信的凭证
c、 移动到config目录下
mv *.p12 config/
d、将如上命令生成的两个证书文件拷贝到另外两个节点作为通信依据。
配置节点间通信
三个ES节点增加如下配置：
## elasticsearch.yml 配置
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.client_authentication: required
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12
开启并配置X-Pack的认证
修改elasticsearch.yml配置文件，开启xpack认证机制xpack.security.enabled: true # 开启xpack认证机制
测试：
使用Curl访问ES，返回401错误curl localhost:9200/_cat/nodes
浏览器访问http://192.168.213.138:9200/需要输入用户名密码
为内置账号添加密码
ES中内置了几个管理其他集成组件的账号即：apm_system, beats_system, elastic, kibana, logstash_system, remote_monitoring_user，使用之前，首先需要添加一下密码。
需要启动集群服务才能设置密码
bin/elasticsearch-setup-passwords interactive
为每个节点都设置密码
interactive：给用户手动设置密码。
auto：自动生成密码。
所有账号密码都是123456，for后面的就是对应的账号。比如上图访问http://192.168.213.138:9200 需要登录的账号密码就是 elastic ; 123456
配置kibana账号密码
开启了安全认证之后，kibana连接es以及访问es都需要认证。修改kibana.yml
elasticsearch.username: "kibana_system"
elasticsearch.password: "123456"
注意上面的用户名密码是kibana 访问 es集群的认证，界面登录kibana的账号密码
启动kibana服务 nohup bin/kibana &
登录的账号密码是 elastic 123456
配置cerebro账号密码
修改配置文件
vim conf/application.conf
hosts = [
{
host = "http://192.168.10.111:9200"
name = "es-cluster"
auth = {
username = "elastic"
password = "123456"
}
}
]
启动cerebro服务 nohup bin/cerebro > cerebro.log &
生产环境常见集群部署方式
在开发环境中，一个节点可承担多种角色。
在生产环境中：
根据数据量，写入和查询的吞吐量，选择合适的部署方式。建议设置单一角色的节点
这种单一角色职责分离的好处：
- 单一 master eligible nodes: 负责集群状态(cluster state)的管理，使用低配置的CPU,RAM和磁盘
- 单一 data nodes: 负责数据存储及处理客户端请求，使用高配置的CPU,RAM和磁盘
- 单一ingest nodes: 负责数据处理，使用高配置CPU; 中等配置的RAM; 低配置的磁盘
- 单一Coordinating Only Nodes(Client Node)，使用高配置CPU; 高配置的RAM; 低配置的磁盘
生产环境中，建议为一些大的集群配置Coordinating Only Nodes。扮演Load Balancers，降低Master和 Data Nodes的负载；负责搜索结果的Gather/Reduce；有时候无法预知客户端会发送怎么样的请求。比如大量占用内存的操作，一个深度聚合可能会引发OOM。
增加节点水平扩展场景
- 当磁盘容量无法满足需求时，可以增加数据节点；
- 磁盘读写压力大时，增加数据节点
- 当系统中有大量的复杂查询及聚合时候，增加Coordinating节点，增加查询的性能
读写分离架构
如何对集群的容量进行规划
一个集群总共需要多少个节点?一个索引需要设置几个分片？规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。
做容量规划时，一些需要考虑的因素：
- 机器的软硬件配置
- 单条文档的大小│文档的总数据量│索引的总数据量（(Time base数据保留的时间)|副本分片数
- 文档是如何写入的(Bulk的大小)
- 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)
评估业务的性能需求：
- 数据吞吐及性能需求
数据写入的吞吐量，每秒要求写入多少数据?
查询的吞吐量?
单条查询可接受的最大返回时间? - 了解你的数据
数据的格式和数据的Mapping
实际的查询和聚合长的是什么样的
ES集群常见应用场景：
- 搜索: 固定大小的数据集
搜索的数据集增长相对比较缓慢 - 日志: 基于时间序列的数据
使用ES存放日志与性能指标。数据每天不断写入，增长速度较快
结合Warm Node 做数据的老化处理
硬件配置：
- 选择合理的硬件，数据节点尽可能使用SSD
- 搜索等性能要求高的场景，建议SSD
按照1∶10的比例配置内存和硬盘 - 日志类和查询并发低的场景，可以考虑使用机械硬盘存储
按照1:50的比例配置内存和硬盘 - 单节点数据建议控制在2TB以内，最大不建议超过5TB
- JVM配置机器内存的一半，JVM内存配置不建议超过32G
- 不建议在一台服务器上运行多个节点
内存大小要根据Node 需要存储的数据来进行估算
- 搜索类的比例建议: 1:16
- 日志类: 1:48——1:96之间
假设总数据量1T，设置一个副本就是2T总数据量
- 如果搜索类的项目，每个节点31*16 = 496 G，加上预留空间。所以每个节点最多400G数据，至少需要5个数据节点
- 如果是日志类项目，每个节点31*50= 1550 GB，2个数据节点即可
部署方式：
- 按需选择合理的部署方式
- 如果需要考虑可靠性高可用，建议部署3台单一的Master节点
- 如果有复杂的查询和聚合，建议设置Coordinating节点
- 集群扩容：
增加Coordinating / Ingest Node：解决CPU和内存开销的问题
增加数据节点：解决存储的容量的问题
为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点
122
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
