银行双活容灾建设方案技术手册

1、 银行双活容灾建设方案技术手册 本手册以银行同城双数据中心建设过程为背景，详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。本手册适合银行从事IT建设的架构师、工程师以及主导核心系统基础架构及应用系统建设或者改造项目的项目经理等人群，可以帮助大家对项目或者技术选型及定位有一些相对比较清晰的认识，从而指导其相关的技术工作。目 录1. 文档介绍1.1 目标人群1.2 写作目标2.分析篇2.1 双活数据中心的驱动力2.2 定义符合自己的双活模式2.2.1 明确双活目标2.2.2 明确业务连续性要求2.2

2、.3 明确整体容灾架构2.2.4 明确企业自身科技实力2.3 实现双活需要考虑的关键因素2.3.1 数据复制技术 数据复制在容灾中的必要性 评价数据复制技术的维度分析2.3.2 数据逻辑错误同步2.3.3 集群仲裁一致性2.3.4 双中心之间的通讯2.3.5 应用集群跨中心会话同步3.规划篇3.1 应用层数据复制架构选型规划3.1.1 应用事务日志回放技术3.1.2 基于系统级逻辑卷镜像技术3.2 存储层数据复制架构选型规划3.2.1 基于存储网关双写复制技术3.2.2 基于存储底层块儿复制技术3.3 整体架构各功能层分解规划设计3.3.1 双数据中心基础架构设计3.3.2 基础架构的横向视图

3、分解3.3.3 基础架构的纵向视图分解3.4 核心系统双活基础架构规划设计4.实施篇4.1 某银行双活设计案例4.1.1 XX 平台双活数据中心建设需求4.1.2 XX 平台数据中心设计4.1.3 应用服务控制与负载均衡设计4.1.4 数据中心安全设计4.1.5 数据中心运维保障体系建设4.1.6 采购需求4.2 某金融企业双活设计案例4.2.1 项目介绍4.2.2 存储设计实施4.2.3 SAN 网络规划4.2.4 数据的迁移1. 文档介绍1.1 目标人群本文章适合银行从事 IT 建设的架构师、工程师以及主导核心系统基础架构及应用系统建设或者改造项目的项目经理等人群， 可以帮助大家对项目或者

4、技术选型及定位有一些相对比较清晰的认识，从而指导其相关的技术工作。1.2 写作目标随着全球 IT 产业的飞速发展， 金融行业的 IT 建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业 IT 系统建设的各种行业标准以及监管标准也相应提高。那么 IT 系统架构的扩展性、灵活性以及容灾能力就成为衡量企业 IT 建设很重要的标准。本文基于银行同城双数据中心建设过程为背景，详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程， 旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。2.分析篇2.1 双活数据中心的驱动力近年来，随着互联网金融的快速发展，金

5、融企业数据中心建设面临着新的挑战。那就是对RTO和RPO的极限追求。从而也就诞生了近年来的热点话题双活数据中心建设。那么我们为什么要建设双活数据中心，它能给我们带来什么样的价值？什么样的数据中心架构叫做双活数据中心？如何认识适合自己业务模式的双活模式？建设阶段我们应该以什么样的原则来指导我们的建设工作？具体的建设思路以及具体的建设方案应该如何把握？基于这些问题，本文将进行深入研究并展开探讨。从科技工作层面来讲，其实双活数据中心并不是一个行业标准或者规范。行业的标准是对RTO和RPO约束，银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO=15分钟，RTO=30分钟。而根据国

6、际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。双活的概念也就由此而来，为了达到国际最高标准。那么决策是否建设双活数据中心的依据也就在于此，首先确定自己企业合适的目标，是不是要必须追求7级标准？是不是所有业务都必须追求这个目标？如果不是，那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。这将决定要不要建设双活数据中心以及建设什么样的双活数据中心。2.2 定义符合自己的双活模式2.2.1 明确双活目标其实对于双活数据中心的定义，从来就没有一个标准的定义或者是行业标准。所有的描述或者所谓的定义暂时都来自厂商的描述。按照目前技术发展

7、的现状以及行业建设状况调查分析，本文认为双活的基础架构基本如下图所描述：双活数据中心架构基础轮廓双活模式主要分三种，主要区别在于途中（A、B、C、D、E、F几个位置的技术架构差异），接下来详细探讨。1. 数据中心级别的广义双活双活认定的标准以数据中心工作模式为基准，只要两个数据中心正常时都工作，灾难时能自动切换，那么认为是双活数据中心模式。如下图中的位置参数表示如下：A = 业务定义（读写）B = 业务定义（读写）A BE = 数据库HA模式F = 存储复制数据中心级别双活架构注1：数据复制可以选择存储的同步复制也可以选择数据库层面的同步复制。故障切换模型设计这种双活架构属于广义上的双活模式，

