身为 IT 人士，大伙身边的各种系统肯定不少吧。系统虽多，但最最最重要的那套、那几套，大伙肯定是捧在手心，关怀备至。如此重要的系统，万一发生故障了且短期无法恢复，该如何保障业务持续运行？
有过这方面思考或经验的同学，肯定脱口而出--切灾备啊。
是的，接下来我来介绍下我们的 ES 灾备方案。当然如果你有更好的，请使用各种可用的渠道联系我们。
总体设计
通过极限网关 将应用对主集群的写操作，复制到灾备集群。应用发送的读请求则直接转发到主集群，并将响应结果转发给应用。应用对网关无感知，访问方式与访问 ES 集群一样。
方案优势
- 轻量级
极限网关使用 Golang 编写，安装包很小，只有 10MB 左右，没有任何外部环境依赖，部署安装都非常简单，只需要下载对应平台的二进制可执行文件，启动网关程序的二进制程序文件执行即可。
- 跨版本支持
极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理，能够让业务代码无缝的进行适配，后端 Elasticsearch 集群版本升级能够做到无缝过渡，降低版本升级和数据迁移的复杂度。
- 高可用
极限网关内置多种高可用解决方案，前端请求入口支持基于虚拟 IP 的双机热备，后端集群支持集群拓扑的自动感知，节点上下线能自动发现，自动处理后端故障，自动进行请求的重试和迁移。
- 灵活性
主备集群都是可读可写，切换迅速，只需切换网关到另一套配置即可。回切灵活，恢复使用原配置即可。
架构图
网关程序部署
下载
根据操作系统和平台选择下面相应的安装包：
解压到指定目录：
mkdir gateway
tar -zxf xxx.gz -C gateway修改网关配置
在此 下载 网关配置，默认网关会加载配置文件 gateway.yml ，如果要指定其他配置文件使用 -config 选项指定。
网关配置文件内容较多，下面展示必要部分。
#primary
PRIMARY_ENDPOINT: http://192.168.56.3:7171
PRIMARY_USERNAME: elastic
PRIMARY_PASSWORD: password
PRIMARY_MAX_QPS_PER_NODE: 10000
PRIMARY_MAX_BYTES_PER_NODE: 104857600 #100MB/s
PRIMARY_MAX_CONNECTION_PER_NODE: 200
PRIMARY_DISCOVERY_ENABLED: false
PRIMARY_DISCOVERY_REFRESH_ENABLED: false
#backup
BACKUP_ENDPOINT: http://192.168.56.3:9200
BACKUP_USERNAME: admin
BACKUP_PASSWORD: admin
BACKUP_MAX_QPS_PER_NODE: 10000
BACKUP_MAX_BYTES_PER_NODE: 104857600 #100MB/s
BACKUP_MAX_CONNECTION_PER_NODE: 200
BACKUP_DISCOVERY_ENABLED: false
BACKUP_DISCOVERY_REFRESH_ENABLED: falsePRIMARY_ENDPOINT：配置主集群地址和端口
PRIMARY_USERNAME、PRIMARY_PASSWORD: 访问主集群的用户信息
BACKUP_ENDPOINT：配置备集群地址和端口
BACKUP_USERNAME、BACKUP_PASSWORD: 访问备集群的用户信息
运行网关
前台运行
直接运行网关程序即可启动极限网关了，如下：
./gateway-linux-amd64后台运行
./gateway-linux-amd64 -service install
Success
./gateway-linux-amd64 -service start
Success卸载服务
./gateway-linux-amd64 -service stop
Success
./gateway-linux-amd64 -service uninstall
Success灾备功能测试
在灾备场景下，为保证数据一致性，对集群的访问操作都通过网关进行。注意只有 bulk API 的操作才会被复制到备集群。
在此次测试中，网关灾备配置功能为：
- 主备集群正常时
读写请求正常执行；
写请求被记录到队列，备集群实时消费队列数据。
- 当主集群故障时
写入请求报错，主备集群都不写入数据；
查询请求转到备集群执行，并返回结果给客户端。
- 当备集群故障时
读写请求都正常执行；
写操作记录到磁盘队列，待备集群恢复后，自动消费队列数据直到两个集群一致。
主备集群正常时写入、查询测试
写入数据
# 通过网关写入数据
curl -X POST "localhost:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "test", "_id" : "2" } }
{ "field2" : "value2" }
'查询数据
# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password
# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin
# 查询网关，网关转发给主集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password
主备集群都已写入数据，且数据一致。通过网关查询，也正常返回。
删除和更新文档
# 通过网关删除和更新文档
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "delete" : { "_index" : "test", "_id" : "1" } }
{ "update" : {"_id" : "2", "_index" : "test"} }
{ "doc" : {"field2" : "value2-updated"} }
'
查询数据
# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password
# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin
两个集群都已执行删除和更新操作，数据一致。
主集群故障时写入、查询测试
为模拟主集群故障，直接关闭主集群。
写入数据
# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "3" } }
{ "field3" : "value3" }
{ "create" : { "_index" : "test", "_id" : "4" } }
{ "field4" : "value4" }
'写入数据报错
查询数据
# 通过网关查询，因为主集群不可用，网关将查询转发到备集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password
正常查询到数据，说明请求被转发到了备集群执行。
备集群故障时写入、查询测试
为模拟备集群故障，直接关闭备集群。
写入数据
# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "5" } }
{ "field5" : "value5" }
{ "create" : { "_index" : "test", "_id" : "6" } }
{ "field6" : "value6" }
'
数据正常写入。
查询数据
# 通过网关查询
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password
查询成功返回。主集群成功写入了两条新数据。同时此数据会被记录到备集群的队列中，待备集群恢复后，会消费此队列追数据。
恢复备集群
启动备集群。
查询数据
等待片刻或通过 INFINI Console 确定网关队列消费完毕后，查询备集群的数据。
(生产和消费 offset 相同，说明消费完毕。)
# 查询备集群的数据
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin
备集群启动后自动消费队列数据，消费完后备集群数据达到与主集群数据一致。
灾备切换
测试了这么多，终于到切换的时刻了。切换前我们判断下主系统是否短期无法修复。
如果我们判断主用系统无法短时间恢复，要执行切换。非常简单，我们直接将配置文件中定义的主备集群互换，然后重启网关程序就行了。但我们推荐在相同主机上另部署一套网关程序--网关 B，先前那套用网关 A 指代。网关 B 中的配置文件把原备集群定义为主集群，原主集群定义为备集群。若要执行切换，我们先停止网关 A，然后启动网关 B，此时应用连接到网关(端口不变)，就把原备系统当作主系统使用，把原主系统当作备系统，也就完成了主备系统的切换。
灾备回切
当原主集群修复后，正常启动，就会从消费队列追写修复期间产生数据直到主备数据一致，同样我们可通过 INFINI Console 查看消费的进度。如果大家还是担心数据的一致性，INFINI Console 还能帮大家做[校验数据]()任务，做到数据完全一致后(文档数量及文档内容一致)，才进行回切。
回切也非常简单，停止网关 B，启动网关 A 即可。
网关高可用
网关自带浮动 IP 模块，可进行双机热备。客户端通过 VIP 连接网关，网关出现故障时，VIP 漂移到备网关。
视频教程戳这里。
这样的优点是简单，不足是只有一个网关在线提供服务。如果想多个网关在线提供服务，则需搭配分布式消息系统一起工作，架构如下。
前端通过负载均衡将流量分散到多个在线网关，网关将消息存入分布式消息系统。此时，网关可看作无状态应用，可根据需要扩缩规模。
以上就是我介绍的 ES 灾备方案，是不是相当灵活了。有问题还是那句话 Call me 。
