腾讯云Elasticsearch集群多可用区容灾实现原理及最佳实践

标签: 腾讯云 elasticsearch 集群 | 发表时间:2021-05-07 04:06 | 作者:云加社区
出处:https://www.infoq.cn

引言

目前腾讯云 ES 集群可以支持双可用区及三可用区的集群部署,且支持单可用区平滑升级到多可用区集群。当一个可用区出现故障时,剩余可用区依然能够保障集群的稳定性、服务的可用性和数据的完整性。

数据节点

当客户选择了跨多可用区的集群架构部署时,集群的数据节点必须是多可用区的倍数,如客户选择的是三可用区部署,则数据节点个数应为 3,6,9,12 等,以此类推。

如上图 1 所示,我们在上海地域选择了三可用区集群的部署,数据节点数量选择 6 个。ES 会自动将 6 个数据节点均衡得分布在三个可用区中,并对每个节点标记上可用区属性,从而可以通过可用区感知功能将索引的分片自动分布在多可用区中,集群中节点的具体分布情况如图 2 所示。

从图 2 中我们可以看到,腾讯云 ES 提供了 VPC 内的负载均衡功能,客户可以直接通过 VIP 连接集群,由于 VIP 下绑定了集群内部的所有数据节点,因此客户所有的读写请求会均衡的分布到各个数据节点上。

另外该 VIP 还自带健康检查功能,如一个周期内多次检测到某节点未响应,健康检查功能则会暂时从该 VIP 的路由列表中摘除该异常节点,直到节点恢复正常。这样就保障了当一个节点宕机或者某一个可用区不可用的情况下,客户端依然能够无感知的请求集群。

专用主节点

为了保障集群的稳定性和高可用性,当选择多可用区集群架构部署时,需强制设置三个专用主节点。其中专用主节点的分布机制如下:

当选择三可用区部署时,会在每个可用区部署一个专用主节点,从而保障任何一个可用区不可用时,依然能够选出 Master 节点;当选择双可用区部署时,为了避免出现一个可用区上分布两个专用主节点且出现“该可用区不可用”导致选不出 Master 节点的情况,腾讯云 ES 会选择一个隐藏可用区用来专门部署专用主节点,如下图 3 所示。

索引副本分片

为了保障在一个可用区不可用的情况下,依然能够保证数据的完整性和服务的可用性,索引分片至少设置 1 副本。如果选择三可用区部署,当两个可用区不可用时,希望剩下的可用区依然能够完整提供服务,则索引的副本个数至少为 2 个。

ES多可用区架构部署实现机制

腾讯云 ES 多可用区集群部署依赖于 ES 提供的节点属性感知 awareness [1] 功能。通过对每个节点进行属性标记,即对节点进行可用区的属性标记:"node.attr.zone_id:shanghai-3"。

该属性配置在 elasticsearch.yml 文件中(也可以选择在启动节点时进行参数指定:"./bin/elasticsearch -Enode.attr.zone_id=shanghai-3"),设置完节点属性后,腾讯云 ES 集群通过设置如下参数:"cluster.routing.allocation.awareness.attributes=zone_id" 来让集群在分片分配中使用节点属性执行分配策略。

这样 ES 就可以通过可用区 zone_id 属性将节点进行分类。且将索引的主副本分片分布到属性 zone_id 不同的节点上。

例如,我们创建了一个具有 4 个数据节点的双可用区的集群,分别部署在上海 3 区和上海 4 区。那么上海 3 区的节点属性为: "node.attr.zone_id:shanghai-3",上海 4 区的节点属性为: "node.attr.zone_id:shanghai-4"。

当我们创建一个索引,该索引有 5 个主分片和 1 个副本分片,那么所有的主分片和对应的副本分片都会均衡的分布在上海 3 区和 4 区上,而不会出现主分片和副本分片同时分布在上海 3 区或者上海 4 区的情况。

需要注意的是:这时候如果有一个可用区挂掉,如上海 3 区整体不可用,ES 会将上海 3 区的主副本分片在上海 4 区进行重建。即这时候会出现主副本分片同时分配在同一个可用区的情况。

为了防止某一个可用区不可用,导致另一个可用区磁盘容量被重建的分片大量耗尽的情况,腾讯云 ES 启用了分片强制感知 (force awareness) 的功能。

腾讯云 ES 通知设置如下参数:cluster.routing.allocation.awareness.force.zone_id.values=shanghai-3,shanghai-4,从而保证了在一个可用区不可用时,不会使得剩余的可用区磁盘资源不足的情况。

单可用区平滑升级多可用区

