唐国兵
作者唐国兵2019-03-18 10:42
系统架构师, LinuxONE

某银行29套数据库业务系统规模化整合最佳实践

字数 4786阅读 6351评论 11赞 25

摘要

由于长期大规模分散建设带来的竖井式IT蔓延和分布式建设的持续发展,银行业的整合需求开始不断涌现。继江西银行2016年底整合了柜面和定价的应用和数据库系统,将DB2、WAS、JAVA应用、GPFS和Oracle等软件快速从其它平台迁移到LinuxONE平台,实现了无缝快速移植。通过LinuxONE全共享的架构优势,结合持续的扩展和自动化资源优化能力,我们不断拓展大规模整合在银行业的深入应用。本文旨在通过简单明了的方式解释LinuxONE是如何帮助某城商行实现大规模整合,以及对比传统分散建设都有哪些方面的业务价值。

该城商行在目前大规模的小型机和X86的部署下,遇到了很多问题亟待解决。而这些问题产生的原因最主要是该城商行缺乏一个可持续发展的平台,往往总是规划赶不上变化。因为技术的原因,采购周期的原因,到位资金的问题,规划的原因,监管变化的原因,外部市场环境变化等多种因素,使得该城商行在IT建设的不同阶段采购了大量品牌不同,产品不同,型号不同的物理设备,部署了上百个业务系统,甚至有些业务系统还是单点和冷备的状态,IT基础架构复杂度非常高,信息孤岛现象严重,改造难度巨大且风险难以控制,极大的阻碍了未来的业务发展。

另外互联网的快速发展使得该城商行业务受到极大的挑战,必须要做出改变,而反映到IT,需要能够快速满足业务发展的需要,比如银行怎么能够快速推出好的产品,怎么快速启用新渠道,这就需要基础架构更灵活。同时如何保障现有和新的平台的持续有效利用,资源共享,特别是在数据库层面,越来越分散的建设思路已经造成了很多问题,竖井式的建设造成了严重的资源浪费,而在某一时段急需资源的系统又得不到这种支撑,唯一能做的就是不断增加硬件。那么其它问题也来了,高峰过后闲置的资源又如何被利用,如果高峰和平峰差距较大,这种浪费将更加巨大,从一个系统扩散到几十个系统,数据中心的蔓延将不可避免。即便X86足够便宜,经济性和高效运维而言也不具有持续性,比如大规模的机器部署,软件成本的急剧攀升如何有效控制,那么多机器,如何保障一致性的运维,都是企业面临的巨大挑战

该城商行所面临的挑战也是银行业遇到的普遍问题,我们将其归纳为四个方面:
第一方面是软件版本的不一致问题。
第二方面是系统缺乏一致的高可用保障。
第三方面是竖井式建设带来的信息孤岛和资源无法有效共享的问题
第四方面是急剧攀升的软件成本问题。

本文将重点围绕第三个方面进行展开分析,该城商行现有大量的小型机和x86服务器,分别部署全行所有的业务系统。如果在新建数据中心的时候,继续沿用原来的建设模式,势必使得当前的IT基础架构部署规模更大,信息孤岛和资源共享问题将更加突出。通过对该城商行服务器的调查和该城商行反馈,低利用率的服务器大量存在,且只有少量业务长期处于资源不足的情况,而其它大部分服务器在大部分时间处于低利用率状态。如何有效的实现资源共享,减少资源浪费是该城商行亟待解决的问题。如果新数据中心建设继续采用原来的部署模式,这种资源浪费的现象将更大规模的蔓延到两个数据中心。通过数据库规模化整合有助于规避这样的风险,确保由于业务变化对物理资源的快速调整,同时保障不同业务负载的优先级资源保障,确保闲置资源能够最大程度释放。比如,由于业务快速发展或者产品促销推广(双十一,网红产品等),交易类业务负载会出现爆发式增长,交易量可能是之前的几倍甚至数十倍以上,原规划业务如果部署在物理分散的两台处理能力较弱的小型机或者x86上,而且这些服务器同时还部署了其它业务,那这样的交易量使得该城商行只能被动的尽可能增加新的设备进行补充。而一旦高峰结束,服务器使用率又回到较低的水平,资源长期闲置,不能得到充分利用。业务高峰和平均使用率的差距越大,使得这种资源闲置越明显,对于银行而言,很难预测和避免,只有通过自动化削峰填谷才能实现最大化资源集约利用,减少浪费,避免业务快速发展带来的IT蔓延。

