投研网 首页 金融大数据 案例 查看内容
0

数据库同城双活确保业务连续性

jonyao 2015-12-15 17:29503 人围观 原作者: 中国民生银行科技开发部生产运营部 袁春光 朱彬 王鹏 来自: 民生银行、数据库双活、业务持续性

简介 :民生银行对选定的业务系统做了大量的功能和性能测试,对数据库技术和硬件做了大量极限和破坏性测试。测试结果表明DB2 GDPC技术完全能够满足当前选定业务系统对数据库双活的要求。 信息系统与信息科技是保障银行业 ...
民生银行对选定的业务系统做了大量的功能和性能测试,对数据库技术和硬件做了大量极限和破坏性测试。测试结果表明DB2 GDPC技术完全能够满足当前选定业务系统对数据库双活的要求。

信息系统与信息科技是保障银行业务持续运营的重要基础。商业银行应当建立相应的业务连续性管理体系,确保重要业务在运营中断事件发生后快速恢复,降低或消除因重要业务运营中断造成的影响和损失,保障业务持续运营。在此要求下,银行数据中心的“两地三中心”建设成为当前银行保障业务连续性目标的重要手段,民生银行也为此投入大量人力和财力进行探索与实践。

        经过一年多的数据库双活技术研究与验证以及基础设施改造,民生银行于2015年5月在北京建设完成了数据库同城双中心双活环境。不同于传统的主运行中心与备份运行中心的模式,民生银行真正实现了对等的双中心双活,解决了传统主备中心模式中备份设备的使用率很低、灾难发生时业务从主运行中心切换至备份运行中心RTO较长等问题,单个数据中心发生故障也无需业务切换,真正实现了业务的连续可用。在关键的数据库双活技术上,我行经过深入的技术验证,最终选择了IBM DB2开放平台上的GDPC技术。民生银行的GDPC环境主要有以下特点:第一,采用了完整的GDPC配置,双中心无主次之分,实现了真正意义的“双活”;第二,在国内首次采用了最新的万兆以太网环境下的RoCE技术,抛弃了限制很大、成本较高的Infiniband技术,降低了建设成本;第三,解决了若干影响性能的关键问题,最大程度地降低70公里地理分离带来的影响;第四,对于业务系统完全透明,应用程序不需做任何改造。

一、民生银行数据库双活架构

        民生银行科技开发部于2014年3月启动数据库双活的建设工作,首先在测试环境搭建了完整的GDPC数据库双活环境,至2014年12月完成相关的测试和验证工作。期间对选定的业务系统做了大量的功能和性能测试,对数据库技术和硬件做了大量极限和破坏性测试。测试结果表明DB2 GDPC技术完全能够满足当前选定业务系统对数据库双活的要求。

        民生银行在北京有位于顺义区的马坡机房和酒仙桥机房,光纤距离70公里。两个机房分别部署两个pureScale成员和一个集群高速缓存设施(CF)。硬件使用lBM P750小型机,操作系统版本目前是最新的AIX 7.1 SP3 TL4。每个pureScale成员和CF都分配一个独立的LPAR。DB2版本采用的也是目前最新的DB2 10.5 fixpack5。SAN存储设备使用的是支持SCSI-3 PR的EMC VMAX存储,两个站点之间SAN网络互通,并配置了GPFS同步复制。在应用服务器方面,一共有4个Weblogic服务器,分别部署在两个机房,每个Weblogic服务器分别连接一个pureScale成员,并配置了客户端自动重路由。

图片6.jpg
图一 民生银行数据库双活实践物理架构

