数据容灾
数据容灾是指为了保护数据免受意外灾害、硬件故障、人为错误等导致的数据丢失或不可用而采取的措施。数据容灾的目标是确保数据的可用性、完整性和持久性，以便在发生灾难或故障时能够快速恢复数据并保持业务的连续性。
一.数据容灾技术选择度量标准
在构建 容灾 系统时，首先考虑的是结合实际情况选择合理的数据复制技术。 在 选择合理的数据复制技术时主要考虑以下因素：
Ø 灾难承受程度 ：明确计算机系统需要承受的灾难类型，系统故障、通信故障、长时间断电、火灾及地震等各种意外情况所采取的备份、保护方案不尽相同。
Ø 业务影响程度 ：必须明确当计算机系统发生意外无法工作时，导致业务停顿所造成的损失程度，也就是定义用户对于计算机系统发生故障的最大容忍时间。这是设计备份方案的重要技术指标。
Ø 数据保护程度 ：是否要求数据库恢复所有提交的交易 ， 并且要求实时同步 ，保证 数据的连续性和一致性， 这是 备份方案复杂程度的重要依据。
二.容灾模式
市场上常见的 容灾 模式可分为本地容灾，同城容灾，异地容灾，两地三中心，双活数据中心几种。
1、 本地 容灾
本地容灾：本地容灾模式是在本地机房建立容灾系统，能够在日常运行中分担业务和管理系统，并在灾难情况下进行应急切换，保持业务的连续运行。本地容灾的优点包括投资成本低、建设速度快、运维管理相对简单、可靠性更高等。然而，其缺点是受限于本地机房的地理位置，可能仍然存在灾难风险。。
2、 同城 容灾
同城容灾：同城容灾模式是将系统的备份复制到同一城市的另一个数据中心或机房，以应对机房级别的故障。同城容灾能够提供更高的可用性和容灾能力，因为备份数据位于同一城市，网络延迟较低，恢复速度更快。同城容灾的优势是在机房级别的故障时可以提供更好的容灾能力。然而，同城容灾仍然存在受限于同一城市的地理位置的灾难风险。
3、 异地 容灾
异地容灾：异地容灾模式是在距离主备中心较远的地方建立备份中心，一般采用异步镜像，可能会有少量数据丢失。异地容灾能够防范大规模区域性灾难，如火灾、战争、地震、水灾等。然而，异地容灾的缺点是与主备中心之间的网络连接存在一定的限制，数据复制和应用切换需要时间，因此在恢复和数据恢复方面可能会有一定的延迟和数据丢失
总的来说，本地容灾适用于防范生产服务器故障，具有较低的成本和较高的可靠性；同城容灾提供更好的容灾能力，但仍然存在同一城市的灾难风险；异地容灾能够防范大规模区域性灾难，但在网络连接和数据恢复方面可能会有一定的限制。选择适合的容灾模式应根据具体需求和风险评估来决定。
可基于Elasticsearch来实现灾备（高可用，负载均衡，实时数据同步）
elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，elasticsearch是核心，结合kibana（数据可视化）、Logstash（存储，计算，搜索数据）、Beats（数据抓取），也就是elastic stack（ELK），应用领域比较广泛：可以用来实现搜索、日志统计、分析、系统监控等功能，也能使用elasticsearch来实现容灾。
安装：官网下载链接：https://www.elastic.co/cn/downloads/elasticsearch
Elasticsearch 是免安装的，只需要把 zip 包解压就可以了。
启动后输出了很多信息，只需要看启动日志中是否有started字眼，就表示启动成功了。 确认是否真正启动成功，可以在浏览器的地址栏里输入 http://localhost:9200 进行查看（9200 是 Elasticsearch 的默认端口号）
因为是用kibana(可视化界面)操作的，所以还需要安装kibana。
官网下载链接：https://www.elastic.co/cn/downloads/kibana
启动同样跟elasticsearch的启动一样，直接点击bin目录下的kibana.bat即可启动，启动速度相对较慢一点。 当看到 Kibana http server running 的信息后，说明服务启动成功了。 验证：在浏览器地址栏输入 http://localhost:5601 查看 Kibana 的图形化界面。
es容灾的优缺点：
优点：
1.Elasticsearch具有分布式架构，数据会分布在多个节点上，如果一个节点发生故障，其他节点仍然可以继续提供服务，确保数据的可用性。
2.另一个好处是负载均衡。Elasticsearch可以将数据均匀地分布在多个节点上，这样可以平衡负载，提高系统的性能和响应速度。当一个节点负载过高时，可以将一部分数据迁移到其他节点上，以保持整个系统的平衡。
3.此外，Elasticsearch还支持实时数据同步。当一个节点的数据发生变化时，Elasticsearch会将这些变化实时地同步到其他节点，确保数据的一致性。这对于灾备非常重要，因为即使在主节点出现故障的情况下，备用节点上的数据也能保持最新。
缺点：
1.成本：实现基于Elasticsearch的灾备需要建立多个节点和集群，这可能会增加硬件、网络和维护成本。特别是在异地容灾的情况下，跨地域的网络连接和数据同步可能会增加额外的费用。
2.复杂性：Elasticsearch的配置和管理相对复杂，特别是在建立分布式集群和跨地域复制时。这涉及到网络设置、数据同步、节点管理等方面的复杂工作。需要有专业的技术人员来进行设置和维护，增加了系统的复杂性。
3.数据一致性：尽管Elasticsearch支持实时数据同步，但在网络延迟或节点故障的情况下，可能会导致数据同步的延迟或不一致。这可能会对数据的一致性和准确性产生一定的影响。
4.依赖性：基于Elasticsearch的灾备方案依赖于Elasticsearch本身的稳定性和可靠性。如果Elasticsearch本身出现故障或问题，可能会对整个系统的灾备能力造成影响。
为什么选择es进行容灾，除了优点外，是上一个项目也有用到es做其他的功能。
用es能做到的方案，可以根据选择的模式和需求选择方案
选取 极限网关 方案：
极限网关 (INFINI Gateway) 是一个面向 Elasticsearch 的高性能应用网关，网关位于应用程序和 Elasticsearch 之间，应用程序将以往直接发送给 Elasticsearch 的请求都发送给网关，再由网关转发给请求到后端的 Elasticsearch 集群。网关对于应用程序而言是透明的，应用程序无需修改任何代码，就像访问 Elasticsearch 一样访问网关就可以。在网关上可以实现写入加速、查询加速、限速限流、流量监测、透明重试等一系列高级的功能。相比于普通网关用于连接不同网络和子网的中间设备，极限网关位于网络边缘，具有更强的安全性和多样性功能的中间设备。
-
1.让网关以主备的方式提供服务，正常情况下只将流量分发给其中一台网关，当网关故障时，才将流量切换到另一台。
-
2.多台极限网关同时提供服务，提升网关的吞吐量，多台网关同时工作的情况下最好基于 URL 路由等方式确保相同索引的流量分发到同一个极限网关。
-
-
1.克隆一下项目：git clone https://github.com/cr7258/elastic-stack-docker.git
在项目的 high-availability 目录下选择infini-gateway
2.搭环境：需要先安装好 Docker 和 Docker Compose 工具（https://docs.docker.com/engine/install/）
3.配置文件
docker-compose.yml 文件如下所示。
version: '3.8' services: # 集群 cluster01 # Elasticsearch es01: image: docker.elastic.co/elasticsearch/elasticsearch:7.16.2 container_name: es01 environment: # 节点名 - node.name=es01 # 集群名 - cluster.name=cluster01 # 指定单节点启动 - discovery.type=single-node # 开启内存锁定 - bootstrap.memory_lock=true # 设置内存大小 - "ES_JAVA_OPTS=-Xms2g -Xmx2g" # 启用安全 - xpack.security.enabled=true # 设置 elastic 用户密码 - ELASTIC_PASSWORD=test123 ulimits: memlock: soft: -1 hard: -1 # 映射到主机名的端口 宿主机端口:容器端口 ports: - 9200:9200 volumes: - data01:/usr/share/elasticsearch/data networks: - elastic # Kibana kib01: image: docker.elastic.co/kibana/kibana:7.16.2 container_name: kib01 ports: - 5601:5601 environment: # Elasticsearch 连接信息 ELASTICSEARCH_URL: http://es01:9200 ELASTICSEARCH_HOSTS: '["http://es01:9200"]' ELASTICSEARCH_USERNAME: elastic ELASTICSEARCH_PASSWORD: test123 networks: - elastic # 集群 cluster02 es02: image: docker.elastic.co/elasticsearch/elasticsearch:7.16.2 container_name: es02 environment: - node.name=es02 - cluster.name=cluster02 - discovery.type=single-node - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms2g -Xmx2g" - xpack.security.enabled=true - ELASTIC_PASSWORD=test123 ulimits: memlock: soft: -1 hard: -1 ports: - 9201:9200 volumes: - data02:/usr/share/elasticsearch/data networks: - elastic kib02: image: docker.elastic.co/kibana/kibana:7.16.2 container_name: kib02 ports: - 5602:5601 environment: ELASTICSEARCH_URL: http://es02:9200 ELASTICSEARCH_HOSTS: '["http://es02:9200"]' ELASTICSEARCH_USERNAME: elastic ELASTICSEARCH_PASSWORD: test123 networks: - elastic # 极限网关 infini-gateway: image: infinilabs/gateway:latest container_name: infini-gateway ports: - 2900:2900 - 8000:8000 - 8001:8001 - 8002:8002 volumes: - ./gateway.yml:/gateway.yml - data03:/software/infini-gateway networks: - elastic # 存储卷 volumes: data01: driver: local data02: driver: local data03: driver: local # 网络 networks: elastic: driver: bridge
极限网关的配置文件 gateway.yml 如下所示。
# 数据路径
path.data: /software/infini-gateway/data
# 日志路径
path.logs: /software/infini-gateway/log
# 定义 Elasticsearch 集群地址
elasticsearch:
# cluster01 集群
- name: cluster01
enabled: true
endpoint: http://es01:9200
basic_auth:
username: elastic
password: test123
# cluster02 集群
- name: cluster02
enabled: true
endpoint: http://es02:9200
basic_auth:
username: elastic
password: test123
# 定义网关入口
entry:
- name: my_es_entry
enabled: true
router: my_router
network:
binding: 0.0.0.0:8000
# 定义工作流
flow:
# 写请求优先发给主集群, 当主集群不可用时发给备集群
# 当主集群数据写入成功时，记录到队列中，异步消费写入备集群
- name: write-flow
filter:
- if:
# 当主集群可用时
cluster_available: ["cluster01"]
then:
# 先将数据写入主集群
- elasticsearch:
elasticsearch: "cluster01"
# 写入消息队列,等待 pipeline 异步消费到备集群
- queue:
queue_name: "cluster02-queue"
else:
- elasticsearch:
elasticsearch: "cluster02"
- queue:
queue_name: "cluster01-queue"
# 读请求优先发给主集群, 当主集群不可用时发给备集群
- name: read-flow
filter:
- if:
cluster_available: ["cluster01"]
then:
- elasticsearch:
elasticsearch: "cluster01"
else:
- elasticsearch:
elasticsearch: "cluster02"
# 路由规则
router:
- name: my_router
# 默认路由
default_flow: write-flow
# 读请求路由
rules:
- method:
- "GET"
- "HEAD"
pattern:
- "/{any:*}"
flow:
- read-flow
- method:
- "POST"
- "GET"
pattern:
- "/_refresh"
- "/_count"
- "/_search"
- "/_msearch"
- "/_mget"
- "/{any_index}/_count"
- "/{any_index}/_search"
- "/{any_index}/_msearch"
- "/{any_index}/_mget"
flow:
- read-flow
# 定义管道, 异步将数据写入备集群
pipeline:
- name: cluster01-consumer
auto_start: true
keep_running: true
processor:
- queue_consumer:
input_queue: "cluster01-queue"
elasticsearch: "cluster01"
when:
cluster_available: ["cluster01"] # 当集群可用时，才消费队列中的数据
- name: cluster02-consumer
auto_start: true
keep_running: true
processor:
- queue_consumer:
input_queue: "cluster02-queue"
elasticsearch: "cluster02"
when:
cluster_available: ["cluster02"]
进入极限网关实验目录，启动容器。
cd infini-gateway docker-compose up -d
查看容器状态 (ps命令)
查看极限网关日志，可以看到此时极限网关已经成功连接到集群 cluster01 和 cluster02。
$ docker-compose logs -f infini-gateway
当两个集群都正常时，cluster01 是主集群，通过极限网关查看集群将返回集群 cluster01 的信息。
可以验证一下数据是否同步
插入 3 条数据。
在集群 cluster01 和 cluster02 分别查询索引 index-1，可以查到相同的数据。
for i in {1..3};do
curl -XPUT -u elastic:test123 -H "Content-Type: Application/json" \
http://11.8.36.25:8000/index-1/_doc/$i \
-d "{\"name\":\"tom_$i\",\"age\":\"$i\"}";done
在集群 cluster01 和 cluster02 分别查询索引 index-1，可以查到相同的数据。(GET index-1/_search)
curl -XDELETE -u elastic:test123 \ http://11.8.36.25:8000/index-1/_doc/1
可以进行一下故障测试
模拟备集群（cluster02）故障
停止 cluster02 集群，此时在极限网关上可以看到报错说集群 cluster02 不可用。（docker-compose stop es02）
接下来继续往索引 index-1 中插入 2 条数据
for i in {4..5};do
curl -XPUT -u elastic:test123 -H "Content-Type: Application/json" \
http://11.8.36.25:8000/index-1/_doc/$i \
-d "{\"name\":\"tom_$i\",\"age\":\"$i\"}";done
查看集群 cluster01 发现新的 2 条数据插入成功。（GET index-1/_search）
访问极限网关的 API 接口查看本地队列状态，由于集群 cluster02 当前不可用，因此刚刚插入的 2 条消息保存在队列中，待集群 cluster02 恢复后再尝试消费。（$ curl http://11.8.36.25:2900/queue/stats）
恢复 es02（docker-compose start es02）
查看网关日志可以看到集群 cluster02 恢复的信息。（$ docker-compose logs -f infini-gateway）
查询集群 cluster02 的数据，可以在 es02 停止期间的数据已经成功写入。
此时查看队列状态，cluster02-queue 中的消息已经消费完毕。（$ curl http://11.8.36.25:2900/queue/stats）
清理现场
cd infini-gateway # -v 参数表示删除 volume docker-compose down -v
4、 两地 三中心
结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的 “两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。
同城双中心 是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。
异地灾备中心 是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。
两地三中心 ： 是指 同城双中心 加 异地灾备 一种商用容灾备份解决方案；
两地 是指同城、异地；
三中心 是指生产中心、同城容灾中心、异地（远程）容灾中心。（ 生产中心、同城灾备中心、异地灾备 中心 ）
灾备中心是用于存储数据和处理业务的主要场所，而生产中心是用于备份和恢复数据的地方。
5、 双活 数据中心
所谓 “ 双活 ” 或 “ 多 活 ” 数据中心，区别于 传统 数据中心 和 灾备中心的模式，前者 多个 或两个数据中心都处于运行当中， 运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力， 所以称为 “双活 ” 和 “ 多 活 ” ；后者是 生产 数据中心投入运行， 灾备 数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。
“ 双活 ” 数据中心最大的特点是 ： 一、充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费 ， 通过资源整合， “ 双活 ” 数据中心的服务能力是 翻 倍的 ； 二 、 “ 双活 ” 数据中心如果断了一个数据中心， 其 业务可以 迅速 切换到另外一个 正在 运行的数据中心， 切换 过程对用户来说是不可感知的。
在 “ 双活 ” 的模式中，两地数据中心同时接纳交易，技术难度很大，需要更改众多底层程序 ， 因而在现实中，国内还没有 真正 “ 双活 ” 数据中心 的成功 应用 案例。
5.1云容灾：云双活
云双活在技术上更关注数据同步与流量管理能力。该架构要求两个生产中心之间的数据同步须保持实时性、一致性，并且外部能够通过调度策略、流量控制实现全局流量管理，各访问请求利用配置策略分发，避免单点故障。常见的应用场景包括两地三中心
5.2云容灾：云多活
云多活是指同一套业务系统分别部署在两个地域以上的多个数据中心，同时对外提供服务的业务场景。云多活主要体现在“多地域”和“多活”两个概念上。多地域是指地域划分，如不同省市地区或者不同国家地区；多活则是指多个地域部署同一套业务系统同时提供业务服务，都处于生产状态。
2232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
