企业容灾规划建设N个关键问题总结

随着全球 IT 产业的飞速发展，企业的 IT 建设逐步成为主导业务发展的核心驱动力，基于企业 IT 架构容灾建设的各种行业标准以及监管标准也相应提高。传统数据中心环境，灾备中心长年处于休眠状态，一旦发生数据中心级的灾难事故，灾备中心很难迅速发挥作用。近些年兴起的双活灾备解决方案逐渐成为探讨业务连续性的主旋律。但是面对技术的日新月异和信息技术的多元化发展，如何提高企业整体容灾体系标准，建立一套适合自己的容灾体系架构，一直企业面临的重大挑战。甚至有些企业花费大量时间调研学习之后还是无从下手。归根结底是一些关键问题困扰着。本次线上交流围绕企业容灾规划建设的全过程进行讨论，梳理总结交流议题如下：

一、关于容灾规划建设之初需要考虑的问题？
【关键问题】

1. 金融企业搞容灾建设应该从什么地方着手？第一步需要做什么事情？
2. 容灾建设的合规性要求有哪些？如何进行容灾建设规划？
3. 容灾的 RTO 和 RPO 需要如何来制定？
4. 数据同步技术到底有没有实际作用？

【关键总结】
如何理解备份、高可用、容灾、容错等常用概念？
从作用范畴上来讲，备份恢复、高可用架构设计、容错设计、容灾都是为了保障业务连续性的一种手段、技术和工具。在广义的容灾设计当中必然也会包括基础架构的高可用设计、设备软件的容错设计以及必要的备份恢复。但是备份恢复、高可用和容错是可以独立存在的，不依赖容灾架构。从设计功能上来讲，备份恢复不仅仅可以解决由物理故障引起的数据损坏和丢失，而且更重要的是它可以解决由人为的逻辑错误导致的数据损坏和丢失，比如误删数据。备份恢复是一种事后的补救措施，也就是说它只能发生在问题发生之后。容错、高可用、容灾中核心的架构设计是为了解决实时问题，是一种事中解决问题的思路，但是这两者都无法解决人为导致的逻辑错误故障导致的业务中断，只能解决物理故障导致的业务中断问题。从所属性质来讲，业务连续性是着眼业务层面的一套解决思路或者方法论指导下的制度、流程、方案、技术、工具、资源等一系列元素组成的。而容灾、高可用、备份恢复、容错仅仅是为了保障业务连续而对基础架构进行设计实现的技术工具或者手段。

企业容灾架构的核心目标是什么？
也就是说我们为什么要花这么大力气去搞容灾建设？就一句话， RTO&RPO 是搞容灾建设的最核心目标，一切容灾建设目的都需要回到 RTO 和 RPO 的评估上来。
RTO ：企业可容许服务中断的时间长度，简言之业务可以恢复的最快时间。
RPO ：企业可容许数据丢失的数量级，简言之数据可以恢复到最新的时刻点。 RTO 关注的是数据丢失的多少，而对什么时候恢复业务中断没有要求； RPO 关注的是什么时候恢复业务，但是历史数据丢失多少并没有要求。只有这两个结合起来才是对现实生活当中的业务连续性的约束。要实现什么样的 RTO&RPO 目标，一定会有相应的方案来支撑，也必然有对此方案需要付出的 IT 成本投入。我们评估容灾的目标要求，一定是从 RTO&RPO 的选定范围出发，然后权衡企业可以付诸的投入，最终确定合理的容灾建设方案。

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

① RPO ：简言之， RPO 就是衡量灾难时刻依靠容灾手段可以丢失的最少数据。数据复制的及时性直接决定 RPO 的量级标准，如果数据复制是同步模式，那么 RPO 必然是零。如果数据是异步模式，那么 RPO 就直接与数据复制的异步效率指标息息相关。
② RTO ：简言之， RTO 就是衡量灾难时刻依靠容灾手段可以恢复业务的最短时间。这个不仅仅取决于数据复制技术，还要依赖于纵向的网络、负载分发、服务器、应用、数据库、存储等各个层面的恢复技术。但是，数据复制技术一定是所有恢复技术的基石，没有这个基石，及时所有层面都恢复了，没有数据的业务访问也依然无效。因此，数据复制技术是容灾体系架构当中最关键的技术元素。

数据同步技术是容灾备份技术，参考的必要的条件。 数据库同步技术是应用系统处理核心，不但应用系统需要向数据库进行增 / 删改 / 查操作，同样数据仓库也需要从众多的数据库中获取不同交易数据来完善自身的数据集。

技术需求 ： 越来越多实时数据查询应用使得数据库不能直接为客户带来直接查询结果，因为数据库负荷越来越重，更多的系统无法享受直接查询的结果，这样数据库同步技术就应运而生。