经过和该城商行多次沟通,梳理不同系统的业务特点,通过数据库规模化整合,实现资源共享和优先级保障,将目标关注在29套数据库业务,共两个安全业务网络,其中核心业务安全域共3套,开放业务安全域共26套。

该解决方案只会替代下图数据库部分,不会改变现有整体网络架构,不影响现有网络防护,安全等架构和改造,外部交互还是通过应用系统来连接和管理。而在LinuxONE端也借助商用服务器中安全等级最高的隔离技术,实现不同业务域的安全隔离需求,保障数据库端的网络,I/O及内存等资源的隔离。

9tijdrqzdsv

9tijdrqzdsv

该解决方案为了实现最大化的资源共享,保证了所有分区的CPU共享(下图红色方框),同时根据当前和未来的使用率评估和预测,进行了权重设置(下图绿色方框),保障各业务负载的优先级,并对内存设置了预留,可以不停机秒级激活。通过规模化整合,实现资源共享可以保障所有分区的业务都有可能在别的分区资源闲置的时候使用到最高10个CPU,也就是所谓的削峰填谷。也能保障当各业务同时处于高峰时候确保每个分区的业务能够得到预先设置的权重资源,也就是所谓的优先级保障,而且这些实现都是自动化,不需要人工干预。资源自动化共享和优先级保障能够最大程度实现资源集约化使用,减少浪费同时能够最大程度提供业务发展的灵活性,而不是被动的不断的增加物理设备。

1zelfd90mr5

1zelfd90mr5

从整个上线情况来看,呈现的效果,是非常好的。联机交易类业务,LinuxONE高峰使用率不超过25%,而原来部署在不同的硬件平台,高峰使用率有高有低,小型机为30%左右,X86为40%左右,虽然这些机器平均使用率并不高,甚至有些机器绝大多数时间处在5%-10%之间,但正如之前提到的,高峰使用率和平均使用率差距太大,造成了资源浪费也就更明显,并且也很难做到资源共享,使得某些业务在需要更多资源时得不到有效支持,比如数据分析类业务,虽然不是58或78的实时业务,但运行期间对资源要求较高。通过LinuxONE整合解决方案,平均使用率和高峰使用率都非常接近,这是资源集约化和错峰利用下的结果,最大程度的减少了资源浪费,提升资源使用效率。而夜间批处理的窗口期减少为原来的1/2到1/3之间,相当于提升了2到3倍的效率,夜间批处理时间窗口的减少,对于该城商行而言,有更多时间应对突发事件,尽可能的避免白天的停业风险。

lnduu8wmdab

lnduu8wmdab

如果按照原来的部署模式,需要将近20台或者更多的设备,而该方案只需要三台设备,极大简化了灾备建设的复杂度。我们提供了同城生产和灾备双中心一个2+1的机器配置,每台机器配置完全相同,10个IFL,960GB,以及对应的网卡和HBA卡。整合的29套数据库原来是部署在18台服务器上,其中小型机为12台,X86为6台,共计536个CPU核,方案整合比例是1:17.8。

