基于浪潮K1 Power的城商行核心系统升级改造方案

1、 基于浪潮 K1 Power 的城商行核心系统升级改造方案 【摘要】本文从某城商行核心系统升级改造项目为背景，根据近十多年以来银行业业务发展的功能与非功能需求，建立短期以及中长期的核心系统改造目标，详尽设计核心系统的业务逻辑，基础架构和浪潮 K1 Power 小型机选型配置，总结破坏性测试、小型机实施运维、监控趋势分析等多阶段、多维度项目实施和运维管理经验，为同业核心系统升级和改造提供可参考、可操作的真实案例和宝贵经验。文章最后从项目考量方向给出评价和验收维度，总结项目实施的效果，相信对同业项目交付的后评价，有借启发和借鉴意义。1.项目建设背景当银行迈入以智能方式提供无感知服务的4.0阶段，银

2、行服务将会通过各种方式出现在我们周围，随着数字化技术普及，个人银行账号可能来自技术公司的智能设备，而非来自于实体银行。这种银行改变方式带来的挑战不但来自传统银行业内部，也有来自于金融市场上的技术公司。未来会要求银行前中后台都要做出改变、所有业务与技术需要重构、经营模式需要转变。数字化水平的提升，有助于银行业弯道超车、实现跨越式发展。然而，当领先银行已经在享受数字化红利，大部分中小银行生存空间并不乐观。中小银行要想借助数字化实现错位竞争，不是一蹴而就的。“银行数字化，不是在所谓传统业务之外另建一套数字业务，应该是所有业务的数字化”。一家真正意义上的数字银行包含三大层次：一是底层基础数据平台；二是

3、中间核心业务层；三是顶层的经营决策层，做到智慧经营才是数字化的顶点。核心系统在银行业务体系中处于重要地位，通过新一代核心系统建设，从整体架构、系统功能、产品功能、数据支持和技术创新等各方面实现核心系统全方位能力的提升，逐步实现银行数字化，为对接“植入式”银行4.0夯实基础，进一步满足未来金融市场的需要。2.需求分析自2006年投产以来，核心系统有效的支撑了银行业务的快速发展，但由于原有的核心系统受到传统系统架构的限制，以客户为中心的设计程度较弱，参数化和产品组件化程度不高，在客户体验、产品创新、差异化定价、参数管理方面的需求响应程度较弱。整体开发实施费时费力，周期过长，不能快速响应业务部门的需

4、求，对未来银行的业务发展支撑能力不足。处于重要地位的核心系统需要实现高度业务规则化、产品参数化、技术组件化、数据标准化的信息系统，以便能够更高效、更敏捷、更安全地响应业务创新发展的要求。核心系统支持分层、松耦合、面向服务的SOA架构，以适应IT系统、服务、产品、流程变化的能力；平台需满足可靠性、可维护性、可移植性、高可用性、系统稽核性、安全性、开放性、扩展性等非功能性需求；系统性能需求主要包括：对集群的支持、文件传输方式的要求、多节点应用部署能力、批量控制、接口性能、并发度控制、数据库几个方面。基于硬件设备的拓展，核心系统应能够提供1.5亿账户数下的支持与服务；数据标准要求：符合某银行数据标准

5、需求，实施的设计方案要符合某银行数据标准，数据架构及数据模型应符合某银行相关IT规范及数据标准的要求。核心系统软件还具备高稳定性、高可靠性、高安全性、高性能等非功能性要求。在技术能力上需要满足以下特征：支持集群部署、灵活的架构设计、组件化的应用、7*24小时不间断服务能力、数据安全管理、快捷高效的二次开发、详尽的产品文档支持、全面的运维监控等。3.改造目标短期的改造目标是搭建一套稳定、安全、可靠的软硬件系统，突破早期传统架构带来的发展制约，快速响应业务需求变化；中期目标则是通过这套新系统技术和业务数据的积累，实现需求和技术的二次开发和快速迭代，掌握并预测数以亿计的客户需求变化和趋势；长期目标会

