【容灾】企业容灾架构技术选型指南

基于企业IT架构容灾建设的各种行业标准以及监管标准正在不断提高，而面对技术的日新月异和多元化发展，很多企业在容灾架构的选型过程当中存在着诸多困惑，本文内容包括：跨中心数据复制技术、数据容错恢复技术、关键故障切换、脑裂问题探讨、容灾架构评估。全文25000字，图文并茂，欢迎阅读。

一、必须知道的概念

1. 什么是企业的容灾？

1.1 什么是企业的业务连续性管理（Business Continuity Management）？

企业的业务连续性是指企业有应对风险、自动调整和快速反应的能力，以保障企业业务的连续运转。为企业的重要应用和流程提供业务连续性应该包括连续操作（Continuous Operations）、高可用性（High Availability）、灾难恢复（Disaster Recovery）三个方面，这几个方面不是孤立存在的，而是相互联系存在的。连续操作强调的指在没有物理故障发生的情况下，保障业务连续的常规运维操作能力；高可用性强调的是基础架构在本地故障的场合下的恢复能力；灾难恢复强调的是在灾难场合下，企业的业务恢复能力。从业务连续性上来讲，企业的容灾也就是我们所说的灾难恢复范畴，应该是业务连续性的子集。

1.2 什么是企业的容灾架构（Disaster Tolerance）？

广义的容灾，我们可以认为就是业务连续性计划当中的灾难恢复，就是指能够容忍灾难的能力。要容忍的灾难类型就包括地震、洪水、火灾等灾害、软硬件故障、网络或病毒攻击、人为蓄意破坏等。容灾能力建设的主要目的，就是在灾难发生的时候，能够保证生产业务系统的不间断运行。

狭义的容灾，我们可以认为是指在相隔较远的区域（同城或者异地），建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。

1.3 什么是企业的备份和恢复（Backup and Recovery）？

备份和恢复是指备份数据以防数据丢失，且设置安全系统以便恢复数据的流程。数据备份要求复制和存档计算机数据以保证数据损坏或删除后数据仍可访问。数据备份恢复是业务恢复的一种形式，因此它属于业务连续性计划当中的连续操作和灾难恢复范围。备份包括系统备份和数据备份，系统备份是指将系统运行环境作为一个整体进行备份，当发生故障时将系统运行环境整体恢复。数据备份是指将应用系统当中保存的数据作为单独的形式进行备份，当数据发生丢失或者损坏的时候进行恢复。

1.4 什么是企业IT基础架构的高可用（High Availability）？

高可用性（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。企业的高可用架构通常指的是为了在面对数据中心本地软硬件故障场景下，保证业务的连续性而规划部署的非对称（主备、主从）以及对称架构（主主、集群），可以是网络架构、主机架构、数据库架构以及存储架构等类IT基础架构，例如交换机的堆叠技术、负载均衡设备的集群架构、主机的HA架构、数据库的Oracle RAC集群等。

1.5 什么是企业的IT基础架构的容错（Fault-tolerant）？

在计算机通信领域来讲，容错就是指当系统在运行时有错误被激活的情况下仍能保证不间断提供服务的方法和技术。从广义来讲，我们所述的容灾、备份恢复、高可用等都是容错的一种手段。

但是通常来讲，我们对IT基础架构当中的容错性有着约定俗成的专指含义，实际上它是指我们在IT设备配置或者软件配置过程当中，为了杜绝网络线路、设备零件、软件模块等方面的运行错误导致的应用系统中断而采取的冗余性设计。例如网卡的逻辑绑定、存储链路的聚合、LVM逻辑卷设计等等。

1.6 如何理解业务连续性、备份恢复以及容灾？

1、从范畴上来讲，我们用以下的图来诠释这几个概念的差异。

备份恢复、高可用架构设计、容错设计、容灾都是为了保障业务连续性的一种手段、技术和工具。在广义的容灾设计当中必然也会包括基础架构的高可用设计、设备软件的容错设计以及必要的备份恢复。但是备份恢复、高可用和容错是可以独立存在的，不依赖容灾架构。

2、从设计功能上来讲，备份恢复不仅仅可以解决由物理故障引起的数据损坏和丢失，而且更重要的是它可以解决由人为的逻辑错误导致的数据损坏和丢失，比如误删数据。备份恢复是一种事后的补救措施，也就是说它只能发生在问题发生之后。容错、高可用、容灾中核心的架构设计是为了解决实时问题，是一种事中解决问题的思路，但是这两者都无法解决人为导致的逻辑错误故障导致的业务中断，只能解决物理故障导致的业务中断问题。

3、从所属性质来讲，业务连续性是着眼业务层面的一套解决思路或者方法论指导下的制度、流程、方案、技术、工具、资源等一系列元素组成的。而容灾、高可用、备份恢复、容错仅仅是为了保障业务连续而对基础架构进行设计实现的技术工具或者手段。

2. 企业容灾架构的核心目标是什么？

企业容灾架构的核心目标是什么？也就是说我们为什么要花这么大力气去搞容灾建设？就一句话，RTO&RPO是搞容灾建设的最核心目标，一切容灾建设目的都需要回到RTO和RPO的评估上来。

① RTO（Recovery Time Objective)：企业可容许服务中断的时间长度，简言之业务可以恢复的最快时间。

② RPO（Recovery Point Object)：企业可容许数据丢失的数量级，简言之数据可以恢复到最新的时刻点。

如图所示，RTO关注的是数据丢失的多少，而对什么时候恢复业务中断没有要求；

RPO关注的是什么时候恢复业务，但是历史数据丢失多少并没有要求。

只有这两个结合起来才是对现实生活当中的业务连续性的约束。

要实现什么样的RTO&RPO目标，一定会有相应的方案来支撑，也必然有对此方案需要付出的IT成本投入。

我们评估容灾的目标要求，一定是从RTO&RPO的选定范围出发，然后权衡企业可以付诸的投入，最终确定合理的容灾建设方案。

3. 企业容灾架构的行业标准都有哪些？

3.1企业容灾的国家级标准

《信息安全技术信息系统灾难恢复规范》国家标准（GB/T20988-2007）是我国灾难备份与恢复行业的第一个国家标准。该标准由国务院信息化工作办公室领导编制的，并于2007年11月1日开始正式实施。该标准规定了信息系统灾难恢复应遵循的基本要求，适用于信息系统灾难恢复的规划、审批、实施和管理，并参照国际标准SHARE78的7个层级定义，确定了符合中国国情的6个灾备能力等级要求。

下面，概括性地介绍各个层级的内容：

1级：数据定时备份、异地存放。

2级：数据定时备份、异地设备冷备。

3级：数据定时备份、异地部分业务热备接管。

4级：数据定时备份、异地业务热备接管。

5级：数据实时备份、异地业务热备接管。

6级：零数据丢失、远程自动接管支持。

3.2企业容灾的行业监管标准

对于评价容灾的RTO&RPO这两个指标，不同的行业有不同的行业标准，例如人民银行在2008年的《银行业信息系统灾难恢复管理规范》当中规定：银行类信息系统恢复要求：

① 一类信息系统：RTO<6小时，RPO<15分钟。

② 二类信息系统：RTO<24小时，RPO<120分钟。

③ 三类信息系统：RTO<7天。

对于银行行业来讲，所有容灾建设必须遵循这个最低要求。在此基础之上，不同的企业对自身有不同的要求。比如工商银行、招商银行之类发展比较优秀的银行企业对自己提出了更高的要求(RTO~0，RPO~0)，有些小的地方银行则因为成本问题，是为了达到银监局及人民银行的最低要求而搞容灾建设。但是无论是出于什么样的目的搞容灾建设，最终必然要回到对RTO和RPO的评估上来，没有这两个核心目标的选择，则一切容灾建设方案都无根可寻。

3.3企业容灾的自我衡量标准

另外一种标准就是企业本身的业务要求，例如生产企业，RTO是可以直接计算企业损失的指标，如果停产1个小时将会给企业带来多少可计算的损失以及不可计算的损失。我们可以根据这个损失来衡量可以为容灾建设付出的成本范围。

4. 企业容灾架构都包含哪些技术框架？

企业的容灾架构根据容灾的地域距离可以划分为本地容灾和异地容灾，而且整个容灾架构不是单独的一类技术或者一类工具，而是系统的整体技术框架，包含了很多的元素和技术体系，如果分解阐述，可以从纵向和横向进行分解描述。