8、两个数据心之间除了存储端的复制，基本没有其他联系。其实这种模式的双活是传统主备模式容灾组合架构的简单升级版。唯一区别的是传统容灾模式下的存储复制是基于异步单向模式的，而双活架构下的复制是基于同步双向模式的。具体架构描述如下图:数据中心级双活架构这种模式下需要的基本关键技术必备的功能如下所述：域名解析设备需要实现动态及全局智能解析，当本地应用无法访问时，DNS能跟负载均衡设备实现联动的健康检查而侦测到这一故障。并且按照解析的动态规则实现解析变化。负载均衡设备需要实现本地集群化，保证本地负载均衡功能的高可用性。应用最好以虚拟化方式实现，这样可以平衡资源的严重浪费与高可用的冗余部署之间的矛盾。数据库

9、在两个数据中心也需要双份部署，同一个业务部署在两个数据中心的数据库节点之间没有任何联系，因为网络二层没有打通，无法实现HA。一般来讲需要手动切换。当然如果不用存储复制技术而是用的ORACLE的ADG技术或者是DB2的DR技术，那么可以实现半自动化或全自动。如果采用的存储层面的复制技术，那么必须是同步复制，必须是双向复制。2. 业务级别双活双活认定的标准以业务是否可以在双中心内同时进行为判定标准。只要同类业务能分布在两个数据中心执行，就认为是双活数据中心模式。如下图中的位置参数表示如下：A = 业务定义B = 业务定义A = BD = 跨数据中心应用集群（区分优先级）E = HAF = HA业务

10、级别双活架构故障切换模型设计这种双活架构虽然实现了同类业务在前端的负载分担，但是在数据库层面还是属于单点模式。这种模式比前一种模式最大的技术变更就是要求网络上的二层打通。具体实现架构如下所示：业务级双活架构以上架构，各个层面应该具备的功能描述如下：双中心DNS设备为主备模式，域名全局解析，DNS设备跟负载均衡设备能实现联动健康检查。网络层面必须实现二层联通以保证数据库层面的跨数据中心HA以及应用服务器的应用大集群。负载均衡层，如果是两个小集群方式，那么不能将其放入大二层，只保证其三层可达就可以了，否则客户端无法实现请求路由切换；如果是大集群方式，那么可以放入大二层网络，但是要设计好会话同步问题

11、；数据库在两个数据中心实现跨数据中心HA部署，主要是以操作系统的HA，将数据库服务作为HA的服务方式来实现，例如IBM的HyperSwap。存储层面需要实现HA以及同步复制，例如IBM的SVC集群解决方案，NETAPP的MCC解决方案。3. 应用级别的双活应用级别的双活，本文将其定义为同一个应用系统的IO可以从两个数据中心分别访问数据库节点，当然这个访问又会分为读操作和写操作。那么相应的这种模式下的双活又分为两种：一种是读写分离的模式；另外一种是混合模式，也就是业内相对较为彻底的双活架构。如下图中的位置参数表示如下：A = 业务定义B = 业务定义A = BE = 数据库AA集群模式F = H

12、A/AA业务级别双活架构故障切换模型设计这种双活架构虽然实现了应用IO级别的双活，是目前金融行业较为彻底的双活。具体架构如下：应用级双活架构各个层面应该具备的功能与前述架构区别最大的几个关键点描述如下：数据库在两个数据中心实现跨数据中心集群模式。存储层可以选择HA方式也可以选择EMC提供的VPLEX虚拟化集群方式。2.2.2 明确业务连续性要求一、银行业务连续性管理的现状与问题近年来我国银行业业务发展迅猛，大型银行的资本总额、开户数量、业务处理量已位居世界前列，经营范围遍及全国并在海外快速扩张，一旦业务停顿，可能影响全行乃至整个金融体系的正常运转，并影响社会稳定。因此，数据大集中后，银行业积极

13、推进灾难恢复、应急管理和IT服务持续性管理有关工作。初步构建了信息系统应急管理体系。确立了应急管理组织架构，区分信息系统突发事件等级，形成统一的应急响应流程和通知报告程序。并注重与地方政府、新闻媒体的沟通协调，加强机构内部各职能部门的协调配合，增强了突发事件的应对处置能力。积极开展灾难备份系统建设工作。按照“统筹规划、资源共享、平战结合”的原则，大型和股份制银行积极推进“两地三中心”的建设，建立了同城和异地灾备中心，应对建筑类故障和区域性（例如地震、洪灾、战争等）灾难。大多数商业银行基本建立了核心业务的灾难恢复系统，保障核心业务数据安全和灾难发生时核心业务的恢复。提升危机处理能力。积极开展应急

14、演练和灾难恢复演练，加强银行内部各部门，及银行与通讯、电力等外部机构的联防协作。实施了包括核心系统在内的重要业务系统切换演练，提高银行应对信息系统突发事件的能力和信心。二、我国银行业在业务连续性管理方面的不足对业务连续性管理的重要性和价值认识不足，尚未形成有效的BCM管理体系。部分银行对业务持续性管理缺乏必要的理解，认为“投入大、收益小”，对金融服务持续性与公众生活、经济社会正常运转的紧密关系缺乏足够的认识，银行改善BCM管理的动力大多来自国家或监管政策压力，主观意愿不足，将业务持续性管理等同于信息系统的灾难恢复、日常故障处置的模糊意识大量存在，参与的多为IT部门、部分人员，业务连续性计划仅作

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

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

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

