反馈已提交
网络繁忙
Cluster is a grouping of several identical projects to provide the same service, and these individual projects are the nodes of the cluster. Based on the horizontal scalability of the cluster, users can increase the number of nodes to make the concurrency tends to linear growth, so as to obtain a higher concurrency support performance.
It is also possible to use multiple projects as backups to avoid losses (business interruption, data/template loss) caused by system stoppage due to single machine unavailability, and to ensure stable system operation 7*24h.
Video Link: [Introduction to Cluster Principle]
As shown in the following figure.
1) High Availability
In hostless mode, the cluster system can still provide normal services after a node is down.
After a node is down, it automatically switches to other nodes, and logged-in users do not need to log in again.
2) High concurrency
The server responds to multiple requests at the same point in time. For example, if request A exists at 11:01:00 and the server finishes processing at 11:01:03, if request B is added at 11:01:02 and request C is added at 11:01:04, the concurrency is 2 (request B and request C).
The higher the number of nodes, the higher the concurrency supported. Since the concurrency is based on the actual business scenario of the user, viewing the template and making the template, the server resources occupied are not the same. So the actual number of concurrent server resources is related to business usage, and requires Fanruan's professional performance testing, combined with the actual network environment, file read and write efficiency, database concurrency performance and other factors to derive the actual size of concurrency that can be supported.
Concurrency and container has no relationship, such as Tomcat, WebLogic, WebSphere container, concurrency difference is not large.
3) High consistency
The platform configuration information and resource file modification updates between nodes can be synchronized in real time.
For the inconsistency of JAR packages between nodes, the comparison can be automatically detected and alerted at startup.
4)Strong scalability
Based on a good architectural design, the Web cluster has good horizontal scalability, and the concurrency tends to grow linearly by increasing the number of nodes, so as to obtain high concurrency support performance.
5) Easy to use
Simple visual configuration, 80% of the configuration can be done on the platform.
Support hot deployment, add and delete nodes without restarting the cluster, just copy the node files.
Real-time monitoring of the operational status of each node, for node downtime, inconsistent time between nodes and other situations can be timely alert.
Fanruan Cluster solution supports both Windows and Linux systems. However, considering the stability and performance, Linux is recommended as the server operating system. The following is a brief comparison of Linux as a server operating system.
1) Stability
Linux systems have excellent stability, and most hardware and configuration updates do not require a reboot.
The Linux system has a lower downtime rate compared to the Windows system, and often does not need to be shut down for a year.
2) Performance Advantages
Linux systems handle multi-threading much better than Windows, and are truly multi-user and multi-threaded, while Windows is single-user and pseudo-multi-threaded.
Linux systems do not have the same graphical interface as Windows systems, so they take up fewer resources and perform better.
The memory management and scheduling is excellent and makes efficient use of all hardware resources.
But the most critical factor that affects which system we end up with is the ability to operate and maintain the system.
Note: For a detailed comparison of Linux and Windows systems, seeLinux and Windows system comparison analysis
Load balancing is divided into software load balancing and hardware load balancing, the core role of both load balancing is the same, load balancing as the entrance to the cluster, to play the role of request distribution and node health check.
Note: Apache load balancing is not supported.
Hardware load balancing is very stable and has relatively good performance, but the cost is also high, the most commonly used load balancing is F5. If your company has hardware load balancing and has good configuration and operation and maintenance capability, you can choose to use hardware load balancing after confirming that hardware load balancing has active health check function.
A brief introduction to the advantages and disadvantages of hardware load balancing.
Pros: It can be achieved directly through the intelligent switch, and is independent of the system, with strong load performance; powerful, supports load balancing at all levels, and supports various load balancing algorithms; adapts to large access volume, and is simple to use.
Cons: high cost, high price of equipment; poor scalability, can not be extended and customized; can not effectively master the server and application status.
Usage documentation:Load Balancing Configuration Guide
A brief description of the advantages and disadvantages of software load balancing.
Pros: System and application based load balancing can better distribute the load according to the status of the system and application. In fact, if there are only a few servers, using hardware products such as F5 is obviously a waste, while using software is much more cost-effective, because the server can also run applications to do clustering (although not recommended), or only provide general configuration of the server to load balancing applications.
Cons: The load capacity will be affected by the performance of the server itself.
There are two kinds of software load balancing officially verified by Fanruan: Traefik and Nginx, both of which are open source software, with stable update frequency and maintenance efforts.
Nginx has very good concurrency performance on Linux systems, and uses very little memory. It is used by many large companies, and its stability and performance are well-proven. However, Nginx does not support high concurrency on Windows systems, so if you choose Nginx as a load balancer on Windows systems, you need to consider the concurrency situation.
If you want to have high availability at the Nginx level to avoid single points of failure, then you can do a Keepalived+Nginx solution to ensure that if an Nginx service goes down or is abnormal, there is a backup Nginx service that can take over.
Documentation: Installing and Configuring Nginx on Linux, Installing and Configuring Nginx on Windows, Keepalived+Nginx Deployment Scenarios
Traefik is a single executable written in Go that requires no installation and can be executed from the command line, making it very easy to deploy and use for users with low O&M requirements. Compared to Nginx, there are two major advantages.
Good performance on Windows systems, so Traefik is recommended for Windows systems.
Support for automated update of reverse proxy and load balancing configurations.
Documentation: Traefik installation and configuration for windows systems
The performance and stability of Nginx on Linux and Traefik on Windows have been tested and verified by Fanruan. Theoretically, Traefik also has better performance on Linux, but in order to avoid the complexity of the solution and to consider the maintenance cost, the performance and stability of Traefik on Linux has not been fully verified.
In general, Nginx is recommended for load balancing on Linux systems, while Traefik is not recommended for Windows systems.
A Web container is a service program, a software that supports the distribution of Web programs. There is a program that provides the corresponding service on one port of the server, and this program is the one that handles the requests from the client.
Conventional recommendations: Tomcat container, WebLogic container, WebSphere container.
The Fanruan clustering solution uses Redis to implement the state server. There are three common Redis solutions: Redis Standalone, Redis Cluster, and Redis Sentinel, and here is an introduction to how to choose between them.
If your company already has a Redis service, you can use it directly, regardless of which one is below, which reduces the cost of maintaining an additional application, but if there is no Redis service, we have to install a new Redis service in order to use the cluster.
Redis standalone refers to the deployment of only one Redis application, which is simple to deploy, has low maintenance costs, and ensures the availability of the cluster.
Documentation: Installing and Configuring Standalone Redis on Linux Systems
If high availability is required for a system/solution and you want to avoid a single point of failure, then a Redis cluster can be a good fit.
5.2.1 Introduction to the Architecture
Redis clusters are structured with N equal-weighted master nodes, each corresponding to M slave nodes, and due to the voting mechanism of Redis clusters, N must be an odd number and must be greater than or equal to 3, otherwise the creation of the cluster will fail.
The most commonly used Redis cluster architecture is 3 masters and 3 slaves, which has been tested extensively in the industry.
5.2.2 Resource Requirements
When deploying a 3-master-3-slave Redis cluster, it is recommended that at least three servers be mastered and slaveed, with the master and slave nodes randomly assigned when building the Redis cluster.
If you want to achieve more extreme high availability and avoid the situation where the master and slave nodes are assigned to exactly one machine and the entire Redis cluster is unavailable due to server downtime, you can prepare 6 servers for a 3-master-3-slave Redis cluster, so that any server downtime will not affect the external service of the Redis cluster.
5.2.3 Advantages and Disadvantages
Advantages:
When the master node goes down, the slave nodes can automatically be promoted to the master node based on the voting mechanism, which makes Redis services more highly available.
Data partitioning on different master nodes can significantly improve the performance of the Redis service.
Disadvantages.
Because of the partitioned data storage, when a master node and its corresponding slave nodes are all down, the entire Redis cluster will be unusable.
When the number of surviving master nodes is less than half of the total number of nodes, the entire Redis cluster will also be unavailable.
Regardless of whether there are three services or six servers, we can see that Redis clusters require more resources and are more expensive to operate and maintain than Redis alone.
Documentation: Installing and Configuring Redis Clusters on Linux Systems
To summarize, Redis clustering can make Redis services more highly available, but it is recommended that you consider the choice carefully.
The Redis sentry model is based on the Redis master-slave model. Redis 2.8 and later provides the sentry tool to automate system monitoring and fault recovery. The role of the sentry is to monitor whether the master and slave are running properly, and to automatically convert the slave to master when the master fails.
It is recommended to use at least two Sentinels (because the Sentinel mode requires at least two Sentinels to agree on the failure of the master server, so at least two or more Sentinels should be deployed).
The most common Redis sentry scheme is 1 master, 2 slave, and 3 sentinels, which can achieve good high availability.
It is possible to deploy master, slave, and sentry nodes on one or more servers, but as with Redis clusters, if we want to achieve the ultimate in high availability and avoid having one server go down and the entire Redis service become unavailable, then deploy each node on a separate server.
Sentinel mode is an upgrade of master-slave mode, and the system is more robust and has higher availability.
Disadvantages:
Can't support high concurrency, and only the master node can provide write capabilities.
To summarize, Redis sentry mode also makes Redis services more highly available, but it is also more costly in terms of operations and resources, and the biggest drawback compared to Redis clusters is that performance is the same as standalone, which does not improve the performance of Redis services.
One of the key points in cluster consistency is file consistency, and Fanruan provides multiple solutions to ensure the consistency of resource files between nodes. We can choose based on operation and maintenance capability and actual scenarios.
Note: "Auto-sync between nodes" is not applicable to multiple nodes, otherwise it will affect the use due to the communication problem between nodes, only when two nodes are supported, please use "File Server" when more than two nodes.
Inter-node synchronization is the simplest solution to guarantee the consistency of resource files between nodes.
No need to open a file server, no need to do any configuration to use, no operation and maintenance costs, very low cost of use.
Each node stores files, so it can achieve the effect of hot standby and has high availability.
The more nodes there are, the more synchronization may fail or affect the usage due to untimely synchronization due to communication and synchronization efficiency, which can seriously lead to high memory occupation or even downtime. So only two nodes are supported to synchronize with each other.
To summarize, the automatic synchronization between nodes can meet the needs of dual hot standby, with low operation and usage costs and no additional maintenance components, but it is not applicable to three or more nodes.
Note: Version 10.0.5, which was released on 2020-04-26, already has the ability to synchronize empty folders between nodes, and remote design from the Nginx portal does not result in the disappearance of folders.
Fanruan supports a variety of file servers, the following will explain the advantages and disadvantages of each type of file server.
First, we will explain the common advantages and disadvantages of file servers, common advantages and disadvantages means that no matter what kind of file server you choose, all of them have.
High file consistency, as each node reads resource files from the same file server, no synchronization is involved and the resource files read by each node will always remain consistent.
Suitable for multi-node and super multi-node scenarios.
The cost of use is higher than inter-node synchronization. The use of an additional component leads to slightly higher deployment and operation and maintenance costs and requires more resources to support these components.
High stability
Good performance and high read write speed
Non-highly available solution, downtime will affect the entire service usage
Easy to deploy, comes with Linux
Non-high availability solution, downtime will affect the use of the entire service
Because SFTP transmission method uses encryption/decryption technology, the transmission efficiency is much lower than normal FTP
Highly available solution, distributed file system with high fault tolerance
Difficult to deploy, high operation and maintenance costs, recommended for companies that already have HDFS services to choose this solution
Hardware storage (NAS): high stability, storage space is generally large
Software storage (NFS): easy to deploy, mature solution
Hardware storage: High cost and not fully highly available, service will be affected even after downtime
Software storage: non-highly available, clients can no longer provide services after server side downtime
Documentation: Linux system installation and configuration of FTP, Windows system configuration of FTP services, Linux system configuration using SFTP, HDFS repository
To summarize, when we have more than 2 nodes, it is recommended to use a file server in order to ensure high consistency of files in each node. Based on the high availability, performance requirements, and the actual situation of the company (whether there is already a file server), then select the corresponding file server.
The JAR package of 2019-11-08 adds cache mode, which can be selected by the front-end. Cache and file server can increase the high availability of file server when used together, and the following describes how to select it.
Cached resource files: including report files, dashboard files, configuration files, map data, etc. Currently, there are four folders: "reportlets/", "resources/", "assets/" and "dashboards".
Active cache: Cache all resource files.
Passive caching: Cache only the accessed resource files.
If the cache is enabled when using the file server, when the file server is down, the system can read the resource files from the cache and still provide normal services to the public.
Caching avoids frequent file reads and writes, which is faster and can significantly improve the performance of template access.
Caching will occupy system memory resources.
To summarize, turning on caching can significantly improve the performance of the project, and when used with a file server, it can improve the high availability of the system, so it is recommended to turn on caching when using a file server.
The external database is also a key point in the cluster solution. Since all nodes use the same external database, the configuration between nodes can be kept consistent. FineReport and FineBI can support all common databases, including MySQL, SqlServer, Oracle, DB2, which will not be introduced in detail here. If your company already has database services and the database version meets the requirements of Fanruan, you can use it directly. If you need to deploy new database services, it is recommended to deploy MySQL, which is easier to deploy.
Using the documentation: Configuring an external database
Fanruan cluster supports both TCP and UDP communication protocols, currently the default is TCP protocol, the following are the differences between the two protocols.
One thing to note is that most cloud servers (Ali cloud, Amazon cloud, etc.) do not support UDP protocol, so you can only choose TCP protocol.
If the server supports both TCP/UDP protocols, when the number of nodes is small, the difference between TCP/UDP protocols is not significant, but when the number of nodes is large, it is recommended to choose UDP protocol for more efficient communication.
售前咨询电话
400-811-8890转1
在线技术支持
在线QQ:800049425
热线电话:400-811-8890转2
总裁办24H投诉
热线电话:173-1278-1526
文 档反 馈
鼠标选中内容,快速反馈问题
鼠标选中存在疑惑的内容,即可快速反馈问题,我们将会跟进处理。
不再提示
10s后关闭