es 集群简单介绍及搭建

这篇具有很好参考价值的文章主要介绍了es 集群简单介绍及搭建。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

es 集群概述

es 集群基本概念

  • Cluster:代表一个集群,集群中有多个节点,其中有一个为主节点,这个主节点是可以通过选举产生的,主从节点是对于集群内部来说的。es 的一个概念就是去中心化,字面上理解就是无中心节点,这是对于集群外部来说的,因为从外部来看 es 集群,在逻辑上是个整体,你与任何一个节点的通信和与整个 es 集群通信是等价的。
  • Shards:代表索引分片,es 可以把一个完整的索引分成多个分片,这样的好处是可以把一个大的索引拆分成多个,分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定,并且索引创建后不能更改。
  • Replicas:代表索引副本,es 可以设置多个索引的副本,副本的作用一是提高系统的容错性,当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高 es 的查询效率,es 会自动对搜索请求进行负载均衡。
  • Recovery:代表数据恢复或叫数据重新分布,es 在有节点加入或退出时会根据机器的负载对索引分片进行重新分配,挂掉的节点重新启动时也会进行数据恢复。

es 为什么要实现集群

在单台 es 服务器节点上,随着业务量的发展索引文件慢慢增多,会影响到效率和内存存储问题等。

我们可以采用 es 集群,将单个索引的分片到多个不同分布式物理机器上存储,从而可以实现高可用、容错性等。

es 集群中索引可能由多个分片构成,并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片,我们可以处理不能在一个单一的服务器上面运行的大型索引,简单的说就是索引的大小过大,导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本,通过将副本分配到多个服务器,可以提高查询的负载能力。

es 如何解决高并发问题

es 是一个分布式全文检索框架,隐藏了复杂的处理机制,内部使用 分片机制、集群发现、分片负载均衡请求路由。

shards 分片:代表索引分片,es 可以把一个完整的索引分成多个分片,这样的好处是可以把一个大的索引拆分成多个,分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定,并且索引创建后不能更改。

replicas 分片:代表索引副本,es 可以设置多个索引的副本,副本的作用一是提高系统的容错性,当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高 es 的查询效率,es 会自动对搜索请求进行负载均衡。

es 集群规划

搭建一个集群我们需要考虑如下几个问题:

  1. 我们需要多大规模的集群?
  2. 集群中的节点角色如何分配?
  3. 如何避免脑裂问题?
  4. 索引应该设置多少个分片?
  5. 分片应该设置几个副本?

下面我们就来分析和回答这几个问题:

我们需要多大规模的集群

需要从以下两个方面考虑

  1. 当前的数据量有多大?数据增长情况如何?

  2. 你的机器配置如何?cpu、多大内存、多大硬盘容量?

推算的依据

ES JVM heap 最大可以设置32G 。

30G heap 大概能处理的数据量 10 T。如果内存很大如128G,可在一台机器上运行多个 es 节点实例。

备注:集群规划满足当前数据规模 + 适量增长规模即可,后续可按需扩展。

两类应用场景

  1. 用于构建业务搜索功能模块,且多是垂直领域的搜索。数据量级几千万到数十亿级别。一般2-4台机器的规模。

  2. 用于大规模数据的实时 OLAP(联机处理分析),经典的如 ELK Stack,数据规模可能达到千亿或更多。几十到上百节点的规模。

集群中的节点角色如何分配

节点角色

  1. Master:

node.master::true 节点可以作为主节点

  1. DataNode

node.data:true 默认是数据节点。

Coordinate node 协调节点

如果仅担任协调节点,将上两个配置设为false。

说明

一个节点可以充当一个或多个角色,默认三个角色都有

协调节点:一个节点只作为接收请求、转发请求到其他节点、汇总各个节点返回数据等功能的节点。就叫协调节点