首先，从纵向来讲，整个容灾架构包括网络层、负载分发层、应用中间件层、应用层以及数据涉及的数据库和存储层，其中数据层最为重要，直接关系到RPO指标，应用层往上则主要关系到RTO指标。接着，我们从横向上来讲，会包括集群技术、数据复制技术以及应用切换技术，数据复制技术又是整个容灾的关键，因为它直接关系到RPO指标，应用切换技术则直接关系到RTO指标，集群技术一般是指在近距离（例如同城）场合下的数据复制和应用切换技术的融合体。最后，我们从整体基础架构来讲，为了支撑以上技术体系的实现，我们需要有一系列的软硬件基础架构来支撑其最终的实现，比如我们的交换机、服务器、存储、备份介质、网络线路以及为了实现应用的切换和数据复制技术体系所需要的SDN、LB、GLB、VM、HA、DB Cluster、Storage Gateway、Storage DP等软件模块。

接下来，我们来看实现企业容灾架构横向支撑的一些关键技术：

① 网络的跨地域L2技术（主要为虚拟机的漂移、集群IP地址漂移等）：同城距离可以采用波分设备和思科的OTV技术来实现跨中心的L2技术，但是这种技术可跨越的距离仅限百公里范围内级别。另外一类就是采用Overlay隧道技术，在原有网络基础架构之上通过逻辑隧道的模式实现L2的传输，这种技术不受距离限制，但是性能不是最佳。

② 跨数据中心负载分发技术（主要为客户端访问流量的切换）：通常需要域名解析DNS与本地负载均衡LB结合来实现全局的负载分发。DNS需要能够实现动态解析，也就是根据备选地址池的健康状况来确定最终的业务地址。本地不在均衡LB实现本地内的负载导流。

如图所示：

③ 跨数据中心VM集群内漂移技术（主要为应用的跨地域高可用服务）：通常可以通过虚拟机的跨地域集群技术实现，只要具备跨数据中心L2网络和存储卷共享的条件，基本上都可以实现。关于跨区域的L2网络技术，上述章节已讨论过。存储卷共享可以通过NAS或者分布式存储来实现。

④ 跨数据中心数据复制技术（主要为数据跨区域冗余服务）：数据复制技术是关键，它是保障容灾目标RTO&RPO的关键技术，根据容灾级别的不同，可分为同步复制和异步复制，所使用的实现手段也因此而不同。关于它的具体实现方式，可以考虑从三个层面落地：系统层的双写、数据库层的数据复制、存储层的复制。具体实现方式及其优劣在后续文章详细介绍。

5. 数据复制技术在企业容灾架构当中的意义

如果上升到商业业务的高度，那么一切容灾技术都是为了业务的连续性服务的。

具体来说，数据复制技术即完成数据从一个数据中心到另外的数据中心的冗余性保护。一旦发生灾难导致一个数据中心的数据丢失或者损坏，可以通过另外一个数据中心的数据来支撑应用系统运行。没有应用系统的不中断运行就没有业务的连续性可言，没有数据的存在就没有应用系统的不中断运行可言，没有数据复制技术的支撑就没有容灾的必要性可言。数据在应用系统当中的地位直接决定了数据复制技术在容灾框架当中的绝对必要性地位。

① RPO：简言之，RPO就是衡量灾难时刻依靠容灾手段可以丢失的最少数据。数据复制的及时性直接决定RPO的量级标准，如果数据复制是同步模式，那么RPO必然是零。如果数据是异步模式，那么RPO就直接与数据复制的异步效率指标息息相关。

② RTO：简言之，RTO就是衡量灾难时刻依靠容灾手段可以恢复业务的最短时间。这个不仅仅取决于数据复制技术，还要依赖于纵向的网络、负载分发、服务器、应用、数据库、存储等各个层面的恢复技术。但是，数据复制技术一定是所有恢复技术的基石，没有这个基石，及时所有层面都恢复了，没有数据的业务访问也依然无效。

因此，数据复制技术是容灾体系架构当中最关键的技术元素。

二、跨中心数据复制技术

1. 什么是企业容灾的数据复制技术？

企业容灾架构中，所谓的数据复制技术主要是指能够将结构化数据进行复制，从而保证数据具备双副本或者多副本分散在不同数据中心的技术。这里面需要强调两点：

① 结构化数据：以结构化数据为主的数据复制技术。

② 分散在不同数据中心：数据副本必须分布在不同的数据中心。

就具体的实现技术而言，就目前业界发展来看，可以实现数据复制的技术多种多样，有基于数据库层面的数据复制技术，例如Oracle公司的Active Data Gurad、IBM公司的 Db2 HADR等；有基于系统层面的数据复制技术，例如赛门铁克的vxvm、传统的逻辑卷管理（LVM）、Oracle公司的自动存储管理（ASM）冗余技术、IBM公司的GPFS等；有基于存储虚拟化实现的数据复制技术，例如EMC公司Vplex Stretch Cluster、IBM公司SVC Split Cluster、NetAPP公司Metro Cluster等；也有基于存储底层实现的数据复制技术，例如IBM公司的DS8000 PPRC技术、EMC公司的SRDF技术、HP公司的CA技术等等。每一种技术都有其实现的前提条件，也有各自的技术特点和实现的不同效果。

2. 企业容灾中的数据复制技术的分类

2.1 同步复制和异步复制

从RPO维度来划分，大的方面可以分为同步复制和异步复制。

① 同步复制：要求每一个写入操作在执行下一个操作处理之前，在源端和目标端都能完成。特点是数据丢失少，会影响生产系统性能，除非目标系统物理上离生产系统比较近。

② 异步复制：在处理下一个操作前， 只需要完成源端数据写入即可， 不等待数据复制到目标系统中。特点是复制的数据与源数据有时间差，但这种复制对生产系统性能影响较小。

那么这里有一个问题“如何界定一个写入操作完成？”，一般来讲，存储端的写入以存储设备的缓存写入为标准，数据库的写入以数据库的事务日志落盘为标准。

如果用图的方式来区别同步和异步之前的区别就在于：同步需要等待黑色和红色的ACK返回才会执行下一个IO，而异步只需要等待黑色的ACK返回即可执行下一个IO。

从结果上来看，等待红色的ACK返回显然需要花费更多时间，因为A和B分别位于不同的数据中心；但是等待会带来RPO=0的回报。

2.2 根据实现复制的手段来划分

根据上图，数据复制最终完成的结果是在两个磁盘介质上完成同一个IO数据，但是将来自客户端的单个IO请求镜像为两个IO的源头可以有三种不同的选择：操作系统层面、数据库层面以及存储层面。

1). 操作系统层面的复制技术：以LVM、VXVM等逻辑卷镜像为基础，IO写入的时候可以在组成同一个逻辑卷的物理镜像上同时写入数据，底层数据写入是需要通过SAN协议完成的。

2). 数据库层面的复制技术：一种是类似操作系统逻辑卷的模式，比如ORACLE的ASM，它也是一种逻辑卷管理模式，同样也可以通过多个物理镜像来组成一个逻辑卷，从而通过镜像复制的方式完成数据副本的同时写入。本质上它与操作系统层面的逻辑卷镜像技术没有区别，只是它离数据库更近，数据库更懂它。另外一种是通过数据库事务日志复制的方式将数据修改行为在另外一个备库上重新演绎一遍，最终可以达到使数据结果一致的目的。

3). 存储层面的复制技术：一种是通过存储网关将两个物理存储卷组成一个逻辑存储卷，通过镜像复制的方式完成数据在存储落盘时的双写。本质上它与操作系统层面的逻辑卷镜像技术也没有区别，只是它选择在存储层面实现。另外一种是通过存储介质之间以块拷贝的方式来实现数据副本的冗余。

究其原理，其实无论从哪个层面来实现，这些技术从原理上可以划分为三种类型：

1、IO双写（操作系统逻辑卷镜像、ASM、存储网关镜像.etc）

2、事务回放（以Oracle ADG为代表.etc）

3、数据单元拷贝（以存储CA、DP技术为代表的存储复制技术）

3. 系统层如何实现数据复制？

对于操作系统层面的逻辑卷管理器LVM模式来讲，是将底层来自不同数据中心的的两个物理存储卷作为物理镜像( PV) 组合成一个可用的逻辑存储卷( LV) 提供给上层应用来存放数据，本地物理卷和远程物理卷分别是由存储经过本地SAN环境以及跨数据中心SAN环境提供给服务器操作系统层。

建立逻辑卷的时候就已经定义好LV和PV的映射关系，并且逻辑页(LP ) 和物理页(PP ) 的映射关系也已经完全定义好了。这种复制只能采用同步复制机制，复制对象为逻辑卷层的变化Block，其过程为：捕获逻辑页( LP) 当中的变化块，同步写两个物理页( PP) ，等于在一个主机上将同一数据写入两个不同的磁盘，本地写完得到ACK确认，并且远端写完也得到ACK确认，才能算是一个完整的写入。假设远端存储卷写入超时就会被标为故障或者是离线状态，当远端存储写入恢复之后，对于LVM来讲需要重新进行手动同步实现镜像副本完全一致。

