1 、灾备定义
灾备顾名思义，就是灾难备份，对于银行业来说，无论是监管机构的规定，还是出于银行重要业务的可靠性要求，都是一件必须要考虑的事情。银行业的灾备建设，从原始的灾难备份要求，逐渐演变为灾难快速响应及快速切换要求。通俗来讲，就是从数据级灾备过渡到应用级灾备的需求。灾备建设主要有以下几个要点。
数据：
无论是哪种灾备建设要求，都是基于数据出发的，数据保护是灾备建设的基本。数据级灾备是要求灾备数据的存在性，当然，还需要定期的验证计划来保证这部分数据时可用的。应用级灾备就要求在保证数据存在前提下，向灾备数据持续可用性转变的过程。相对地对系统建设的要求和成本，也就要高很多。
数据同步：
保证数据同步的一致性和实时性才能使灾备应用的接管有效。目前主要的数据同步方式有两种，应用层同步和存储阵列同步。考虑到目前城商行规模和实际场景，大部分都已经实现了共享的开放平台存储，所以基本上都采用了各存储厂商提供的数据复制技术来实现（同步异步可选），如 EMC 的 SRDF、IBM 的 metro mirror、HDS 的true copy 等，使用下来可以说同步复制技术几乎没有差别，都是基于一致性写实现的；异步复制技术区别也不大。
存储：
简单来说，存储是所有数据的载体，是现在灾备建设基础设备。实践经验告诉我们，对于有建设同城灾备甚至两地三中心需求的机构，尽量能够采用各型存储中的高端型号，避免在中端存储的复制稳定性和 license 限制上受局限。
网络：
网络环境是灾备建设最底层的需求。灾备网络需要满足这么几个要点：生产隔离＋网络联通性，网络对称性＋适量冗余，安全访问＋自动分发。
2 、灾备建设原则
数据一致性：
实时检验数据复制的状态，保证数据传输链路的稳定。并建立应用校验机制，定期验证数据的一致性
完善的流程：
建设灾备，就必须同步建设相应的灾备切换流程和应用同步流程，这有助于降低日常灾备维护压力，提高灾备中心规范化同步，保证双中心的系统能够同步上线。
标准化文档：
标准化文档管理为了保障系统灾备切换时间能够降到最低。因为双中心距离一般会在 30-50km 之间，在主要技术负责人紧急的情况下，维护人员能够按照标准的流程操作，完成切换，降低切换成本。
技术的选择：
当然银行等金融机构都有一套严格的准入标准。一般选择案例丰富，成熟稳定的技术方案。
3 、应用级灾备的详细规划
我们的灾备建设从无到有，也逐渐从数据级灾备慢慢向应用级灾备靠拢，在此过程中，无论是数据级还是应用级，规划工作永远是最最重要的。在规划中往往会因为对应用级灾备需求的不了解和期许太高，产生一些误区。
对灾备定位不清，认为灾备事件随时会发生，我们随时都要切灾备，而且生产中心某套重要系统环境异常，就有可能切灾备。建设了应用级灾备，就能够实现自动灾备切换。
在这里，稍微解释下，保证大家对于选择应用级灾备有一个理性的认识。
首先，非灾难性事件发生，一般不会考虑切换灾备中心，这里说的灾难是指地震、洪水、战争等对区域一致性破坏的事件，几乎95%的故障事件，最有时效性和最简单的解决方式就是本地高可用建设。系统层面的 lvm，旁路 CDP 连续数据保护，应用负载均衡集群，oracle 数据库 RAC 等。
其次，应用级灾备建设，尤其是第三方外联系统，会要求网络上的安全控制和隔离，当发生灾难时，首先需要评估并决策，在保证对外服务一致性前提下切换灾备，我们一般都会选择人为参与灾备切换，并制定灾备切换应急预案和切换手册。
在明确了灾备建设目标和实现方式后，就需要开始进行完整的设计规划。
1、灾备基础环境规划
IP 网络：
评估双中心数据传输需求
数据传输带宽评估
网络传输通道的冗余
网络设备商及线路运营商的评估
灾备网络安全设备及安全策略
灾备网络分层设计
SAN 网络：
光纤传输线路选择
线路冗余设计
生产中心的核心
SAN 网络和复制
SAN 网络隔离设计
光交选择
存储及主机：
存储统一选型
主机统一选型
存储复制技术选择
存储虚拟化技术选择
标准化系统搭建
2、系统分层
系统分层基于系统架构梳理。这需要我们梳理所有系统 0 层图，明确各系统的业务逻辑关联和数据耦合性，根据客户资金，确定系统分层 A 、A、B、C、D 类。所有挂接公共存储平台的系统，都实施存储复制来实现数据级灾备。所有 A 、A 和 B 类系统都是资金相关联系统，且 RTO、RPO 级别较高，都要求逐步建设应用级灾备。同时，数据耦合性高的业务系统，通过存储设定的 consistent group，来保证复制数据的一致性。
3、建立灾备团队
灾备建设不是一个独立的项目，而是一个可持续的 IT 架构，需要有专门的建设团队及运维团队，全程跟进灾备建设及优化，并统一管理监控及标准化。
4、应用级灾备选择
和数据库灾备比较之下，应用级灾备需要灾灾备端部署一套包含软硬件在内的完整设备，在配置方面与生产中心要大致相当，如果真的发生切且灾备系统承载所有生产访问压力，如果性能不满足要求则没有太大意义。但从成本上考虑，可以适当降低灾备系统的冗余度。
统一 dns 服务器与生产中心同步，能够大量降低用户修改 ip 地址的工作。
统一的时间同步服务器，以保证跨中心集群环境的时间一致性，消除心跳仲裁等时间一致性较敏感的架构带来的风险。统一的程序上线、更新流程，保证灾备端和生产端的每次程序版本更新的一致性。
4 、典型的应用级灾备
根据应用特点不同，也有不同的灾备应用场景。
读写分离：
小部分应用系统能够定义并分离读写需求，如果应用层面能够满足业务操作和业务查询的逻辑隔离，可以通过数据层的双活，实现生产中心和灾备中心的业务逻辑分离，灾备中心应用系统提供业务查询，有效利用灾备环境。
模型：数据库的双活＋应用逻辑区分
实现：生产中心系统底层通过存储卷复制技术实现数据级的灾备，数据库（oracle）可以通过 dataguard（gg 等）实现数据库层面逻辑复制，双中心两套数据库，主库提供业务操作，备库（灾备中心）提供业务查询。上层应用完成读写逻辑分离，使特定查询链接灾备应用服务器。当主中心异常，oracle 层面切换备库为读写状态，网络接入灾备中心应用服务器，提供所有读写操作。
注意点：主中心和灾备中心是完全的两套独立环境，软硬件投入成本大，需要数据库层面操作，为了提高可靠性，也可以实现 主中心多接点 rac＋灾备中心 onenode的 dataguard 模式。适用于一些特殊需求系统。
可验证的热备份：
绝大部分灾备应用系统处于启动状态，在搭建过程中预先创建好灾备复制存储对应生产中心的复制件映射，平时处于应用开启状态，用于同步程序，只有灾备切换时挂接复制卷提供对外服务。
模式：存储复制＋数据 OS 分离
实现：这部分系统最好实现 OS 和数据分离（属于不同的存储卷），灾备切换时，需要断开复制关系，并重新映射灾备卷给灾备主机，保证数据一致性的情况下，应用能够正常运行并实现数据灾备端落地。
注意点：因为正常情况下，灾备数据卷无法验证，所以需要定期安排灾备切换演练，保证数据卷可用性。并且当生产中心发生存储卷扩容的情况，灾备端需要同步操作。普适的应用灾备方案。
应用双活：
理想状态下，我们都希望双中心的应用系统能够实现集群化管理，同时，底层数据也实现跨中心的复制（类似于在存储层实现 OS 上的 LVM）。使得在主中心发生灾备切换时，灾备中心应用和数据同时都能够提供正常的访问。
模式：存储虚拟化＋应用负载均衡
实现：据了解，目前某些知名的存储厂商都有灾高端型号上开始实现一些虚拟化解决方案，比如 hds 的 gad 技术。通过这些实现存储层面跨中心的全局话虚拟卷，相当于原来灾数据库层面（oracle）实现的 rac 节点，可以拉开到距离相对较近的容灾中心，底层全局虚拟化卷能够被两中心数据库服务器同时访问，结合网络负载均衡设备支持的应用负载均衡，能够实现双活的应用。
注意点：这类技术在本地双存储安全实现，但是对于拉开距离的把握以及可靠性还有待验证。同时，一般需要第三方阵列来提供仲裁卷。一般都需要高端存储支持虚拟化，成本较高且相对不是很成熟。
联系客服