在具体的整合方案中,生产中心两台机器根据该城商行需求,同时增加了准生产区,并做了内存和网络,I/O的隔离,对于CPU来说,因为共享的,并设置了权重和优先级,未来准生产可以有效利用错峰的时间窗口期,即便同时运行,也不会相互干扰。两台机器的部署完全相同,并做了RAC集群,三个业务网络实现了分区隔离,核心生产业务域和开放生产业务域都预留了一个备用分区,该备用分区是为以后新上线系统预留的分区,而准生产分区是保障每一个系统上线前的验证。

hnt7y0qe1u4

hnt7y0qe1u4

可以看到这是一个极简的整合方案,借助逻辑分区+ORACLE 12C的容器集中部署的方式,相较于虚拟化软件,更轻量级,性能也会更好,管理和易用性也更简单,降低了部署安装和性能的风险,架构更为简单。另外该城商行的学习门槛直线下降,原来多种虚拟化方式不能共融的情况得到彻底解决,通过分区加数据库容器的部署,该城商行能够快速上手,实施规模也变得更小。而如果使用虚拟化,每台机器该城商行需要部署8个分区,8套虚拟化, 超过30个Linux, 而这个方案只需要部署8个分区,8套Linux,后期项目风险和运维都会相对简单。

从同城双中心的视角来看,原来18台服务器的部署变成现在的3台,而且原来是以小型机为主,如果换成X86为主,规模将更大,通过LinuxONE整合平台,我们极大的简化了该城商行的基础架构,使得运维管理和灾备建设变得更加简单。存储方面通过双活部署,作为第一灾备切换选择,应用端通过ORACLE ADG实现数据库复制,作为第二灾备切换选项,能够最大程度提供该城商行在RTO和RPO上的灵活性。

matdqz8su5s

matdqz8su5s

通过LinuxONE大规模整合解决方案我们帮助该城商行解决了四个方面历史遗留问题:第一,统一了29个业务系统的操作系统和数据库的版本。第二,实现了29个业务系统的一致的高可用等级,LinuxONE实现了一致性应用(RAC+ADG)和存储(同城双活)的高可用和灾备等级. 第三点是,和原来每台服务器较低的平均使用率和较高的高峰使用率相比,资源浪费得到极大改善,原来在高峰时段,某些业务系统的硬件资源不足的情况的场景,包括错峰的业务却不能通过分散的物理设备实现共享的场景,通过这套方案得到了有效缓解,而且这些资源平衡还是自动化的。第四点,软件成本风险得到有效规避,由于即将上市,该城商行非常重视未来的各种潜在的软件成本风险规避。以Oracle为例,LinuxONE解决方案相较于之前的部署模式至少可以降低一个数量级的License费用。

总结该城商行LinuxONE大规模整合解决方案的价值,主要是两个方面,一个是集约运营,提升回报。一个是简化运维,降低风险。

9ws7i8vqpdm

9ws7i8vqpdm

就集约运营和提升回报这个价值点而言,有些之前已经提到就不再赘述,关于构建绿色数据中心这一点,因为大规模减少了物理硬件的部署,包括外围设备的大幅减少,除了能耗的减少以外,紧张的机房空间得到了有效解决。虽然该城商行是新建机房,看起来也足够大,但是已经规划满,未来可扩展空间已经非常有限,机房紧张的问题也是大部分该城商行遇到的制约发展的普遍问题,这也反映出大规模分布式建设过程中出现的一些问题。我们说历史是一面镜子,古语有言:“天下之事,分合交替,分久必合,合久必分。”IT发展史不但曾经经历过类似的发展史,未来也势必经历这样的历史发展趋势。LinuxONE区别于其它平台的关键之处在于,效率的提升和价值的创造是依赖于架构的创新,而不是传统的通过扩大规模的方式来实现。