3.2 通过数据库逻辑卷镜像实现的数据复制

对于ASM模式来讲，其实原理与LVM基本相同，创建DiskGroup的时候，将冗余策略选择为Normal，也就是所有业务数据保证两份镜像。这样的话，我们可以将相等数量的磁盘分别归入不同的故障组( Failure Group) 。ASM对Oracle数据文件( Data File) 进行修改的时候，以AU为单元进行实时双向写入，本地写完得到ACK确认，并且远端写完也得到ACK确认，才能算是一个完整的写入。

相比LVM的优势在于两点：ASM会有一个短时间内的写事务日志记录，它会帮助恢复离线镜像恢复数据，但是如果超过这个时间，同样需要一个全新的同步来保证数据的一致性。另外一点，AU并非建立数据文件的时候就已经映射好了，ASM是在数据写入时才会分配具体的AU，完全可以做到通过指针转移的方式避免坏块儿导致的数据写入失败问题。

3.3 通过分布式文件系统文件镜像实现的数据复制

对于GPFS模式来讲，它是通过将底层来自不同站点的两个物理存储卷归属到不同的Failure Group当中，然后由这些物理存储卷经过文件系统格式化形成分布式文件系统，提供给上层应用以文件的形式写入数据。

文件本身会被GPFS文件系统打散形成若干文件碎片，这些碎片在落盘时分别落入不同Failure Group当中的物理磁盘，从而保证底层数据的双副本。这种模式与前两种模式的最大区别在于它的数据落盘是根据NSD磁盘定义的服务实例顺序来决定的，正常情况下我们需要定义本站点的服务节点为磁盘的主服务节点，这样的话两个镜像写入的时候是靠GPFS位于不同中心的两个服务实例节点分别写入，两个服务实例之间也需要私有协议的交互，相当于数据的双写多了一个环节。

4. 数据库层如何实现数据复制？

4.1 通过数据库日志回放模式实现数据复制

对于事务日志的复制技术，可以分为绝对同步模式、近似同步模式和异步模式三种。

对于Oracle DB来讲，客户端的数据更新请求首先要由日志写入进程( LGWR) 从重做缓存刷到重做日志文件当中，然后由数据写进程再周期性地写入数据文件当中。重做日志当中以SCN为数据库独有的时间戳序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。也就是说在数据库的认知当中，只要事务日志写入重做日志文件，这个IO就算完成。

如图，对于配置了Data Guard绝对同步模式的数据库，在以上所述过程中，写入进程( LGWR) 在本地日志文件并不能结束，日志传输进程( LNS) 会将缓存里面的重做日志通过TCP /IP 网络传输给灾备站点的备库实例的日志接受进程(RFS ) ，备库实例的日志接收进程( RFS) 根据接受到的重做日志在备库上重新执行数据库的更新操作，然后将ACK回传给日志传输进程( LNS) ，日志传输进程( LNS) 再通知写入进程( LGWR) ，才算是一个完整的IO完成。这样做可以保证主库和备库的事务性更新行为实时一致，最终保证数据的一致。当然也有一个前提条件，那就是在Data Guard开始同步复制之前，必须保证备库的数据保持与主库的某一固定时间点的完整副本，这需要靠传统数据备份技术来实现备库的初始数据复制。因为事务复制的本质是行为复制，那么行为作用的初始数据副本必须保持一致，才能保证最终两副本的一致性。

如图，对于配置了Data Guard异步模式的数据库，日志传输进程( LNS) 会将缓存里面的重做日志以及被LGWR归档的重做日志文件通过TCP /IP 网络异步传输给灾备站点的备库实例的日志接受进程(RFS ) ，备库实例的日志接收进程( RFS) 根据接受到的重做日志在备库上重新执行数据库的更新操作，但是并不会实时给日志传输进程( LNS) 进行ACK反馈，PrimaryDB只要完成本库的事务更新就认为IO结束。但是备库日志接受进程(RFS ) 会定期将进度信息反馈给主库进程。

当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。第二是日志发送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。

近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。

5. 存储层如何实现数据复制？

5.1 通过存储网关逻辑卷镜像实现数据复制

所谓存储网关双写复制技术，就是在物理存储层之上增加一层网关技术，用以形成存储资源透明抽象层，即存储虚拟化是服务器与存储间的一个抽象层用以实现存储底层的虚拟化以及高可用镜像，它是物理存储的逻辑表示方法。其主要目的就是要把物理存储介质抽象为逻辑存储空间，将分散的物理存储管理整合为集中存储管理并且由存储网关来控制镜像写入的策略和模式。IBM、EMC、NETAPP 、 HUAWEI、英方等公司都有相应容灾技术方案及相应产品 。基于写入原理及策略的不同， 各自方案又各有一些区别。但是抛开细节究原理，归类总结之后有两种模式 。

模式 1，如 图中所示，是以 EMC Vplex为代表的分布式存储卷技术。在存储网关VPLEX上重新定义虚拟存储卷，该虚拟卷由分布在两个数据中心的物理存储卷以1:1方式映射组成，并且以共享模式提供给VPLEX的两个引擎，引擎之间类似Oracle RAC的原理来共享全局缓存、心跳信息以及分布式锁的信息。两个引擎同时可以写IO，对于Block级别的并发写操作，是通过分布式锁及全局缓存机制来完成。所以这种双写是可以做到IO级别。

模式 2，如图中所示，是以 IBM SVC为代表的虚拟存储卷技术。在存储网关SVC上重新定义虚拟存储卷，该虚拟卷由分布在两个数据中心的物理存储卷以1:1方式映射组成，并且归属同一个IO Group，并且以共享模式提供给SVC的两个节点，虽然两个节点都可以写操作，但是对于某一个IO Group来讲，只能通过一侧节点进行物理层面的双写操作，这样就避免了两个节点的在Block级别的并发控制。所以这种双写只能做到应用级别，做不到IO级别。

当然还有一些类似的架构，在某些细节上更先进，比如NetApp的容灾方案MCC架构，它在此基础之上可以将负责存储写操作的实例节点做到VM级别，VM负责以卷为粒度的双写，同时VM可以在存储网关的物理引擎或节点之间进行漂移和重组，这样的话以应用为粒度的写操作的容灾切换更加平滑。

5.2 通过存储介质块复制实现数据复制

对于存储存储底层的块儿复制技术来讲， 它的数据复制是完全脱离了上层的应用层、系统层、数据库层。主要是依靠存储层两个物理存储设备 来完成源到目标 设备 的 Block 复制。

如图所示，从组成上来看，只有两个同型物理存储设备，数据复制跟上层没有任何关系，只需要存储层从一边的物理卷捕获 Block变化，复制到另外一边的物理存储卷，整个复制行为通过源端的日志文件来记录进度以及保障故障恢复。根据整个复制过程是否需要等待复制完成的ACK返回可以分为同步复制和异步复制。复制过程依赖的传输环境可以是远距离的以太网也可以是近距离的SAN网络。

但是这种数据复制技术和上层的联系几乎是割裂的，基本很难与上层的容灾切换配合。

三、数据容错恢复技术

1. 企业容灾可能面临的数据灾难场景

之前在《企业容灾选型指南-2：企业容灾的数据复制技术》文章当中，我们介绍了企业容灾建设过程当中经常会用到的远程数据复制技术，主要集中笔墨在其正常场合下的数据复制原理和机制上。那么有正常场合就有异常场合，一个成熟的数据复制技术必须能处理异常场合下的数据损坏和丢失故障。本文我们探讨的异常场景，主要是因数据中心之间的通讯故障、主数据中心数据存储设备故障等引起的其中一个数据镜像不可用（数据损坏、复制中断、镜像失效等）的场景。归纳为以下两个问题：

① 异常发生期间，数据变化如何保存记录？

② 异常恢复之后，镜像数据如何恢复到正常复制状态？

围绕以上两个问题，我们接下来探讨从系统层面、数据库层面以及存储层面用什么样的机制或者策略来保障以上问题的完美解决 。

2. 操作系统层面如何完成数据镜像恢复？

2.1 基于逻辑卷管理器模式的数据复制技术

首先，第一个问题“异常发生期间，数据变化如何保存记录？”。

逻辑卷管理器是可以通过参数控制逻辑卷的读写行为是否一定要双写（例如 AIX参数：Keep Quorum Checking On=yes/no ）。如果我们设置双写控制参数为是，那么这个时候整个逻辑卷的写请求就会被挂起，逻辑卷被认为不可用，业务中断。如果我们设置宽松的双写控制参数，那么这个时候整个逻辑卷的写请求会等待 PV2的ACK回复，如果超过系统默认Timeout时间，那么认为PV2失效，将其标注为Disable，之后的写行为就不会顾及PV2的镜像复制了，业务无中断，但是之后的数据更新不会有任何辅助手段去记录。

