为什么要使用ES集群架构1.2

个人感觉集群架构其实都有点大同小异看了这么多集群架构之后感觉无非要考虑的地方就几点

使用何种通信协议去同步数据互相通信采用何种策略同步数据异步还是同步如何保证一致性保证到什么程度【最终一致性】

or【实时一致性

强一致性】使用何种算法去选举主次节点感觉这个比较随意通常为了快速恢复服务选举流程是怎么快怎么来但是不能出现【脑裂问题】

阅读对象

系列上一篇文章《【ES专题】ElasticSearch搜索进阶》

系列下一篇文章《【ES专题】ElasticSearch功能详解与原理剖析》

ES要掌握什么

使用搜索和聚合操作语法理解分词倒排索引相关性算分文档匹配度优化

笔记正文

为什么需要使用集群架构这就得提一下分布式系统的可用性与扩展性了。

服务高可用性允许个别节点停止服务个别节点停止服务不影响整体使用数据可用性部分节点丢失不会丢失数据需要有备份策略

提高系统的可用性部分节点停止服务整个集群的服务不受影响存储的水平扩容

1.2

ES集群中有2个比较核心的概念需要理解一下。

分别是节点、分片。

在聊这些概念之前我们先重新梳理一下ES的集群是什么。

集群中有一个或者多个节点不同的集群通过不同的名字来区分默认名字【elasticsearch】

1.2.1

ES中的节点本质上是一个Elasticsearch的实例一个Java进程。

通常我们建议生产环境中一台机器只运行一个ES实例。

一台机器部署多个节点其实是违背【高可用】原则的

ES节点有如下特性

node.namenode1指定每一个节点在启动之后会分配一个UID保存在data目录下节点有多种角色类型不同角色通常有不同的功能它们分别是

Master

nodes【直译符合条件的节点】。

可以参与选举的合格节点Data

Node数据节点负责文档的写入、读取。

节点保存数据并执行与数据相关的操作如CRUD、搜索和聚合Coordinating

Node协调节点其他节点

通过ES多角色定义可以看的出来ES的集群架构非常成熟它也是我目前见过的角色最丰富的架构。

如此丰富的角色定义肯定是为了拓展集群架构而生的单一职责嘛。

不过有一点我没想通的是如果节点太多了做一次CRUD的速度能快吗会不会在通信上就花费了很多时间。

关于Master

eligible节点即都可以参与集群选举成为Master节点。

可以通过node.materfalse禁止当第一个节点启动时候它会将自己选举成Master节点每个节点上都保存了集群的状态但是只有Master节点才能修改集群的状态信息。

集群状态信息(Cluster

State)

所有节点信息所有的索引和其他相关的Mapping与Setting信息分片的路由信息

关于Data

Node负责保存分片数据。

在数据扩展上起到了至关重要的作用节点启动后默认就是数据节点。

可以设置node.data:

false禁止由Master

Node决定如何把分片分发到数据节点上通过增加数据节点可以解决数据水平扩展和解决数据单点问题

Coordinating

将请求分发到合适的节点最终把结果汇集到一起每个节点默认都起到了Coordinating

其他节点类型

不同硬件配置通常是CPU跟硬盘。

硬盘根据冷热数据类型可以选择固态或者机械硬盘

Ingest

Node数据前置处理转换节点支持pipeline管道设置可以使用ingest对数据进行过滤、转换等操作Machine

Learning

Node连接到不同的Elasticsearch集群并且支持将这些集群当成一个单独的集群处理

1.2.1.1

管理索引和分片的创建、删除和重新分配监测节点的状态并在需要时进行重分配协调节点之间的数据复制和同步工作处理集群级别操作如创建或删除索引、添加或删除节点等维护集群的状态

1.2.1.2

节点会将索引分片存储在本地磁盘上并对查询请求进行响应复制和同步数据为了确保数据的可靠性和高可用性ElasticSearch

Data

节点上并定期将各节点上的数据进行同步参与搜索和聚合操作当客户端提交搜索请求时Data

Node

