2.2.3 商业银行的传统灾备架构
备份就像买车险，不出事的时候永远用不上，只有当出了事故才能深刻意识到它的宝贵。2001年的“911”事件对世贸大厦内所有金融机构而言，都是一场灭顶之灾。事件发生后，德意志银行在短时间内，通过距纽约30公里外的灾备机房迅速恢复了业务运转。相反，纽约银行数据中心及其关键设施和数据，则随着世贸大厦的灾难事件毁于一旦，因缺乏灾备系统和应急业务恢复计划，不能及时恢复业务，严重影响了其业务的正常运行。
银行信息系统的安全性和可靠性直接关系到个人、企业、国家的切身利益，保障银行IT基础架构在灾难情况下的业务连续性，是信息科技业务连续性的重中之重。本节将对商业银行传统灾备架构的灾备要求、灾备方案进行简单描述，并着重介绍银行两地三中心灾备架构。
1. 灾备要求
（1）监管及政策要求
依照《商业银行业务连续性监管指引》《商业银行信息科技风险管理指引》《银行业信息系统灾难恢复管理规范》等相关文件的指导精神，商业银行应于取得金融许可证后两年内设立生产中心；生产中心设立后两年内设立灾备中心。结合灾备中心建设在科技监管评级以及保障业务连续性等方面的重大影响，灾备中心建设可以保障数据安全、快速恢复业务、减少灾难损失，基于双活的灾备架构还可以对主数据中心进行分流，降低单数据中心的业务负载，提升资源利用率。
（2）连续性管理要求
业务连续性管理可以使企业认识到潜在的危机和相关影响，通过制定业务连续性的恢复计划，可以提高企业的风险防范能力，有效降低非计划的业务中断及不良影响。根据《信息系统灾难恢复规范》，信息系统灾备等级分为6级，各个灾备级别对RTO（Recovery Time Objective）和RPO（Recovery Point Objective）的要求如表2-2所示。
表2-2 灾难恢复能力等级要求
提示
· RTO：恢复时间目标，指灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。
· RPO：恢复点目标，指灾难发生后，系统和数据必须恢复到的时间点要求。
2. 两地三中心方案
商业银行常见的灾备建设方案有同城灾备、异地灾备及两地三中心（同城灾备+异地灾备）三种建设模式。
▪ 同城灾备即在同一城市建立灾备中心，主备数据中心之间的距离在几十公里内，通过数据同步复制或异步复制技术实现应用级或数据级同城灾备建设。同城应用级灾备可以使灾备中心在发生灾难时提供全量业务服务，同城数据级灾备实现数据复制，保障灾难时数据无丢失。
▪ 异地灾备即在不同城市建立灾备中心，距离一般在一百公里以上，数据复制采用异步数据复制技术，实现应用级或数据级异地灾备建设。
▪ 两地三中心模式则是结合同城灾备与异地灾备，兼具两者在可用性保障方面的全部优点，最大程度保障业务系统连续性运行，缩短RTO及RPO，缺点是成本太高。
因两地三中心架构在传统灾备建设中较具有代表性，下文将着重针对两地三中心的灾备建设方案进行介绍。
两地三中心中的同城灾备根据数据中心是否对外提供服务，又可以细分为A-A（Active Active）和A-S（Active-Standby）两种模式。在A-A模式中，又可以分为双中心对称模式和非对称模式。
对称模式即主备中心均对外提供完整业务功能，用户请求可以发送到任何一个中心进行处理，每个中心都可以承担行内全部业务，并且在任一中心发生灾难时都不会出现业务中断。对称模式可以理解为双活数据中心，具体实施方面又可以分为应用级双活和数据库级双活两种模式。
非对称模式即主备中心分别对外提供有限的不同功能的业务访问，前置路由系统会按照路由策略转发用户请求到相应的中心，比如主中心提供面向互联网网银类应用，备中心提供柜面及ATM类应用。在这种模式下，每个中心承载的是不一样的服务，单数据中心突发故障会造成部分业务不可用，因此在RTO方面的表现必然不如对称模式。
在A-S模式中，同城灾备中心处于冷备状态，可以人为手动或在灾难情况下自动切换业务到同城灾备中心。
虽然异地灾备中心平时不使用，但须部署对应的应用系统，并且进行底层数据同步（并根据RPO要求设置同步或异步频率），保证完整数据的异地保存。只有在灾备演练或真正发生灾难并进行灾备切换时使用。
图2-9展示了两地三中心模式下的架构示意图。
图2-9 两地三中心基础架构
业务接入层对用户信息进行识别，根据业务类型、用户分组路由到不同机房。业务处理层主要进行业务处理，同城灾备中心应该与主中心部署相同的应用系统，包括对公、对私、信用卡、中间业务等众多的金融服务，异地灾备中心可以选择性地只部署第一类、第二类系统，以保障特殊情况下重要业务能及时恢复。两地三中心数据同步则是通过服务器层、数据库层和存储层复制完成，因为距离因素，主要实现同城数据同步复制和异地数据异步复制。根据灾备模式A-A、A-S不同，相应的底层数据复制技术也不同，主要为主备数据中心的数据读写、只读需求差异，具体技术选型将在下文说明。
3. 两地三中心技术
灾备建设两地三中心技术是在单中心系统冗余的基础上进行拓展，包括灾备网络层设计、灾备服务器层设计、灾备数据库层设计和灾备存储层设计。
（1）单中心系统冗余设计
灾备建设的目的即保证业务连续性，在发生设备故障和灾难时，能够及时完成切换，保障业务可用性及数据完整性。IT基础架构以业务连续性为目标，首先需要保障单中心IT基础设施的健壮性。
▪ 网络层：通过VRRP、堆叠实现网络交换机高可用，通过“N+M”集群实现F5等负载均衡、DNS解析服务高可用。
▪ 服务器层：在服务器高可用（HA）设计中，使用如大型机SysPlex、小型机 HACMP、虚拟机VMware Vmotion和HA方案。
▪ 数据库层：使用Oracle RAC、DB2 PureScale、MySQL Replication等冗余设计。
▪ 存储层：采用双控制器、I/O多路径保障物理冗余设计，采用Metro Mirror、Snapshot快照的逻辑冗余设计。
（2）灾备网络层设计
灾备网络层设计的重点是互联网全局负载均衡设计和跨中心链路设计。
■ 全局负载均衡
在灾备的应用场景中，全局负载均衡（Global Server Load Balance, GSLB）是经常被谈论到的一个组件。用户通过域名访问银行业务系统，在多个机房的情况下，无论是A-A还是A-S模式，数据中心都需要对外提供服务，而用户访问的公网域名是固定的，所以我们需要GSLB来帮助我们智能解析公网DNS。GSLB会替代最终的DNS实现灵活的域名解析，返回给用户最合适的公网IP地址列表。全局负载均衡的智能DNS解析功能可以为用户提供最优的可用路径，并在故障时进行域名解析的自动切换。关于全局负载均衡的更多内容，将在第8章详细介绍。
■ 跨中心链路
灾备建设跨中心链路包括同城DWDM波分链路和异地WAN（Wide Area Network，广域网）互联网链路。其中因为同城跨中心业务交互和FC通道数据同步强依赖于同城跨中心DWDM波分链路，因此对同城波分链路的可用性、延迟都有较高要求。同城波分链路至少需要两条光纤通道，以满足波分通道高可用条件。
在同城数据同步设计中需要考虑通道及协议带来的延迟。正常情况下主机磁盘I/O响应时间为0.2～0.5ms，50KM同城基于FC复制磁盘的响应延迟将至少增加125%，直接反映在磁盘I/O方面就是响应时间变长。需要说明的是，城域网络、FC链路延迟不仅涉及距离和协议层面，还有主机延迟、交换机延迟、存储延迟等较多其他因素，所以包括IBM PPRC、Oracle RAC等对跨中心网络都有较高要求，最好不超过5ms，同城数据同步的最大距离建议不超过100KM。
（3）灾备服务器层设计
灾备服务器层主要是指所使用的各类大型机、小型机或X86服务器按照相同架构部署与主中心相同的应用系统，当发生灾难事件时能够实现服务器的切换和接管。服务器层系统可以作为无状态应用在灾备中心访问已完成切换的本地存储数据，或是作为有状态应用在主机层面完成数据复制。
基于服务器层的跨中心复制技术通过IP网络建立传输通道，并使用数据复制软件来实现远程数据复制。其中具有代表性的有Symantec公司的VVR（Veritas Volume Replicator）存储卷复制技术和基于虚拟化层面的VMware SRM（Site Recovery Manager）复制技术。
在虚拟化层面，VMware SRM提供了业务连续性和灾难恢复方案。以SRM为例，如图2-10所示。
图2-10 SRM架构与基于阵列的复制
注：图片来源为《Site Recovery Manager管理指南》。
SRM使用基于阵列的复制，即受保护站点中的一个或多个存储阵列会将数据复制到恢复站点中的对等阵列，通过存储复制适配器（SRA），将SRM与各种阵列进行集成。SRM用于A-S模式，即正常情况下虚拟机存活于主中心，对应的存储阵列一致性组和LUN在主中心为可读写状态，备中心虚拟机为受保护状态，对应存储阵列一致性组和LUN为只读状态。当主中心发生灾难时，SRM通过SRA插件触发存储阵列一致性组切换，切换保护站点与恢复站点读写权限，并完成存储阵列一致性组反向保护。同时受保护虚拟机在完成阵列状态变更后，会根据恢复计划在恢复站点上打开复制的虚拟机电源，通过自定义虚拟机IP属性配置及虚拟机服务器自启动配置，可以在较短时间内完成灾备中心服务器层灾难恢复。
值得注意的是，无论是自动还是手动触发SRM，原站点虚拟机在切换后均会处于不可用状态。
（4）灾备数据库层设计
在两地三中心数据库层灾备架构中，可通过数据库复制技术，实现数据库层逻辑操作的同城机房同步复制和异地机房的异步复制。数据库层复制支持异构存储，数据库级复制软件的数据校验技术能够有效保障数据库的一致性。总体思路为，当出现数据级灾难时，可以切换至同城灾备机房，数据无丢失，在同城机房均不可用的情况下可以切换到异地灾备中心，保证数据的完整性和可用性。其中具有代表性的有Oracle DataGuard和Golden Gate、IBM DB2 Q Replication、Quest SharePlex、MySQL Replication技术等。
数据库层灾备架构的总体思路是当出现数据级灾难时，可以将读写切换至灾备机房，由于数据均已通过复制技术同步，因此数据并不会丢失，切换完成后可以使用灾备机房的数据库系统，继续对外提供服务。
以Oracle数据库为例，Oracle容灾可以使用DataGuard（以下简称DG），而异构平台的数据迁移同步可以使用Oracle Golden Gate（以下简称OGG）。OGG是抽取源端Redo Log或者Archive Log，获得数据的增量变化，转换为GGS自定义数据格式存放在本地队列或者远端队列以实现数据同步。DG的基本原理是将日志文件从原数据库传输到目标数据库，并在目标数据库上重新应用，实现目标库与原库的数据同步。DG实现了数据库数据的同步复制，但是在Oracle 11G版本之前，当备份数据库处于只读模式时，日志的数据同步会停止，而如果日志数据同步又无法处于只读模式，所以后来Oracle推出了ADG（Active Data Guard）特性，使得备库能够在只读打开模式下继续应用日志的数据同步，从而实现备库作为读数据库对外提供服务，以缓解主数据库的负载压力。
ADG同步复制过程可以使备用数据库一直处于Active状态，备用数据库可以在响应只读查询操作的同时，继续应用主库发送过来的Redo Log，保持数据与主库的一致性。在这个过程中，又可以把备用数据库作为查询库，对外提供服务，以提升备用数据库的利用率，即A-Q（Active-Query）模式。ADG数据同步稳定性强，效率非常高，对硬件的资源要求却更低。在A-Q模式下，备用数据库可以分担主库分析、统计、报表、备份、测试等数据处理工作，在实现灾备的同时也提高了生产环境的处理能力和服务质量。
实现数据库级别的同城同步复制可以通过ADG特性，实现单个数据中心内高可用，可以使用Oracle的RAC特性。如图2-11所示的最高可用性架构（Maximum Availability Architecture, MAA）方案即为ADG和RAC方案的结合。
图2-11 MAA最高可用性架构
在MAA方案中，单数据中心内部通过RAC实现本地Oracle集群高可用，跨机房则通过ADG实现数据实时复制。在双活场景下，主中心Oracle RAC集群同时受理双数据中心应用读写请求，备中心Oracle RAC集群受理部分应用只读请求。当发生灾备进行切换时，只需要修改Oracle数据库域名指向的IP地址，使其解析到灾备机房Oracle地址并修改灾备数据库保护模式即可。
（5）灾备存储层设计
从实现上来看，存储层复制有同步数据复制和异步数据复制两种，如图2-12所示，同步复制要求在本地存储接收到主机的更新时，除了更新本地存储缓存，还要将数据发送到对端存储缓存，只有在得到对端存储写成功标识后，才会向主机返回I/O完成指示，最大限度保证数据的一致性，减少灾难发生时的数据丢失。异步复制则是在完成本地存储缓存更新后立即返回I/O完成指示，所以异步复制的数据在一定时间内不同步，只是保证最终所有复制节点的数据一致。
图2-12 同步复制、异步复制
存储双活与存储主备模式的不同之处在于主中心、同城灾备中心存储设备都处于Active状态。存储双活模式下的灾难切换能够实现业务自动切换，做到上层应用基本无感知。目前主流存储厂商的双活方案有华为HyperMetro、HDS GAD、Dell Live Volume、IBM MetroMirror和SVC ESC、富士通 Storage Cluster、HP PeerPersistence、EMC VPLEX、NetAPP MetroCluster。
根据是否需要中间设备可以分为存储网关双活方案和非存储网关双活方案。以NetAPP MetroCluster为代表的非存储网关双活方案，可以简单理解为把双中心存储控制器作为HA Pair集群对外提供服务。EMC VPLEX和IBM SVC的存储网关方案则是在主机和存储之间添加存储网关设备，数据读写均通过镜像卷实现双活访问。如图2-13所示，存储网关双活方案数据一致性确认由存储网关保证。
图2-13 存储网关数据复制
在网络拓扑上，非存储网关方案需要主机通过SAN交换机划Zone，使主机能够访问同城对端存储控制器，各中心存储须同构，而存储网关方案只需要主机能够访问双机房存储网关，后端阵列只与本地存储网关对接，且后端存储可以异构。
双活存储方案双写的实现参照同城数据复制技术，可以保证本端存储缓存和对端存储缓存数据变更一致。发生灾难时，通过DCL记录业务运行中的数据变更，以便在灾难恢复后继续进行数据同步。
在多数情况下，双活存储方案中不同服务器对同一卷、LUN、数据块的读写通过锁分配机制来避免冲突，获得锁请求才能写入数据，其他请求则需要待锁释放之后重新获取才能完成。如在EMC VPLEX存储网关双活方案中，通过分布式一致性缓存技术来实现锁机制，VPLEX把控制器单个内存系统合并形成分布式缓存，以提供全局系统的缓存一致性控制。
值得一提的是，随着信息技术的快速发展，同城双活甚至异地多活已经在互联网大厂得到充分的实践，部分有实力的商业银行也在灾备建设中进行了较多实践。双活和多活的出现打破了原有的同城、异地灾备模式，能够最大限度地提高IT基础设施的利用率、提高IT设备的投入产出比；在保障业务连续性要求的前提下，双活、多活方案都能够优化用户访问路径，使用户可以自动路由分流到最优数据中心，提升客户体验。随着越来越多的案例实践，双活及多活场景下的应用也越来越成熟。综合来看，不管是从投入产出比、业务连续性保障，还是从用户体验考虑，双活方案都将是更优的选择。