两地三中心规则原则

一、两地三中心的概念：

• 1、两地是指同城、异地

• 2、三中心是指生产中心、同城容灾中心、异地容灾中心。

二、两地三中心设计架构图

三、容灾衡量指标

    衡量容灾系统的主要指标有

• 1、RPO(Recovery Point Object) :灾难发生时允许丢失的数据量

• 2、RTO(Recovery Time Objective) : 系统恢复的时间

• 3、容灾半径: 生产系统和容灾系统之间的距离

• 4、ROI(Return of Investment): 容灾系统的投入产出比

• RPO 是指业务系统所允许的灾难过程中的最大数据丢失量（以时间来度量），这是一个灾备系统所选用的数据复制技术有密切关系的指标，用以衡量灾备方案的数据冗余备份能力。

• RTO 是指“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态，并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态”所需时间，其中包括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等，该指标用以衡量容灾方案的业务恢复能力。例如，灾难发生后半天内便需要恢复，则 RTO 值就是十二小时。

• 容灾半径是指生产中心和灾备中心之间的直线距离，用以衡量容灾方案所能防御的灾难影响范围。

• 容灾方案的 ROI 也是用户需要重点关注的，它用以衡量用户投入到容灾系统的资金与从中所获得的收益的比率。

• 显然，具有零 RTO 、零 RPO 和大容灾半径的灾难恢复方案是用户最期望的，但受系统性能要求、适用技术及成本等方面的约束，这种方案实际上是不大可行的。所以，用户在选择容灾方案时应该综合考虑灾难的发生概率、灾难对数据的破坏力、数据所支撑业务的重要性、适用的技术措施及自身所能承受的成本等多种因素，理性地作出选择。

四、做灾备你面临最大的挑战是什么？

• 
  

• 1、Scalability(可扩展性)

• 2、Availability(可用性)

• 3、Performance(性能)

• 4、Flexibility(灵活性)

五、容灾级别

按照容灾系统对应用系统的保护程度可以分为数据级容灾 、 应用级容灾 和 业务级容灾。

数据级容灾 仅 将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实现 存储 系统的接管或是数据的恢复 。容灾 中心的数据可以是本地生产数据的完全复制（ 一般 在同城实现） ， 也可以比生产数据略微落后，但必定是可用的 （一般 在异地实现） ， 而差异的数据 通常 可以通过一些工具（ 如 操作记录、日志等） 可以 手工补回。基于数据容灾 实现 业务恢复的速度 较慢 ，通常情况下 RTO 超过 24 小时， 但是这种 级别 的容灾系统运行维护成本较低。

应用级容灾是 在数据级容灾的基础上，进一步实现应用 可用性 ，确保业务的快速恢复。这就 要求 容灾系统 的 应用不能改变原有业务处理逻辑，是对生产中心系统的基本复制 。因此 ，容灾中心需要建立起一套和本地生产相当的备份环境，包括主机、网络、应用、 IP 等 资源均有配套，当 生产 系统发生灾难时，异地系统可以 提供 完全可用的生产环境。 应用级 容灾的 RTO 通常 在 12 个 小时 以内 ，技术复杂度较高，运行维护的成本也比较高。

业务级容灾 是生产中心 与容灾中心对业务请求同时进行 处理 的容灾方式，能够确保 业务 持续可用。这种 方式 业务 恢复 过程的自动化程度高， RTO 可以 做到 30 分钟 以内 。 但是 这种容灾级别 的 项目 实施难度大， 需要从 应用层对系统进行改造，比较适合流程固定 的 简单业务系统 。 这种 容灾系统 的运行维护成本最高。

六、同城容灾和异地容灾

同城容灾

同城容灾 是在同城或相近区域内 （ ≤ 200KM ）建立两个数据中心 : 日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。

与异地灾备模式相比较，本地双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点；异地灾备中心是指在异地建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

异地容灾

异地容灾 主备中心之间的距离较远 （＞ 200KM ) ， 因此一般采用异步镜像，会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患，还能够防范战争、地震、水灾等风险。由于同城灾难备份和异地灾难备份各有所长，为达到最理想的防灾效果，数据中心应考虑采用同城和异地各建立一个灾难备份中心的方式解决。

