In simple installations of RockSolid only a single RockSolidAgent is required to be installed. This would be typical for ~70% of RockSolid sites.
However for more complex deployments, multiple RockSolidAgents may be required. Factors which may influence the use of multiple RockSolidAgents include:
- High availability of RockSolid monitoring
- Large number of SQL Server instances deployed
- WAN Connections
- Separate Network Domains or Secure Zones
- Multi-site set up
High availability of RockSolid monitoring
Multiple agents can be used to avoid a single point of failure in terms of RockSolid monitoring, being the RockSolidAgent host. If multiple agents are deployed to a single RockSolid site, RockSolid will dynamically load balance instances between Agents. If either of the RockSolidAgent's were to go offline for a period of 2x the configured monitoring interval, RockSolid will automatically move all the agents monitoring workload to the remaining RockSolidAgent(s).
Once communication with the failed agent is re-established, RockSolid will automatically reassign the relevant monitoring workload between all on-line RockSolidAgent hosts.
Large number of SQL Server instances deployed
If more than 300 SQL Server instances are deployed, then one RockSolidAgent should be installed for each multiple of 300 instances. This is required for the best monitoring performance.
NOTE: An unlimited number of SQL Server instances can be supported on a single monitoring host, however monitoring performance may suffer.
If many SQL Server instances are located across a WAN connection from the primary RockSolidAgent it may be beneficial to locate a RockSolidAgent on the same network segment as the remote SQL Server hosts.
This is because the RockSolidAgent to SQL Server instance connection expects a high speed connection and data flows between the RockSolidAgent and SQL Server instance uncompressed. However data from the RockSolidAgent to the central RockSolid monitoring software assumes a low bandwidth connection. Data is highly compressed and de-de-duplicated before transmission.
In this scenario if the SQL Server instances and RockSolidAgent are on opposing ends of a WAN connection, there is more traffic than required flowing over that WAN connection between the RockSolidAgent and SQL Server environment(s). If multiple SQL Server hosts are deployed, the monitoring traffic can become limited by bandwidth causing monitoring delays. Locating a RockSolidAgent on the same network as the SQL Server instances will substantially reduce the WAN traffic load and allow a larger number of SQL Server instances to be monitored.
The RockSolidAgent runs in the security context of a single Windows Domain account. If multiple windows domains exist without trusts between them, or networks are physically isolated via firewalls, it may not be possible for a single RockSolidAgent to be able to connect and/or authenticate with the target SQL Server environments.
In this scenario a separate RockSolidAgent would be required on each isolated network.
Windows Host not in a Domain
It is possible for the RockSolidAgent to monitor SQL Server instances installed on non-domain servers (stand-alone hosts) without installing a separate RockSolidAgent. This is achieved using Windows pass through authentication. For this to occur the domain service account being used to run the relevant RockSoldiAgent service must have an account with exact matching Username and Password created on the stand-alone windows host. This account must also have SQL Server syadmin and local Windows administrator rights on the stand-alone host for RockSolid monitoring to successfully collect all monitoring data.
Multi Site setup
A RockSolidAgent is scoped to a single site configuration within RockSolid. If you have created multiple sites, for example in a parent/subsidiary structure or in a service provider/customer structure, each site requires at least one agent to be created.