6、着眼于全面提升核心系统的各项技术与功能指标，为银行数字化转型成功奠定基础。4.方案架构设计新一代核心业务系统按照产品功能分为核心模块、卡模块、前端模块、报表模块，按照数据不同特性将核心数据划分为四个数据库。核心系统重要的应用和数据库都部署在成熟、稳定的浪潮K1 Power小型机上；多节点冗余架构应用，部署在x86架构的RedHat 7.4系统；数据库采用的是DB2 11.5，报表应用的中间件使用的是WAS 8.5，其他模块应用未使用单独的中间件产品。架构设计从核心系统服务发布，到应用多活联机服务，再到数据库高可用角度出发，既能满足上层核心与外围系统的业务访问连续性需求，又能保障核心系统自身健壮

7、健全的高可用需求。核心系统服务发布核心系统对外提供服务方式主要分为2种，第一种是间接访问方式：网上银行、手机银行等外围系统访问发布在ESB（企业服务总线）的核心系统服务。第二种直接访问方式：柜面系统、ESB、BANCS LINK直接访问核心业务系统服务。第一种方式ESB通过发布通用的Web services的接口，减少外围的报文格式转换，提高了外围系统的改造工作量，提高了外围系统的接口调用的稳定率。采用第二种方法的系统属于调用接口较为复杂或与核心系统报文接口相似的系统，这类系统一般不适合通过ESB进行调用。核心系统四节点多活模式核心系统对外提供服务采用四节点多活模式，四节点中任意节点都可独立提

8、供全部的核心联机服务。ESB（企业服务总线）按照一对一原则与核心系统应用进行连接，ESB又将自身的服务发布在负载均衡设备上，外围系统只连接负载均衡设备，负载均衡设备采用权重轮询算法将外部的访问请求均衡的分布到各个ESB节点，最终均衡的访问到核心应用的四个节点中。一旦某一ESB节点、核心应用节点出现问题，通过负载均衡关闭对应的ESB节点通路即可，不影响其他节点提供对外服务。核心系统日库、夜库、卡库、报表库功能核心数据库采用DB2 v11.5，主要应用对外服务主要由日库和夜库、卡库、报表库四个数据库组成。日库承载全部业务交易数据；夜库承载每天日库批处理过程中发生的交易数据，当批处理完成后夜库数据再

9、汇入日库，卡库承载卡相关业务，通过AIX PowerHA构建的HA进行数据库的第一层保护。通过数据库的DB2 HADR技术作为第二层保护，DB2 HADR将生产库的数据实时复制到目标数据库，形成生产数据库的只读库,只读库可以承载一部分查询业务，并且当生产库发生故障时，也可以将只读库激活为可写库，起到生产库备机的作用，目前HADR库未连接任何应用。参考库作为批处理过程中对日库数据的参考，数据来源于批处理前对日库的存储快照。报表库的实时数据是通过CDC数据实时同步软件复制日库、夜库、卡库相关表实现的，同时报表库每日核心批量完成后，会加工卸数库的表的数据，并将加工后的结果存入报表库中。下图是核心系统

10、整体的逻辑架构图，采用浪潮K1Power小型机的重要系统模块用红色标注。随着自有产权的新数据中心建成，生产数据中心、同城容灾以及异地容灾数据中心均发生变化，同城容灾规划架构如下图，新一代核心系统项目在新数据中心投入必要主机、存储与网络资源，确保新一代核心系统基础架构资源方面能够满足功能要求、性能需求、数据标准要求以及稳定、可靠、安全等非功能性要求，选择由浪潮K1Power小型机承载重要业务系统和核心数据库，具体应用请见下图标注。按生产和容灾的方案架构，给出浪潮K1 Power小型机使用的型号，资源分配和情况列表，原则是利用现有资源和新采购相结合，同时利用PowerVM虚拟化技术提高资源利用率，

