本文其他章节：
银行双活容灾建设方案技术手册——规划篇
银行双活容灾建设方案技术手册——实施篇
全文PDF下载：
城商银行同城双数据中心建设技术手册

1. 文档介绍

1.1目标人群

本文章适合银行从事IT建设的架构师、工程师以及主导核心系统基础架构及应用系统建设或者改造项目的项目经理等人群，可以帮助大家对项目或者技术选型及定位有一些相对比较清晰的认识，从而指导其相关的技术工作。

1.2写作目标

本随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统建设的各种行业标准以及监管标准也相应提高。那么IT系统架构的扩展性、灵活性以及容灾能力就成为衡量企业IT建设很重要的标准。本文基于某银行同城双数据中心建设过程为背景，详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。

2.分析篇

2.1双活数据中心的驱动力

近年来，随着互联网金融的快速发展，金融企业数据中心建设面临着新的挑战。那就是对RTO和RPO的极限追求。从而也就诞生了近年来的热点话题-双活数据中心建设。

那么我们为什么要建设双活数据中心，它能给我们带来什么样的价值？什么样的数据中心架构叫做双活数据中心？如何认识适合自己业务模式的双活模式？建设阶段我们应该以什么样的原则来指导我们的建设工作？具体的建设思路以及具体的建设方案应该如何把握？基于这些问题本文进行深入研究并展开探讨。

从科技工作层面来讲，其实双活数据中心并不是一个行业标准或者规范。行业的标准是对RTO和RPO约束，银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO=15分钟，RTO=30分钟。而根据国际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。双活的概念也就由此而来，为了达到国际最高标准。

那么决策是否建设双活数据中心的依据也就在于此，首先确定自己企业合适的目标，是不是要必须追求7级标准？是不是所有业务都必须追求这个目标？如果不是那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。这将决定要不要建设双活数据中心以及建设什么样的双活数据中心。

2.2定义符合自己的双活模式

2.2.1 明确双活目标

其实对于双活数据中心的定义，从来就没有一个标准的定义或者是行业标准。所有的描述或者所谓的定义暂时都来自厂商的描述。按照目前技术发展的现状以及行业建设状况调查分析，本文认为双活的基础架构基本如下图所描述：
图2.1 双活数据中心架构基础轮廓

双活模式主要分三种，主要区别在于途中（A、B、C、D、E、F几个位置的技术架构差异），接下来详细探讨。

1. 数据中心级别的广义双活

双活认定的标准以数据中心工作模式为基准，只要两个数据中心正常时都工作，灾难时能自动切换，那么认为是双活数据中心模式。如图3.1中的位置参数表示如下：

A = 业务定义（读写）
B = 业务定义（读写）
A ≠ B
E = 数据库HA模式
F = 存储复制

表3.1.1 数据中心级别双活架构

注1：数据复制可以选择存储的同步复制也可以选择数据库层面的同步复制。

表3.1.2 故障切换模型设计

这种双活架构属于广义上的双活模式，两个数据心之间除了存储端的复制，基本没有其他联系。其实这种模式的双活是传统主备模式容灾组合架构的简单升级版。唯一区别的是传统容灾模式下的存储复制是基于异步单向模式的，而双活架构下的复制是基于同步双向模式的。具体架构描述如下图:
图3.1 数据中心级双活架构

这种模式下需要的基本关键技术必备的功能如下所述：①域名解析设备需要实现动态及全局智能解析，当本地应用无法访问时，DNS能跟负载均衡设备实现联动的健康检查而侦测到这一故障。并且按照解析的动态规则实现解析变化。②负载均衡设备需要实现本地集群化，保证本地负载均衡功能的高可用性。③应用最好以虚拟化方式实现，这样可以平衡资源的严重浪费与高可用的冗余部署之间的矛盾。④数据库在两个数据中心也需要双份部署，同一个业务部署在两个数据中心的数据库节点之间没有任何联系，因为网络二层没有打通，无法实现HA。一般来讲需要手动切换。当然如果不用存储复制技术而是用的ORACLE的ADG技术或者是DB2的DR技术，那么可以实现半自动化或全自动。⑤如果采用的存储层面的复制技术，那么必须是同步复制，必须是双向复制。