如何分配

  1. 小规模集群,不需严格区分。

  2. 中大规模集群(十个以上节点),应考虑单独的角色充当。特别并发查询量大,查询的合并量大,可以增加独立的协调节点。角色分开的好处是分工分开,不互影响。如不会因协调角色负载过高而影响数据节点的能力。

如何避免脑裂问题

脑裂问题

一个集群中只有一个 A 主节点,A 主节点因为需要处理的东西太多或者网络过于繁忙,从而导致其他从节点 ping 不通 A 主节点,这样其他从节点就会认为 A 主节点不可用了,就会重新选出一个新的主节点 B。过了一会 A 主节点恢复正常了,这样就出现了两个主节点,导致一部分数据来源于 A 主节点,另外一部分数据来源于 B 主节点,出现数据不一致问题,这就是脑裂问题。

尽量避免脑裂,需要添加最小数量的主节点配置

discovery.zen.minimum_master_nodes:(有 master 资格节点数/2) + 1

这个参数控制的是,选举主节点时需要看到最少多少个具有 master 资格的活节点,才能进行选举。官方的推荐值是(N/2)+ 1,其中 N 是具有master 资格的节点的数量。

常用做法(中大规模集群)

  1. Master 和 dataNode 角色分开,配置奇数个 master,如3
  2. 单播发现机制,配置 master 资格节点:discovery.zen.ping.multicast.enabled: false —— 关闭多播发现机制,默认是关闭的

discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"] —— 配置单播发现的主节点 ip 地址,其他从节点要加入进来,就得去询问单播发现机制里面配置的主节点我要加入到集群里面了,主节点同意以后才能加入,然后主节点再通知集群中的其他节点有新节点加入

  1. 配置选举发现数,及延长 ping master 的等待时长

discovery.zen.ping_timeout: 30(默认值是3秒)——其他节点 ping 主节点多久时间没有响应就认为主节点不可用了

discovery.zen.minimum_master_nodes: 2 —— 选举主节点时需要看到最少多少个具有 master 资格的活节点,才能进行选举

索引应该设置多少个分片

说明:分片数指定后不可变,除非重索引。

思考:

分片对应的存储实体是什么?存储的实体是索引

分片是不是越多越好?不是

分片多有什么影响?分片多浪费存储空间、占用资源、影响性能

分片过多的影响

每个分片本质上就是一个 Lucene 索引,因此会消耗相应的文件句柄,内存和 CPU 资源。

每个搜索请求会调度到索引的每个分片中,如果分片分散在不同的节点倒是问题不太,但当分片开始竞争相同的硬件资源时,性能便会逐步下降。

es 使用词频统计来计算相关性,当然这些统计也会分配到各个分片上,如果在大量分片上只维护了很少的数据,则将导致最终的文档相关性较差。

分片设置的可参考原则

es 推荐的最大 JVM 堆空间是30~32G,所以把你的分片最大容量限制为30GB,然后再对分片数量做合理估算,例如,你认为你的数据能达到200GB,推荐你最多分配7到8个分片。

在开始阶段,一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片,例如,如果你有3个节点,则推荐你创建的分片数最多不超过9(3x3)个。当性能下降时,增加节点,es 会平衡分片的放置。

对于基于日期的索引需求,并且对索引数据的搜索场景非常少,也许这些索引量将达到成百上千,但每个索引的数据量只有1GB甚至更小,对于这种类似场景,建议只需要为索引分配1个分片。如日志管理就是一个日期的索引需求,日期索引会很多,但每个索引存放的日志数据量就很少。

分片应该设置几个副本

说明:副本数是可以随时调整的!

思考:

副本的用途是什么?备份数据保证高可用数据不丢失,高并发的时候参与数据查询

针对它的用途,我们该如何设置它的副本数?一般一个分片有1-2个副本即可保证高可用

集群规模没变的情况下副本过多会有什么影响?副本多浪费存储空间、占用资源、影响性能

副本设置基本原则