18、效应对，维护正常的经济金融运行秩序非常迫切。从长远来看，BCM的价值并非仅仅是企业应对灾难、提高生存能力的工具，在许多发达国家金融行业，BCM已成为改善经营管理、承担社会责任的基本准则，是银行提高风险预测和快速应对能力，适应需求变化和威胁，保持竞争优势的重要基础。可以说，业务连续性管理直接关系到中国银行业的国际竞争力，对整个行业长期、可持续健康发展具有深远的意义。为此，银监会在充分借鉴新加坡金管局SINGAPORE STANDARD SS 507、英国BSI PAS 56及一些国际先进银行的业务连续性管理经验基础上，结合我国国情和商业银行实际情况，编写并正式发布了商业银行业务连续性监管指引（下

19、称指引）。2.2.3 明确整体容灾架构本节将重点通过架构对比、功能对比、实现复杂度对比等方面来分析三种双活架构的优劣势，以帮助明确企业自己的整体容灾架构。双活架构对比2.2.4 明确企业自身科技实力为什么要明确银行自身的科技实力，因为科技实力直接决定企业对双活容灾体系的建设水平和掌控能力。在数据中心容灾架构建设之间必须明确以下几个问题，以对容灾建设起到正确的决策作用：（1）运维管理能力（2）应急处理能力（3）对运营商的掌控能力（4）科技项目质量保障能力如果运维管理能力和应急处理的能力不足的话，那么容灾架构越简单越好，复杂了反而是一种巨大的风险；如果对运营商的掌控能力不足的话，那么双数据中心之间

20、的复制技术选型和具体的数据传输量和数据传输类型的设计就是整个容灾架构的最关键的地方了，一定需要将链路的风险考虑到第一位；如果科技项目质量保障能力不足的话，那么在整个建设过程当中就很难把握其中的关键架构实施的质量，从而也就无法保障整体架构的完整性。2.3 实现双活需要考虑的关键因素2.3.1 数据复制技术 数据复制在容灾中的必要性1. RPO保障如果没有数据复制技术，那么容灾也就无从谈起。当面临站点及故障时，由于没有数据复制技术的支撑，我们的数据无法在其他站点再现，这将意味着RPO将无法保障。对于一个金融企业来讲，最终要的就是客户的数据，它是企业的生命。从这个意义上来讲，金融企业不能没有容灾体系

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

22、数据复制技术的维度分析对于数据复制来讲，我们可以从多个层面、多种技术去实现。各有各的特点，那么究竟哪一种数据复制技术更适合我们？活着说哪一种复制技术更科学合理？这需要一系列从不同纬度进行的科学评估。本文认为应该从以下几个方面来展开分析，并结合我们自己的需求来选择合理的数据复制方案。一、投资成本分析建设任何一个项目，投资成本的分析都是必不可少的分析维度。对数据复制技术的投资成本分析来讲，我们需要从它的首次建设成本、持续维护成本以及容灾管理成本等多方面去考虑。二、技术成熟度及健壮性分析对于数据复制技术的成熟度和健壮性分析来讲，一方面我们要从技术本身的原理上来分析，另外我们还需要从技术的发展以及应用

23、范围以及应用的持久稳定性等方面来考虑。三、风险评估分析数据复制技术本身来讲是要帮助我们解决站点级故障带给我们的IT风险，但是对于技术应用本身来讲，它也会存在一些技术风险。比如说特殊场合下的一些技术风险、容灾管理过程中的一些风险、极端场合下的一些技术风险等等。四、功能拓展性分析对于数据复制技术本身来讲，其主要功能就是完成数据的复制。但是在完成数据复制的同时，由于其架构的特点以及技术特点等因素有可能对于我们的应用产生积极的拓展性作用，也有可能限制了我们的应用架构模式，还有可能对我们的基础架构扩展性以及灵活性造成一定的限制。2.3.2 数据逻辑错误同步存储层面的复制技术基本以存储块儿为单位进行的数据

24、复制，对于块儿内数据的应用层面的逻辑错误是没有完整校验的，它只保证存储块儿的可用性，这个可用性仅仅保障存储层面的卷可用，并不能完全保证应用层面的数据可用性。假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。对于这个问题发生的概率是非常低的，但是毕竟存在这个风险，解决这个问题的方法就是对于重要数据增加数据库层面的数据复制方案，比如ORACLE的ADG，比如DB2的HADR。当然这个可能会带来一些功能上的重复，因为无论是存储复制还是数据库复制，其实都是数据保障的手段。但是存储的复制解决的问题不仅仅是数

25、据库层的数据保护，所以在基础架构中的角色，他还是不能丢弃的。2.3.3 集群仲裁一致性所谓的仲裁一致性问题，是指双中心之间的VPlex存储集群和数据库RAC集群的仲裁结果是否能保证一致性。VPlex集群是靠仲裁站点分别于两个站点之间的网络连通性来判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。二者仲裁时的一致性如何保障是非常重要的一个问题。假设在发生站点级别故障时，数据库集群首先根据网络故障触发仲裁，判定站点A的节点存活。而存储随后再发生存储集群的仲裁，这个时候如果根据Witness判定的结果恰恰仲裁委站点B的节点存活

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