节点会使用本地缓存和分片数据完成搜索和聚合操作执行数据维护操作例如清理过期数据和压缩分片等

官方定义

数据节点保存包含您已索引的文档的分片。

数据节点处理数据相关操作例如

I/O、内存和

在多层部署体系结构中您可以使用专门的数据角色将数据节点分配到特定层data_content、data_hot、data_warm、

data_cold或data_frozen。

一个节点可以属于多个层但具有专用数据角色之一的节点不能具有通用data角色。

1.2.1.3

诸如搜索请求或批量索引请求之类的请求它们可能涉及不同数据节点上保存的数据。

例如搜索请求分两个阶段执行这两个阶段由接收客户端请求的节点协调节点协调。

在分散阶段协调节点将请求转发到保存数据的数据节点。

每个数据节点在本地执行请求并将其结果返回给协调节点在收集阶段协调节点将每个数据节点的结果缩减为单个全局结果集

每个节点都是隐式的协调节点。

这意味着具有显式空角色列表的节点node.roles将仅充当协调节点无法禁用。

因此这样的节点需要有足够的内存和

CPU

在实际的文档索引发生之前使用摄取节点对文档进行预处理。

摄取节点拦截批量和索引请求应用转换然后将文档传递回索引或批量api。

默认情况下所有节点都启用摄取因此任何节点都可以处理摄取任务。

您还可以创建专用的摄取节点。

如果要禁用节点的摄取请在elasticsearch.

false

要在索引之前对文档进行预处理请定义一个指定一系列处理器的管道。

每个处理器都以某种特定的方式转换文档。

例如管道可能有一个处理程序从文档中删除字段然后有另一个处理程序重命名字段。

然后集群状态存储配置的管道。

要使用管道只需在索引或批量请求上指定pipeline参数。

这样摄取节点就知道要使用哪个管道。

例如

PUT

my-index/my-type/my-id?pipelinemy_pipeline_id

