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

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

        经过一年多的数据库双活技术研究与验证以及基础设施改造，民生银行于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成员，并配置了客户端自动重路由。

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

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

        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数据库同城双活领域走在了国内银行业的前列，也为同业银行提供了可资参考的成功范例。

（文章来源：《金融电子化》杂志）

扫码即可手机
阅读转发此文