11、完成上述关键业务系统的承载，配置详情如下：(点击图片放大)文件系统规划，按照标准系统部署操作，包括rootvg中各系统文件系统大小，SAN存储VG类型、PP size和Concurrent属性，逻辑卷大小、属组关系，文件系统大小与访问权限，网络存储本地与远程挂载点，自启动配置等。存储配置规划，按照未来数据增长速度，将存量与增量内容考虑进去，有PowerHA的需要逻辑卷共享并配置心跳磁盘，有CDC和HADR的需要分离存储设备，避免存储单点，有数据库Clone要求的，需要梳理好逻辑关系；5.方案实施经验5.1 破坏性测试破坏性测试是系统正式上线运行前必不可少的一环，测试目的是配合压力测试的场景，连

12、带应用负载共同测试，模拟系统上线后的实际运行情况，并通过对单点主机电源、网络线路、光纤线路、操作系统的破坏性关闭与断开，观测对业务连续性的实际影响，判断计划性和非计划性宕机各种情况。配置系统层面高可用软件（PowerHA），数据库层面的复制技术（DB2 HADR和CDC），以及存储层面的复制技术（Clone），防患设备故障与逻辑故障对生产系统造成不良影响。核心系统的破坏性测试场景包含架构中的各功能主机数据库和应用服务器，如核心系统日间联机交易、卡库数据库运行、参考库运行、数据库复制CDC运行等场景的PowerHA主备机切换过程，记录自动切换及应用时间、数据库同步CDC软件和HADR库的同步状态

13、及恢复有效操作。日间核心数据库主机发生宕机情况，则等待备机启动后，检查并启动核心和卡相关业务即可，但批量运行过程中如果发生数据库主机宕机情况，是核心业务系统中比较特殊的场景，需要考虑多方面因素与状态进行判断。在数据库主机进行PowerHA切换之前，会控制暂停外部交易，在此过程中，确认PowerHA备机数据库和CDC同步数据库状态，当备机切换完成并启动后，首先检查并启动核心和卡应用，检查调度工具状态和批量执行进度，如果批量检查脚本可以通过，则正常完成，若批量数据丢失而无法续跑，则需要停止日间数据库，通过批量任务执行前clone保护数据，将数据反向写回，再正常运行CDC和同步表对报表的导出动作，后

14、续通过应急批量流程，完成批量操作。对核心数据库、核心应用、卡数据库、卡应用、参考库、CDC的高可用冗余环节均做破坏性测试完成后，在硬件冗余架构、集群软件和应用负载的作用下，各系统均通过破坏性测试，并可以在分钟级恢复业务连续性。不过也发现在实施和部署检查之后疏漏的一些问题，如PowerHA的切换脚本在切换过程中，业务逻辑变更，启动顺序及相关应用连带发生调整；数据库主机的配置文件和参数在调优和测试后，与备机不一致，需要多次同步更改；数据库和应用服务器主机的相关文件系统、执行命令的权限经过多轮测试和调整后，与备机需要再次调整为一致，这些问题需要也需要在正式上线前更正并重新测试并验证。5.2IBM P

15、ower8 服务器（E870/S824/850）UAK 过期IBM Power8 的服务器UAK过期后，需要运维人员提前从IBM官网申请新的license，输入后找原厂来消除故障码。另外该问题也在新版HMC(V9 R1 M931)补丁中得到解决。新版的浪潮K1 Power HMC产品提供了关闭UAK提示的命令，并可以手工关闭当前亮灯。提前申请license和升级HMC版本都可以避免行内监控系统因此类问题，产生高级别的故障告警且在段时间内无法消除的窘境。另外，浪潮商用机器有限公司成立以后，所有出货的浪潮K1 Power产品都没有这个UAK过期告警的问题。5.3 PowerHA补丁更新在核心系统上