技术指标 ：
1-- 重要数据必须可以实时查询，至少到秒级别
2-- 必须能够限制查询人员的条件
3-- 查询系统主机和业务系统主机必须处于内外网，保证系统安全
4-- 必须能够对需要同步的 OWNER 、 TABLE 、 FIELDS 进行配置和过滤，保证查询数据的安全。

二、关于容灾架构规划阶段需要定性的问题？
【关键问题】

1. 容灾方案中的异常处理方面的设计？
2. 灾备与双活如何选择？
3. 企业容灾的规划者如何找到适合自己的规划？
4. 异地容灾规划的时候，在业务分级上有什么注意的地方？

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

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

建设的容灾架构应该是什么级别（国家标准 & 国际标准）？
银监局和中国人民银行对商业银行业最严格的要求标准是 5 级容灾标准， RPO<=15 分钟， RTO<=30 分钟。而根据国际标准 share78 ，六级容灾标准是 RPO=0 ， RTO= 分钟级；七级容灾标准是 RPO=0 ， RTO 近似为 0 。企业可以根据这些标准界定自己应该实现的最低标准，比如说 5 级或者 6 级标准。

选择什么样的容灾架构技术体系，如何评估各种容灾中技术方案？
以同城双中心容灾为例，企业需要评估网络层、应用层、数据库层、存储层等纵向各个功能层的具体技术方案，同时需要考虑到纵向和横向的融合和扩展。评估的时候，我们需要选择好评估的维度以及关键风险的把控，后续章节我们会详细介绍评估这些关键技术方案的方法和思路。每一种容灾技术方案，从实现的技术复杂度、需要投入的成本、需要承担的风险、技术的先进性、技术的成熟度等几个方面来综合评估，寻求适合企业的最佳技术组合方案 。

① 技术复杂度： 对于容灾技术方案的技术复杂度，总的原则是同目标可达的情况下，架构越简单越好。大的方面分析来看，不仅仅需要考虑建设的复杂度还需要考虑运维的复杂度；不仅仅要考虑方案本身的复杂度还需要考虑方案需要依赖的环境的复杂度；不仅仅需要考虑横向复杂度还要考虑纵向的复杂度。
② 投入成本： 对于企业来讲，投入成本是非常总要的一项因素。总的原则是同目标可达的情况下，成本越少越好。大的方面分析来看，投入成本不仅包括容灾方案本身的设备成本还需要考虑软件成本；不仅需要考虑建设成本还需要考虑运维成本；不仅需要考虑资源成本还需要考虑人力成本；不仅需要考虑一次性成本还需要考虑持续投入成本。
③ 承担风险： 所谓风险，最主要的就是极端情况下的 RTO 和 RPO 风险。总的原则是可以在宽松目标范围内适度降低，但是不能因此而承担灾难性的风险概率。大的方面分析来看，承担风险主要包括极端情况下的数据丢失风险、区域性业务中断扩展的风险。
④ 技术先进性： 所谓技术先行性，一方面要看技术本身与主流发展的方向是否匹配，另外一方面要看技术本身在性能、高可用、扩展性、兼容性等方面的能力。总的原则是在目标可达的情况下，选用先进的技术体系。
⑤ 技术成熟性： 所谓技术成熟性，不仅需要从技术体系本身的发展历史来看它的健壮性和稳定性，还需要从技术方案应用的案例情况以及市场的反馈情况来看技术的成熟性。

三、关于容灾建设过程当中必需要考虑的一些关键技术问题？
【关键问题】

1. 双活架构中是否设定仲裁优先级，合理规避“脑裂”风险？
2. 是否更应该考虑多种容灾方案的叠加？
3. 企业如果想建设三个数据中心，都跑应用业务，互备模式如何实现？
4. 同城双活方案中关联业务的保障与支撑主要依靠什么来实现？
5. 双活数据中心如何保证数据同步实时与一致性？如何解决错误传递问题？

【关键总结】

如何选择数据复制技术路线？
数据复制最终完成的结果是在两个磁盘介质上完成同一个 IO 数据，但是将来自客户端的单个 IO 请求镜像为两个 IO 的源头可以有三种不同的选择：操作系统层面、数据库层面以及存储层面。
1). 操作系统层面的复制技术：以 LVM 、 VXVM 等逻辑卷镜像为基础， IO 写入的时候可以在组成同一个逻辑卷的物理镜像上同时写入数据，底层数据写入是需要通过 SAN 协议完成的。
2). 数据库层面的复制技术：一种是类似操作系统逻辑卷的模式，比如 ORACLE 的 ASM ，它也是一种逻辑卷管理模式，同样也可以通过多个物理镜像来组成一个逻辑卷，从而通过镜像复制的方式完成数据副本的同时写入。本质上它与操作系统层面的逻辑卷镜像技术没有区别，只是它离数据库更近，数据库更懂它。另外一种是通过数据库事务日志复制的方式将数据修改行为在另外一个备库上重新演绎一遍，最终可以达到使数据结果一致的目的。
3). 存储层面的复制技术：一种是通过存储网关将两个物理存储卷组成一个逻辑存储卷，通过镜像复制的方式完成数据在存储落盘时的双写。本质上它与操作系统层面的逻辑卷镜像技术也没有区别，只是它选择在存储层面实现。另外一种是通过存储介质之间以块拷贝的方式来实现数据副本的冗余。

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

