es部署--生产环境--9.1--跨机房灾备--介绍

最新推荐文章于 2024-08-25 22:03:06 发布

勤径苦舟

最新推荐文章于 2024-08-25 22:03:06 发布

阅读量1k

点赞数 10

分类专栏： elasticsearch 文章标签： elasticsearch 大数据搜索引擎

本文链接：https://blog.csdn.net/zhou920786312/article/details/141535851

版权

elasticsearch 专栏收录该内容

29 篇文章 4 订阅

订阅专栏

es部署–生产环境–9.1–跨机房灾备–介绍

1、为什么要跨机房灾备

确保在某个机房不可用时，还能持续对外提供业务。
本质是机房级别的高可用

2、常见的灾备方案

在这里插入图片描述

3、灾备方案–定期快照

Elasticsearch提供快照和恢复功能，我们可以在远程文件系统中为部分索引或者整个集群创建快照。
远程文件系统
- 共享文件系统
- S3
- HDFS

3.1、快照使用场景

3.1.1、数据灾备

当发生误删索引数据的情况时，可以使用快照来还原；
在主集群无法正常工作时，可以使用快照在备集群上恢复数据。

3.1.2、归档数据

随着数据的积累，集群中磁盘存储的压力会越来越大，对于一些时效性高的数据，比如日志、指标，我们往往只关心最近一段时间内的数据。对于时间比较早的数据，我们可以选择以快照的形式归档，以备后续有查询的需求。
从Elasticsearch 7.10版本开始我们还可以结合ILM索引生命周期管理，在Cold和Frozen数据层使用可搜索快照进一步降低存储成本。

3.1.3、迁移数据

当需要将数据从一个集群迁移到另一个集群时，使用快照是一种高效的选择。

3.1、使用快照的方式做跨机房灾备的优点

一致性高，快照是十分可靠的集群备份方式。
成本低，可以使用廉价的存储来保存快照，例如在公有云上的 S3，OSS，GCS 等等。
只要可以访问到外部文件系统中存储的快照数据，即使在主集群和备集群都崩溃的情况下，仍然通过快照将数据恢复到新集群中。

3.2、快照方法的主要缺点如下：

数据无法实时备份，通过快照恢复时，延迟可能导致数据丢失。例如，如果用户指定每 5 分钟执行一次快照备份，则正在备份的数据始终会延迟 5 分钟。如果在执行最后一个快照 4 分钟后集群出现故障，则这 4 分钟的数据将完全丢失。
快照无法实时进行恢复，当主集群不可用时，需要手动在备集群上使用快照恢复数据，在这期间将无法对外提供服务。

4、灾备方案–跨机房部署集群

部署实现比较简单，就是将集群中的节点分布在不同的机房中
对网络带宽和延迟要求较高，仅适用于同城灾备
异地灾备通常还是使用主备集群的方式

4.1、注意点

确保同一个索引主分片和副分片分布在不同的机房中，这样当某一个机房挂掉后另外一个机房仍然保留完整的数据，数据仍然可靠。

4.2、案例：腾讯云Elasticsearch集群多可用区容灾实现

4.2.1、介绍

在上海地域选择了三可用区集群的部署，数据节点数量6个。
Elasticsearch 会自动 6个数据节点均衡地分布在三个可用区中，并对每个节点标记上可用区属性，从而可以通过可用区感知功能将索引的分片自动分布在多可用区中。

在这里插入图片描述

4.2.2、客户端通过 VIP 连接集群

由于 VIP 下绑定了集群内部的所有数据节点，因此客户端所有的读写请求会均衡的分布到各个数据节点上。

在这里插入图片描述

4.2.3、为了保障集群的稳定性和高可用性，当选择多可用区集群架构部署时，需强制设置三个专用主节点。

其中专用主节点的分布机制如下：

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

在这里插入图片描述

5、灾备方案–CCR 跨集群复制

Elasticsearch 6.7 版本中引入跨集群复制(CCR, Cross-Cluster Replication)功能，支持将指定的索引从一个 Elasticsearch集群复制到一个或多个 Elasticsearch集群。
跨集群复制属于Elastic Stack 的白金版(PLATINUM)付费功能，需要额外付费才可以使用

