ES架构设计:从单节点服务到百万节点 Elasticsearch 高可用集群系统架构设计

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: ES架构设计:从单节点服务到百万节点 Elasticsearch 高可用集群系统架构设计

Elasticsearch 高可用系统架构设计

高可用性即:High Availability(HA),高可用性是分布式系统架构设计的重要因素之一,简单来说,可用性越高的集群在发生意外情况(如断电、节点宕机)的时候,服务发生故障而不可用的可能性越低,也就是降低了意外情况而对整体服务产生的影响的可能性。


高可用性原理

  • ES使用数据分片(shard)来提高服务的可用性,将数据分散保存在不同的节点上以降低当单个节点发生故障时对数据完整性的影响,同时使用副本(repiica)来保证数据的完整性。关于分片的默认分配策略,在7.x之前,默认5个primary shard,每个primary shard默认分配一个replica,即5主1副,而7.x之后,默认1主1副
  • ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是,实际情况取决于集群拥有的分片和索引的数量以及它们的大小,不一定总是能均匀地分布。
  • Paimary只能在索引创建时配置数量,而replica可以在任何时间分配,并且primary支持读和写操作,而replica只支持客户端的读取操作,数据由es自动管理,从primary同步。
  • ES不允许Primary和它的Replica放在同一个节点中,并且同一个节点不接受完全相同的两个Replica
  • 同一个节点允许多个索引的分片同时存在。


ES的容错机制

容错性可以理解系统容忍的局部发生异常情况的比率和当异常发生时自行恢复的能力。在ES中表现为对节点宕机的处理机制。


步骤:

  1. Master选举:选出集群中的Leader。
  2. Replica容错:新的Active Master会将丢失的Primary的某个Replica提升为Primary。
  3. 重启故障机:Master尝试重启故障节点。
  4. 数据同步:Master将宕机期间丢失的数据同步到重启节点对应的分片上去,从而使服务恢复正常。


高可用性集群设计:

高可用性的中心思想就是采取一切可能的策略,降低集群中任意一部分节点出现问题后导致服务整体不可用的概率。其包含数据的完整性,集群的存活概率以及选主等。


小规模集群
  • 单节点集群:
    一般用于学习或者开发、测试环境,不推荐在生产环境中使用单节点集群。由于集群只有单个节点,为了适应这一点,ES默认会给集群分配所有角色。单节点角色不具备高可用性,并且无法分配副本分片。为了使集群保持健康,单节点模式下创建索引,需要使用index.number_of_replicas设置副本数量为0。


两节点集群:

  • 如果处于硬件成本考虑,集群中只允许有两个节点,那么一般来说最好把两个节点都设置成数据节点。还应该通过在每个不是可搜索快照索引的索引上设置index.number_of_replicas为 来确保每个分片都冗余存储在两个节点 1上。这是默认行为,但可能会被索引模板覆盖。Auto-expand replicas也可以达到同样的效果,但是在这么小的集群中没有必要使用这个功能。
  • 推荐在两个节点之一设置node.master: false明确告知其不具备候选节点资格。目的是为了确定哪个节点是主节点。集群可以容忍另一个不具备候选资格的节点的丢失。如果不做此设置,这时两个节点都会具有候选资格,但是其中一个节点如果宕机,由于选主需要票数过半(票数>N/2+1),也就是票数必须是两票才能选出active master,所以会导致无法选主。此时集群无法容忍任何一个节点宕机
  • 默认情况下,ES会为每个节点分配所有角色,如果手动分配角色,一般建议为每个节点分配所有角色,如果其中一个节点宕机,另一个节点可以取而代之。
  • 两个节点的集群,只允许其中一个固定的节点宕机,而不是任意一个节点。因为如果允许两个节点可以独立选举,那么如果集群由于网络或者其他原因导致节点连接断开,那么两个节点没办法确定另一个节点是否是宕机了,也就是会产生所谓的”脑裂“问题,而产生多主的情况。Elasticsearch 避免了这种情况并通过不选择任何一个节点作为主节点来保护您的数据,直到该节点可以确保它具有最新的集群状态并且集群中没有其他主节点。这可能导致集群在连接恢复之前没有主节点。