二、关键技术方案的选择与问题解决

        1.完整GDPC配置,双中心并重

        DB2 pureScale集群中有两个或者多个pureScale成员,两个CF。每个pureScale成员独立运行对外提供服务,但都需要与CF进行交互:两个CF互为主备,同一时间只有一个CF与pureScale成员交互,此时另一个CF作为备CF与主CF保持实时同步,当主CF出现故障可以在极短的时间内接替主CF,因此主备CF机制是保证pureScale集群连续可用的关键配置。同时,DB2从技术上也支持pureScale集群只有一个CF的配置,pureScale集群可以正常运行,但这种配置无法避免单点故障(SPOF)。

        两个站点之间70公里的距离给数据库的性能带来了巨大挑战,即使用光速走过这个距离单程也需要0.35毫秒。站点之间必须使用高速互连,以便在站点间的pureScale成员与主备CF之间的消息能够尽可能快并且开销尽可能小地传输。但即使是有了支持RDMA的高速互连,GDPC环境中一次消息交互要比普通pureScale集群中的多0.7毫秒的延迟,这会明显影响业务系统的响应时间和数据库系统性能。在具体实践中,某银行将双CF放在同一站点,并且只有一个主CF运行,另一个备用CF平时不活动也不与主CF同步,仅在主CF所在服务器故障时接入集群。这种方式减少了与CF之间的交互,提高了数据库性能,但是在CF发生故障时需要做集群的整体恢复,业务中断时间相对长。

        民生银行在GDPC数据库双活的实践中,通过性能压力测试观察到,只有一个CF的配置比两个CF的配置,TPS高10%以上,响应时间也更短。但是经过综合考虑,最终决定保留两个CF的配置,充分利用GDPC的优势保证业务的连续性。

        在GDPC架构中,与主CF位于同一个站点的pureScale成员,其与CF交互时不需要跨越站点之间的70公里距离,因此这些pureScale成员的响应时间更快。基于这个原因,在一些银行或者其他行业的双活实践中,他们从业务系统的层面对工作负载进行区分,针对性地将一部分工作负载指定到主CF所在的站点。这种方式能够带来一定优势,但需要对业务系统进行一定的改造,增加了建设成本,还限制了业务系统的适用性。民生银行在双活的架构中,对选定的业务系统没有做任何改造,只是在Weblogic服务器的连接池配置中修改了数据库服务器IP地址和服务端口。外部业务系统发来的请求通过F5机制平均分配到4个Weblogic服务器,每个Weblogic服务器分别连接一个pureScale成员。也就是说,民生银行实现的是真正完整的GDPC同城双活。

        2.高速互联方式选择:RoCE还是Infiniband?

        民生银行在高速互连的方式上进行了充分验证和慎重选择。在DB2 10.5 FP4(Cancun)版本之前,DB2 GDPC只支持Infiniband方式。这种方式支持RDMA协议,最高带宽可以达到40Gb/s,但需要专用的网络设备(如Mellanox QDR Infiniband网卡)、专用的线缆以及专用的Infiniband交换机。在DB2 10.5 FP4中,GDPC:开始支持RoCE(RDMA over converged Ethernet,RDMA基于融合以太网)方式。这种方式同样支持RDMA,带宽可以达到10Gb/s,需要专用的网卡(如Mellanox RoCE网卡),但不需要专用的线缆和交换机,它可以使用通用的万兆以太网交换机。经过验证比对,RoCE方式的数据库吞吐量与Infiniband方式比较接近。

        另外需要考虑的是,无论哪种方式,其有效的跨越距离都是有限的,Infiniband只有数十米或者数百米,RoCE在1公里以上时光纤通信衰弱也比较明显,因此还需要其他设备的支持来跨越这70公里的距离。Infiniband方式可以采用Obsidian Longbow Infiniband扩展器之类的设备,RoCE方式可以采用DWDM设备(Dense Wavelength Division Multiplexing,密集型光波复用)。

        另外,在扩展性上RoCE方式比Infiniband更有优势,例如在IBM小型机p750上可以接多个RoCE网卡供多个LPAR使用,而Infiniband网卡插槽则非常有限。同时考虑到目前国内采购Infiniband设备的渠道非常受限且缺少后续的维护和技术支持,而RoCE方式对设备依赖较少,最终民生银行选择了RoCE方式。这也是国内首次在GDPC二环境采用RoCE方式。

        3.热点数据问题

        热点数据的争用是数据库系统中的一个常见问题,在GDPC环境中由于地理分离的特殊性,这一问题可能会更加复杂,对数据库性能的影响也更加严重。IBM DB2开发实验室官方建议中提到,当业务应用中写操作占整个工作负载20%以上时,GDPC两个站点间距离不建议超过30公里。民生银行在压力测试过程中遇到了这一问题,选定的业务系统需要频繁向若干数据表中插入数据并随后进行查询,这可能导致两个或者多个pureScale成员同时向一个数据页(即数据库存储单元,一个数据页可以存放多条数据)中插入数据。这个数据页需要不断从一个DureScale成员的本地缓;中池(LBP)发送到CF的全局缓冲池((3BP)中,再从CF的全局缓冲池发送到另一个pureScaIe成员的本地缓冲池,而且当需要查询之前插入的数据时,这个数据页可能被另一个pureScale成员修改过,这时也需要从CF的全局缓冲池中获取。这个过程本身是一个保证事务一致性的正常处理机制,但在GDPC环境中,一半的pureScale成员与主CF不在同一个站点,每次数据页的传输都需要跨越70公里的距离。同时由于主备CF分别位于两个站点且需要进行实时同步,因此这种现象发生时数据页需要多次跨过70公里进行站点间的传输。这可能会延长响应时间,加剧latch竞争和锁等待,从而严重影响数据库系统性能。

        为解决这一问题,民生银行科技开发部人员创新性利用DB2的分区表功能结合pureScale中CURRENT MEMBER 变量,将热点表修改为基于pureScale成员编号进行分区的分区表,并配合使用分区索引,使得每个pureScale成员只访问特定的若干个数据分区。例如,在热点数据表上以(MOD(ID,10)+MOD(CURMEM,4)×1 0))增加隐藏列并以此作为分区键进行分区,这样pureScale成员0处理和访问的数据都集中在数据分区0~9,成员1的数据集中在数据分区10~19,以此类推。有了这一解决方案,一个pureScale成员向数据页插入一行数据后,当它再次查询时这个数据页还在自己的本地缓冲池中并且是有效的,而不需要从CF全局缓冲池获取,也不会有其他成员争抢这个数据页,很大程度地减少数据页在pureScale成员之间以及与CF之间的传输,从而减少响应时间,避免latch竞争,提高数据库系统性能。

        此外,民生银行科技部技术人员在GDPC实践中通过解决一系列问题,不断提高技术水平。例如在分析AIX版本升级之后发生的添加pureScale成员失败问题时,科技部技术人员深入研究了DB2 pureScale技术,以及底层的IBM RSCT(Reliable Scalable Cluster Technology)集群技术,IBM TSA(Tivoi System Automation)集群技术;在合理选择HostFailureDetectionTime参数值时,发现这个参数修改之后DB2会在内部联动修改GPFS的三个参数(failureDetectionTime,leaseRecoveryWait,totalPingTimeout),同时研究了GPFS集群文件系统技术。最终总结了一整套的最佳实践,包括合理选择操作系统版本、基础集群软件RSCT版本、各种参数的合理配置、使用大对象内连(LOB Inline)以及压缩技术、合理增大序列(sequence)的cache大小等。

三、实践结果与总结

        民生银行数据库同城双活完全自主建设,除了硬件投入,无其他额外投入,所有建设工作由民生银行科技部技术人员自主完成,科技部技术水平得到了提升。

        民生银行对GDPC环境进行了完整的功能性测试和异常场景测试,包括单个站点故障、站点间链路完全中断故障等,所有测试均顺利通过。在性能方面,对于选定的业务系统得出了2200 TPS(每秒交易数)和49000 QPS(每秒执行语句数)的性能指标。2015年5月,民生银行第一个采用数据库同城双活的业务应用——计费系统成功上线,双中心同时对其他业务系统提供服务。这标志着民生银行业务连续性水平提高到一个更高层次,在DB2数据库同城双活领域走在了国内银行业的前列,也为同业银行提供了可资参考的成功范例。

(文章来源:《金融电子化》杂志)

收藏 邀请
鲜花
鲜花
握手
握手
雷人
雷人
路过
路过
鸡蛋
鸡蛋
返回顶部