Elasticsearch7.17 四 : ElasticSearch集群架构

文章目录

  • ElasticSearch集群架构
    • 核心概念
      • 节点
      • 分片(Primary Shard & Replica Shard)
      • 集群状态和分片设定
    • 集群搭建
    • 安装Cerebro客户端
    • 安装kibana
    • ES安全认证
      • 集群内部安全通信
      • 开启并配置X-Pack的认证
    • 生产环境常见集群部署方式
    • 如何对集群的容量进行规划

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
Elasticsearch7.17 四 : ElasticSearch集群架构_第1张图片
到此集群搭建完毕

安装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
Elasticsearch7.17 四 : ElasticSearch集群架构_第2张图片
输入ES集群节点:http://192.168.65.192:9200,建立连接:
Elasticsearch7.17 四 : ElasticSearch集群架构_第3张图片

安装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
Elasticsearch7.17 四 : ElasticSearch集群架构_第4张图片
浏览器访问http://192.168.10.111:9200/需要输入用户名密码
Elasticsearch7.17 四 : ElasticSearch集群架构_第5张图片
为内置账号添加密码
ES中内置了几个管理其他集成组件的账号即:apm_system, beats_system, elastic, kibana, logstash_system, remote_monitoring_user,使用之前,首先需要添加一下密码。
bin/elasticsearch-setup-passwords interactive
interactive:给用户手动设置密码。
auto:自动生成密码。
Elasticsearch7.17 四 : ElasticSearch集群架构_第6张图片
所有账号密码都是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"
    }
  }
]

Elasticsearch7.17 四 : ElasticSearch集群架构_第7张图片

启动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节点,增加查询的性能

Elasticsearch7.17 四 : ElasticSearch集群架构_第8张图片
读写分离架构
Elasticsearch7.17 四 : ElasticSearch集群架构_第9张图片

如何对集群的容量进行规划

一个集群总共需要多少个节点?一个索引需要设置几个分片?规划上需要保持一定的余量,当负载出现波动,节点出现丢失时,还能正常运行。
做容量规划时,一些需要考虑的因素:

  • 机器的软硬件配置
  • 单条文档的大小│文档的总数据量│索引的总数据量((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和内存开销的问题
    增加数据节点:解决存储的容量的问题
    为避免分片分布不均的问题,要提前监控磁盘空间,提前清理数据或增加节点

你可能感兴趣的:(搜索服务,elasticsearch,架构,java)