作者简介：

张鹏，某银行。原就职于 IBM 、 DellEMC 公司，从事小型机及存储技术支持 10 年 + ，在小型机、高端存储关键技术有深入研究，在容灾项目实施、性能监控与调优以及运维管理有丰富经验。目前就职金融银行 3 年 + ，从事行内及子公司的存储、备份、应用负载、数字签名等设备运维管理、项目实施工作，曾参与行内新一代核心系统建设、容灾建设与切换演练、影像平台升级改造、村镇银行核心系统迁移与容灾等项目。在 twt 社区做过的技术分享《等保 2.0 时代，银行新一代核心系统升级及容灾项目实践》、《城商行异构存储统一监控分享》及《异构存储监控线上交流活动问题总结》。

文章简介：

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

1.项目建设背景

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

核心系统在银行业务体系中处于重要地位，通过新一代核心系统建设，从整体架构、系统功能、产品功能、数据支持和技术创新等各方面实现核心系统全方位能力的提升，逐步实现银行数字化，为对接“植入式”银行 4.0 夯实基础，进一步满足未来金融市场的需要。

2.需求分析

自 2006 年投产以来，核心系统有效的支撑了银行业务的快速发展，但由于原有的核心系统受到传统系统架构的限制，以客户为中心的设计程度较弱，参数化和产品组件化程度不高，在客户体验、产品创新、差异化定价、参数管理方面的需求响应程度较弱。整体开发实施费时费力，周期过长，不能快速响应业务部门的需求，对未来银行的业务发展支撑能力不足。

处于重要地位的核心系统需要实现高度业务规则化、产品参数化、技术组件化、数据标准化的信息系统，以便能够更高效、更敏捷、更安全地响应业务创新发展的要求。

核心系统支持分层、松耦合、面向服务的 SOA 架构，以适应 IT 系统、服务、产品、流程变化的能力；平台需满足可靠性、可维护性、可移植性、高可用性、系统稽核性、安全性、开放性、扩展性等非功能性需求；系统性能需求主要包括：对集群的支持、文件传输方式的要求、多节点应用部署能力、批量控制、接口性能、并发度控制、数据库几个方面。基于硬件设备的拓展，核心系统应能够提供 1.5 亿账户数下的支持与服务；数据标准要求：符合某银行数据标准需求，实施的设计方案要符合某银行数据标准，数据架构及数据模型应符合某银行相关 IT 规范及数据标准的要求。核心系统软件还具备高稳定性、高可靠性、高安全性、高性能等非功能性要求。在技术能力上需要满足以下特征：支持集群部署、灵活的架构设计、组件化的应用、 7*24 小时不间断服务能力、数据安全管理、快捷高效的二次开发、详尽的产品文档支持、全面地运维监控等。

3.改造目标

短期的改造目标是搭建一套稳定、安全、可靠的软硬件系统，突破早期传统架构带来的发展制约，快速响应业务需求变化；中期目标则是通过这套新系统技术和业务数据的积累，实现需求和技术的二次开发和快速迭代，掌握并预测数以亿计的客户需求变化和趋势；长期目标会着眼于全面提升核心系统的各项技术与功能指标，为银行数字化转型成功奠定基础。

4.方案架构设计

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

• 核心系统服务发布

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

• 核心系统四节点多活模式

核心系统对外提供服务采用四节点多活模式，四节点中任意节点都可独立提供全部的核心联机服务。 ESB （企业服务总线）按照一对一原则与核心系统应用进行连接， ESB 又将自身的服务发布在负载均衡设备上，外围系统只连接负载均衡设备，负载均衡设备采用权重轮询算法将外部的访问请求均衡的分布到各个 ESB 节点，最终均衡的访问到核心应用的四个节点中。一旦某一 ESB 节点、核心应用节点出现问题，通过负载均衡关闭对应的 ESB 节点通路即可，不影响其他节点提供对外服务。

