Overview of load balancing
The farm-cluster-node concept allows you to configure and manage how the data is analyzed. Creating individual clusters, you can for example, define unique data sources to monitor specific software services, configure separate client aggregations schemes or different applications monitoring where the data should be analyzed and reported in a per application manner.
Report server load balancing provides greater scalability, usability and data integrity:
- Application users are automatically load balanced across all nodes in the cluster.
- As demand increases, more nodes can be added to seamlessly scale the solution.
- The primary node provides a single entry point to view all data.
- Avoid duplicating traffic across report servers in large scale deployments.
- Configuration is shared to all nodes in the cluster reducing configuration overhead.
In situations where any of the individual clusters is under-performing you can add an extra node, or nodes, to the cluster in order to alleviate the workload for that cluster. Once the new node is added to the cluster, the primary node of the cluster will automatically balance evenly the number of observed unique users between all the nodes located within the cluster. The unique users moved to the new load balancing node will retain their historical data on their original report server node. With time, moved users data will be located on the new node in its entirety. The amount of time depends on your data storage settings. If you wish to manually distribute load across report servers this can be achieved with filtering configured through the report server advanced properties editor.
Once an existing node is removed from a cluster, the load is not redistributed until the next execution of the sampling task and all historical data processed by that node will remain with that node.
While the load balancing occurs on a unique user level, some unique users may contain different amounts of data associated with them for example, number of operations. In such instance, while the number of users is balanced evenly between all nodes, some nodes will have a larger processing load. This, combined with possible differences in system hardware, may cause for some the nodes to perform diversely.
The software service packs do not need to be applied in any specific order within the load balancing cluster. As a general rule, the software service packs and patches should first be applied to the primary node and then all other nodes. It is recommended to keep the same software version on all Nodes within the cluster. If all nodes share the same database server, it is recommended to deploy the service packs successively as not to overload the database server.
Limitations of load balancing
A load balanced cluster provides a great scalability, but there are limitations that should be observed when following this style of deployment.
Every data source located within a cluster will report its monitoring data to a primary node of a given cluster. Next, that primary node will distribute the monitored data among all nodes of the same type within the cluster using the unique users load balancing method. Even though, all data sources transmit data only to the primary node, all data sources must be connected to every node in the cluster to ensure execution of any administrative and diagnostic tasks . If combining existing deployments, or operating in large environments, this can add extra overhead to the network management.
Uneven load balancing
While the load balancing occurs on a unique user level, some unique users may contain different amounts of data associated with them for example, the number of operations. In such instance, while the number of users is balanced evenly between all nodes, some nodes will have a larger processing load. This, combined with possible differences in system hardware, may cause for some the nodes to perform differently.
URL aging is performed per report server and not per cluster. This means that an operation could be aged out on some report servers and not on others. This could lead to different numbers being reported for operations when viewing them historically from when they were first recorded.
In a standalone report server deployment, a report server will determine if an operation is eligible to be aged out or not. If it is aged out, the data will be collected in the All other operations metric. If you examine this operation for yesterday, and it has been aged out, it will be missing. In the clustered environment, this could be aged out on some of the report servers but not all. This will cause the statistic to be different than they were earlier.