其次，第二个问题“异常恢复之后，镜像数据如何恢复到正常复制状态？”

当PV2所面临的异常环境恢复之后，虽然PV2的硬件环境和设备都已经恢复正常，但是逻辑卷的镜像PV2已经被标注为失效状态，因此不会有任何自愈行为。这个时候需要我们手动去做以下几步操作来恢复数据镜像同步状态：

① 命令方式手动拆除逻辑卷对应PV2的镜像。

② 命令方式手动创建PV2物理卷设备，并加入卷组创建成为逻辑卷的新镜像。

③ 命令方式执行镜像之间的数据同步。

这一系列过程，第三步的原理是PV2会作为一个新的设备存储空间，逐个读取原来PV1对应镜像里面的数据，然后以PP为单元进行复制同步，本身会很耗费时间和系统的读写性能。

2.2 基于ASM模式的数据复制技术

如图所示， Failure Group 2对应的数据副本部分或者全部不可用的场景 。

首先，第一个问题“异常发生期间，数据变化如何保存记录？”。

Oracle ASM本身对于磁盘或者整个Failure Group是否可用的判断，也是有参数可以控制的 （例如 Disk_Repair_Time，Failuregroup_repair_time ）。如果超过参数设置的Timeout时间，那么认为磁盘或Failure Group失效，将其标注为Unavailable，之后的写行为就不会再往Failure Group 2写入了。但是这个时候它会有一个机制来保存后续短时间内的数据增量变化。

其次，第二个问题“**异常恢复之后，镜像数据如何恢复到正常复制状态？”**

当Failure Group 2所面临的异常环境恢复之后，ASM会通过设置的参数来判断是否可以自愈，如果不能在参数所限条件下进行自愈，一样需要手动通过命令进行再同步的操作。

1). 小于等于参数 disk_repair_time（默认3.6H）时，认为是暂时性failure，会一直跟踪涉及failure磁盘extents修改，等该磁盘恢复后，重新同步将修改过的extents同步到failure磁盘。此过程无感知。

2). 大于 disk_repair_time。ASM会自动离线failure磁盘。需要人为使用命令剔除无效设备，并添加有效设备进入Failure Group2，然后ASM会自动通过扫描复制方式完成镜像的同步。

2.3 基于并行文件系统模式的数据复制技术

如图所示，灾难发生后，经过仲裁之后，右侧数据中心的节点 Node-2和Failure Group2当中的所有磁盘对于集群都处于不可用状态。

首先，第一个问题“异常发生期间，数据变化如何保存记录？”。

GPFS 本身不会通过自身的参数控制来判断磁盘是否不可用，它完全是依赖操作系统对IO状态判断的反馈来执行它的操作。如果GPFS的主节点Node-1通过ping判断负责failure Group2的节点Node-2是可用的，但是Node-2写入磁盘的IO被操作系统判断为failed或者hung。GPFS会通过Recovery Log来记录元数据和镜像数据的增量变化；如果GPFS的主节点Node-1发现负责Failure Group2的节点Node-2失败了，那么集群会通过选举算法剔除Node-2，并选择与Node-2同数据中心的其他节点来负责Failure Group2的读写；如果节点和磁盘同时发生了故障（数据中心级别故障），那么GPFS集群会剔除失败节点，并且启用Recovery Log来记录元数据及镜像数据的增量变化。

其次，第二个问题“异常恢复之后，镜像数据如何恢复到正常复制状态？”

当环境所面临的异常恢复之后，需要通过命令将节点和NSD磁盘组加入到集群资源当中，然后GPFS集群会通过自身算法重新分配节点和磁盘组资源的映射关系，然后进行镜像数据的同步。同步的时候由于文件系统本身的结构特点所致，它是需要有文件系统的Meta数据和文件系统用户数据两部分，GPFS会通过元数据服务器上的Jornal Log和Recovery Log来同步数据镜像。

3. 数据库层如何完成数据副本恢复？

首先，我们需要明确对于数据库层要讨论的数据再同步问题，一定是同步模式设置为近似同步或者是异步的这种模式，如果是绝对同步的模式那么一旦数据复制中断，读写也就挂起了。

如图所示， 如果是灾备中心数据库完全损毁的场景，只有重新配置Standby DB，并且重新用备份数据为基点进行增量数据的追平。我们讨论的是由于 网络问题或者其他问题导致的 Primary DB 无法访问到Standby DB的场景。

首先，第一个问题“异常发生期间，数据变化如何保存记录？”。

数据库层面的数据复制本身就是日志的应用过程， 当Primary Database的某些日志没有成功发送到Standby Database，这时就发生了归档裂隙（Archive Gap），缺失的这些日志就是裂隙（Gap）。那么自然发生异常后的时间段内，数据增量变化都会在归档的 Redo日志当中记录。

其次，第二个问题“异常恢复之后，镜像数据如何恢复到正常复制状态？”

当环境所面临的异常恢复之后，需要通过命令将节点和NSD磁盘组加入到集群资源当中

Data guard 具备 自动检测、解决归档裂隙 的能力 。一旦Standby Database被认定是failed，那么Primary Database就会强制进行一次日志切换，以明确的标识出Failed的时间点，也就是达到零数据丢失的时间点，而在这以后产生的redo日志就不再向Standby发送了。数据库 的连通性 异常 一旦恢复，则所有的实例会自动去解决日志裂隙问题，接着 Primary Database 所有的实例会进行日志切换，以启动LNS进程，继续发送Redo。这种模式只是尽量避免数据丢失，并不能绝对保证数据完全一致。这种模式要求Standby Database必须配置Standby Redo Log，而Primary DATABASE必须使用LGWR、SYNC、AFFIRM方式归档。

除了自动的日志缺失解决，DBA也可以手工解决，这需要作如下操作：

① 确认Standby Database上缺少的日志 ；

② 把这些日志从Primary Database拷贝到Standby Database ；

③ 在Standby Database使用命令手工注册这些日志 。

④ 执行日志应用恢复。

4. 存储层如何完成数据副本恢复？

4.1 基于存储网关镜像的数据复制技术

如图所示，以 VPLEX为例 ，灾难发生后，经过仲裁之后，右侧数据中心的引擎和存储卷 处于不可用状态。自然虚拟分布式卷Virtual Volume的另外一个镜像就被置为failed状态。

其实它的恢复原理与操作系统镜像恢复的原理是一致的，无非就两种方法，一个是通过日志记录增量变化，待镜像状态恢复之后重新同步增量的变化；另外一个就是从可用镜像扫描全盘进行拷贝同步。

首先，第一个问题“异常发生期间，数据变化如何保存记录？”。

这个问题其实各家不尽相同，有的存储厂商可以通过一定量的Jornal Log来捕获存储卷上的Block变化，也有的存储厂商相对比较传统，没有这样的记录机制，要区别产品而言。

其次，第二个问题“异常恢复之后，镜像数据如何恢复到正常复制状态？”

就增量事务，一旦异常恢复可以首先通过Jornal Log来进行恢复，原理类似于Oracle ASM的Resync机制。但是也有一些存储厂商采取的是快照机制来进行镜像拷贝复制，虽然对原数据副本的读写性能不会造成太大影响，但也毕竟是全盘的扫描。就用过的VPLEX产品的实践经验来看，从VPLEX Virtual Volume多种场景的同步时间周期来判断，它是具备Jornal Log的机能的。

4.2 基于存储介质块拷贝的数据复制技术

如图所示 ， 基于存储设备本身实现的数据复制技术与上层对象相关性非常少，仅依靠物理存储设备层实现数据的复制，由于源端和目标端都是同品牌甚至同规格存储设备，那么底层存储 Block的复制以及异常场景后的镜像恢复也会有很多种手段，毕竟自家的设备自家的软件，实现的手段就更多 。

首先，第一个问题“异常发生期间，数据变化如何保存记录？”。

各家不尽相同，但是也很少看见存储厂商真正原理性的东西出来，仅仅宣传可以有增量记录、快照记录等功能可以记录数据的变化。究竟是结果捕获模式还是事务行为记录模式还是要根据具体产品来说。

其次，第二个问题“异常恢复之后，镜像数据如何恢复到正常复制状态？”

如果有两个以上副本的情况，可以通过其他副本延续数据的复制，当然中断点是必须有日志文件可以参考才可以。如果没有其他副本可以通过检查点之后的日志或者增量快照文件进行增量同步。例如SRDF就是通过增量快照实现的。

这里大家可能非常容易看到一个问题，那就是为什么存储层的数据复制技术很多都是采用快照技术来实现增量或者全量数据的同步恢复呢，而系统层镜像复制技术却很少呢？我个人觉得有两点：

① 存储层与上层应用及数据联系甚少，实现增量记录功能就算复杂一些也不会影响业务。