27、，存储集群会有一个默认的Winner策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第二个引发点也就不存在了。2.3.4 双中心之间的通讯双中心间的通讯不可控问题主要表现为两个方面：链路稳定状况不可控；IO延时指标不可控。因为双中心之间的链路是通过租用运营商的裸光纤链路实现的，那么这其中会经历很多的中继设备及节点。无论从管理上还是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定，也就是说数据库节点之间私网传输的延时会经常出现长延时情况，这势必导致这种延时会加倍放大到数据库节点之间的读写热点竞争上。由

28、于数据库集群之间的数据传输量非常大（缓存、锁、心跳等），在读写热点相对突出的业务上，轻则导致数据库读写性能灾难，重则导致数据库节点直接处于僵死状态。另外，链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁频繁发生，这对于业务连续性更是一个灾难。对于这个问题来讲，就目前金融行业的传统数据架构来讲，并没有一个十足的解决方案。我们只能通过以下措施来减少这种问题带给我们的风险。1）业务层面需要进行拆分重组：按照IO特点进行合理拆分，将读写业务尽量分布于不同节点上，减少节点间的锁竞争。按照业务将数据库表进行分区，避免在数据库写上的数据热点块儿。例如，对于银行核心系统来讲，尤其是要将批量业务和联机业务

29、区分对待，批量业务的热点以及数据量非常之巨大，所以一定要将批量业务的数据库读写放在单边实现。对于联机业务来讲可以根据热点状况以及链路质量评测结果可以尝试实现双中心同时读写，但是本文建议对于这种重量级的业务还是要从业务层尽量实现应用上的读写分离，或者在应用层双中心部署而在数据库层将数据引到单边来做。2）双中心间通讯的整体控制，具体包括对通讯带宽的优先级管理、对通讯的实时监控和控制、对跨中心数据传输的严格策略把控。例如：优先保障存储和数据库通讯的优先级和带宽，严格的规则算法和优先级限定VMOTION、DRS等行为的跨中心随意性，从LTM负载分发上尽可能保障正常情况下纵向IO的单中心效率策略，故障情

30、况下保障跨中心访问的科学性。DWDM上设置双中心间通讯带宽的逻辑隔离以及实时可控。2.3.5 应用集群跨中心会话同步网络二层打通的情况下，GTM和LTM的跨数据中心集群就成为可能，但是同时也带来一个问题，那就是会话的跨中心同步问题。毕竟跨地域的集群节点之间会话同步会受到距离延时等多方面影响，而这个会话同步又是应用负载集群中很重要的一个稳定性因素。如果LTM或者GTM的节点之间的会话不同步，那么最终会导致应用负载在故障情况下无法正常切换。对于这个问题来讲，本案例采用的是中心内双节点小集群，然后利用GTM解析的全局性来完成应用负载功能的全局性。假设单中心内LTM集群发生故障时，我们完全可以利用GT

31、M和LTM的联动性来感知到这一故障，而从GTM解析层面将数据流引入另外一个数据中心的LTM集群。功能上，这种模式同样实现应用负载的全局性，同时又避免了双中心LTM节点会话不一致的问题。3. 规划篇3.1 应用层数据复制架构选型规划3.1.1 应用事务日志回放技术下图是Oracle数据库层面的数据复制技术（ADG）的架构原理图。对于该架构原理图，本文从其实现的基本条件、数据复制原理、数据复制的模式以及数据复制的关键因素等几个方面来进行深度剖析。Oracle Active Data Guard 前提条件容灾站点之间需要有三层以太网连通，软件层面需要数据库的集群软件模块（Oracle Active

32、Data Gurard）或者是db2 purscale hadr。服务器层面需要至少两套服务器系统分别部署于两个数据中心。存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。 复制原理对于主站点的数据库来讲，客户端的数据更新请求首先要由日志写入进程写到重做日志当中，然后由数据写进程再周期性地写入数据文件当中。重做日志当中以SCN为数据库独有的时间搓序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。那么对于配置了Active Data Guard的数据库读写的完成在以上所述过程中，日志写进程在本地日志文件写入过程的

33、同时，日志传输进程会将缓存里面的重做日志通过ADG传输给灾备站点的备库实例，备库实例的日志接收进程根据接受到的重做日志在备库上重新执行数据库的更新操作，从而保证主库和备库的事务性更新行为一致性，最终保证数据的一致。当然也有一个前提条件，那就是在ADG作用之前，必须保证备库的数据保持与主库的某一固定时间点的完整副本，这需要靠传统数据备份技术来实现备库的初始数据复制。因为事务复制的本质是行为复制，那么行为作用的初始数据副本必须保持一致，才能保证最终两副本的一致性。对于事务日志的复制技术，本文根据主库IO周期特点可以分为绝对同步模式、近似同步模式和异步模式三种。绝对同步模式是指主库的一个完整更新事务

