System-Recovery-2020系统灾难恢复

生产故障恢复修订日期

第1 部分灾难恢复 (3)

1.1 灾难描述 (3)

1.2 灾难恢复 (3)

1.3 域名映射 (4)

第2 部分单点故障恢复 (5)

2.1 单点故障描述 (5)

2.2 单点故障恢复 (5)

第3 部分数据库单点故障恢复 (6)

3.1 数据库单点故障描述 (6)

3.2 数据库单点故障恢复 (6)

第 1 部分灾难恢复

1.1 灾难描述

当整个区域因重大自然灾难或大规模服务中断而发生中断时的真实灾难恢复方

案。这些情况极少发生，当然为了交易安全/数据安全/交易稳定性，如果整个区域的服务中断，但须对这种可能性做出准备。如果整个VM区域的网络中断，会暂时无法交易，数据的安全也无法保障。如果启用了异地复制，则会在其他区域额外存储的交易数据/业务重新上线并实现灾难恢复。

1.2 灾难恢复

为VM 配置Azure Site Recovery，从而只需单击一下便可在几分钟内恢复应用程序。可复制到所选的VM 区域（并不局限于配对区域）。通过创建恢复计划，以便自动进行应用程序的整个故障转移过程。可事先测试故障转移从而避免影响生产应用程序或正在进行的复制。若主要区域发生中断，只需启动故障转移并将应用程序带到目标区域。因此次展示为生产环境，只能通过截图展示恢复的可能性。如下

图：

可以通过CLI一键转移所有VM到指定区域，如下图所示：

1.3 域名映射

使用Azure DNS区域，针对内部API接口地址进行统一管理和调用，执行灾难恢复后无须修改程序配置中心地址，通过Azure DNS区域进行统一修改管理，能够快速恢复生产系统业务的运行。如下图展示为Azure区域API接口地址的管理：

以上灾难恢复，均为生产测试通过。

第 2 部分单点故障恢复

2.1 单点故障描述

如果某个交易程序所在VM出现底层硬件故障、“SSH”连接故障、或者业务应用程序访问调用其他接口出现故障。以下实施过程：

2.2 单点故障恢复

1，负载均衡器自动移除故障节点，通过报文检测故障节点，在故障节点恢复之前，确保不会转发请求，如下图所示，当其中一个交易节点发生故障后，Load

Balancer自动检测到测服务为故障，自动移除故障节点，此时对于客户是无感

知，直至故障节点恢复为running，继续提供交易数据业务。

2，重新部署VM 时，将VM 移到其他基础结构中的新节点，并重新提供支持。所有配置选项和关联资源均保留。以下通过命令实现故障转移的操作。

3，单点故障恢复时间，通过生产故障时间总结得到如下结果，在不影响生产系统的交易和交易的安全性前提下，整个节点平均恢复时间为6分钟。

第 3 部分数据库单点故障恢复

3.1 数据库单点故障描述

在交易环境中，如果MYSQL数据库主节点故障，会导致交易数据丢失，面临无法交易的场景，为了方式这种场景出现，通过以下过程实现MYSQL的高可用性和交易的安全性。

3.2 数据库单点故障恢复

1，客户端通过VIP连接Maxcale，方式Maxscale单点故障，当Maxscale一台出现故障，Keepalived自动移除故障节点，提升备用Maxscale为新节点。为了不影响交

易环境，数据库单点故障不做演示，如以下示意图，整个数据库的流程图：

2，MYSQL数据库为主从复制架构，为了防止单点故障，通过Maxscale实现管理/监控/日志审计等功能。

2.1，MYSQL数据库互为主备，主库故障，从库自动提升为主节点，提供读写操

作，如图所示当前节点为正常状态：

2.2，模拟主库故障，如下图显示，自动提升从库为主节点，不影响交易，保证

数据的完整性可靠性。

3，存储的安全性

通过Azure blob会将数据库的备份全部写入网络端的Azure Blob Storage 中，Azure Blob Storage 基于加密的分布式协议设计，负责在多层面保障用户数据备份的可用性及安全性。

备份过程对用户完全透明，无需担心在备份的过程中要安排任何人手监控。

通过Azure blo实现两地三中心的容灾方案解决区域故障/认为故障造成数据丢失的问题，如下图所示：