中国民生银行灾备自动化切换调度平台实践与应用.pdf

中国民生银行灾备自动化切换调度平台实践与 应用 内容简介：中国民生银行在灾备建设的过程中，自行研发了一套灾备自动化调度指挥平台， 用于日常灾备系统管理、切换演练、灾备切换、状态监控展现和应急启停。平台投入使用第 一年就陆续接入几十套同城和异地灾备业务系统，得益于弹性灵活的流程编排特性，灾备系 统接入时间大大缩短，后期变更维护的工作量大幅度减少；切合实际需求的桌面演练、应急 启停、跳过和重做失败步骤等功能的实现，提高了系统可用性和用户满意度。灾备自动化调 度指挥平台随着需求的更新、应用新架构的引进而不断演进，以支持我行所有场景下的自动 化灾备切换操作。 1、中国民生银行灾备建设背景介绍 近年来随着银监会《商业银行数据中心监管指引》和《商业银行业务连续性监管指引》等规 范的陆续出台，监管部门对商业银行信息系统业务连续性管理提出了很高的要求，特别是要 求定期开展灾备切换演练，而随着业务系统架构多样性及复杂性的不断提高，整个切换流程 将变得越来越复杂，同时演练中对于流程控制的要求也变得越来越高。 民生银行在灾备建设中采用的是大同城小异地的两地三中心灾备方案，同城两个机房采用了 网络大二层打通的技术，主要目的是实现同城应用双活和系统在任意机房运行，在灾备技术 方面，由于行内新核心刚刚上线不久，因此没有采用对应用有改造需求的应用端双活技术， 而数据库日志传输技术可能会导致数据丢失，灾难时无法保证 RPO=0，因此我们在现有技 术栈基础上，采用了改造和影响最少的存储复制技术，虽然在切换过程中需要激活灾备端的 各种资源，会导致 RTO 时间较长，但是可以尽力保证 RPO=0。 存储复制技术带来的灾备切换问题主要有：流程复杂，切换步骤多，逐层操作的 IT 模块 多，切换时间长。因为银行业务特点和技术栈的原因，我行业务系统数量非常多，而且使用 了各种 IT 技术，存储方面有 EMC SRDF/SWAP/STAR 以及华为 HyperReplication，数据 库方面有 DB2、ORACLE、MySQL、DB2 HADR、ORACLE RAC、MySQL MHA 以及 DB2 PureSacle GDPC、Oracle extend RAC 等，操作系统方面包括 Suse Linux、IBM AIX、HP Unix、Oracle Solaris 以及相应的集群技术，中间件包括Weblogic、Tomcat、 Apache、Nginx、ActiveMQ、IBM MQ 等。日常灾备切换演练和真实灾备切换时间压力 比较大。 灾备切换面临的主要问题除保证 RPO 的前提下尽量减小 RTO 外，还包括跨部门指挥协调 问题、切换流程进度监控问题、以及众多流程的维护问题。灾备切换时要考虑如何解决这些 问题，实现安全有序的灾备切换，这样就需要一款能自动化执行、对所有系统的切换流程可 以指挥调度的平台。 fm4z2kh8igp 我们从 2015 年开始进行灾备指挥平台的建设，项目初期我们曾尝试通过某 IT 公司咨询来 解决我们的问题，但是后来发现洋洋洒洒几百页无法落地的 ppt 并不能解决上述问题，为 此我们也曾了解过业内几个灾备切换产品，这些产品大多需要深度定制，而且大多无法实现 自动化操作，或者在流程编排方面只能采用一个系统一个场景对应一个流程的方式编排，缺 乏灵活性，当系统和场景复杂时对流程的维护是一个大问题。 基于以上背景，我们决定自行架构开发一套符合我行使用需求的灾备自动化调度指挥平台。 2、灾备自动化调度指挥平台需求分析 银行的数据中心一般采用两地三中心架构，分为同城生产和灾备中心，异地灾备中心，可能 采用大同城架构，也可能大异地架构，甚至采用异地双活。目前因技术和财务限制，大多数 银行业务没有采用双活架构，而是按照业务系统重要性在同城或者异地搭建容灾环境。常见 的可能面对的灾难场景有整个站点故障、网络问题导致整个网络区域服务不可用、主机或者 存储故障导致部分服务不可用，等等。那么平台不仅要支持单一系统的切换，还要支持多系 统的站点的切换，针对网络区域故障、存储故障的切换。 考虑到场景复杂，灾备系统数量多，在确保 RTO 基础上，既要做到灾备切换过程可控，满 足多种容灾场景，还要提高跨部门沟通效率，我们对平台需求做了如下分析： 1）架构分层，逐层解耦 为加快灾备建设进度，保护行内已有投入，灾备指挥平台需要采用松耦合分层架构，实现通 用性和弹性，层与层之间没有强依赖，使用 API 接口调用，每一层都可以使用市面上符合 要求的开源或商用产品。主要分层包括：展示层、数据层、调度指挥引擎、