34、的结束既要包括主库的重做日志落盘也要包括备库的重做日志落盘，也就是说备库重做日志落盘之后返回给主库，主库才能执行下一个事务。近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。异步模式是指主库只保证本地重做日志落盘，并不会等待备库重做日志落盘的返回信号。在后两种模式下，当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。第二是日志发

35、送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。 关键因素基于事务日志回放技术的数据复制架构，从技术规划上以及运维管理层面上有几个关键因素需要把握才能将这种数据复制技术运用自如，才能帮我们真正实现高标准的容灾体系建设。重做日志管理策略设计我们知道对于数据库来讲，我们是靠其在线重做日志和离线重做日志来进行数据恢复的。对于离线重做日志也就是归档日志，我们是需要周期性备份并删除的，否则离线重做日志就会无限占用数据库有限的存储资源。那么对于事务日志型数据复制架构来讲，无论是主库还是备库，都需要有合理的日志管理策略来配合才能正常运行。策略的规划和

36、设计需要把握以下几个原则：1)完成应用的日志要及时转储，包括主库传输完毕的归档和备库应用完毕的归档日志。2)没有完成应用的日志必须能够保留，主库没有传输到备库的归档日志如果被提前转储会造成备库数据丢失，备库没有被应用的日志如果转储，备库同样会丢失数据。3)存储资源的科学规划，如果主备库暂时中断，又因为原则2导致归档日志堆积，那么势必造成存储资源的需求超过正常时刻的存储需求量，如果存储资源不够，又会造成数据库发生宕机事故。以上各个原则的科学设计既需要依赖于数据库参数的合理设置，又需要依赖于备份工具的转储策略合理配合，同时更需要根据不同的业务系统以及负载特点，通过历史数据评估以及仿真测试数据来设计

37、合理的数值并进行动态评估和优化。架构扩展性及灵活性在今天的互联网线上时代，系统架构的扩展性和灵活性显得尤为重要。对于容灾架构来讲，它的扩展性和灵活性同样非常重要。对于业务型的数据复制架构来讲，它有两种基本架构：级联架构和串联架构。级联架构是指一点为主多点为备，串联架构是指主备模式依次类推。级联架构更有利于主库的多点保障，串联架构更有利于主库的性能保障。具体采用什么样的架构组合，是要根据主库数据的具体业务需求进行合理评估和设计。容灾切换管理主备库的切换，包括两种类型的切换：Fail Over & Switch Over。Fail Over是指故障情况下的强制切换，Switch Over是指计划性

38、的切换。无论是哪种切换首先是要保障备库数据和主库数据一致或者可容忍范围内的近似一致。其次当数据发生切换时，实际上主库的服务IP地址就会转化成备库的服务地址，无论是通过域名转换还是通过应用重连的方式都需要保障上层的服务地址能够无缝切换。最后切换之后，原来的主库如果没有时间戳恢复功能的话，那么原主库里面的数据就会变成无效数据，需要重新初始化数据副本。但是如果保持时间戳恢复功能的化，就会巨大的存储空间消耗。3.1.2 基于系统级逻辑卷镜像技术下面三张图都是基于系统级逻辑卷镜像技术实现的数据双重复制。图2-1是基于ORACLE自动存储卷管理技术实现的ASM磁盘卷镜像复制技术；图2-2是基于UNIX存储

39、卷管理（LVM）实现的逻辑卷镜像技术；图2-3是基于IBM GPFS分布式文件系统底层逻辑磁盘镜像实现的数据复制。三种技术虽然依赖的具体技术不同，但是其底层原理都是基于系统层面的双写实现的数据复制。图2-1 ORACLE ASM复制镜像架构图2-2 LVM镜像复制架构图2-3分布式文件系统GPFS镜像复制架构 前提条件容灾站点之间需要SAN环境联通。软件层面，架构一需要具备ORACLE集群软件当中的自动存储卷管理模块，架构二需要借助UNIX操作系统层的逻辑卷管理器，架构三需要借助GPFS或者类似的分布式文件系统软件。存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间

40、独立。 复制原理对于ASM和LVM模式来讲，都是将底层来自不同站点的两个物理存储卷作为镜像对组合成一个可用的逻辑存储卷提供给上层应用来存放数据，本地物理卷和远程物理卷分别是由存储经过本地SAN环境以及跨数据中心SAN环境提供给服务器操作系统层。LVM是对操作系统的PP写入进行实时双向复制，而ASM是对Oracle数据文件AU写入进行实时双向复制。本地写完并且远端写完才能算是一个完整的写入，假设远端存储卷写入超时就会被标为故障或者是离线状态，当远端存储写入恢复之后，对于LVM来讲需要重新进行手动同步实现镜像副本完全一致。而对于ASM来讲，会有一个短时间内的日志记录会帮助恢复离线镜像恢复数据，但是

41、如果超过这个时间，同样需要一个全新的同步来保证数据的一致性。二者的区别在于LVM的逻辑卷与物理卷的映射关系在创建逻辑卷的时候就已经定义好了，所以对于坏块儿问题，LVM无法完成块儿指针的动态转移。而ASM是在数据写入时才会分配具体的AU，完全可以做到通过指针转移的方式避免坏块儿导致的数据写入失败问题。对于GPFS模式来讲，它是通过将底层来自不同站点的两个物理存储卷归属到不同的Failure Group当中，然后由这些物理存储卷经过文件系统格式化形成分布式文件系统，提供给上层应用以文件的形式写入数据。文件本身会被GPFS文件系统打散形成若干文件碎片，这些碎片在落盘时分别落入不同Failure Gr

