ES节点角色深层解读,及高可用集群架构角色设计

简介: ES节点角色深层解读,及高可用集群架构角色设计

1、角色的重要性

角色是ES节点的重要属性,属于Elasticsearch的重要基础概念。


在高可用系统架构中,节点角色发挥着至关重要的作用。如果前期没有对业务系统和技术架构做足准备,没有充分考虑后期的扩展问题,势必会为将来的性能优化留下潜在问题。


ES中存在两个模式:“开发模式”和“生产模式”。

  • 开发模式存在的意义是为了降低ES的上手难度,在开发模式下不会触发启动检查,避免了刚考试学习ES在一些基础环境问题上死磕
  • 生产模式:生产模式存在的意义是尽可能的避免开发者因为对ES体系掌握不全面从而造成在项目初期对业务系统和性能评估的判断失误,从而给项目系统后期在系统架构上没有充分考虑性能扩展和数据结构有优化实践,为后期的性能优化带来阻碍,也为业务系统埋下了隐患。


2、高可用(HA)集群架构设计应遵循以下原则

  • 高可用原则
  • 职责单一原则
  • 易扩展原则
  • 避免资源浪费


3、节点角色划分

3.1 主节点(active master node

1 主节点 ≠ master节点

集群中只允许有一个活跃的主节点(下面简称主节点),我们称之为 active master 节点。一般为了避免主节点宕机造成集群无主,所以需要配置候选节点以便在主节点宕机时选举出新的主节点。


通常在口语中所说的主节点(或者master节点)指的都是active master节点,而不是严格意义上的配置了master角色的节点,换句话说,配置了master的节点应该叫做候选节点,其不一定是主节点,只有在master选举中胜出的节点,才是主节点,即 active master节点。


2 主节点必须遵循以下分配原则:

  • 避免重负载任务:主节点负责轻量级集群范围的操作,例如创建或删除索引、跟踪哪些节点是集群的一部分以及决定将哪些分片分配给哪些节点。拥有一个稳定的主节点对于集群健康很重要。当选的主节点拥有履行其职责所需的资源,这对于集群的健康非常重要。如果所选的主节点承载了其他任务,比如数据的增删改查等资源密集型人物,会对集群的稳定运行造成较大影响。避免主节点负载过重的最可靠方法是把所有配置了master角色的节点配置为专用主节点(或者称之为专用候选节点),使它们能够专注于管理集群。
  • 负载均衡器:专用master节点仍将充当协调节点,也就是集群中的负载均衡器,将请求从客户端路由到集群中的其他节点,但是不要以负载均衡器的目的而设置候选节点。另外负载均衡节点
  • 任何不是 voting-only的 master-eligible节点都可以被选举为 active master。
  • 主节点必须有一个 path.data目录,其内容在重启后仍然存在,就像数据节点一样,因为这是存储集群元数据的地方。集群元数据描述了如何读取存储在数据节点上的数据,因此如果丢失,则无法读取存储在数据节点上的数据。
  • 高可用性 (HA) 集群需要至少三个候选节点,其中至少两个不是仅投票节点。这样即使其中一个节点发生故障,也可以保证剩下的节点能够选举出一个主节点。


3.2 候选节点(master-eligible nodes)★

候选节点即:master-eligible node,口语中经常也称之为 master node ,严格来说,用中文来解释,应该叫做 候选节点(中文口语中通常也叫 master节点)。默认情况下,候选节点默认也是有效的投票节点,即:配置了master角色的节点,默认具备选举权和被选举权,可以参与选举,也可以为其他节点投票。


活跃的主节点一定是配置了master角色的节点,即一定是候选节点,但是候选节点不一定是主节点,一个集群中只可能有一个主节点,而可以同时存在多个候选节点,候选节点的作用主要在于当主节点宕机或发生故障脱离集群时,参与选举成为新的主节点,从而避免集群无主。


任何不是仅投票节点的主合格节点都可以通过主选举过程选举成为主节点**。**


3.3 专用主节点(dedicated master-eligible node)

专用候选节点(专用主节点)一般指仅配置了master角色的节点,其设计初衷为尽可能的让主节点职责单一,避免重负载任务给集群管理带来压力。


1 配置

node.roles: [ master ]


3.4 仅投票节点(voting_only node)

1 什么是仅投票节点

仅投票节点即:仅具备选举权可以为其他候选节点投票,而没有被选举权无法参与竞选的节点。


2 仅投票节点存在的意义

仅投票节点存在的意义就是为了降低资源浪费,注意是降低而无法做到完全避免。因为高可用系统在很多层面都需要以空间换时间,在很多情况下需要我们去权衡利弊,做出最佳选择。


为了避免让主节点执行重负载任务,遵循职责单一原则,我们一般不为其分配 data 角色,从而避免让主节点执行数据的增删改查这种重负载任务。


但是这无形中造成很大的资源浪费,尤其是小规模集群,本身服务器资源就不多,节点就少。以一个五节点的集群为例,如果我们为了遵循职责单一法则,让其中3个master节点都作为专用候选节点(仅配置master角色),那么真正执行增删改查的节点就只有两个了,


一个很好的办法就是“二加一部署”,即两个专用主节点 一个仅投票节点

节点 角色 是否主节点 选举权 被选举权 备注
node-1 master 活跃的主节点,同时也是一个负载均衡器
node-2 master 候选节点,主要作用是当 node-1 故障时替代node-1成为主节点,次要作用是充当负载均衡器
node-3 master、voting_only、data 不可能 X 虽然配置了master角色,但是只能投票。其永远不可能成为主节点,因此可为其分配data角色,避免了node-3空置,降低了资源浪费
node-4 data 不可能 无效 X 主要承担数据的读写任务,不具备有效的选举权和被选举权
node-5 data 不可能 无效 X 主要承担数据的读写任务,不具备有效的选举权和被选举权


仅投票节点没有被选举权只有选举权,也就是仅投票节点永远无法成为主节点,这样的话我们就可以为其分配data角色让其承担数据负载,这样技能保证选举出的新的主节点是一个专用主节点,又降低的资源浪费。


3 配置仅投票节点

一般情况下,voting_only 和 master 角色是一起配置的,单独配置 voting_only 角色是没有意义的。

配置master角色的节点拥有被选举权选举权,而voting_only 的作用就是阉割掉候选节点的被选举权,让其只能投票,而不能参与选举。所以如果没有master角色,配置voting_only也是没有意义的。

node.roles: [ data, master, voting_only ]


3.5 数据节点(data nodes)

数据节点保存包含已编入索引的文档的分片。数据节点处理数据相关操作,如 CRUD、搜索和聚合。这些操作是 I/O 密集型、内存密集型和 CPU 密集型的。监控这些资源并在它们过载时添加更多数据节点非常重要。


配置数据节点:

node.roles: [ data, xxx ]


3.6 预处理节点(ingest nodes)

预处理节点有点类似于logstash的消息管道,所以也叫ingest pipeline,常用语一些数据写入之前的预处理操作,比如去除空格、split等操作,常和update_by_query、reindex等一起考

配置方法

node.roles: [ ingest, xxx ]


3.7 远程节点(remote_cluster_client client)

具有 remote_cluster_client角色的节点,使其有资格充当远程客户端

当需要通过远程访问节点时,该角色必须配置,比如通过publish_host配置的地址访问服务节点时,该角色必须启用

配置方法

node.roles: [ remote_cluster_client, xxx ]


4 小规模集群推荐高可用配置

专用主节点存在的意义和集群规模是正相关的,也就是说,集群规模越大,配置专用主节点的意义也就越大

对于 3.4.2 中提到的五节点的集群,两个专用主节点的设计,对于当前集群规模来说,仍然是存在很大的浪费的


举个栗子

我们可以把主节点想象成一个班级的班长,五个节点分别代表五个学生,这其中包含班长。


班级就是我们的集群,现在班级需要打扫卫生(重负载任务),班长的职责主要就是指挥其他学生打扫卫生,但是当班级里人数特别少的时候,指挥其他学生这个工作对于班长的负担并不大,因为学生人数本来就很少,这个时候缺的是打扫卫生的人,此时让班长同时也去打扫卫生是更加合理的。


但是如果班级学生很多,比如有几十个上百个甚至更多,此时班长就应该把他的主要职责放在“指挥”这件事上面,自己同时兼顾打扫卫生不仅不会对整个集群负载带来多少好处,反而会大大影响自己指挥整个班级。所以此时他应该这一件事做好,也就是专用主节点了。


节点 角色 是否主节点 选举权 被选举权
node-1 master、data
node-2 master 、data
node-3 master 、data
node-4 data 不可能 无效 X
node-5 data 不可能 无效 X


小规模集群,尤其是节点个数为个位数的集群,分配专用主节点是得不偿失的!专用主节点带来的价值是远远无法弥补其浪费的节点所带来的损失的


相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
15小时前
|
Cloud Native API 开发者
构建未来:云原生架构在企业数字化转型中的关键角色
【5月更文挑战第9天】 随着企业加速迈向数字化时代,传统的IT架构已不足以支撑快速变化的市场需求。本文深入探讨了云原生架构如何成为推动企业敏捷性、可扩展性和创新能力的关键因素。通过分析微服务、容器化、持续集成与持续部署(CI/CD)等核心技术的实践应用,揭示了云原生技术如何助力企业实现真正的业务和技术一体化,以及在竞争激烈的市场中保持领先地位。
|
1天前
|
运维 负载均衡 关系型数据库
MySQL高可用解决方案演进:从主从复制到InnoDB Cluster架构
MySQL高可用解决方案演进:从主从复制到InnoDB Cluster架构
|
3天前
|
Kubernetes Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键角色
【5月更文挑战第7天】 随着企业加速数字化转型,云原生架构已成为推动创新和敏捷性的重要驱动力。本文将深入探讨云原生技术的基本原理,以及如何利用这些技术实现业务灵活性和响应速度的显著提升。通过分析微服务、容器化、持续集成/持续部署(CI/CD)等关键组件,我们将揭示云原生架构如何帮助企业应对快速变化的市场需求,同时确保系统的稳定性和可扩展性。
|
3天前
|
关系型数据库 MySQL 数据库
MySQL集群 双主架构(配置命令)
MySQL集群 双主架构(配置命令)
|
9天前
|
设计模式 Cloud Native 算法
拥抱变化:我的技术适应之旅构建未来:云原生架构在企业数字化转型中的关键角色
【4月更文挑战第30天】 在技术的浪潮中,我学会了不仅仅是编码,还有如何与时俱进。本文记录了我从一名初出茅庐的开发者成长为一个能够适应不断变化技术环境的工程师的心路历程。从最初的困惑与挑战到后来的接纳与创新,我意识到,技术能力的提升和心态的转变同样重要。
|
9天前
|
机器学习/深度学习 安全 网络安全
数字堡垒的构筑者:网络安全与信息安全的深层剖析构建高效微服务架构:后端开发的新趋势
【4月更文挑战第30天】在信息技术高速发展的今天,构建坚不可摧的数字堡垒已成为个人、企业乃至国家安全的重要组成部分。本文深入探讨网络安全漏洞的本质、加密技术的进展以及提升安全意识的必要性,旨在为读者提供全面的网络安全与信息安全知识框架。通过对网络攻防技术的解析和案例研究,我们揭示了防御策略的关键点,并强调了持续教育在塑造安全文化中的作用。
|
13天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在企业转型中的关键角色
【4月更文挑战第27天】 随着数字化转型的浪潮汹涌澎湃,企业亟需灵活、可扩展的技术基础来支撑其业务的快速发展。云原生架构,以其独特的设计理念和运行模式,为企业提供了一条创新的途径。本文将深入探讨云原生技术的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)等,并分析它们如何共同作用,推动企业实现敏捷开发和自动化运维。通过对这些技术的深度剖析,我们将揭示云原生架构如何在不断变化的市场环境中赋予企业竞争优势。
24 0
|
22天前
|
存储 负载均衡 容灾
架构设计|基于 raft-listener 实现实时同步的主备集群
本文介绍如何从数据库内核角度建立一套实时同步的主备集群,确保线上业务的高可用性和可靠性。本系统采用双 AZ 主备容灾机制,并要求数据与 schema 实时同步,同步时延平均在 1 秒内,p99 在 2 秒内。此外,系统支持高效的自动或手动主备切换,并能在切换过程中恢复丢失数据。
24 0
|
28天前
|
Cloud Native API 持续交付
构建未来:云原生架构在企业数字化转型中的关键角色
【4月更文挑战第12天】 随着企业加速其数字化转型的步伐,云原生架构已经成为推动创新和实现敏捷性的关键技术。本文将深入探讨云原生的概念、核心组件以及它如何为企业提供灵活性、可扩展性和更快的服务交付能力。通过分析案例研究和最新的行业趋势,我们将揭示如何利用云原生原则来构建和维护一个响应迅速、高度可用且成本效益高的IT环境。
|
29天前
|
消息中间件 大数据 Kafka
Kafka与大数据:消息队列在大数据架构中的关键角色
【4月更文挑战第7天】Apache Kafka是高性能的分布式消息队列,常用于大数据架构,作为实时数据管道汇聚各类数据,并确保数据有序传递。它同时也是数据分发枢纽,支持多消费者订阅,简化系统集成。Kafka作为流处理平台的一部分,允许实时数据处理,满足实时业务需求。在数据湖建设中,它是数据入湖的关键,负责数据汇集与整理。此外,Kafka提供弹性伸缩和容错保障,适用于微服务间的通信,并在数据治理与审计中发挥作用。总之,Kafka是现代大数据体系中的重要基础设施,助力企业高效利用数据。
37 1