第二个价值点简化运维和降低风险而言,之前也都有不同程度的介绍,这套方案的易用性非常明显,因为没有虚拟化软件,安装部署极为简单。关于弹性扩展这方面,当前使用产品为入门级产品,该城商行当前产品平均使用率为20%,高峰使用率为25%,按照LinuxONE体系架构设计,建议高峰使用率不超过80%,对于未来新增系统而言,不改变当前配置下也能够支撑未来相当一段时间的业务扩展。同时大规模整合的意义在于集约化资源利用,即便在负载大量增长后,也能够通过资源优化平衡实现最大化资源节约。同时10个IFL的配置意味着该城商行还能通过该机器扩展到30个IFL,再不考虑企业级产品的情况,30个的IFL也足以支撑未来3-5年的业务发展。另外一个方面而言,透过这个简化运维,降低风险的价值点其实我们也想表达一点,和目前业界大规模分散建设的做法,LinuxONE做了一些不一样的事情。这并不是简单的集中式和分布式的比较,从另一个层面来说,目前一味的增加物理设备的方式,通过分布式建设并不是适用于所有场景,所有业务,通过不断做加法,为了分而分的做法,直接照搬没有可持续性,否则整个IT的复杂度将越来越不可控制。实际上LinuxONE大规模整合是在帮助该城商行做减法,最终实现简化运维,降低系统风险。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

25

添加新评论11 条评论

#lhh20120105项目经理, 某IT公司
2019-08-02 10:51
太赞了,多谢分享!
#powx技术经理, ZWT
2019-05-13 18:37
大型机好贵!!!
#Leaveschz项目经理, 重庆三峡银行
2019-03-23 19:00
我对数据库层面架构不是太了解,但是对于数据库整合有几点自己的看法:1、整合数据库不仅是简单意义的数据库的整合,还需要考虑到全行级的数据治理;2、数据库的整合也适用于数据整合管理,是否需要考虑通用化数据整合管理;3、是否需要考虑业务相关性数据或是相似性数据的标准统一性,方便后续的数据备份及管理;4、不管架构如何好都需要花钱,对于银行来说如何评估支出和利益尤为重要。

唐国兵@Leaveschz 您的思考非常有前瞻性,结合方案过程中,需要银行IT和业务人员更多的从数据治理的顶层设计上进行思考,就我们参与度和目前的情况而言,只是结合了客户对于业务等级或者业务网络的分类,该城商行客户更多的是考虑业务类型的相互干扰,所以将不同类的业务分开,包括交易类,管理类等等,有的客户主要是考虑业务等级,比如1类,2类业务,流量,比如流量在白天,晚上,对象,比如面向互联网,面向最终客户等等进行划分,还没有上升到数据治理和数据标准性这个层面。

2019-03-25 10:43
#firelord823系统运维工程师, 贵阳银行
2019-03-22 16:49
本方案其实对于中小规模的城商行很有吸引力,极大程度的能够降低部署的物理复杂度,整合资源。在城商行运维人手有限的情况下,降低运维的人力成本。 个人认为不足的地方是鸡蛋都放到一个篮子里了,极端情况下可能对抢修造成很大故障。

唐国兵@firelord823 谢谢您的评论,关于您的问题,首先硬件本身可靠性是远高于其他平台,另外单机情况下,LinuxONE本身做了分区隔离,隔离度能够达到接近于物理隔离的级别,所以分区之间的相互干扰是很小的。另外极端情况下,避免鸡蛋放到一个篮子,主要是考虑硬件的故障,所以双机高可用做了补充,单机的配置是可以撑起来所有负载的,更极端的情况是站点故障,所以灾备也做了两层的接管,相对而言,这和之前的方案区别在于架构上更简单了,接管操作也会更简单。 从建设思路上来说,LinuxONE有更高的可靠性设计,也比分布式模式更适合银行得核心业务 LinuxONE方案对可靠性的诠释有着不同的平衡思想,分布式或者其他平台的思想是把鸡蛋放到多个篮子,篮子之间是软连接,LinuxONE解决方案的思想是有限的篮子,但篮子间的连接相对强度较高.很重要的问题是要放几个鸡蛋。LinuxONE解决方案在不断提高篮子的强度的同时通过结合存储和数据库等技术来规避鸡蛋放到同一个篮子的风险。