② 快照技术本身就是存储软件层比较得意的衍生功能模块，正所谓做自己擅长的事情。

四、关键故障切换

1. 容灾设计需要进行故障切换的场景

容灾设计过程当中需要考虑的故障切换的场景有很多，数据中心内部的高可用切换不在本次讨论范围之内，我们讨论的是容灾恢复过程中的关键跨数据中心级的故障切换场景，从网络层到存储层都会涉及到，其主要涉及如下几个方面：

① 网络层故障切换（路由、 DNS、交换机、负载均衡 ）。

② 应用服务计算层故障切换（应用 APP ） 。

③ 数据库服务实例层故障切换（数据库 Instance ）。

④ 数据副本层故障切换（数据副本）。

2. 网络层的故障切换策略

2.1 网络流量路径分析

如图所示，来自客户端的流量访问会分为两个过程：

1、客户端需要获取到业务系统的地址信息。通过路由交换机找到域名解析设备得到业务地址信息。

2、客户端利用获取地址和应用服务端口与应用服务建立 Socket连接，然后交互通讯 。

2.2 域名解析层主中心故障场景切换策略

省略掉中间的交换机设备信息，我们将通常的 AA容灾架构的网络层抽象为上图所示框架。

客户端保存两个DNS地址，根据网络线路的健康状况，由客户端操作系统选择第一步地址请求的DNS服务器地址，每个数据中心的DNS服务器一般会通过HA方式来避免设备的单点故障。同时DNS服务能够实现智能动态解析，也就是说它可以根据负载均衡(LB)层的健康检测信息来判断解析结果是主数据中心地址还是备数据中心地址。对于LB层与物理应用(APP)层的交互来讲，一般是以数据中心为界划分为两个不同的LB资源池，相互不能在L2网络层交互。

这里大家可能有一个问题：

为什么不把LB层规划为一个大的资源池，增加资源选择的灵活性（如下图） ？

其实从容灾的角度来看，相互独立的小集群LB资源池和跨数据中心的大集群LB在容灾切换功能都是合格的，APP节点故障无论是在大集群和小集群架构下，都可以合理切换。但是如果建立跨中心的大集群会增加对跨数据中心L2网络的过度依赖(L2的打通、横向流量的控制、ACK数据流的控制等)，增加网络架构复杂度，而且LB之间的会话同步也无法得到像小集群那样的质量。 最关键的问题，这样的架构导致DNS或者LB提供的业务地址VIP只有一个，对于同样地址的数据请求，客户端如何知道该走哪个路由？除非客户端是互联网客户端或者也是隧道技术框架的一个节点。

接下如上图，来看故障场景下的切换策略。

1、如果DNS层发生单边功能不可用，容灾切换机制是什么？

这个故障可能是由单边入口出口路由故障、单边交换机故障、单边DNS服务设备层导致，总而言之最终的结果就是客户端到DNS地址不可达。那么这个时候就需要客户端操作系统自身的域名解析机制来进行动态切换，把DNS解析服务地址切换到备用侧，导致客户端到DNS地址请求的数据量发生切换。

2、如果LB层发生单边资源池功能不可用，容灾切换机制是什么？

这个故障可能是由单边LB集群服务节点、单边资源池节点等因素导致，总而言之最终的结果就是单边LB集群的业务VIP服务不可用。这个功能层故障信息会反馈给上层的DNS层（两个数据中心的DNS），无论是由谁来解析，一定能探测到下层LB资源的健康状况，那么根据这个健康状况来选择将客户端的业务请求指引到哪个数据中心，如果是LB层整体均健康，那么会有两种选择1或者是2（如图）。

这时候有一个新的问题： 如果是线路故障导致左边数据中心DNS不可用的情况，虽然LB-Cluster-1资源池是健康的，如果把数据流引入的话，网络路径照样不可达，业务就中断了，如何解决？ 这就要求 DNS功能层不仅仅与下边的LB具有健康联动的能力，同时还要具备与上层线路的健康联动能力。综合这两类健康信息才可以做出正确的判断。

这个时候可能又有新的问题了： 那DNS直接解析为自己数据中心的LB资源池就可以了，干嘛还要那么复杂，将数据流指向左边数据中心的LB资源池？ 如果是左边的DNS和右边的LB发生的交叉故障，及时其他功能层都完好，那么也会面临业务中断，整体的高可用性就会大打折扣。

3. 应用服务层的故障切换策略

我们讨论的应用服务层是不带任何业务数据、缓存、状态信息的应用节点层 。如果是缓存，可以作为数据层元素单独讨论，如果是由会话数据或者状态数据需要保持的情况，可以通过应用改造或者考虑缓存架构放在数据层考虑 。如果是这种前提下，那么应用服务节点的故障就没有必要讨论了，因为在LB层的切换已经解决了这个问题。接下来我们探讨如果是互联网架构下跨数据中心集群架构场景：

这种环境下的容灾，在应用层就不必担心会话、状态、缓存信息的保留了 。因为 APP服务节点采用多个的原因在于负载的分担，容灾切换完全可以通过APP在VM集群内部进行漂移。当然这种容灾策略的可行性还需要两个前提条件：

① 数据中心之间的L2层的打通，目前隧道技术相对比较成熟。

② 数据层的双副本或者多副本技术（如分布式存储技术），毕竟状态、会话、缓存也是数据。

4. 数据库服务实例层的故障切换策略

4.1 AS数据库服务模式

对于类似 Oracle DB模式的AS服务模式，那么一般会有两种切换方式: Failover and Swithover 。

Failover 是指主库发生故障暂时不能恢复的情况下，主备库进行的主备切换；

Switchover一般是指计划内的维护事件所需，将主备库角色切换，数据同步方向切换。

容灾故障场合下的恢复切换一般是指Failover，因此我们探讨的也是Failover的情况。

如图所示，主库对外服务地址 10.8.120.101，备库对外服务地址10.8.130.101；两个服务地址网络L3可达即可，客户端地址到两个服务地址也是L3可达即可，切换之后备库角色变为主库。

① 切换过程：备库->切换->主库->检查状态，原主库脱离DG架构；

② 应用场合：当主库发生严重故障不可逆转的时候可以使用 Failover；

③ RPO ：如果用最大性能模式或者最大高可用模式配置的 DG，极有可能丢失数据 。具体的 RPO要看网络之间的传输质量和传输的重做日志多少等因素。因此建议人工干预这种操作。

④ 网络条件：L3可达。

⑤ 应用切换请求方法：DB 域名连接方式，动态切换解析地址；数据连接客户端配置动态数据库连接（例如 Oracle ）。

4.2 HA数据库服务模式

所谓 HA数据库服务模式是指通过操作系统HA软件结合数据库服务实现的容灾架构，架构设计之初是为了实现各类应用服务的本地服务器高可用，但双活容灾技术兴起之后，也常常被用来作为近距离（百公里内范围）双活容灾的数据库服务架构 。例如 IBM的HACMP与DB2、Oracle结合、例如HP Service Guard与Oracle结合等。

如图所示，数据库服务对外提供服务的地址只有一个 VIP，是跨中心组成HA的两个实例节点的虚拟地址，借助跨数据中心L2的网络环境，VIP可以漂移到任何一个物理节点上。

当主中心数据库服务实例DB-instanceA侧发生故障（网卡、服务器、SAN连接）时，根据HA的集群仲裁规则，DB-instanceA可以获取到的仲裁资源（网络心跳、磁盘心跳）一定小于DB-instanceP，这个时候，集群会发生AP切换，集群执行以下动作让DB-instanceP接管数据库服务：

1、将虚拟VIP绑定到DB-instance-P的物理网卡；

2、将共享存储卷从 DB-instanceA上卸载，并在DB-instanceP上挂载；

3、将共享存储卷上的服务在DB-instanceP上启动并激活对外提供服务。

注意：这3个步骤，尤其是2&3两个步骤是需要一定切换时间T的（分钟级），这意味着RTO不会为零，应用会产生一定的中断，因此整个容灾架构的RTO>T，这是需要在设计时充分考虑的。

4.3 AA数据库服务模式

所谓 AA模式的数据库服务就是以Oracle RAC、DB2 pureScale为代表的双活集群架构，同样它们的设计初衷也是为了解决数据库服务本地高可用的解决方案，后来衍生为Extended RAC之类的容灾架构 。

从架构本身来看，与 HA架构有些类似，差异的地方在于AA模式是两边的节点都是Active状态，都可以进行读写，并发控制由缓存同步及锁机制来协调。

如图所示，数据库服务对外提供服务的地址只有一个 VIP，是跨中心组成集群的两个实例节点的虚拟地址，借助跨数据中心L2的网络环境，相互之间可以交换缓存信息、锁信息以，从而保障两个实例均可以激活状态进行数据的读写。

