Linux之FineBI集群部署

在企业应用中，通常单个计算机的配置是有限的，而企业应用又是高并发的需求，这个时候会通过计算机集群的方式来提高并发数，从而提高整体应用服务的性能。集群是将多台计算机作为一个整体来提供相关应用的服务。FineBI支持多计算机服务的集群部署，通过集群部署利用有限的计算机资源来有效提高整体应用的并发性能。本文主要介绍整体FineBI集群的思路。

FineBI采用负载均衡集群的模式，将多台服务器创建为一个集群服务器。这里碰到这几个问题：1）web工程的存储问题：FineBI在集群中，由于自身的问题需要多台服务器读取同一个web工程。因此要实现web工程分享。2）系统数据一致性：在FineBI的运行过程中，存在读写的操作，同时有部分的数据的配置文件要写入数据库。需要保证集群的情况下，系统数据的一致性。3）负载均衡：一方面通过负载均衡来处理session的问题，另一方面达成负载均衡的集群环境，使用代理服务器可以将请求转发给集群内部的服务器，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能。4）FS平台集群：如FineBI使用FS平台，则FS平台的各种配置也需要进行集群配置。

如下图是一个FineBI进去的架构的案例示意图，这种方式通过NFS文件共享来处理web工程。

 

Web工程存储问题

Web工程的存储，我们要解决的是多个服务器保证读取同一个web工程。我们可以通过ceph做到多块物理硬盘组件一块逻辑硬盘，从而实现所有节点都是在访问同一地址；也可以通过linux本身带有的nfs共享文件服务来达成访问同一web工程。无论使用哪一种方式，我们要保证：

<!--[if !supportLists]-->1）<!--[endif]-->访问同一web工程

<!--[if !supportLists]-->2）<!--[endif]-->Cube存储地址是一致的

因为同一个web工程下，要求cube的存储地址是一致的，因此要求cube存储地址一定要一样。

而真正使用的时候，ceph的实现需要至少三台计算机来实现，而实际企业应用中，比较少使用三台；而nfs均可以且是linux本身的，因此使用“nfs”方案。

系统数据配置

单节点的情况下，利用缓存和通过操作系统的文件系统来保存数据的方式，在集群模式下不再合适。主要原因在于数据的一致性问题，多个节点可能进行同时读写，更改系统数据，最终势必会造成整体数据不一致。最好的解决方案是系统配置数据全部交给MySQL等关系型数据库来管理。但由于这样工程量好大，更主要的原因为许多代码缺少维护，贸然更改可能带来意想不到的bug。于是我们采用一种折中的做法。在集群中选出一台几点作为主节点，简称M。其余节点担当子节点，简称S。当S上所有与更改系统配置相关的操作，全部发送到M上进行处理。M负责来更改系统状态，维护整个系统到底一致的状态。S节点放弃全部的缓存数据，读取状态的时候，不再通过读取自身数据，而是通过向M发送读取请求，获得M上的数据。M节点自身可以存在缓存数据。其他数据S节点与M节点时等同的，不存在从属关系。

 

因此按上述原由我们提供如下解决方案：

<!--[if !supportLists]-->1）<!--[endif]-->mysql数据库：原web工程中存在finedb的配置信息转存到mysql数据库中。因为finedb数据库只能有一个连接，无法多节点同时读取，而mysql数据库则不存在。Logdb也需迁移；

<!--[if !supportLists]-->2）<!--[endif]-->主子节点：我们使用主子节点的方式来配置集群，系统数据的更改均在主节点上进行，子节点只读取主节点上的数据；

<!--[if !supportLists]-->3）<!--[endif]-->Zookeeper：为了保证读写情况下，主子节点保证数据一致性，还需要zookeeper进行通信，充当文件锁的功能。

负载均衡

在FineBI的集群环境中，我们可以使用任何支持负载均衡的服务器来完成轮发的任务，并保证session粘滞。此处我们使用的是nginx反向代理，使用IP标识轮发，保证同一个用户在同一个session。（在一个服务器一个节点的情况下，同一个IP就保证session粘滞）。

FS平台集群

使用FS平台集群插件，将FS平台配置能够满足集群需求。在FS平台集群中，FS平台的所有操作都是发到主节点上来操作；子节点只是作计算服务器。