2. 业务级别双活

双活认定的标准以业务是否可以在双中心内同时进行为判定标准。只要同类业务能分布在两个数据中心执行，就认为是双活数据中心模式。如图3.1中的位置参数表示如下：

A = 业务定义
B = 业务定义
A = B
D = 跨数据中心应用集群（区分优先级）
E = HA
F = HA

表3.2.1 业务级别双活架构

表3.2.1 故障切换模型设计

这种双活架构虽然实现了同类业务在前端的负载分担，但是在数据库层面还是属于单点模式。这种模式比前一种模式最大的技术变更就是要求网络上的二层打通。具体实现架构如下所示：
图3.2 业务级双活架构

以上架构，各个层面应该具备的功能描述如下：
①双中心DNS设备为主备模式，域名全局解析，DNS设备跟负载均衡设备能实现联动健康检查。②网络层面必须实现二层联通以保证数据库层面的跨数据中心HA以及应用服务器的应用大集群。③负载均衡层，如果是两个小集群方式，那么不能将其放入大二层，只保证其三层可达就可以了，否则客户端无法实现请求路由切换；如果是大集群方式，那么可以放入大二层网络，但是要设计好会话同步问题；④数据库在两个数据中心实现跨数据中心HA部署，主要是以操作系统的HA，将数据库服务作为HA的服务方式来实现，例如IBM的HyperSwap。⑤存储层面需要实现HA以及同步复制，例如IBM的SVC集群解决方案，NETAPP的MCC解决方案。

3. 应用级别的双活

应用级别的双活，本文将其定义为同一个应用系统的IO可以从两个数据中心分别访问数据库节点，当然这个访问又会分为读操作和写操作。那么相应的这种模式下的双活又分为两种：一种是读写分离的模式；另外一种是混合模式，也就是业内相对较为彻底的双活架构。如图3.1中的位置参数表示如下：

A = 业务定义
B = 业务定义
A = B
E = 数据库AA集群模式
F = HA/AA

表3.3.1 业务级别双活架构

表3.3.2 故障切换模型设计

这种双活架构虽然实现了应用IO级别的双活，是目前金融行业较为彻底的双活。具体架构如下：
图3.2 应用级双活架构

各个层面应该具备的功能与3.2区别最大的几个关键点描述如下：①数据库在两个数据中心实现跨数据中心集群模式。②存储层可以选择HA方式也可以选择EMC提供的VPLEX虚拟化集群方式。

2.2.2 明确业务连续性要求

一、银行业务连续性管理的现状与问题

近年来我国银行业业务发展迅猛，大型银行的资本总额、开户数量、业务处理量已位居世界前列，经营范围遍及全国并在海外快速扩张，一旦业务停顿，可能影响全行乃至整个金融体系的正常运转，并影响社会稳定。因此，数据大集中后，银行业积极推进灾难恢复、应急管理和IT服务持续性管理有关工作。

初步构建了信息系统应急管理体系。确立了应急管理组织架构，区分信息系统突发事件等级，形成统一的应急响应流程和通知报告程序。并注重与地方政府、新闻媒体的沟通协调，加强机构内部各职能部门的协调配合，增强了突发事件的应对处置能力。

积极开展灾难备份系统建设工作。按照“统筹规划、资源共享、平战结合”的原则，大型和股份制银行积极推进“两地三中心”的建设，建立了同城和异地灾备中心，应对建筑类故障和区域性（例如地震、洪灾、战争等）灾难。大多数商业银行基本建立了核心业务的灾难恢复系统，保障核心业务数据安全和灾难发生时核心业务的恢复。

提升危机处理能力。积极开展应急演练和灾难恢复演练，加强银行内部各部门，及银行与通讯、电力等外部机构的联防协作。实施了包括核心系统在内的重要业务系统切换演练，提高银行应对信息系统突发事件的能力和信心。

二、我国银行业在业务连续性管理方面的不足