前文图 1 演示了在腾讯云 ES 控制台购买多可用区集群的操作步骤。对于存量的单可用区集群,腾讯云 ES 同样支持平滑升级到多可用区的部署架构。具体操作如下图 4 所示:

这里需要注意以下几点:

当选择了升级到多可用区时,只能设置新的可用区信息,不可更改节点配置和磁盘容量;当升级到双可用区时,数据节点数量自动翻倍;当升级到三可用区时,数据节点数量自动乘三倍;当从双可用区升级到三可用区时,数据节点数量自动乘 1.5 倍;如果原集群未设置专用主节点,则会强制选择设置 3 个专用主节点;如果原集群设置了专用主节点,则节点数量不变,腾讯云 ES 会自动完成专用主节点在各可用区之间的调度和分布。

单可用区升级到多可用区的变配流程最大的难点和挑战在于专用主节点的协调上。下面重点介绍腾讯云 ES 在处理可用区升级方案中专用主节点的实现机制:

为了下图说明方便,我们先对各类型节点使用不同颜色进行标记:

普通节点:包含 master、data、ingest 等所有属性,节点上存储索引数据,使用蓝色标记。

专用主节点:只包含 master 属性,在集群中属于专用主节点,不存储索引数据,只负责管理集群和存储集群的元数据信息,使用粉红色标记。

数据节点:只包含 data、ingest 属性,一般用于具有专用主节点的场景,该节点上存储索引数据,通常也被称为专有数据节点,使用绿色标记。

单可用区升级到多可用区场景分析:

(1)原单可用区集群没有专用主节点:

如果原单可用区集群没有设置专用主节点,这种情况下无论是升级到双可用区还是三可用区都是比较简单的。

升级变配流程如上图 5 所示:

在新增的可用区中申请创建并加入普通节点以及在每个可用区中各加入一个专用主节点(如果是升级到双可用区,则会在隐藏可用区加入一个专用主节点);修改各可用区中普通节点的属性为专有数据节点,即上图中将蓝色变更为绿色。

在流程的第 2 步修改节点属性时,每重启一个节点,min_master_node 都会重新计算并设定,避免在中间状态发生脑裂。

(2)原单可用区集群已设置专用主节点:

如果原单可用区集群中已经设置了 3 个专用主节点,那么按照最终的状态来看,应该是每个可用区都会均衡分布一个专用主节点。

自然想到的流程是先在新增的可用区中各加入一个专用主节点,然后再将原可用区中的多余两个专用主节点下线即可。如下图 6 所示:

具体流程步骤如下:

在新增的可用区中加入数据节点及一个专用主节点(如果是升级到双可用区,则只需要在隐藏可用区申请加入一个专用主节点即可);将原单可用区中多出的两个专用主节点下线。

但是这种升级变配流程存在一个隐藏的集群不可用风险。如图 7 所示:

从图 6 的第一个流程上我们再结合图 7 可以看到,如果在中间状态原单可用区突然发生不可用,那便会出现剩余的可用区中只剩下 2 个专用主节点,这时候从 5 个专主变成了 2 个专用主节点,便会出现选不出 Master 节点的情况,从而使得集群整体不可用,违背了跨可用区的容灾初衷。

为了规避上面分析的这种异常风险,我们对图 6 的第 1 个流程的中间状态做了优化,如下图 8 所示:

具体流程如下:

在新增的可用区中加入数据节点及两个专用主节点(如果是升级到双可用区,则只需要在隐藏可用区申请加入两个专用主节点即可);将原单可用区中多出的两个专用主节点和新增的可用区中多出的一个专用主节点下线。

这样便可保证即使在流程一的中间状态下任何一个可用区不可用,依然不影响剩余专用主节点选出 Master 节点。从而保障了集群的高可用性。

结语

本篇文章我们详细介绍和分析了腾讯云 ES 集群多可用区容灾的实现原理和操作实践。并重点介绍了单可用区集群升级到多可用区的几种场景及具体流程细节,希望能够帮助到腾讯云 ES 的客户朋友们。

头图:Unsplash

作者:吴容

原文:https://mp.weixin.qq.com/s/7VzmoK4ZsVfnJflEs_B9tA

原文:腾讯云Elasticsearch集群多可用区容灾实现原理及最佳实践

来源:云加社区 - 微信公众号 [ID:QcloudCommunity]

转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

相关 [腾讯云 elasticsearch 集群] 推荐:

腾讯云Elasticsearch集群多可用区容灾实现原理及最佳实践

