A node is a single report server that shares its configuration and monitoring responsibilities with its peers within the same cluster.
There are two types of nodes within any given cluster: primary node and secondary (regular) node. The primary node within each cluster represents all of the secondary nodes located in that cluster. Each of the nodes is responsible for analyzing an equal portion based on number of unique users observed in the monitored traffic destined for the cluster. Adding a new node to a cluster increases the analysis performance by automatically balancing the monitored traffic load between all nodes within the cluster.
Each type of node (CAS and ADS) within a cluster must have its own primary node. Newly added nodes that are not fresh report server installations must be authorized by the Central Security Server that is designated for the cluster.
New additions to the cluster may require database reset or cleanup. The database reset is required if the node being added has different site and user option settings from the primary node's settings of the edited cluster. For more information, see CAS Configuration.
New nodes that are fresh installations and contain no data in their databases automatically receive the configuration and data to analyze, so no reset is necessary. This process occurs after at least one configuration refresh interval (by default, approximately 10 minutes).
Primary node in the primary cluster. This node is responsible for sharing its configurations and settings with the rest of the nodes and clusters based on synchronization options set at each cluster. This is the node that collects data from all other clusters and displays all reports. This is the node that can display the reports of data monitored by the entire farm.
The green label indicates that the connection and configuration statuses are available and the node type is CAS.
Primary node in a secondary cluster. This node is responsible for sharing its configurations and settings with the rest of the nodes (report servers) attached to the particular cluster. Any configuration changes and settings will propagate to all nodes of the same type within the given cluster.
Based on the synchronization settings for the cluster, this node acquires its configuration from the primary node of the primary cluster.
A report server located either within the primary or a secondary cluster. It acquires its configurations and settings from the cluster's primary node of the same type.
Viewing reports via report server nodes is not advised, because the data available to a single node is only a section of all monitored traffic (load balancing distributes traffic among nodes in a cluster).
A node located either within the primary or a secondary cluster.
The gray label indicates that the connection and configuration statuses are unknown and the node type is CAS.
A node located either within the primary or a secondary cluster.
The red label indicates that the connection and configuration statuses are unavailable.
A node located either within the primary or a secondary cluster containing an invalid or expired license.
An example of a primary node in draft mode. The label indicates that the configuration has been changed but has not been published. Typically, draft mode permits an additional reset option in the action menu of the node.
An example of a primary node in draft mode, which is processing and publishing the configuration or resetting the node.
Accepted client or server IP address ranges
Nodes previously operated as standalone report server or a load balancing server, may contain accepted client or server IP address range definitions to limit the traffic they monitor. If such a report server is selected as a primary node while creating a new cluster, the entire cluster and all secondary nodes within, will limit their monitoring with accordance to the IP address ranges defined on the primary node. Monitoring limits defined by client or server IP address ranges will propagate to all nodes within a given cluster.
Accepted client or server IP address range definitions were typically used to control the load of each report server and spread the load evenly by filtering the incoming data to the CASes or ADSes by configuring the Accepted client IP address range (
RtmJob.client) and Accepted server IP address range (
RtmJob.server) properties available in the CAS Advanced Properties Editor.
Since current farm hierarchy performs load balancing within a cluster automatically, the range definitions used for this purpose in previous deployment may hinder the load balancing performance. However, if you have used the range definitions to limit the observed traffic to a specific portion, and you wish to maintain this limitation, you can leave the range definitions on the the primary node and continue creating the new cluster. If you wish for the new cluster to monitor all available traffic, you must remove the ranges from the primary node.
Each node is capable of three basic actions: add failover, delete node, and reset node. All secondary nodes also include an additional option of setting the selected node as primary.
Use this option to select a standalone report server of the same type and attach it as a failover server. For more information, see Report server failover overview.
Set as Primary
Use this option to set the current node as the primary node for this cluster. This will demote the current primary node to a regular node within the cluster and set the selected node as the primary node. The configuration of the new primary node will be distributed to the rest of the nodes attached to the cluster within approximately 5 to 10 minutes.
Use this option to remove this node from the cluster and from the farm. This action resets the node as a standalone report server, but it retains the data and options used while operating within the cluster. Removing a node from a monitoring cluster creates an incomplete data set because the analysis is based on equal distribution of monitored traffic between all nodes within the cluster.
If removed node did not have a failover server, the historical data stored on that node will not be available for reporting and will be missing from any historical reports generated by that cluster.
When a node is removed from a cluster the load is not redistributed until the next execution of the nightly tasks and all historical data will remain with that node.
There is no possibility to preserve the historical data stored on the node if you plan to permanently remove that node from the cluster.
Reset node (available only in draft mode)
Use this option to reset the node, which purges all data from its database and prepares the node to be synchronized within the cluster.
Resetting a node deletes all data in the report server's database. We recommend that you reset a node only if it has previously been part of another cluster, or has been monitoring traffic as a standalone report server and contains monitoring data.