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，主要应用对外服务主要由日库和夜库、卡库、报表库四个数据库组成。日库承载全部业务交易数据；夜库承载每天日库批处理过程中发生的交易数据，当批处理完成后夜库数据再汇入日库，卡库承载卡相关业务，通过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.用于核心库、卡库准生产系统 | 1.卸数库主机 | 不需要 | |
同城容灾中心存储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信号灯和负载均衡流量控制，开启外围业务系统，开启图形前端节点信号灯
业务测试及环境检查
业务测试完成之后，可以发起核心存储由容灾中心到主中心的反向数据复制，检查确认存储同步复制的方向后，也就完成主中心向容灾中心的切换。
4.2 核心存储同城容灾切换主要操作与状态转换
步骤1 生产到容灾中间网络链路检查及SRDF状态查询
图9：同城容灾存储切换前状态
步骤2 存储同步复制断开split
图10：同城容灾存储同步复制断开状态
步骤3 存储同步复制方向对调swap
图10：同城容灾存储swap动作
步骤4 核心存储复发起数据同步复制（JB原生产数据会被覆盖）establish
图11：同城容灾存储swap后发起同步状态
4.3 同城容灾切换实践经验总结
核心系统存储同城容灾切换演练完成后，有下面几点还是值得复盘的：
第一、同城容灾切换过程中，存储同步复制通过split命令断开后，主中心与容灾中心数据均为可以读写状态，如果容灾端验证数据的过程中，主中心数据被更改，将失去最直接的一份数据保护。为保护主中心生产数据不被破坏，存储采用failover命令去切换存储，这样在R2端提供生产服务同时，R1端数据将保持只读状态，补充示意图：
图12：同城容灾存储切换采用failover状态
第二、对于主中心与容灾中心的波分DWDM线路要实时进行监控与冗余性检查
主中心与容灾中心的存储复制是通过波分设备DWDM实现的，当波分之间线路不稳定，造成延时大或者时断时续的情况时，轻则影响存储同步复制的传输速度，重则会造成存储设备的RDF端口Partitioned，影响切换动作而且恢复时间不可控；
数据通过下面这条路径传输的过程中，监控尽可能布置在存储设备、SAN交换机和波分设备上；
数据传输路径：主中心存储-----主中心SAN交换机-----经跳线架-----主中心波分-----运营商线路--------容灾中心波分---光纤直连---容灾中心SAN交换机-------容灾中心存储
存储设备可以通过symrdf ping/symsan/symrdf命令检查远端设备连通性，连接端口状态，以及RDF pairs状态
表4：同城容灾存储切换命令检查监控表
光线交换机可以通过fcping和zonevalidate
表5：同城容灾光纤交换机检查监控表
5. 项目效果
5.1 新一代核心业务系统上线运行情况
新一代核心系统的建设是某银行成立以来建设规模最大的科技工程，堪称其发展史上新的里程碑。项目关联外围近200个系统的改造与验收，历时近两年，参与人员超过500人。经过投产前的周密部署与调度安排，全行上下同心奋战，参与机构300余家，参战人员达到3000余人，投产历时18小时，比预计时间提前7小时，圆满完成了新核心系统项目群整体投产的各项任务，顺利完成投产上线，已正式对外营业一年零三个月，日均金融交易总笔数在近百万以上，日均请求总笔数近千万，响应时间在30毫秒左右，相比上一代和系统，日均请求数为100万左右，响应时间在100ms左右，各项指标均已达到了预期目标，
新一代核心系统的上线，标志着某银行翻开“智慧运营”新篇章。依托新核心系统这一新的发展引擎，借助金融科技的引领，该行将持续从客户体验、服务效能、流程优化等方面着手，积极构建新型商业银行运营服务模式，进一步加快发展和服务转型，助力智慧银行建设，全面提升核心竞争优势。
5.2 核心系统存储运行情况
新一代核心系统主中心存储Vmax200K已安全平稳运行2年左右，容量已经分配60%左右。因为分配已预留出未来2至4年的容量增长空间，所以容量分配上也没有过多的变更；内存的命中率都平均维持在60%左右，且几乎没有从内存到存储后端磁盘的写等待情况发生，后端压力不大而且压力平均；存储前端主机访问IOPS平均在10000以下,批量及高峰在24000左右，前端平均带宽300MB/s以下，压力不大，存储性能表现突出。
图13：新一代核心存储容量统计图
图14：新一代核心存储半年内性能统计图
核心系统也需要面对每日批量任务的挑战，如图15所示，当日23点左右有高并发的IO产生，读写各半，数据量并不大，但延时写WP数量和写延时激增，延时到十几ms，同城容灾 SRDF/s同步复制，需要将IO写到远端存储，返回后通知前端主机写操作完成，但如果大量密集IO操作，会使部分写操作超时无法返回，再次发起多次的写操作，最终导致在批量期间，大量业务超时情况出现。
图15：新一代核心存储每天性能统计图
临时的解决办法在大量IO操作的这段时间，暂时断开SRDF/s的复制保护，避开IO高峰后，再回复同步复制。永久解决的建议之一是在设计和测试之处，做好各个环节的测试，上线前将参数调整至最优，包括系统数据库、系统参数（条带化）、存储参数等，避免生产上线后无法调整底层参数的尴尬；另外，建议扩充生产与容灾端SSD pool中磁盘数量或使用全闪存储，提高存储读写性能，同时进一步缩短存储复制与DWDM链路延时，根本上解决在批量任务时存储无法满足响应时间的情况。
另外，非批量时间核心系统存储性能出现偶发性能较差情况，与SRDF/s同步复制IO返回慢也有直接关系，提高主生产与同城容灾存储读写性能，避免DWDM运营商链路抖动与高延时情况发生，就显得尤为重要，在未来向等保2.0要求的4级发展时，双活数据中心成败的关键，也在于存储本身的性能与存储间DWDM链路的可靠性和低延时性。
5.3 核心备份系统运行情况
核心系统每日批量完成后，手工执行业务数据备份，备份数据在虚拟带库中保存一周，并复制到同城容灾中心虚拟带库，两中心物理带库永久保存。
图16：新一代核心备份策略图
如图16备份策略中核心系统的SLP，备份任务由DataDomain虚拟带库完成并保存一周，后续复制到同城数据中心DataDomain虚拟带库保存一周，由于复制关系是一对一，因此目标备份服务器target master中会配置成源端备份服务器所有的目标服务器，随后，主中心备份服务器还会按照SLP进行物理带库的永久保存， 传输到同城中心的另一份数据，会按同城中心SLP配置策略，导入数据后，在虚拟带库保存一周，物理带库永久保存。
5.4 核心系统同城容灾切换时间与改善目标
核心系统同城容灾经过数轮演练、功能性切换和正式切换，最近一次主中心到同城容灾中心切换耗时40分钟左右；分行网点验证近千笔非现金交易，涵盖对私客户所有类型，且验证无误；由同城容灾中心回切主中心耗时30分钟左右。
切换的过程整体比较顺利，个别环节还有需要完善。除在上面章节提到的通过技术层面提高切换安全性，监控层面提高切换流程可控性之外，从操作实施上也需要标准化，更快完成切换，如果可以实时显示切换过程，并且把切换过程标准化，利用自动化调度工具完成，在突发故障紧急切换时，可以降低人为操作风险，更快速、稳妥地完成容灾切换，恢复业务系统。
前面提出了一些技术和操作上的改善建议，最后从切换流程上也要在计划性灾难切换手册的基础上，补充非计划性的灾难恢复手册，其中存储故障导致非计划容灾切换的场景下，存储执行的步骤至少应包含：1）确认主中心存储故障且无法管理访问，进行故障恢复；2）通过同城容灾存储管理机，确认同城容灾存储同步复制状态：Patitioned，即无法发现对端存储设备；3）Split断开存储同步复制，启用同城容灾存储；4）启用容灾端数据库服务器，更改核心应用数据库连接指向，启动外围系统验证业务；5）生产端存储恢复后，安排维护窗口，用同城容灾端存储数据反向refresh生产端数据，业务回切；
6. 总结
新一代核心系统升级和容灾项目已基本完成，目前正处于“运行维护-发现问题-局部变更-总结经验-高效运行维护”的优化迭代过程，加强监控手段，优化监控工具，提高运维对故障的相应速度，完善应急处理预案，优化变更管理流程，完善运维知识库，不断提升运维效率已经转变为重点工作。
对于光纤交换机、存储设备和备份设备的监控，采用厂商管理软件监控、存储集中监控和行内监控告警平台，这三级监控和管理系统进行故障告警、设备维护、变更管理、性能监控等日常运维工作。通过各厂家产品的管理软件进行健康检查，诊断与定位问题准确，便于数据收集与原厂商沟通，如用Unisphsere for Vmax来管里Vmax200k等高端存储设备，因此使用存储厂商管理软件作为第一级监控；但由于行内存储产品品牌众多，不便于存储设备的日常统一管理，行内的监控平台也无法兼容存储的管理统一管理协议，因此部署了TPC监控软件和开源的Stor2RRD软件，接管绝大多数的存储设备，作为第二集监控平台统一管理存储容量、告警时间生成报告；第三层监控是配置每台存储设备的带外管理IP，定义故障级别和过滤条件之后，设备第一时间自动发送SNMP trap到告警服务器，通过MIB库将告警内容翻译过来，再发送给相应存储管理员进行报修与维护。越来越多的监控需求需要监控工具优化与二次开发，如在同城容灾切换实践经验总结中提到的存储状态监控和SAN交换机内执行检查命令，提取关键字作为判断的情况，需建立和管理好监控账户权限与监控频率，才能让设备运维更高效；此外，变更管理流程也至关重要，根据变更内容与影响范围，通知相关厂商、业务人员甚至前台网点进行前期准备测试、变更保障和后期变更验证，更新相关配置项后，一项变更才算完整有效；变更结果更新也会产生一系列联动的变更操作，核心系统需要增加逻辑磁盘补充数据库空间，给出容量、性能等需求到系统管理员和存储管理员，赠加分配容量之后，会触发调整参考库、卸数库、准生产的克隆关系以及同城、异地容灾复制关系，从而触发系统管理员进行逻辑磁盘管理、集群软件参数调整变更，同时触发备份管理员LAN-FREE备份系统重新扫描SAN链路识别逻辑磁盘。经过一段时间的积累和总结之后，将上述问题产生、根本原因和相关处理变更结果进行总结录入知识库，作为后续问题处理的依据和参考，从而会为高效运维迭代过程中做出特有贡献。
最后，希望以上文字能给从事相关工作的同行们项目建设提供参考和依据，本人也本着开放的心态，随时欢迎对上文中提到、未提到的内容进行探讨。