• 核心系统日库、夜库、卡库、报表库功能

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

下图是核心系统整体的逻辑架构图，采用浪潮 K1 Power 小型机的重要系统模块用红色标注。

随着自有产权的新数据中心建成，生产数据中心、同城容灾以及异地容灾数据中心均发生变化，同城容灾规划架构如下图，新一代核心系统项目在新数据中心投入必要主机、存储与网络资源，确保新一代核心系统基础架构资源方面能够满足功能要求、性能需求、数据标准要求以及稳定、可靠、安全等非功能性要求，选择由浪潮 K1 Power 小型机承载重要业务系统和核心数据库，具体应用请见下图标注。

按生产和容灾的方案架构，给出浪潮 K1 Power 小型机使用的型号，资源分配和情况列表，原则是利用现有资源和新采购相结合，同时利用 PowerVM 虚拟化技术提高资源利用率，完成上述关键业务系统的承载，配置详情如下：

文件系统规划，按照标准系统部署操作，包括 rootvg 中各系统文件系统大小， SAN 存储 VG 类型、 PP size 和 Concurrent 属性，逻辑卷大小、属组关系，文件系统大小与访问权限，网络存储本地与远程挂载点，自启动配置等。

存储配置规划，按照未来数据增长速度，将存量与增量内容考虑进去，有 PowerHA 的需要逻辑卷共享并配置心跳磁盘，有 CDC 和 HADR 的需要分离存储设备，避免存储单点，有数据库 Clone 要求的，需要梳理好逻辑关系；

5.方案实施经验

5.1 破坏性测试

破坏性测试是系统正式上线运行前必不可少的一环，测试目的是配合压力测试的场景，连带应用负载共同测试，模拟系统上线后的实际运行情况，并通过对单点主机电源、网络线路、光纤线路、操作系统的破坏性关闭与断开，观测对业务连续性的实际影响，判断计划性和非计划性宕机各种情况。配置系统层面高可用软件（ PowerHA ），数据库层面的复制技术（ DB2 HADR 和 CDC ），以及存储层面的复制技术（ Clone ），防患设备故障与逻辑故障对生产系统造成不良影响。

核心系统的破坏性测试场景包含架构中的各功能主机数据库和应用服务器，如核心系统日间联机交易、卡库数据库运行、参考库运行、数据库复制 CDC 运行等场景的 PowerHA 主备机切换过程，记录自动切换及应用时间、数据库同步 CDC 软件和 HADR 库的同步状态及恢复有效操作。

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

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

5.2IBM Power8服务器（E870/S824/850）UAK过期

IBM Power8 的服务器 UAK 过期后，需要运维人员提前从 IBM 官网申请新的 license ，输入后找原厂来消除故障码。另外该问题也在新版 HMC(V9 R1 M931) 补丁中得到解决。新版的浪潮 K1 Power HMC 产品提供了关闭 UAK 提示的命令，并可以手工关闭当前亮灯。提前申请 license 和升级 HMC 版本都可以避免行内监控系统因此类问题，产生高级别的故障告警且在段时间内无法消除的窘境。

另外，浪潮商用机器有限公司成立以后，所有出货的浪潮 K1 Power 产品都没有这个 UAK 过期告警的问题。

5.3PowerHA 补丁更新

在核心系统上线前或系统运行过程中，要定期关注操作系统集群软件 PowerHA 等其他软件的更新内容，对照生产系统的基线版本，对生产系统有高等级影响的补丁需要安排时间进行计划性升级变更。

本次项目所使用的集群软件 PowerHA 版本为 7.1 ，在系统上线近 8 个月之后，发现 PowerHA 发布高风险等级的补丁 APAR IJ15739 ，内容是 clstrmgr 进程在运行一段时间后，会发生内存泄露，触发主节点向备节点的切换。

这种未知时间的切换会对业务造成一定影响，因此需要安排维护窗口，主动进行补丁升级至 PowerHA 7.2.1 Gold 或 iFix IJ10601 安装。