在这里插入图片描述

5.1、跨集群复制使用主动-被动模型(active-passive model)

复制更改的索引称为追随者索引(follower Index)，被复制的索引称为领导者索引(leader index)。
当leader index收到写入时，follower index会从远程集群上的leader index上基于文档操作实现订阅复制。
follower index是被动的，它可以服务于读取请求，但不能接受写入请求，只有leader index可以接受写入请求。
当配置复制规则时
- 可以指定特定的索引进行复制；
- 也可以通过auto-follow pattern以通配符的形式自动匹配多个索引，创建复制规则后新创建的索引也会自动匹配。

在这里插入图片描述

5.2、CCR 跨集群复制问题

当主集群发生宕机时，如果我们想让在备集群中的follower index接管服务，允许进行写入请求，需要依次暂停索引的复制，关闭索引，取消跟随leader index，最后将其重新打开为普通的索引，整套操作下来非常复杂，而且无法进行回切，这也是 CCR 跨集群复制最大的一个问题。

5.3、CCR 跨集群复制问题–解决方案

使用双向复制(CCR bi-directional replication)。
在这里插入图片描述

在集群cluster01上创建索引logs-cluster01，并在集群cluster02上复制该索引；
在集群cluster02上创建索引logs-cluster02，并在集群cluster01上复制该索引。
然后在两个集群上创建别名logs指向索引logs-cluster01和logs-cluster02，对外可以提供统一的索引名。
别名指向的多个索引中，只能有一个索引是允许接收写入请求的
1. 在cluster01将索引logs-cluster01设置为可写，logs-cluster02索引中的数据将会通过 CCR 跨集群复制从集群cluster02中获取；
2. 集群cluster02的别名设置相反。
通过以上设置，应用程序在读写的时候都往logs别名发送请求
1. 当集群cluster01不可用时，我们可以继续使用集群 cluster02，并且依然是往logs别名发送请求，无需手动进行切换操作；
2. 当集群cluster01恢复后，会从上次记录的checkpoint继续从集群cluster02复制数据，也无需额外的切换操作。

5.4、双机房部署的一个整体架构图

在这里插入图片描述

在两个机房以双活的形式各部署一套Elasticsearch集群，同时对外提供服务，两个Elasticsearch集群配置 CCR双向复制。
机房之间的网络通过专线打通，用于承载 CC 跨集群复制以及业务应用跨机房访问 Elasticsearch集群的流量。
业务应用的读写请求优先访问本机房的Elasticsearch集群，当本机房的集群出现不可用时，访问备机房的Elasticsearch集群。
在公网部署一套智能DNS服务，根据用户的 IP地址将域名解析到邻近用户机房的公网IP，当整个机房出现故障时，才将域名解析到备机房的公网IP。

6、应用双写

就是应用程序直接将数据同时写入两个 Elasticsearch 集群

在这里插入图片描述

6.1、缺点(比较明显)

一致性差，应用双写并非原子操作，假设上海机房的Elasticsearch 集群写成功了，然而北京机房的Elasticsearch集群没写成功，将造成两个集群的数据不一致。
假设北京机房的Elasticsearch 集群宕机了，过一段时间集群又恢复了，在故障期间的数据将会丢失。
每次写入请求都要跨机房处理，将会增加网络延迟。

7、借助消息队列实现双写

是应用双写方案的改进版
消息队列： Kafka，Pulsar

7.1、原理

在这里插入图片描述

应用程序优先将数据写入本机房的消息队列，当本机房的消息队列不可用时，才通过专线写入备机房的消息队列
应用程序在查询数据的时候优先访问本机房的 Elasticsearch 集群，当本机房的集群不可用时，才访问备机房的 Elasticsearch 集群。
两个机房消息队列间的数据通过消息队列的跨集群复制保持最终一致。
在下游通过消费者程序消费本机房消息队列中的数据，然后写入Elasticsearch 集群中，
- 当Elasticsearch 集群数据写入失败或者宕机时，消费者程序要有相应的重试或者异常处理机制。
- 当消费者程序挂掉时，数据会暂停写入Elasticsearch集群，消息队列会有offset记录消费者程序消费的进度，当消费者程序恢复后，可以从上一次的 offset 继续消费消息。