In enterprise applications, the configuration of a single computer is usually limited, and enterprise applications have high concurrency requirements. At this time, the number of concurrency will be increased by means of computer clusters, thereby improving the performance of the overall application service. A cluster is a service that uses multiple computers as a whole to provide related applications. FineBI supports cluster deployment of multi-computer services, and utilizes limited computer resources to effectively improve the concurrent performance of the overall application through cluster deployment. This article mainly introduces the idea of the overall FineBI cluster.
FineBI adopts the mode of load balancing cluster to create multiple servers as a cluster server. Here are a few problems: 1) Storage problem of web projects: FineBI needs multiple servers to read the same web project due to its own problems in a cluster. Therefore, it is necessary to realize web project sharing. 2) System data consistency: During the operation of FineBI, there are read and write operations, and some data configuration files need to be written to the database. It is necessary to ensure the consistency of system data in the case of clusters. 3) Load balancing: On the one hand, load balancing is used to deal with the problem of sessions, and on the other hand, a cluster environment with load balancing can be achieved. The proxy server can forward the request to the server inside the cluster, and the cache technology of load balancing and proxy server can be used. combined to provide beneficial properties. 4) FS platform cluster: If FineBI uses the FS platform, the various configurations of the FS platform also need to be clustered.
The following figure is a schematic diagram of a case where FineBI enters the architecture, which handles web projects through NFS file sharing.
Web project storage problem
For the storage of web projects, what we need to solve is that multiple servers ensure that the same web project is read. We can achieve multiple physical hard disk components and one logical hard disk through ceph, so that all nodes are accessing the same address; we can also use the nfs shared file service that linux itself has to achieve access to the same web project. No matter which method is used, we want to ensure that:
<!--[if !supportLists]-->1) <!--[endif]--> Access the same web project
<!--[if !supportLists]-->2) <!--[endif]-->Cube storage addresses are consistent
Because under the same web project, the storage address of the cube is required to be the same, so the storage address of the cube must be the same.
When it is actually used, the implementation of ceph requires at least three computers to implement, and in actual enterprise applications, three are rarely used; and nfs can be used and is Linux itself, so the "nfs" scheme is used.
System data configuration
In the case of a single node, the use of cache and the way of saving data through the operating system's file system is no longer suitable in cluster mode. The main reason is the consistency of data. Multiple nodes may read and write at the same time, changing system data, which will eventually cause overall data inconsistency. The best solution is to hand over all system configuration data to relational databases such as MySQL for management. However, due to the large amount of engineering, the main reason is that many codes are lack of maintenance, and rash changes may bring unexpected bugs. So we take a compromise approach. Select a point in the cluster as the master node, referred to as M. The rest of the nodes act as child nodes, referred to as S. When all operations related to changing the system configuration on S are sent to M for processing. M is responsible for changing the state of the system and maintaining the consistent state of the entire system. Node S gives up all cached data, and when reading the status, it no longer reads its own data, but sends a read request to M to obtain the data on M. The M node itself may have cached data. Other data S nodes are equivalent to M nodes, and there is no affiliation.
因此按上述原由我们提供如下解决方案：
<!--[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平台的所有操作都是发到主节点上来操作；子节点只是作计算服务器。