42、oup当中的物理磁盘，从而保证底层数据的双副本。这种模式与前两种模式的最大区别在于它的数据落盘是根据NSD磁盘定义的服务实例顺序来决定的，正常情况下我们需要定义本站点的服务节点为磁盘的主服务节点，这样的话两个镜像写入的时候是靠GPFS位于不同中心的两个服务实例节点分别写入，两个服务实例之间也需要私有协议的交互，相当于数据的双写多了一个环节。 关键因素基于系统级逻辑卷镜像技术实现的数据复制，相对于其他类型的数据复制技术来讲风险性较高，主要表现为以下几个方面：性能方面的问题对于LVM和GPFS方式来讲，对于数据库的结构化数据复制性能会有较大损耗。因为数据库的读写需要经过数据库本身的存储映射以及操作

43、系统层的存储映射之后才能真正写入存储缓存。纵向的路劲很长，性能损耗会比较大。而ASM本身是将数据库的映射和系统级的映射做到了一起，相对性能损耗会低很多。所以如果利用这类型数据复制技术的话，数据库层的存储块儿参数和操作系统层的存储块儿参数设置要经过一系列优化。容错性问题如果我们用做本地存储高可用实现这种方式的镜像，那么容错性就不会有问题。因为两个镜像副本的链路指标可以认为是同质的，镜像之前的IO读写不会有差异。但是如果用在容灾场合下，由于两个镜像副本的链路指标完全不同，那么就要求系统层能对正常场合下、故障场合下以及故障恢复后场合下的读写差异有很好的容错性。比如说故障场合下的IO超时反馈速度、故障

44、恢复之后的数据再同步问题。再有就是关于应用数据的容错性，对于纯粹操作系统层面的复制，完全无法避免应用逻辑错误。负担过载问题其实这种技术在设计之初并没有过多考虑过其在容灾中的数据复制问题，设计初衷还是系统层的存储卷的虚拟化管理。所以其灵活性以及扩展性优于其在容灾数据复制中的作用。如果非要把这类技术应用到容灾场合的数据复制当中，那么操作系统层一方面要完成应用功能载体作用，另外一方面要完成本地存储卷虚拟化作用，还要一个重量级的容灾数据复制作用。这种负担会直接影响到其承载的数据库应用。3.2 存储层数据复制架构选型规划3.2.1 基于存储网关双写复制技术所谓存储网关双写复制技术，就是在物理存储层之上增

45、加一层网关技术用以实现存储底层的虚拟化以及高可用镜像，并且由存储网关来控制镜像写入的策略和模式。IBM、EMC、NETAPP等公司都有相应技术的产品方案。基于写入原理及策略的不同，又各有区别。图3-1、图3-2、图3-3分别是IBM SVC Split Cluster、EMC Vplex Stretch Cluster、Netapp Metro Cluster。下面我们就其图示、从原理上分别进行分析和论述。图3-1 IBM SVC Split Cluster图3-2 EMC Vplex Stretch Cluster图3-3 NetaApp Metro Cluster 前提条件容灾站点之间需要

46、SAN环境联通，TCP/IP实现三层可达。两个站点分别要部署各自的存储集群节点，共同组成存储网关集群。假设要实现双中心的自动化仲裁及切换，那么第三个仲裁站点以及站点中承载仲裁软件的计算及存储载体也是必须的。 复制原理对于Vplex Stretch Cluster来讲，首先两个存储网关节点是一对类似ORACLE RAC模式的AA模式集群节点。如图3.3.2-2所示，两个节点都可以接受来自上层应用的读写请求。假设来A和B分别是来自底层存储的两个物理卷，那么经过Vplex集群化之后，这两个物理卷被虚拟化集成为一个分布式共享卷C，对于C来讲，两边的应用节点都可以看得到，都可以读写，它的底层又是有A和B

47、两个物理镜像组成。两个站点在写请求到来时，首先要完成本地A或B的写入，然后需要把写入请求传送给另外一个VPLEX节点来完成镜像盘B或A的写入。很显然，两边同时写入就有可能带来同一个数据块儿的访问竞争，这个时候Vplex节点靠他们共同维护的分布式一致性缓存目录来对竞争数据块儿进行加锁以及释放等协同操作，最终完成对数据块儿的最后更新。当发生链路故障而导致一边节点无法写入时，那么节点会保存相应存储日志用以故障恢复之后的数据同步。我们可以理解该同步模式类似于Oracle的最大可用模式，正常情况下保证镜像数据写入的同步完成，当故障时刻会有timeout时间阈值来决定是否暂时切断其中一个镜像的读写。对于I