安装此补丁需要停止 HACMP 的服务，经测试，在承载数据库和文件系统正常运行的情况下，仅停止 HACMP 服务进行补丁安装，不不影响正常运行，但存在 HACMP 服务无法正常启动或是在操作过程中触发 HACMP 切换，导致服务中断，因此选择在系统切换演练或者维护窗口安装补丁。

5.4 监控与趋势分析

项目在上线后，需要对核心系统进行长期监控和性能数据的收集，目的是：对前期的规划设计进行总结评估、对系统性能进行持继的优化。通过行内监控及自建监控系统对操作系统及浪潮 K1 Power HMC 性能数据进行综合分析可以满足上述要求，总结如下：

性能监控

• 核心系统 CPU 日使用率

CPU 的日使用率图是纵坐标 CPU 实时使用情况在横坐标 24 小时内这个时间维度的描述，核心系统数据库主备机、核心应用四台主机、卡数据库主备机的每日 CPU 使用率曲线用下图红色曲线描绘出，绿色为系统配置授权的 CPU 数，从下图中看出，各系统处理器均保持在较低的负载水平，核心应用负载非常均衡，数据库主机业务量比较大，尤其在夜间批量时间段，而 PowerHA 备机基本没有压力。

• 核心系统 CPU 周使用率

CPU 的周使用率图是纵坐标 CPU 实时使用情况在横坐标 7 天这个时间维度的描述，核心系统应用、数据库与卡数据库数据基本为上述日使用率的重复，无异常情况也无切换情况。

监控系统从操作系统内部 agent 每日抓取的 CPU 使用率柱状图中，也印证了上述分析结果，但图中仅能看到使用和分配的日平均百分比，并不会看到实际的 CPU 分配和使用数，以及动态变化的过程。

• 核心系统内存分配与使用

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

监控系统从操作系统内部 agent 每日抓取的内存使用率柱状图中，会发现核心数据库和核心应用 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 ；粉色强烈建议是调整六个分区的 entitlement CPU 值；绿色的通知是后面的六个 LPAR 的 VP 、 entitlement 值可以减小至推荐值，补充其他分区，其他分区 CPU 设置比较合理均标注为 OK 。

• 内存调整建议

与 CPU 调整建议类似，内存建议针对针分区缺少内存或者内存可以被减少的系统而提出增删数量，如下图所示。

• 趋势分析

根据核心系统长期监控的性能数据分析，由于业务不断增长而带来的资源增长需求，会体现在监控软件年度、季度和月度的趋势曲线中，以下图核心数据库主机的分区为例，图中展示年度 CPU 使用情况，并给由不同时间段分析出的增长趋势曲线，便于后续资源重分配与系统调优。

6.效果总结

基于浪潮 K1 Power （原 IBM Power ）的硬件平台、操作系统和集群软件，核心系统出色地经受住了包括破坏性测试，性能测试和业务压力测试在内的一些列严格到苛刻的各项挑战，并以稳定的产品性能、成熟的技术累积和丰富的解决方案支撑保障核心系统项目的顺利完成和验收。核心系统集成项目完成之后，行内通过多个维度考量项目集成的效果，主要分为项目沟通管理、人员管理、进度管理、实时质量、知识转移和信息安全几个方面。比较关键的考量指标是实施质量、信息安全和实时进度。实施质量中需要考量实施管理、测试管理、投产管理和验收管理。具体要求集成工作要遵守行操作规范，不影响其他生产系统，测试完整全面并达到测试目标，投产准备工作细致，方案完善，产品验收通过率高不需要修改等；另外信息安全和实施进度也非常重要，保质保量、安全规范的完成项目实施，是本核心项目的基本要求。最后项目顺利完成，现已进入运行维护阶段，通过不断监控、调整与变更管理，容灾切换演练等技术手段，保障系统长期健康平稳运行。