- - InfoQ推荐
目前腾讯云 ES 集群可以支持双可用区及三可用区的集群部署,且支持单可用区平滑升级到多可用区集群. 当一个可用区出现故障时,剩余可用区依然能够保障集群的稳定性、服务的可用性和数据的完整性. 当客户选择了跨多可用区的集群架构部署时,集群的数据节点必须是多可用区的倍数,如客户选择的是三可用区部署,则数据节点个数应为 3,6,9,12 等,以此类推.

elasticsearch集群搭建

- - zzm
之前对于CDN的日志处理模型是从 . logstash agent==>>redis==>>logstash index==>>elasticsearch==>>kibana3,对于elasticsearch集群搭建,可以把索引进行分片存储,一个索引可以分成若干个片,分别存储到集群里面,而对于集群里面的负载均衡,副本分配,索引动态均衡(根据节点的增加或者减少)都是elasticsearch自己内部完成的,一有情况就会重新进行分配.

Elasticsearch集群入门

- - 编程语言 - ITeye博客
欢迎来到Elasticsearch的奇妙世界,它是优秀的全文检索和分析引擎. 不管你对Elasticsearch和全文检索有没有经验,都不要紧. 我们希望你可以通过这本书,学习并扩展Elasticsearch的知识. 由于这本书也是为初学者准备的,我们决定先简单介绍一般性的全文检索概念,接着再简要概述Elasticsearch.

elasticsearch 1.x集群优化

- - ITeye博客
欢迎发送邮件至 [email protected]. 本博文为 Elasticsearch Server2nd的部分第7章部分章节的翻译,版权归原作者. 设置Filter cache. 缓存是提高性能的很重要的手段,es中的filter cache能够把搜索时的filter条件的结果进行缓存,当进行相同的filter搜索时(query不同,filter条件相同),es能够很快的返回结果.

elasticsearch集群监控工具bigdesk

- - zzm
bigdesk是elasticsearch的一个集群监控工具,可以通过它来查看es集群的各种状态,如:cpu、内存使用情况,索引数据、搜索情况,http连接数等. 项目git地址:  https://github.com/lukas-vlcek/bigdesk. 和head一样,它也是个独立的网页程序,使用方式和head一样.

Elasticsearch集群的脑裂问题

- - 互联网 - ITeye博客
所谓脑裂问题(类似于精神分裂),就是同一个集群中的不同节点,对于集群的状态有了不一样的理解. 今天,Elasticsearch集群出现了查询极端缓慢的情况,通过以下命令查看集群状态:. 发现,集群的总体状态是red,本来9个节点的集群,在结果中只显示了4个;但是,将请求发向不同的节点之后,我却发现即使是总体状态是red的,但是可用的节点数量却不一致.

ElasticSearch-2.0.0集群安装配置与API使用实践

- - 简单之美
ElasticSearch是基于全文搜索引擎库Lucene构建的分布式搜索引擎,我们可以直接使用ElasticSearch实现分布式搜索系统的搭建与使用,都知道,Lucene只是一个搜索框架,它提供了搜索引擎操作的基本API,如果要实现一个能够使用的搜索引擎系统,还需要自己基于Lucene的API去实现,工作量很大,而且还需要很好地掌握Lucene的底层实现原理.

基于docker环境实现Elasticsearch 集群环境

- - 学习日志
最近搭建了es集群的时候,现在需要测试添加一个新的数据节点,项目是使用docker-compose命令来搭建的. 以下基于最新版本 es7.2.0进行. // docker-compose.yaml 集群配置文件. 集群配置了3个master节点,并同时作为数据节点使用,当节点未指定 node.master和node.data的时候,默认值为 true.

Elasticsearch 集群规模和容量规划的底层逻辑

- - IT瘾-dev
问题 1:请问下大家是如何评估集群的规模. 比如数据量达到百万,千万,亿万,分别需要什么级别的集群,这要怎么评估. ps:自己搭建的测试环境很难达到这一级别. 问题 3:我看了很多文章关于 es 集群规划的文章,总感觉乱七八糟的,没有一个统一的规划思路. 如何根据硬件条件和数据量来规划集群,设置多少节点,每个节点规划多少分片和副本.

我在 Elasticsearch 集群内应该设置多少个分片?

- -
Elasticsearch 是一个功能十分丰富的平台,支持各种用例,能够在数据整理和复制战略方面提供很大的灵活性. 然而这一灵活性有时也会带来困扰,让您在前期难以确定如何最好地将数据整理为索引和分片,如果您刚上手使用 Elastic Stack,这一点可能更明显. 如果未能做出最佳选择,尽管这在开始的时候可能不会造成问题,但随着数据量越来越大,便有可能会引发性能问题.