48、BM SVC和NETAPP MCC架构来讲，它们同样在存储网关节点上实现对底层两个物理卷的镜像绑定，但是这个卷并不是一个分布式共享卷的模式，仅仅是一个实现了镜像绑定的虚拟卷，对于卷的读写只能以其中一侧节点为主，另外一侧节点为备。节点发生故障场合下实现节点主备切换，它比传统HA模式的切换先进在哪里呢？它的备节点是要从主节点上同步缓存的，所以一旦切换发生，时间仅仅耗费在虚拟卷的Ownership转换上，缓存不需要重新读入，从切换的时间上来讲要比传统HA快很多，从而保障了容灾的RTO。那么MCC和SVC的区别在于什么地方呢？对于SVC的Split Cluster的两个节点来讲，它们是两个控制器节点组

49、成的一个IO组，这个IO组意味着故障切换只能发生在这两个控制器节点之间，而且对于一个物理卷来讲只能归属于一个IO组，当这个IO组不可用时，那么这个卷也就无法读写了。对于MCC来讲，承载虚拟卷读写的载体是SVM虚拟机，这个虚拟机是一个资源的组合体，可以动态组合网络、存储以及存储操作系统等资源，所以它能在组成集群的四个控制器节点上进行动态切换，理论上可以切换到任何一个控制器节点上，只不过其切换本身有一个故障优先级控制其切换的顺序。如图，SVM可以首先切换到A2节点上，当A2节点也发生故障时，可以切换到B1节点上，当B1节点也发生故障时可以切换到B2节点上。 关键因素基于存储网关双写技术实现的容灾数

50、据复制，可以将数据容灾管理功能从应用及系统层剥离，从而对上层影响相对很小，而且容灾针对性设计保障其功能实现上会更优。但是其实施的复杂度相对较高，而且对于以上不同架构来讲，其所承担的风险也是不一样的，所以在这类技术的应用上，我们需要特别关注以下几个方面：一、架构复杂性无论是以上哪种存储网关复制技术，那么从硬件条件上来讲，存储这一层需要通过硬件节点组成一层统一存储集群。要想实现自动切换的话，那需要仲裁站点的参与。也就是说从存储这一层来讲，其实两个站点就是一个系统的整体了，底层的复杂性就很高了。如果数据库层、网络层以及应用层的架构再稍微复杂一些的话，那么整个容灾架构的复杂度就会直线上升。二、架构扩展

51、性问题在这种容灾架构下，其实存储层不仅仅是作了一层虚拟化和集群化，更重要的是作了一层存储的集中化，存储网关成为存储的统一出口。那么存储网关集群的横向拉伸能力制约了整个存储系统的可扩展能力。当我们的业务出现快速膨胀的场合下，存储网关集群的最大扩展能力以及其本身的纵向性能扩展性就会是一个关键性问题，我们必须考虑。3.2.2 基于存储底层块儿复制技术基于物理存储层之间的软件复制技术是相对比较传统的存储复制技术，应用的时间也比较长。几乎每一个存储厂商都会有针对性的解决方案。下图是基于存储软件复制技术的基本原理图。存储层软件复制 前提条件对于物理存储底层的块儿复制技术来讲，对于环境要求主要是存储层的要求

52、。容灾站点之间需要SAN环境联通，两边的存储一般要求型号一致并且配置有专门的存储复制软件以及相关许可。 复制原理其实对于存储存储底层的块儿复制技术来讲，它跟上层的应用层关系不大，主要是依靠存储层两个节点来完成源到目标的复制。当上层应用将数据写入存储的时候，那么由存储将这一IO请求再以块儿的方式传输到另外一个存储上，从而保证存储设备在块儿级别上的一致性副本。对于同步复制来讲，需要应用端的IO请求等到存储层的复制完毕之后才会正常返回，对于异步复制来讲，应用IO请求跟底层复制没有任何关系，不需要等待复制结果。对于这种复制技术来讲，两个数据副本仅仅是数据内容相同，在上层没有任何逻辑捆绑或者是虚拟化，所

53、以上层应用也是完全隔离的两套应用，一旦存储发生故障，无论上层应用节点及网络节点是否可用都需要发生站点级切换实现业务连续性，存储本身不能隔离开应用发生切换。 关键因素对于物理存储层面的块儿复制技术，它剥离了对上层应用的依赖，直接靠存储来完成数据复制。好的地方在于它的架构相对简单、相关影响面较小，不好的地方在于它的功能狭窄，功能仅仅在于数据的拷贝，对于上层应用的支撑面儿很窄。所以对于这种复制技术的把握需要注意以下几个点：1. 容灾的切换管理对于容灾的切换管理，我们需要决定好几个问题：切换的决策问题。如果故障集中在存储层面，而其他层面不受任何影响的场合下，那么是不是一定要执行容灾切换？这需要一个完善

54、的决策体系来支撑各种场合下的故障应对。切换的流程以及技术管理体系建设。由于这种数据复制技术对上层依赖的耦合性非常低，那么单纯的存储切换无法实现，这就需要从上到下的一系列技术措施和管理流程来应对容灾切换。回切的流程及技术管理体系建设。同样当故障恢复之后，我们需要回切的时候，这个过程虽然是个计划内的事件，但是可能相对比容灾切换更要复杂、更需要关注。2. 技术兼容性基于存储底层的块儿复制技术，其中最重要的软件依赖就是存储复制软件，但是这个存储复制软件一般都是基于特定的存储设备实现的，具有厂家或者设备壁垒。当我们的存储呈现五花八样的时候，那么这个核心的复制软件可能也会呈现五花八门。对于存储的升级换代或

