xindo99
作者xindo992021-01-18 10:21
系统架构师, 某证券

某证券核心交易系统从 x86 架构迁移到浪潮 K1 Power 架构实践经验分享

字数 6140阅读 4008评论 6赞 11

【摘要】

文章以某证券公司机房建设项目构建新的两地三中心为背景,分享证券核心交易系统从x86服务器迁移到浪潮K1 Power E950小型机的实践过程,通过现状分析、新旧架构对比论证其架构转型的必要性,阐述证券交易核心系统架构迁移的不寻常之路。

项目背景

根据公司IT建设发展规划,为更好地适应未来公司业务发展需求,2020年1月公司正式启动了上海金桥机房建设项目,包括恒生UF2.0在内的多个关键系统将从目前的张江机房切换到金桥机房。在项目建设完成后,新交易中心将以上海金桥机房作为主中心,与上海张江机房同城备份中心、福州异地中心机房形成两地三中心的架构。

在2020年4月完成网络基础环境的建设后,根据项目建设方案,金桥机房对新购置的服务器进行部署,在应用部署陆续完成达到切换条件后以业务系统(含关联性系统)为单位分阶段分批次进行切换。这样一个全新的机房建设项目,客观上为我们营造了一次难得的契机,那就是通过这次新的机房建设项目,重新审视现有的IT架构,针对当中出现的问题与不足,彻底卸下历史包袱,在一个崭新的环境中进行调整与优化。其中核心交易系统数据库在硬件选型和系统架构方面是否需要调整也是此次项目前期评估中的一项重要任务。

近年来在互联网公司思维的感召下,x86化的呼声越来越高,从x86迁移到浪潮K1 Power这种看似违背潮流的做法似乎显得有些不合时宜,曾经也有不少的朋友向我提出这样的疑问,这样的转型对我们是否有现实意义可以听听我们分析。

需求分析

公司在2017年建设新一代核心系统,将核心交易系统从某证券交易柜台系统转到恒生UF2.0系统,当时考虑到系统负载均衡以及单台x86服务器所能承受的系统压力等因素,数据库架构了采用3+1的部署模式,即按业务功能进行分库,部署了3套与实时交易相关的应用服务(交易中心一、交易中心二、账户中心)和1套以查询及报表功能为主的经营管理应用服务,整个架构共包含8台4路x86服务器。

据了解,业内也有不少使用恒生UF2.0系统的证券公司采用1+1或者2+1的数据库部署模式。在本次金桥机房建设项目之前,公司所有机房包括核心系统在内部署的均是清一色的x86服务器,本次项目核心数据库是否继续使用x86服务器,部署的架构是否需要调整,以及如何在一个合理可接受的成本框架内实现架构的最优化成为项目需要实现的目标之一。

痛点

核心应用采用的3+1部署模式,虽然自2017年正式上线以来总体运行平稳,在性能上能够满足核心交易系统的需求且理论上有足够的余量应对未来几年可能突然爆发的行情,但是在经历了几年的实践和磨合后也逐渐显现出了一些架构的不足之处:

(1)整体架构臃肿,运维成本较高。尽管8台服务器在数量上并不起眼,但作为核心服务器其运维压力不容低估,升级、监控、设备维护所承载的工作都不可与一般用途的服务器相提并论,例如由于每个中心对应一套不同的应用用户,运行升级脚本前,需要提前改好脚本中的数据库连接,使不同的用户连接到对应中心,通常涉及的脚本和用户比较多,需要花较多的时间进行核对。

(2)x86服务器整体故障率较高。从过往的统计数据来看,x86服务器整体故障率较高,轻则导致服务器部件冗余度降级,重则可能直接引发宕机,虽然核心数据库未曾发生过影响业务的事故,但也倍感压力。近年来外部监管对证券行业信息系统安全的要求和检查的力度也不断提高,信息系统安全事件除了导致直接的经济损失以外还有可能面临严厉的监管处罚。

(3)理论上的故障点较多。由于交易中心一、交易中心二、账户中心、经营管理中心各自承当不同的功能,各个中间件与4个中心的连接是多对多的关系,关联性较为复杂,任一套应用中心出现问题时都不能简单的进行单个中心的切换,而需要将4个中心当成一个整体进行应急处置切换,这与1+1的部署模式相比较,理论上故障点增加了一倍。

原因

针对当前核心系统数据库架构存在的不足之处,综合多方面因素考虑,决定将核心服务器从当前的x86服务器迁移到浪潮K1 Power服务器,主要原因有以下几个方面:

(1)浪潮K1 Power服务器所具有的高RAS特性(高可靠性、高可用性、高服务性)。恒生UF2.0使用的数据库属于传统的集中式架构,风险集中度相对较高,与其他具有分布式部署特征的应用相比,这种架构对单个服务器的可靠性要求更高,浪潮K1 Power具备的RAS能力使它更加适合这样的使用场景。一方面从硬件设计层面来说,浪潮K1 Power支持从CPU、内存、互联到IO以及关键组件提供全面的RAS保护,而x86仍停留在Intel RAS 2.0为基础的器件级RAS层面;另一方面由于浪潮K1 Power的操作系统为硬件量身定制,两者深度契合,与x86服务器的松耦合、开放性的架构相比,这种量身定制的组合具有更高的可靠性。

(2)浪潮K1 Power服务器具有更出色的性能。其CPU指令集的执行效率,超高的主频,单核多线程的处理能力,IO总线带宽等方面具备更好的的优势,单机的整体性能比x86更胜一筹。其优异的性能可以为未来持续快速增长的业务提供可靠的性能保障。

(3)精简架构。凭借单机性能上的优势,可以将核心数据库原来相对复杂的多集群多中心的架构进行整合,使用更加精简的架构,从而降低运维复杂度,减轻运维压力,由于架构的精简,理论上的故障点也随之减少。

(4)总体成本可控。成本是所有项目不可回避的一个因素,方案再好也要在可接受的成本框架之内,否则都将成为一纸空谈。对于此次项目来说,由于只考虑对核心服务器进行架构迁移,通过整合后总的服务器数量减少了,总体硬件成本虽仍略有增加,但是仍然可以控制在一个相对合理的范围内,如果能做到以较小的成本代价换取可靠性和性能上的优势何尝不可。

另外,据此前调研统计的数据,在使用恒生UF 2.0系统的46家券商中,有31家券商的核心系统使用浪潮K1 Power服务器,UF 2.0系统使用浪潮K1 Power服务器的方案已相当成熟,其架构的稳定及高效已在行业中得到充分验证,由此可见浪潮K1 Power机仍然是恒生2.0系统的主流架构,是我们应当考虑的首选方案。

整体架构方案设计

新的架构在设计上主要遵循三个原则:架构精简、性能不减、成本可控。具体来说,在精简架构方面,核心数据库从之前的3+1架构整合为1+1,即交易中心一、交易中心二、账户中心合并为一(以下称为交易中心),经营管理中心保持原有架构不变,调整后的两个中心均为两节点的应用集群。针对性能上的要求,新的架构不但要满足当前系统的负载需求,同时也要考虑未来几年因用户量增加、证券行情爆发等因素带来的系统压力。

在控制总体成本方面,此次项目共部署300多台服务器,在控制总体成本的前提下,要使好钢用在刀刃上,将最优质的资源分配给最核心的需求。在核心应用新的1+1部署的架构中,交易中心与证券实时交易关系最为密切,是最为核心的部分,成为项目特殊关照的对象,因此成为唯一使用浪潮K1 Power服务器的系统,经营管理中心因为主要承担查询任务,重要性次之,故仍然使用x86服务器,其它具备分布式特征的中间件及非核心应用也继续使用x86服务器。具体到浪潮K1 Power的配置,以满足实际需求为导向,避免性能过剩带来的成本压力。根据此前的调研结果,在近期已实施或者正在实施的核心系统的相关项目中,大型券商多数采用浪潮K1 Power E980,而中小券商更多的使用浪潮K1 Power E950,根据系统规模对比测算,浪潮K1 Power E950比较适合我们的需求。

最终确认的核心数据库架构方案就是:1+1,即1套2台浪潮K1 Power E950服务器组成的交易中心数据库集群与1套2台x86服务器组成的经营管理中心数据库集群。这样的整合方案使核心数据库在架构上实现了精简,性能上能有效保障业务需求,整体成本也得到了有效控制。

在新的两地三中心的架构中,浪潮K1 Power服务器作为主系统部署在上海金桥机房,原作为主中心的上海张江机房被重新定位为同城备份中心,原来3+1的架构将被4台x86服务器组成的多中心合并部署的集群所替代,福州异地中心机房不涉及调整,同样为4台x86服务器组成的多中心合并部署集群。另外,核心数据库在各中心机房之间的数据同步的流向也将作出相应调整。方案实施前后核心数据库的部署架构及两地三中心的容灾关系变化如下:
图 1方案实施前

图 1方案实施前

图 2方案实施后

图 2方案实施后

迁移实施过程

迁移实施过程主要经历中间件配置调整、联调测试、投产运行几个环节。