1. IO 双写（操作系统逻辑卷镜像、 ASM 、存储网关镜像 .etc ）
2. 事务回放（以 Oracle ADG 为代表 .etc ）
3. 数据单元拷贝（以存储 CA 、 DP 技术为代表的存储复制技术）

基于镜像技术实现的数据复制技术（无论是基于系统层还是存储层）以及基于存储本身 Block Copy 的技术实现的数据复制技术，都存在逻辑 Block 错误传导的问题。也就是说一旦发生存储 Block 错误，那么它一定会传导到备数据中心。本质上是因为这种传输机制跟 IO 应用没关系，识别不到 IO 应用层的数据，所以有些数据虽然在应用层看已经是坏掉的数据了，但是存储层完全识别不到，所以正常复制。但是，这种问题在整个数据中心容灾可防范的灾难列表里面占据的比例非常小。基于数据库重做日志实现的数据复制技术，不存在这种问题。因为它是应用层的复制，它复制的是数据库层做过的事务，是过程复制，不是结果复制。只要过程没错，那么结果就不会有问题。即使主中心的存储 Block 发生了错误，但是在灾备中心经过日志回放实现的数据结果不会受到任何影响。所以从这一点上，这种技术相对安全。如果是人为失误造成的数据损坏，那就是备份技术解决的问题了，不是容灾方案能解决的了（比如 DBA 的误操作删除了一些数据，无论哪种数据复制技术都会传导到灾备中心，容灾方案没有义务也没有能力来区分 DBA 的操作到底是不是失误）。

为什么会集群可能产生脑裂？集群如果发生了脑裂问题，那么会造成什么样的结果？
这个问题需要回到集群的仲裁机制上来，一般来讲集群的仲裁算法是以每一个节点可以获得仲裁资源的多少来判断谁是集群的主导。集群的仲裁资源无非是来自网络层面的心跳信息和共享存储的磁盘心跳资源，在普通的节点层故障场合下，发生故障的节点可以获得的仲裁资源就会少于其他节点，那么就不会发生脑裂问题。但是在一种特殊的场合（双数据中心之间的网络发生了故障），两个节点可以获得的仲裁资源是一样的，网络彼此不能互通，存储彼此不能看到对方，这样的的场景下仲裁就会失效，脑裂发生。
那么为什么说对于容灾架构来讲，脑裂是灾难性的事件呢？如果从一个统一集群的调度变成两个相互独立的集群调度，意味着双方的写操作相互也是独立的，但是他们的存储空间是共享的， AA 模式下通过锁机制控制并发， HA 模式下通过存储卷的 Owner 控制写的权限。但是独立之后意味着两个集群可以随时写入同样的存储地址，必然会造成脏写脏读等一系列数据不一致事件。这对业务来讲是灾难性的。

如何解决脑裂问题？
1. 优先级解决方案
Oracle RAC优先级解决方案
以两个节点的 Oracle RAC 为例来讲，当私网发生故障而从网络上导致集群分割为几个孤岛子集的时候，网络心跳同票数情况下，仲裁算法有两个非常重要的规则：
①保障隔离后的集群子集中节点数目最多的子集存活。
②当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。
从规则内容上可以看出，第一条规则基本没有什么意义，双方的资源是对等的；但是第二条规则直接决定了集群的最终状态，那就是实例号小的节点成为新的集群，这就避免了脑裂的存在。

资源失衡配置解决方案
所谓资源失衡配置解决方案，就是要在容灾设计之初就保障主数据中心的资源配置要多于灾备中心，使得两个数据中心节点可以获取到的仲裁资源处于不平衡状态。容灾设计的时候可以将主备数据中心的节点分布数量或者仲裁文件分布数量按照 2:1 的非平衡策略设置。那么按照集群仲裁的一般规则：发生集群分裂故障的时候，可以获得更多仲裁资源的子集将成为新的集群。当发生数据中心之间的网络故障的时候：
第一种架构，主数据中心内部两个节点可以获取到更多的网络心跳，自然会接管集群。
第二种架构，主数据中心的节点可以获取到更多的磁盘心跳，同样会接管集群。
这也符合我们设计之初衷。但是，这种方法只适合于 AA 模式的多节点集群，不适合 HA 模式的架构。

