Elasticsearch7.17 四 : ElasticSearch集群架构

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

查看启动时候publish的地址是否是 配置文件上的地址，如果是其他地址，需要通过ifconfig把其他网关禁止。
验证集群
访问：http://192.168.10.111:9200/_cat/nodes

到此集群搭建完毕

安装Cerebro客户端

Cerebro介绍
Cerebro 可以查看分片分配和通过图形界面执行常见的索引操作。 完全开源，并且它允许添加用户，密码或 LDAP 身份验证问网络界面。
Cerebro 基于 Scala 的Play 框架编写，用于后端 REST 和 Elasticsearch 通信。 它使用通过 AngularJS 编写的单页应用程序（SPA）前端。
项目网址：https://github.com/lmenezes/cerebro
下载地址：https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip
运行 cerebro

cerebro-0.9.4/bin/cerebro

#后台启动
nohup bin/cerebro > cerebro.log &

访问：http://192.168.10.111:9000

输入ES集群节点：http://192.168.65.192:9200，建立连接：

安装kibana

修改kibana配置 vim config/kibana.yml

server.port: 5601
server.host: "192.168.10.111" 
elasticsearch.hosts: ["http://192.168.10.111:9200","http://192.168.10.112:9200","http://192.168.10.114: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——任何节点都可以加入，开发环境中用于诊断目的

生成节点证书

# 为集群创建一个证书颁发机构
bin/elasticsearch-certutil ca
# 为集群中的每个节点生成证书和私钥
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
# 移动到config目录下
mv *.p12 config/

将如上命令生成的两个证书文件拷贝到另外两个节点作为通信依据。
配置节点间通信
三个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.10.111: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.10.111: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和内存开销的问题
  增加数据节点：解决存储的容量的问题
  为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点