某银行ESB系统文件系统迁移满足企业业务连续性需求

一.背景介绍

某银行ESB系统（企业服务总线），承载着前置类系统与后台账务系统的对接工作，一旦瘫痪则会导致大部分业务无法正常运行。该系统原有架构为两台小型机通过共享存储组成的HA热备集群，一旦服务器宕机，则会切换。但由于应用程序会将系统间交互的报文以文件的方式存放，导致该系统中存放的文件数量过多，一旦发生切换，切换时间耗时较长（通常在1-2个小时左右），无法满足业务连续性的要求。

二、产品选型

为了解决这些问题，需要对原有架构进行改造，目标是将现有HA热备集群改造为多活集群架构，当发生故障时避免发生切换，并且能够充分利用多台服务器的资源。

由于应用程序的特点，该系统改造过程的主要难点在于各个服务器需要能够同时读写这些文件，为了满足此要求，需要采用分布式文件系统或共享文件系统来替换原有文件系统。目前市面上常见的分布式文件系统主要有HDFS，Spectrum Scale（GFS），Ceph等，但其中部分是开源产品，稳定性较差且产品后期维护的成本较高，因此还是偏向于考虑商业性产品对比，基于以下几方面的考虑，最终选定的是Spectrum Scale（GFS）：

1.原有应用运行在IBM的小型机上，SpectrumScale（GFS）的兼容性更好

2.SpectrumScale（GFS）的性能相对较好，且该系统中存在大量文件，分布式文件系统在此场景下性能不佳

3.开源产品维护成本较大

三、架构设计及实施过程

为避免2台服务器宕机导致整个集群不可用，在设计上考虑采用选择3台服务器+2块仲裁盘的架构，这样的好处是即使任意两台服务器宕机，还能够保证服务对外可用。

此外由于该系统文件个数较多，因此对以下参数进行优化，避免Spectrum Scale（GFS）带来的性能负面影响：

Spectrum Scale（GFS）缓冲区大小：mmchconfig pagepool=2G -i -Nall

并发线程数量（需重启GPFS）mmchconfigworker1Threads=128 -i -N all

单节点最大吞吐量限制：mmchconfig maxMBpS=2048 -i -Nall

最大及最小NSD线程：mmchconfignsdMaxWorkerThreads=3072 -i -N all

mmchconfig nsdMinWorkerThreads=3072-i -N all

文件系统小文件比例：mmchconfignsdSmallThreadRatio=9 -i -N all

每个队列分配的nsd线程数量：mmchconfignsdThreadsPerQueue=16 -i -N all

四、迁移后效果

迁移后性能与迁移前几乎无变化，服务器宕机直接通过负载均衡设备进行分发，无需进行切换，满足最初预期。