16、线前或系统运行过程中，要定期关注操作系统集群软件PowerHA等其他软件的更新内容，对照生产系统的基线版本，对生产系统有高等级影响的补丁需要安排时间进行计划性升级变更。本次项目所使用的集群软件PowerHA版本为7.1，在系统上线近8个月之后，发现PowerHA发布高风险等级的补丁APAR IJ15739，内容是clstrmgr进程在运行一段时间后，会发生内存泄露，触发主节点向备节点的切换。这种未知时间的切换会对业务造成一定影响，因此需要安排维护窗口，主动进行补丁升级至PowerHA 7.2.1 Gold或iFix IJ10601安装。安装此补丁需要停止HACMP的服务，经测试，在承载数据库和

17、文件系统正常运行的情况下，仅停止HACMP服务进行补丁安装，不不影响正常运行，但存在HACMP服务无法正常启动或是在操作过程中触发HACMP切换，导致服务中断，因此选择在系统切换演练或者维护窗口安装补丁。5.4 监控与趋势分析项目在上线后，需要对核心系统进行长期监控和性能数据的收集，目的是：对前期的规划设计进行总结评估、对系统性能进行持继的优化。通过行内监控及自建监控系统对操作系统及浪潮K1 Power HMC性能数据进行综合分析可以满足上述要求，总结如下：性能监控核心系统CPU日使用率CPU的日使用率图是纵坐标CPU实时使用情况在横坐标24小时内这个时间维度的描述，核心系统数据库主备机、核心

18、应用四台主机、卡数据库主备机的每日CPU使用率曲线用下图红色曲线描绘出，绿色为系统配置授权的CPU数，从下图中看出，各系统处理器均保持在较低的负载水平，核心应用负载非常均衡，数据库主机业务量比较大，尤其在夜间批量时间段，而PowerHA备机基本没有压力。核心系统CPU周使用率CPU的周使用率图是纵坐标CPU实时使用情况在横坐标7天这个时间维度的描述，核心系统应用、数据库与卡数据库数据基本为上述日使用率的重复，无异常情况也无切换情况。监控系统从操作系统内部agent每日抓取的CPU使用率柱状图中，也印证了上述分析结果，但图中仅能看到使用和分配的日平均百分比，并不会看到实际的CPU分配和使用数，以

19、及动态变化的过程。核心系统内存分配与使用核心系统内存的分配和使用率都比较稳定，并不会经常调整，因此以月使用率图为例介绍。下图中纵坐标为各物理机内存总数，不同颜色为不同浪潮K1 Power LPAR分配情况，最下面浅蓝色为Firmware占用内存。从下图中可以看出核心系统数据库主机会分配较大内存，而备机会相应调整内存便于其他分区的动态分配，而核心应用基本平分各自物理机内存。核心数据库备机的内存已完全可以满足业务要求，在主备机发生切换的场景也可以满足内存性能要求，此处建议核心系统数据库主机内存也可以调整分配给其他资源使用，提高内存利用率。监控系统从操作系统内部agent每日抓取的内存使用率柱状图中

20、，会发现核心数据库和核心应用02的使用率会维持较高的水平，其他系统内存使用率均在50%以下。内存使用率较高的是交易较多的体现，也是操作系统为提高效率一种手段，监控系统会实时监控，在需要的时候进行动态分配调整。热点与趋势分析CPU热点分布图监控软件对CPU使用情况进行统计，然后会自动将各LPAR（也可以以物理机为对象）将近1小时内的CPU使用率按每10%一个级别，在由绿至红的范围内加以标注，我们重点关注颜色等级比较高的分区即可，如下图所示，分区整体CPU使用率均在正常范围内，将鼠标放置相应LPAR，就会显示分区名称，重点加以关注。也可以按照CPU热点使用率进行排序，得到一张分区排名表，重点关注前10位的分区（物理机）状态，或定期生成性能报告，反馈给相应的系统与应用管理员。CPU调整建议CPU建议是根据LPAR或CPU池中规定周期内至少存在1个10-分钟使用尖峰的情况并且尖峰值已经高于LPAR已分配的CPU值（entitlement. CPU），也会列出那些授权CPU值不必要过高的LPAR或CPU池。如下图中，红色务必执行的建议有：第一个LPAR的VP调整为17，第三个LPAR的entitlement调整为3.4；粉色强烈建议是调整六个分区的en