(1)中间件配置调整。原核心数据库从3+1调整1+1后,金桥机房新部署的中间件的数据库连接配置需要作出相应调整,为不同的中间件用户重新分配不同的数据库接入节点。原来接入交易中心一、交易中心二节点的配置改成接入新的交易中心集群中的一个节点,接入账户中心节点的配置改成接入新的交易中心的另外一个节点,接入管理中心节点的配置保持不变。

(2)联调测试。首先是测试数据准备,通过第三方数据库同步软件,将原来3+1架构的数据同步到新的1+1架构中的数据库,在每轮测试之前通过同步软件的全同步功能进行重新同步以获取最新的业务数据,如此可进行多轮反复的测试。测试包括业务功能验证及压力测试。业务功能验证主要由业务部门负责。因压力测试与浪潮K1 Power密切相关,因此我们对压力测试的效果更加关注。压力测试通过Loadrunner工具进行,使用模拟实际业务场景的用例,涵盖用户登录、委托交易、资产查询等12个业务场景,每个场景测试时间为20分钟,测试结果取平均值。其中混合场景为综合多种业务的测试,与生产的实际业务行为最为接近,最具代表性和参考价值,与之前在3+1架构上测试的结果相比,该场景在处理能力上约有80%的提升,总体来说测试效果较好,各场景实际测试结果对比如下:

(3)投产使用。在经过多轮的测试验证之后,系统达到投产运行的条件,投产分两个阶段推进。第一个阶段金桥数据库作为同城备份系统使用,将张江主系统的数据重新同步到新部署的金桥数据库,并保持实时同步的状态,实际运行时间超过三个月,确保长时间的拷机运行,使系统的安全和稳定性得到进一步验证。第二个阶段正式启用为生产主系统,金桥机房成为主中心,而张江机房成为同城备份中心。此阶段各机房间容灾复制的数据流向发生变化,数据从金桥机房反向同步到张江同城备份机房,同时同步到福州异地机房,至此形成新的两地三中心的架构。

实施经验及难点分析

总的来说,架构迁移的整个过程并不复杂,在项目实施中我们比较关注的几个技术环节包括制定硬件配置方案、确定软件版本、安装实施、数据准备、技术培训等。

(1)制定硬件配置方案。为确保整合后的架构在性能上能满足核心系统的需求且不低于之前的性能表现,需要对小型机的CPU、内存、网卡等关键配置一一确认。由于公司此前并没有使用小型机的经历,没有可参考的配置基线,另外由于小型机与x86架构设计上的差异,两者之间的性能高低也不能简单的通过对比CPU个数、内存数量的方式来衡量,直接叠加之前几台x86服务器的硬件资源没有太大意义。因此在项目前期展开了大量的行业调研,调研主要集中在同样使用恒生UF2.0系统的兄弟券商,了解不同规模的券商使用的小型机配置和系统压力,特别是规模与我们相当的券商的使用情况,最后形成了配置的初步方案。在此后的模拟交易的压力测试中,在使用相同数量中间件的情况下,使用此配置方案的1+1架构在性能上比之前的3+1架构有一定程度的提升。由于测试的瓶颈在中间件,小型机的性能最终并未完全体现。即便如此,这样的性能表现也超过了预期的效果。

(2)确定软件版本。软件本身支持不同的硬件平台,所用的软件并不需要改变。为了尽可能减少软件版本差异带来的风险,软件的基础版本号与原来保持一致,仅在补丁级别上做了更新。AIX操作系统选择与软件版本兼容的较新的稳定版本7.2。通过软件原厂商、维保商、以及开发商了解软件+操作系统的版本组合是否存在一些已知的BUG及相关的解决方案,尽量避免以后踩坑。

(3)安装实施。设备的机柜位置都已在项目初期规划好,存储设备、小型机按照预定计划先后上架,并由原厂工程师进行相关的设备初始化配置。需要特别注意的是安装过程中需要的配置信息一定要提前规划好,避免后期修改配置导致返工或者工期延长,比如分区的划分、网口的分配、系统参数的设置等等。虽然绝大部分的内容都可以在安装之后修改,但是这无疑增加了很多时间成本,并且到了项目后期由于应用已经完成部署和调试,任何的改动都需要重新验证和测试,一个小的调整都会牵扯到大量的工作。

(4)数据准备。在项目部署阶段,为了配合应用系统的部署和验证,数据需要从张江机房的数据库实时同步到金桥机房的数据库。容灾复制仍然延续了此前基于数据库层面的同步技术,具体原因不在此讨论。

