1.1 原有业务系统架构以及核心系统面临的挑战
某银行核心系统自2006年投产以来，有效的支撑了某银行业务的快速发展，但由于原有的核心系统受到传统系统架构的限制，以客户为中心的设计程度较弱，参数化和产品组件化程度不高，在客户体验、产品创新、差异化定价、参数管理方面的需求响应程度较弱。整体开发实施费时费力，周期过长，不能快速响应业务部门的需求，对未来银行的业务发展支撑能力不足。
1.2 银行新一代核心系统业务架构设计原则
核心系统在银行业务体系中处于重要地位，通过新一代核心系统建设，从整体架构、系统功能、产品功能、数据支持和技术创新等各方面实现核心系统全方位能力的提升，进一步满足未来金融市场的需要。实现高度业务规则化、产品参数化、技术组件化、数据标准化的信息系统，以便能够更高效、更敏捷、更安全地响应业务创新发展的要求。
1.3 新一代核心系统业务架构建设规划
核心系统软件在多法人、事业部制、客户信息管理、产品工厂、交易核算分离、机构柜员、公共业务、账务处理、资产业务处理、负债业务处理、银行卡业务处理、凭证式国债、支付结算业务处理、清算业务处理、内部管控、集成接口等方面具备足够的业务支持能力，同时满足产品创新、差异化定价和利率市场化的要求。
核心系统支持分层、松耦合、面向服务的SOA架构，以适应IT系统、服务、产品、流程变化的能力；平台需满足可靠性、可维护性、可移植性、高可用性、系统稽核性、安全性、开放性、扩展性等非功能性需求；系统性能需求主要包括：对集群的支持、文件传输方式的要求、多节点应用部署能力、批量控制、接口性能、并发度控制、数据库几个方面。基于硬件设备的拓展，核心系统应能够提供1.5亿账户数下的支持与服务；数据标准要求：符合某银行数据标准需求，实施的设计方案要符合某银行数据标准，数据架构及数据模型应符合某银行相关IT规范及数据标准的要求。核心系统软件还具备高稳定性、高可靠性、高安全性、高性能等非功能性要求。在技术能力上需要满足以下特征：支持集群部署、灵活的架构设计、组件化的应用、7*24小时不间断服务能力、数据安全管理、快捷高效的二次开发、详尽的产品文档支持、全面地运维监控等。
2. 银行新一代核心系统基础架构整体设计
2.1 原有核心系统基础架构
原有核心系统如图1所示，核心系统以小型机为主，核心存储为VMAX40k，承载核心系统数据库、CICS中间件、MCP及ESB等系统，为适应架构、性能、数据标准、IT规范与数据标准、技术能力等不断变化的要求，需要设计并搭建新一代核心系统基础架构。
图1：原有核心系统基础架构
2.2 新一代核心系统基础架构资源补充与设计
新一代核心业务系统采用的是某核心厂商的产品，按照产品功能分为核心模块、卡模块、前端模块、报表模块，按照数据不同特性将核心数据划分为四个数据库。应用和数据库安装在目前较为成熟的AIX 7.1 和 RedHat 6.8操作系统中，数据库采用的是DB2 10.5，报表应用的中间件使用的是WAS 8.5，其他模块应用未使用单独的中间件产品。图2是核心系统整体的逻辑架构图：
图2：新一代核心系统逻辑架构图
核心系统服务发布
核心系统对外提供服务方式主要分为2种，一种是间接访问方式：网上银行、手机银行等外围系统访问发布在ESB（企业服务总线）的核心系统服务。第二种直接访问方式：柜面系统、ESB、BANCS LINK直接访问核心业务系统服务。第一种方式ESB通过发布通用的Web services的接口，减少外围的报文格式转换，提高了外围系统的改造工作量，提高了外围系统的接口调用的稳定率。采用第二种方法的系统属于调用接口较为复杂或与核心系统报文接口相似的系统，这类系统一般不适合通过ESB进行调用。
核心系统四节点多活模式
核心系统系统对外提供服务采用四节点多活模式，四节点中任意节点都可独立提供全部的核心联机服务。ESB（企业服务总线）按照一对一原则与核心系统应用进行连接，ESB又将自身的服务发布在负载均衡设备上，外围系统只连接负载均衡设备，负载均衡设备采用权重轮询算法将外部的访问请求均衡的分布到各个ESB节点，最终均衡的访问到核心应用的四个节点中。一旦某一ESB节点、核心应用节点出现问题，通过负载均衡关闭对应应用通过即可，不影响其他节点提供对外服务。
核心系统日库、夜库、卡库、报表库功能
核心数据库采用DB2 v10.5，主要应用对外服务主要由日库和夜库、卡库、报表库四个数据库组成。日库承载全部业务交易数据；夜库承载每天日库批处理https://www.3tt.net/?mod=artinfo&aid= 813过程中发生的交易数据，当批处理完成后夜库数据再汇入日库，卡库承载卡相关业务，通过AIX HACMP构建的HA进行数据库的第一层保护。通过数据库的DB2 HADR技术作为第二层保护，DB2 HADR将生产库的数据实时复制到目标数据库，形成生产数据库的只读库,只读库可以承载一部分查询业务，并且当生产库发生故障时，也可以激活只读库为可写库，起到生产库备机的作用，目前HADR库未连接任务应用。参考库作为批处理过程中对日库数据的参考，数据来源于批处理前对日库的存储快照。报表库的实时数据是通过CDC数据实时同步软件复制日库、夜库、卡库相关表实现的，同时报表库每日核心批量完成后，会加工卸数库的表的数据，并将加工后的结果存入报表库中。
随着自有产权的新数据中心建成，生产数据中心、同城容灾以及异地容灾数据中心均发生变化，同城容灾规划架构如图3，新一代核心系统项目在新数据中心投入必要主机、存储与网络资源，确保新一代核心系统基础架构资源方面能够满足功能要求、性能需求、数据标准要求以及稳定、可靠、安全等非功能性要求。
图3：新一代核心系统同城容灾架构图
同城、异地容灾数据中心存储资源，需要对原有数据中心基础架构存储资源进行扩容、搬迁利旧重新配置等工作，最终实现新的两地三中心架构。如图4两地三中心存储容灾架构所示：绿色为现有存储资源，橘色为需要搬迁或重新部署后补充进存储资源池内使用。核心存储部分除Vmax200k新购安装之外，其余Vmax40k都需要扩容及搬迁、重配置。
图4：两地三中心存储容灾资源补充架构图
3. 核心存储及备份方案
3.1 核心存储光纤交换机实施方案
核心存储光纤交换机型号为F96，两台设备组成独立的Fabric网络，考虑到核心主机访问生产数据传输、备份网络（SAN）数据传输与同城容灾存储同步复制数据三部分的需求，在FOS层将光纤交换机划分为三个虚拟逻辑交换机：包括一个核心存储交换机、一个备份用交换机和一个存储复制用交换机，每个逻辑交换机有各自独立的Zone配置文件，仅对存储复制用逻辑交换机主中心和容灾中心间进行级联，简化级联zone配置，便于故障的迅速定位与排查，也便于存储管理员、备份管理员和容灾管理员等不同职责权限人员进行独立管理与变更。
三组逻辑交换机视图如下，光模块可以在三组逻辑交换机之间调整（调整过程中会被disable掉）
核心存储逻辑交换机：均为核心主机数据访问HBA卡端口与核心存储前端口
图5：核心存储逻辑交换机
核心备份逻辑交换机：均为备份主机HBA卡端口、物理带库drive端口和虚拟带库前端口
图6：核心备份逻辑交换机
存储复制逻辑交换机：均为交换机级联端口与存储复制RDF端口
图7：存储复制逻辑交换机
3.2 核心存储实施与配置方案
核心存储在实施与配置早期，需要根据新购存储的自身情况，按照生命周期管理原则，规划整理好核心系统的基本分配需求、查询或保护克隆需求、同城容灾系统需求以及备份需求等。
当前核心存储配置如表1：
表1：核心存储配置表
主中心存储Vmax200k配置
同城容灾Vmax40k扩容后配置
异地容灾Vmax40k扩容配置
引擎配置
双引擎（每个引擎512G内存）
双引擎（每个引擎256G内存）
单引擎（每个引擎192G内存）
硬盘托架
120槽位2.5英寸硬盘托架4个
15槽位3.5英寸硬盘托架24个
15槽位3.5英寸硬盘托架8个（待扩容）
硬盘配置
2.5” 960GB SSD闪盘50块（含2块热备），
2.5” 10K 600GB磁盘196块（含4块热备）；
3.5”800GB SSD闪盘18块（含2块热备），
3.5”400GB SSD闪盘74块（含2块热备），
3.5” 15K 600GB磁盘204块（含12块热备）；
3.5” 10K 900GB磁盘48块（含4块热备）；
待扩容
前端口
16个16G前端口
32个8G前端口
16个8G前端口
本地数据复制
30T本地数据复制软件容量许可
30T本地数据复制软件容量许可
SRDF远程数据保护
30T SRDF远程数据保护容量许可
30T SRDF远程数据保护容量许可
远程数据保护容量许可
存储池
SSD闪盘使用RAID5，形成可用空间30TB存储池；
SAS硬盘使用RAID10，形成可用空间50TB的存储池；
SSD闪盘使用RAID5，形成可用空间30TB存储池；
SAS硬盘使用RAID10，形成可用空间50TB的存储池；
SAS硬盘使用RAID5，形成可用80TB存储池；（待扩容）
逻辑卷
每个LUN大小统一为200GB
每个LUN大小统一为200GB
每个LUN大小统一为200GB
3.2.1 核心存储基本分配
核心存储基本分配考虑功能、容量、性能需求，划分如表2，标注共享部分还需要分配10GB HDD逻辑磁盘作为PowerHA心跳磁盘使用。
表2：核心存储分配表
存储设备
用途
LUN大小
个数
磁盘类型
备注
主中心存储Vmax200k
核心数据库主机
200GB
21
SSD
共享（附心跳盘）
核心数据库备机
核心数据库HADR只读库
200GB
21
HDD
卡库主机
200GB
9
SSD
共享（附心跳盘）
卡库备机
卡库备机只读
200GB
9
SSD
参考库主机
200GB
17
HDD
共享（附心跳盘）
参考库备机
卸数库主机
200GB
17
HDD
共享（附心跳盘）
卸数库备机
报表库主机
200GB
10
HDD
共享（附心跳盘）
报表库备机
CDC主机
200GB
2
HDD
共享（附心跳盘）
CDC备机
200GB
同城容灾中心存储Vmax40k
核心数据库主机_同城容灾
200GB
21
HDD
卡库主机_同城容灾
200GB
9
HDD
参考库主机_同城容灾
200GB
17
HDD
卸数库主机_同城容灾
200GB
17
HDD
报表库主机_同城容灾
200GB
10
HDD
CDC主机_同城容灾
200GB
2
HDD
异地容灾中心存储Vmax40k
核心数据库主机_异地容灾
200GB
21
HDD
卡库主机_异地容灾
200GB
9
HDD
3.2.2 核心存储Clone需求配置
核心系统数据库在指定时间点对核心数据库存储数据发起克隆，对核心数据库影响时间极短（从核心数据库Suspend、克隆命令完成，到核心数据库恢复的秒级时间），克隆的目标数据可用于备份、功能测试和报表功能，新一代核心系统中除上述用途外，也采用克隆数据进行容灾切换前的数据保护和准生产环境搭建及核心数据库的投产测试等功能，如表3所示。用作保护的克隆功能，区别于其他用途，需要确认克隆数据100%同步完成，再对克隆源端数据读写；另外需要准备克隆的反向刷新脚本，一旦源端数据被破坏，需要对调克隆源端、目标端卷ID，用做克隆数据进行恢复源数据卷，谨慎保存反向克隆脚本。
表3：核心存储Clone配置表
存储设备
克隆数据库
克隆数据库用途
克隆库来源
反向clone
主中心存储Vmax200k
参考库主机
核心数据库批前克隆备份
核心数据库主机
需要
卸数库主机
核心数据库批后克隆备份、卸数
核心数据库主机、卡库主机
需要
核心数据库HADR主机
在同城容灾搭建之前、预防生产库主、备机故障，同城容灾搭建后，会迁移至其他存储，并取消clone
卡库备机只读
不需要
核心准生产主机
1.用于核心库、卡库准生产系统
2.同城容灾切换前数据保护
1.卸数库主机
2.核心数据库主机
不需要
同城容灾中心存储Vmax40k
参考库主机_同城容灾
同城容灾核心数据库批前克隆备份
同城容灾核心数据库主机
需要
卸数库主机_同城容灾
同城容灾核心数据库批后克隆备份、卸数
同城容灾核心数据库主机、卡库主机
需要
异地容灾中心存储Vmax40k
暂无需求
3.2.3 核心存储容灾配置方案
容灾规划设计的基本策略是“大同城、小异地、以用代备、资源复用”，新建主生产中心承担生产系统、内部办公系统、准生产验证、研发测试等环境的设备运行与维护工作，分支行网点、社保等三方机构、网上银行等外联线路的主要接入点；同城容灾中心承担关键系统的容灾运行服务，按应用系统风险度评估结果，差异化配置同城容灾资源，能快速恢复保证网点、线上业务正常服务，监管报送类系统能够及时报送，并满足监管对于RTO、RPO的基本要求，能够在业务高峰期，作为辅助资源分流业务；异地容灾中心第一阶段建立核心系统等关键生产系统的数据级容灾，确保关键生产数据安全，满足监管最低要求；第二阶段实现应用级容灾，在极端情况下，能够恢复网点基本营业，保障基本的对客户服务能力，满足当前监管要求。
核心系统同城容灾采用SRDF/S将主中心核心存储数据同步复制到同城容灾数据中心；异地容灾通过SRDF/A异步复制，将同城数据中心数据复制到异地容灾中心，作为数据保护与验证。
如图8所示，同城与异地容灾存储配置如下：
图8：同城与异地容灾存储配置图
创建与使用同城和异地存储复制关系步骤需要如下五步：
存储间建立复制RA端口连接
同城容灾中心间通过DWDM设备连接两中心F96光纤交换机，并在两个独立的光纤网络中，配置两存储RA端口zone，确认存储端口物理连通；类似，异地容灾中心之间配置SAN Router R06通过WAN网，连接同城中心与异地中心存储端口。
存储内创建SRDF RA端口组
根据存储配置文件中端口的定义，选择属性为RF，且与对端连通的端口作为RA组成员，主中心存储4号RA端口组包含1e/2e/3e/4e的port7四个端口，对应的同城中心同步复制4号RA端口组包含7f/8f/9/10h的port0四个端口；异步复制在同城、异地中心的端口组号为30，分别包含8h/9f的port0和7h/8h的port0。
存储内将复制逻辑卷组成DG
按照业务不同，将需要复制的逻辑卷放入该业务DG中，根据复制关系，指定DG在存储关系中的类型，目前通常设置为动态RDF类型，便于随时改变复制方向。
存储间建立复制关系
源卷R1与目标卷R2建立好pair对应关系后，指定复制关系的本端存储与远端存储，和复制需要的RA端口组。
发起、断开数据同步，验证同步数据
通过对之前定义的DG操作，可以发起组内多个逻辑卷的数据复制，查询数据复制速率与状态，断开数据复制关系，使远端逻辑卷Write Enable，以及配合业务系统进行的存储复制数据切换、回切等动作。
配置上值得关注的同城中心的逻辑卷，同时作为主中心的目标卷与异地中心的源卷，因此该逻辑卷组成的DG属性为R21，这种处于复制关系中间结点的存储，不但对RDF端口数量上有要求，对存储前端Cache容量也有相应的要求，配置不当会影响提供生产服务的存储性能。
3.3 核心备份系统实施与配置方案
按照新一代核心系统签署的数据管理协议，兼顾在2019年12月1日正式实施的等保2.0备份与灾难恢复的规定，核心备份系统对业务数据、系统数据和系统软件应进行基本的本地备份与恢复，此外随着测评级别的提高，对数据和业务的连续性要求也随之提高，除备份之外，还要有数据和业务系统的本地高可用和异地容灾手段，这两部分可以通过集群软件、数据库复制软件和存储复制等功能实现。
图9：核心备份系统架构图
如图9核心备份系统架构图所示：左右两侧主、备数据中心备份系统均配有备份服务器集群，通过LAN和SAN两个网络对该中心服务器进行本地的备份与恢复；等保2.0二级技术要求中需要的异地定时备份由虚拟带库DataDomain的DDBoost Association来实现，配合NetBackup备份软件对于服务器备份策略的生命周期SLP实现备份数据到容灾端备份服务器的Replication复制和备份数据在本地物理带库落地备份。
为了降低重复数据备份的比率，减小以太网络的数据传输压力，安装了DDBoost OST插件的服务器会在传输备份数据之前，通过计算与对比，规避重复数据的传输，实现源端去重功能。除此之外，NBU备份服务器通过SAN网络识别存储设备上映射给服务器的逻辑卷，以只读方式将数据传输至虚拟带库或虚拟带库，也会减少备份任务耗时，减少物理磁带消耗，同时也大大降低备份LAN网络的数据传输压力（随着备份次数增多，带宽可减少90%以上）。
4. 容灾切换流程与切换实践经验
监管部门对于实现银行关键业务与服务渠道的高可用性保障提出了明确的要求，并且将银行IT系统的容灾能力纳入了相关监管指标，根据监管的要求，以及我行的实际情况，2019年科技部门启动了围绕新核心系统的两地三中心容灾体系建设工作，并列入本年度科技重点工作。
为达到既要落实监管要求与保障生产安全，又要有效控制成本的工作目标，协同风险、合规、内审以及主要业务部门，针对行内当前系统，以保障核心业务、关键对客服务渠道、监管报送等为主要目标，设计了配套的评估流程与算法，经过量化评估，最终确定，在2019年度首期实现，36套应用系统实施同城容灾，复杂程度最高的核心系统，容灾切换步骤将会作为其他应用系统标准和参考。
4.1 核心系统同城容灾主要切换流程
核心系统同城容灾切换分为两个过程，主中心向容灾中心切换和容灾中心向主中心切换。切换步骤类似，以主中心向容灾中心为例，切换步骤分为切换前检查、生产环境服务停止、切换并启动容灾服务、业务测试及环境检查几个步骤。
图10：核心系统同城容灾切换流程图
切换前检查
当日核心批量和备份结束后，检查生产系统健康情况，并在准生产环境克隆一份当日最新核心数据库做一份逻辑保护（该步骤为提前追数），当以外发生时，可以使用克隆数据反向刷新进生产系统作为数据还原。后续应用环境进行快照备份，需要在全闪NAS中做一份当日最新的snapshot；后续是容灾环境健康检查与生产到容灾中间环境的网络链路检查，包括SAN环境以及波分设备的连通性；
生产环境服务停止
并行完成下面五项内容：停止所有外围系统、停止所有通过CDC实现的日、夜、卡库逻辑复制、停止企业服务总线信号灯、停止企业服务总线负载均衡流量、停止图形前端信号灯，之后串行执行核心应用系统的停止，检查核心数据库和卡库流水表，停止核心数据库和卡库，准生产克隆数据一份日、夜、卡库实现逻辑保护，完成后主生产中心到容灾存储的同步复制断开并对调两生产中心的复制方向；
切换并启动容灾服务
开通网络主中心到容灾中心的网络VLAN之后，容灾端主机核对并更新VG信息之后，会启动核心数据库和卡库，再次比对检查数据库的流水表，与之前主中心结果比对一直之后，启动核心数据库应用，启动数据库CDC同步复制，启动ESB信号灯和负载均衡流量控制，开启外围业务系统，开启图形前端节点信号灯
业务测试及环境检查
业务测试完成之后，可以发