This section describes the main features of the JReport Server Cluster. Some of these features are also available through the API. With these features in mind, you will be better able to understand JReport Server Clusters and easily use them.
In a distributed cluster, you can accomplish all administrative tasks from any single node.
After logging onto the cluster from a clustered server as an administrator, certain security administrative tasks can be performed:
As for scheduled tasks in a cluster environment, JReport Server provides a load balancing mechanism which enables the server to work more effectively.
Every clustered server has a scheduler, and among the schedulers those with a lease are active schedulers. When the time of a scheduled task arrives, active schedulers compete and the winner gets to trigger the schedule. When dispatching tasks, the server which has the active scheduler will select a server according to load balancing algorithm and allocate the task to it.
Here are the benefits of deploying load balancing in a JReport Server Cluster.
By default, in a JReport Server Cluster all nodes of the cluster compete to become the active scheduler when the time of a scheduled task arrives. If the scheduled task has been bound with a trigger, then the node who gets the trigger becomes the active scheduler. The active scheduler for the task will then determine the server that will be asked to run the scheduled report based on load balancing. The Cluster Scheduler Lease option allows you to limit the number of servers competing for each scheduled report by setting a Cluster Scheduler Lease Active Count. As long as the count is less than the total number of nodes in the cluster, only the nodes holding a lease will compete to become the scheduler for the report that is ready to run. Depending on the number of scheduled reports you have, you may find that setting the Lease Active Count to 1 or 2 will provide more overall throughput on the system so the other nodes never have to be concerned about scheduled tasks.
There are two additional parameters that can be set:
There is a JReport Server residing in each node of a JReport Server Cluster. The main factor that affects load balancing is the number of concurrent reports that are running on every JReport Server. In order to avoid heavy load, every member server in the cluster has been enabled to send the number of concurrently running reports on it to the other cluster nodes.
JReport Server Cluster supports several algorithms for load balancing clustered servers. Configurable algorithms for load balancing clustered servers are:
| Number of currently running reports | |
| Weighted current reports= |
|
| Performance Weight |
Performance weight is a positive floating point number that you set to each server in a cluster on any clustered server. Use JReport Administration page > Cluster > Weight panel and measure the performance of a typical report on each node of the cluster. The higher performance weight you set to a clustered server, the higher chance it may get selected by the server that holds the active scheduler during load balancing. See Configuring performance weight for how to set performance weight and how this algorithm works.
If you do not set performance weight, by default the algorithm will work the same as Round Robin.
You can check the status of the clustered servers on JReport Server Monitor and notice the failure of any member server. If a member server is down, JReport cluster will remove it from the active clustered server list.
Effect on load balancing
When JReport cluster detects a failed member server, it will remove the member server from the active server list and will not schedule reporting tasks to that server any more. Load balancing will proceed on the remaining active servers.
Effect on incomplete tasks
When JReport cluster detects a failed clustered server, it will check the shared table for the list of incomplete tasks and will then reassign all incomplete tasks to other active servers using the load balancer.
Effect on completed tasks
JReport supports only report level recovery but not session level recovery. Once a report task is completed, it will be written to temporary storage for redirection to the requester. Failure after that will not be recovered.
If you have enabled the notifying of server down feature, when a member server crashes or is disconnected with the cluster, JReport cluster will send a notification e-mail to a specified address.
In a pure distributed cluster the resource files are not stored in a central place. Each server has its own directories to be able to hold all types of resources including catalogs, templates, dashboards and report results. The sharing of resources among servers is achieved via a copying mechanism. More copies of resources reduce the possibility of resources being lost if a server goes down. However, making too many copies consumes system resources by making copies that are never used.
There are two copying scenarios. One is when a resource is saved, JReport will copy the resource to other randomly selected servers within the cluster, according to an argument: the number of copies allowed for this type of resource. The saved resource itself is regarded as a copy. That is, in the case when copy number is three, two other random servers will each be given a copy of the resource.
The other is on demand when a resource does not exist on the local server. JReport will search among the other servers for the resource and copy it to the local server.
The controllable number of copies argument is available to administrator users on the JReport Administration page > Cluster > Configuration panel. These types of resources support distribution: history resources which are resources saving into the versioning system, realm resources, CRD results that are cached report results, and memory storage related resources. You will be able to find the number of copies setting for each type.
The best number to use for each resource depends on two factors, how many points of failure do you want to tolerate and how often resources which are not local are requested by users. For example on a 10 node system, you might want to still run in case any two nodes go down. In this case, you would want the number of copies to be three. Any two nodes could go down and there would still be one with a copy of the resources. However, if there is a lot of on-demand requests that require copies you might find that a higher number actually provides better average performance for your users since they are not waiting for resources when they make on-demand requests.