为保证高可用,副本数设置为2即可。要求集群至少要有3个节点,来分开存放主分片、副本。如发现并发量大时,查询性能会下降,可增加副本数,来提升并发查询能力。

注意:新增副本时主节点会自动协调,然后拷贝数据到新增的副本节点

集群核心原理分析

  1. 每个索引会被分成多个分片 shards 进行存储,默认创建索引是分配5个分片进行存储。每个分片都会分布式部署在多个不同的节点上进行部署,该分片成为 primary shards。

    注意:索引的主分片 primary shards 定义好后,后面不能做修改。

  2. 为了实现高可用数据的高可用,主分片可以有对应的备分片 replics shards,replic shards 分片承载了负责容错、以及请求的负载均衡。

    注意: 每一个主分片为了实现高可用,都会有自己对应的备分片,主分片对应的备分片不能存放同一台服务器上。主分片 primary shards 可以和其他 replics shards 存放在同一个 node 节点上。

  3. documnet routing(数据路由):当客户端发起创建 document 的时候,es 需要确定这个 document 放在该 index 哪个 shard 上。这个过程就是数据路由。

    路由算法:shard = hash(routing) % number_of_primary_shards

    如果 number_of_primary_shards 在查询的时候取余发生的变化,无法获取到该数据

    注意:索引的主分片数量定义好后,不能被修改

es 集群,elasticsearch学习,elasticsearch

es 集群,elasticsearch学习,elasticsearch

es 集群,elasticsearch学习,elasticsearch

高可用视图分析

下图所示:上面的图,如果节点1与节点2宕机了,es 集群数据就不完整了。

下图,如果节点1与节点2宕机了,es 集群数据还是完整的

es 集群,elasticsearch学习,elasticsearch

集群搭建

  1. 复制三个 es 的文件
  2. 进入 es的 config 目录,修改 elasticsearch.yml 的配置
# ================= Elasticsearch Configuration ===================
# 配置es的集群名称, es会自动发现在同一网段下的es,如果在同一网段下有多个集群,就可以用这个属性来区分不同的集群。
cluster.name: elasticsearch
# 节点名称(要修改)
node.name: node-001
# 指定该节点是否有资格被选举成为node
node.master: true
# 指定该节点是否存储索引数据,默认为true。
node.data: true
# 设置绑定的ip地址还有其它节点和该节点交互的ip地址,本机ip
network.host: 127.0.0.1
# 指定http端口,你使用head、kopf等相关插件使用的端口 (要修改)
http.port: 9200
# 设置节点间交互的tcp端口,默认是9300。 (要修改)
transport.tcp.port: 9300
#设置集群中master节点的初始列表,可以通过这些节点来自动发现新加入集群的节点。
#因为下两台elasticsearch的port端口会设置成9301 和 9302 所以写入两台#elasticsearch地址的完整路径
discovery.zen.ping.unicast.hosts:
["127.0.0.1:9300","127.0.0.1:9301","127.0.0.1:9302"]
#如果要使用head,那么需要解决跨域问题,使head插件可以访问es
http.cors.enabled: true
http.cors.allow-origin: "*"

配置解析

IP 访问限制、默认端口修改9200

这里有两个需要提醒下,第一个就是IP访问限制,第二个就是 es 实例的默认端口号9200。IP 访问限制可以限定具体的 IP 访问服务器,这有一定的安全过滤作用。

# Set the bind address to a specific IP (IPv4 or IPv6):
network.host: 192.168.152.128

如果设置成 0.0.0.0 则是不限制任何 IP 访问。一般在生产的服务器可能会限定几台 IP,通常用于管理使用。

默认的端口9200在一般情况下也有点风险,可以将默认的端口修改成另外一个,这还有一个原因就是怕开发人员误操作,连接上集群。当然,如果你的公司网络隔离做的很好也无所谓。

# Set a custom port for HTTP:
http.port: 9200
transport.tcp.port: 9300