对业务连续性管理的重要性和价值认识不足，尚未形成有效的BCM管理体系。部分银行对业务持续性管理缺乏必要的理解，认为“投入大、收益小”，对金融服务持续性与公众生活、经济社会正常运转的紧密关系缺乏足够的认识，银行改善BCM管理的动力大多来自国家或监管政策压力，主观意愿不足，将业务持续性管理等同于信息系统的灾难恢复、日常故障处置的模糊意识大量存在，参与的多为IT部门、部分人员，业务连续性计划仅作为事件处理的应急预案，未建立起BCM的管理组织体系。

应急预案体系不够完整，业务应急机制匮乏，外部应急协调不足。大多数银行没有业务层面应急管理机制的开发和演练，场地应急、人员应急等BCM重要环节缺乏实质性的建设。信息系统应急预案流于形式，不少银行对业务连续性的认识不足，认为业务连续性就是信息系统应急恢复，就是科技部门的责任，没有在全行层面建立整体管理体系，缺乏科技与业务、公关等部门的联动，缺少业务应急手段和客户安抚、媒体公关等处理措施。业务部门配合不足、业务人员参与力度不大、业务覆盖面不全，一旦出现意外，应急预案可能无法发挥作用，与外部机构（如政府机构、公共事业机构、银行同业、外部合作金融服务机构等）的协作联动不足。多数银行业务连续性演练仅停留在信息科技层面，缺乏涵盖业务、技术和后勤保障等多方面的全行性演练，导致应急和灾备能力有效性无法得到验证。

业务的灾难恢复目标不明确、信息系统灾备覆盖面不够、灾备资源的有效性保障不足。缺乏风险评估和业务影响分析，缺乏对业务中断损失与灾备建设投入的成本效益测算，导致灾备系统、科技应急体系建设盲目投入、缺乏规划，灾备系统覆盖不足等问题。虽然银行大多已建立了灾备中心，但是业务分类分级及差异化的业务恢复目标还不十分明确，部分银行灾备中心只停留在核心账务数据保护的层面，一旦发生灾难，很难实现重要交易渠道的恢复、重要客户及交易数据的恢复。灾备切换演练未能真正贴近实战，灾备人员配置、系统演练有效性验证等方面存在不足。

三、加强银行业务连续性管理的意义

信息科技连续运作的根本目标是保障业务的持续性，商业银行更应从业务角度出发，以业务持续为目标，形成应对突发事件、灾害灾难的各部门协同管理体系，加强顶层设计。随着经济、金融全球化和信息技术发展加速，信息科技的广泛应用使得金融机构之间的关联度大大提升，各个国家金融机构间的外部依赖度也不断加强，单家机构的故障可能使关联金融机构遭受损失，并且风险扩散的速度更快、范围更大，外部性大大增强，因此推动和加强银行业的业务连续性体系建设，从全行层面进行规划，进一步加强整体业务连续性规范和深层次机制建设，实现对各种事故和灾难的有效应对，维护正常的经济金融运行秩序非常迫切。

从长远来看，BCM的价值并非仅仅是企业应对灾难、提高生存能力的工具，在许多发达国家金融行业，BCM已成为改善经营管理、承担社会责任的基本准则，是银行提高风险预测和快速应对能力，适应需求变化和威胁，保持竞争优势的重要基础。可以说，业务连续性管理直接关系到中国银行业的国际竞争力，对整个行业长期、可持续健康发展具有深远的意义。

为此，银监会在充分借鉴新加坡金管局《SINGAPORE STANDARD SS 507》、英国《BSI PAS 56》及一些国际先进银行的业务连续性管理经验基础上，结合我国国情和商业银行实际情况，编写并正式发布了《商业银行业务连续性监管指引》（下称《指引》）。

2.2.3 明确整体容灾架构

本节将重点通过架构对比、功能对比、实现复杂度对比等方面来分析2.2.1节当中所述的三种双活架构的优劣势，以帮助明确企业自己的整体容灾架构。
表3.4 双活架构对比

2.2.4 明确企业自身科技实力