{foo:

通常集群启动时第一个启动的节点会被选为主节点。

当主节点挂了的时候进行下一步互相Ping对方Node

低的会成为被选举的节点其他节点会加入集群但是不承担Master节点的角色。

一旦发现被选中的主节点丢失就会重新选举出新的Master节点

Master节点非常重要在部署上需要考虑解决单点的问题为一个集群设置多个Master节点每个节点只承担Master

1.2.2

分片是ES中一个比较重要的概念。

ElasticSearch是一个分布式的搜索引擎索引可以分成一份或多份多份分布在不同节点的分片当中。

ElasticSearch会自动管理分片如果发现分片分布不均衡就会自动迁移。

主分片Primary

用以解决数据水平扩展的问题。

通过主分片可以将数据分布到集群内的所有节点之上一个分片是一个运行的Lucene的实例主分片数在索引创建时指定后续不允许修改除非Reindex

副本分片

副本分片是主分片的拷贝备份副本分片数可以动态调整增加副本数还可以在一定程度上提高服务的可用性读取的吞吐

PUT

通常都是奇数所谓【集群奇数法则】。

但其实只是名字很唬人本质上也没那么神奇。

你自己想想如果是偶数的话是不是很有可能出现选举平票的时候根据我的经验选举算法通常都希望快速选举一个master或者leader出来以便能够快速提供服务所以没空扯皮

每个节点各有一个主副分片

主副分片之间交叉存储node1的副本放在node3node2放在node1node3放在node2

使用【cat

es安装版本elasticsearch-7.17.3。

接着切换到root用户修改/etc/hosts

vim

注意集群的名字3个节点的集群名称必须一直给每个节点指定名字比如这里是node1/2/3是否要开启外网访问跟redis的配置差不多

指定集群名称3个节点必须一致

#7.0新引入的配置项,初始仲裁仅在整个集群首次启动时才需要初始仲裁。

#该选项配置为node.name的值指定可以初始化集群节点的名称

#解决跨域问题

*三个节点配置很简单按照上面的模板依次修改node.name就行了

否则会导致无法加入集群

正常来说如果我们先启动了192.168.66.150那么它就是这个集群当中的主节点所以我们验证集群的话只需要访问http://192.168.66.150:9200即可看到如下界面

1.3.2

介绍完了ES的集群部署我们再来看看ES客户端的部署。

这里有两个可选方案它们分别是Cerebro和Kibana它们的区别与联系如下

Cerebro和Kibana都是用于Elasticsearch的开源工具但它们在功能和使用场景上存在一些区别。

CerebroCerebro是Elasticsearch的图形管理工具可以查看分片分配和执行常见的索引操作功能集中管理alias和index

template十分快捷。

此外Cerebro还具有实时监控数据的功能。

KibanaKibana是一个强大的可视化工具可以用于Elasticsearch数据的探索、分析和展示。

它提供了丰富的图表类型包括折线图、直方图、饼图等可以方便地展示基于时间序列的数据。

此外Kibana还提供了日志管理、分析和展示的功能

使用场景

CerebroCerebro适合用于生产和测试环境的Elasticsearch集群管理尤其适用于需要快速查看和执行索引操作的情况。

由于Cerebro轻量且适用于实时监控它可能更适用于较小的集群和实时监控的场景。

KibanaKibana适合对Elasticsearch数据进行深入的分析和探索以及对日志进行管理和分析。

它提供了丰富的可视化功能和灵活的数据展示方式适用于各种规模的数据分析和监控场景。

Cerebro安装

可以查看分片分配和通过图形界面执行常见的索引操作完全开源并且它允许添加用户密码或

LDAP

安装包下载地址如下https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip

nohup

输入ES集群节点http://192.168.66.150:9200建立连接。

然后会出现以下界面

kibana安装

[http://192.168.66.150:9200,http://192.168.66.151:9200,http://192.168.66.152:9200]

i18n.locale:

访问http://192.168.66.150:5601/验证

二、生产环境最佳实践

Learning等。

不过跟之前学习的各种集群架构不同的是ES一个节点可承担多种角色。

不过在生产环境中尽量还是一个节点一种角色比较好优点是极致的高可用缺点是可能有点费钱

#Master节点

在实际生产中我们可能会遇到需要水平扩展容量的场景通常来说以下是几个常见的场景

当磁盘容量无法满足需求时可以增加数据节点磁盘读写压力大时增加数据节点当系统中有大量的复杂查询及聚合时候增加Coordinating节点增加查询的性能

2.3

下面是一个多集群架构。

集群处在三个数据中心数据三写使用GTM分发读请求

GTM

是通过DNS将域名解析到多个IP地址不同用户访问不同的IP地址来实现应用服务流量的分配。

同时通过健康检查动态更新DNS解析IP列表实现故障隔离以及故障切换。

最终用户的访问直接连接服务的IP地址并不通过GTM。

SLB

是通过代理用户访问请求的形式将用户访问请求实时分发到不同的服务器最终用户的访问流量必须要经过SLB。

一般来说相同Region使用SLB进行负载均衡不同region的多个SLB地址时则可以使用GTM进行负载均衡。

2.4

热节点存放用户最关心的热数据温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。

在成本有限的前提下让客户关注的实时数据和历史数据硬件隔离最大化解决客户反应的响应时间慢的问题。

业务场景描述每日增量6TB日志数据高峰时段写入及查询频率都较高集群压力较大查询ES时常出现查询缓慢问题。

ES集群的索引写入及查询速度主要依赖于磁盘的IO速度冷热数据分离的关键为使用SSD磁盘存储热数据提升查询效率。

若全部使用SSD成本过高且存放冷数据较为浪费因而使用普通SATA磁盘与SSD磁盘混搭可做到资源充分利用性能大幅提升的目标。

ES为什么要设计Hot

节点通常使用HDD)︰索引不存在新数据的写入同时也不存在大量的数据查询

Hot

CPU和IO都有很高的要求所以需要使用高配置的机器存储的性能要好建议使用SSD

Warm

node.attr来指定node属性hot或是warm。

在index的settings里通过index.routing.allocation来指定索引index)到一个满足要求的node

Shard

Filtering步骤分为以下几步标记节点(Tagging)配置索引到Hot

Node配置索引到

