银行双活容灾建设方案技术手册——规划篇 | 周末送资料
本手册包括分析篇、规划篇、实施篇，本篇为规划篇，其余两篇见本公众号推送。也可点击文末阅读原文下载全文。
1、应用层数据复制架构选型规划
1.1 应用事务日志回放技术
下图是Oracle数据库层面的数据复制技术（ADG）的架构原理图。
对于该架构原理图，本文从其实现的基本条件、数据复制原理、数据复制的模式以及数据复制的关键因素等几个方面来进行深度剖析。
Oracle Active Data Guard
1.1.1 前提条件
容灾站点之间需要有三层以太网连通，软件层面需要数据库的集群软件模块（Oracle Active Data Gurard）或者是db2 purscale hadr。服务器层面需要至少两套服务器系统分别部署于两个数据中心。存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。
1.1.2 复制原理
对于主站点的数据库来讲，客户端的数据更新请求首先要由日志写入进程写到重做日志当中，然后由数据写进程再周期性地写入数据文件当中。重做日志当中以SCN为数据库独有的时间搓序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。那么对于配置了Active Data Guard的数据库读写的完成在以上所述过程中，日志写进程在本地日志文件写入过程的同时，日志传输进程会将缓存里面的重做日志通过ADG传输给灾备站点的备库实例，备库实例的日志接收进程根据接受到的重做日志在备库上重新执行数据库的更新操作，从而保证主库和备库的事务性更新行为一致性，最终保证数据的一致。当然也有一个前提条件，那就是在ADG作用之前，必须保证备库的数据保持与主库的某一固定时间点的完整副本，这需要靠传统数据备份技术来实现备库的初始数据复制。因为事务复制的本质是行为复制，那么行为作用的初始数据副本必须保持一致，才能保证最终两副本的一致性。
对于事务日志的复制技术，本文根据主库IO周期特点可以分为绝对同步模式、近似同步模式和异步模式三种。绝对同步模式是指主库的一个完整更新事务的结束既要包括主库的重做日志落盘也要包括备库的重做日志落盘，也就是说备库重做日志落盘之后返回给主库，主库才能执行下一个事务。近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。异步模式是指主库只保证本地重做日志落盘，并不会等待备库重做日志落盘的返回信号。在后两种模式下，当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。第二是日志发送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。
1.1.3 关键因素
基于事务日志回放技术的数据复制架构，从技术规划上以及运维管理层面上有几个关键因素需要把握才能将这种数据复制技术运用自如，才能帮我们真正实现高标准的容灾体系建设。
重做日志管理策略设计
我们知道对于数据库来讲，我们是靠其在线重做日志和离线重做日志来进行数据恢复的。对于离线重做日志也就是归档日志，我们是需要周期性备份并删除的，否则离线重做日志就会无限占用数据库有限的存储资源。那么对于事务日志型数据复制架构来讲，无论是主库还是备库，都需要有合理的日志管理策略来配合才能正常运行。策略的规划和设计需要把握以下几个原则：
1)完成应用的日志要及时转储，包括主库传输完毕的归档和备库应用完毕的归档日志。
2)没有完成应用的日志必须能够保留，主库没有传输到备库的归档日志如果被提前转储会造成备库数据丢失，备库没有被应用的日志如果转储，备库同样会丢失数据。
3)存储资源的科学规划，如果主备库暂时中断，又因为原则2导致归档日志堆积，那么势必造成存储资源的需求超过正常时刻的存储需求量，如果存储资源不够，又会造成数据库发生宕机事故。
以上各个原则的科学设计既需要依赖于数据库参数的合理设置，又需要依赖于备份工具的转储策略合理配合，同时更需要根据不同的业务系统以及负载特点，通过历史数据评估以及仿真测试数据来设计合理的数值并进行动态评估和优化。
架构扩展性及灵活性
在今天的互联网线上时代，系统架构的扩展性和灵活性显得尤为重要。对于容灾架构来讲，它的扩展性和灵活性同样非常重要。对于业务型的数据复制架构来讲，它有两种基本架构：级联架构和串联架构。级联架构是指一点为主多点为备，串联架构是指主备模式依次类推。级联架构更有利于主库的多点保障，串联架构更有利于主库的性能保障。具体采用什么样的架构组合，是要根据主库数据的具体业务需求进行合理评估和设计。
容灾切换管理
主备库的切换，包括两种类型的切换：Fail Over & Switch Over。
Fail Over是指故障情况下的强制切换，Switch Over是指计划性的切换。无论是哪种切换首先是要保障备库数据和主库数据一致或者可容忍范围内的近似一致。其次当数据发生切换时，实际上主库的服务IP地址就会转化成备库的服务地址，无论是通过域名转换还是通过应用重连的方式都需要保障上层的服务地址能够无缝切换。最后切换之后，原来的主库如果没有时间戳恢复功能的话，那么原主库里面的数据就会变成无效数据，需要重新初始化数据副本。但是如果保持时间戳恢复功能的化，就会巨大的存储空间消耗。
1.2 基于系统级逻辑卷镜像技术
下面三张图都是基于系统级逻辑卷镜像技术实现的数据双重复制。图2-1是基于ORACLE自动存储卷管理技术实现的ASM磁盘卷镜像复制技术；图2-2是基于UNIX存储卷管理（LVM）实现的逻辑卷镜像技术；图2-3是基于IBM GPFS分布式文件系统底层逻辑磁盘镜像实现的数据复制。三种技术虽然依赖的具体技术不同，但是其底层原理都是基于系统层面的双写实现的数据复制。
图2-1 ORACLE ASM复制镜像架构
图2-2 LVM镜像复制架构
图2-3分布式文件系统GPFS镜像复制架构
1.2.1 前提条件
容灾站点之间需要SAN环境联通。软件层面，架构一需要具备ORACLE集群软件当中的自动存储卷管理模块，架构二需要借助UNIX操作系统层的逻辑卷管理器，架构三需要借助GPFS或者类似的分布式文件系统软件。存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。
1.2.2 复制原理
对于ASM和LVM模式来讲，都是将底层来自不同站点的两个物理存储卷作为镜像对组合成一个可用的逻辑存储卷提供给上层应用来存放数据，本地物理卷和远程物理卷分别是由存储经过本地SAN环境以及跨数据中心SAN环境提供给服务器操作系统层。LVM是对操作系统的PP写入进行实时双向复制，而ASM是对Oracle数据文件AU写入进行实时双向复制。本地写完并且远端写完才能算是一个完整的写入，假设远端存储卷写入超时就会被标为故障或者是离线状态，当远端存储写入恢复之后，对于LVM来讲需要重新进行手动同步实现镜像副本完全一致。而对于ASM来讲，会有一个短时间内的日志记录会帮助恢复离线镜像恢复数据，但是如果超过这个时间，同样需要一个全新的同步来保证数据的一致性。二者的区别在于LVM的逻辑卷与物理卷的映射关系在创建逻辑卷的时候就已经定义好了，所以对于坏块儿问题，LVM无法完成块儿指针的动态转移。而ASM是在数据写入时才会分配具体的AU，完全可以做到通过指针转移的方式避免坏块儿导致的数据写入失败问题。
对于GPFS模式来讲，它是通过将底层来自不同站点的两个物理存储卷归属到不同的Failure Group当中，然后由这些物理存储卷经过文件系统格式化形成分布式文件系统，提供给上层应用以文件的形式写入数据。文件本身会被GPFS文件系统打散形成若干文件碎片，这些碎片在落盘时分别落入不同Failure Group当中的物理磁盘，从而保证底层数据的双副本。这种模式与前两种模式的最大区别在于它的数据落盘是根据NSD磁盘定义的服务实例顺序来决定的，正常情况下我们需要定义本站点的服务节点为磁盘的主服务节点，这样的话两个镜像写入的时候是靠GPFS位于不同中心的两个服务实例节点分别写入，两个服务实例之间也需要私有协议的交互，相当于数据的双写多了一个环节。
1.2.3 关键因素
基于系统级逻辑卷镜像技术实现的数据复制，相对于其他类型的数据复制技术来讲风险性较高，主要表现为以下几个方面：
性能方面的问题
对于LVM和GPFS方式来讲，对于数据库的结构化数据复制性能会有较大损耗。因为数据库的读写需要经过数据库本身的存储映射以及操作系统层的存储映射之后才能真正写入存储缓存。纵向的路劲很长，性能损耗会比较大。而ASM本身是将数据库的映射和系统级的映射做到了一起，相对性能损耗会低很多。所以如果利用这类型数据复制技术的话，数据库层的存储块儿参数和操作系统层的存储块儿参数设置要经过一系列优化。
容错性问题
如果我们用做本地存储高可用实现这种方式的镜像，那么容错性就不会有问题。因为两个镜像副本的链路指标可以认为是同质的，镜像之前的IO读写不会有差异。但是如果用在容灾场合下，由于两个镜像副本的链路指标完全不同，那么就要求系统层能对正常场合下、故障场合下以及故障恢复后场合下的读写差异有很好的容错性。比如说故障场合下的IO超时反馈速度、故障恢复之后的数据再同步问题。再有就是关于应用数据的容错性，对于纯粹操作系统层面的复制，完全无法避免应用逻辑错误。
负担过载问题
其实这种技术在设计之初并没有过多考虑过其在容灾中的数据复制问题，设计初衷还是系统层的存储卷的虚拟化管理。所以其灵活性以及扩展性优于其在容灾数据复制中的作用。如果非要把这类技术应用到容灾场合的数据复制当中，那么操作系统层一方面要完成应用功能载体作用，另外一方面要完成本地存储卷虚拟化作用，还要一个重量级的容灾数据复制作用。这种负担会直接影响到其承载的数据库应用。
2、存储层数据复制架构选型规划
2.1 基于存储网关双写复制技术
所谓存储网关双写复制技术，就是在物理存储层之上增加一层网关技术用以实现存储底层的虚拟化以及高可用镜像，并且由存储网关来控制镜像写入的策略和模式。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
2.1.1 前提条件
容灾站点之间需要SAN环境联通，TCP/IP实现三层可达。两个站点分别要部署各自的存储集群节点，共同组成存储网关集群。假设要实现双中心的自动化仲裁及切换，那么第三个仲裁站点以及站点中承载仲裁软件的计算及存储载体也是必须的。
2.1.2 复制原理
对于Vplex Stretch Cluster来讲，首先两个存储网关节点是一对类似ORACLE RAC模式的AA模式集群节点。如图3.3.2-2所示，两个节点都可以接受来自上层应用的读写请求。假设来A和B分别是来自底层存储的两个物理卷，那么经过Vplex集群化之后，这两个物理卷被虚拟化集成为一个分布式共享卷C，对于C来讲，两边的应用节点都可以看得到，都可以读写，它的底层又是有A和B两个物理镜像组成。两个站点在写请求到来时，首先要完成本地A或B的写入，然后需要把写入请求传送给另外一个VPLEX节点来完成镜像盘B或A的写入。很显然，两边同时写入就有可能带来同一个数据块儿的访问竞争，这个时候Vplex节点靠他们共同维护的分布式一致性缓存目录来对竞争数据块儿进行加锁以及释放等协同操作，最终完成对数据块儿的最后更新。当发生链路故障而导致一边节点无法写入时，那么节点会保存相应存储日志用以故障恢复之后的数据同步。我们可以理解该同步模式类似于Oracle的最大可用模式，正常情况下保证镜像数据写入的同步完成，当故障时刻会有timeout时间阈值来决定是否暂时切断其中一个镜像的读写。
对于IBM SVC和NETAPP MCC架构来讲，它们同样在存储网关节点上实现对底层两个物理卷的镜像绑定，但是这个卷并不是一个分布式共享卷的模式，仅仅是一个实现了镜像绑定的虚拟卷，对于卷的读写只能以其中一侧节点为主，另外一侧节点为备。节点发生故障场合下实现节点主备切换，它比传统HA模式的切换先进在哪里呢？它的备节点是要从主节点上同步缓存的，所以一旦切换发生，时间仅仅耗费在虚拟卷的Ownership转换上，缓存不需要重新读入，从切换的时间上来讲要比传统HA快很多，从而保障了容灾的RTO。
那么MCC和SVC的区别在于什么地方呢？对于SVC的Split Cluster的两个节点来讲，它们是两个控制器节点组成的一个IO组，这个IO组意味着故障切换只能发生在这两个控制器节点之间，而且对于一个物理卷来讲只能归属于一个IO组，当这个IO组不可用时，那么这个卷也就无法读写了。对于MCC来讲，承载虚拟卷读写的载体是SVM虚拟机，这个虚拟机是一个资源的组合体，可以动态组合网络、存储以及存储操作系统等资源，所以它能在组成集群的四个控制器节点上进行动态切换，理论上可以切换到任何一个控制器节点上，只不过其切换本身有一个故障优先级控制其切换的顺序。如图，SVM可以首先切换到A2节点上，当A2节点也发生故障时，可以切换到B1节点上，当B1节点也发生故障时可以切换到B2节点上。
2.1.3 关键因素
基于存储网关双写技术实现的容灾数据复制，可以将数据容灾管理功能从应用及系统层剥离，从而对上层影响相对很小，而且容灾针对性设计保障其功能实现上会更优。但是其实施的复杂度相对较高，而且对于以上不同架构来讲，其所承担的风险也是不一样的，所以在这类技术的应用上，我们需要特别关注以下几个方面：
一、架构复杂性
无论是以上哪种存储网关复制技术，那么从硬件条件上来讲，存储这一层需要通过硬件节点组成一层统一存储集群。要想实现自动切换的话，那需要仲裁站点的参与。也就是说从存储这一层来讲，其实两个站点就是一个系统的整体了，底层的复杂性就很高了。如果数据库层、网络层以及应用层的架构再稍微复杂一些的话，那么整个容灾架构的复杂度就会直线上升。
二、架构扩展性问题
在这种容灾架构下，其实存储层不仅仅是作了一层虚拟化和集群化，更重要的是作了一层存储的集中化，存储网关成为存储的统一出口。那么存储网关集群的横向拉伸能力制约了整个存储系统的可扩展能力。当我们的业务出现快速膨胀的场合下，存储网关集群的最大扩展能力以及其本身的纵向性能扩展性就会是一个关键性问题，我们必须考虑。
2.2 基于存储底层块儿复制技术
基于物理存储层之间的软件复制技术是相对比较传统的存储复制技术，应用的时间也比较长。几乎每一个存储厂商都会有针对性的解决方案。下图是基于存储软件复制技术的基本原理图。
存储层软件复制
2.2.1 前提条件
对于物理存储底层的块儿复制技术来讲，对于环境要求主要是存储层的要求。容灾站点之间需要SAN环境联通，两边的存储一般要求型号一致并且配置有专门的存储复制软件以及相关许可。
2.2.2 复制原理
其实对于存储存储底层的块儿复制技术来讲，它跟上层的应用层关系不大，主要是依靠存储层两个节点来完成源到目标的复制。当上层应用将数据写入存储的时候，那么由存储将这一IO请求再以块儿的方式传输到另外一个存储上，从而保证存储设备在块儿级别上的一致性副本。对于同步复制来讲，需要应用端的IO请求等到存储层的复制完毕之后才会正常返回，对于异步复制来讲，应用IO请求跟底层复制没有任何关系，不需要等待复制结果。对于这种复制技术来讲，两个数据副本仅仅是数据内容相同，在上层没有任何逻辑捆绑或者是虚拟化，所以上层应用也是完全隔离的两套应用，一旦存储发生故障，无论上层应用节点及网络节点是否可用都需要发生站点级切换实现业务连续性，存储本身不能隔离开应用发生切换。
2.2.3 关键因素
对于物理存储层面的块儿复制技术，它剥离了对上层应用的依赖，直接靠存储来完成数据复制。好的地方在于它的架构相对简单、相关影响面较小，不好的地方在于它的功能狭窄，功能仅仅在于数据的拷贝，对于上层应用的支撑面儿很窄。所以对于这种复制技术的把握需要注意以下几个点：
1. 容灾的切换管理
对于容灾的切换管理，我们需要决定好几个问题：
切换的决策问题。如果故障集中在存储层面，而其他层面不受任何影响的场合下，那么是不是一定要执行容灾切换？这需要一个完善的决策体系来支撑各种场合下的故障应对。
切换的流程以及技术管理体系建设。由于这种数据复制技术对上层依赖的耦合性非常低，那么单纯的存储切换无法实现，这就需要从上到下的一系列技术措施和管理流程来应对容灾切换。
回切的流程及技术管理体系建设。同样当故障恢复之后，我们需要回切的时候，这个过程虽然是个计划内的事件，但是可能相对比容灾切换更要复杂、更需要关注。
2. 技术兼容性
基于存储底层的块儿复制技术，其中最重要的软件依赖就是存储复制软件，但是这个存储复制软件一般都是基于特定的存储设备实现的，具有厂家或者设备壁垒。当我们的存储呈现五花八样的时候，那么这个核心的复制软件可能也会呈现五花八门。对于存储的升级换代或者更换品牌等事件更是有诸多限制。所以我们在应用此类技术的时候要充分考虑到这一点。
3、整体架构各功能层分解规划设计
3.1 双数据中心基础架构设计
下图是基于双数据中心以及第三仲裁站点三个跨地域物理站点设计的整体IT基础架构案例（案例仅做分析参考，并非标准）。两个业务站点之间相距30公里，90%的银行业务需要通过营业网点或者是行内外其他渠道分别引入AB两个数据中心，其容灾目标是业内六级容灾目标，详细组成如图中所描述：
双数据中心整体架构设计
3.2 基础架构的横向视图分解
从上图来看，基础架构的横向视图很简单，就是两个同等角色的业务站点，以及第三个非业务仲裁站点组成。AB两个站点之间距离为30公里，他们之间通过运营商的裸光纤相连，当然这里会有一些中继设备以及一些波分设备，帮我们实现光传输的放大加强、逻辑隔离等重要功能。无负载情况下双中心之间的RTT是在1ms左右。双中心之间通过OTV设备对通讯协议的转换实现以太协议转换，并结合核心以太交换机实现双中心的网络二层、三层的联通。双中心和仲裁站点之间仅仅靠以太三层联通来实现站点级故障场合下的仲裁。
总而言之，横向上双中心实现了以太二层以及光纤协议跨地域联通，从而为其他资源共享、数据容灾以及存储整合的实现提供了前提条件。
3.3基础架构的纵向视图分解
以太网络层
图中最上层既为基础架构的网络层，这一层当中主要设备为思科的N7K核心交换机和OTV设备，N7K交换机实现虚拟网络交换层，双中心之间通过OTV设备的联通实现光纤传输协议的以太转换最终实现网层的联通（L2&L3）。可以实现这一功能的技术有很多，例如Vxlan技术，我们需要根据自己的具体需求来选择合适的实现技术。
应用负载层
网络层的下一层即为应用负载层，这一层既有GTM实现DNS解析之后向LTM分发的请求负载也包括LTM实现应用解析之后向真正应用节点分发的请求负载。虽然这一层我们可以实现跨数据中心的LTM或者GTM大集群，但是基于负载均衡设备会话同步问题的考虑，我们并没有实现跨数据中心大集群。取而代之的是数据中心内部的双节点小集群，然后通过GTM跨数据中心负载引流来实现负载业务的跨数据中心模式。从功能上来讲，这两种模式都能实现跨数据中心负载均衡。后续篇幅会详细说明其中缘由。
虚拟应用节点层
应用负载层之下就是真正的应用节点层。这一层主要是各个应用系统的应用节点，他们的载体是我们的私有云平台。本质上来讲，每一个应用节点都是一个虚拟化之后的服务器节点，包括X86架构的虚拟化节点也包括PowerVM虚拟化之后的节点。就单个应用系统来讲，这一层我们可以灵活扩展其横向宽度实现与业务负载的相匹配。
数据实例节点层
所谓数据实例节点层主要功能是实现数据读写以及数据容灾。这一层主要包括两个主要部分，一部分是跨数据中心的RAC集群节点，另外一部分是跨数据中心的ADG容灾节点。RAC集群主要实现数据读写的跨数据中心均衡负载，当然这个均衡是否绝对均衡取决于业务在数据读写上的热点争用的强烈程度，后续章节会详细介绍。ADG主要是为了实现数据库层面的容灾，为了弥补存储容灾以及存储架构本身的缺陷来设计的。
存储网络层
所谓存储网络层，也就是SAN环境，它承载着存储与主机以及存储内部光纤协议交换的功能。就单个数据中心而言，它实现了存储网络的前后隔离，也就是说存储层与计算层之间属于前端网络，而存储整合层内部的SAN属于后端网络。他们通过不同的核心光纤交换机实现物理隔离，从而避免故障泛滥的风险。双数据中心之间通过存储后端网络实现联通，也就是说数据中心之间靠后端存储网络连接为一个大的存储网络，而数据中心内部实现存储网络的前后端隔离。
存储层
图最下面的部分就是整个基础架构的存储层，这一层的主要部分实际上是整合之后的存储层，它是经过了存储网关（VPlex）虚拟化以及集群化之后展现出来的存储层。两个数据中心各有一个Vplex存储网关，结合仲裁站点的Withness就组成了一个跨数据中心的存储集群，它将底层的分布在两个数据中心的三个物理存储设备整合成为一个经过本地Local以及跨中心Metro虚拟化之后的虚拟存储卷展示给上层的计算节点，当然在存储层内也存在一些直接映射给计算节点的存储卷。
4、核心系统双活基础架构规划设计
下图是基于某一中小银行的核心系统做的保守型双活容灾架构，在这里仅做参考案例来帮我们对银行的核心系统双活设计规划更加具体明确。
核心系统数据容灾架构
本案当中的核心系统数据容灾架构，对于该架构的分解也分为两个维度：横向和纵向。横向分为AB两个数据中心站点。纵向上，分为应用、数据实例、计算资源、存储等四个层面：
1）应用层面包括核心系统的联机和批量应用，联机应用分别部署于两个数据中心，而批量应用仅仅部署于其中一个站点。还有其他一些需要利用核心系统数据的一些管理及测试性质的应用部署于其中一个数据中心。
2）数据实例层面主要包括两个部分：一个是数据库集群，是跨数据中心的2+1模式的RAC集群，另外一个是以一个数据中心为主另外一个数据中心为备的Oracle ADG容灾架构。也就是说站点1的数据库节点1即是Rac集群里面的实例节点，同时它也是ADG的源节点。
3）计算节点层面主要是PowerVM承载的动态客户分区，核心系统所有的数据库实例节点以及ADG节点都是运行在PowerVM之上，借助PowerVM的虚拟化动态扩展特性可以实现计算资源的灵活调度。
4）存储层面同样也包括两个部分：一部分是经过存储集群化虚拟化之后的跨中心分布式共享卷，另外一部分是避开存储虚拟化网关直接挂在计算节点上的存储卷。
点击文末阅读原文，可到社区下载该完整资料 觉得本文有用，请转发或点击“在看”，让更多同行看到
欢迎关注社区以下 容灾技术主题，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/71
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场