三节点集群:


  • 三节点部署:如果整个集群中所有节点一共只有三个,建议把三个节点全部部署为数据节点和候选节点。虽然active master节点一般只负责轻量级任务不做数据节点。但是通常来说三节点集群一般不会承载很大的业务量,也就不必考虑那么多了。这也是处于成本考虑不得已而为之。三节点集群的容错能力是1,即允许一台节点故障。
  • 二加一部署:即两个候选节点,一个仅投票节点,若干数据节点。这种配置的最大好处就是在保证高可用的前提下性价比更高,适用于小规模集群。由于在避免脑裂的前提下,要选举出主节点的最小节点数量是3,也就是选主的必要条件是票数过半也就是2票。而候选节点一般是不负责其他的任务的,也就不会为其分配data角色,那么集群通常会出现三个节点不存放数据的局面。此时会产生造成资源浪费。因为active master只存在一个,另外两个master作为候选节点,在及群众仅仅是充当了负载均衡器。为了避免这种资源浪费,通常的做法是把其中一个候选节点设置为仅投票节点,即node.roles: [ data, master, voting_only ],此时,当前节点在选举过程中,仅有选举权而没有被选举权,这样就可以同时给他分配数据节点的角色,因为其不会被选举为active master。三节点集群中,三个节点必须都具有master角色,并且仅投票节点最多只能有一个。仅投票节点由叫仲裁节点起着决胜票的作用。


多节点集群


  • 一旦集群增长到三个以上的节点,可以开始根据它们的职责对这些节点做职责专一化。主要根据需要配置尽可能多的数据节点、预处理节点、机器学习节点等来均衡工作负载。随着集群变大,一般建议给每个角色使用专用节点,以便为每个任务独立扩展资源。
  • 但是,最好将集群中候选节点数量限制为三个。主节点不像其他节点类型那样扩展,因为集群总是只选择其中之一作为集群的主节点。如果有太多候选节点,那么主选举可能需要更长的时间才能完成。在较大的集群中,一般建议把候选节点设置为专用候选节点,即不分配其他角色,并避免向这些专用节点发送任何客户端请求。以免候选节点被不必要的额外工作所拖累导致集群服务不稳定。
  • 但是可以把候选节点之一配置为仅投票节点以便它永远不会被选为主节点。例如,集群可能有两个专用的候选节点和一个既是数据节点又是仅投票的候选节点的第三个节点。这第三个仅投票节点将在Master选举中投出决胜票,但是自己永远不会被选举为active master。


大规模集群

单集群

  • 避免跨数据中心:ES对网络和宽带要求较高,并且一般来说要尽量避免服务跨多个数据中心。因为一旦遇到分区恢复问题,它必须重新同步任何丢失的数据并重新平衡集群。如果一定要跨多个数据中心,建议在每个数据中心部署独立集群,然后配置跨集群搜索或跨集群复制。
  • 部署分片分配感知:为了降低当集群出现单个或区域节点(比如一个机架)宕机对整个服务造成的影响,一般策略是通过分配感知来实现。


双区集群:

  • 如果集群部署在两个区域比如两个机房内,应该在每个区域中拥有不同数量的候选节点,这样在其中一个区域出现问题的时候,会增加另一个区域的存活概率。比如两个机房部署同一个集群,那么两个机房的候选节点避免相等,因为此时如果一个机房意外断电,两个机房的服务都会停止。配置单数投票节点可避免此问题。此时其中一个机房断电,服务可用的概率为50%。
  • 双区集群理论上能容忍一个区域的数据丢失,但不是任意一个区域,打个比方:服务部署在两个机房,机房A和机房B,要么是仅允许A机房出现故障而不允许B机房出现故障,也就是A机房断电服务可用,但是B机房断电服务中断;要么是仅允许B机房出现故障而不允许A机房出现故障,也就是B机房断电服务可用,但是A机房断电服务中断。从高可用的角度想,我们更希望任意一个机房断电,另一个机房的服务都不受影响,但是这是不可能的。因为没有断电的机房不知道出现故障的机房是断网了还是断电了,也就不知道应该是发起独立选举还是等待下去。如果两个机房都可以独立选主,那么就无法避免脑裂,可能会产生两个机房选出active master。解决办法是在两个区域中都配置一个仅投票节点并在独立的第三个区域添加一个额外的候选节点。这样两个区域其中之一断电,额外的投票节点就可以投出关键票。这个额外的节点也叫专用tiebreaker节点,此节点可以用低配服务器。


多区集群

  • 如果集群中有三个区域,那么每个区域中应该有一个候选节点。如果集群包含三个以上的区域,那么应该选择其中的三个区域,并在这三个区域中的每一个区域中放置一个候选节点。这意味着即使其中一个区域发生故障,集群仍然可以选举主节点。


多集群

  • Elasticsearch是主从结构,主节点能管理的节点上线一般不超过一千个,如果继续增加节点,可能会导致active master不稳定,如果集群想突破集群规模带来的性能瓶颈,一般可配置多集群,利用跨集群搜索单个超大集群拆分成多个小集群(相对小,千节点级别)来完成对集群的性能扩展。


