【摘要】本文介绍了某银行权益类系统如何基于信创数据库、信创虚拟化、信创容器云、全闪SAN存储等技术实现Oracle替换。在面临性能、可用性和可扩展性挑战的背景下,该系统通过迁移至信创容器云服务、采用TDSQL分布式数据库等措施实现了全面升级优化。通过基于专业存储的存算分离架构, 微服务架构、多副本部署、灵活的流量切换方案以及高可用部署方案,系统提升了性能、容灾能力和服务能力。同时,文中还介绍了Oracle迁移到TDSQL的工具和方法,以及系统升级改造的挑战和解决方案。这些举措将有助于提高系统的稳定性和可靠性,推动银行业务的数字化发展。
一、背景说明
二、系统原架构和痛点分析
该系统原基于Intel X86非信创虚拟机进行部署,数据库采用Oracle Data Guard(DG)架构,未采用分库分表的策略,操作系统为RHEL,应用为行内开发平台的单体架构,且数据库和应用均只部署在一个机房中。这导致系统在后期的业务经营发展中面临较大的性能、可用性以及可扩展性的挑战。
随着业务的扩展和账户数据量的不断增加,数据库的负载逐渐加重。这种集中式存储方式会导致数据库的I/O性能和处理能力容易达到一定瓶颈,随着业务的快速发展与扩展,系统交易量提升,业务数据膨胀,进而引发一系列性能问题。如实时查询速度明显减缓,批量处理时间显著延长,系统在进行大规模数据处理时效率低下,可能会导致批量数据产出延迟,通过增加系统资源也并没有较好的性能表现。
另外由于数据库和应用程序均部署在同一机房内,这种方式带来了单点故障风险。一旦机房内的硬件设备出现严重故障,或者网络出现问题,整个系统可能会立即停摆,导致系统整体不可用。这种情况对业务运营带来严重的影响,甚至可能导致数据丢失和业务中断。
当迫于上述二者的压力,需要对系统进行扩容时,该系统架构下扩容方案复杂、成本较高。
三、容灾方案架构图
四、容灾流量切换方案
健康探测是流量切换的主要抓手。
DNS和F5均提供了灵活的探测策略和流量分发策略,可根据项目具体需要进行评估选择,其中探活策略有IP层探活、端口层探活、自定义应用级探活等。流量分发策略有热备、百分比配置(如两个解析目标地址流量配置为1:1,则解析目标地址均存活时,流量按1:1向两个解析目标地址分发,当某个解析目标地址不存活时,流量解析到其他存活的目标地址)等。我们在DNS上配置了到云应用和TDSQL数据库在F5上IP的到端口级别的探活,在F5上配置了到应用和数据库PROXY的探活。当F5到应用的探活失败时,DNS到F5的探活亦失败,此时流量发生切换。同时,在不同地理位置部署DNS 服务器,确保 DNS 服务在任何单点故障的情况下仍能正常运行。
云内应用的流量控制由Ingress、Service控制,策略可自定义,通常为轮询,将请求均匀分发给多个Pods。微服务多副本以及注册中心等保证应用集群可用性,避免任一应用节点故障带来应用使用影响。
五、应用的高可用部署方案
六、TDSQL部署架构图及高可用方案及性能优化实践
在当今数字化转型浪潮中,数据库作为支撑业务运行的核心基础设施,其架构设计显得尤为重要。TDSQL作为一款高性能、高可用、可扩展的分布式数据库系统,其架构设计遵循了分布式和存储计算分离的设计理念,主要由计算节点(proxy)+存储节点(DB)+管理调度节点(zookeeper等)等组成。
核心的架构设计如上图所示:计算节点Proxy负责SQL解析、转写、分发、鉴权、结果聚合、结果过滤和读写分离等功能,在主数据中心和同城数据中心分别安排了两台Proxy组成集群,Proxy集群内节点无状态,作为接入层对外提供计算能力;存储节点DB负责数据的存储和管理,主数据中心和同城数据中心的多台DB服务器共同组成数据库资源池;调度节点zookeeper负责集群的高一致和可用性管理,采用“2+2+1”架构,即主数据中心2台+同城数据中心2台+灾备数据中心1台(仲裁),确保在单机房故障情况下Tdsql集群仍能正常工作;另有scheduler/manager负责资源调度,chitu/oss提供页面和接口服务,旁路模块nfs负责备份,DBbridge负责数据迁移等。
下图为基础架构图,在采用存算分离理念的架构设计中,Proxy、DB、Zookeeper等服务器的部署可以更加灵活地配置,以实现计算资源与存储资源的独立管理和优化。其总体架构分为计算资源层和存储资源层。
计算资源层使用物理服务器作为计算节点,采用FusionCompute集群作为虚拟化计算资源的统一管理平台,承载Proxy、Zookeeper等服务器的虚拟机实例,DB节点则直接部署在物理服务器上。在存储资源层,采用华为OceanStor Dorado 全闪SAN存储系统作为独立的存储资源,为所有需要持久化存储的服务(包括虚拟机镜像、数据库数据等)提供高性能、高可靠的存储服务。存储资源与计算资源完全解耦,通过网络连接进行数据的读写操作,实现计算资源和存储资源的独立优化和高效利用提高了系统的灵活性、可扩展性。
在该架构模式下,TDSQL集群展现出了卓越的容错和容灾能力。该架构的核心在于设计了模块间的独立性与冗余机制,确保在模块级别出现突发故障时TDSQL集群的平稳运行,几乎不会对其对外提供服务的能力造成实质性影响;更进一步,该架构设计还考虑了更为极端的情况,即机房级别的故障容灾,即在面临如供电异常、自然灾害等导致整个机房故障的情况下,TDSQL集群依然能够迅速且自动地切换至正常机房,以保证对外服务的连续性和稳定性,进一步提升了集群的可靠性和用户体验。
接下来,我们将一一介绍该架构是如何实现上述的容错与容灾能力的:
1.计算节点故障:Proxy作为无状态的接入层组件,任何一台Proxy服务器都能独立地对外提供计算服务,无需依赖特定状态信息。为了增强系统的可靠性和容错能力,每个机房均配置了两台Proxy服务器,并通过F5负载均衡器进行流量分发。某一机房单台proxy发生故障时,通过F5探活,可很快将故障Proxy踢出;多台Proxy服务器故障时,业务系统也可通过网络设备连接至仍存活的Proxy,最高可支持3台proxy故障;当某一机房内的单台Proxy服务器发生故障时,被F5负载均衡器健康检查机制检测到,F5会迅速将该故障的Proxy服务器从服务列表中移除,确保用户请求被自动转发至其他健康的Proxy服务器,从而实现无缝的故障转移,最小化对业务连续性的影响;在极端情况下,若多个Proxy服务器同时发生故障,业务系统能够识别并连接到尚存活的Proxy服务器,继续提供服务,此机制支持最多三台Proxy服务器同时故障而不影响整体服务的可用性。
2.存储节点故障:数据库DB实例采用了一主三备架构,以确保数据的可靠性和服务的连续性。具体而言,主实例与跨数据中心的一个备实例间采用强同步复制技术,与同数据中心的备实例和跨数据中心的另一个备实例之间则采用异步复制技术。当单台DB服务器发生故障时,若其上只运行有备实例,则由于备实例基本不参与对外服务,对整体服务无影响;若其上运行有主实例,则由Zookeeper根据数据一致性第一原则和同IDC备实例优先切换原则自动从剩余的备实例中选举出新的主实例,更新路由表并告知所有的Proxy服务器,这样Proxy服务器就能根据新的路由信息将请求转发至新的主实例,确保数据的一致性和服务的快速恢复,整个故障检测、主备切换和路由更新过程中,RPO=0,RTO<40s。
3.调度节点故障:Zookeeper集群任一Follow节点故障,不影响Zookeeper集群的仲裁决策能力;Leader节点发生故障,则触发Zookeeper集群自动选举机制,由至少三个节点重新选举出新的Leader节点;确保Zookeeper集群在面对故障时能够迅速恢复并继续稳定运行。
4.其他模块故障:其他模块故障不影响业务可用性。
5.机房级故障:以主数据中心故障为例,在主机房全面故障的情况下,由同城数据中心的两台Zookeeper节点和灾备数据中心的Zookeeper节点共同参与,通过选举算法选举出新的Leader节点,确保集群的元数据管理和服务协调功能迅速恢复;然后同城数据中心的备实例在Zookeeper Leader节点主持下依据预设原则选举出新的主实例,已有的主实例保持不变;主实例选举完成后,Zookeeper集群更新路由表并告知所有存活的Proxy,Proxy服务器根据新的路由信息将请求转发至新的主实例;至此整个数据中心的切换完成,RPO=0,RTO<40s,确保了数据库服务的高可用性和连续性。
七、Oracle迁移到TDSQL的工具和方法
Oracle数据到TDSQL的迁移有多种方式,我们主要评估了使用文件形式数据卸载装载和使用KETTLE工具这两个方式。评估的着眼点在于,1.海量业务,2.业务连续性,3.对运行生产系统的影响。基于这三点,我们最终选择了KETTLE工具进行数据迁移。
迁移分为存量迁移和增量迁移两部分。存量迁移:定义某个时间点前的业务数据,如2024年9月30日(含)前的业务数据进行迁移;增量迁移:存量时间后的业务数据和数据量较小的系统表。存量迁移可以是个长期的过程,比如系统切换前一天或者一周,持续进行。增量迁移是在存量迁移完成后,系统切换停机时短时间内执行完成。
在KETTLE工具中,可自定义执行任务,通过控制任务分段大小,控制任务执行时间,减少读操作对源系统的影响,减少写对目标数据库的影响。
八、总结
本次系统升级是一个较为复杂的工程,综合应用了云计算、大数据、信创技术以及分布式技术等多种技术栈。前后也经历了很多挫折,通过项目组专家和同事的共同努力,逐个进行技术验证,问题分析,最终实现系统顺利上线运行。本次的系统升级改造,很好提升了系统性能、容灾能力和服务能力,有助于大幅提升相关业务的竞争力,推动我行技术创新发展,在符合国家信创要求的同时也为未来的发展奠定坚实基础。
参与协同同行专家:
万里鹏 -某银行单位
于洋-某银行单位
王新宇-某银行单位
吴盛哲-某银行单位
阳文灿-某银行单位
黄庆-某金融单位
专业审核:
董生 某大型银行 数据库架构师
如有任何问题,可点击文末阅读原文,到社区原文下评论交流
觉得本文有用,请转发或点击在看,让更多同行看到
资料/文章推荐:
欢迎关注社区以下 “数据库”技术主题 ,将会不断更新优质资料、文章。地址:https://www.talkwithtrend.com/Topic/597
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点,不代表社区立场