邱县专业做网站,用dw建立网站,房地产免费网站建设,用vps建网站备案目录 前言阅读对象阅读导航前置知识笔记正文一、ES集群架构1.1 为什么要使用ES集群架构1.2 ES集群核心概念1.2.1 节点1.2.1.1 Master Node主节点的功能1.2.1.2 Data Node数据节点的功能1.2.1.3 Master Node主节点选举流程 1.2.2 分片1.3 搭建三节点ES集群1.3.1 ES集群搭建步骤1… 目录 前言阅读对象阅读导航前置知识笔记正文一、ES集群架构1.1 为什么要使用ES集群架构1.2 ES集群核心概念1.2.1 节点1.2.1.1 Master Node主节点的功能1.2.1.2 Data Node数据节点的功能1.2.1.3 Master Node主节点选举流程 1.2.2 分片1.3 搭建三节点ES集群1.3.1 ES集群搭建步骤1.3.2 安装客户端 二、生产环境最佳实践2.1 一个节点只承担一个角色的配置2.2 增加节点水平扩展场景2.3 异地多活架构2.4 Hot Warm 架构2.5 如何对集群的容量进行规划2.6 如何设计和管理分片 前言
个人感觉集群架构其实都有点大同小异看了这么多集群架构之后感觉无非要考虑的地方就几点
使用何种通信协议去同步数据互相通信采用何种策略同步数据异步还是同步如何保证一致性保证到什么程度【最终一致性】 or【实时一致性 / 强一致性】使用何种算法去选举主次节点感觉这个比较随意通常为了快速恢复服务选举流程是怎么快怎么来但是不能出现【脑裂问题】
阅读对象
有基本ES使用知识需要使用集群架构
阅读导航
系列上一篇文章《【ES专题】ElasticSearch搜索进阶》
前置知识
笔记正文
一、ES集群架构
1.1 为什么要使用ES集群架构
为什么需要使用集群架构这就得提一下分布式系统的可用性与扩展性了。
高可用性分为两个点考虑 服务高可用性允许个别节点停止服务个别节点停止服务不影响整体使用数据可用性部分节点丢失不会丢失数据需要有备份策略 可扩展性 请求量提升/数据的不断增长(将数据分布到所有节点上)
上面所说的正是集群架构的优势所在。对ES集群架构来说则体现在
提高系统的可用性部分节点停止服务整个集群的服务不受影响存储的水平扩容 1.2 ES集群核心概念
ES集群中有2个比较核心的概念需要理解一下。分别是节点、分片。在聊这些概念之前我们先重新梳理一下ES的集群是什么。 ES的集群亦上图所示它通常由如下特征
集群中有一个或者多个节点不同的集群通过不同的名字来区分默认名字【elasticsearch】 注意ES在实际生产环境中还会部署多个集群一起工作 通过配置文件修改或者在命令行中 -E cluster.namees-cluster进行设定
1.2.1 节点
ES中的节点本质上是一个Elasticsearch的实例一个Java进程。通常我们建议生产环境中一台机器只运行一个ES实例。一台机器部署多个节点其实是违背【高可用】原则的 ES节点有如下特性
每一个节点都有名字通过配置文件配置或者启动时候 -E node.namenode1指定每一个节点在启动之后会分配一个UID保存在data目录下节点有多种类型不同类型通常有不同的功能其他中间件也会称之为集群角色。它们分别是 Master Node主节点负责索引的删除创建Master eligible nodes【直译符合条件的节点】。可以参与选举的合格节点Data Node数据节点负责文档的写入、读取Coordinating Node协调节点其他节点 节点类型可以通过如下配置参数禁用/启用 关于Master eligible nodes和Master Node
每个节点启动后默认就是一个Master eligible节点即都可以参与集群选举成为Master节点。可以通过node.materfalse禁止当第一个节点启动时候它会将自己选举成Master节点每个节点上都保存了集群的状态但是只有Master节点才能修改集群的状态信息。集群状态信息(Cluster State) 维护了一个集群中所有必要的信息。比如 所有节点信息所有的索引和其他相关的Mapping与Setting信息分片的路由信息
关于Data Node 和 Coordinating Node
Data Node 可以保存数据的节点叫做Data Node负责保存分片数据。在数据扩展上起到了至关重要的作用节点启动后默认就是数据节点。可以设置node.data: false禁止由Master Node决定如何把分片分发到数据节点上通过增加数据节点可以解决数据水平扩展和解决数据单点问题 Coordinating Node 负责接受Client的请求 将请求分发到合适的节点最终把结果汇集到一起每个节点默认都起到了Coordinating Node的职责
其他节点类型
Hot Warm Node冷热节点。不同硬件配置 的Data Node用来实现Hot Warm架构降低集群部署的成本Ingest Node数据前置处理转换节点支持pipeline管道设置可以使用ingest对数据进行过滤、转换等操作Machine Learning Node负责跑机器学习的Job用来做异常检测Tribe NodeTribe Node连接到不同的Elasticsearch集群并且支持将这些集群当成一个单独的集群处理
以下是一个多集群业务架构图
1.2.1.1 Master Node主节点的功能
Master节点主要功能:
管理索引和分片的创建、删除和重新分配监测节点的状态并在需要时进行重分配协调节点之间的数据复制和同步工作处理集群级别操作如创建或删除索引、添加或删除节点等维护集群的状态
1.2.1.2 Data Node数据节点的功能
Data Node数据节点的功能
存储和索引数据Data Node 节点会将索引分片存储在本地磁盘上并对查询请求进行响应复制和同步数据为了确保数据的可靠性和高可用性ElasticSearch 会将每个原始分片的多个副本存储在不同的 Data Node 节点上并定期将各节点上的数据进行同步参与搜索和聚合操作当客户端提交搜索请求时Data Node 节点会使用本地缓存和分片数据完成搜索和聚合操作执行数据维护操作例如清理过期数据和压缩分片等
1.2.1.3 Master Node主节点选举流程
ES的选举流程也很简单如下
通常集群启动时第一个启动的节点会被选为主节点。当主节点挂了的时候进行下一步互相Ping对方Node ld 低的会成为被选举的节点其他节点会加入集群但是不承担Master节点的角色。一旦发现被选中的主节点丢失就会重新选举出新的Master节点 在我们的生产过程中Master Node的最佳实践方案 Master节点非常重要在部署上需要考虑解决单点的问题为一个集群设置多个Master节点每个节点只承担Master 的单一角色 1.2.2 分片
分片是ES中一个比较重要的概念。ElasticSearch是一个分布式的搜索引擎索引可以分成一份或多份多份分布在不同节点的分片当中。ElasticSearch会自动管理分片如果发现分片分布不均衡就会自动迁移。
分片又有【主分片】、【副本分片】之分。它们的区别如下
主分片Primary Shard 用以解决数据水平扩展的问题。通过主分片可以将数据分布到集群内的所有节点之上一个分片是一个运行的Lucene的实例主分片数在索引创建时指定后续不允许修改除非Reindex 副本分片 用以解决数据高可用的问题。 副本分片是主分片的拷贝备份副本分片数可以动态调整增加副本数还可以在一定程度上提高服务的可用性读取的吞吐
# 指定索引的主分片和副本分片数
PUT /csdn_blogs
{settings: {number_of_shards: 3,number_of_replicas: 1}
}分片架构 如上图是某个集群的分片架构它有如下特征
集群中有3个节点每个节点各有一个主副分片主副分片之间交叉存储node1的副本放在node3node2放在node1node3放在node2 使用【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的详细信息 1.3 搭建三节点ES集群
1.3.1 ES集群搭建步骤
下面是在Linux环境centos7下面的集群搭建步骤 1系统环境准备 首先创建用户因为es不允许root账号启动
adduser es
passwd es安装版本elasticsearch-7.17.3。接着切换到root用户修改/etc/hosts
vim /etc/hosts
192.168.66.150 es-node1
192.168.66.151 es-node2
192.168.66.152 es-node3 2修改elasticsearch.yml 注意配置里面的注释里面有一些细节。比如
注意集群的名字3个节点的集群名称必须一直给每个节点指定名字比如这里是node1/2/3是否要开启外网访问跟redis的配置差不多
# 指定集群名称3个节点必须一致
cluster.name: es-cluster
#指定节点名称每个节点名字唯一
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
#用于节点发现
discovery.seed_hosts: [es-node1, es-node2, es-node3]
#7.0新引入的配置项,初始仲裁仅在整个集群首次启动时才需要初始仲裁。
#该选项配置为node.name的值指定可以初始化集群节点的名称
cluster.initial_master_nodes: [node-1,node-2,node-3]
#解决跨域问题
http.cors.enabled: true
http.cors.allow-origin: *三个节点配置很简单按照上面的模板依次修改node.name就行了
3) 启动每个节点的ES服务
# 注意如果运行过单节点模式需要删除data目录 否则会导致无法加入集群
rm -rf data
# 启动ES服务
bin/elasticsearch -d 4验证集群 正常来说如果我们先启动了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安装 Cerebro 可以查看分片分配和通过图形界面执行常见的索引操作完全开源并且它允许添加用户密码或 LDAP 身份验证问网络界面。Cerebro 基于 Scala 的Play 框架编写用于后端 REST 和 Elasticsearch 通信。 它使用通过 AngularJS 编写的单页应用程序SPA前端。 安装包下载地址如下https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip
下载安装之后用以下命令启动即可
cerebro-0.9.4/bin/cerebro#后台启动
nohup bin/cerebro cerebro.log 访问http://192.168.66.150:9000/ 输入ES集群节点http://192.168.66.150:9200建立连接。然后会出现以下界面 kibana安装 1修改kibana配置
vim config/kibana.ymlserver.port: 5601
server.host: 192.168.66.150
elasticsearch.hosts: [http://192.168.66.150:9200,http://192.168.66.151:9200,http://192.168.66.152:9200]
i18n.locale: zh-CN 2运行Kibana
#后台启动
nohup bin/kibana 3访问 访问http://192.168.66.150:5601/验证
二、生产环境最佳实践
2.1 一个节点只承担一个角色的配置
我们在上面的介绍中知道节点有多种不同的类型角色有Master eligible / Data / Ingest / Coordinating /Machine Learning等。不过跟之前学习的各种集群架构不同的是ES一个节点可承担多种角色。 不过在生产环境中尽量还是一个节点一种角色比较好优点是极致的高可用缺点是可能有点费钱 想要一个节点只承担一个角色只需要修改如下配置
#Master节点
node.master: true
node.ingest: false
node.data: false#data节点
node.master: false
node.ingest: false
node.data: true#ingest 节点
node.master: false
node.ingest: true
node.data: false#coordinate节点
node.master: false
node.ingest: false
node.data: false2.2 增加节点水平扩展场景
在实际生产中我们可能会遇到需要水平扩展容量的场景通常来说以下是几个常见的场景
当磁盘容量无法满足需求时可以增加数据节点磁盘读写压力大时增加数据节点当系统中有大量的复杂查询及聚合时候增加Coordinating节点增加查询的性能
2.3 异地多活架构
下面是一个多集群架构。集群处在三个数据中心数据三写使用GTM分发读请求 全局流量管理GTM和负载均衡SLB的区别 GTM 是通过DNS将域名解析到多个IP地址不同用户访问不同的IP地址来实现应用服务流量的分配。同时通过健康检查动态更新DNS解析IP列表实现故障隔离以及故障切换。最终用户的访问直接连接服务的IP地址并不通过GTM。 而 SLB 是通过代理用户访问请求的形式将用户访问请求实时分发到不同的服务器最终用户的访问流量必须要经过SLB。 一般来说相同Region使用SLB进行负载均衡不同region的多个SLB地址时则可以使用GTM进行负载均衡。 2.4 Hot Warm 架构
热节点存放用户最关心的热数据温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。 它的典型的应用场景如下 在成本有限的前提下让客户关注的实时数据和历史数据硬件隔离最大化解决客户反应的响应时间慢的问题。业务场景描述每日增量6TB日志数据高峰时段写入及查询频率都较高集群压力较大查询ES时常出现查询缓慢问题。
ES集群的索引写入及查询速度主要依赖于磁盘的IO速度冷热数据分离的关键为使用SSD磁盘存储热数据提升查询效率。若全部使用SSD成本过高且存放冷数据较为浪费因而使用普通SATA磁盘与SSD磁盘混搭可做到资源充分利用性能大幅提升的目标。
ES为什么要设计Hot Warm 架构呢
ES数据通常不会有 Update操作;适用于Time based索引数据同时数据量比较大的场景。引入 Warm节点低配置大容量的机器存放老数据以降低部署成本
两类数据节点不同的硬件配置
Hot节点(通常使用SSD)︰索引不断有新文档写入。Warm 节点通常使用HDD)︰索引不存在新数据的写入同时也不存在大量的数据查询
Hot Nodes用于数据的写入
lndexing 对 CPU和IO都有很高的要求所以需要使用高配置的机器存储的性能要好建议使用SSD
Warm Nodes 用于保存只读的索引比较旧的数据。通常使用大容量的磁盘
配置Hot Warm 架构 使用Shard Filtering实现HotWarm node间的数据迁移
node.attr来指定node属性hot或是warm。在index的settings里通过index.routing.allocation来指定索引index)到一个满足要求的node 使用 Shard Filtering步骤分为以下几步标记节点(Tagging)配置索引到Hot Node配置索引到 Warm节点
1标记节点 需要通过“node.attr”来标记一个节点
节点的attribute可以是任何的key/value可以通过elasticsearch.yml 或者通过-E命令指定
# 标记一个 Hot 节点
elasticsearch.bat -E node.namehotnode -E cluster.nametulingESCluster -E http.port9200 -E path.datahot_data -E node.attr.my_node_typehot# 标记一个 warm 节点
elasticsearch.bat -E node.namewarmnode -E cluster.nametulingESCluster -E http.port9201 -E path.datawarm_data -E node.attr.my_node_typewarm# 查看节点
GET /_cat/nodeattrs?v2配置Hot数据 创建索引时候指定将其创建在hot节点上
# 配置到 Hot节点
PUT /index-2022-05
{settings:{number_of_shards:2,number_of_replicas:0,index.routing.allocation.require.my_node_type:hot}
}POST /index-2022-05/_doc
{create_time:2022-05-27
}#查看索引文档的分布
GET _cat/shards/index-2022-05?v3旧数据移动到Warm节点 Index.routing.allocation是一个索引级的dynamic setting可以通过API在后期进行设定
# 配置到 warm 节点
PUT /index-2022-05/_settings
{ index.routing.allocation.require.my_node_type:warm
}
GET _cat/shards/index-2022-05?v2.5 如何对集群的容量进行规划
一个集群总共需要多少个节点?一个索引需要设置几个分片规划上需要保持一定的余量当负载出现波动节点出现丢失时还能正常运行。做容量规划时一些需要考虑的因素
机器的软硬件配置单条文档的大小│文档的总数据量│索引的总数据量(Time base数据保留的时间)|副本分片数文档是如何写入的(Bulk的大小)文档的复杂度文档是如何进行读取的(怎么样的查询和聚合)
评估业务的性能需求
数据吞吐及性能需求 数据写入的吞吐量每秒要求写入多少数据?查询的吞吐量? 单条查询可接受的最大返回时间? 了解你的数据数据的格式和数据的Mapping实际的查询和聚合长的是什么样的
ES集群常见应用场景
搜索: 固定大小的数据集 搜索的数据集增长相对比较缓慢 日志: 基于时间序列的数据 使用ES存放日志与性能指标。数据每天不断写入增长速度较快结合Warm Node 做数据的老化处理
硬件配置
选择合理的硬件数据节点尽可能使用SSD搜索等性能要求高的场景建议SSD 按照1∶10-20的比例配置内存和硬盘 日志类和查询并发低的场景可以考虑使用机械硬盘存储 按照1:50的比例配置内存和硬盘 单节点数据建议控制在2TB以内最大不建议超过5TBJVM配置机器内存的一半JVM内存配置不建议超过32G不建议在一台服务器上运行多个节点
内存大小要根据Node 需要存储的数据来进行估算
搜索类的比例建议: 1:16日志类: 1:48——1:96之间
假设总数据量1T设置一个副本就是2T总数据量
如果搜索类的项目每个节点31*16 496 G加上预留空间。所以每个节点最多400G数据至少需要5个数据节点如果是日志类项目每个节点31*50 1550 GB2个数据节点即可
部署方式
按需选择合理的部署方式如果需要考虑可靠性高可用建议部署3台单一的Master节点如果有复杂的查询和聚合建议设置Coordinating节点
集群扩容
增加Coordinating / Ingest Node解决CPU和内存开销的问题增加数据节点解决存储的容量的问题为避免分片分布不均的问题要提前监控磁盘空间提前清理数据或增加节点
2.6 如何设计和管理分片
单个分片
7.0开始新创建一个索引时默认只有一个主分片。单个分片查询算分聚合不准的问题都可以得以避免单个索引单个分片时候集群无法实现水平扩展。即使增加新的节点无法实现水平扩展
两个分片 集群增加一个节点后Elasticsearch 会自动进行分片的移动也叫 Shard Rebalancing
算分不准的原因 相关性算分在分片之间是相互独立的每个分片都基于自己的分片上的数据进行相关度计算。这会导致打分偏离的情况特别是数据量很少时。当文档总数很少的情况下如果主分片大于1主分片数越多相关性算分会越不准 一个示例如下
PUT /blogs
{settings:{number_of_shards : 3}
}POST /blogs/_doc/1?routingfox
{content:Cross Cluster elasticsearch Search
}POST /blogs/_doc/2?routingfox2
{content:elasticsearch Search
}POST /blogs/_doc/3?routingfox3
{content:elasticsearch
}GET /blogs/_search
{query: {match: {content: elasticsearch}}
}#解决算分不准的问题
GET /blogs/_search?search_typedfs_query_then_fetch
{query: {match: {content: elasticsearch}}
}解决算分不准的方法
数据量不大的时候可以将主分片数设置为1。当数据量足够大时候只要保证文档均匀分散在各个分片上结果一般就不会出现偏差使用DFS Query Then Fetch 搜索的URL中指定参数“_search?search_typedfs_query_then_fetch到每个分片把各分片的词频和文档频率进行搜集然后完整的进行一次相关性算分
但是这样耗费更加多的CPU和内存执行性能低下一般不建议使用
如何设计分片数 当分片数节点数时
一旦集群中有新的数据节点加入分片就可以自动进行分配分片在重新分配时系统不会有downtime
多分片的好处: 一个索引如果分布在不同的节点多个节点可以并行执行
查询可以并行执行数据写入可以分散到多个机器
分片过多所带来的副作用 Shard是Elasticsearch 实现集群水平扩展的最小单位。过多设置分片数会带来一些潜在的问题
每个分片是一个Lucene的索引会使用机器的资源。过多的分片会导致额外的性能开销。每次搜索的请求,需要从每个分片上获取数据分片的Meta 信息由Master节点维护。过多会增加管理的负担。经验值控制分片总数在10W以内
如何确定主分片数 从存储的物理角度看
搜索类应用单个分片不要超过20 GB日志类应用单个分片不要大于50 GB
为什么要控制分片存储大小
提高Update 的性能进行Merge 时减少所需的资源丢失节点后具备更快的恢复速度便于分片在集群内 Rebalancing
如何确定副本分片数 副本是主分片的拷贝
提高系统可用性︰响应查询请求防止数据丢失需要占用和主分片一样的资源
对性能的影响
副本会降低数据的索引速度: 有几份副本就会有几倍的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级别的配置