总结
  • 集群应该至少有两个区域包含数据节点。
  • 除了主分片之外,每个 不是可搜索快照索引的索引都应该有每个主分片的至少一个副本。
  • 分片分配感知配置为避免将分片的所有副本集中在单个区域内。
  • 集群至少有三个候选节点。这些节点中至少有两个不是仅投票节点,均衡分配在至少三个区域中。
  • 客户端被配置为将其请求发送到多个区域中的节点,或者被配置为使用负载平衡器来平衡一组适当的节点之间的请求。所述弹性云服务提供了这样的负载平衡器。
相关实践学习
使用阿里云Elasticsearch体验信息检索加速
通过创建登录阿里云Elasticsearch集群,使用DataWorks将MySQL数据同步至Elasticsearch,体验多条件检索效果,简单展示数据同步和信息检索加速的过程和操作。
ElasticSearch 入门精讲
ElasticSearch是一个开源的、基于Lucene的、分布式、高扩展、高实时的搜索与数据分析引擎。根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr(也是基于Lucene)。 ElasticSearch的实现原理主要分为以下几个步骤: 用户将数据提交到Elastic Search 数据库中 通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据 当用户搜索数据时候,再根据权重将结果排名、打分 将返回结果呈现给用户 Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索,具有接近实时的搜索,并支持多租户。
相关文章
|
3天前
|
数据挖掘 关系型数据库 MySQL
Serverless高可用架构的解决方案体验
Serverless高可用架构的解决方案体验
38 6
|
5天前
|
弹性计算 运维 关系型数据库
Serverless高可用架构解决方案评测
Serverless高可用架构方案提供卓越效能与极简运维体验,支持服务托管、弹性伸缩及按量付费,有效降低成本并优化性能。一键部署快速启动,流程直观,文档详实;但在高级配置与特定场景实践方面指导有限。方案采用双可用区部署确保高可用性,自动故障切换保障服务连续。成本模型按需计费,减轻企业负担。功能上集成监控、日志与负载均衡,简化运维,加速上线。性能方面,秒级弹性伸缩保证资源高效匹配负载。总体而言,此方案竞争力强,特别推荐给初创公司及需灵活应对流量波动的场景。
51 2
|
5天前
|
运维 监控 负载均衡
如何构建高可用的系统基础架构
【8月更文挑战第15天】构建高可用的系统基础架构是一个复杂而系统的工程,需要综合考虑设计原则、关键技术和实践策略等多个方面。通过冗余设计、分布式架构、自动化与智能化等技术的运用,可以显著提升系统的可用性和稳定性。同时,加强运维团队的能力建设和制定完善的高可用性策略也是确保系统高可用性的重要保障。希望本文能为读者在构建高可用系统时提供有益的参考和借鉴。
|
5天前
|
弹性计算 运维 关系型数据库
云上Serverless高可用架构一键部署体验与测评
在数字化转型背景下,Serverless架构因其实现业务敏捷、降低成本及提升服务可靠性而备受青睐。本文以阿里云Serverless应用引擎(SAE)为核心,展示了一种高可用、低成本且易于扩展的解决方案。通过单地域双可用区部署,构建了具备自动伸缩与故障恢复能力的架构。借助阿里云的一键部署功能,大幅简化了搭建流程,实现了快速部署,并通过性能与成本分析验证了其优势。对比传统ECS,SAE在资源利用与运维效率上表现更佳,特别适合平均负载较低的应用场景。
|
13天前
|
关系型数据库 Serverless 分布式数据库
Serverless高可用架构
PolarDB在《Serverless高可用架构》中展现了零代码改造、极简易用与自适应弹性的特性,提供按需伸缩与计费服务。相比传统架构,它能自动调整资源满足不同负载需求。阿里云Serverless服务简化了开发者的工作流程,让用户专注业务创新。为了优化用户体验,可通过提供最佳实践、深化文档内容、增强社区支持等方式进一步提升。PolarDB不仅降低了迁移难度,还简化了数据库管理,确保资源高效利用,是企业数字化转型的关键技术支撑。
|
5天前
|
自然语言处理 Java 索引
ElasticSearch 实现分词全文检索 - Java SpringBoot ES 文档操作
ElasticSearch 实现分词全文检索 - Java SpringBoot ES 文档操作
7 0
|
5天前
|
自然语言处理 Java 索引
ElasticSearch 实现分词全文检索 - Java SpringBoot ES 索引操作
ElasticSearch 实现分词全文检索 - Java SpringBoot ES 索引操作
15 0
|
5天前
|
自然语言处理 Docker 容器
ElasticSearch 实现分词全文检索 - ES、Kibana、IK分词器安装
ElasticSearch 实现分词全文检索 - ES、Kibana、IK分词器安装
10 0
|
12天前
|
存储 安全 Java
[elasticsearch]部署安装单节点和集群
[elasticsearch]部署安装单节点和集群
|
3天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。