当主中心数据库服务实例DB-instanceA侧发生故障（网卡、服务器、SAN连接）时，根据集群的集群仲裁规则，DB-instanceA可以获取到的仲裁资源（网络心跳、磁盘心跳）一定小于DB-instanceB，这个时候，集群不会发生任何切换，只是将DB-instanceA置为离线状态，不再接受任何读写事务。所有向DB-instanceA请求的事务均被集群分发给DB-instanceB，这个过程对应用是无感知的。因此我们基本认为RTO为零。

5. 存储层的故障切换策略

5.1 存储网关服务模式

所谓存储网关模式，我们在《企业容灾选型指南- 2 ：企业容灾的数据复制技术》当中介绍过， 就是在物理存储层之上增加一层网关技术，用以形成存储资源透明抽象层 ，形成虚拟存储卷对外提供服务。根据物理引擎的服务方式不同，又分为 HA和AA工作模式两种。

但是因为他们对外提供的服务是存储服务，对数据服务层和应用层没有任何影响，存储服务连接的地址SAN环境识别的存储卷的WWN，而这个WWN是可以通过Service Instance-1&2上面的Port同时以多链路的方式提供给上层数据服务层，因此存储网关层的故障切换对上层是透明的。

如图所示，在这个问题讨论的时候，我们不在分别说明 HA和AA两种模式下的网关节点切换。因为本质上他们都一样，只是在缓存的处理和存储卷的控制权限上的策略有一些区别：

HA模式：首先，服务节点上的IO缓存一般可以做到实时同步，如果不能实时同步或者同步不完全，那么缓存会有一些丢失，只是需要在Service Instance-2激活之后，系统需要做一些恢复工作（通过事务日志等手段）；然后，将虚拟卷的读写控制权交给Service Instance-2，当它成为虚拟卷的Owner之后，负责后续的IO，根据两边存储设备的健康状况选择双边落盘或者是单边落盘。

AA模式：这种模式下没有任何所谓的网关节点切换，只是所有本来由Service Instance-1服务的IO需要重新排队到Service Instance-2，中间几乎没有中断，因为两个节点的缓存本来就是全局缓存，两个节点对虚拟卷的读写权限本来就是共享开放的。只是原来需要分担给Service Instance-1服务的部分IO，这个时候需要自己跨中心写入到主中心的物理存储上，当然如果主中心的物理存储也发生了故障，那么就只好单边落盘了。

5.2 通过存储介质块复制实现数据复制

对于存储存储底层的块儿复制技术来讲， 它的数据复制是完全脱离了 上层的 应用层、系统层、数据库层。主要是依靠存储层两个 物理存储设备 来完成源到目标 设备 的 Block 复制。适合远距离的传输模式，一般用来做异地的数据级别容灾，因此一旦发生主数据中心灾难后，那么需要网络层、应用层、数据层等一系列人工干预之后，才能启用灾备中心的存储卷，这里就不再详述。

五、脑裂问题探讨

1. 什么是容灾中的脑裂问题？

脑裂(split-brain)就是“大脑分裂”，也就是本来一个“大脑”，由于某些原因被拆分了两个或多个“大脑”，我们都知道，如果一个人有多个大脑，并且相互独立的话，那么必然会出问题。

在容灾架构设计当中，我们经常会利用一些 HA、Cluster等高可用架构在其中，而且一般都是借助于跨地域L2网络，采用跨数据中心的方式在某一个功能层组成一个独立的集群，例如数据库集群、存储网关集群等 。假设因为两个数据中心节点通讯中断故障导致形成了两个独立的集群，彼此独立工作，那么这就是脑裂。

正如下图所示情况。

第一个问题：为什么会集群可能产生脑裂？

这个问题需要回到集群的仲裁机制上来，一般来讲集群的仲裁算法是以每一个节点可以获得仲裁资源的多少来判断谁是集群的主导。集群的仲裁资源无非是来自网络层面的心跳信息和共享存储的磁盘心跳资源，在普通的节点层故障场合下，发生故障的节点可以获得的仲裁资源就会少于其他节点，那么就不会发生脑裂问题。但是在一种特殊的场合（双数据中心之间的网络发生了故障），两个节点可以获得的仲裁资源是一样的，网络彼此不能互通，存储彼此不能看到对方，这样的的场景下仲裁就会失效，脑裂发生。

第二个问题：集群如果发生了脑裂问题，那么会造成什么样的结果？

那么为什么说对于容灾架构来讲，脑裂是灾难性的事件呢？如果从一个统一集群的调度变成两个相互独立的集群调度，意味着双方的写操作相互也是独立的，但是他们的存储空间是共享的， AA模式下通过锁机制控制并发，HA模式下通过存储卷的Owner控制写的权限。但是独立之后意味着两个集群可以随时写入同样的存储地址，必然会造成脏写脏读等一系列数据不一致事件。这对业务来讲是灾难性的。

2. 优先级解决方案

2.1 Oracle RAC优先级解决方案

如图所示，以两个节点的 Oracle RAC为例来讲，ORACLE RAC ASM管理模式下，磁盘组通常有三个（+DATA，+FRA，+OCR），在OCR磁盘组当中所有的磁盘中存储的数据包括两部分，一部分是Vote File，另外一部分就是OCR（Oracle Cluster Registry）。Vote File是用来记录集群节点的磁盘心跳信息，而OCR是保存集群配置信息的数据。Vote File，以整个文件的方式存储在OCR磁盘上，不做任何条带。

下图是其信息记录的一个说明：

以上是一个三节点的ORACLE RAC集群的Vote FIle的一个示意矩阵，每一行是一个节点的写入的信息，例如第一行，Instance1分别把其对集群中的三个成员（1、2、3）进行私网检测的结果写入到仲裁文件当中，Instance2、Instance3同样把其检测结果写入仲裁文件，最终组成了三个节点的仲裁矩阵。当私网发生故障而从网络上导致集群分割为几个孤岛子集的时候，网络心跳同票数情况下，仲裁算法有两个非常重要的规则：

① 保障隔离后的集群子集中节点数目最多的子集存活。

② 当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。

当两个节点的Oracle RAC集群面临私网故障的时候，必然会遵循以上规则，从规则内容上可以看出，第一条规则基本没有什么意义，双方的资源是对等的；但是第二条规则直接决定了集群的最终状态，那就是实例号小的节点成为新的集群，这就避免了脑裂的存在。

2.2 资源失衡配置解决方案

所谓资源失衡配置解决方案，就是要在容灾设计之初就保障主数据中心的资源配置要多于灾备中心，使得两个数据中心节点可以获取到的仲裁资源处于不平衡状态。

如上两图所示，容灾设计的时候可以将主备数据中心的节点分布数量或者仲裁文件分布数量按照2:1的非平衡策略设置。那么按照集群仲裁的一般规则：发生集群分裂故障的时候，可以获得更多仲裁资源的子集将成为新的集群。当发生数据中心之间的网络故障的时候：

第一种架构，主数据中心内部两个节点可以获取到更多的网络心跳，自然会接管集群。

第二种架构，主数据中心的节点可以获取到更多的磁盘心跳，同样会接管集群。

这也符合我们设计之初衷。但是，这种方法只适合于AA模式的多节点集群，不适合HA模式的架构。

2.3 自定义优先级解决方案

自定义优先级的解决方案，其实本质上与Oracle RAC的仲裁算法第二条“当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。”是一样的。只不过对于Oracle RAC，当通过第一条规则无法判断的时候（节点获取的仲裁资源矩阵是平衡的），它默认采用了实例号定义其优先级。

而其他的一些容灾方案，这个优先级定义的灵活性留给了客户。例如图当中的VPLEX产品，尤其是在双活架构的设计当中，有可能因为地域、设备新旧、运营管理等方面的差异，往往灾备中心的运行能力会稍差，那么发生数据中心之间隔离的这种故障时，大家往往希望保留主数据中心的运行。那么这个时候客户就可以根据主数据中心的节点标识来固定其仲裁优先级。

3. 仲裁解决方案

3.1 网络仲裁

网络资源是集群仲裁当中非常重要的一种心跳资源，因此通过第三方网络资源的可达性心跳信息来判断对称集群分裂后的新秩序也是一种非常有效的方法。一般在以存储网关实现数据双写的容灾架构当中比较常见，比如 VPLEX、SVC、MCC等。

具体原理如下图所示：

第三方仲裁点需要满足的条件：

① 与主备两个数据中心 L3可达，并且网络质量稳定。

② 仲裁点一般需要安装具备网络探测功能的虚拟服务器或者物理服务器，具备运行条件。

