ES容灾技术探讨和测试

Elasticsearch | 作者 yangmf2040 | 发布于2021年10月27日 | | 阅读数:1043

ES灾备技术调研

早就听说极限网关了,最近有个ES要做灾备,就搜集了下技术方案:

  1. 应用双写两个集群

  2. 跨集群复制CCR

  3. 极限网关

三个方案的优缺点我也简单整理了下:

  1. 优点:自主研发,想怎样就怎样;缺点:难,水平、时间都是成本

  2. 优点:实施简单;缺点:需要license

  3. 优点:部署灵活,功能齐全;缺点:不熟悉,没用过

貌似方案 3,比较理想。不熟悉,那就多用用,测试测试找找感觉。

测试环境 笔记本

主集群:A 7.14.1 10.0.2.15:9214 Rbac+tls 节点数:1
备集群:B 7.13.2 10.0.2.15:9213 Rbac+tls 节点数:2
极限网关 1.3.0 0.0.0.0:8000 tls 实例数:1

wpsF088.tmp_.jpg

wpsF089.tmp_.jpg

网关下载

先下载极限网关:https://release.www.ksh17j.com/gateway/snapshot/

解压后,可看到有几个预定义的配置,方便大家快速上车。

wpsF08A.tmp_.jpg

网关配置

这次是做灾备,应该就是在 dc-replica.yml的基础上改比较妥当,配置还是比较多的 300多行,很多都是为了保证两个集群数据一致性,解耦啥的做的判断和写队列之类的设置。我只修改了 elasticsearch资源的定义信息,还有网关也可选择tls,不用手工生成证书,非常方便。

贴下我修改的地方

wpsF08B.tmp_.jpg

wpsF08C.tmp_.jpg

启动网关

wpsF08D.tmp_.jpg

两个集群都是 available ,说明连接应该ok

测试场景:围绕主备集群之间数据复制展开

1. 主备集群间复制创建、写入、删除索引操作

目的:对网关(A集群)创建索引test,对test索引写文档,能自动同步到B集群

初始情况A、B无test

wpsF09E.tmp_.jpg
wpsF09F.tmp_.jpg

手工put test索引到网关

wpsF0A0.tmp_.jpg
wpsF0A1.tmp_.jpg
wpsF0A2.tmp_.jpg
A,B集群都创建成功

用loadgen写点文档进去吧,loadgen直接写网关

wpsF0A3.tmp_.jpg

wpsF0A4.tmp_.jpg

wpsF0A5.tmp_.jpg

都10000条写入成功,如果查看是0的话,先refresh下索引

看下文档

wpsF0A6.tmp_.jpg

简单校验一下

wpsF0A7.tmp_.jpg

wpsF0A8.tmp_.jpg

感觉没问题,删点文档看看,把那23个删了吧

wpsF0A9.tmp_.jpg

再看看

wpsF0AA.tmp_.jpg

wpsF0BA.tmp_.jpg

更新524个文档看看

wpsF0BB.tmp_.jpg

wpsF0BC.tmp_.jpg

wpsF0BD.tmp_.jpg

增、删、改 完事

2. 主集群故障的处理和恢复

目的:主集群故障后,网关如何处理收到的请求:读、写

Kill 掉 A 集群,模拟主集群故障

网关直接有报错说连不上A集群

此时对网关查询、写入数据都会报错

wpsF0BE.tmp_.jpg

重新启动主集群后,一切正常

3. 备集群故障的处理和恢复

目的:备集群故障,读、写主集群不受影响,备集群恢复后,自动追数据直到两边数据一致

Kill 掉B集群,网关报错,B集群无法连接

wpsF0BF.tmp_.jpg

对A集群进行写入一个新文档,并查询下

wpsF0C0.tmp_.jpg

wpsF0C1.tmp_.jpg

启动B集群,查看,已自动添加了新的文档

wpsF0C2.tmp_.jpg

4. 主集群容灾切换

目的:主集群故障,短时间不可用,网关切换指向备集群作为主集群,A集群作为备集群;待A集群恢复后,自动追数据

KILL A 集群 模拟A集群故障

Kill 网关,切换配置:

wpsF0C3.tmp_.jpg

启动网关,B是主了,available

wpsF0C4.tmp_.jpg

写B集群,删除前面创建的 test 索引,新建test2索引,并插入文档

wpsF0C5.tmp_.jpg

wpsF0D6.tmp_.jpg

启动A集群,检查数据,有test2索引,且文档一致

wpsF0D7.tmp_.jpg

5. 主集群故障恢复后,网关回切

目的:假设A集群已经完全恢复,网关回切,A集群为主,B集群为备

Kill网关,恢复配置,再启动网关

再次测试写入test2 检查能否同步成功

写网关

wpsF0D8.tmp_.jpg

查看A集群

wpsF0D9.tmp_.jpg

查看B集群

wpsF0DA.tmp_.jpg

两个集群数据一致,主备角色也恢复到最初了

**测试环境变更

中间工作比较忙,中断了测试,也就十来天吧

不成想 网关更新了,我就下了新版本的gateway和ES-7.15.1 继续捣鼓

环境 笔记本

主集群:es-751primary 7.15.1 10.0.2.15:7151 No:Rbac、tls 节点数:1
备集群:es-751backup 7.15.1 10.0.2.15:7152 No:Rbac、tls 节点数:1
极限网关 场景6:1.4.0场景7:1.5.0 0.0.0.0:8000 No:tls 实例数:1

wpsF0DB.tmp_.jpg

网关不光版本升级了,配置文件也稍稍有些变化,新版本示例配置如下

wpsF0DC.tmp_.jpg

本着不会就猜的原则,我还是能做到见名之知意的