七、备端在线容灾系统设计

1）当生产服务器处于正常工作状态时，把生产服务器的监控代理软件连接至服务器。当监控代理检测到主存储数据变化后，将捕获变化的数据实时的复制到备用存储上，实现了实时的复制。具体部署如下图：

2）当生产服务器故障，或者存储故障导致生产系统无法正常提供业务支持时，本地容灾服务器可直接接替生产服务器工作保障业务系统的持续运行；当本地机房发生灾难时，异地机房的容灾服务器可直接接替生产服务器工作保障业务系统的持续运行。具体部署如下图：

3）当生产系统恢复工作后，代理软件会继续其生产服务器的复制工作，并且在这之前会通过回切工具保障主备系统数据一致，具体部署如下图：

异地容错的容灾系统设计

如果本地机房发生故障，将异地容灾服务器中备份的数据进行手动恢复，可以直接恢复到原生产服务器（也可恢复到新服务器）。备份存储系统保存了应用系统任意时刻的数据，恢复时可恢复到任意时间点，实现容错，具体部署如下图：

八、具体实施面临的问题

1. 分类 根据是否需要数据同步大体分为三类： 1、必须同步型。（比如数据库） 2、无须同步型。比如缓存，仅仅是当做缓存，就可以这样做（这个有待商榷，其实缓存也需要同步的，严格来说的话）。 3、只能单活（对全局原子要求较高），不接受有一定时延的“不一致”窗口。

2. 核心问题

数据同步、网络时延。

3. 切换方式

1、自动切换。自动切换表现为当灾难来临时，程序内部可以自动识别出问题然后切换至可用机房。 2、手动切换。通过简单的配置，在几分钟或者一两小时内切换到另外的机房。

4. 异地多活面临的挑战

4.1、切换问题。 切换问题不仅仅是灾难发生自动切换到好的机房，还有另外一个问题，就是灾难机房恢复能力后，如何再切换回去，切换回去的数据同步问题又是需要解决的。

4.2、跨机房流量问题。 跨机房的流量是花钱的。所以不是无限大的。控制跨机房消息体大小，越小越好。然而，很多时候要想保证数据同步是一件很耗费流量的事情。但跨机房流量真的是一座山。

既然跨机房流量有限制，而且不稳定。所以有一种解决方案就是不跨机房。既然不跨机房就要做用户分区，确保每个用户只能访问自己所在的区，这样至少能保证该用户自己的数据的完整。

4.3、所有的业务都适合做异地双活吗？

异地多活效果看起来很诱人，但如果不假思索贪大求全的要求所有业务都实现异地多活的话，就会把自己带到坑里去。

第一个原因是异地多活是有成本的，包括开发成本和维护成本。需要实现异地多活的业务越多，方案越复杂，投入的设计开发时间越多；同时维护成本也会越高，需要更多的机器，需要更多的带宽。

第二个原因是有的业务理论上就无法实现异地多活。典型的有“余额”和“库存”这两个业务。

以余额为例，假设我们实现了余额的异地多活业务，用户小明有10000块钱，在A机房给女友转账了5000块，还剩余5000块；如果此时A机房异常且数据还没同步到B机房，小明登录到B机房发现自己又有10000块了，小明感觉中彩票了，赶紧又转了10000块给女友，最后出现了小明只有10000块却转账了15000块的问题，对于和资金相关的业务，这样的问题是绝对无法容忍的，哪怕一个用户有问题都不行。

所以，异地多活也不能保证所有业务都异地多活，在设计异地多活方案的时候，需要从业务和用户的角度出发，识别出核心和关键业务，明确哪些业务是必须实现异地多活，哪些是可以不实现异地多活，哪些是不能实现异地多活的。比如“登录”必须实现异地多活、“注册”和“修改用户信息”不一定要实现异地多活。

4.4、冷备还是热备。冷备了以后，一直冷备，当真正出现问题，你还有勇气去切换到那个一直冷的机房吗？恐怕需要点勇气。

4.5、数据一致性问题。

解决方案： （1）守护进程同步。 （2）客户端双写。 （3）不去解决。不需要解决的前提是用户分区。分区后，从本质上说，其实是没有做到双活的。只是看起来一个业务确实被分到了多个机房而已。