如图所示，仲裁点服务器上的软件会与组成集群的存储器网关两个节点分别发送PING/ACK来确认双方的健康情况，集群会把两个节点与第三方仲裁点的网络仲裁心跳看做是最终的裁判。Vplex Witness 通过管理 IP 网络连接至两个集群节点，通过将其自身的观察与集群定期报告的信息进行协调，让集群可区分是集群内故障还是集群间链路故障，并在这些情况下自动继续相应站点上的 I/O 服务。Vplex Witness 仅当分离规则没有定义时才会生效。当然细心的读者可能产生了一个新的问题：

如果数据中心与第三仲裁站点的网络发生故障，那会不会影响集群本身的运行？

什么是仲裁？仲裁是只有发生集群隔离故障的时候才会起作用，如果没有发生数据中心之间的隔离故障的时候，即使他们的一方或者双方于第三方仲裁站点发生网络暂时中断的事件，也不会对既有集群造成任何健康影响。我们需要做的是保障第三方仲裁资源在发生故障的时候有效就可以了（监控&及时修复）。

3.2 存储仲裁

存储一般是数据库集群当中非常关键的仲裁资源，数据库集群的节点负载比较重，不像存储网关模式的集群，可以再设计与 Witness Node的通讯接口。所以在这类技术方案的容灾设计当中，通常会用第三方存储阵列来作为集群的第三方仲裁点。例如Oracle Extended RAC、HA&Oracle、HA&DB2等。具体原理如下图所示：

a. 第三方站点放置一个存储阵列、并且与两个数据中心网络稳定可达。

b. 存储阵列以NFS或者ISCSI方式提供共享存储卷或文件服务给两个中心的集群节点。

c. 集群配置的时候，将这个共享存储卷或者文件作为集群的磁盘仲裁之一。

当双中心的集群发生隔离故障的时候，集群通过第三方的仲裁磁盘或者文件来判断集群的新秩序。

3.3 对称隔离场景

集群发生的故障场景有很多，有可能是网卡故障导致节点隔离，也有可能是链路问题导致节点隔离。链路问题本身又分很多种，有一种场景即使存在第三仲裁的场景下，依然有可能是对称平衡的状态。

如下图所示：

如图所示，当两个中心之间的链路中断，但是其他各条线路都完好无损的情况下，及时存在第三方仲裁，那么集群分裂后的仲裁资源分布依然是平衡对称的，这又该如何解决呢？

我们认为有两种解决方式：

1、优先级定义解决方案，也就是说我们在第二节提到的解决方案必须成为容灾设计的必选项。

2、仲裁争夺方案，无论是三方的网络仲裁还是存储仲裁，假设出现集群隔离故障后各个节点开始争夺这个资源，那么必然有先后顺序之分，先到先得的规则来重新定义集群新秩序。这种方案尤其适用于以HA模式的容灾架构。当然具体如何争夺，如何确认争夺维度及结果就需要根据不同产品架构来探讨了。

4. 仲裁冲突问题

4.1 什么是仲裁冲突？

我们知道在容灾整体设计当中，需要有网络层、计算层、数据库服务层、存储服务层等各方面的设计。

他们在纵向上是叠加的形态。如图所示：

上图是我们将容灾设计当中纵向抽象出来的几个功能层，其中数据跨中心复制是实现双活容灾的前提条件，它是支撑网络及计算层具备容灾意义的基础，那么如何实现数据复制，我们在《企业容灾选型指南- 2：数据复制技术》当中介绍了很多方法，基本上集中在数据库层和存储层去实现。假设我们采用了存储层的数据复制技术，存储层提供的虚拟分布式卷对于数据库集群来讲是透明的。

当数据中心之间发生线路故障的时候，数据库集群和存储网关组成的集群是两个不同的集群，他们的仲裁结果会不会不一致？

集群的仲裁是瞬间完成的，集群的仲裁触发条件有可能有片刻的先后顺序之差，数据库层的仲裁先于存储层的仲裁，那么虽然概率小，但是这个冲突是完全有可能的。但是如果存储的仲裁发生在数据库之前，理论上这个冲突是可以避免的，因为存储卷是数据库集群健康运行的前提。

4.2 如何解决仲裁冲突问题？

以 Oracle RAC 和VPLEX结合的架构为例，我们探讨它的解决方法。

风险发生的引发点有两个：

① 集群的仲裁触发 条件导致的仲裁顺序发生紊乱；

② 对称平衡状态下的仲裁规则冲突。

资源被1:1割裂之后的默认仲裁策略不一致。也就是说，只要控制这两个引发点，那么这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以只要我们将misscount这个参数调整到 1 5秒之后，也就是说理论上绝对保障存储集群仲裁在前，而数据库仲裁在后，那么第 1 个引发点就没有了。对于第二个引发点来讲，假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的Winner策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第 2 个引发点也就不存在了。

六、容灾架构评估

1. 容灾设计规划的步骤

容灾对于企业的 IT建设来讲是非常重要的事情，如何进行企业的容灾架构设计规划是整个容灾建设的核心关键事宜，因此需要一套方法论或者科学的步骤来参考。概括起来应该遵循以下逻辑进行：

根据图中所示的逻辑思路，我们需要依次解答以下几个问题：

① 为什么要搞容灾建设？

这个问题非常重要，因为企业搞容灾建设的背景可能会因为行业背景、监管标准、业务特点等情况不同而完全不一样。例如多数金融行业搞容灾建设是因为监管的行业要求，有的企业则是因为曾经面临过数据中心灾难教训或者看到别人的教训而主动搞容灾建设。不同的建设目的会导致追求的目标不尽相同。

② 建设成什么样的容灾架构体系，用什么样的标准去衡量？

在《企业容灾选型指南-1：什么是企业容灾》文章当中详细阐述过：RTO&RPO是搞容灾建设的最核心目标，一切容灾建设目的都需要回到RTO和RPO的评估上来。

RTO：企业可容许服务中断的时间长度，简言之业务可以恢复的最快时间。

RPO：企业可容许数据丢失的数量级，简言之数据可以恢复到最新的时刻点。

企业因搞容灾的初衷不同，那么对RTO和RPO的目标也会有严格和宽松之分，所谓严格的RTO&RPO指标就是政府或行业监管的最低标准，不同规模性质的企业有不同的最低标准要求。所谓宽松就是企业为了平衡投入成本和容灾架构带来的收益，可以将RTO&RPO锁定在一定范围内。

③ 建设的容灾架构应该是什么级别（国家标准&国际标准）？

在《企业容灾选型指南-1：什么是企业容灾》文章当中详细阐述过：银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO<=15分钟，RTO<=30分钟。而根据国际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。

企业可以根据这些标准界定自己应该实现的最低标准，比如说5级或者6级标准。

④ 选择什么样的容灾架构技术体系，如何评估各种容灾中的关键技术方案？

以同城双中心容灾为例，企业需要评估网络层、应用层、数据库层、存储层等纵向各个功能层的具体技术方案，同时需要考虑到纵向和横向的融合和扩展。评估的时候，我们需要选择好评估的维度以及关键风险的把控，后续章节我们会详细介绍评估这些关键技术方案的方法和思路。

2. 评价容灾技术的维度

每一种容灾技术方案，从实现的技术复杂度、需要投入的成本、需要承担的风险、技术的先进性、技术的成熟度等几个方面来综合评估，寻求适合企业的最佳技术组合方案 。

① 技术复杂度： 对于容灾技术方案的技术复杂度，总的原则是同目标可达的情况下，架构越简单越好。

大的方面分析来看，不仅仅需要考虑建设的复杂度还需要考虑运维的复杂度；不仅仅要考虑方案本身的复杂度还需要考虑方案需要依赖的环境的复杂度；不仅仅需要考虑横向复杂度还要考虑纵向的复杂度。

② 投入成本： 对于企业来讲，投入成本是非常总要的一项因素。总的原则是同目标可达的情况下，成本越少越好。大的方面分析来看，投入成本不仅包括容灾方案本身的设备成本还需要考虑软件成本；不仅需要考虑建设成本还需要考虑运维成本；不仅需要考虑资源成本还需要考虑人力成本；不仅需要考虑一次性成本还需要考虑持续投入成本。

③ 承担风险： 所谓风险，最主要的就是极端情况下的RTO和RPO风险。总的原则是可以在宽松目标范围内适度降低，但是不能因此而承担灾难性的风险概率。大的方面分析来看，承担风险主要包括极端情况下的数据丢失风险、区域性业务中断扩展的风险。

④ 技术先进性： 所谓技术先行性，一方面要看技术本身与主流发展的方向是否匹配，另外一方面要看技术本身在性能、高可用、扩展性、兼容性等方面的能力。总的原则是在目标可达的情况下，选用先进的技术体系。

⑤ 技术成熟性： 所谓技术成熟性，不仅需要从技术体系本身的发展历史来看它的健壮性和稳定性，还需要从技术方案应用的案例情况以及市场的反馈情况来看技术的成熟性。