这里的9300是集群内部通讯使用的端口,这个也可以修改掉。因为连接集群的方式有两种,通过扮演集群 node 也是可以进入集群的,所以还是安全起见,修改掉默认的端口。

说明:记得修改安装了 es 的3台虚拟机(三个节点)的相同配置,要不然节点之间无法建立连接工作,也会报错。

集群配置 IP 列表、node、cluster 名称

紧接着修改集群节点 IP 地址,这样可以让集群在规定的几个节点之间工作。es,默认是使用自动发现 IP 机制。就是在当前网段内,只要能被自动感知到的 IP 就能自动加入到集群中。这有好处也有坏处。好处就是自动化了,当你的 es 集群需要云化的时候就会非常方便。但是也会带来一些不稳定的情况,如,master 的选举问题、数据复制问题。

导致 master 选举的因素之一就是集群有节点进入。当数据复制发生的时候也会影响集群,因为要做数据平衡复制和冗余。这里面可以独立 master 集群,剔除 master 集群的数据节点能力。

固定列表的 IP 发现有两种配置方式,一种是互相依赖发现,一种是全量发现。各有优势吧,我是使用的依赖发现来做的。这有个很重要的参考标准,就是你的集群扩展速度有多快。因为这有个问题就是,当全量发现的时候,如果是初始化集群会有很大的问题,就是 master 全局会很长,然后节点之间的启动速度各不一样。所以我采用了靠谱点的依赖发现。

你需要在 192.168.152.128 的 es 中配置成:

# --------------------------------- Discovery ----------------------------------
# Pass an initial list of hosts to perform discovery when new node is
started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
discovery.zen.ping.unicast.hosts: ["192.168.152.129:9300","192.168.152.130:9300" ]

让他去发现129,130的机器,以此内推,完成剩下的129和130机器的配置。

然后你需要配置下集群名称,就是你当前节点所在集群的名称,这有助于你规划你的集群。集群中的所有节点的集群名称必须一样,只有集群名称一样才能组成一个逻辑集群。

# ---------------------------------- Cluster -----------------------------------
# Use a descriptive name for your cluster:
cluster.name: mycluster

配置你当前节点的名称

# ------------------------------------ Node ------------------------------------
# Use a descriptive name for the node:
node.name: node-1

以此类推,完成另外两个节点的配置。cluster.name 的名称必须保持一样。然后分别设置 node.name

说明

这里搭建的是一个简单的集群,没有做集群节点角色的区分,所以3个节点默认的角色有主节点、数据节点、协调节点

选举ES主节点的逻辑

选举的大概逻辑,它会根据分片的数据的前后新鲜程度来作为选举的一个重要逻辑。(日志、数据、时间都会作为集群 master 全局的重要指标)

因为考虑到数据一致性问题,当然是用最新的数据节点作为 master,然后进行新数据的复制和刷新其他 node。文章来源地址https://www.toymoban.com/news/detail-852657.html