为什么要明确银行自身的科技实力，因为科技实力直接决定企业对双活容灾体系的建设水平和掌控能力。在数据中心容灾架构建设之间必须明确以下几个问题，以对容灾建设起到正确的决策作用：

（1）运维管理能力
（2）应急处理能力
（3）对运营商的掌控能力
（4）科技项目质量保障能力

如果运维管理能力和应急处理的能力不足的话，那么容灾架构越简单越好，复杂了反而是一种巨大的风险；如果对运营商的掌控能力不足的话，那么双数据中心之间的复制技术选型和具体的数据传输量和数据传输类型的设计就是整个容灾架构的最关键的地方了，一定需要将链路的风险考虑到第一位；如果科技项目质量保障能力不足的话，那么在整个建设过程当中就很难把握其中的关键架构实施的质量，从而也就无法保障整体架构的完整性。

2.3实现双活需要考虑的关键因素

2.3.1 数据复制技术

2.3.1.1 数据复制在容灾中的必要性

1. RPO保障
如果没有数据复制技术，那么容灾也就无从谈起。当面临站点及故障时，由于没有数据复制技术的支撑，我们的数据无法在其他站点再现，这将意味着RPO将无法保障。对于一个金融企业来讲，最终要的就是客户的数据，它是企业的生命。从这个意义上来讲，金融企业不能没有容灾体系，容灾体系的前提条件是能够实现数据复制。那么数据复制的效率如何，复制的效果如何，复制技术的先进与否也就决定了金融企业生命线的稳固与否。

2. RTO保障
所谓RTO就是在容灾系统在面临站点级故障时，多长时间能够恢复业务。假设站点故障恢复的时间不可容忍或者根本没有可能，那么业务必须能够切到另外一个数据中心，从数据、应用以及网络层都需要具备这个切换能力。但是最终的目的就是要保障业务能正常恢复，而业务恢复的前提条件就是数据，没有数据的应用切换和网络切换没有任何意义。也就是说数据恢复是应用切换以及网络切换的前提条件，从这个意义上讲，数据复制效率和效果直接决定了一些列切换，也就是它使得RTO成为可能。

2.3.1.2 评价数据复制技术的维度分析

对于数据复制来讲，我们可以从多个层面、多种技术去实现。各有各的特点，那么究竟哪一种数据复制技术更适合我们？活着说哪一种复制技术更科学合理？这需要一系列从不同纬度进行的科学评估。本文认为应该从以下几个方面来展开分析，并结合我们自己的需求来选择合理的数据复制方案。

一、投资成本分析
建设任何一个项目，投资成本的分析都是必不可少的分析维度。对数据复制技术的投资成本分析来讲，我们需要从它的首次建设成本、持续维护成本以及容灾管理成本等多方面去考虑。

二、技术成熟度及健壮性分析
对于数据复制技术的成熟度和健壮性分析来讲，一方面我们要从技术本身的原理上来分析，另外我们还需要从技术的发展以及应用范围以及应用的持久稳定性等方面来考虑。

三、风险评估分析
数据复制技术本身来讲是要帮助我们解决站点级故障带给我们的IT风险，但是对于技术应用本身来讲，它也会存在一些技术风险。比如说特殊场合下的一些技术风险、容灾管理过程中的一些风险、极端场合下的一些技术风险等等。

四、功能拓展性分析
对于数据复制技术本身来讲，其主要功能就是完成数据的复制。但是在完成数据复制的同时，由于其架构的特点以及技术特点等因素有可能对于我们的应用产生积极的拓展性作用，也有可能限制了我们的应用架构模式，还有可能对我们的基础架构扩展性以及灵活性造成一定的限制。

2.3.2 数据逻辑错误同步

存储层面的复制技术基本以存储块儿为单位进行的数据复制，对于块儿内数据的应用层面的逻辑错误是没有完整校验的，它只保证存储块儿的可用性，这个可用性仅仅保障存储层面的卷可用，并不能完全保证应用层面的数据可用性。假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。