节点的attribute可以是任何的key/value可以通过elasticsearch.yml

标记一个

{settings:{number_of_shards:2,number_of_replicas:0,index.routing.allocation.require.my_node_type:hot}

}POST

_cat/shards/index-2022-05?v3旧数据移动到Warm节点

Index.routing.allocation是一个索引级的dynamic

配置到

index.routing.allocation.require.my_node_type:warm

GET

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

做容量规划时一些需要考虑的因素

机器的软硬件配置单条文档的大小│文档的总数据量│索引的总数据量(Time

base数据保留的时间)|副本分片数文档是如何写入的(Bulk的大小)文档的复杂度文档是如何进行读取的(怎么样的查询和聚合)

数据吞吐及性能需求

了解你的数据数据的格式和数据的Mapping实际的查询和聚合长的是什么样的

ES集群常见应用场景

使用ES存放日志与性能指标。

数据每天不断写入增长速度较快结合Warm

Node

选择合理的硬件数据节点尽可能使用SSD搜索等性能要求高的场景建议SSD

单节点数据建议控制在2TB以内最大不建议超过5TBJVM配置机器内存的一半JVM内存配置不建议超过32G不建议在一台服务器上运行多个节点

内存大小要根据Node

G加上预留空间。

所以每个节点最多400G数据至少需要5个数据节点如果是日志类项目每个节点31*50

1550

按需选择合理的部署方式如果需要考虑可靠性高可用建议部署3台单一的Master节点如果有复杂的查询和聚合建议设置Coordinating节点

集群扩容

Node解决CPU和内存开销的问题增加数据节点解决存储的容量的问题为避免分片分布不均的问题要提前监控磁盘空间提前清理数据或增加节点

2.6

7.0开始新创建一个索引时默认只有一个主分片。

单个分片查询算分聚合不准的问题都可以得以避免单个索引单个分片时候集群无法实现水平扩展。

即使增加新的节点无法实现水平扩展

两个分片

相关性算分在分片之间是相互独立的每个分片都基于自己的分片上的数据进行相关度计算。

这会导致打分偏离的情况特别是数据量很少时。

当文档总数很少的情况下如果主分片大于1主分片数越多相关性算分会越不准

一个示例如下

/blogs/_search?search_typedfs_query_***n_fetch

{query:

数据量不大的时候可以将主分片数设置为1。

当数据量足够大时候只要保证文档均匀分散在各个分片上结果一般就不会出现偏差使用DFS

Query

搜索的URL中指定参数“_search?search_typedfs_query_***n_fetch到每个分片把各分片的词频和文档频率进行搜集然后完整的进行一次相关性算分

如何设计分片数

一旦集群中有新的数据节点加入分片就可以自动进行分配分片在重新分配时系统不会有downtime

实现集群水平扩展的最小单位。

过多设置分片数会带来一些潜在的问题

每个分片是一个Lucene的索引会使用机器的资源。

过多的分片会导致额外的性能开销。

每次搜索的请求,需要从每个分片上获取数据分片的Meta

信息由Master节点维护。

过多会增加管理的负担。

经验值控制分片总数在10W以内

如何确定主分片数

提高系统可用性︰响应查询请求防止数据丢失需要占用和主分片一样的资源

有几份副本就会有几倍的CPU资源消耗在索引上会减缓对主分片的查询压力但是会消耗同样的内存资源。

如果机器资源充分提高副本数可以提高整体的查询QPS

ES的分片策略会尽量保证节点上的分片数大致相同但是有些场景下会导致分配不均匀

扩容的新节点没有数据导致新索引集中在新的节点热点数据过于集中可能会产生性能问题

index.routing.allocation.total_shards_per_nodeindex级别的表示这个index每个Node总共允许存在多少个shard默认值是-1表示无穷多个cluster.routing.allocation.total_shards_per_nodecluster级别表示集群范围内每个Node允许存在有多少个shard。

默认值是-1表示无穷多个。

如果目标Node的Shard数超过了配置的上限则不允许分配Shard到该Node上。

注意index级别的配置会覆盖cluster级别的配置