到了这里,关于es 集群简单介绍及搭建的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 袁庭新ES系列14节 | 搭建Elasticsearch集群

    单节点的Elasticsearch需要在处理大量数据的时候需要消耗大量内存和CPU资源,数据量大到一定程度就会产生处理瓶颈,甚至会出现宕机。 为了解决单节点ES的处理能力的瓶颈及单节点故障问题,我们考虑使用Elasticsearch集群。接下来袁老师带领大家学习如何搭建Elasticsearch的集群

    2024年04月17日
    浏览(120)
  • 【ElasticSearch系列-06】Es集群架构的搭建以及集群的核心概念

    ElasticSearch系列整体栏目 内容 链接地址 【一】ElasticSearch下载和安装 https://zhenghuisheng.blog.csdn.net/article/details/129260827 【二】ElasticSearch概念和基本操作 https://blog.csdn.net/zhenghuishengq/article/details/134121631 【三】ElasticSearch的高级查询Query DSL https://blog.csdn.net/zhenghuishengq/article/details/1

    2024年02月04日
    浏览(60)
  • 磐基2.0搭建es集群 k8s安装elasticsearch集群

    参考: k8s安装elasticsearch集群_k8s部署elasticsearch集群_MasonYyp的博客-CSDN博客 1 环境简述搭建es集群需要使用的技术如下:k8s集群、StatefulSet控制器、Service(NodePort)服务、PV、PVC、volumeClaimTemplates(存储卷申请模板)。StatefulSet控制器创建的Pod适合用于分布式存储系统,它最大的特

    2024年02月09日
    浏览(40)
  • elasticSearch核心概念的介绍(十四):ES集群索引分片管理

    上一章节我们对ES的集群进行了搭建,有兴趣的朋友可以参考一下elasticSearch核心概念的介绍(十三):docker搭建ES集群 这里我们来介绍了ES集群索引的分片管理 ES集群索引分片管理 介绍 分片(shard):因为ES是个分布式的搜索引擎,所以索引通常都会分解成不同部分,而这些

    2023年04月27日
    浏览(56)
  • Elasticsearch学习-ES中的一些组件介绍

    ES是什么 Elastic Search简称ES, 是一个高性能的全文检索框架。它提供存储、搜索、大数据准实时分析等。一般用于提供复杂搜索的服务。 ES是基于Lucene进行二次开发的一个框架,首先Lucene是一个类库,业务系统中想要使用它,你必须使用Java来作为开发语言并将其直接集成到你

    2024年02月06日
    浏览(42)
  • 【Elasticsearch】从零开始搭建ES8集群并且集成到Springboot,更好的服务电商类等需要全文索引的项目(一)

    最近公司的电商项目越来越庞大,功能需求点也越来越多,各种C端对查询和检索的要求也越来越高,是时候在项目中引入全文检索了。 ElasticSearch 是一个基于 Lucene 的搜索服务器,它提供了一个分布式多用户能力的全文搜索引擎,并且是基于Java 开发的,我记得很久之前ES还不

    2024年02月15日
    浏览(48)
  • Elasticsearch 系列(六)- ES数据同步和ES集群

    本章将和大家分享ES的数据同步方案和ES集群相关知识。废话不多说,下面我们直接进入主题。 1、数据同步问题 Elasticsearch中的酒店数据来自于mysql数据库,因此mysql数据发生改变时,Elasticsearch也必须跟着改变,这个就是Elasticsearch与mysql之间的数据同步。 在微服务中,负责酒

    2024年04月28日
    浏览(83)
  • 【ES专题】ElasticSearch集群架构剖析

    个人感觉集群架构其实都有点大同小异,看了这么多集群架构之后,感觉无非要考虑的地方就几点: 使用何种通信协议去同步数据,互相通信 采用何种策略同步数据(异步还是同步) 如何保证一致性,保证到什么程度(【最终一致性】 or【实时一致性 / 强一致性】) 使用何

    2024年02月04日
    浏览(59)
  • ElasticSearch---查询es集群状态、分片、索引

    查看es集群状态: 如果?后面加上pretty,能让返回的json格式化。 加上?v的返回结果,如下: 解释如下: 查看es分片信息: 查看es分片信息,模糊匹配,比如匹配test: 返回信息如下: 解析如下: 查看状态为unassigned的es分片信息: 查看es索引 查看es所有索引: indices表示索引,是

    2024年02月02日
    浏览(41)
  • elasticsearch——ES集群分片不平衡处理

    在使用云上的一个ES集群的时候,发现搜索性能很差,查看分片情况,发现ES有12个节点,索引创建了10个分片,1个副本,最后20个分片全在其中3个节点上,分布不均衡,实际只消耗了3个节点的资源,所以性能很差,再次创建新的索引,发现仍然是这种情况,最后通过下面的命

    2024年02月13日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包