对于这个问题发生的概率是非常低的，但是毕竟存在这个风险，解决这个问题的方法就是对于重要数据增加数据库层面的数据复制方案，比如ORACLE的ADG，比如DB2的HADR。当然这个可能会带来一些功能上的重复，因为无论是存储复制还是数据库复制，其实都是数据保障的手段。但是存储的复制解决的问题不仅仅是数据库层的数据保护，所以在基础架构中的角色，他还是不能丢弃的。

2.3.3 集群仲裁一致性

所谓的仲裁一致性问题，是指双中心之间的VPlex存储集群和数据库RAC集群的仲裁结果是否能保证一致性。VPlex集群是靠仲裁站点分别于两个站点之间的网络连通性来判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。二者仲裁时的一致性如何保障是非常重要的一个问题。假设在发生站点级别故障时，数据库集群首先根据网络故障触发仲裁，判定站点A的节点存活。而存储随后再发生存储集群的仲裁，这个时候如果根据Witness判定的结果恰恰仲裁委站点B的节点存活。那么数据库集群整体就会宕掉，这对于业务来讲就是一个灾难。

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

2.3.4 双中心之间的通讯

双中心间的通讯不可控问题主要表现为两个方面：链路稳定状况不可控；IO延时指标不可控。因为双中心之间的链路是通过租用运营商的裸光纤链路实现的，那么这其中会经历很多的中继设备及节点。无论从管理上还是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定，也就是说数据库节点之间私网传输的延时会经常出现长延时情况，这势必导致这种延时会加倍放大到数据库节点之间的读写热点竞争上。由于数据库集群之间的数据传输量非常大（缓存、锁、心跳等），在读写热点相对突出的业务上，轻则导致数据库读写性能灾难，重则导致数据库节点直接处于僵死状态。另外，链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁频繁发生，这对于业务连续性更是一个灾难。

对于这个问题来讲，就目前金融行业的传统数据架构来讲，并没有一个十足的解决方案。我们只能通过以下措施来减少这种问题带给我们的风险。

1）业务层面需要进行拆分重组：按照IO特点进行合理拆分，将读写业务尽量分布于不同节点上，减少节点间的锁竞争。按照业务将数据库表进行分区，避免在数据库写上的数据热点块儿。例如，对于银行核心系统来讲，尤其是要将批量业务和联机业务区分对待，批量业务的热点以及数据量非常之巨大，所以一定要将批量业务的数据库读写放在单边实现。对于联机业务来讲可以根据热点状况以及链路质量评测结果可以尝试实现双中心同时读写，但是本文建议对于这种重量级的业务还是要从业务层尽量实现应用上的读写分离，或者在应用层双中心部署而在数据库层将数据引到单边来做。

2）双中心间通讯的整体控制，具体包括对通讯带宽的优先级管理、对通讯的实时监控和控制、对跨中心数据传输的严格策略把控。例如：优先保障存储和数据库通讯的优先级和带宽，严格的规则算法和优先级限定VMOTION、DRS等行为的跨中心随意性，从LTM负载分发上尽可能保障正常情况下纵向IO的单中心效率策略，故障情况下保障跨中心访问的科学性。DWDM上设置双中心间通讯带宽的逻辑隔离以及实时可控。

2.3.5 应用集群跨中心会话同步

网络二层打通的情况下，GTM和LTM的跨数据中心集群就成为可能，但是同时也带来一个问题，那就是会话的跨中心同步问题。毕竟跨地域的集群节点之间会话同步会受到距离延时等多方面影响，而这个会话同步又是应用负载集群中很重要的一个稳定性因素。如果LTM或者GTM的节点之间的会话不同步，那么最终会导致应用负载在故障情况下无法正常切换。

对于这个问题来讲，本案例采用的是中心内双节点小集群，然后利用GTM解析的全局性来完成应用负载功能的全局性。假设单中心内LTM集群发生故障时，我们完全可以利用GTM和LTM的联动性来感知到这一故障，而从GTM解析层面将数据流引入另外一个数据中心的LTM集群。功能上，这种模式同样实现应用负载的全局性，同时又避免了双中心LTM节点会话不一致的问题。