当然以上五个方面的评估维度，在具体分析技术方案的时候，可以根据方案本身的特点建立起一套评估指标体系，根据不同维度指标的得分情况来具体评估。

3. 关键容灾技术比较分析

3.1 DB：HA vs AA vs AS

数据库层的集群模式是容灾设计当中必不可少的部分，这部分的服务模式一般会有三种类型：以操作系统级别的HA与数据库服务相结合的模式；通过数据库层实现的AA服务模式；通过数据库层容灾技术实现的AS服务模式。下图是我们对这三种模式的抽象描述：

服务模式 ：只有一个浮动VIP，以主数据中心为基础提供对外数据访问接口服务。

集群模式 ：主备模式，主节点提供服务，备节点故障时刻接管服务。

存储模式 ：主备节点均可以激活存储卷，正常时刻只有激活节点可以挂载存储卷并具备读写权限。

环境依赖 ：跨数据中心L2网络；共享存储卷（可以是操作系统或者是存储网关实现的虚拟共享卷）；第三方仲裁站点（与主备数据中心有相互独立的L3网络）。

服务模式 ：SCAN IP+2个VIP，主备中心以负载均衡的模式对外提供服务。

集群模式 ：主主模式，节点可以扩展，主备节点同时提供服务。

存储模式 ：主备节点共享存储卷，通过节点间的缓存协调机制以及锁机制实现并发控制。

环境依赖 ：跨数据中心L2网络；共享存储卷（可以是操作系统或者是存储网关实现的虚拟共享卷）；第三方仲裁站点（与主备数据中心有相互独立的L3网络）。

服务模式 ：主库VIP+备库VIP，并且不能是同网段地址；主库对外提供服务。

集群模式 ：主备模式，但是主库的A可以扩展为AA集群，主库对外服务，备库故障时切换为主库。

存储模式 ：主备节点各自拥有自己的存储卷，从主库到备库实现数据复制。

环境依赖 ：双中心网络三层可达即可。

我们从技术复杂度、投入成本、承担风险、技术先进性、技术成熟性五个维度来对比分析这几种技术方案的优劣，篇幅的原因，我们这里只做大方面的定性分析，不做体系化的指标模型分析。

技术复杂度上 ，HA和AA模式均依赖于跨数据中心L2网络，AS模式仅需要跨数据中心L3可达即可，相对来讲AS模式的技术复杂度会更优。

投入成本上 ，建设阶段HA和AA模式会因为跨数据中心L2网络环境的建设而投入更多的设备、软件以及线路成本，AS模式多数需要人为干预切换，因此后期需要专门的高水平团队管理容灾切换。

承担风险上 ，AA模式两个节点之间的Cache/Lock管理非常重要，一旦私网出现不稳定问题，影响极其重大，小则性能出现问题，大则数据重大损坏集群崩溃；HA模式正常情况下是单节点控制读写，因此不会产生因为读写竞争出现的重大性能或数据损坏问题；AS模式双节点之间只是日志单向复制，风险相对较其他两种模式小很多。

技术先进性上 ，AA模式RTO&RPO理论上都是零，可以达到7级容灾目标；HA模式(RPO=0，RTO约为0-30分钟级别)，可以达到6级容灾目标；AS模式(RPO约为0，RTO约为0-30分钟级别)，也可以达到6级容灾目标。架构扩展和灵活性方面，AA可以扩展到多节点集群，AS模式可以扩展多一对多以及级联架构，而HA的扩展性和灵活性都非常差；性能方面，AA模式可以横向扩展，AS不仅可以横向扩展，而且可以读写分流；HA模式只能增加单节点处理能力。

技术成熟性上 ，HA模式虽然历史较长，但是并不是一个成熟的数据库高可用技术，它受限于操作系统方面的处理机制。而AA模式就是基于数据库集群服务而诞生的成熟高可用技术，但是官方并没有把它作为一种成熟的容灾技术宣传（例如Oracle将Extended RAC作为过渡的容灾架构，而不是官方正式认可的容灾技术方案），而AS模式是官方认可的成熟容灾技术。

3.2 Replication: Mirror vs Log Replication

关于数据复制技术，我们在《企业容灾选型指南- 3 ：数据复制技术》当中介绍了常见的几种技术方案，但是总结来看，其实无非两种模式，一种是基于镜像的双写复制技术，一种是基于端到端的拷贝复制技术（日志拷贝应用 &存储Block复制，仅考虑日志拷贝应用模式 ）。

对于数据复制的这两种模式的对比分析，我们主要从风险和技术复杂度、先进性三个方面来看：

从承担风险上来看 ，基于镜像实现的数据复制模式，其复制原理主要是基于操作系统存储卷或者存储的Block来进行双写，跟数据库层的事务操作没有任何关联性，无法识别Block里面包含的业务数据。极端情况，如果主数据中心因为数据库层配置文件或元数据之类的数据损坏而导致的灾难，这个时候备数据中心也会发生同样的问题。而基于重做日志应用的数据复制完全是数据库应用层的事务操作实现的数据复制，它的复制不会掺杂数据库配置层、系统层等外界的多余的写操作，因此不会存在这种逻辑Block损坏的事故概率。另外一方面，这种模式的镜像是不平衡的，每一次写过程都会受到IO延时不平衡的影响，性能极大受到外界不稳定网络的影响，而且放在AA数据库集群环境会无限放大。

从技术复杂度来看 ，如果是本地镜像，那么技术复杂度并不高，但是如果是跨数据中心的镜像技术，无论是基于操作系统层还是基于存储层，都是需要基于远距离SAN环境做跨中心的镜像，每一次IO都需要经历远距离写的过程。因此它的技术复杂度一定高于后者。

从技术先进性来看 ，基于镜像的数据复制技术，那么RTO&RPO理论上都是零。基于日志应用实现的复制技术虽然也可以实现同步复制，但是实际应用当中绝大多数采用高可用或者性能模式，网络传输质量好的情况下，RPO只能接近于零，出现故障的时候需要切换时间，RTO指标也不如前者。

3.3 Storage：HA vs AA

存储网关集群技术实现的数据复制，也是基于镜像实现的数据复制，总结市场上的一些产品方案，总结来看主要分为两种模式，一种是以VPLEX为代表的双活网关模式，另外一种是以SVC为代表的HA网关模式（厂商的宣传永远是双活，但是我们需要从单个存储卷的维度去看它是不是双活，另外即使双活做到卷和IO的粒度也不一定是好事，需要辩证去看）：

如图所示，上图是基于HA模式和AA模式的存储网关实现数据复制的基本技术轮廓，主要区别在于两个网关节点的工作模式。HA两个节点针对同一个卷的工作模式是主备，单边故障的时候可以切换到备节点工作，有些产品可以做到同步缓存，甚至利用存储操作系统虚拟化技术做到虚拟机漂移并自动接管存储卷读写，有些则需要较长的切换过程。AA两个节点针对同一个卷的工作模式是主主，通过全局缓存和分布式锁机制控制并发。底层都是双写，只是由一个点写下去还是由两个点协商写下去的区别。

对比这两种技术方案，应该说从技术复杂度、成本投入都没有太明显的区别，所以我们着重还是要从风险和技术先进性及成熟度上来做辩证性比较。

承担风险上 ，存储网关的AA架构类似于Oracle RAC架构，两节点之间的通讯数据量不仅量非常大（维持全局Block缓存和分布式锁），而且非常重要，一旦出现通讯不稳定问题，两节点无法协商完成并发写入控制，严重的时候可能出现更严重的问题。如果与数据库层的RAC集群配合使用，那么风险无疑是雪上加霜，纵向两套集群（DB、Storage）都是同类机制，都严重依赖双数据中心的通讯质量，不确定性就太高了。HA架构相对于AA来讲，最大的优点在于双写是由单边发出的，无需协调控制，最少不会出现因协调不稳定出现的性能及数据安全风险。这两种模式与数据库集群配合的时候，都会面临同样的风险，那就是仲裁冲突的问题，还需要谨慎考虑。 

技术先进性上 ，站在理论的高度，认为可以实现存储卷、IO级别的双活就是技术上的制高点，实现以应用为最小粒度的双活就是伪双活；其实站在业务的高度，我们认为只要两套系统都能运作，都能承载应用就可以了，企业追求的目标是业务连续性，不是IO连续性。这个意义上讲，二者没有区分出太大的优劣。 

技术稳定性上 ，二者都是基于操作系统及数据库高可用技术实现的存储容灾技术，技术源头都有较长历史传承。所以大家还要从市场的应用状况来考察。

参考

社区 "灾备" 技术主题

https://www.talkwithtrend.com/Topic/3457?p=3

企业高可用数据库容灾备份方案

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