基于数据库层面的数据同步无外乎物理复制和逻辑复制两种,主流的数据库软件一般都有比较成熟的方案,如Oracle的Data Guard、MySQL的主从复制、SQL Server的AlwaysOn等,或者使用一些第三方的数据同步软件,可以综合平台异构要求、兼容性特点、带宽要求、RTO指标、运维复杂度等因素选择适合的方案。

在此次项目部署阶段,我们需要从原来3+1架构的同步数据到新的1+1架构,实现数据迁移的目标。由于架构内部涉及多对多的同步关系,另外带宽也是考虑的因素之一,因此我们采用了能够实现灵活配置,带宽占用相对较少的第三方数据库同步软件实现数据的实时同步。

(5)技术培训。对于已经用惯了小型机的人开说,培训可能不值得一提了,但是我们作为x86转浪潮K1 Power的亲身经历者,初次接触浪潮K1 Power多少会觉得存在一些神秘感。不管是硬件还是操作系统都与此前熟悉的x86有些不小的差异,为此特别组织了两天针对运维人员的培训,内容从硬件架构到AIX操作系统,从日常运维到故障排查都做了比较系统的介绍和解析。总体感觉,硬件维护相对简单,巡检、报修流程并没有什么特别之处,AIX操作系统与Linux有相通之处,在培训之后也有了相对全面的了解,后续使用也会逐渐适应。

(6)其它工作。主要涉及监控、审计、运维等方面的一些变化。由于引入了AIX操作系统,需要在原来的监控和审计系统里增加对AIX的支持,一些日常的运维脚本也需要做一些操作系统的适配性调整。

总结

最后我想说的是此次核心服务器从x86转浪潮K1 Power的项目,不管从架构设计还是具体实施来说都较为顺利。通过这次项目分享,可以更多的去思考这样一种转型的意义,以及转型能够带来的实际价值。以我之见,一刀切、盲目追求潮流的做法并不能解决所有的问题和困境,只有针对实际的应用场景选择适合的方案,才能真正得到我们期望的结果。

就此次项目来说,使用浪潮K1 Power服务器能够为我们核心数据库带来更高的内在价值,是更贴合我们核心数据库需求的优选方案,也最终使我们在精简架构、提升性能以及稳定运行等方面实现或超过了预期目标。

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

11

添加新评论6 条评论

#湖人总冠军吗售前工程师, 航天信息
2021-01-28 16:30
马克一下
#wykkx系统架构师, 某基金公司
2021-01-27 09:04
传统的IT架构还是会在金融企业有一席之地,毕竟金融企业稳定,安全最重要。只要企业适合才是最好!
#huangyi系统运维工程师, 方正证券
2021-01-22 14:20
power的稳定性是非常好的,仍然是券商的it主流架构。从我们的使用经验上看,power高负载下的稳定性绝非x86可比的,但如果x86都能够承载,或许一体机也是一个不错的选择。
匿名用户
2021-01-21 14:00
以我之见,一刀切、盲目追求潮流的做法并不能解决所有的问题和困境,只有针对实际的应用场景选择适合的方案,才能真正得到我们期望的结果。这个我是非常赞同的!
匿名用户
2021-01-21 13:51
这个方案的确也是新颖的一种,文章从需求出发,介绍之前x86遇到的一些痛点,也给了其他行业和个人一些启发,到介绍浪潮power的一些优势,刚好适应交易系统的场景。其中项目的经验教训和难点分析,给其他人十分明确的路线,避免踩坑。单从趋势来说,x86当前来说还是主流的方向,不过也要根据具体的需求和场景来决定,此文章就给大家介绍了另一种方案并且已落地,两地三中心的架构也成熟实现,能够为其他人提供了多一种的方案选择。
#michael1983技术总监, 某证券
2021-01-20 14:02
1、很佩服兄弟的勇气,从X86迁移到Power平台,带来的不仅是技术层面的挑战(软件版本、OS系统版本、硬件环境、系统架构、跨平台数据同步等),还有人员架构方面的挑战(人员技术栈),更多的是理念上的挑战(从分布式转向大集中,有逆流而上的勇气)。 2、有同业调研、有技术实践,测试充分,准备充足,迁移必然成功。从方案和结果来看,分布式集群还是有其弊端,败给了Power平台的强大可靠性,但要注意一点的是,随着后续业务规模的扩张,E950的升级换代要考虑好。 3、跨平台的数据迁移和同步,没有讲明白,想了解下兄弟用到的是哪种方案。文中所提到的Oracle的Data Guard、MySQL的主从复制、SQL Server的AlwaysOn等,这些好像对操作系统版本、软件版本、数据库版本都是有要求的,跨平台好像无法使用。
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。