城商行新一代核心平台高可用设计方案Word格式文档下载.docx
- 文档编号:16174476
- 上传时间:2022-11-21
- 格式:DOCX
- 页数:15
- 大小:569.07KB
城商行新一代核心平台高可用设计方案Word格式文档下载.docx
《城商行新一代核心平台高可用设计方案Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《城商行新一代核心平台高可用设计方案Word格式文档下载.docx(15页珍藏版)》请在冰豆网上搜索。
伴随着信息技术的发展历程,城商银行的IT系统建设在银监、人行等监管单位的指导下逐步形成里两地三中心的基础架构格局。
这里主要介绍笔者所在城商银行上一代基于同城主备双中心的核心系统基础架构。
本行核心系统即综合业务系统建设于08年开始上线运行,并于13年实现同城双中心容灾模式改造。
综合业务系统主要包括前置系统、渠道系统、核心后台系统三套应用系统组成,是全行最重要的业务生产系统,是管理核心客户信息、处理客户账户及核心总账、提供存贷款业务、支付结算业务、中间业务、进行产品创新的主要信息平台。
在多年的运行过程中有效的支撑了银行业务的运营与发展。
上一代核心系统基础架构拓扑图如下:
核心群业务应用采用高端PC服务器冷备模式核心1机和核心2机组成一套
冷备环境;
核心前台渠道1机和核心前台渠道2机组成一套冷备环境;
核心数据库系统运行在IBMPower小型机上,核心数据库1机和核心数据库
1机组成一套HA环境,通过使用PowerHA高可靠集群软件,利用冗余配置,消除单点故障,保证整个系统连续可用性和安全可靠性。
两台主机系统在整个运行过程中,通过“心跳线”相互监测对方的运行情况(包括系统的软硬件运行、网络通讯和应用运行情况等);
一旦发现对方主机的运行不正常(出故障)时,故障机上的应用就会立即停止运行,本机(故障机的备份机)就会立即在自己的机器上启动故障机上的应用,把故障机的应用及其资源(包括用到的IP地址和磁盘空间等)接管过来,使故障机上的应用在本机继续运行;
应用和资源的接管过程由PowerHA软件自动完成,无需人工干预;
当两台主机正常工作时,也可以根据需要将其中一台机上的应用人为切换到另一台机(备份机)上运行。
PowerHAforAIX解决方案始终提供可靠的监控、故障检测和业务应用环
境向备份资源的自动恢复,实现了核心数据业务高可用运行。
数据存储层主备中心采用ERM增强的远程磁盘镜像复制技术—Metro
Mirror(同步的镜像模式),在两套IBMDS8000存储设备间建立数据复制关系。
对主机来讲,活动状态的存储只有一台。
这台存储使用硬件复制技术进行磁盘之间的数据复制,保持两个存储设备上的数据一致,存储系统的数据复制对于主机来说是透明的,无需占用主机设备的系统资源。
保证了主机上的应用高性能运行。
在两套DS8000存储设备上建立磁盘镜像复制关系从而实现了存储高可用性,从而建立了完善的灾难备份中心,保证关键数据的可恢复性和业务应用的可持续性。
1.2中小银行核心系统基础架构现有问题
从现有架构来看,随着业务的不断发展,银行现有的核心系统在支撑系统开发、产品创新和服务创新上的支撑越来越艰难,开发效率和质量越来越难保证,业务处理和数据管理也存在问题。
核心及整体架构问题体现在以下这些方面:
核心系统产品层面
产品的规划没有清晰的界限,核心承载了过多的业务功能、账务功能和其他管理功能,成为架构瓶颈;
核心系统产品化和参数化程度低,二次开发难度大、周期无法估算;
前置系统未进行整合,所有的渠道类、中间业务类、支付类业务基本处于各自为政的状态,不利于渠道业务的快速拓展;
核心系统应用架构层面
应用系统过多,系统功能定位不明确,功能边界不清晰,缺乏整体架构规范和架构层次规划,集成化、平台化程度不高;
各系统之间以网状结构连接,缺少统一的服务标准,功能和代码复用性不高;
缺少全行统一的安全标准;
数据层面
部分数据散落在各个应用系统,数据模型不统一,数据质量参差不齐,数据准备性、完整性均无法得到保障,不利于未来实现数字化经营的目标,导致数据应用程度不高;
核心系统基础架构层面
系统横向扩展和纵向部署能力不足,系统标准化有待提高;
由于核心系统应用模式限制只能实现核心应用单中心运行,无法实现核心应用双中心分布式运行。
数据层面只能实现灾备中心底层数据实时复制,没有实现数据库层面双活运行。
当主生产中心出现故障需要同城切换时,需要进行大量数据一致性确认,应用启停等复杂操作。
同城灾备中心大部分时间处于备份状态,造成系统、网络等资源空置状态,不利于有效利用灾备中心资源。
2银行新一代核心架构方案设计
2.1.新一代核心架构设计目标
随着近年来互联网和大数据的发展,以及利率市场化的快速推动,银行面临的经营环境发生巨大的变化。
银行业务的发展,对IT系统提出了全新的要求,互联网、大数据、移动、社交、识别、智能等都成为银行IT系统规划和建设的关键词。
由于历史的原因,中国大多数银行的信息化建设缺乏统一规划,不具备合理、清晰、灵活的架构,从而出现系统越来越庞大、复杂,系统数量众多但标准各异,数据冗余而信息缺乏等问题,直接表现为IT对业务及管理的应变性差、响应速度慢、支撑力弱,从而严重地影响和制约了银行业务的高速发展。
目前,
越来越多的银行已经意识到,一个合理、灵活、松耦合的IT应用架构对于银行
IT应用整体效益至关重要,许多银行已将构建先进的IT架构作为提升其竞争力的有力手段之一。
银行新一代核心系统架构充分考虑本行整体IT架构规划的要求,架构目标
及原则包含:
1.整体的解决方案规划与设计
银行核心业务系统的建设,决不仅仅是单纯的核心银行系统产品实施,从IT应用的角度上看,不仅涉及前、中、后台包括柜面、渠道平台、应用整合、数据整合等一系列应用,还必须考虑国内特殊的如中间业务、银行卡等特色业务,以及支付、监管等系统需求,并结合当前的IT应用、整体的IT策略和未来发展,兼顾银行的统一性、规范性以及各分行独立性、特色性和差异性,因此,必须是一个整体、全面的解决方案设计。
2.基于SOA设计思想的开放架构体系
技术体系基于开放式系统,采用SOA的架构设计思想,以服务为导向,结合模块化结构,参数化设计,交易模板定制技术,层次清晰,封装性好,便于系统功能的扩充,维护灵活。
系统建设采用先进的设计理念、技术架构和实现技术,构建国内最先进、实用的金融计算机体系结构;
合理划分各个层次系统的功能;
能够实现三层或多层式架构,保证系统整体灵活性。
3.信息资源整合与信息标准
以建设新一代核心业务系统为契机和基础,规划、建立全行统一的数据模型和信息视图,通过企业信息集成与整合,为管理和决策系统提供源数据,提高银行信息获知能力及掌控精度。
4.高效的处理能力
系统具备高效的处理能力,满足各种技术指标要求:
✓具有高效的联机处理能力和并发处理能力,对于面向连接的业务应用,系统能承受不断堆积的应用请求;
✓具有较强的批量处理能力,利用周期性结转功能,确保在客户所规
定的时间内完成批处理;
✓系统能够与硬件同步升级,当硬件能力提升时,系统能够线性地提
升处理能力。
5.良好的扩展能力
具备良好的可扩展能力:
✓可支持计算机系统的横向和纵向伸缩,以提高系统处理性能,满足业务量和数据量的快速增长:
支持单个行集中和区域集中;
✓系统具备良好的应用层次结构,快速响应业务请求;
按应用需要进行封装,便于系统的组装。
6.高可靠性和可用性
系统具备较高的可靠性和可用性,支持24*7小时不间断运行:
关键设备和部件都采用冗余备份技术;
应用系统具备良好的数据备份和数据恢复功能;
核心应用系统实现基于X86—虚拟化平台的分布式部署模式,分别部署于同城双数据中心,实现应用双活模式;
7.灵活部署,易于维护
支持整体架构集中部署、特色业务分行部署等多种部署模式。
建设统一维护平台,统一管理分布式核心应用群所有系统。
2.2.新一代核心基础架构数据库模块
2.2.1数据库模块部署设计方案
随着银行现有同城双数据中心部署现状条件下,本次项目实施计划采用数据库集中式部署模式,即采用配置较高的硬件设备来集中化承载各系统的数据库。
根据本次上线系统及重要改动系统的功能定位,结合行内现有资源现状,参
考业内主流数据库部署模式做统一规划:
在同城主数据中心内,由2台小型机作
为物理运行平台,在同城备份数据中心有1台小型机做灾备机。
主数据通信与备份数据中心之间采用裸光纤网络联通,RPO≈0。
主数据中心DB在部署方式上采用OracleRAC方式,实现数据库集群,避免
数据库的单点故障。
具体实施如下图所示:
2.2.2数据库模块技术要点
根据银行现有数据量及未来五年业务量预估,参考1000万级账户同等规模的城商行硬件配置,及业内生产环境主流小型机型号,我们系统数据库采用IBM
PowerE850小型机3台物理机;
进行Dlpar分区已满足多数据库节点规划需求。
如下硬件配置:
硬件类型
数据库
CPU
(Core)
内存
IBMPowerE850*2
核心数据库
16
256G
渠道数据库
主中心在2台IBMP850主机上部署双节点RAC,灾备中心部署单节点ADG,分别使用各自中心的DS8000系列存储。
本方案是最简洁、最稳定的架构。
当主中心遇到故障无法提供数据库服务时,可以快速切换至备中心,在最大性能模式下,可以基本保证数据无损,同时又能保证生产端数据库的性能。
另外,这样的架构下备中心数据库可以提供数据库只读服务,实现同城准双活架构。
2.3.新一代核心基础架构应用模块
2.2.3应用模块部署设计
对于本次实施的核心系统、运营管理平台、综合柜面系统来说,各应用服务器物理架构采用开放式硬件平台,对硬件设备和操作系统不受限制,可以灵活选用不同的硬件设备和各类主流的操作系统。
同时支持虚拟化和非虚拟化两种方式部署
从高性能、高可伸缩性与低价格三方面考虑,应用系统采用VMwere虚拟化方式部署。
功能角度分层逻辑如下图所示:
虚拟化部署方式
虚拟化部署方式设备采用高配X86PC服务器,服务器之间通过VMware做虚拟化,操作系统建立在虚拟主机上,每个操作系统可以部署多个应用。
操作系统与硬件没有直接联系,通过虚拟机实现资源灵活分配,提高资源的合理利用,系统横向扩展方便。
系统维护工作量小,方便系统迁移及灾备。
2.2.4应用模块虚拟化技术特点
在现有资源基础上,整体部署方案将采用PCServer服务器搭建虚拟化资源池。
为保证虚拟化环境下的I/O性能,虚拟化将建立在存储之上,即整个虚拟环境的映像使用存储空间,而不是本地硬盘。
虚拟化是资源高度集中的硬件环境,为避免存储单点故障引起整体瘫痪,存储将采用双存储方案,在主备两个数据中心分别部署存储服务器。
应用服务器采用V7000作为存储服务器,使用svc硬件设备实现磁盘级备份与管理。
对应数据库服务器,存储设备使用DS8000存储服务器,存储间使用ESS的PPRC(PeertoPeerRemoteCopy)实现数据同步;
将虚拟化应用服务器,分为两个独立的物理资源池,将应用平均分布在两个物理资源池中,外部通过相关设备进行负载均衡关联,如果一组设备出现问题,可通过负载设备进行隔离,以降低物理设备故障对系统的影响。
2.4.新一代核心基础架构总体部署方案
本次核心项目计划应用系统及相关数据库分别在两个数据中心部署实现。
主数据中心部署两台Power小型机以RAC模式作为数据库服务器,灾备中心部署一台Power小型机作为数据库灾备环境。
在主备两个数据中心分别部署多台PC
Server通过硬件负载均衡设备对核心和综合柜面系统做6路高可用双活部署。
主数据中心机房发生意外情况时,修改灾备中心应用系统到数据库服务器的
链路配置文件,链接到灾备中心的单节点灾备数据库,使得外部业务访问独立运
行在灾备中心环境上,从而整个生产系统实现灾备快速切换。
新一代核心系统整体拓扑如下:
3新一代核心系统基础架构建设
3.1.新核心基础平台建设实施与经验分享
新核心基础平台建设分为五大阶段实施,方案制定、前期测试、方案实施阶段、故障及性能测试、上线保障;
方案制定阶段行方投入技术经理和专家,对系统环境进行多次摸底,与集成
商责任人、Oracle原厂专家多次讨论后,编写了《新核心环境VMware6.0U3集群设计方案》、《同城容灾方案》、《数据库设计方案》等等。
前期测试阶段通过大量细致的测试,总结出了AIX最佳系统版本号、数据库最佳版本号以及补丁号、上线前需要调整的参数等等.同时形成了标准化的实施工艺。
方案实施阶段共计实施核心相关业务VMware集群平台、核心数据库四套
(RAC),同城灾备(ADG单机)四套,并全部生成实施手册《新核心环境
VMware6.0U3集群实施报告》等。
实施阶段积累了一些数据库相关的宝贵技术经验例如:
稳定性问题
初次安装的操作系统平台是AIX7.2,根据oracle官方文档(文档ID22832149.8)的描述,数据库实例可能会自己宕掉这是一个bug,这个bug在AIX7.1TL4及以上版本都可能产生,我们及时调整了版本,最终确认稳定版本为7100-03-09-1717;
数据同步方式问题
在带压模拟同城数据同步中断时,默认的同步方式(最大可用)会导致业务Hang30秒钟,经过软件开发厂商和原厂技术专家讨论后,认为这样会对业务造成影响,后修改为最大性能模式后,避免了该问题。
性能问题
数据库内部作业统计信息执行窗口的修改,考虑到核心系统的业务高峰期和夜间批量的特性,默认时间窗口可能会影响到批量的完成时间,我们修改自动收集统计信息为每天凌晨一点,持续5个小时。
故障及性能测试阶段在业务系统正式上线前,我们按照前期制定的测试方案,
在带压的情况下测试了各种可能的场景,包括生产库破坏性测试、RAC功能测试、同城灾备切换等等,生成了测试报告。
上线保障阶段投入了行方、集成商及原厂专家等大量人力全力保障银行新一代业务上线,上线期间部署了巡检脚本和OSWatch对系统和数据库的主要指标进行监控,保障期间处理若干性能相关问题并生成性能分析报告。
3.2.新核心基础环境平台测试验收
本次性能测试的目的是综合测试所涉及的主要系统与基础环境平台集成到一起后的整体性能和负载承受能力,为系统上线运行提供依据。
严格来说,本次测试包含了性能测试、稳定性测试、故障测试三个方面。
测
试目标包含以下几个方面:
Ø
测试系统性能:
测试在一定负载下系统的响应速度、交易成功率的性能指标,保证被测试系统在生产环境的业务和用户量下,系统性能能够满足业务交易人员操作的需求;
测试系统负载承受能力:
逐步加大负载,通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别;
发现性能瓶颈,为后期性能调优提供参考依据;
验证稳定性与可靠性:
持续承载在一定生产负荷,评估系统稳定性和可靠性是否满足要求;
验证集群节点故障、单中心集群故障、设备故障等情况下系统的可用性和
故障转换能力。
测试计划安排步骤如下:
序号
测试计划步骤
工作内容
1
性能测试方案
性能测试案例与评审
2
基础环境安装/调整
基础环境安装、基础软件安装配置、参数调整
3
测试脚本、监控准备
脚本整理/编写、脚本测试、监控准备
4
联机案例测试
联机交易场景测试、监控收集(代码调优)
5
批量案例测试
批量案例测试、监控、调优
6
故障测试
故障:
辅助节点故障、主节点故障等
7
稳定性测试
持续压力稳定性测试、监控收集
8
案例结果收集
案例执行结果整理
9
报告编写
测试报告整理、编写
根据《新核心群数据库同城RAC&
ADG故障测试方案》、《新核心环境
VMware6.0U3集群故障测试方案》《新核心系统集成性能测试方案》对基础平台进行了测试验收工作;
按照计划测试验收工作持续了进一个月时间,生成进1000页测试报告。
为今后的生产运维工作提供了宝贵的技术积累和运维经验。
3.3.新核心基础平台高可用架构故障应急方案
新一代核心系统采用分布式部署方式分为6节点分别部署在生产中心和灾备中心。
核心应用支持多节点多活方式运行,但上线初期考虑性能和稳定性因素在负载均衡设备上将应用访问负载设置为首选生产中心应用节点。
当首选3节点全部故障时自动分配到灾备中心3节点。
核心数据库在生产机房采用2节点IBMPower850小型机的OracleRAC环境,当其中一台小型机出现问题时,不会影响数据库的访问,可以正常连续的提供数据库服务;
在OracleRAC的基础上,在灾备中心有1台核心数据库的ADG环境,可以实时同步核心数据库的数据,如果灾难发生时,可以把备库切换成主库,正常对外提供服务。
根据以上的设计方案,核心应用生产环境支持主备机房之间的切换,当生产中心发生灾难时,在规定的时间窗口内,由灾备中心全面接管生产中心的各项功能,同时尽量缩短灾备切换时间,降低对业务的影响。
保证灾备中心与生产中心的数据在规定的时间窗口内保持同步,灾备中心硬件和软件环境就绪,随时能够接管生产中心的运行和管理功能。
正常情况下交易信息保存在生产中心,在生产中心产生的数据和业务更新被同步到灾备中心。
当生产中心发生灾难时,灾备中心启用并接管客户端访问,保证业务的连续性。
生产中心恢复后,将灾备中心的数据备份在生产上恢复,并将数据回传,将网络回切,完成生产中心的恢复。
4结语
新一代核心系统基础平台建设是一项时间跨度大、涉及技术条线广、集成度复杂的系统工程,需要协调各个厂商和集成商有效组织实施。
项目实施过程中需要厂商高度配合包括人员、时间,有效协调各个资源,才能保证建设项目顺利按期实现各个阶段目标,最终实现系统按期顺利上线。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 商行 新一代 核心 平台 可用 设计方案