55、者更换品牌等事件更是有诸多限制。所以我们在应用此类技术的时候要充分考虑到这一点。3.3 整体架构各功能层分解规划设计3.3.1 双数据中心基础架构设计下图是基于双数据中心以及第三仲裁站点三个跨地域物理站点设计的整体IT基础架构案例（案例仅做分析参考，并非标准）。两个业务站点之间相距30公里，90%的银行业务需要通过营业网点或者是行内外其他渠道分别引入AB两个数据中心，其容灾目标是业内六级容灾目标，详细组成如图中所描述：双数据中心整体架构设计3.3.2 基础架构的横向视图分解从上图来看，基础架构的横向视图很简单，就是两个同等角色的业务站点，以及第三个非业务仲裁站点组成。AB两个站点之间距离为30

56、公里，他们之间通过运营商的裸光纤相连，当然这里会有一些中继设备以及一些波分设备，帮我们实现光传输的放大加强、逻辑隔离等重要功能。无负载情况下双中心之间的RTT是在1ms左右。双中心之间通过OTV设备对通讯协议的转换实现以太协议转换，并结合核心以太交换机实现双中心的网络二层、三层的联通。双中心和仲裁站点之间仅仅靠以太三层联通来实现站点级故障场合下的仲裁。总而言之，横向上双中心实现了以太二层以及光纤协议跨地域联通，从而为其他资源共享、数据容灾以及存储整合的实现提供了前提条件。3.3.3 基础架构的纵向视图分解以太网络层图中最上层既为基础架构的网络层，这一层当中主要设备为思科的N7K核心交换机和OT

57、V设备，N7K交换机实现虚拟网络交换层，双中心之间通过OTV设备的联通实现光纤传输协议的以太转换最终实现网层的联通（L2&L3）。可以实现这一功能的技术有很多，例如Vxlan技术，我们需要根据自己的具体需求来选择合适的实现技术。应用负载层网络层的下一层即为应用负载层，这一层既有GTM实现DNS解析之后向LTM分发的请求负载也包括LTM实现应用解析之后向真正应用节点分发的请求负载。虽然这一层我们可以实现跨数据中心的LTM或者GTM大集群，但是基于负载均衡设备会话同步问题的考虑，我们并没有实现跨数据中心大集群。取而代之的是数据中心内部的双节点小集群，然后通过GTM跨数据中心负载引流来实现负载业务的

58、跨数据中心模式。从功能上来讲，这两种模式都能实现跨数据中心负载均衡。后续篇幅会详细说明其中缘由。虚拟应用节点层应用负载层之下就是真正的应用节点层。这一层主要是各个应用系统的应用节点，他们的载体是我们的私有云平台。本质上来讲，每一个应用节点都是一个虚拟化之后的服务器节点，包括X86架构的虚拟化节点也包括PowerVM虚拟化之后的节点。就单个应用系统来讲，这一层我们可以灵活扩展其横向宽度实现与业务负载的相匹配。数据实例节点层所谓数据实例节点层主要功能是实现数据读写以及数据容灾。这一层主要包括两个主要部分，一部分是跨数据中心的RAC集群节点，另外一部分是跨数据中心的ADG容灾节点。RAC集群主要实现

59、数据读写的跨数据中心均衡负载，当然这个均衡是否绝对均衡取决于业务在数据读写上的热点争用的强烈程度，后续章节会详细介绍。ADG主要是为了实现数据库层面的容灾，为了弥补存储容灾以及存储架构本身的缺陷来设计的。存储网络层所谓存储网络层，也就是SAN环境，它承载着存储与主机以及存储内部光纤协议交换的功能。就单个数据中心而言，它实现了存储网络的前后隔离，也就是说存储层与计算层之间属于前端网络，而存储整合层内部的SAN属于后端网络。他们通过不同的核心光纤交换机实现物理隔离，从而避免故障泛滥的风险。双数据中心之间通过存储后端网络实现联通，也就是说数据中心之间靠后端存储网络连接为一个大的存储网络，而数据中心内

60、部实现存储网络的前后端隔离。存储层图最下面的部分就是整个基础架构的存储层，这一层的主要部分实际上是整合之后的存储层，它是经过了存储网关（VPlex）虚拟化以及集群化之后展现出来的存储层。两个数据中心各有一个Vplex存储网关，结合仲裁站点的Withness就组成了一个跨数据中心的存储集群，它将底层的分布在两个数据中心的三个物理存储设备整合成为一个经过本地Local以及跨中心Metro虚拟化之后的虚拟存储卷展示给上层的计算节点，当然在存储层内也存在一些直接映射给计算节点的存储卷。3.4 核心系统双活基础架构规划设计下图是基于某一中小银行的核心系统做的保守型双活容灾架构，在这里仅做参考案例来帮我们