我仅仅对 cross-cluster-replication.yml 做了简单的修改,就是和前面一样

6. ES由代理暴露的能否正常工作

目的:检验,比如由nginx代理ES的时候,网关能否正常工作

使用 nginx 代理后端的ES

80-->primary

81-->backup

wpsF0DD.tmp_.jpg

测试下反向代理工作是否正常

wpsF0DE.tmp_.jpg

启动网关,网关里elasticsearch资源指向nginx,没错就改了下 url

wpsF0DF.tmp_.jpg

开始测试,增删改查 once more,还是对着网关操作

创建索引

wpsF0E0.tmp_.jpg

PUT 文档

wpsF0F0.tmp_.jpg

抄家伙

wpsF0F1.tmp_.jpg

看看数量

wpsF0F2.tmp_.jpg

简单对比下

wpsF0F3.tmp_.jpg
给 code为500的文档增加一个字段 new_field

wpsF0F4.tmp_.jpg

直接通过代理查询,检验数据

wpsF0F5.tmp_.jpg

没问题,测试删除

删除单条

wpsF0F6.tmp_.jpg

wpsF0F7.tmp_.jpg

wpsF0F8.tmp_.jpg

批量删除

wpsF0F9.tmp_.jpg

看看结果

wpsF0FA.tmp_.jpg

删除索引,并确认真的删除

wpsF10B.tmp_.jpg

关调backup集群,然后primary集群创建索引后,再启动backup集群,看能否自动追平

wpsF10C.tmp_.jpg

创建test2索引

wpsF10D.tmp_.jpg

顺手put个文档

wpsF10E.tmp_.jpg

Primary上查看

wpsF10F.tmp_.jpg

OK 启动backup

wpsF110.tmp_.jpg

妈的 奇迹

7. 请求压缩功能如何

目的:看看客户端和网关分别在不同的请求压缩配置下,是否工作正常

在网关的配置中,看到了 compress 压缩,也设计几个场景测试下

网关配置里面有个压缩的配置,意思是消费线程往ES发送请求的时候是否启用gzip压缩。

默认是 true

wpsF111.tmp_.jpg

7.1 用压缩的方式写网关,但网关不启用压缩

我们把网关配置中的true改成false

wpsF112.tmp_.jpg

启动网关

wpsF113.tmp_.jpg

开始写数据,写的过程中,随机停止backup集群,等待一会儿后再启动

wpsF114.tmp_.jpg

网关可看到 backup集群,从不可用到可用

wpsF115.tmp_.jpg

看看网关的队列情况,这时候backup队列应该堆积了不少请求

wpsF116.tmp_.jpg

等待队列被消费完后,我们对比数据。

wpsF117.tmp_.jpg

简单看看文档条数

wpsF128.tmp_.jpg

wpsF129.tmp_.jpg

用网关对比下数据看看

wpsF12A.tmp_.jpg

妥妥的一致

7.2 用压缩的方式写网关,网关也启用压缩

就把前面网关贴图的false改成true

启动网关

wpsF12B.tmp_.jpg

压缩写入

wpsF12C.tmp_.jpg

写入过程中,随机重启backup集群

网关日志

wpsF12D.tmp_.jpg

等待网关backup队列消费完毕,后对比数据

wpsF12E.tmp_.jpg

wpsF12F.tmp_.jpg

没得问题,下一场

7.3 用不压缩的方式写网关,网关也不启用压缩

网关配置compress: false,后启动网关

wpsF130.tmp_.jpg

不压缩请求

wpsF131.tmp_.jpg

中途随机重启backup集群

wpsF132.tmp_.jpg

队列消费完后对比数据

wpsF133.tmp_.jpg

数据一致

7.4 用不压缩的方式写网关,网关backup队列的消费线程使用压缩

wpsF134.tmp_.jpg

写入过程中,停止backup集群,稍等一会儿后启动backup集群

wpsF135.tmp_.jpg

观察网关的backup 队列情况

wpsF145.tmp_.jpg

等消费完之后,我们对比数据

数量一致

wpsF146.tmp_.jpg

wpsF147.tmp_.jpg

用网关来对比下两个集群的test索引的数据

wpsF148.tmp_.jpg

至此,关于跨集群复制的场景测试可以告一段落了,功能大家也看到了确实强大,部署也很灵活,对环境无侵入,直接把应用连接ES的地址、端口改下就行。或者网关直接监听9200端口,替换原有的协调节点,应用无感知。

此外,极限网关还有很多别的使用场景和激动人心的功能,像在线修改查询、请求限流、请求流量分析,这都是保障ES集群稳定运行的手段。

看到一款国产软件如此强大很欣慰,很激动。希望各位感兴趣的小伙伴也下载测试下自己的场景,我们ES圈(论坛)多交流交流。让我也看看你们的场景和测试是怎样的。

最后一个图,我也不知道咋回事,请忽略。

wps95F7.tmp_.jpg

[尊重社区原创,转载请保留或注明出处]
本文地址:https://www.ksh17j.com/article/14396


3 个评论

我使用gateway-1.3.0_SNAPSHOT-22-mac-amd64.tar.gz这个包进行主备集群测试,使用https://0.0.0.0:8000创建完索引或写完数据,只会同步到主集群,没有及时同步到副集群,然后把网关重启下才会把数据同步到副集群
medcl

medcl 回复 w_b

这个 bug 被你踩到了,建议用最新的,中间改进很多的。
感谢用心评测,值得注意的是,目前的版本需要确保新增的文档是带_id 的,也就是不由 es 自己来生成 id,因为两边集群各自生成 id 的话,就会不一致了,后续会提供一个 filter 来提前处理。

要回复文章请先登录注册