2019-03-25 09:54
#邓毓系统工程师, 江西农信
2019-03-21 16:43
该方案确实不错,整合能力强,性能突出,硬件平台可靠性已经达到极致,但有两个方面我个人觉得可能会有些问题,一个是操作系统或者中间件的稳定性,硬件可靠性高,但操作系统和中间件不稳定,依然会宕机,这个靠硬件本身没办法解决。所以要靠高可用架构解决,分布式或者传统主备HA等,如果是分布式的话,适合应用节点分布式部署,但LinuxOne本身不自带存储,需要接入SAN和存储,算上能耗、空间、人力等的优势,TCO其实和X86也算持平,这个估计不能算优势,优势还是在于性能和纵向弹性方面;如果是主备HA部署的话,LinuxOne只能靠数据库本身的复制技术、TSA或keepalive等实现高可用,本身相比PowerHA或者AS400的高可用机制还是有所欠缺,尤其是防脑裂方面。 综合而言,LinuxOne的确是一款很优秀的硬件产品,加上Linux操作系统越来越稳定,生态圈也非常广泛,造就了如此火热的产品。

bbaimm88@唐国兵 的确LINUXONE 的CPU超强能力,在数据库的授权上解决了很多法律纠纷问题!隐形节约了很多版权费。

2019-08-17 19:02

唐国兵@邓毓 谢谢您的问题, 第一个问题,关于和x86的TCO比较,其实您评估的比较准确,就该方案而言,替代的x86不多,所以TCO是要明显低一些的。另外其实我们在和x86做TCO比较的时候,往往忽略了软件成本,随着x86规模的变化,整合规模越大,在TCO核算的时候是越有优势,甚至有些客户场景下,软件成本远高于硬件采购成本,这个需要根据实际的客户情况而定,但是LinuxONE可以有效规避软件成本在未来的快速攀升风险。 第二个问题,同X86 Linux一样,在应用解决方案上其实是基本上一样,都是Linux世界。不过对于类似于Power HA的解决方案也是有的,即TSAMP的高可用机制,区别在于,TSAMP是跨平台的,不限于AIX,本案例没有用到。相信随着Linux的发展,Linux自身的HA也能够越来越好。

2019-03-25 12:58
#guanyang1326系统工程师, 辽宁农信
2019-03-20 10:05
方案总体上写得很好。言简意赅的写明了在银行核心系统整合过程中基本架构的设计以及设备的基本配置和规划。在资源整合的过程中充分利用最少的物理硬件实现系统的最高可用和最大利用率,统一了操作系统、软件、和硬件的版本,避免不同版本兼容性不一致带来的负面影响。同时在使用LinuxONE过程中也可极大的节省数据库或者相关软件的License费用。 在高度整合过程中还是存在一些问题的,就是当物理cpu和内存故障时还是需要系统切换或者停机操作的。虽然LinuxONE继承了大机的特性,但是在线更换cpu和内存还是取决于当前客户的硬盘配置是否购买了充足的cpu和内存。

唐国兵@guanyang1326 您提到的问题非常专业,我想从两个方面进行解释吧,第一个方面:从可靠性来说,物理CPU是有固定冗余的,还有未激活部分的CPU也是作为冗余使用的,一旦CPU故障可自动切换。另外内存也做1:1.25左右比例的冗余阵列(RAIM),类似于存储RAID,允许部分内存条故障而不影响系统运行,极大的避免了内存故障的风险,该技术使得产品本身近五年未有内存故障导致硬件停机的情况发生。另外从ITIC每年对于硬件可靠性的统计报告可以看出,单纯硬件本身,LinuxONE平台是远远高于其它平台的。 第二个方面:解决方案本身,做了双机集群部署,单机能够完全接管业务负载,所以单机出现了极端情况,需要在线更换,完全可以选择一个合理的时间窗口进行,而业务不需要停止,也能够满足两台机器滚动升级的需求。