自定义优先级解决方案
自定义优先级的解决方案，其实本质上与 Oracle RAC 的仲裁算法第二条“当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。”是一样的。只不过对于 Oracle RAC ，当通过第一条规则无法判断的时候（节点获取的仲裁资源矩阵是平衡的），它默认采用了实例号定义其优先级。而其他的一些容灾方案，这个优先级定义的灵活性留给了客户。例如 VPLEX 产品，尤其是在双活架构的设计当中，有可能因为地域、设备新旧、运营管理等方面的差异，往往灾备中心的运行能力会稍差，那么发生数据中心之间隔离的这种故障时，大家往往希望保留主数据中心的运行。那么这个时候客户就可以根据主数据中心的节点标识来固定其仲裁优先级。

2. 仲裁解决方案
网络仲裁
网络资源是集群仲裁当中非常重要的一种心跳资源，因此通过第三方网络资源的可达性心跳信息来判断对称集群分裂后的新秩序也是一种非常有效的方法。一般在以存储网关实现数据双写的容灾架构当中比较常见，比如 VPLEX 、 SVC 、 MCC 等。第三方仲裁点需要满足的条件：
① 与主备两个数据中心 L3 可达，并且网络质量稳定。
② 仲裁点需要安装具备网络探测功能的虚拟服务器或物理服务器，具备运行条件。
仲裁点服务器上的软件会与组成集群的存储器网关两个节点分别发送 PING/ACK 来确认双方的健康情况，集群会把两个节点与第三方仲裁点的网络仲裁心跳看做是最终的裁判。 Vplex Witness 通过管理 IP 网络连接至两个集群节点，通过将其自身的观察与集群定期报告的信息进行协调，让集群可区分是集群内故障还是集群间链路故障，并在这些情况下自动继续相应站点上的 I/O 服务。 Vplex Witness 仅当分离规则没有定义时才会生效。当然细心的读者可能产生了一个新的问题：

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

存储仲裁
存储一般是数据库集群当中非常关键的仲裁资源，数据库集群的节点负载比较重，不像存储网关模式的集群，可以再设计与 Witness Node 的通讯接口。所以在这类技术方案的容灾设计当中，通常会用第三方存储阵列来作为集群的第三方仲裁点。例如 Oracle Extended RAC 、 HA&Oracle 、 HA&DB2 等。
a. 第三方站点放置一个存储阵列、并且与两个数据中心网络稳定可达。
b. 存储阵列以 NFS 或者 ISCSI 方式提供共享存储卷或文件服务给两个中心的集群节点。
c. 集群配置的时候，将这个共享存储卷或者文件作为集群的磁盘仲裁之一。
当双中心的集群发生隔离故障的时候，集群通过第三方的仲裁磁盘或者文件来判断集群的新秩序。

对称隔离场景
集群发生的故障场景有很多，有可能是网卡故障导致节点隔离，也有可能是链路问题导致节点隔离。链路问题本身又分很多种，有一种场景及时存在第三仲裁的场景下，依然有可能是对称平衡的状态。当两个中心之间的链路中断，但是其他各条线路都完好无损的情况下，及时存在第三方仲裁，那么集群分裂后的仲裁资源分布依然是平衡对称的，这又该如何解决呢？我们认为有两种解决方式：

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

什么是仲裁冲突？
我们知道在容灾整体设计当中，需要有网络层、计算层、数据库服务层、存储服务层等各方面的设计。他们在纵向上是叠加的形态。当数据中心之间发生线路故障的时候，数据库集群和存储网关组成的集群是两个不同的集群，他们的仲裁结果会不会不一致？
集群的仲裁是瞬间完成的，集群的仲裁触发条件有可能有片刻的先后顺序之差，数据库层的仲裁先于存储层的仲裁，那么虽然概率小，但是这个冲突是完全有可能的。但是如果存储的仲裁发生在数据库之前，理论上这个冲突是可以避免的，因为存储卷是数据库集群健康运行的前提。

如何解决仲裁冲突问题？
我们探讨它的解决方法，风险发生的引发点有两个：
① 集群的仲裁触发条件导致的仲裁顺序发生紊乱；
② 对称平衡状态下的仲裁规则冲突。
资源被 1:1 割裂之后的默认仲裁策略不一致。也就是说，只要控制这两个引发点，那么这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是 15 秒左右，而数据库仲裁触发的控制参数由 misscount 这个参数来决定，所以只要我们将 misscount 这个参数调整到 15 秒之后，也就是说理论上绝对保障存储集群仲裁在前，而数据库仲裁在后，那么第 1 个引发点就没有了。对于第二个引发点来讲，假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的 Winner 策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第 2 个引发点也就不存在了。