4.6、读取问题。

这个相对来说要好解决一些，就是就近读取。

九、两地三中心方案架构-组网

两地三中心容灾解决方案中的“两地三中心”一般指的是一个生产中心、一个同城灾难备份中心、一个异地灾难备份中心。生产中心的数据同步地复制到同城灾难备份中心，同时，生产中心的数据异步地复制到异地灾难备份中心。

同城灾备中心通常具备与生产中心等同业务处理能力，应用可在不丢失数据的情况下切换到同城灾备中心运行，保持业务连续运行。在生产中心和同城容灾中心同时不可用时，可在异地的容灾中心实现业务的恢复，保持业务连续性。

相比仅建立同城灾难备份中心或异地灾难备份中心，“两地三中心”的方式结合两者的优点，能够适应更大范围的灾难场景，对于小范围的区域性灾难和较大范围的自然灾害，都能够通过灾难备份系统较快地响应，尽可能保全业务数据不丢失，实现更优的RPO和RTO。所以，两地三中心容灾解决方案得到了广泛的应用。

1、两种方案的优缺点比较:

级联方案：

优点：对本地生产端资源消耗较小，对异地数据传输的网络带宽要求较低；

缺点：本地生产中心和同城灾备中心同时发生故障时，异地灾备机房无法实时接管业务。

并联方案：

优点：业务实时性高，本地生产中心和同城灾备中心同时发生故障时，异地灾备中心可以实时接管业务；

缺点：本地生产中心需要同时将数据实时同步到同城灾备中心和异地灾备中心，对本地生产端压力较大，对异地传输的带宽要求较高。

组网原理：

2、关键组件技术实施说明

    1）城域网要求：

            容灾网络距离：<100km，裸光纤连接。

            传输延迟：<1ms （单向）。

            网络真实带宽：>业务的峰值写IO带宽。

    2）广域网要求：

            容灾网络距离：无限制。

            传输延迟：<50ms （单向）。

            网络真实带宽：>业务的平均写IO带宽。

    3）灾备管理控制端：

            管理工作站需要三中心间通信。

            网络距离要求：无限制。

            通信网络带宽要求：10Mb/s。

十、关键技术

两地三中心关键技术原理

1、应用级高可用业务接管

    提供针对多种应用任意距离内的高可用性服务，当应用异常或生产系统出现异常 （如服务异常停止、网络异常、硬件故障、生产系统宕机维护）而导致应用业务系统不可用时，能将相关应用立刻切换到灾备服务器上， 由灾备服务器上的应用提供服务，保证整体业务的连续和不间断。

2、数据实时/定时备份

连续数据备份、按需恢复服务，能简便地将生产端的数据实时或定时备份到本地或异地的灾备中心节点，并且按需快速地恢复需要的数据。并严格保证生产系统和灾备中心数据的一致性和完整性。 可广泛应用于普通文件系统、数据库系统、邮件系统等实时的容灾备份保护。

在数据备份的同时，将变化的数据以字节级复制或快照的方式实时复制到灾备中心的同时，把数据的变化以日志方式记录下来。在系统故障时根据数据变化日志，快速定位需要恢复的时间点，将数据一键式恢复到异常点之前，保证数据的安全性和业务的连续性。

方案亮点

字节级增量数据捕获：以字节为数据捕捉的最小单位，而不是以传统方式上的文件或者块为单位，从而极大地缩小了需复制的数据量，不仅节省了网络带宽资源，也提高了整个灾备系统的效率；

任意时间点数据恢复：通过监控被保护数据的变化，将数据的每一次变化的部分，将其保存在CDP数据保护区中。当生产端因故障丢失数据时，可将数据恢复到任意时间点；

应用的无缝切换：通过对应用、服务器等资源的状态进行实时监控，在发现应用突然异常停止或者达到需要切换的条件时，自动或手工将应用切换到灾备服务器；

平台支持：支持目前主流的Windows、Linux、虚拟化平台，与服务器无关，并且支持生产端和灾备端服务器和存储的异构；

全图形化监控和管理：所有操作都可通过图形界面完成，无需命令行操作。

参考：https://cloud.tencent.com/developer/article/2097034

           https://zhuanlan.zhihu.com/p/713448296