第3章 从小型机迁移到x86 服务器 横看成岭侧成峰,远近高低各不同; 不识庐山真面目,只缘身在此山中。 回顾2010 年,很多商业银行新系统上线初期通常先按系统重要程度进行评级,针对业务 评级重要的交易系统首选IBM Power 小型机或者惠普小型机,只有银行内部管理信息类的系 统才会选择x86 服务器。当时大家被“只缘身在此山中”的惯性思维所桎梏,总觉得一个系 统如果不部署在小型机上,将给后续运维、系统可用性、可靠性等带来不可预知的挑战,甚 至出现了Java 应用程序也要部署到一台IBM Power 小型机上。 但是,在上线后却发现,即使在业务洪峰期,小型机的计算资源也很难得到很好的利用。 即便是这样,大家也觉得这是同业的标准,这才是金融级系统应有的架构! 从2010 年以来,随着很多商业银行对x86 服务器的应用与小型机的性能对比测试工作的 进行,发现x86 服务器的诸多优势也随之呈现出来。在随后的基础设施采购项目中,特别是 在虚拟化建设方面,开始逐渐增加x86 服务器而有意减少小型机的新购数量。另外,从单机 角度来讲,虽然x86 服务器的RAS 指标不及小型机,但其他指标基本可以满足很多系统对性 能的需求,总之可以花费相对少的成本就能满足业务需求,何乐而不为呢? 从2013 年开始,互联网行业对x86 服务器的使用如火如荼。2013 年5 月,阿里巴巴宣 布最后一台IBM 小型机在支付宝下线了!这对阿里巴巴来说是非常重要的一个里程碑。暂且 不谈“去IOE”,单从小型机下移至x86 服务器这一动作来看,阿里巴巴从容转身的背后一定 有着很多的技术挑战,这对于一个已部署传统IT 技术和架构的互联网公司实属不易。 什么是RAS 指标? RAS 是计算机系统可靠性(Reliability)、可用性(Availability)和可服务性(Serviceability) 三项技术的总称。是设计、研究、评价计算机系统,特别是高可靠性的计算机系统必不可 少的指标。 3.1 迁移项目概述 如果这一切要发生在传统的商业银行,那应该如何应对呢?商业银行的业务系统复杂度 很高,并且影响面更广,这套下移动作的难度系数可不低,每个系统都好像带电的老虎摸不 52 商业银行数据库库管理实践 得。事实证明明,如果不努力力改变历史,那那就有可能将将被历史改变。但这一天终究究还是来了, 22019 年年初,笔者所在的商商业银行决定将目前所有在在役的小型机下下移至x86 服务务器,当这一一 举举措宣布之时时,大家的内心心可谓是百味杂杂陈。 3.1.1 商业业汇票系统下移背景与与目标 每个商业业银行都有自己己的应用系统评评级体系,笔笔者所在的商业业银行根据系统统涉及的交易易 金额、对外影影响及在线用户户量等指标,将将系统划分为四个等级,由由高至低分别为为A+、A、BB 和和C 类。目前前部署在IBM 小型机的系统统基本都是A++和A 类,这些些系统的共性是是停机时间窗窗 口短,且重要要程度高;也有有少部分B 类系系统,该类系统的特点是““体量庞大”,停停机时间窗口口 也很有限。并并且这些小型机机都存在超期服服役风险,其其故障率随着服服役时间增长而而不断增加。 根根据相关统计计,超过5 年的的小型机,故障率大概增长长42%左右;另另外,如果系统下移至x866 服服务器后,硬硬件采购和维护护费都将有一定定下降。 结合系统统架构的发展趋趋势,分布式架架构已成为大大势所趋,这种种架构已在互联联网行业得到到 广广泛应用,各各家商业银行也也在研究适合自身业务的分分布式系统。特特别是近年来,,在分布式架架 构中,各个节节点所使用的xx86 服务器,开始使用本地地磁盘(例如性性能更好的固态态盘)来存放放 数据。与使用集中式存储的的系统相比,这这类系统的横向向扩展更便捷。因此,在小型型机下移中, 推推荐使用基于于本地磁盘的分分布式架构。 考虑到运运行在这些小型型机上的软件版版本已经退出厂商产品技术术支持周期(Ennd Of Service)) , 存存在大量隐患患,时刻威胁着着生产环境的安安全稳定运行行,为提升相关关系统软件运行行的可靠性, 利用小型机下下移x86 服务器器的机会,将存在重大风险险隐患的操作系系统、数据库及及中间件进行行 大版本升级。升级后,从操操作系统到数据据库,运维复复杂度和成本也也会随之大幅降降低,同时也也 能实现资源整整合,为基础软软件的标准化、、自动化做好好准备,为智能能化运维奠定良良好基础。 商业汇票票系统是一套系系统评级为A++的交易系统,该系统主要面面向商业银行多多个业务部门门 , 用用于实现商业业银行各项商业业汇票业务放款款操作与业务务管理的信息处处理平台。 以上提及及的背景问题,在商业汇票系系统上体现得得淋漓尽致。系系统内所有应用用程序和数据据 库都部署在IBBM Power 小型型机上,且服役时间已超限限;应用程序与与数据库紧耦合合在一起,存存 在在资源争用、架构不合理等等问题隐患;所所有的中间件件及数据库产品品均已退出厂商商产品技术支支 持周期。 因商业汇汇票系统在整个个项目背景中具具有较强代表表性,本章将以以该系统为例,,深入介绍整整 个个系统下移过过程。 3.1.2 迁移移计划 经过对现现有系统梳理,涉及小型机下下移的系统均均为笔者所在商商业银行的重点点交易系统, 系统可用性要要求较高,因此此不能出现因小小型机下移变变更而引起任何何生产事件。任任何一套系统统 都不会给试错错的机会,这需需要做足功课,谋定而后动动!谋就是要做做好计划,围绕绕着目标,在在 具体实施之前前,要先计划清清楚。 既然首要要目标要向x866 服务器迁移,先要证明x86 服务器有能能力代替小型机机承载这些应应 用用和数据库。有了理论的支支撑,再结合实实际测试数据据,就可以总结结出一套将小型型机资源转换换 53 第3章章 从小型机迁移移到x86 服务器器 为x86 服务器器资源配置的方方法。 项目背景景和目标确定后后,随即成立了了专项工作小组,接下来开开始制订“作战战计划”。制订订 详详细的计划之之前,首先需要要分解任务目标标。小型机下下移x86 服务器器有以下两个主主体目标。 (1)将所所有部署在小型型机的系统平滑滑迁移至x86 服务器,这是是第一个目标。 (2)将所所有涉及下移交交易系统中的基基础软件升级级至主推版本,这是第二个目目标。 针对第一一个目标,计划划根据待下移系系统的现状,分分别对应用程序序和数据库进行行深入分析, 针针对不同的场场景、不同的系系统级别、不同的业务连续续性要求、不同同的高可用级别别,制订出合合 理的数据“平平滑”迁移方案案。 针对第二二个目标,计划划在小型机下移移的同时完成成相关软件的大大版本升级。这这需要梳理当当 前前待下移的各各系统软件版本本,随后根据版版本差异、升级级策略来制订软软件升级方案和和测试方案。 再根据测试方方案进行合理的的系统测试,最最终才能结合合数据迁移方案案进行生产环境境的实施。 在现代化化战争中,给士士兵配备各种作作战辅助装备备,一方面提高高了生存率,也也同时提升了了 单兵作战能力力。所以,考虑虑对应用程序部部署架构和数数据库部署架构构进行优化调整整,将系统性性 能和高可用能能力发挥到极致致。对于每一套套待下移的系系统都可以通过过现有架构分析析,形成x866 服服务器的优化化方案。 3.1.3 数据据迁移原理 小型机下下移项目中,并并不是将数据从从小型机平台复复制至x86 服服务器就达到系系统下移目标, 而是需要在一一套安全详尽的的迁移理论支持持下进行。在在小型机下移xx86 服务器的项项目中,需要要 考考虑应用和数数据库整体迁移移。 商业银行行的应用程序具具有应用及数据据架构复杂度度高、系统敏感感度高、业务连连续性要求高高 等特性。应用程序本身是无无状态的,这对对迁移来说简单单了不少。也就是说,将应应用迁移至x866 环环境后,如果果考虑回退,只只需要将前端应应用请求连接接转向原环境即即可。只涉及更更换应用运行行 的平台和软件件版本,不会变变更程序的处理理逻辑,所以以单纯应用程序序的迁移只考虑虑做适当的黑黑 盒测试即可满满足上线条件。 应用程序序的迁移并不复复杂,但数据库库就不同了,在传统的数据据库数据迁移方方案中,有多多 种种方法可以满满足迁移的目的的,一般会采用用数据导出导导入方式和数据据库日志复制方方式。 (1)基于于数据导出导入入的方式实现数数据迁移。 对于数据据传输方法是指指在应用停止写写入的情况下下,将数据从源源端数据库全量量导出传输至至 目标环境。随随后再进行目标标端相关数据对对象的初始化化,验证应用程程序访问数据库库后,即可对对 外提供服务。但方法也存在在诸多不足,可可能需要花费费较长的停机时时间窗口,这和和数据量有一一 定关系。对于于数据的回退比比较复杂,需要要提前梳理应应用层级的表对对象,并手工将将目标端的增增 量量数据同步至至源端。整个回回退的时间也相相对较长。 (2)基于于数据库日志复复制的方式实现现数据迁移。 这种方法法通常要借助一一些数据迁移工工具配合完成成,如IBM Change Data Cappture(CDC)、、 OOracle Goldenn Gate(OGG))、IBM Q Repplication(Qreep)。IBM CDC 和OGG 两款款软件都是基基 于数据库日志志复制的,也就就是需要有程序序在源端根据据不同数据库的的日志API 来解解析数据库事事 务日志,随后后通过网络传输输至目标端进行行事务重放。而对于Qrep,,它和CDC 一一样,同属于于 IIBM InfoSpheere Data Replication(IIDR))产品系,算算是Db2 的原生生数据迁移工具具,功能非常常 54 商业银行数据库库管理实践 强大。Qrep 通通过IBM MQ 消息中间件作作为数据传输媒媒介,这样在在保证消息可靠靠性的前提下, 提提升了数据迁迁移速度。但QQrep 在配置管管理上过于复杂杂,所以应用的的场景并不多多。 关于数据据迁移方法的选选择和细节的介介绍,将在数数据库平滑迁移移方案中揭晓。 3.1.4 迁移移难点分析 在项目启启动会上,摆在在面前的有以下下三大难题。 难题一:如何保证小型型机下移x86 服务器后系统统的性能不低于于小型机性能?我们对x866 服服务器的性能能预期是“至少少不能低于小型型机”。 在小型机机下移前,必须须找到x86 服务器代替小型型机的有效配置置方案,从而证证明经过策略略 配配置的x86 服服务器足以代替替小型机承载相关业务。但但很难从公开的的数据集中找到到一个万能的的 换算公式,能能让我们在小型型机下移项目中中直接找到资源源配比良方。例如,小型机机有4 核64GBB 内存,需要买买哪种配置的xx86 服务器才能与其对应,刚好超过性能能预期,而又不不能过度分配配 资源,对此,我们决定拿IIBM Power 小型机与x86 服服务器进行性能能对比测试,找找出它们之间间 的资源配比方方案,后续的系系统就可以按照照这种配比方案案选择x86 服服务器了。3.2 节节中将揭晓此此 部分内容。 难题二:数据迁移过程程中,如何做到到对业务影响最小化? 小型机下下移x86 服务器器还涉及数据的跨平台迁移移。数据主要包包括两大部分::应用数据的的 迁迁移和数据库库迁移。其中,应用迁移主要要涉及应用程程序在新版本中中间件的重新安安装和部署。 而数据库迁移移相对复杂一些些,需要将数据据库内的对象象以及数据在有有限的时间窗口内传输到新新 的环境中。3.6 节中将揭晓此部分内容。 难题三:待下移的目标标系统都部署着着许多商业软软件产品,如IBBM WebSpherre Applicationn Server(WAS))、IBM Http SServer(IHS)、IBM Messagee Queue(MQ)、IBM Db2 和和Oracle 等。 这种重量级商商业软件并没有有提供细粒度的软件版本差差异项,这样就就无法做到针对对性的测试, 只能依赖传统统的地毯式测试试方法。根据以以往经验,这这种测试方法占占据了较多时间间。 上述三大大难题中最让人人头疼的就是测测试。小型机机下移涉及系统统架构的调整和和基础软件升升 级,每个环节节都需要测试验验证。最终,我我们打开思路路,创造了新的的测试方法———高仿真测试试 方法,在项目实施中将综合合运用传统测试试方法和高仿真真测试方法来来达成最终目标标。3.5 节中将将 详详细介绍。 3.2 小型机与x86服服务器大比比拼 当我们打打响这个小型机机下移战役时,,必须要做到到心中有数,如如果用x86 服务务器代替小型型 机机来承载重要要业务系统时,它能否胜任??那我们就来来华山论剑,一一决高下吧! 本节通过过对主机计算资资源、扩展性、、可靠性等层层面的分析,从从理论并结合已已公布的相关关 数据来评估xx86 服务器代替替小型机作为未未来系统服务务器的可行性。分别对比了x86 服务器与与 小型机的优势势和劣势,以及及在小型机下移移项目中的应应对策略。我们们准备据此整理理出适合自身身 现现状且充分考考虑各系统未来来几年的业务增增长,切合实实际的服务器配配置套餐,将应应用于小型机机 下移项目中。 55 第3章章 从小型机迁移移到x86 服务器器 随后,为为实现下移后系系统预期性能提提升的目标,参照评估的xx86 主机对标配配置策略进行行 性能对比测试试。选用数据库库类应用在TPPC-C 的模型场场景中的测试结结果,同时佐证证了x86 服务务 器器在性能方面面完全可以超越越当前主要交易易系统的小型型机配置资源。另外,还从已已下移的部分分 业业务系统下移移前后的性能对对比数据来分析析,按照小型型机计算资源转转换方案来配置置服务器计算算 资源,从下移移后一段时间的的系统处理能力力表现来看,选购的x86 服服务器基本是现现有在役小型型 机机处理能力的的一倍以上。 3.2.1 计算算资源对比分析 首先调阅阅两个平台CPPU 的处理能力力数据,再以Power 8 中最最高端E880 和Intel 至强强 EE7-8890 为例,分为8 路和和16 路两种CPPU 配置,根据据2016 年标准准性能评估协会会(SPEC)公公 布布的数据如表表3-1 所示。 表3-1 2016 年SPECC 公开的小型机与与x86 服务器性性能对比 技术架构 物理CPU 颗数 物理CPU 总核数 逻逻辑CPU 总核数 CPU (G U 主频 GHz) 操作 系统 作 统 CPU 整数 运算能力 CPU 浮点 运算能力 Power8-E880 16 192 1536 4.0 AIX 14400 11400 E7-8890v4 16 384 768 2.2 Linux 13900 8890 Power8-E880 8 64 512 4.35 AIX 5400 4470 E7-8890v4 8 192 284 2.2 Linux 7340 4740 表3-1 中SPECint_ratee 与SPECfp_raate 代表由SPEEC CPU 测试试工具测量出的的CPU 性能参参 考考值。前者用用于测量和对比比CPU 的整数数运算性能,后后者用于测量和和对比浮点运算算性能。这两两 个个参数值越高高,代表CPU 在该方面的运运算能力越强。 结合SPEEC 公布的数据据,Power 小型型机E880 与Inntel 至强E7-88890 处理器对对比结论如下。。 (1)在16 路机型上,Power 小型机机性能略强于xx86,但两者的的性能已经非常常接近。 (2)在8 路及以下的机机型上,x86 服服务器性能已经经超越Power 。 (3)Powwer 机型的核数数已经落后x866 许多 。 Intel 在2007 年发布的最新一代至强强CPU,配置从从高到低分为:铂金(Platinumm)、金(Gold)、、 银(Silver)、铜(Bronze)共四款。对于于数据库来说,,CPU 的需求求主要分为以下下三类。 (1)并发发连接数高、事事务粒度较小的联机交易((OLTP )类型,需要选用核核数相对较多、、 主频要求不高高的CPU。 (2)并发发连接数不高、但经常存在复复杂查询且事务务体量较大的的联机分析处理理(OLAP)类类 型,选择核数数可以不多、但但主频要求较高高的CPU。 (3)并发连接数较高,且交易偏混合合交易类型,既既有复杂查询同同时又存在频繁繁的小事务, 就需要选择主主频和核数都高高的CPU。 我们计划划在小型机转换换x86 服务器上上采用套餐化化策略。应用程程序将采用虚拟拟化部署方式, 不会单独考虑虑CPU 物理资源源分配,届时可以根据每个个虚拟机承载的的应用服务器数数量和负载情情 况进行扩缩容容。 数据库方方面需要根据业业务类型拟定出出合适的CPUU 套餐,针对对负载和数据量量较小的系统, 通通过合理的虚虚拟化转换测试试后,即可选择择虚拟机部署方方式,资源划分分策略与应用服服务器一致, 56 商业银行数据库库管理实践 可将它们归类类为同一种资源源套餐。针对联联机交易、联联机分析处理和和混合类型的系系统,将数据据 库大体分为两两类套餐。 相较CPUU,内存能对比比的指标比较少。从配置上上来看,IBM PPower 7 小型机采用DDR33 1066MHz 的内内存,而目前选选购的x86 服务务器基本采用用DDR4 2666MMHz 的内存。DDR4 提供比比 DDDR3 更低的的供电电压1.2VV 以及更高的的频宽,而且DDDR4 新增了4 个Bank Grouup 组的设计, 各个Bank Grooup 具备独立启启动操作读、写等动作特性性,在同一时钟钟脉冲工作周期期内,至多可可 以处理4 组数数据,效率明显显要好过DDRR3。 数据库类类软件对内存的的需求还是比较较可观的。从从数据库对内存存需求来分析,,将其分为两两 大类,针对在在线联机事务处处理(OLTP)类型的数据库库,相较在线分分析类(OLAAP)对内存的的 需求不是很大大。因为业务数数据本身就较少少,历史数据据也会定期进行行归档,那么活活跃的数据一一 般般不会太多,并且对于批处处理的数据量也也基本可控。因此对在线联联机事务处理(OLTP )类型型 的数据库,选选择128GB 的的服务器即可。而对于在线分分析类(OLAAP)和混合负载载(现在比较较 时髦的叫法为为HTAP )的数数据库,因这类类的应用多数数都有报表和复复杂查询,通常常会对大数据据 量量的中间结果果数据进行计算算。因此此类数数据库要配置比比较高的内存配配置,如256GGB 的服务器。 综上,无无论是CPU 还是是内存,这两两个主要的计算算资源从配置上上都比小型机强强,所以从性性 能角度分析,x86 对比小型型机,在同样的运算场景下下,其计算资源源性能应能超过过小型机。结结 合公布的相关关数据,从理论论上分析,可以以保证达到我我们对x86 服务务器的性能预期期目标。 3.2.2 存储储资源对比分析 除了前面面所述的主机计计算能力以外,,决定主机性性能的关键指标标还有I/O 处理理能力。小型型 机机具备较强的的I/O 扩展能力力,而x86 服务务器综合考虑兼兼容性,I/O 扩扩展能力逊于小型机。但小这这 并不是最终结结论,因为真正正考量主机的I/O 性能,单从从硬件架构分分析是不够的。影响主机I/OO 处理能力的主主要因素如下。 (1)硬件件I/O 卡扩展能能力。 (2)存储储阵列、本地磁磁盘。 (3)操作作系统I/O 调度度处理能力。 (4)业务务类型。 硬件的突突破总是有限的的,I/O 卡的扩扩展能力不再赘赘述。存储阵列列方面,小型机机下移x86 服服 务器后,针对应应用程序将选选择虚拟机的方方式提供服务,对于宿主机将将采用全闪阵列列存储数据。 针针对数据库,将将选择固态盘(盘SSD 全闪阵阵列)作为磁盘盘选用标准,这相比现生产的的SCSI 磁盘, 针针对随机读I//O 有明显提升升。这将较大幅幅度优化数据库库数据、索引引的顺序及随机机读取性能。 从数据存存储介质考虑,存储阵列并不不是唯一选择择。在部分x866 的部署场景中中,我们认为为 本地磁盘(SSSD)作为数据据存储介质也有有很大优势,应应该有本地磁磁盘部署场景的的用武之地。 首先在虚虚拟化方面,将将考虑采用宿主主机结合本地地盘的方式构建建虚拟化集群,,针对大多数数 对对数据存储空空间需求不大的的应用可以部署署其中。 其次在数数据库方面,也也考虑使用本地地磁盘代替共共享存储。通过过对数据库类应应用进行共享享 存存储和本地磁磁盘全方位的实实测对比,从对对比结果来分分析,可以通过过本地磁盘代替替共享存储, 例例如,Db2 HAADR 或者MyySQL 组复制(MGR)。这些些前提保证了数数据的安全性。我们认为部部 分小于3TB 数数据量,且可配配置数据库高可可用的非数据仓仓库类系统可可以采用本地磁磁盘部署方式。。 57 第3章章 从小型机迁移移到x86 服务器器 由于业务务类型不同,I//O 类型也分为为:顺序I/O 和和随机I/O。这这都对I/O 的性性能有较大影影 响。在操作系系统层面,CPUU 调度I/O 请求求的效率也是是不同的,例如如AIX 系统与Linux 系统。 因此,需要结结合实际的业务务场景进行对比性测试,测测试结果将作为为重要参考依据据。该部分在在 基基于x86 服务务器性能测试方方案中体现。 综上,在在I/O 处理能力力方面,无论是采用本地磁磁盘还是全闪阵阵列,从性能角角度完胜原来来 基基于SCSI 磁盘盘阵列。而可靠性方面,虽虽然本地磁盘无无法与磁盘阵列列相比,但通过过应用层和软软 件件层的高可用用设计可以完美美弥补这部分短短板,从而能能够扭转乾坤。 3.2.3 可扩扩展性对比分析 目前,随随着业务不断发发展,在线数据据量的增加,我们更关注主主机的可扩展性性,这将决定定 了系统性能的的伸缩能力。主主机下移至x886 服务器后,为满足系统可可扩展性要求,,应有更优的的 解解决方案。 无论是小小型机还是x866 服务器,主机都具备良好好纵向扩展能力力(Scale-up),,可以通过增增 加主机计算资资源,达到提升升单机处理能力力的目标。但对对于小型机来说说,横向扩展能能力(Scale-outt) 就显得性价比比不足,一方面面不能为了横向扩展而采购购更多的小型机机,即使采用分分区管理,那那 么这些分区同同在一台物理主主机也存在单点点风险;另一一方面,从软件件方面来看,系系统的扩展能能 力主要是考量量软件层的扩展展能力,如果果软件不能很好好地支持扩展展性,有再多的的主机也是徒徒 劳的。 x86 服务务器相对小型机机,具备更高的性价比。在在具备纵向扩展展能力的环境下下,可继续选选 择择增加横向扩扩展能力。对于于应用服务器,可以充分结合合虚拟化,实现现应用程序节点点动态伸缩, 也可轻松应对对计划性业务促促销带来的业务务峰值。对于于数据库服务器器,可以充分结结合数据库层层 高可用设计或或分库设计增强强其横向扩展能能力。但不得不不承认,一套系系统的扩展能力力的强与弱, 并不在于服务务器层面,而是是在于应用和软软件架构层面面,但服务器的的扩展能力和扩扩展策略是必必 要条件。 因此,单单从服务器的扩扩展性角度来分分析,x86 服务务器比传统小小型机更具备竞竞争力。 3.2.4 可靠靠性对比分析析 单机小型型机的可靠性要要强于x86 服务器。不得不不说,小型机在在可靠性方面,,因许多冗余余 组件和高可用用技术,如处理理器降级使用、PCI 槽热插拔拔等,所以可靠靠性相较x86 服服务器较高。 而x86 服务器器方面,硬件的的质量水平良良莠不齐,所以以从服务器本身身而言,x86 服服务器的稳定定 性与小型机不不在一个级别。 从服务器器可用性角度分分析,无须对比它们之间的的具体差异,应应从系统整体可可靠性出发, 虽然单机小型型机具备更高的的可靠性,但下下移至x86 服服务器后,可以以通过x86 服务务器有效的横横 向扩展能力,弥补其有限单单机可靠性缺失失。这就是我我们将小型机的的“独虎战术””改为“群狼狼 战术”的主要要打法。 要支持““群狼战术”,主主要挑战并不不在服务器层面面。从系统整体体可靠性对比,决定系统是是 否稳定的关键键点不在于硬件件架构的差异,而在于上层层应用。如上层层应用采用集群群化设计时, 任任意节点的宕宕机对业务系统统的服务是无影影响的。因此此,对于x86 服服务器,将把重重点放在应用用 58 商业银行数据库库管理实践 层层集群化或数数据库层多节点点化来提升系统统高可靠性。 3.2.5 小型型机与x86 服务器计算算资源实测对对比分析 “纸上得来来终觉浅,绝绝知此事要躬行行!”通过前面面对各种计算资资源的调研和分分析,只是从从 理论及公布的的数据进行初步步分析,为了找找到更适合x86 服务器的资资源配置,需要要通过实测数数 据据验证前面的的分析结论。以以理论分析为基基础,再结合实实测数据,梳理理现有小型机的的资源配置, 综合分析后得得出小型机下移移x86 服务器的的资源转换配配置套餐,应用用于所有待下移移的系统中。 我们的资资源对比测试方方案主要采用数数据库TPC-CC 标准测试场景景。TPC 是事务务处理性能委委 员会,是由数数十家会员公司司创建的非盈利利组织,TPC--C 使用三种性性能和价格度量量,其中性能能 由tpmC(Traansactions Per Minute,TPMM)衡量,C 指指TPC 中的CC 基准程序。它它的定义是每每 分钟内系统处处理的新订单个个数。之所以选选择对比测试试数据库,是因因为我们觉得在在这些待下移移 的系统中数据据库的负载比应应用程序更具具代表性,更容容易区分出测测试结果。而选选择数据库的的 OOLTP 测试场场景,主要考虑虑待下移的系统统90%都属于于商业银行的重重要交易类系统统,很多系统统 属于偏联机交交易负载和混合合负载类交易。。 选择测试试场景如下。 我们选择择使用Hammerr DB 来模拟典典型的使用TPPC-C 测试规范范的OLTP 业务务场景。配置置 部署了200 个个Warehouse,整个交易占比比为:新订单445%,付款433%,订单交付付4%,订单查查 询询4%,库存查查询4%。数据据库内各表对象之间的关系系如图3-1 所示示。 图3-1 TPPC-C 模型数据结结构关系图 在小型机机和x86 服务器器两个平台的配配置几乎相同的情况下,对对比TPC-C 的测测评值(每分分 钟钟产生的新订订单数NOPM)),x86 服务器器处理的NOPMM 数量是IBMM 小型机的近2 倍,实测数数 据据如表3-2 所所示。 表表3-2 P7 小型型机对比x86 服务务器(TPC-C) 型型号CPU 核数主主频操作系统磁盘内存数据据库NOPM TPC-C IB P7 BM 750 6 12 3.66GHz AIX HUAWEI SAS (500GB) 128GB IBM V9 Db2 .7 16 816 x86 服务 6 PC 务器 4(第4 代CPU) 10 2.0 (E7 V 0GHz -4820 V4) Linuxx HUAWEI SAS (500GB) 128GB IBM V9 Db2 .7 32 851 59 第3章章 从小型机迁移移到x86 服务器器 33.3 小型型机下移xx86 服务器器的资源源转换方案案 小型机下下移x86 服务器器的项目中,有一项很重要要的工作,就是是要找到适合待待下移系统的的 xx86 服务器资源配置转换方方案。其意义是为了贴近小型型机下移x86 服服务器项目的目标和要求, 设计出满足下下移资源需求的的资源配置,而而又不能过度度升级造成资源源浪费。配置成成型后以其为为 标杆,按照不不同的资源选择择策略,应用到到不同类的系统中去。 3.3.1 x866 服务器资源源转换原则则 在制订这这些服务器配置置套餐前,首先先要做的是分析析待下移系统的现状,并结合合项目要求, 明确小型机资资源转换的配置置原则如下。 (1)前面面也曾提到,应应用服务器由由于对主机计算算资源的需求求相较数据库服服务器来说不不 大,且应用多多为集群方式部部署,每个应用用程序主机不不会配置过多的的应用服务器,,往往都是通通 过横向扩展方方式部署在应用用集群中。因此此,对于应用用服务器,主要要选择虚拟化配配置套餐。例例 如,IBM WASS、MQ 和Weeb 服务器IHS 等。 (2)数据据库服务器主要要有两类选择。针对数据量量和未来数据增增长量均小于300GB 的非非 II/O 敏感型的数数据库,且在测试中的TPSS 和平均业务响响应时间能满满足未来3~5 年年的业务发展展 需求时,应考考虑数据库虚拟拟化。而针对超超过300GB 或或I/O 敏感型的的数据库,应该该选择x86 物物 理主机部署方方式。 (3)数据据存储方面,也也带来两种选择择。针对应用用程序统一使用用虚拟化部署,,宿主机将采采 用用本地磁盘方方式部署。数据据库方面,针对对具备较强高高可用能力的数数据库高可用部部署架构,可可 以采用本地磁磁盘方式部署。而针对只能采采用存储复制制方案实现数据据库高可用的数数据仓库类应应 用用来说,应该该选择共享存储储的方式。并通通过存储级复复制解决同城或或异地数据容灾灾的问题。 (4)内存存方面差异并不不大。中间件方方面,选择虚虚拟机配置,内内存为64GB 。数据库方面, 针针对小于300 GB 数据量的数数据库,选择择虚拟机配置不不应超过64GBB 内存。对于物物理机不超过过 2256GB 内存。x86 物理内存存一般都会配置比现有小型型机的容量大,具体按服务器器选型配置套套 餐即可。 (5)网络络方面,做了两两方面的改造。一是将原有有老系统的千兆兆网络统一升级级为万兆网; 二是对应用和和数据库进行智智能DNS 改造造,这给高可用用架构的优化打打下基础。 3.3.2 x866 服务器资源源转换方案案 结合多方方调研数据和实实测数据分析,,以x86 资源转转换为原则,最终定制出““高、中、低” 三三类服务器配配置套餐,如表表3-3 所示。 之前也曾曾介绍了新一代代拥有最强劲性性能的Intel 至至强CPU 铂金金版,它最高拥拥有8 路的高高 配配置,更像一一头“猛兽”,它的性能和一一些辅助技术十十分耀眼。但经过前期测试试和充分调研, 依照目前待下下移系统的数据据量和业务增势势,采购铂金版版的性价比太太低,反而金版版的5118 性价价 比还比较不错错。虽然该配置置在金版CPU 中也不算最高高配置,但它拥拥有4 路12 核核24 线程,最最 60 商业银行数据库库管理实践 大睿频3.2GHHz,从后续的测测试数据来看看,这基本够用用了。 表3-3 服服务器资源转换换配置套餐 x86 物理机 机高配置套餐 x86 物理机中配置套套餐 虚拟化套餐(低配置) CPU:Intel 至至强Gold 5118 CPU:Inttel 至强 Silver 44116 CPUU:按需配置 内存:256GB 内存:2556GB / 128GB 内存存:最大64GB 存储:HUAWEEI 18800 全闪阵阵列 存储:HUUAWEI 18800 全全闪阵列 存储储:宿主机采用本本地SSD 磁盘 或本地磁盘:SSSD + RAID6 或本地磁磁盘:SSD + RAIID6 中配置套套餐中的银版44116 CPU 与5118 相比,44116 只有2 路路12 核24 线程程,最大睿频频 3GHz,性能略略逊于5118 。主频要求不高高或系统负载不不高的应用可以选择该配置置套餐。在x866 服服务器CPU 的的选型上,我我们准备了许多多测试场景,例例如,按应用消耗CPU 资源源类型划分的的 消耗主频型、线程消耗型、混合消耗型三三类,做了很很多测试工作,最终才选择了了SkyLake 金金 版和银版,分分别作为中高配配置。总之一句句话:“没有最最好的,只有最适合的”。而而对于虚拟机机 方面,同样采采用金版5118 作为宿主机的的资源配置,而而虚拟机采用各各系统按需划划分的策略。 存储方面面,遵循x86 服服务器资源转换换原则,在x886 服务器上有有以下两种配置置选择。 第一种,针对大型数据据仓库类的应用用选择共享存存储作为数据持持久化的主要介介质。我们的的 OODS 系统就属属于此类应用,,在系统下移移x86 服务器后后,存储方面由由原来的EMCC 存储,统一一 更换为华为的的18800 的全闪闪阵列,从存储角度来讲也也算是一项重要要提升了,这对对于数据库的的 随机I/O 读写都有较大优化化。 第二种,考虑在小型机机下移x86 项目中开始试点点使用本地磁盘盘的高可用部署署架构。应用用 采采用集群化部部署,这是较为为常见的配置。而数据库采采用本地磁盘(SSD)的部署署方式并不多多 见,这个思路路来源于我们MySQL 数据库的常规高可可用部署方案,对于生产环境境依旧占比较较 高的Db2 数据据库在配置高可可用容灾恢复复(HADR)的的情况下依然适适用。从机房布布线和主机维维 护管理方面也也是有较大优势势,因为取消存存储部署后,会省去很多相相关工作。但从从性能方面很很 难难用经验来评评估,随后,又组组织了本地磁盘盘与共享存储储在Db2 HADRR 架构下的性能能对比测试, 总结如下。 (1)从性性能对比测试结结果来看,基于于本地磁盘构构建数据库级主主从复制的高可可用架构具有有 较较强的优势。由于x86 本地地盘多数采用RAID-1 或RAAID-6,基本忽忽略RAID 写惩惩罚。相较存存 储储也不会与其其他系统共用磁磁盘,亦不会经经过SAN,所所以性能会优于于存储。 (2)x86 物理机本地磁磁盘统一配置为为SSD 磁盘,该类磁盘都会会出现写磨损(颗粒损耗), 寿命与写磨损损的次数有关。对于数据库日志属于频繁繁顺序写,故需需要有提前预警警手段防范于于 未然。因此,我们将通过带带外监控方式对对磁盘寿命进进行监控,及时时更换风险磁盘盘。 (3)高可可用方面,本地地磁盘不如存储储。相较存储储的故障率较高高,因此对于部部署在本地盘盘 的数据库相较较部署在存储上上的出现“部分分写”(数据库库专业上叫Paartial Page Wriite)的概率相相 对对偏高。但由由于主库与备库库同时磁盘损坏坏的概率极低低,因此该劣势势并不突出。 综上所述述,x86 服务器器配置本地磁盘盘的部署方案案在部分场景还还是有用武之地地的。所以, 综合考虑待下下移系统的数据据量、业务类型型、技术架构构等方面,凡是是应用程序可以以通过集群化化 部署,且系统统对同城RPO 要要求不能为0,,数据量不超过3TB 的非数数据仓库类应用用都可以部署署 在在本地磁盘上上。 表3-4 列列示了IBM Power 小型机对标x86 服务器器的硬件映射关关系。综合实测测数据和资源源 分析,为了最最大限度保证服服务器性能,IIBM Power 小小型机CPU 1 核可以用x866 服务器3~44 第3章章 从小型机迁移移到x86 服务器器 核代替。 表表3-4 小型机对对标x86 服务器器硬件资源映射表表 61 用途IBM PPower 小型机x886 服务器套套餐选择 含6C 及以以上 4 路×12 核 HUAWEI 18 或本地盘( 核/256GB 8800 存储 SSD) x86 物理机高配置套餐 数据库 6C 以下 2 路×12 核 HUAWEI 18 或本地盘( 核/256GB/128GB 8800 存储 SSD) x86 物理机中配置套餐 任意 12 核/32~6 宿主机本地 64GB 地盘(SSD) 虚拟化套套餐 WAS 任意 4 核/16GB 宿主机本地地盘(SSD) 虚拟化套套餐 MQ 任意 4 核/16GB 宿主机本地地盘(SSD) 虚拟化套套餐 Web/IHS 任意 2 核/8GB 宿主机本地地盘(SSD) 虚拟化套套餐 将6 核的的小型机作为一一个分水岭,大大于6 核的数数据库服务器,全部采用x886 物理机高配配 置套餐来代替替;低于6 核的的数据库服务器选择中配置置套餐;数据量量较小且能通过过虚拟化转换换 测试的数据库库可以采用虚拟拟化套餐。 3.3.3 商业业汇票系统资源转换结结果 3.3.2 节介介绍了x86 服务器资源转换换方案,并结合合实际情况,总总结了资源映映射表。随即, 我们就可以通通过映射表来转转换商业汇票系系统的服务器器配置。目前,该系统数据库库服务器配置 为8 核64GB 内存,根据资资源转换方案,,将用x86 物物理机高配置套套餐来代替小型型机。应用服 务器和消息中中间件将单独部部署到虚拟机中中。详见表3--5。 表3-5 商业业汇票服务器资资源转换结果 服服务器小型机机下移x86 服务务器前小型机下移x866 服务器后 数据库服务器 IBM P EMC 存 ower6(P550) 8C 存储阵列 /64GB x86 物理机高配 (选择本地盘+ 配置套餐 +HADR) 应用服务器(WAS) 与数据据库服务器部署在在一起虚拟化套餐 消息中间件件服务器(MQ) IBM P EMC 存 ower6(P550) 2C 存储阵列 /16GB 虚拟化套餐 3.4 基础软件件版本升级级与架构构优化 我们决定定在小型机下移移x86 服务器的同时,将系系统中相关的基基础软件版本也也一并升级至至 软件版本管理理办法中要求的的最高版本。例例如,待下移移的系统涉及IIHS、WAS 、JJDK、MQ 和和 62 商业银行数据库库管理实践 DDb2 等多种软软件产品和开发发工具包,待系统下移时,要综合考虑这这些基础软件版版本升级对应应 用用系统的影响响。从变更角度度来看,这个决决定无非承担担着较大风险。项目初期,在在整体下移方方 案中,是否再再进行基础软件件升级,就成为为大家争论的焦点。 基础软件件升级后,与应应用程序本身是是否兼容必然然存在某种不确确定性。我们是是否能有合适适 的测试方案或或一套理论支撑撑就一定能保证证升级和迁移移的成功吗?答答案是否定的。。从历史上经经 历过的诸多升升级案例来看,没有万无一失失的方案能100% 保证升级级后一定不会出出问题。因此, 从整体系统下下移方案来看,许多人赞成拆拆分方案,分步步实施。虽然这这样看似将风险险降到最低, 来解决一次性性系统下移和基基础软件升级的多点变更带带来的不确定性性,但实际上也也隐藏着诸多多 不可见的风险险点,而这些风风险可能直接导导致小型机下移移整体方案的失败。这些风险险点主要有: (1)项目目层面,系统下下移与基础软件件升级方案拆拆分后,每套系系统面临工作排排期压力,很很 难难在计划的时时间内完成所有有系统的下移工工作。 (2)技术术层面,主要是是系统软件与基基础软件的兼兼容性带来的过过渡版本的选择择性问题。例例 如,系统在小小型机的基础软软件版本较低,,下移后操作作系统更换为LLinux 平台后,,迫于基础软软 件件版本兼容性性要求,软件本本身也要随之升升级。如果选选择过渡的版本本,再升级到最最终版本的做做 法略显多余。另外,选择应应用程序和数据据库分开升级级,也会存在新新老版本共存,,同时维护两两 套环境的问题题,这同样带来来不必要的复杂杂性,同时带带来隐患。 经过讨论论研究,我们将将在小型机下移移项目中统筹筹考虑基础软件件升级的方案,,将其融合到到 整体下移方案案中,与此同时时也解决系统中软件退出服服务期(EOS)的问题。对于于前面提及的的 问题,我们并并没有采用传统统互联网的做法法,用灰度发发布的方法来进进行上线后分流流测试,这种种 方案在某些金金融系统场景中中并不适合。我我们依然采用测测试的方式在在软件升级前安安排专项测试, 创创新思路在于于测试范围大幅幅度的缩减。这这部分主要在在软件版本差异异性对比的方案案中说明。 3.4.1 升级级策略 因为小型型机下移项目中中涉及的系统较较多,每个系系统架构和软件件现状又千差万万别,因此, 需要从整体下下移方案中考虑虑基础软件升级级。为了贯彻彻和落实我们提提出的技术方案案,在每套系系 统小型机下移移分析前,都要要形成一份专业业化的技术评评估报告,例如如《某系统小型型机下移技术术 分析报告》。在在报告中形成有有针对性的基基础软件升级策策略,主要包括括应用相关软件件升级策略和和 数据库升级策策略两部分内容容。 在生产环环境下,待下移移的系统比重比较大的还是是传统的企业级级应用架构,经经过前期的梳梳 理和汇总分析析,我们的生产产环境相关软件件主要包括Weeb 服务器、中间件、数据库和和应用程序, 如表3-6 所示示。 表3-66 应用程序软件件分类 Web 服务器中间件数据库应应用程序 Nginx IBBM WebSphere Db2 Java 应用用 IBM IHS IBBM MQ C/C++应用用 1. Web 服服务器软件升级级 主要有两两种软件产品,IBM IHS 是是基于Apache 的高性能Webb 服务器,其版版本要求和应应 用用服务器的版版本一致,一般般升级了中间件件也会一同升升级IHS,同时时也会将Plugiin 组件一同更更 63 第3章章 从小型机迁移移到x86 服务器器 新到相同的版版本。如果Weeb 服务器暴露露在公网,前端端是负载均衡进进行轮询分发时时,这时会选选 用用版本较高的的Nginx 代替IIHS。或在IHHS 前面再加一一层Nginx 做反反向代理,达到到软负载均衡衡 的效果。 2. 中间件件升级 分为应用用中间件和消息息中间件,具体体如下。 (1)IBM WAS 应用中间件。WAS 的的版本选择V99 的大版本,主主要也是为了解解决软件退出出 服服务期的问题题。同时,也考考虑升级WASS 内置JDK 版版本至V1.8。根根据前面的介绍绍,在下移的的 项目中优先沿沿用原先的软件件,所以应用中中间件并未选择择市面上的开开源中间件或其其他商用产品。。 (2)IBMM MQ 消息中间间件。主要负责系统间数据据传输,它与应应用程序间兼容容性很高,在在 整体系统测试试中通过报文捕捕获的方式验证证消息传递的准确性。 3. 数据库库软件升级 待下移的的系统中,数据据库产品使用很很单一,全部部是IBM Db2 。而现有的数据据库版本是多多 样样的,最低版版本有Db2 V9..1,最高有Dbb2 V10.5 。对此此现状,系统下下移后,将统一一升级至Db22 VV11.1.4.5 。当时时选择这个版本的原因有二二:主要考虑到到V11.5 刚刚出出厂,还不稳定定;而V11.1.4.55 又解决了之前前许多程序缺陷陷,且在读写分分离支持上略略有提升。 数据库跨跨平台升级的常常用方式有两种种:一种是比比较简单的数据据迁移方案,即即将数据导出出 后,在新环境境导入的过程;另一种是通过过工具准实时时跨平台同步日日志数据的方式式。这两种方方 案各有优略,细节将在3.6 节来详细描述述。 4. 应用迁迁移 主要分为为Java 应用和C/C++ 应用,具体如下。 (1)Javaa 应用迁移。 由于JDKK 目标版本是是1.8,在应用代码重新编译译后,还需要大大量的测试工作作。从理论上上 来讲,JDK 升升级后,对某些些方法不推荐使用,在程序序中依然使用这这些老方法可能能会带来效率率 问题。我们曾在某套JDK 11.4 的应用中找找出了比较严重重性的方法弃用问题,在JDDK 1.8 中不再再 使用这些方法法了,这些问题题都是在程序测测试阶段发现现并改造的。 另外,JDDK 升级后的难难点不仅是应用程序本身的的兼容性问题,最难解决的是是第三方程序序 组件的适配。例例如,报表类jar 包或框架类类的程序,如Spring、Hibernnate 等,对于常常见的框架, 可能官网或社社区会公布是否否支持JDK 1.88,但大多数边边缘组件可能都都无从查证,只只能通过测试试 进进行验证。所所以,我们对于于第三方的程序序采用的策略略主要是先在官官网确认兼容性性,不确认的的 通通过测试手段段辅助确认。 (2)C/C+++应用迁移。 待下移的的系统中也有一一部分是通过C/C++ 开发的的应用程序。因因涉及平台的转转换(从AIXX 到x86),应用用必须要做重新新编译。小型机机下移后的操操作系统采用红红帽Linux 7.7 版本,对此类类 应应用先找到源源码用新版Linnux 平台下的GGCC 编译器进进行重新编译。。考虑到程序员员的开发水平平 良莠不齐,在在开发的过程中中对程序的兼容容性和健壮性性考虑不足,更更换环境后极易易出现如内存存 越越界或访问地地址错误等问题题,所以需要通通过一些辅助工具进行验证证。 3.4.2 不同同版本差异性对比 商业银行行业务系统的复复杂度超过很多多人的想象,系统间的调用用和级联关系错错综复杂。软软 64 商业银行数据库库管理实践 件件升级必经之之路就是全量测测试,通过全量量交易码的梳理理和后续的全回归测试,最终终才能上线。 迫于软件版本本管理要求,亟亟待找到一套完完善的工作机机制来应对后续续软件的升级常常态化。 要想改变变现状,墨守成成规是不可取的,必须利用用科学的方法来来改善这种“地地毯式”测试试 方案带来的测测试周期长和资资源消耗大的问题。我们分分析了以往的测测试方案,结合合各专业方向向 的专家建议,梳理了同业软软件升级时遇到到的问题和相相关软件厂商公公布的软件版本本差异,总结结 出一套辅助测测试的方法,主主要目的在于缩缩减后续系统统测试的范围。随之测试案例例也会缩减, 那那么将会节省省一部分软件的的测试时间和资资源消耗。这这种辅助测试方方法叫作“软件件版本升级差差 异化分析”,分分析结论主要基基于软件版本本差异库。基础础软件升级带来来的变化后对应应用程序的影影 响是未知的,我们往往期望望测试越全面越越好。那么,如果已知这些些软件的变化项项,也就是软软 件件升级前后的的差异,只针对对应用所调用软软件变化部分分的功能即可发发现软件升级后后给整个系统统 带来的影响和和变化。 1. Web 服服务器、中间件件等版本差异异 这些软件件产品与应用程程序本身代码的耦合性不强强,只负责交易易请求的转发、、负载均衡、 消息传递等。因此,Web 服服务器、消息中间件、编译译器等软件升级级,根据规范配配置相关参数数 后,结合系统统完成普通功能能测试即可。 2. 应用升升级版本差异 对于Javaa 程序,按照如如上逻辑,需需要找出JDK 11.5 与JDK 1.88 的具体差异,,如果真能从从 AAPI 层面整理理出差异,那可可能是非常厚的一本手册,但缺乏实用性性。所以,只能能从各项目组组 在在以往升级项项目中积累的实实战经验发布到到软件差异库库中,这样也可可以应用到其他他相关软件升升 级项目中去。 对于应用用程序升级JDKK,最难的并不不是应用程序本本身的调整,因因为我们掌握这这些源代码, 很清楚版本变变更后做出相应应的调整。而对对于第三方插插件或框架的升升级是重点,针针对升级JDKK 带来的差异,只能采用官方方确认结合通过过性测试的方方法来验证。 涉及C/CC++程序的编译译器,由于操作作系统的平台更换,由原来来的Xlc 更换为为GCC,对于于 CC/C++ 程序第一步要做的就就是先要通过GGCC 的编译。那些在开发初初期不考虑兼容容性、鲁棒性性 的程序将会在在编译中暴露出出大量问题,这这就需要根据据之前总结出来来的软件差异库库中的专家建建 议议来调整相关关程序,并最终终完成测试目标标。 3. 数据库库版本升级差异化对比策略略 在应用程程序代码逻辑不不变的情况下,,对于数据库库的影响冲击较较小,主要包含含以下两方面面 考考虑。 第一,是是新版本数据库库带来的新老功功能的兼容性性,而这部分变变动主要由原厂厂发布前的大大 量量相关产品级级测试,无须再再投入更多的精精力,只需要要针对应用程序序使用到的差异异部分进行测测 试试即可。 第二,涉涉及应用与数据据库交互的SQQL 语句执行计计划发生变化。。因为数据库版版本升级后带带 来统计信息的的变化,从而影影响数据库优化化器的最终判断,造成SQLL 语句的运行时时长无法达到到 预预期。这就无无法通过软件版版本差异化分析析来提前预估估影响的交易场场景,即使将统统计信息更新新 到最新,SQLL 的执行效率也也有可能与之前前版本不同。 如图3-2 所示,我们梳梳理了所有待下移待升级的的数据库产品,总结出适合现现有软件升级级 场场景的数据库库版本差异库,主要由以下三三部分构成。 第一部分分由原厂提供的的软件版本差异异和已知升级级后的版本问题题构成。 第3章章 从小型机迁移移到x86 服务器器 第二部分分由专家建议构构成,这部分信信息是历史以来数据库版本本升级的问题与与经验总结。 第三部分分是同业的相关关升级案例与知知识分享。 65 图3--2 软件版本差异库 基于软件件差异库的“软软件版本升级差差异化分析”是一种辅助手手段,它存在的的目的是对传传 统测试进行有有效的补充,尽尽量避免“大水水漫灌”式的的测试方法,针针对存在差异的的软件功能项项 所所对应的交易易码进行针对性性的测试,从而而有效降低测试成本。 3.4.3 软件件架构优化 软件层面面,应分别从应应用程序、数据据库、网络等等方面进行优化化评估,目的也也是在完成系系 统下移的同时时,将下移后的的系统性能发挥挥至极致。下下面就介绍在系系统下移过程中中在软件上的的 优优化方案。 1. 应用层层优化方案 除了应用用层相关软件升升级以外,考虑虑分别对Webb 层、应用服务务器、数据缓冲冲层进行了不不 同程度的优化化。 首先,将将Web 层物理机机资源转换为为虚拟机(后称称P2V 资源转转换),这样既便便于服务器资资 源源管理又能有有效提高Web 可可靠性。为进进一步提升系统统高可用能力,对重要的交易易系统增加硬硬 负载(如F5)或软负载均衡衡器。 其次,对业业务压力较大大的应用服务器器集群进行纵向向扩容(Scale--up)或横向扩容(Scale-out)) , 并优化相关参参数。目的是为为提高应用集群群可用性,并并进行压力分摊摊。 最后,还还有一些特殊应应用场景的优化化,为并发压力力大或存在“抢抢购”类业务的的交易系统, 在在中间件层和和数据库层之间间增加缓冲层。事实证明,这些应用缓冲冲层在提供更好好的客户访问问 需求的同时,大大缓解了后后端数据库层的的压力。 2. 数据库库层优化方案 据统计,涉涉及小型机下下移的数据库系系统均为IBM Db2,不考虑下下移至其他的数数据库产品, 也不涉及国产产化的改造方案案。 针对集中中式数据库的优优化方案,将首首选Db2 高可可用容灾功能(HADR)提高高单节点高可可 用用能力。针对对A+类系统,考考虑应采用一一主三备的数据据库级高可用方方案,实现两地地三中心的高高 可用部署架构构。针对A 或部部分B 类系统统,可搭建一主主两备的数据库库级高可用方案案,实现同城城 容灾。 多节点并并行处理架构(后称DPF)的优化方案,根据业务与数数据量增长趋势势,针对单分分 66 商业银行数据库库管理实践 区数据量达到到TB 级别,且且应用主要进行大数据量加加工、流转、清清洗等动作的在在线分析类业业 务(OLAP)。为为了充分利用每每台x86 服务器的计算资源源,考虑将数据据库架构转换为为多分区(MPPP Share Nothingg)模式。 数据库读读写分离场景用用于解决“读””的压力,主要要针对在线事务类业务(OLLTP)。例如, 在性能压力测测试环境中,单单节点数据库库无法应对高并并发读操作时,,可以考虑将读读业务(或部部 分读业务)分分摊到更多数据库备机上,这样将有效地地缓解主库压力力。 对于数据据基础体量大,且读写压力都都非常高,尤其针对在线事事务类业务(OOLTP )短事务务 写的压力,如如果性能压力测测试数据无法达达到预期,将将考虑采用自研研的分布式数据据库进行分库库 分表的拆分优优化。 3. 网络层层优化方案 小型机下下移x86 服务器器的项目中,涉涉及系统网络层层面的优化主主要涉及智能DDNS 和网络安安 全全性方面的改改造。 智能DNS 改造方面主主要从应用和数数据库两个层级级部署实现。应用层建设DDNS 主要为了了 实现双活应用用调度,在同城城机房配置应用用服务器集群实实现应用双活活。数据库层的的DNS 改造主主 要用于结合当当前数据库主流流的高可用架构构进行平滑服服务切换,提高高高可用性的同同时,配合实实 现现系统自动化化切换。 网络安全全性方面的改造造主要涉及应用用前端反向代代理的更换。部部分商业银行安安全规范中规规 定了Web 服务务器禁止使用Root 账户配置置启动的要求。。另外,传统统的80 端口也需需要进行相应应 的调整。基于于安全规范的发发布,从技术层层面建议将暴暴露在公网的DDMZ 的Web 服服务器统一调调 整为Nginx。 3.4.4 商业业汇票系统软件升级和和架构优化结结果 根据基础础软件的升级策策略,商业汇票票系统最终评评估结果如表33-7 所示。 表3-7 商商业汇票系统软件件升级列表 评估内容 小小型机下移x86 服务器前小型型机下移x86 服务器后 软软件版本软件件版本 操作系统AIXX 5.3 Linux((RHEL) 77.7 数据库IBMM Db2 9.7.0.11 IBM Dbb2 111.1.4.5 应用中间件IBMM WAS 6.1 IBM WWAS 99.0.0.10 应用消息中间件件IBMM MQ 6 IBM MMQ 99.1.2.0 Java JDKK 1.5 JDK 11.8 开发框架 Stru +Spr +Hib ts ring bernate 1.2.4 +2.0 +3.2.0.cr4 Struts +Spring +Hibern g nate 1 + + 1.2.4 +2.0 +3.2.0.cr4 从表3-7 可以看出,除除了第三方开发框架的依赖赖包版本未升级级以外,我们的的目标是将商商 业业汇票系统内内部的所有基础础软件升级到当当前(2020 年年)最高版本。 1. 软件升升级评估结果 在这里比比较大的风险点点是对JDK 的的升级,主要体体现在以下两个个方面。 (1)源代代码兼容性存在在问题。通过JDK 1.8 编译,先后发现程程序转码问题、FTPClient 实实 67 第3章章 从小型机迁移移到x86 服务器器 例例化等问题,需要进一步调调整代码,并将将其总结编入入软件差异库中中。 (2)对第第三方框架和第第三方jar 包的的影响。我们需需要花费大量的的时间和精力反反复确认相关关 程程序jar 包与JDK 的兼容性性。这也将作为为测试环节的重点测试场景景。 另外,配配置新版本应用用消息中间件时时,只遇到常见的MQ 20355 异常,需要单单独关闭通道道 权权限。 注意:MQ 22035 异常 IBM MMQ 在7.1 及更更高版本中默认认配置通道权限限记录,该记录录阻止所有MMQ 管理员作 为客户机连接接到队列管理理器。需要通过过如下命令关闭闭权限。 runmqscc <qmname> alter qqmgr chlauthh(disabled) alter qqmgr connautth('' ) end 数据库方方面,在升级评评估过程中,根根据总结的软软件版本差异库库进行应用代码码梳理,均未未 发现问题,剩剩下的工作就可可以顺利进入测测试阶段了。 应用服务务器方面,由于于进行了横向扩扩容,所以需要要重新调整Weeb 服务器、Weeb 容器、JDBCC 连连接池等相关关参数。 2. 架构优优化结果 架构方面面,为了避免资资源争用,将应应用服务器从从数据库服务器器迁出。另外,,考虑到未来来 3 年的业务增增势,TPS 峰值值预计增加200%。参考应用用程序服务器性性能测试结论,,单台应用压压 力较大。为能能更好地向客户户提供优质服务务,计划将4 个服务器横向向扩容至6 个,,分别部署在在 3 台虚拟机中。 数据库方方面,从主备加存储复制的架架构,优化为DDb2 HADR 一主三备,两地三三中心架构, 并使用本地盘盘替换共享存储储。 消息中间间件方面,将原原有的单节点MQ 优化为集集群部署架构。 网络方面面,应用服务器器前端已经改造造为智能DNSS,实现同城平平滑切换,本次次下移将数据据 库层也改造为为智能DNS。 3.5 小型型机下移x86 服务务器系统测测试方案 正如前面面所述,无论是是小型机下移资资源选型后的的论证,还是基基础软件的升级级,离不开的的 一道工序就是是测试。如何优优化现有测试方方法带来的工工期长、所用资资源多的问题,,一直是我们们 研研究的课题。在项目中独创了一一种新的测试方法,起源于“用新思路, 最终,我们在小型机下移项于 解解决老问题”的工作思路。 3.5.1 传统统测试方法 传统测试试方法,意指在在测试项目中常常常使用的黑黑盒测试、回归归测试和性能测测试等传统手手 段的测试方法法。这种测试方方法的测试场景景选择往往有有两种策略,一一种是高频交易易选择法,即即 68 商业银行数据库库管理实践 选选择几只经常常访问的高频次次交易码作为测测试场景;另另一种是全量测测试选择方法,,即需要将该该 系统涉及的所所有交易码梳理理出来再测试,如在测试过过程中修改了部部分代码,还需需要再进行回回 归测试全量运运行所有相关测测试场景。 传统测试试方法中有些难难点需要克服。。例如,被测系系统涉及与第三三方系统进行交交互通信时, 往往往需要开发发相对应的挡板板程序来完成此此类测试,而而这类挡板程序序只能采用固定定交易往复模模 型,返回固定定的消息内容,所以不能真正正模拟出所有有真实场景。 从现阶段段传统测试所用用工具来看,业业内经常使用传统测试工具具(如LoadRuunner 等工具) ) 完成上线前测测试。采用此类类测试工具,进进行传统测试试的弊端主要有有以下几点。 (1)测试试前需要先梳理理测试场景,并并根据场景来来定制测试用例例,往往不能实实现业务系统统 交易码的全量量覆盖。 (2)需要要测试人员根据据测试用例定制制化开发测试试脚本,用于实实现各场景的回回归测试,这这 需要大量时间间调试及开发脚脚本。 (3)测试的数据均采用用测试人员模拟拟的数据,而非非真实的交易数数据,造成测试试结果失真, 很难真实地描描绘生产负载情情况。 利用传统统的测试方法,很难达成小型型机下移x86 服务器的项目目目标,所以要要改变以往的 测试方法,利利用新方法来开开展测试工作。。 3.5.2 高仿仿真测试方法 分析了目目前业内常用的的测试方法后,,我们取长补补短研发了高仿仿真测试平台。。该平台利用用 了一种基于交交易报文精确化化匹配和自动化化返回方法与与装置,结合生生产网络镜像流流量导出的真真 实业务报文进进行测试,提升升了测试质量的同时也缩短短了测试工期,传统的测试方方案将被高仿仿 真真测试方案代代替。 如图3-3 所示,我们在生产网段区域域搭建了隔离区区环境,该环境境内的数据流向只进不出, 隔离环境内数数据无须进行脱脱敏,这点保证证了数据的安安全性。高仿真真测试是通过生生产网络流量 图3-3 高仿真测试平台台架构图 69 第3章章 从小型机迁移移到x86 服务器器 镜镜像方式获取取真实业务报文文数据,随后将将真实生产数数据单向传入隔隔离环境内,再再通过一种基基 于交易报文精精确化匹配和自自动化返回方法法与装置,将真真实业务报文文自动化发向两两种测试环境, 基基于报文粒度度对每一笔系统统间传输的往复复报文进行字字段级对比,以以此判断总结来来自两个系统统 平平台的业务系系统差异化报文文,从而达到对对比测试目的。 这里运用用x86 环境与AAIX 小型机环环境做比较,目目的是寻找来自自这两个环境应应用程序执行行 结果的具体差差异,以此来判判断系统下移后后对应用程序序的影响。因为为小型机下移x86 服务器主主 要更换了软件件和应用程序的的系统运行环境境,并将基础础软件进行版本本升级,应用程程序本身代码码 逻逻辑并不会发发生改变,运用用对比测试方法法可以直接找找到问题点。这这种测试方法与与传统的系统统 测试不同,重重点是找差异,随后针对差异异再制订整改改方案。 高仿真测测试平台的主要要流程主要分为为数据准备、报文捕获、交交易还原、交易易重放和结果果 对对比五个步骤骤。 1. 数据准准备 数据准备备工作主要是根根据被测系统的的架构和基本本情况,在隔离环境搭建与AAIX 生产1︰11 的系统环境,随后再根据小小型机下移至x86 服务器的的资源转换方案案在隔离环境内搭建与小型型 机机对标的x86 服务器环境。 2. 报文捕捕获 在生产网网段通过TAP 分分路器设备复复制一段时间的的真实生产报文文流量,以文件件形式保存在在 报报文文件落地地区。 3. 交易还还原 在交易还还原阶段,通过过集中备份系统统将复制好的的过去一段时间间的真实报文文文件单向传输输 至高仿真测试试服务器中,高高仿真测试服务务器读取并格格式化生产真实实报文,解析报报文字段,建建 立立请求与应答答报文的关系。 4. 交易重重放 在交易重重放阶段,模拟拟生产真实交易易请求,根据据不同的报文格格式分别向隔离离环境内的小小 型机和x86 服服务器发起交易易请求,重放所所有生产录制制的交易。 如图3-4 所示,针对与与第三方交互的系统,高仿仿真测试过程中中会配置交易报报文精确化匹匹 配配和自动化返返回装置,简称称为“智能强关关联”挡板程程序(后称“智智能挡板”)。该该程序与以往往 的挡板程序有有较大不同,主主要是传统测试试中的挡板程程序只能返回固固定应答报文,,对于需要几几 次通信往复的的交易就无法进进一步模拟测试试。而智能挡挡板程序会自动动适配被测系统统发送的报文文 请请求,并根据据获取的生产报报文交易路径,,分析出需要要反馈的响应报报文。 图3-4 高高仿真智能挡板工工作示意图 图3-4 中的报文1、2、3、4 是代表表生产环境系统统产生的报文。那么在高仿真真测试的时候候 通通过网络镜像像流量抓取,落落地文件解析,,将报文1、22、3、4 导入到到高仿真测试平平台的数据库库 70 商业银行数据库库管理实践 中,并且通过过报文中的某些些信息,建立报报文1 与报文文2 的关系以及及报文2 与报文文3 的关系。 高仿真测测试执行的时候候,模拟发送工工具从数据中读取报文1 发发送至被测系统统,同时把报报 文1 和报文22 的关联关系发发送给智能挡板,报文关系系其实就是依据据哪些信息能够够在数据库中中 搜搜索到报文2 的。 被测系统统接收到报文11 后,通过业务务逻辑处理产生生报文2',注意不是报文2,因为在新的的 测试执行中,被测系统产生生的报文有些信信息是动态变变化的,例如,流水号、时间间戳等每次执执 行行都会产生不不同的值。 智能挡板板接收到报文2'之后,会对它进行解析,提取动态生成成的信息,例如如流水号、时时 间戳。同时挡挡板工具接收模模拟发送工具发发送的报文1 和报文2 的关关联信息,从数数据库搜索到到 报报文2,依据报报文2 和报文文3 的关联关系系搜索到报文3,再对报文3 进行实时处理,例如,将将 解解析提取报文文2'中动态信息息替换报文3 中相应的信息息,产生报文33'返回给被测系系统。被测系系 统接收报文3',进行业务逻逻辑处理,生成成报文4',发送送至模拟发送送工具。 在高仿真真测试中,智能能挡板实现了报报文的精确化化匹配,以及报报文的实时处理理,返回给被被 测系统不再是是固定格式、固固定数据的报文文,而是完全全匹配每次测试试执行产生的数数据。 5. 结果对对比 最后,在在高仿真测试的的前端GUI 展展示界面中,会会为每个测试试场景展示出报报文对比结果, 利用报文对比比工具扫描出来来自不同环境的报文字段差差异结果,根据据具体的差异项项可以协助开开 发人员判断出出具体差异项来来自于哪个业务务实现逻辑,可以针对性地地设计整改方案案。 通过对高高仿真测试在小小型机下移x86 服务器项目中的应用,总总结其优势如下下。 (1)解决了了传统测试模模拟测试数据带带来的缺乏真实实性等问题。高高仿真所用真实实生产数据, 能清晰地回放放生产真实交易易情况。 (2)高仿仿真测试整个定定制及测试过程程中实现自动动化,因此节约约了测试人力自定义编写测测 试试脚本的时间间,并缩短了测测试工期。 (3)高仿仿真测试突破了了传统的测试方方案对交易路路径设置固定挡挡板的方案。采采用智能挡板板 针针对不同交易易特性,将每一一笔交易的往复复规则记录在在数据库中,并并自动关联匹配配真实的响应应 报报文,替换关关键动态信息字字段后反馈被测测系统,达到到交易的100% 全全覆盖。 高仿真测测试方法适用于于带有系统间交交互(如Socket 、MQ 异步步通信等)的复复杂业务系统统 通通过性测试,尤其针对基础础软件升级或相相关变更类的的测试,并不适适合应用程序变变更后的单元元 测试或回归测测试。 针对HTTTP 类的交易,,因无法解析请求与响应报报文的对应关系系,所以无法通通过高仿真测测 试试来回放带有有HTTP 类的生生产交易。针对对这个问题,可可以通过机器人人流程自动化化工具(RPA) 方式辅助测试试,此工具采用用录制加回放技技术,即先由由手工完成一遍遍需要测试的流流程,同时捕捕 获用户每一步步键盘的操作或或鼠标的像素坐坐标形成记录录,所有记录转转换为脚本文件件。随后,回回 放放时将脚本转转换为屏幕的操操作。 3.5.3 性能能测试评估原则 在小型机机下移项目中,是否需要进行行性能测试,要进行评估后后才能决定。 基础软件件的运行环境从从小型机下移到到x86 平台,是否需要进行行性能测试,唯唯一的决定因因 素是应用做了了什么样的修改改,是否改了接口与逻辑,而不是Db2 数据库运行环环境和版本的的