2019-03-20 21:00
#wuwenpin软件开发工程师, 南京
2019-03-19 20:26
太赞了,多谢分享

唐国兵@wuwenpin 谢谢支持

2019-03-20 21:18
#topbill系统工程师, RCCU
2019-03-19 18:25
该方案确实良好的解决了主机系统资源整合共享利用和数据库版本统一的问题。但是在面对互联网业务场景,在该方案基础上,考虑应用架构层面的优化或重构是否更加重要?另外信息孤岛应该是数据架构层面的需要解决的顶层设计问题,通过该方案恐怕无法有效解决。

唐国兵@topbill 您说的很对,信息孤岛需要顶层设计,全方位的解决,我这里说的仅仅是信息孤岛的一个方面,主要指的硬件这一块,物理资源的有效共享。另外您提到的应用架构层面的优化或重构,确实这也是IT驱动业务转型的重点,不过在当今IT环境下,应用层面架构基本都是虚拟的分布式部署提升扩展性和性能,整体而言,目前应用越来越分散了,而数据库再继续分散建设,很容易造成竖井式的建设,我觉得需要规避新一轮孤岛式建设。我认为基于大型数据库的逻辑集中或者多个数据库的物理集中部署,可以实现数据的有效管理及价值的最大化。

2019-03-20 20:59
#ForeverMoon系统架构师, 徽商银行股份有限公司
2019-03-19 17:17
数据库整合也是类似用了虚拟化的理念,将原本分散的资源进行合并,节约机房空间硬件成本、便于管理。但是用linuxone整合,集成度太高,两台物理机器运行了几十个数据库,出现硬件故障或者需要维修时,涉及系统多,费时费力。银行系统数据库包括虚拟化等,整合度不宜太高,业内会有一些最佳实践,减少故障影响面。

唐国兵@ForeverMoon 理解您的担心,银行基本没有大规模整合的做法和经验,上一套系统或者几套系统就买几台机器,集群或者双机部署,如果其它平台有这样的能力,我想整合的故事早就发生了,具体linuxone解决方案的能力和保障我也不再赘述。我们在全球有非常多的整合案例,对于我们而言,该客户规模不大,业务量也不大,在我们的整合客户中,几十个数据库的数量只算一般规模。而对于我们而言,我们已经习惯了帮助客户做整合,另外方案并不是一味追求整合,也在平衡高可用和灾备。不过我非常同意您的一个观点,整合度的问题,对于我们和其他平台比较而言,该客户的整合度其实并不高,我想这也是刚才我提到的。合久必分,分久必合,如果这是一个循环的话,那么当今IT发展所处的阶段,我想现在处于分的阶段,而且很多客户的环境极度分散。当然整合度越高,风险也是需要考虑的,不过现在更应该考虑整合,这是我的一个想法。

2019-03-20 21:25
#michael1983技术经理, 某证券
2019-03-18 17:47
太赞了,多谢分享

唐国兵@michael1983 谢谢支持!

2019-03-20 21:26
#seagl系统运维工程师, XXX商业银行
2019-03-18 17:23
方案不错,极大的节约了设备,充分利用了资源。 但是需要考虑版本兼容性,由于历史原因,生产上遗留的版本很多,整合为一套版本是否能够保持业务系统的稳定。

唐国兵@seagl 您说的很对,有的客户会非常担心这个问题,有的客户则相反,这个要根据客户的经验和能力进行取舍,该客户预留了时间进行验证,我想客户需要有一个考虑和完整的解决办法,甚至需要一些取舍,整合不是什么都整合,而是根据客户对于业务等级,对于流量,对于运行时间等等的一个整体考虑。

2019-03-20 21:17
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。
银行业务系统规模化整合交流需求有奖调查

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30